[wp-trac] [WordPress Trac] #12706: Custom post status bugs in the admin

[WordPress Trac]

#12706: Custom post status bugs in the admin
-------------------------------------------------+-------------------------
 Reporter:  ptahdunbar                           |       Owner:  ptahdunbar
     Type:  task (blessed)                       |      Status:  new
 Priority:  normal                               |   Milestone:  Future
Component:  Post Types                           |  Release
 Severity:  normal                               |     Version:  3.0
 Keywords:  has-patch westi-likes needs-testing  |  Resolution:
  needs-refresh needs-unit-tests editorial-flow  |
-------------------------------------------------+-------------------------

Comment (by helen):

 Replying to [comment:178 MikeSchinkel]:
 > I'd propose we start with the following: ''SIMPLY'' add custom statues
 to the list of potential selectable statues in the post add/edit UI and
 require any new workflow to be handled by the developer.  Period.  That
 could easily be implemented in time for 3.9.

 It isn't simple. The existing metabox makes almost no sense when you step
 back and look at it. Visibility and status are separate in the UI, but not
 in the data, and they mess with button labeling in different and sometimes
 unpredictable ways - how can we add to this in any sane way? Shoving more
 in there just makes it even harder to change later.

 I don't think core should be providing non-default workflows at all, and
 I'm sorry about not being particularly clear about that - I just think
 that once we're talking about supporting custom statuses, we should take
 at least a few minutes to be considerate of what developers are doing with
 that. Even if the end result is simple (and, dare I hope, a simplified
 UI), a little consideration goes a long way so that people don't end up
 still having to do lame hacks, just in different places. I'm not calling
 for creating formal personas and scenarios or anything like that here -
 just a look at some of the bigger parts of the picture.

 I have no preconceived notions on how involved or big changes to UI and
 API might be. I just think there's value in a UX-first approach,
 especially when it comes to trying to avoid hampering extensibility or the
 future. Again - that UX part of the discovery process could take a total
 of 10 minutes. I don't know. I don't think we're actually conceptually at
 odds here. And, after all, it's also just my two cents.

--
Ticket URL: <https://core.trac.wordpress.org/ticket/12706#comment:180>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress blogging software