[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:  feature request                      |      Status:  new
 Priority:  normal                               |   Milestone:  Future
Component:  Post Types                           |  Release
 Severity:  normal                               |     Version:
 Keywords:  has-patch westi-likes needs-testing  |  Resolution:
  needs-refresh needs-unit-tests                 |
-------------------------------------------------+-------------------------

Comment (by nacin):

 While important, I don't think it's only a matter of only a refresh and
 unit tests.

 I've chatted with benbalter about this a few times. He studied the
 original patch for easily 10+ hours while updating it to trunk, so he's
 quite familiar. But he also didn't make any changes to it, instead simply
 refreshing a two-year-old patch based on a two-year-old API proposal.

 I think, and he agrees, that the API as proposed is lacking, confusing,
 and needs some work.

 My initial thoughts on reviewing it are:
  * The JS has a lot of room for improvement. Part of that is due to the
 age of the JS for the existing publish meta box.
  * The meta box code has a lot of room for improvement. Rather than being
 a somewhat elegant status API, it looks like a complete hack. Again, a lot
 of that is due to the existing code.

  * The "moderation" property is confusing and ill-defined.

  * Seems like we need a new query var. We currently have post_status =
 'any' (along with post_type=any) as a "meta" status that maps to
 everything. This whole thing seems like a ripe situation to take the
 post_status and perm query variables and make them better.
  * That capabilities.php is untouched in the latest patch is incredibly
 odd, to say the least. map_meta_cap() supports custom post types and needs
 to support custom statuses for both built-in and custom post types.
  * When it comes to capabilities.php and query.php, the left hand doesn't
 talk to the right hand. The previous two bullet points outline the two
 different systems, which really shouldn't be two completely separate
 systems.

  * I randomly noticed that wp_count_posts() goes from 'draft, publish,
 future, pending, private' to only public statuses. There are many
 instances of raw SQL queries being changed — we need to thoroughly review
 these and ideally avoid direct SQL as much as possible.

  * The concept of a "scheduled status" (a post having a status outside of
 the fact that it is in the "future") is nice. Perhaps this should be spun
 off and implemented separately from custom post statuses. There's just too
 much going on here, and that seems like a good thing to start with. There
 are likely other things that could be done or spun off. For example, why
 must a "published" post have a date in the past? (Think an event in the
 future.) I'm not even sure if the API as designed handles that.

 Overall, there's just so much to consider here, there's really no way it
 is happening for 3.5.

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