Advertisement
Advertisement

More Related Content

Advertisement
Advertisement

WordPress 4.4 and Beyond

  1. (Beyond) WordPress 4.4 WordCamp NYC, 2015
  2. Scott Taylor • WordPress 4.4 Release Lead • Core Committer • Sr. Software Engineer, The New York Times • @wonderboymusic on Trac/ Twitter/Swarm/Instagram
  3. Pre-4.4
  4. My goals for 4.4 • Close as many tickets as possible • Front-load development, no lull in activity • Work on as many things as possible • Find out what can be accomplished - try things, revert doesn’t matter • Find out what really needs to be fixed • Rely on no one else to make progress • Set goals for Trac
  5. What’s in 4.4? • REST API: Phase 1 • Term Meta + WP_Term • Responsive Images • Embeds beyond Embeds • Twenty Sixteen • Comments overhaul + WP_Comment
  6. Things I learned • Committers have a responsibility to the community to move the project forward. Those who patch tickets have no ability to commit their own code. • Volunteers are not beholden to a project schedule. • The burn out rate on components and features is high. • WordPress has frightening amounts of technical debt.
  7. Case Studies from 4.4
  8. “PHP Manifests” • a file like post.php contained PHP classes, dozens of functions, and sometimes “top-level code” • without a plan for these domains of the code, the future will just be more bloat • PSR-1 tells us to not mix symbols and side-effects • Hack disallows top-level code
  9. File Structure • Classes should live in their own files • Important for code organization • Important for developer experience (DX™) • Essential for Autoloading • Moved functions out of admin handlers
  10. Comments • Comments were being queried in a ludicrous way • Comment “permalinks” were designed poorly • Extreme scale was not considered
  11. “The Worst Case Scenario should be your Default Use Case” - Scott Taylor
  12. Changes were made to WP_Query that never made it to WP_Comment_Query and WP_User_Query
  13. AJAX Unit Tests • Have been running slow forever • Everyone thought it was because of the @runInSeparateProcess annotation • Every test method was internally triggering ‘admin_init’ • ‘admin_init’ has the following callbacks hooked to it: • _maybe_update_core • _maybe_update_plugins • _maybe_update_themes
  14. Moden Application Structure
  15. Modern Structure
  16. • Composer • Node modules • Gulp • Git modules • WordPress as a piece of a larger system
  17. Ticking Time Bombs
  18. “Globals will destroy WordPress, Globals are destroying WordPress” - Scott Taylor
  19. Backwards Compatibility • Once a global is added, it can almost never be replaced • Globals are not immutable, every global import requires type-checking or re-instantiation • Top-level variables arbitrarily get hoisted into global scope • Functions are an anti-pattern in modern PHP • Functions exist mainly for Themes to use
  20. PHP is NOT a template language
  21. Template Language • PHP is not a template language • WordPress Themes are not portable • inline PHP logic in markup is dangerous • Engines like Mustache can be shared between PHP and JS
  22. HTTP • WordPress does not support parallel HTTP • HTTP does not scale when requests are made serially
  23. WordPress: Good Intentions
  24. REST API • It’s great that we added this • The main thing this does is replace XML-RPC • REST is not new • WordPress is not unique for having REST • Many other languages/frameworks do it
  25. Browserify • write code that looks like Node for the browser • break code into modules • Media has to use a modified version of it • Media exposed everything to global scope, so plugin devs had the ability to wipe out entire objects with their own version
  26. Meta Query • the Metadata API is great • it is great for READING data • it is awful for searching by value
  27. Where we can draw inspiration
  28. PSR • PSR-1 and PSR-2 describe Coding Standards • PSR-3 describes Application Logging • PSR-0 PSR-4 describes Autoloading • Autoloading simplifies large codebases • Autoloading encourages OO • PSR-7 describes HTTP Request/Response interfaces
  29. { "repositories":[ { "type":"composer", "url":"http://wpackagist.org" }, { "type": "vcs", "url": "https://github.com/newsdev/nyt-wp-media.git" }, { "type": "vcs", "url": "https://github.com/newsdev/nyt-wp-bylines.git" } ], "require": { "guzzlehttp/guzzle": "~6.0", "mustache/mustache": "~2.5", "symfony/http-foundation": "~2.7", "monolog/monolog": "~1.14", "wpackagist-plugin/akismet": "~3.1", "wpackagist-plugin/amazon-s3-and-cloudfront": "~0.9", "wpackagist-plugin/amazon-web-services": "~0.3", "wpackagist-plugin/rewrite-rules-inspector": "~1.2", "wpackagist-plugin/debug-bar": "0.8.*", "wpackagist-plugin/debug-bar-console": "0.3.*", "newsdev/nyt-wp-media": "dev-master", "newsdev/nyt-wp-bylines": "dev-master" }, "prefer-stable": true, "autoload": { "psr-4": { "NYT" : "lib/php", "NYTShell": "wp-content/themes/shell/php" } } }
  30. Node / Gulp / Express • JavaScript is extremely popular • Node is the back end and the front end • Node is easy compared to many other low-level languages • Express is way easier than learning Apache/nginx • Express routing is dead simple • Share code on the back-end / front-end
  31. Mustache • Mustache is my current favorite template language • Mustache is almost completely devoid of logic • Mustache requires you to query your data ahead of time • Mustache is portable • tools like Hogan allow you to compile your backend templates for the front end
  32. <span class="byline" itemprop="author creator" itemscope itemtype=“http://schema.org/Person" itemid="{{ meta.website }}"> {{# meta.website }} <a href="{{ meta.website }}" rel="author" title="{{ l10.more_articles_by }}{{# upper }} {{ display_name }}{{/ upper }}"> {{/ meta.website }} <span class="byline-author" data-byline-name="{{# upper }}{{ display_name }}{{/ upper }}" itemprop="name" data-twitter-handle="{{ meta.twitter }}">{{ display_name }}</span> {{# meta.website }}</a>{{/ meta.website }} </span>
  33. Guzzle • written by Michael Dowling from AWS • allows asynchronous requests • implements Promises/A+ in PHP • implements PSR-7
  34. <?php namespace NYTHttp; use GuzzleHttpPromise; trait Client { protected $client; protected $promises = []; public function setConfig( $config = [] ) { $this->client = new GuzzleHttpClient( $config ); } public function add( $key, $request ) { $this->promises[ $key ] = $request; } public function send() { $results = Promiseunwrap( $this->promises ); $responses = []; foreach ( $results as $key => $response ) { $responses[ $key ] = [ 'status' => $response->getStatusCode(), 'headers' => $response->getHeaders(), // convert PsrHttpMessageStreamInterface to string 'body' => (string) $response->getBody(), ]; if ( in_array( 'application/json', $response->getHeader( 'Content-Type' ) ) ) { $responses[ $key ]['body'] = json_decode( $responses[ $key ]['body'], true ); } } // clear the queue $this->promises = []; return $responses; } }
  35. Questions?
Advertisement