[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 MikeSchinkel):

 Replying to [comment:176 helen]:
 > then from a "what COULD people want to do" standpoint, and then
 determine what UI and API changes need to happen from there.

 That seems like a rather large scope for core development.  Maybe not for
 a "Feature-as-a-plugin", but definitely for core-focused features.

 Replying to [comment:177 danielbachhuber]:
 > If I were to pick up development on this again, I would likely follow
 this approach:
 >
 > 1. Identify five or more use cases for more complex publishing workflows
 with sufficient detail that it's possibly to understand the commonalities
 between them.
 > 2. Discuss how the commonalities could be better supported by core.
 > 3. From the commonalities, define the problem to be solved. Get buy-in
 from a core committer or two.
 > 4. Build a library to support the commonalities. Should it prove useful,
 include it in core.

 That also seems like quite a large scope, and part of the reason this
 ticket is 4 years old and still not addressed.

 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.

 Lack of custom statuses in the UI is a big missing piece in core
 ''(considering core has `register_status()`)'' and something for which
 I've had to revert numerous times to a very hackish use of
 `ob_start()`/`ob_end_clean()` to correct.

 Once custom statues have appeared in the core UI then we can more easily
 identify specific workflow use-cases that deserve to be in core, and then
 each of those independent issues can get their own ticket in core.

 JMTCW.

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