[wp-trac] [WordPress Trac] #24672: Remove final from WP_Post class

[WordPress Trac]

#24672: Remove final from WP_Post class
-------------------------------+------------------------------
 Reporter:  carlalexander      |       Owner:
     Type:  enhancement        |      Status:  reopened
 Priority:  normal             |   Milestone:  Awaiting Review
Component:  Posts, Post Types  |     Version:  3.5
 Severity:  normal             |  Resolution:
 Keywords:  2nd-opinion        |     Focuses:
-------------------------------+------------------------------

Comment (by hawaiipersson):

 I've noticed that the reluctancy to this change may have a lot to do with
 avoiding a situation where changes to WP_Post might break backwards
 compatibility for any plugins using this feature.

 As much as I understand that I do believe (as a plugin developer) that the
 downsides are greater. On larger sites a Wordpress upgrade will always be
 subject to extensive testing to make sure nothing breaks. Also it seems
 impossible to make any kind of changes with the constant fear of breaking
 backwards compatibility. It happens, and it's up to the plugin / theme
 developers to keep up.

 In any case, "automatic" upgrades of the Wordpress core should prevent the
 upgrade if any of the installed plugins are not compatible with the new
 version (but I guess that's a different issue).

 Why would you want to extend \WP_Post?

 I've got to different, real life, examples:

 First we use Wordpress admin gui as a system for creating and maintaining
 content that is sent to a different app for storage and rendering. The
 object sent to the external app consists of both core WP_Post properties,
 as well as a lot of meta data associated with the post. If I could extend
 WP_Post I would be able to collect all data for the object in a neater
 way.

 Second - we are experimenting with using different rendering engines to
 actually render the front end (personally I like Twig, and strongly feel
 that WP must move in a direction where business logic and design in not
 mangeled together). When using Twig all data must be collected (and
 filtered) first, before the rendering process starts. It would help a lot
 if all data needed to render a specific post could be included in one
 single object. As of now the separation makes the data structure very
 unintuitive for our frontend devs.

 There are of course solutions to both problems above. But development is
 not only about making this work, but to also make it beautiful and
 maintainable. In my opinion, making \WP_Post final prevents that.

--
Ticket URL: <https://core.trac.wordpress.org/ticket/24672#comment:19>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform