(Beyond)
WordPress 4.4
WordCamp NYC, 2015
Scott Taylor
• WordPress 4.4 Release Lead

• Core Committer

• Sr. Software Engineer, The
New York Times

• @wonderboymusic on Trac/
Twitter/Swarm/Instagram
Pre-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
What’s in 4.4?
• REST API: Phase 1

• Term Meta + WP_Term

• Responsive Images

• Embeds beyond Embeds

• Twenty Sixteen

• Comments overhaul + WP_Comment
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.
Case Studies from 4.4
“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
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
Comments
• Comments were being queried in a ludicrous way

• Comment “permalinks” were designed poorly

• Extreme scale was not considered
“The Worst Case Scenario
should be your Default
Use Case” - Scott Taylor
Changes were made to
WP_Query that never made it
to WP_Comment_Query and
WP_User_Query
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
Moden Application
Structure
Modern Structure
• Composer

• Node modules

• Gulp

• Git modules

• WordPress as a piece of a larger system
Ticking
Time
Bombs
“Globals will destroy
WordPress, Globals are
destroying WordPress”
- Scott Taylor
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
PHP is NOT a
template language
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
HTTP
• WordPress does not support parallel HTTP
• HTTP does not scale when requests are made
serially
WordPress:
Good Intentions
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
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
Meta Query
• the Metadata API is great
• it is great for READING data
• it is awful for searching by value
Where we can
draw inspiration
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
{	
				"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"	
	 			}	
				}	
}
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
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
<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>
Guzzle
• written by Michael Dowling from AWS
• allows asynchronous requests
• implements Promises/A+ in PHP
• implements PSR-7
<?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;	
	 }	
}
Questions?

WordPress 4.4 and Beyond