The WordPress 4.4 train is rolling and rolling fast still. oEmbed, Responsive Images, and the REST API infrastructure have all been committed to core.
The links for the merge tickets are as follows:
Twenty Sixteen, which has thus far used Github for development, will also be merged into trunk soon. Twenty Sixteen has gotten feature plugin treatment during the dev cycle, hence my noting it as well.
Iāve covered each of these features a number of times in Notes and on the podcast, so I donāt want to run through every aspect of them all now, but there are some things about each featureĀ Iām thinking about given that they areĀ now in:
Responsive Images
Responsive Images adds a number of handy functions to help make it all work. Those may be usefulĀ for you beyond just getting responsive image support. It’s still up in the air as to what new image sizes will be added to go with this feature, but it looks like perhaps one that mirrors $content_width as defined in a theme and — maybe in the future — @2x versions of each image size.
That would mean storing a lot of extra images, but it would really make for more full featured support of retina devices, and generally supply more images that could fill in for various viewports. It would also help fill the large gap between current default medium and large sizes.
Theme authors will have a big role to play in making their themes play nicely with responsive images, with regard to how they define custom image sizes. It gives a big reason to support fewer aspect ratios for custom defined images, for one. For instance, if you have a 2000×800 size for big featured images, you might want to use 600×240 for a smaller featured image size instead of some other arbitrary aspect ratio.
You could also make a good case for fewer hard cropped image sizes, but rather sizes simply determined by width or height.
With add_image_size(), you don’t have to define every parameter, nor does it have to be set to hard crop. So a “soft crop” definition could look like add_image_size( 'other-new-size', 600 ) and add_image_size( 'big-new-size', 2000 ) and both would have relative aspect ratios, with set widths. Then in the srcset provided for responsive images, you’re guaranteed that both those sizes are available for use. WP Shout does a nice job explaining image sizes and the considerations.
I’d like to see this better explored for core supported sizes too, especially medium and large, as I’ve only really ever seen usage of them restricted by the width, not width and height.
The larger point here is that it will make for more responsible themes if they can create consistency between custom image sizes, because more images become available for the srcset.
REST API infrastructure
The infrastructure component to the REST API is a big milestone, for sure. But if you’re really using the REST API, you’ll still just want to install the plugin so you can take advantage of the endpoints that aren’t yet in core.
Including the infrastructure allows for more testing and work to go into endpoints, and gives other API developers a good base for their work, but if you want to use the REST API as defined in v2, you’ll still need endpoints.
More than anything, in my opinion, the infrastructure landing in core is a stamp of approval on the REST API as a whole, and guarantees more eyes on both the current code and the code slated for the next release. WhileĀ celebration is good now, the real celebration will be with the endpoints, and knowing that a quarter of the internet will truly have something amazing available, in full.
oEmbed
oEmbed is an interesting feature. I honestly am unsure how much this will be used by end users. But it is most useful if the expectation is that it is available. I like comparing it to Twitter’s oEmbed.
I can embed a tweet and I expect it to be an oEmbed out of the gate. But that’s not always the case. Users that are private on Twitter (so you have to request to follow) don’t support embedded tweets. But the general expectation is that when you embed a tweet URL, it works. The same needs to be true for WordPress oEmbed.
And that’s why the opt-out, or “off button”, shouldn’t be a user-driven option. It should be possible with a plugin or filter, but the expectation should be that embeds are safe and available. And the core team has hashed that conversation out well, and indeed it seems the way it’s going.
Twenty Sixteen
I have tested Twenty Sixteen myself, and it’s a nice theme. It’s not exactly ground breaking, but it will serve as a worthyĀ default theme. I also find it to be best when certain publishing consistenciesĀ are followed.
For instance, it looks a little weird to me with short titles and no featured images, because of the way the offset on the content works with the meta information on the left. Some other design opinions, like the massive border around the whole page, bug me, but designs have to have opinions so I can get over it.
I do like most of the customizer implementation: like the way the borders reflect the main text color, and the built in color schemes.Ā But it would be cool to save your custom color schemes somehow. Might make for a nice plugin by somebody. I’d also prefer if title text and content text were different customizer color options.
I really want to see something more drastic with Twenty Seventeen, but I don’t want that statement to take away from Twenty Sixteen; it’s a fine theme. Test it if you haven’t. Unfortunately there’s still not a demo that really stretches the theme and shows all that it does. Soon, hopefully.
These are just the features as plugins…
There are a lot of other achievements in WordPress 4.4: comments are rewritten, term meta (!!!), multisite work, customizer work, attachments work, HTTP/2, and more. I have to have something to write about in the actual release post though!
