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,
3. Scott Taylor
• WordPress 4.4 Release Lead
• Core Committer
• Sr. Software Engineer, The
New York Times
• @wonderboymusic on Trac/
Twitter/Swarm/Instagram
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
7.
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.
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
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
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
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
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
34.
35.
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