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

WordPress Trac noreply at wordpress.org
Thu Jan 9 22:31:48 UTC 2014


#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):

 I would love to see this taken on again, although I don't think it should
 be promised for a release until the UX and ensuing UI and API are thought
 through. I think it's important to note the order there - I understand
 that the instinct is to go for API first (I'm a developer, too, I more
 than get it), but I think what we're really battling here is growing
 pains, not just a broken API. We need to focus on what the UX should be,
 first from a default standpoint, then from a "what COULD people want to
 do" standpoint, and then determine what UI and API changes need to happen
 from there.

 For example, let's take a pretty common custom workflow of "I save a post,
 somebody else copyedits it, and somebody else actually publishes it". What
 does each user type's workflow look like when they're in the admin
 (possibly not even just the edit screen)? How can the admin help guide
 them to the best or right action or set of actions to take? From there we
 think about how an ideal UI would be structured and what an API would need
 to support for that scenario. Then, through considering various and
 varying scenarios, again starting with existing default ones, we can come
 to what kind of extensibility the UI needs to account for and, of course,
 what the API needs to look like to make it all actually work and to allow
 developers to mold and customize as needed.

 I'd love to explore this some more and plan on doing so in the near
 future, and invite anybody else who has some thoughts to do the same.
 [comment:162 comment:162] is a nice breakdown of the current "flows".

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


More information about the wp-trac mailing list