WC 401: New APIs in WordPress 3.5

WordCamp Phoenix 2013

About Me

• Design Engineer at Automattic, the company behind WordPress.com
• Formerly a Senior WordPress Developer with Oomph, Inc. working on the WordPress.com VIP platform
• 3+ years developing WordPress themes and plugins
• WordPress Core Contributor
• WordCamp Boston Organizer
• Plugin Author

Moar APIs?!?!

But of course!

As WordPress evolves, many of its older APIs need refining.

It's like renovating a house or taking your car in for maintenance.

What New APIs?

• WP_Post (#21309)
• WP_Image_Editor (#6821)

WP_Post: What Prompted It?

A ticket from February 2010 opened by Andy Skelton.

TL;DR

WP delivers posts in an object, but the object has no methods.

As Andy said,

[$post] is only a syntactic alternative to the array.

WP_Post: What made it into 3.5?

Basically, a framework for the future.

Quoting Ryan Boren:

Just do what we did with WP_User. Add some magic methods so we can load things like ancestors on demand and get better cache behavior. Make sure everything is back compat. Do more some other time.

WP_Post: What Changed?

To most users, nothing……yet.

WP_Post: What Changed?

• $post is now an object of type WP_Post, rather than stdClass.
• Each instance of $post now includes helper methods to retrieve data not present in the object previously.

Don't worry though, each instance of $post still has the same properties it did in 3.4.

WP_Post and metadata

Before:

<?php
global $post;

$meta = get_post_meta( $post->ID, 'my_key', true );
?>

After:

<?php
global $post;

$meta = $post->my_key;
?>

WP_Post: More properties

• ancestors: uses get_post_ancestors()
• page_template: same value as the _wp_page_template meta key
• post_category: array of category IDs*
• tags_input: array of post tag IDs*

* matches the data format from wp_get_single_post(), which was deprecated in favor of get_post().

Cautions

• Obviously, won't work pre-3.5.
• Anything strictly checking the object type will fail.

The latter bit us on WordPress.com, because one layer of our caching system didn't properly handle the new object type.

Final Thoughts on WP_Post

Keep in mind that this is an evolving API.

While these changes may seem trivial, they prepare WordPress for things to come.

Questions?

WP_Image_Editor: What Prompted It?

A five-year-old ticket created by Matt. (#6821)

Timely, eh?

Just shows that even being the project's cofounder doesn't mean your wants are promptly addressed.

WP_Image_Editor: What Changed?

To the end-user—someone who only interacts with WordPress via the Dashboard—nothing.

More than anything, this was truly a developer's change.

WP_Image_Editor: What Changed?

WordPress is no longer wed to GD for image manipulation.

WP_Image_Editor: What Changed?

All image manipulation functions were abstracted in such a way that other image manipulation libraries can supplant GD.

As a result, WP now includes support for both GD and ImageMagick.

WP_Image_Editor: But How?

• A base class defines methods used within WordPress, such as resize, crop, and rotate.
• Image manipulation libraries are defined, and tests are included so WordPress can determine if the library is available.
• Based on a specific request, WordPress chooses the first editor capable of handling the request.
• WordPress allows additional handlers to be specified, and the preferred order of handlers to be changed.

WP_Image_Editor: But Why?

This is lovely and all, but what's the point?

GD is rather ubiquitous, but other libraries exist that generate better-quality images, are more performant, or have functionality not available in GD.

WP_Image_Editor: Practical Application

For example, want to use Gmagick?

There's a plugin for that: http://wordpress.org/extend/plugins/gmagick/.

The plugin is written by Marko Heijnen and Mike Schroder, the guys who were primarily responsible for the WP_Image_Editor API.

Let's look at some code

Questions?