Replace Custom Post Status with a Taxonomy

[tomjn]

I've come to the conclusion that post status' can work, but taxonomies are just easier

The branch that was merged included a lot of improvements to help this, so the plan of action is:

• Remove the includes/core/post_statuses/ folder
• Add a class that registers a talk_status taxonomy
  • non-hierarchical
  • add a radio button UI metabox for selecting it
• Adjust includes/core/poststatus.php
  • it should probably be renamed to postfilter.php and the class changed accordingly
  • Instead of changing the post_status query param, it should set a tax query or talk_status parameter instead
• The default post status to be changed to publish
• Remove the status column from the admin table, and use the core functionality for showing a taxonomy column instead

This will eliminate some odd bugs and avoid the hacks needed to implement them. It will also be much faster than post meta.

[imath]

I've been looking at all this and exploring the status API.

I think there are 2 problems due to how the plugin was primarly built. The private status is used in the plugin for its conveniency: only loggedin Admins or loggedin redactors of the talk can see all talks for the first and only their own talk for the second.

As a result:

• Custom statuses should have the property private === true
• We should avoid using the "Publish metabox" in favor of a custom statuses metabox which could contain the radio boxes you are talking about with a submit button having a name attibute !== 'publish'.

Custom statuses having their private property set to true should make sure the raters' comment bug has disappeared (as we are filtering pre_comment_approved for this matter). We'd probably do not need to filter the statutes of the WP Query. The only thing that could be done is adding a new default status (private = true) named something like awaiting_review.

That being said, I'm ok with the taxonomy plan, but i think we'll have a bunch or work to accomplish if you choose a default status !== private .

[tomjn]

I'm not fond of the private status as it takes some of the visibility control away from the pre_get_posts filter, but whatever happens, it must be publish or private else frontend commenting won't work as expected. I'm happy for private to be used as long as it doesn't show up in the User Interface

[tomjn]

I'm also keen on keeping the CSS that reduces the options in the publish box, it might be worth investigating expanding that styling to include the status options

[imath]

It's up to you. Imho it's a mistake to keep the publish box. It should be removed and a new metabox should be added with the radio buttons you suggested to transition post statuses. It would prevent anyone to use the regular publish post status for the talks post type and avoid some visibility issues/comments issues etc...

[tomjn]

So rather than trimming down the publish box we remove it completely? I think some design work would be good for doing that but I think it's something we should investigate. It may be the all that remains of the publish box is a save and move to trash buttons On Sat, 4 Mar 2017 at 17:54, imath notifications@github.com wrote:

It's up to you. Imho it's a mistake to keep the publish box. It should be removed and a new metabox should be added with the radio buttons you suggested to transition post statuses. It would prevent anyone to use the regular publish post status for the talks post type and avoid some visibility issues/comments issues etc...

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/imath/wordcamp-talks/issues/38#issuecomment-284168477, or mute the thread https://github.com/notifications/unsubscribe-auth/AADl57HXNZclrEM83N5XUqSb5DjTFu68ks5riaVkgaJpZM4MQhdZ .

[imath]

Yes, i've been looking at it for this plugin: https://github.com/imath/wp-statuses and i came to the conclusion it was safest to use another publish box to have a full control of it. I think the current publish box is not great for custom statuses. For instance, let's say you add a new post and immediately use one of the custom statuses you added using Javascript, clicking on the publish button won't save it as your custom status but will post it as 'publish' (unless you change the name property of the #publish submit). So yes my suggestion, is to avoid using the native metabox by removing it for the talks post type and build a new custom publish box with the statuses you created (making sure they are all $status->private = true to be sure all existing caps mapping will carry on working). Trash can be a button or one of the radio button. And btw talks doesn't need all the timestamp and visibility stuff so it can be a very straight forward list of radio buttons + save submit + eventually the button you are envisioning to create the session post.

[tomjn]

I still think the custom post statuses should be taxonomy terms, using post_status has too many edge cases that's more work than I'm comfortable with On Sat, 4 Mar 2017 at 21:23, imath notifications@github.com wrote:

Yes, i've been looking at it for this plugin: https://github.com/imath/wp-statuses and i came to the conclusion it was safest to use another publish box to have a full control of it. I think the current publish box is not great for custom statuses. For instance, let's say you add a new post and immediately use one of the custom statuses you added using Javascript, clicking on the publish button won't save it as your custom status but will post it as 'publish' (unless you change the name property of the #publish submit). So yes my suggestion, is to avoid using the native metabox by removing it for the talks post type and build a new custom publish box with the statuses you created (making sure they are all $status->private = true to be sure all existing caps mapping will carry on working). Trash can be a button or one of the radio button. And btw talks doesn't need all the timestamp and visibility stuff so it can be a very straight forward list of radio buttons + save submit + eventually the button you are envisioning to create the session post.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/imath/wordcamp-talks/issues/38#issuecomment-284183006, or mute the thread https://github.com/notifications/unsubscribe-auth/AADl5_9g2IQbyWL3k5VFK8DF4O_RTUudks5ridY3gaJpZM4MQhdZ .

[imath]

No problem, you then just need a metabox with 3 buttons

• Trash
• Save
• Generate Session

And an hidden field named 'post_status' set to 'private'.

You can probably add the taxonomy buttons in this metabox too.

PS: If you don't like 'private', then, you'll need to edit all capability mappings so that 'publish' is only viewable for raters/admin and owner id (the one who submitted the talk). In other words you'll need to transform the 'publish' status for a 'private' one.