Scott Taylor was the release lead for WordPress 4.4. He outlined several goals for the release, including closing many tickets, front-loading development, and finding out what could realistically be accomplished with limited resources. Some of the major features included in 4.4 were the REST API, responsive images, comments overhaul, and Twenty Sixteen theme. Taylor discussed lessons learned, like the high burnout rate among volunteers and the significant technical debt in WordPress. He presented case studies on refactoring PHP code structure and improving performance of AJAX unit tests. Taylor argued for moving away from globals and treating WordPress as one part of a larger system, and drew inspiration from practices like PSR standards, Composer,

1. (Beyond)
WordPress 4.4
WordCamp NYC, 2015

3. Scott Taylor
• WordPress 4.4 Release Lead
• Core Committer
• Sr. Software Engineer, The
New York Times
• @wonderboymusic on Trac/
Twitter/Swarm/Instagram

4. Pre-4.4

5. 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

6. What’s in 4.4?
• REST API: Phase 1
• Term Meta + WP_Term
• Responsive Images
• Embeds beyond Embeds
• Twenty Sixteen
• Comments overhaul + WP_Comment

8. 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.

10. Case Studies from 4.4

11. “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

12. 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

13. Comments
• Comments were being queried in a ludicrous way
• Comment “permalinks” were designed poorly
• Extreme scale was not considered

14. “The Worst Case Scenario
should be your Default
Use Case” - Scott Taylor

15. Changes were made to
WP_Query that never made it
to WP_Comment_Query and
WP_User_Query

16. 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

17. Moden Application
Structure

18. Modern Structure

19. • Composer
• Node modules
• Gulp
• Git modules
• WordPress as a piece of a larger system

20. Ticking
Time
Bombs

21. “Globals will destroy
WordPress, Globals are
destroying WordPress”
- Scott Taylor

22. 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

23. PHP is NOT a
template language

24. 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

25. HTTP
• WordPress does not support parallel HTTP
• HTTP does not scale when requests are made
serially

26. WordPress:
Good Intentions

27. 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

28. 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

29. Meta Query
• the Metadata API is great
• it is great for READING data
• it is awful for searching by value

30. Where we can
draw inspiration

31. 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

32. {
"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"
}
}
}

33. 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

36. 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

37. <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>

38. Guzzle
• written by Michael Dowling from AWS
• allows asynchronous requests
• implements Promises/A+ in PHP
• implements PSR-7

39. <?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;
}
}

40. Questions?