Customizer improvements in 4.4

Now an update for the hottest most buzz-worthy JavaScript-driven single page application (SPA) in WordPress: Calypso the Customizer. Earlier in the release cycle there was a proposed roadmap for the Customizer and I wanted to share an update for what improvements have made it into the 4.4 release. I won’t include everything, but I’ll highlight some items that you may notice or want to make note of.


As noted on the roadmap, the focus for the Customizer in 4.4 has been to improve performance, and there are some drastic improvements in this release. Note that selective refresh (#27355, neé partial refresh) did not make it in, however the feature plugin now has a pull request for review.

Multidimensional Customizer settings (options & theme mods) are not scalable (#32103)

In 4.3 the time to load/refresh the Customizer preview increases exponentially as the number of settings/controls grows. If you have 200 settings it can take 15 seconds for the preview to update. If you have 300 settings, it can take 36 seconds to load/refresh the Customizer preview. And the time to reload the preview continues to grow exponentially as the number increases:

With the fixes in place for 4.4, the time to refresh the preview grows linearly very slowly (basically flatlined) as opposed to exponentially. I would share a graph, but it would be a very boring flat horizontal line.

See also aggregated multidimensional settings below.

Reduce Customizer peak memory usage by JSON-encoding settings and controls separately (#33898)

In addition to the slow preview load/refresh time, when there are a lot of Customizer settings/controls registered, the process for exporting the data from PHP to JavaScript used a lot of server memory when it serializes the JSON data in 4.3. In 4.4, each setting and control now gets serialized individually in a loop to avoid the memory spike, and this helps avoid any white screen of death due to the allowed memory size being exhausted in PHP.

Defer embedding Customizer widget controls to improve DOM performance (#33901)

The previous performance improvements were for the server and reduced the amount of time it takes to get a response (TTFB). Nevertheless, for sites that have a lot of widgets, the Customizer would still load very slowly, not due to WordPress being slow on the server, but due to the JavaScript running in the browser. In 4.3 given 100 widgets (with a lot of inputs), the Customizer could take 40 seconds to finish building the page due to all of the widget controls being embedded into the DOM. So in 4.4 we defer the embedding of widget controls until the contained widget area section is expanded, that is until the widget control is actually shown to the user. This results in the Customizer loading over 10× faster: what did take 40 seconds now takes 3 seconds in WordPress 4.4.

Widgets section in customize late to show up (#33052)

The widgets panel now will now always be shown even if there are no widget areas currently displayed in the preview. This ensures that the widgets panel doesn’t slide down after the preview finishes loading. This is another browser-based improvement that doesn’t actually improve actual performance but it does improve perceived performance, or at least the user experience.

Aggregated Multidimensional Settings

The problem with the scalability of multidimensional settings for options or theme mods (#32103) is that the number of filters added to preview changes grows exponentially (see above). The fix for this is to ensure that only one filter gets added for a multidimensional settings that share a common ID base. The entire root value for the option or theme mod gets stored in a variable, and any previewed setting’s value gets applied to that variable once, and this root value then gets returned by the filter. This construct is referred to in the source as a “aggregated multidimensional setting”. Note that this has only been implemented for options and theme mods: custom multidimensional setting types that subclass WP_Customize_Setting should also be able to make use of the functionality, although this has not been specifically tested.

Two new actions have been introduced:

  • customize_post_value_set
  • customize_post_value_set_{$setting_id}

These are triggered whenever WP_Customize_Manager::set_post_value() is called, and they allow for WP_Customize_Setting::preview() to update the value being previewed. You can now, for instance, call preview() on a setting up-front and then set the post value later, and the new value will be applied for previewing as expected. This can be called a “deferred preview” or “just in time” previewing.

Facilitate plugins to override Customizer features (#33552)

Sometimes widgets or menus are not applicable for a given site. Ticket #33552 introduces a new filter customize_loaded_components which allows nav menus or widgets to be skipped from initialization. For example, to prevent the nav menu functionality from being loaded the following plugin code can be used:

add_filter( 'customize_loaded_components', function ( $components ) {
    return array_filter( $components, function ( $component ) {
        return 'nav_menus' !== $component;
    } );
} );

JS Inline Docs

The Customizer is a JavaScript-heavy application, and in #33503 #33639 the inline docs for JS have been improved to help developers understand how it works. See [33709] [33911] [33841].

Non-autoloaded Option Settings (#33499)

When settings are registered for options that don’t already exist in the DB, an update for these settings in the Customizer would result in update_option() called with the default $autoload parameter and thus them being saved as autoloaded. In 4.4 you can now register option settings to explicitly not get added with autoloading, for example:

$wp_customize->add_setting( 'foo[first]', array(
    'type' => 'option',
    'autoload' => false,
) );

Other Improvements

  • #21389 Retina theme custom headers
  • #31540 Dropdown pages Customizer description option
  • #32637 Customizer should default to returning to the front page, not the themes page
  • #32812 Customizer Menus: Escaping inconsistencies — You can now use limited markup in nav menu item titles in the Customizer.
  • #33319 Customizer header image crop uses static URL when refreshing UI after crop.
  • #33665 Menu Customizer: Implement indicators for invalid menu items
  • #34432 Customizer subclasses can be broken out and remain BC — All Customizer PHP classes now reside in a separate files.
  • #34607 Customizer: Wrapped labels should align to start of label, not checkbox or radio button
  • New methods:
    • WP_Customize_Manager::get_preview_url()
    • WP_Customize_Manager::set_preview_url()
    • WP_Customize_Manager::get_return_url()
    • WP_Customize_Manager::set_return_url()
    • WP_Customize_Manager::set_autofocus()
    • WP_Customize_Manager::get_autofocus()
    • WP_Customize_Manager::customize_pane_settings()

Several accessibility fixes were also made.

See also the full list of tickets that were closed during the 4.4 release for the customize component.

#4-4, #customize, #dev-notes

WordPress 4.4: Field Guide

WordPress 4.4 is the next major release of WordPress and is shaping up to be an amazing release. While you have likely discovered many of the changes from testing your plugins, themes, and sites (you have been testing, right?), this post highlights some of the exciting 🎉changes developers can look forward to. 💥

Externally Embeddable

Using a handful of filters, you can customize how your site looks when it’s embedded elsewhere. As a part of the work around embeds, there are also a couple of new functions for retrieving and displaying embeddable content. The post above also links to a plugin which will remove the ability to embed your site elsewhere.

REST API Infrastructure Introduction

The infrastructure to create a REST API has landed in WordPress core.  Adding your own endpoints (or using the latest version of the REST API plugin) is now even easier.  The new embed feature mentioned above uses this new infrastructure.
Note: If you are using v1 of the API plugin, it is incompatible with 4.4, however an update is planned before 4.4 ships. The update will not use the new REST API infrastructure, so you’ll want to update your REST API usage eventually. If you are using v2 of the API plugin, be sure you’re on beta 5 or later; previous versions do not support WordPress 4.4.

Responsive Image Insertion

Through the use of a display filter, image tags in WordPress now include srcset and sizes.  These two attributes to the <img> tag allow browsers to choose the most appropriate image size and download it, ignoring the others. This can save bandwidth and speed up page load times. There are new functions, filters, and an additional default image size available to help with the creation of responsive images.

wp_title Deprecation Decision

Since WordPress 4.1, add_theme_support( 'title-tag' ); has been the recommended way of outputing a title tag for themes.  Now, a year later the wp_title function has been officially deprecated. Take a look at this post if you want to see all the great new filters you can use to modify title tags.

UPDATE 12 November – wp_title has been reinstated for the time being. It is a zombie function.  add_theme_support( 'title-tag' ); remains the recommended way to insert a title tag into your theme, however there were use cases for wp_title that were not accounted for in the original deprecation decison

Term Taxonomy Tranquility

WordPress 4.4 is the latest in a string of releases to feature major updates to the taxonomy system. This release introduces of term meta, a new WP_Term class, and a host of other under the hood changes.

Comment Component Cultivation

Comments received love both on the front end of sites and on the backend. On the front-end, the comment field will always appear first, before the name and email fields. This fixes a longstanding bug where the behavior was different for logged in and logged out users.

Under the hood, comments are now represented by a WP_Comment class and comment queries are now considerably more powerful.

Multisite Momentum

Like taxonomy and comments, the multisite features gains a new class, WP_Network. Additionally, there are now *_network_option functions which make it easier to use multiple networks. The linked post also highlights new hooks, some notable bug fixes, and two newly-deprecated functions. If you use WordPress in a multisite environment, this is a must-read.

Heading Hierarchy Happiness

Headings on the admin screens are now more semantic. Be sure to update your custom admin screens to follow the proper heading structure. These changes help users of assistive technologies, such as screen readers.

Twenty Sixteen

Each year, WordPress releases a new default theme and this year is no exception. Twenty Sixteen is a brand new theme, bundled with WordPress 4.4. Default themes are incredibly popular; be sure to test your plugins to ensure they function well with Twenty Sixteen.

Other Notes

So far, this release has had over two thousand commits. There are many additional changes not outlined above including: the removal of support for my-hacks.php(Update Nov 20th: My Hacks support was added back), giving add_rewrite_rule support for an easier-to-read syntax, support for single-{post_type}-{post_name} in the template hierarchy, pretty permalinks for unattached media, and stronger enforcement of the show_ui argument in custom post types. As with every major update, it is very important to test every feature in your plugins and themes to ensure there are no regressions in their behavior.


If you haven’t been testing your themes, plugins, and sites with WordPress 4.4, now is a great time to start. You can grab a copy from svn (or git), download the nightly builds, or install it using the Beta Tester Plugin.

WordPress 4.4 is not recommended for use on production servers until the final release has been announced on the WordPress News blog. The release is currently targeted for December 8, 2015. Get testing today!

#4-4, #dev-notes, #field-guide

Responsive Images in WordPress 4.4

WordPress 4.4 will add native responsive image support by including srcset and sizes attributes to the image markup it generates. For background on this feature, read the merge proposal.

How it works

WordPress automatically creates several sizes of each image uploaded to the media library. By including the available sizes of an image into a srcset attribute, browsers can now choose to download the most appropriate size and ignore the others—potentially saving bandwidth and speeding up page load times in the process.

To help browsers select the best image from the source set list, we also include a default sizes attribute that is equivalent to (max-width: {{image-width}}px) 100vw, {{image-width}}px. While this default will work out of the box for a majority of sites, themes should customize the default sizes attribute as needed using the wp_calculate_image_sizes filter.

Note that for compatibility with existing markup, neither srcset nor sizes are added or modified if they already exist in content HTML.

For a full overview of how srcset and sizes works, I suggest reading Responsive Images in Practice, by Eric Portis over at A List Apart.

New functions and hooks

To implement this feature, we’ve added the following new functions to WordPress:

  • wp_get_attachment_image_srcset() – Retrieves the value for an image attachment’s srcset attribute.
  • wp_calculate_image_srcset() – A helper function to calculate the image sources to include in a srcset attribute.
  • wp_get_attachment_image_sizes() – Creates a sizes attribute value for an image.
  • wp_calculate_image_sizes() – A helper function to create the sizes attribute for an image.
  • wp_make_content_images_responsive() – Filters img elements in post content to add srcset and sizes attributes. For more information about the use of a display filter, read this post.
  • wp_image_add_srcset_and_sizes() – Adds srcset and sizes attributes to an existing img element. Used by wp_make_content_images_responsive().

As a safeguard against adding very large images to srcset attributes, we’ve included a max_srcset_image_width filter, which allows themes to set a maximum image width for images include in source set lists. The default value is 1600px.

A new default image size

A new default intermediate size, medium_large, has been added to better take advantage of responsive image support. The new size is 768px wide by default, with no height limit, and can be used like any other size available in WordPress. As it is a standard size, it will only be generated when new images are uploaded or sizes are regenerated with third party plugins.

The medium_large size is not included in the UI when selecting an image to insert in posts, nor are we including UI to change the image size from the media settings page. However, developers can modify the width of this new size using the update_option() function, similar to any other default image size.

Customizing responsive image markup

To modify the default srcset and sizes attributes,  you should use the wp_calculate_image_srcset and wp_calculate_image_sizes filters, respectively.

Overriding the srcset or sizes attributes for images not embedded in post content (e.g. post thumbnails, galleries, etc.), can be accomplished using the wp_get_attachment_image_attributes filter, similar to how other image attributes are modified.

Additionally, you can create your own custom markup patterns by using wp_get_attachment_image_srcset() directly in your templates. Here is an example of how you could use this function to build an <img> element with a custom sizes attribute:

$img_src = wp_get_attachment_image_url( $attachment_id, 'medium' );
$img_srcset = wp_get_attachment_image_srcset( $attachment_id, 'medium' );
<img src="<?php echo esc_url( $img_src ); ?>"
     srcset="<?php echo esc_attr( $img_srcset ); ?>"
     sizes="(max-width: 50em) 87vw, 680px" alt="A rad wolf">

Final notes

Users of the RICG Responsive Images Plugin should upgrade to version 3.0.0 now in order to be compatible with the functionality that included in WordPress 4.4.

#4-4, #dev-notes, #media, #respimg

Headings hierarchy changes in the admin screens

For a number of years, the headings hierarchy in the admin screens have been setup without careful thought. WordPress 4.4 aims to fix this. This work is mainly focused on helping those users of assistive technologies such as screen readers, and is a continuation of the work started in 4.3 on restoring the H1 (heading level 1) to the admin screens.

If you’re a plugin or theme author and you’re providing custom admin screens for settings, etc., there are a few things you should check and update.

Why it matters

Headings provide document structure, which can directly aid keyboard navigation. Users of assistive technologies use headings as the predominant mechanism for finding page information. When heading levels are skipped, it’s more likely for these users to be confused or experience difficulty navigating pages.

Putting it simply, one of the first things screen reader users do in a web page to find relevant content is to press the 1 key on their keyboard to jump to the first <h1> heading and then they will try the key 2 to find the <h2> headings and so on. Thus, it’s extremely important for WordPress to provide a correct headings hierarchy, ensuring no headings levels are skipped.

How to fix your Plugin or Theme

Restructure the document headings hierarchy to ensure that heading levels are not skipped. The main heading should be a <h1> and any subsequent headings should (likely) be bumped one level up. There should be no skipped levels. Check your headings in the Admin, for example in settings pages, list tables, screen options, (dashboard) widgets, and meta boxes.

See for example the screenshot below, the first heading (Sharing Settings) should be a <h1> followed by a <h2> for Sharing Buttons.

main h1 heading example

Your plugin screens should start with a H1!

List Table headings

List tables (such as on wp-admin/edit.php ) have now additional headings added, though you won’t see them. These headings are hidden with the .screen-reader-text CSS class and are intended to allow users to jump to the relevant sections in these screens.

Note: For more in-depth information on using the core .screen-reader-text class, the Accessibility team has a great write-up on it.

The screenshot below illustrates the new headings in the Posts and Categories screens.

In the screen wp-admin/edit.php the heading structure is now:

  • H1: Posts
  • H2: Filter posts list (visually hidden)
  • H2: Posts list navigation (visually hidden)
  • H2: Posts list (visually hidden)

In the screen wp-admin/edit-tags.php?taxonomy=category the heading structure is now:

  • H1: Categories
  • H2: Categories list navigation (visually hidden)
  • H2: Categories list (visually hidden)
  • H2: Add new category
hidden headings for default posts and taxonomies lists

The hidden headings in the default posts and taxonomies lists.

If your plugin or theme provides custom post types or custom taxonomies, these new headings will use their default values “Post” and Category”:

hidden headings for custom posts and taxonomies lists

The hidden headings in the custom posts and taxonomies lists.

New post type and taxonomy labels in 4.4

In order to provide for better heading text, some new labels have been added for use with register_post_type() and register_taxonomy().

For register_post_type():

'filter_items_list'     => __( 'Filter your-cpt-name list', 'your-plugin-text-domain' ),
'items_list_navigation' => __( 'Your-cpt-name list navigation', 'your-plugin-text-domain' ),
'items_list'            => __( 'Your-cpt-name list', 'your-plugin-text-domain' ),

For register_taxonomy():

'items_list_navigation' => __( 'Your-tax-name list navigation', 'your-plugin-text-domain' ),
'items_list'            => __( 'Your-tax-name list', 'your-plugin-text-domain' ),

Here’s an example for a custom post type:

custom posts list with proper headings

Using the new labels to provide proper headings for a custom post.

Screen Options tab changes

Some plugins add custom options in the Screen Options tab. Previously, a h5 heading was used for the options “title”. In WordPress 4.4, the Screen Options tab has been revamped and together with other changes, it has been decided to remove the h5 heading which didn’t allow for a good headings hierarchy.

Each group of options is now within its own form fieldset and uses a legend element as “title”. You’re strongly encouraged to change the HTML you use for your plugin options and use the new markup.

the new Screen Options tab

The new Screen Options tab: each option is in a separate fieldset.

Dashboard widgets and meta boxes changes

All Dashboard widgets and meta boxes headings changed from an H3 to an H2.

<h2 class="hndle ui-sortable-handle">

If you are a theme or plugin developer: please check the heading structure in the content of your widgets and meta boxes, use an H3 and lower in the right order and context.

Get ahead of 4.4 and update now!

Now is a great time to update your plugins and themes! The power of the Web is in its universality. Help us to make the Web a place designed to work for all people. Any feedback and thoughts are more than welcome, please let us know in the comments below.

#4-4, #accessibility, #dev-notes, #example-flow, #user-anecdote, #visual-comparison

Multisite Focused Changes in 4.4

WordPress 4.4 has been a very productive release for multisite. In addition to some exciting new enhancements, we were able to resolve some long standing bugs. Check out the full list of multisite focused changes on Trac if you want even more wonderful reading material. 💖

Introduce WP_Network

The $current_site global has been maintaining a stdClass object representing an assumed description of a network since the original merge of WordPress MU with WordPress. With the introduction of WP_Network, we give a network a bit more definition and open up possibilities for working with a network (or networks) in a more sane way.

Take a look at ms-settings.php if you are using a custom sunrise.php to populate the $current_blog or $current_site globals. We now create a WP_Network object from the existing $current_site if it has been populated elsewhere. This is a backward compatible change, though should be tested wherever your code interacts with $current_site, especially if anything has been done to extend its structure.

See #31985 for more discussion while this was built.

Introduce *_network_option functions

During the introduction of WP_Network, we needed a way to populate network options (stored in wp_sitemeta) for a network other than the current.

add_network_option(), update_network_option(), get_network_option(), and delete_network_option() are all new functions in 4.4. Each takes the network ID as its first argument, matching the structure of the *_blog_option() functions.

*_site_option() functions remain as the proper way for working with a current network’s options. These now wrap the new *_network_option() functions and pass the current network’s $wpdb->site_id.

In a future release, likely 4.5, we can look at the introduction of network 0 as a way to store global options.

See #28290 for more discussion.

New actions and filters

  • before_signup_header fires before the signup header in wp-signup.php. #17630
  • ms_network_not_found fires when the $current_site global has not been filled and ms_not_installed() is about to fire. #31702
  • invite_user fires immediately after a user is invited to join a site, but before the notification is sent. #33008

Other enhancements of note:

  • WordPress has always enforced a /blog prefix for the main site’s permalink structure to avoid collisions with other sites in a subdirectory configuration. This was always changeable in the network admin, though the permalinks UI in the site admin never reflected the change and could cause confusion. Now, thanks to #12002, WordPress forgets that /blog was ever assigned if it is changed in the network admin to anything else. When changing this value, choose something that won’t conflict.
  • manage_network_users is now used to determine edit_users caps rather than is_super_admin. In preparation for 4.4, take a look at how you’re using the manage_network_users capability in your code to be sure access is set as intended. #16860
  • Network activated plugins are now visible as “network activated” in an individual site admin if the user can manage network plugins. These are not shown to site administrators. #20104
  • Recently active plugins are now displayed as such in the network admin. #20468
  • Language selection is now available when adding a new site through the network admin. 🌍 #33528
  • Language selection is also now available when signing up for a new site through wp-signup.php. 🌏 #33844
  • Network user searching has been improved by wrapping search terms in asterisk for looser matching. #32913

Bugs of note fixed:

  • It was previously impossible to set the upload limit for an individual site to 0 as it would then fallback to the default of 100MB. In 4.4, 0 is a respected number. #34037
  • When a site’s home, siteurl, or page_on_front option was updated in the network admin, rewrite rules were previously flushed incorrectly, causing rewrite rules for the main site on the network to take the place of the rewrite rules for the site being changed. #33816
  • Subdirectory sites created on an HTTPS network are now set to HTTPS rather than the incorrect HTTP. 🔒 #33620
  • A site’s title can now be longer than 50 characters! #33973

Deprecated functions:

Both get_admin_users_for_domain() #34122 and create_empty_blog() #34120 have never been used by WordPress core and are now deprecated. 🍻

#4-4, #dev-notes, #multisite

New Embeds Feature in WordPress 4.4

WordPress has been operating as an oEmbed consumer for quite some time now, allowing users to easily embed content from other sites. Starting with version 4.4, WordPress becomes an oEmbed provider as well, allowing any oEmbed consumer to embed posts from WordPress sites.

Here’s how that looks:

Feature Plugin Merge Proposal: oEmbed

In order to achieve this, WordPress’ oEmbed consumer code has been enhanced to work with any site that provides oEmbed data (as long as it matches some strict security rules). For security, embeds appear within a sandboxed iframe – the iframe content is a template that can be styled or replaced entirely by the theme on the provider site.

Related ticket: #32522

What That Means for Developers

First of all, this new feature means that any post (or basically any public post type) will now be embeddable. If you’re using pretty permalinks, the embeddable content will be available at

If you’re a developer, make sure you do not add an embed rewrite endpoint yourself!

Functions and Hooks

Here are the four most useful functions related to embeds:

  • get_post_embed_url() — Retrieves the URL to embed a specific post in an iframe, e.g.
  • get_post_embed_html() — Retrieves the full embed code for a specific post.
  • get_oembed_endpoint_url() — Retrieves the oEmbed endpoint URL for a given permalink, e.g.<url>. This is used to add the oEmbed discovery links to the HTML <head> for single posts.
  • get_oembed_response_data() — Retrieves the oEmbed response data for a given post, according to the oEmbed specification.

Of course the return values of these functions are all filterable, making it easy for you to customize this new feature.

Customizing The Output

The embed template mentioned earlier can be customized similarly to any theme template file. Use embed_head and embed_footer to add custom code in the beginning and the end of the template.

Note that an X-WP-embed:true header will be sent when that template is used, so you can easily target embedded posts in your application.

Further Improvements

We’re currently tweaking the embeds functionality to sort out the last few bugs. Here’s a short list of tickets that are being worked on and their purposes:

  • #34204 — Improved support for IE7+. This will also introduce a enqueue_embed_scripts hook that can be used to enqueue JavaScript and CSS.
  • #34451 — Improved support for embedding posts on non-WordPress sites
  • #34278 — Add support for embeds in the theme template hierarchy, allowing you to override the template easily in your theme.
  • #34207 — Leverage the REST API structure for the oEmbed endpoint.
  • #34462 — Add a <blockquote> fallback for the iframe.

Disabling The Feature

Don’t like these enhanced embeds in WordPress 4.4? You can easily disable the feature using the Disable Embeds plugin if you really want to.

#4-4, #dev-notes, #embeds, #feature-oembed

REST API: Welcome the Infrastructure to Core

Hi from the REST API team! We’re extremely excited to announce the API infrastructure has now been merged into core as of r34928 (plus a couple of fix up commits we won’t mention). Huzzah!

Sincere thanks to every single one of the contributors, we wouldn’t be where we are today without you. It takes time and effort to produce great things, and it’s impossible to make things great without everyone helping. This has been a truly collaborative effort, and I wish I could do more than just give you props.

(Important note: if you have a 2.0 beta already installed, you must upgrade to beta 5.)

What’s included in 4.4?

As mentioned in the merge proposal, the API comes in two parts: infrastructure and endpoints. In 4.4, the infrastructure is now available as part of core, while the endpoints continue to only be available in the plugin.

You can think of the infrastructure as an “API construction kit”. WordPress 4.4 will make it possible for everyone to build RESTful APIs in a much easier fashion, which will benefit people building custom APIs for their site. The infrastructure handles the routing, argument handling, JSON serialisation/deserialisation, status codes, and all that other lovely REST stuff.

For client authors, this doesn’t help you much right now. Hold tight, the team is working as fast as we can on the endpoints to get them ready for a future release. In the meantime, you can make sure sites you want to work with have the plugin installed, which isn’t a change from the current state.

For plugin and theme authors, you can start building new APIs immediately using the infrastructure now in core. This can start replacing your existing custom admin-ajax endpoints or other bespoke code you already have.

To authenticate with the API, only built-in cookie authentication is available out of the box right now. The OAuth 1 plugin will continue to work with WP 4.4 and the API plugin, as will the Basic Auth plugin for local development.

It’s super easy to get started, and there’s even a guide available to kick-off. (Note: the WP_REST_Controller class is not included in WordPress 4.4.) This documentation will be migrated across to soon.

If you want to access any of the built-in data in WordPress without building it out yourself, you’ll need the endpoints as well. These will continue to be packaged in plugin form, and version 2.0 final will be released to accompany 4.4 before the end of this cycle.

What if I’m using the API already?

If you’re on version 2 of the API, you’ll need to update the API to beta 5 or later before updating to the latest version of core. This new version will use the new infrastructure in core if available, or fallback to a compatibility library otherwise.

Important note: Earlier 2.0 betas (1 through 4) are incompatible with WP 4.4. Your site will fatal error if you don’t upgrade to beta 5 or later. You must upgrade to the latest API to run trunk and to run WP 4.4 when it’s released.

If you’re on version 1 of the API, you won’t hit any fatal errors straight away, but endpoints will stop working with 4.4. We’re still planning on releasing a final version 1 release for compatibility, but now would be a great time to consider migrating forward to version 2. Apart from security releases, version 1 has ceased being actively maintained.

Looking forward for the API

Now that the API is past this first hurdle, it’s important to keep looking forward. Our immediate next step is to improve and polish the endpoints for phase two of our merge. There’s a lot of work still to be done here, so we’d love you to join us on GitHub.

The infrastructure of the API will now be maintained via Trac, so new issues and patches should be sent there instead under the “REST API” component. Issues with endpoints should still be filed on GitHub. Don’t worry if you’re not sure; you can file issues on either Trac or GitHub, and they’ll be triaged into the correct place as needed. (It’s more important to make sure the issue is filed in the first place!)

The team wants to keep pressing forward with the API and keep up our rate of progress, if not improve it even further, and we’d love your help. We still need help from content writers on our documentation, designers and developers on our authentication plugins, and developers on the endpoints. If you want to help, we can always use a hand, and we’d love to help get you started. We’re available in the #core-restapi room on Slack, and we’d love to see you at the weekly meeting at Monday 23:00 UTC 2015.

We look forward to continuing to work on the API and getting these endpoints happening. Thanks again to everyone who got us here.

(Then again, maybe a REST API is more of a Shelbyville idea…)

#4-4, #dev-notes, #json-api, #rest-api

Comment Object and Query Features in 4.4

Without comments, a website is as effective at creating a community as the Chicago Cubs are at winning World Series titles. WordPress 4.4 is a rebuilding release and the comments system is much improved under the hood.

This release lays the groundwork for future features and improvements.

A New Classy and Strong Comment Object

The new WP_Comment class provides a single organized comment object that models its row in $wpdb->comments. You may be familiar with this approach from WP_Post, which inspired the caching implementation used in WP_Comment.

This was a prerequisite to many of the other comment-related bug fixes and features added in 4.4. The WP_Comment class is marked final to retain flexibility while it is young.

See #32619.

Comment Queries for the Whole Family

WP_Comment_Query has new query parameters for traversing your comments family tree.

  • parent__in takes an array of comment parent IDs to return all matching children.
  • parent__not_in takes an array of comment parent IDs and does not return any matching children.
  • hierarchical can be set to either threaded, flat, or false.
    • threaded returns a tree for matched comments, with the children for each comment included in its children property.
    • flat returns a flat array of matched comments plus their children.
    • false does not include descendants for matched comments. This is the default behavior.
  • orderby has a new option comment__in, useful when querying by comment__in the matched results will return in the same order.

See #8071 and #33882.

#4-4, #comments, #dev-notes

Under the hood of Twenty Sixteen

Twenty Sixteen is the new default theme for WordPress 4.4. This year the process has been done differently, with an exciting exploration of how default themes are created. The theme has been developed on GitHub and you can follow along here. The theme has also been synced every night with the theme repository. This has meant more people have been able to use them theme earlier than previous default themes.

As Beta 1 is now out, it’s a great time to explore a little more about what Twenty Sixteen contains and how the contributions have shaped this default theme so far.

Features of Twenty Sixteen

This theme is designed to be a fresh take on the traditional blogging format. It includes:

  • Multiple menu positions and a social menu.
  • Optional sidebar.
  • Custom color options and beautiful default color schemes.
  • Harmonious fluid grid using mobile-first approach.
  • Custom background and header.
  • Overflow displaying large images.
  • Ability to add intro to post using custom excerpt.

Contributions to Twenty Sixteen

During development, there have been some amazing contributions along the way. These include:

  • Lots of accessibility improvements. The Accessibility team have done amazing work reviewing and ensuring Twenty Sixteen is better than any other default theme for accessibility.
  • Improved js handling and tidying in files. Thanks to contributions, the theme js and that of other default themes has been reviewed and optimised.
  • Numerous design enhancements including sub menus.
  • Travis testing integrated with the repo.
  • Device and browser testing. Everyone really helped put this theme through it’s paces.
  • The addition of singular.php.
  • Responsive image support (on the way).
  • Prefixing cleaning up to focus on browsers using.
  • Sanitisation and escaping.
  • Adding of core comments navigation.
  • Hyphenated post titles for better language support.
  • Numerous bug fixes, code tidying and countless tiny improvements.

A big thank you to everyone that has helped make Twenty Sixteen the theme it is. It’s been incredible to see everyone so engaged and active over on GitHub.

With Twenty Sixteen on GitHub, if you have a bug you’d like to report you can do so using GitHub right here.

#4-4, #dev-notes

4.4 Taxonomy Roundup

We’ve made lots of improvements to the Taxonomy component for WordPress 4.4. Let’s round ’em up, pardner!🐴

Term Meta

The most significant improvement is the introduction of term meta #10142. Use the new term meta API – add_term_meta(), update_term_meta(), delete_term_meta(), and get_term_meta() – to store arbitrary data about taxonomy terms, in the same way you would for posts, users, or comments. The term query functions get_terms() and wp_get_object_terms() now support a ‘meta_query’ parameter, with syntax identical to the corresponding argument for WP_Query, etc.

Term meta was built with performance in mind. When fetching terms using get_terms() or wp_get_object_terms(), metadata for located terms is loaded into the cache with a single database query; disable this by passing 'update_term_meta_cache' => false in your query parameters. When querying for posts using WP_Query, we have another trick up our sleeves: term meta for terms belonging to matched posts is lazy-loaded, so that all relevant term meta is only fetched the first time you call get_term_meta() in the loop.

Developers who have previously implemented term meta in their own plugins or client sites should prepare their customizations for WordPress 4.4, to ensure that nothing’s broken in the transition.

WP_Term and unique term IDs

For the last few releases, we’ve been working hard on the taxonomy roadmap. A major achievement was the complete splitting of shared taxonomy terms in 4.3, which ensures that terms can be uniquely identified by their term_id. In 4.4, we begin taking advantage of this uniqueness: the $taxonomy parameter is now optional in get_term() and get_term_field(), functions that previously required both $term_id and $taxonomy.

Under the hood, we’ve introduced WP_Term, a new class that properly models a term object #14162. Everywhere where terms can be retrieved – one at a time, as in get_term() or get_term_by(), or in bulk, as in get_terms() and wp_get_object_terms()– you should expect WP_Term objects to be returned, rather than stdClass. For 4.4, this change doesn’t affect much, aside from making our term-caching internals somewhat more sane. But in the future, WP_Term will allow for more extensive caching throughout the Taxonomy component, as well as the potential for method chaining and other developer conveniences.

Other goodies

We’ve made lots of smaller improvements to Taxonomy as well. Some highlights:

  • Registering a taxonomy with 'public => false' now prevents the taxonomy from being queried publicly. (Imagine that!) #21949
  • The $taxonomy parameter for get_term_by() is optional (and ignored) when fetching by term_taxonomy_id. #30620
  • Argument arrays are now filtered in get_terms(), register_taxonomy(), and in the Categories post edit metabox. #33026 #33369
  • Accented characters in term names are no longer ignored when checking for duplicates, allowing for, eg, tags ‘foo’ and ‘fóó’ to coexist. #33864
  • Term relationships caches are properly busted during wp_remove_object_terms(). #34338

#4-4, #dev-notes, #taxonomy