WordPress.org

Make WordPress Core

Changes between Initial Version and Version 1 of Ticket #12955, comment 67


Ignore:
Timestamp:
03/26/2018 03:15:39 AM (4 years ago)
Author:
MikeSchinkel
Comment:

Legend:

Unmodified
Added
Removed
Modified
  • Ticket #12955, comment 67

    initial v1  
    66While I would be ecstatic to see this ticket moved forward. changing the object class would be 3 steps forward and then 2 steps back. It would create broken code if any classes are used statefully, e.g. if you assign value to properties and expect those values to be retained later in the code. It could result in a lot of memory thrashing; creating new objects based on existing objects every time a template tag used `get_post()` to sanitize a post.  AND, it is not compossible; what if two different plugins want to change the post type to their own post custom type? Only one plugin would get to win.
    77
    8 '''As I think about it maybe the answer to this use-case need is not to filter get_post and not to remove `final` but instead''' to extend `WP_Post` with magic methods and filters.  Add `__call()` `__set()` and Add filters that can affect both those as well as `__get()`.  Add an action hook in `__construct()` and add a property array `supports` that allows plugins to attach support (by array key) to posts and their own instances to implement the support.
     8'''As I think about it maybe the answer to this use-case need is not to filter `get_post()` and not to remove `final` but instead''' to extend `WP_Post` with magic methods and filters.  Add `__call()` `__set()` and Add filters that can affect both those as well as `__get()`.  Add an action hook in `__construct()` and add a property array `supports` that allows plugins to attach support (by array key) to posts and their own instances to implement the support.
    99
    1010This would be much more compossible across plugins and would still allow plugins to ''"decorate"'' posts with properties and behaviors.