[wp-trac] [WordPress Trac] #36492: Add `WP_Post_Status` class

WordPress Trac noreply at wordpress.org
Thu Apr 28 08:07:59 UTC 2016


#36492: Add `WP_Post_Status` class
------------------------------------+------------------------------
 Reporter:  flixos90                |       Owner:  DrewAPicture
     Type:  enhancement             |      Status:  reviewing
 Priority:  normal                  |   Milestone:  Awaiting Review
Component:  Posts, Post Types       |     Version:  3.0
 Severity:  normal                  |  Resolution:
 Keywords:  has-patch dev-feedback  |     Focuses:
------------------------------------+------------------------------

Comment (by flixos90):

 Replying to [comment:6 DrewAPicture]:
 > My primary concern with the current approach is that we're doing
 argument handling in the constructor.
 >
 > Outside of the Customizer APIs and list table classes, we don't usually
 do much argument handling in constructors, as they're typically relegated
 to populating properties in core classes.
 The thing is the arguments are only validated and filled with defaults to
 populate the properties afterwards. I agree in so far that the constructor
 should not do anything external with the arguments. But we can think about
 alternatives, for example we could put all the arguments into an `$args`
 property in the class and then move the logic from the constructor into a
 `validate()` method. We could then use magic getters to access these
 values as properties. I definitely think the validating logic should stay
 in the class and not in the `register_post_status()` function. Anyway, we
 should probably discuss this in a broader scope since there are also a
 `WP_Post_Type` and `WP_Taxonomy` class in the making which use a similar
 approach (see #36217 and #36224).

 > With that in mind, I think we'd do well to implement a base/sub-class
 pattern with something like `WP_Status` – as [comment:211:ticket:12706
 suggested] by @johnjamesjacoby in !#12706 – that could be then extended
 for the posts, or users, or comments, or * use cases.
 That definitely makes sense. Just for an overview, can you outline to me
 which parts of WordPress have statuses? Not sure atm if there are others
 beside posts and comments. I would also like to broaden this discussion
 for the above two tickets - a post type and a taxonomy (and a comment
 type) are basically "content types", similar to how a post status and a
 comment status are both statuses.

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


More information about the wp-trac mailing list