Extending the WP_Post class

OK, so it’s technically impossible to extend WP_Post.  Big deal.

Still, I’m thinking a lot about how I might go about extending WP_Post for my own purposes; and I’m experimenting with classes that “kind of” extend WP_Post, because the class is not going to be final forever.

In a Trac ticket from 2013,  we have the following quote that establishes that WP_Post is scheduled to have the final keyword removed at some point (strikethrough and links added by me):

I think we are waiting for WP_Post to be joined by a WP_Comment and WP_Term, and then for all four classes (along with WP_User) to actually be decorated with methods.

– Andrew Nacin on Trac

It looks like WP_User is pretty well decorated with methods, but the others – not so much.  I can’t find any indication as to when the final keyword is supposed to be removed from WP_Post, but it’s something I’m looking forward to.

I wondered for a while whether it even made sense for me to think about extending WP_Post, but the above quote confirms (for me anyways) that it’s something worth putting thought into.

I have a plugin called Helping Friendly Plugin, which is my generalized template plugin that I use as a starting point for most of my plugins.  In addition to being a template, it is also geared toward helping others learn about plugin development and contains resource links about the different API’s that WordPress has to work with.

As part of the plugin, I have created an “extension” of WP_Post (called  Helping_Friendly_Post) which is itself extensible.

Essentially, I am storing a WP_Post object into a class parameter and bolting on custom fields for the extended object.  I have some methods for getting the extended objects by post ID or by an existing WP_Post object, as well as some easily hook-able wrapper methods for WP_Query.

Here are some examples of basic usage for the class.

For getting multiple posts, I have a strict wrapper for WP_Query that accepts the same argument format, as well as a method for getting extended posts by field value.

My idea is to extend the class, possibly multiple times to account for the different post types that I might be creating for some install, and to create custom methods as needed for each post type.

Theoretically, I could use the object on any WP install in the future by copying the file from within the plugin, renaming the class, and putting it in my child theme or in another plugin.

According to Nacin, the reason for the wait on officially extending WP_Post is backward compatibility.

Removing that final makes it a free-for-all that will make it painful if not nearly impossible to make changes that don’t break plugins. Very simply, final is the only thing that lets us turn this into a real API while not worrying about back compat.

I interpret that to mean that the core team doesn’t want to commit to the object (and its related objects) in its current form because they want to be able to change bits of the code base without being locked into something that’s incomplete.

As things in core change, I suppose this means I have to assume that any objects I create like the Helping_Friendly_Post object will most likely need to be re-worked from time to time.

I wonder who else out there is thinking about what an extended WP_Post object could possibly look like. I’m sure I’m not the only one!