[wp-trac] [WordPress Trac] #12955: Add get_post filter

[WordPress Trac]

#12955: Add get_post filter
------------------------------------+-----------------------------
 Reporter:  JohnLamansky            |       Owner:
     Type:  feature request         |      Status:  new
 Priority:  normal                  |   Milestone:  Future Release
Component:  Posts, Post Types       |     Version:
 Severity:  normal                  |  Resolution:
 Keywords:  has-patch dev-feedback  |     Focuses:
------------------------------------+-----------------------------

Comment (by MikeSchinkel):

 Replying to [comment:51 flixos90]:

 > ''That's what I meant with it should only happen in a custom setup where
 you have full control over the theme. To be clear, I agree with what
 you're saying, but I wanted to highlight that only custom projects where
 you have full control would benefit from this.''

 I agree with that completely.

 But you are still missing the most common use-case; plugins.  Custom sites
 often use plugins that themselves use `get_post()`.

 I will give you a real world example that happened to us.   We built a
 site in combination with a design-focused WordPress shop and then when we
 were close to project completion they had discussed something with the
 client and they had recommended Beaver Builder.  Well is turns out Beaver
 Builder was broken when we wrapped `WP_Post` because it used `get_post()`
 and thus sanitized our wrapper class into oblivion.

 Is it not unreasonable to expect that a custom site would want to use
 commercial or open-source plugins, and it is highly likely they will use
 `get_post()` internally and destroy the wrapped class objects we use.

 > ''In my case I do not override the global at all, I have my own
 container class for the wrappers so that there are no conflicts with the
 `$post` global, and that is the workaround I was referring to.''

 We currently do the same.  Because we cannot override the `$post` global
 without the problems I am discussing. And thus we cannot use template tags
 nor plugins that expect template tags.

 > ''This is also the only way the code can remain proof of conflicts with
 other plugins. When you put a wrapper class like the example you posted in
 the `$post` global, for example something like `get_object_vars( $post )`
 would fail as magic properties are used.''

 Yes you are correct that my example would fail with `get_object_vars(
 $post )`.  I was quickly trying to illustrate how template tags would
 fail, not actually show the class that we'd have to use.  Here is an
 (untested) class that is closer to what would actually be needed in a
 custom application:

 {{{#!php
 <?php
 class My_WP_Post {
         public $ID;
         public $post_author = 0;
         public $post_date = '0000-00-00 00:00:00';
         public $post_date_gmt = '0000-00-00 00:00:00';
         public $post_content = '';
         public $post_title = '';
         public $post_excerpt = '';
         public $post_status = 'publish';
         public $comment_status = 'open';
         public $ping_status = 'open';
         public $post_password = '';
         public $post_name = '';
         public $to_ping = '';
         public $pinged = '';
         public $post_modified = '0000-00-00 00:00:00';
         public $post_modified_gmt = '0000-00-00 00:00:00';
         public $post_content_filtered = '';
         public $post_parent = 0;
         public $guid = '';
         public $menu_order = 0;
         public $post_type = 'post';
         public $post_mime_type = '';
         public $comment_count = 0;
         public $filter;
         public function __construct( $post ) {
                 $this->_set_state( get_object_vars( $post ) );
         }
         function __call( $method, $args ) {
                 $post = new WP_Post( $this );
                 $return = call_user_func_array( array( $post, $method ),
 $args );
                 $this->_set_state( get_object_vars( $post ) );
                 return $return;
         }
         private function _set_state( $post ) {
                 foreach( $post as $var => $value ) {
                         $this->$var = $value;
                 }
         }
         public static function get_instance( $post_id ) {
                 $post = new WP_Post( get_post( $post_id ) );
                 $instance = new static( $post );
                 return $instance;
         }
         public function __isset( $key ) {
                 $post = new WP_Post( $this );
                 return $post->__isset( $key );
         }
         public function __get( $key ) {
                 $post = new WP_Post( $this );
                 return $post->__get( $key );
         }
         public function filter( $filter ) {
                 $post = new WP_Post( $this );
                 return $post->filter( $filter );
         }
         public function to_array() {
                 $post = new WP_Post( $this );
                 return $post->to_array();
         }
 }

 class Custom_Wrapper extends My_WP_Post {
         function custom_value() {
                 return 'It worked!';
         }
 }

 }}}

 BTW, have I mentioned how much I hate that PHP in edge cases?  But I
 digress...

 > ''In short, I still think this filter is worth exploring, but we should
 be careful on how to approach this in terms of compatibility issues, and
 I'm sure that is the reason it has not happened yet.''

 Frankly it would solve the need if any final class like the `WP_Post`
 class could be made to be pluggable.  I know pluggable functions are an
 anti-pattern in WordPress but this seems like an appropriate use-case. So
 really I mean a new concept, let's call that ''replaceable'' functions.

 Replaceable functions could load from a `/wp-content/replaceable/`
 directory in `wp-settings` as soon as `WP_CONTENT_DIR` is available, and
 any `final` classes could be replaceable. This would allow people creating
 custom sites to replace classes and allow them to be extended.

 OR better yet, let's just [/ticket/24672 get rid of `final` on `WP_Post`].

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