WordPress 4.4, “Clifford”, released

WordPress 4.4, “Clifford”, has just been released, right on the heels of WordCamp US — the largest WordPress conference ever. The release was led by Scott Taylor, and an astounding 466 people contributed to WordPress 4.4 — which is a record by a long shot.

“Clifford” is named after Jazz trumpeter Clifford Brown. Check out his Wikipedia for more information about him.

You can view all closed tickets for WordPress 4.4, and view an evolving overview of changes on the 4.4 Codex page as well.

Here’s a video overview of WordPress 4.4:

WordPress 4.4 includes a variety of user facing and developer features, and I consider it to be one of the most important releases for developers, and the way WordPress can be extended, in years.

Let’s go over some of the most notable features in 4.4:

WordPress REST API infrastructure

The WordPress REST API is going into WordPress core in multiple parts, starting with the infrastructure in 4.4. The endpoints will go in, “in a future release,” likely starting with endpoints for some core object types in 4.5, but full coverage may span multiple releases.

The REST API has been widely covered, and was a focus area of the WordCamp US conference, but it is also a rapidly evolving part of WordPress. Decisions going into the REST API now will affect WordPress as a whole for many years.

There are many reasons the API is going in infrastructure first, but one important reason is that the code going into core for 4.4 is quite isolated from the endpoints that are not going in yet. The infrastructure provides a lot of helpers for plugins to extend for supporting custom endpoints, while giving the REST API and core team more time to evolve the endpoints and work out a variety of remaining challenges.

For people using the WordPress REST API feature plugin (version 2 or later), you’ll still want to have the plugin installed after updating to 4.4, as the plugin will continue to provide the endpoints that are already developed.

The REST API infrastructure going into core is also a statement of core team endorsement, which the API needed after years of development, so that developers would be comfortable basing large projects on it, with the understanding that it would be supported for a long time.

Amongst the challenges that remain for the REST API project is creating parity with the WordPress.com REST API. The WordPress.com REST API has been separately developed from the core REST API, but a number of important applications use the WordPress.com version, and both the core REST API team and key members at WordPress.com parent company Automattic believe it is in the best interest of both APIs for them to be interchangeable.

Both APIs have made decisions that would require some sort of bridge or support-breaking versioning in order to get on the same page. Automattic has made resources available to work with the core team over coming months to help ensure that the two play nicely together.

The REST API infrastructure hitting core is a huge milestone that will take WordPress to the next level. It’s more possible than ever for WordPress to be used as an application platform. It also means we will see more examples of websites using parts of WordPress and decoupling from other parts.

The REST API is the work of dozens, but an enormous amount of credit is due to four people that have pushed this cart up the big hill of core inclusion: Ryan McCue and Rachel Baker have lead the project, and Joe Hoyle and Daniel Bachhuber have been hugely influential in code and architectural decisions.

Interested in learning more about the WordPress REST API? Here are some links to help:

• WordPress REST API website and documentation
• Official WordPress REST API plugin (still important for users needing endpoints)
• WordPress REST API Github (includes helper clients and libraries, plus all versions of code)
• Introduction to the REST API (basics, pre v2 information)
• All about the REST API (recent, deep dive podcast)
• A Future API (theoretical future world where the REST API is in use)
• State of the Word, 2015 (REST API played a starring role)

Congratulations to everyone involved on making this important step to WordPress’s future.

Responsive Images

Another hugely important feature for WordPress 4.4 is the inclusion of the Responsive Images Community Group’s feature plugin, which is based on a specification now broadly supported in modern browsers.

Project lead Joe McGill outlined how responsive images work, from a technical perspective, in a recent Make Core post. Essentially, WordPress now has support for dynamically replacing images for small viewports and for retina screens. The functionality operates on an underlying WordPress function that enables responsive images on new posts and old, both in the content and within most functions themes use to display images.

You may wonder what images will be made available. At its core, the plugin puts all images that are the same aspect ratio as the requested image in the srcset. So if you insert a full size image and it is 1500×1500 and your large image size is 1024×1024 (the WordPress default), it would replace the full size with the large size for smaller viewports, because it is both smaller and it is the same aspect ratio.

If an image isn’t the same aspect ratio, it wouldn’t be used; so it prevents, for example, an intended landscape image from being replaced by a vertically cropped image on a smaller screen. Because WordPress default images skip from 300px to 1024px, a new image size has been introduced to increase the likelihood one is available for use in the srcset. Any custom image sizes will be available as well.

With this functionality, most images on every WordPress website in the world will be responsive-ready as soon as the sites are updated to WordPress 4.4. It’s a massive win for WordPress, as well as the broader web community.

Term meta and taxonomy improvements

WordPress 4.4 includes a long requested feature for terms with the introduction of term meta support. Term meta works much like post meta, and makes several new functions available: add_term_meta(), update_term_meta(), delete_term_meta(), and get_term_meta().

Folks have used custom term meta for ages, but with core support, there’s now a standard way to enable developers to store arbitrary data to terms. Just like post meta, term meta can be abused, but when used smartly, it will increase the possibilities for complex websites that have complex post and term relationships. I also anticipate we’ll see helpers and user interfaces show up that make the process for registering meta fields and various form field types a simple process.

In addition to term meta, 4.4 also introduces WP_Term. Developers won’t notice a big difference now, but as project lead Boone Gorges put it in the overview post, “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.”

oEmbed for WordPress posts

WordPress posts can now be embedded anywhere, with the new core WordPress supported oEmbed feature. Lead by new committer Pascal Birchler as a feature as plugin, oEmbed makes sharing a WordPress post as easy as putting the URL on its own line, just as if you were sharing a Tweet or other oEmbed provider piece of content.

Twenty Sixteen

Twenty Sixteen marks the seventh Twenty-series default WordPress theme. Twenty Sixteen is another minimalist WordPress theme with a focus on blogging. Its two most visible features are the negative margin large images in the content, and the support for nearly any color background.

I think Twenty Sixteen is nice, but it isn’t groundbreaking theme territory. That may well change with Twenty Seventeen, which I imagine will have a larger JavaScript influence, but Twenty Sixteen is still a nice iteration on the WordPress default theme.

Designed by Takashi Irie, you can find more about Twenty Sixteen on a Make Core internals post, its official WordPress.org theme page, view the demo, or see the development history on Github.

WP_Comment and comments overhaul

Comments were a bit of a mess in WordPress. Release lead Scott Taylor took this component under his wing for 4.4, and along with Rachel Baker (the component lead), revamped a lot of comment internals.

Scott talked more about digging into WordPress comments in this week’s Post Status Draft podcast (posting soon).

More Multisite goodies

Just as I’ve said in 4.3, and previous releases, it makes me happy to repeat that Multisite continues to see active development.

As Jeremy Felt outlines, WordPress 4.4 includes new support for WP_Network (that makes three new objects in 4.4 for those keeping count at home) as well as new network functions, actions, and filters.

Another great WordPress release

WordPress 4.4 is an outstanding release, and Release Lead Scott Taylor deserves a ton of credit for steering the ship. This release saw more overall commit activity than WordPress has seen in a single release in years.

In addition to a lot of code improvements, many community members made incredible efforts to consistently garden Trac, where WordPress core development happens, and ensure that all tickets received at least some level of attention during the release phase of 4.4.

Congratulations to everyone that received props, wrote docs, advocated for, or otherwise contributed to WordPress 4.4. It’s a great way to end the year for WordPress, and sets a path for a very exciting 2016 for the WordPress project.