WordPress 4.6, “Pepper”, has been released. It’s named, as always, after a famous jazz musician, and this release is named after Park Frederick “Pepper” Adams III, a baritone saxophonist and jazz composer.
The Release Lead for WordPress 4.6 was Dominik Schilling, known often as Ocean90, and the Deputy Release Lead was Garth Mortensen. There were 272 total contributors to this release. According to Aaron Jorbin, 85 of these contributors were first timers, so congratulations to all new WordPress contributors!
For this release, we did a special episode of the Post Status Draft podcast, which you can find on iTunes, Google Play, Stitcher, and via RSS for your favorite podcatcher. Post Status Draft is hosted by Joe Hoyle — the CTO of Human Made — and me, Brian Krogsgard.
In this episode, Joe and I discuss WordPress 4.6 and deep dive on a few of its features.
About WordPress 4.6
Here’s a video overview of WordPress 4.6:
Overall, this was a planned iterative release from the beginning, with a goal to fix as many longstanding bugs as possible, and to refine existing features, rather than to focus on a lot of brand new features.
Folks have been clamoring for a release like this for a long time, and in most respects 4.6 delivered. According to Trac, 489 tickets were closed, across 53 components, during the 4.6 milestone. Also, it shipped exactly on time.
User facing features
WordPress 4.6 has a few user facing features that aren’t huge functional changes, but nice interface enhancements.
No more bleak screen of sadness, as the team working on this termed it. The plugin installation, updates, and delete process is much smoother than it used to be. There’s a nice video of this from the initial proposal:
This was the second release where “shiny updates” features were a focus. To see some under the hood considerations for developers, there’s more information on that from Pascal Birchler.
WordPress is leaving Open Sans, which was introduced with the “MP6” admin overhaul of WordPress 3.8. You may have seen GitHub’s recent change to native fonts. It’s definitely a trend lately. Matt Miklic explains the switch from Open Sans to native system fonts in the WordPress admin.
The declaration of fonts when using system fonts has a good bit of science behind it, and may be useful for those of you who wish to do something similar for your own projects. Marcin Wichary has a really interesting post describing Medium’s process when they made the switch.
And if you’re curious, the new declaration is this:
font-family: -apple-system, BlinkMacSystemFont, "Segoe UI", Roboto, Oxygen-Sans, Ubuntu, Cantarell, "Helvetica Neue", sans-serif;
Inline link checker
WordPress will now automatically detect improperly formatted links, as you write. While this doesn’t check the validity of any properly written URL, it will ensure the URL you add in an
href is properly formatted. So, it will catch if you accidentally type something like
http:/w.org and outline it in red for you to fix.
If you copy and past a URL into the link editor, but don’t include
http:// at all (I do this a bunch), it auto detects and inserts it for you.
Browser content caching
Yet more efforts have been made to always ensure that you do not lose your content as you write. I followed the steps in the Trac ticket to see exactly what happens here.
So I typed the first sentence below, saved a draft, then typed the second paragraph:
What if I start typing and save a draft?
Then start typing some more, because that’s what bloggers do. And I chill here for a few seconds, then stupidly just reload this page?
Then I reloaded the page without saving again, and got this notice:
And just like that, the content is back, because it was saved in the browser’s local storage. Pretty cool.
There are several important developer centric features that you should know about.
Enhanced meta data registration
This is a significant aid to the (pending) REST API meta handling, but also improves other meta data functionality. The
register_meta() function allows developers to tell WordPress more about what specific meta data is designed to do. In WordPress 4.6, the arguments for this function have changed, enabling more information to be communicated in the third parameter, which is now an array.
show_in_rest key, an experimental key (until the API endpoint goes in), finally solves the issue for the REST API for knowing when to include meta data in the API’s default responses. It’s one step of a few that need to be made to better support meta for the API, but it’s a good step forward.
For plugin developers not using
register_meta(), be sure to learn more about it and the advantages, as there are quite a few. Jeremy Felt describes how to use
register_meta() on Make Core.
Translation priorities and changes
WordPress will now default to the translations from Translate.WordPress.org community translations, then pull from theme or plugin translation files. A procedure called “just-in-time” translation loading will be utilized, and for plugins and themes distributed through the official repository,
load_theme_textdomain() no longer need to be used.
Commercial plugin authors will still largely follow the same internationalization procedures they always have.
In a related note, and quite impressively, WordPress 4.6 shipped 100% translated in 50+ languages.
Joe helped teach me more about resource hints on the podcast, and Aaron did a much better job detailing resource hints than I could, in his excellent field guide:
Resource Hints is a rather new W3C specification that “defines the
prerenderrelationships of the HTML Link Element (
)”. These can be used to assist the browser in the decision process of which origins it should connect to, and which resources it should fetch and preprocess to improve page performance.
In 4.6, WordPress adds an API to register and use resource hints. The relevant ticket is #34292.
Developers can use the
wp_resource_hintsfilter to add custom domains and URLs for
prerender. One needs to be careful to not add too many resource hints as they could quite easily negatively impact performance, especially on mobile.
Resource hints can be very useful for certain situations, and it’s a technique that I personally need to explore further. Those of you doing advanced performance-driven development will surely be excited about support for this in WordPress.
The Customize API continues to evolve and improve, and Nick Halsey walks through new developer-focused features and changes to the API for WordPress 4.6. Also quite notably, Weston Ruter describes new APIs for both settings validation and notification management in the customizer.
Other developer-centric changes
Multisite changes: Jeremy Felt describes
WP_Network_Query, and goes over a few new functions and filters.
There is now a persistent comment cache, allowing more performant comment loading functionality. Rachel Baker, the comments component maintainer, explains further.
The WordPress HTTP API now uses the Requests library, as Ryan McCue describes.
Aaron Jorbin describes some of the lower level WordPress loading priorities and defaults that have changed. He also describes how WP CLI and core have reconciled their differences in
wp-settings.php, which makes backward compatability for WP CLI possible now.
Boone Gorges describes the introduction of
WP_Term_Query. He’s the term whisperer. As Joe and I discuss in the podcast, these sorts of changes make for better consistency in WordPress, and provide an improved developer experience.
WordPress 4.6 is the result of hundreds of community members. You can find their names and links to their profiles on the official release post.
Also check out the official 4.6 Codex page that has a lot of handy information and links to source Trac tickets. You can see all closed tickets from 4.6 on the Trac milestone. View all new functions, classes, methods, and hooks on the official Developer Reference. And learn more about some of what I discuss above, and other items, on the ever-helpful field guide.
For the record, WordPress 4.5 was downloaded more than 45 million times. You can track 4.6 downloads on the page dedicated to the task.
Thank you to everyone who contributed to WordPress 4.6! I hope you have a or to celebrate if that’s your kind of thing, or otherwise your efforts.
Podcast Sponsor: Prospress
Prospress exists to make the world’s best eCommerce platform a little better, because they want to help entrepreneurs prosper with WordPress. They are the creators of WooCommerce Subscriptions, PayPal Digital Goods, and One Page Checkout. Check them out at Prospress.com.