Your browser doesn't support the features required by impress.js, so you are presented with a simplified version of this presentation.

For the best experience please use the latest Chrome, Safari or Firefox browser.

Use a spacebar or arrow keys to navigate

WC 401: New APIs in WordPress 3.5

WordCamp Phoenix 2013

Erick Hitter

Design Engineer @ Automattic


About Me

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: What Prompted It?


A ticket from February 2010 opened by Andy Skelton.



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?



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

WP_Post and metadata



global $post;

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



global $post;

$meta = $post->my_key;

WP_Post: More properties



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



The latter bit us on, 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.


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?


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:


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