Make WordPress Core

Changes between Initial Version and Version 1 of Ticket #12706, comment 186


Ignore:
Timestamp:
01/19/2014 07:55:32 PM (11 years ago)
Author:
MikeSchinkel
Comment:

Legend:

Unmodified
Added
Removed
Modified
  • Ticket #12706, comment 186

    initial v1  
    1616}}}
    1717
    18 With a `post_status_supports()` function it would seem we could evolve a lot of the code in core and in plugins that operate on happenstance related to statues and actually focus on the thing matters.  With this approach and a relate filter hook plugin and themes could add their own statuses ''(or status aliases, however it plays out)'' and if they want their status to support editing but not revisions, then so be it. 
     18With a `post_status_supports()` function it would seem we could evolve a lot of the code that operates on happenstance and instead actually focus on the ''(currently implicit)'' logic needed.  With this approach and a related filter hook, plugin and themes could add their own statuses ''(or status aliases, however it plays out)'' and if they want their status to support editing but not revisions, then they would have control to do so and core would support their new statuses.
    1919
    2020> And at that point, I begin to wonder if an actual "aliases" API is most helpful. And if a post is pending review ("Pending"), who is it pending review for? Is it really necessary to have a separate "status" for each desk a post needs to reach (I'm thinking newsroom, but you can probably extrapolate this for other workflows), or is it just a piece of metadata tied to the post that allows us to say "oh yes, it is assigned to Helen for review". It's still "Pending", so does it really matter what its status is?