Make WordPress Core

Opened 8 years ago

Last modified 5 years ago

#37914 new enhancement

Taxonomy: Allow terms to be previewed before publishing

Reported by: celloexpressions's profile celloexpressions Owned by:
Milestone: Future Release Priority: normal
Severity: normal Version: 4.7
Component: Taxonomy Keywords: needs-patch dev-feedback
Focuses: Cc:


There is currently no mechanism to preview or draft taxonomy terms. As soon as a draft post with new terms is saved, for example, the new term is published, visible to other users in wp-admin, and could be visible on the front end of the site depending on the theme and plugins.

The lack of a draft or preview mechanism also makes it impossible to manage terms in the customizer. Long term, the goal is to enable posts and terms to be able to be live-previewed with front end context, based on functionality being developed in the Customize Posts and, now, Customize Terms plugins.

In 4.7, with the new ability to create posts wintih nav menus (#34923), we'd like users to also be able to create terms so that they an set up their site structure. Unfortunately this is not possible until we have a mechanism for previewing terms. I'm currently milestoning this for 4.7 so that we can try to add support for that feature (in a separate ticket), but this ticket is for API support only and still may be more than we can complete in time for 4.7.

Based on comments from @boonebgorges on #34923, there are a couple of potential approaches for enabling term previewing:

  • Introduce a term_status field

    Even if we don't have anything as robust as a "term status API", we still have to be sure that, at the very least, term_status != 'publish' terms are excluded from most queries - a change that has the potential for weird back compat issues.

  • An internal taxonomy for draft terms, which may be more conservative but also more complex, especially if we want to support things like hierarchy for draft terms.

    It may be easier (maybe more code, but fewer hacks) to do on-the-fly registration of a separate internal taxonomy for each taxonomy that's getting a draft term added via the Customizer.

We'll want a future-proof solution that can support term meta being previewable as well. auto_draft posts are the inspiration on the posts end for the customizer approach.

Change History (10)

This ticket was mentioned in Slack in #core-customize by celloexpressions. View the logs.

8 years ago

This ticket was mentioned in Slack in #core by celloexpressions. View the logs.

8 years ago

#3 @boonebgorges
8 years ago

Whoops, I just left some thoughts on #37915 that I probably should have left here instead. See and

#4 @boonebgorges
8 years ago

I've started writing up a more detailed plan. Feedback and edits welcome here:

This ticket was mentioned in Slack in #core-customize by celloexpressions. View the logs.

8 years ago

This ticket was mentioned in Slack in #core-customize by celloexpressions. View the logs.

8 years ago

#7 @johnjamesjacoby
8 years ago

Playing devil's advocate, and without being fully educated on the most desirable workflow, is it possible to mock all of this in the customizer UI, and not write anything to the database until the results are complete?

Outside of the customizer, it's still possible for an Editor/Admin to draft a blog post, add a bunch of new categories and tags, then immediately trash the post, leaving the newly added categories and tags in place. If we want to change this behavior, that should happen within the context of the current UI before it's transitioned to the customizer.

Maybe I've been working around schema quirks for too long, but if I understand the problem correctly, there may be at least 1 way to achieve a less complex data object relationship...

If I were trying to build a plugin to do this, I'd stash an associative array of potential taxonomy terms in post-meta on the draft or revision. It would need to be diffed/merged on edit/update (to not duplicate terms that might have been added since the last edit.) We couldn't use the metadata API to do this (#11049, #20564) but that is where it belongs, so it would need direct DB queries to get by.

I can also imagine odd behavior for active sites with multiple authors and frequent taxonomy term updates. Imagine this scenario:

  • Author 1 starts writing a post, tagged "Puppies
  • Author 2 notices a "Puppies" draft tag exists, and deletes it
  • Author 1 publishes a new post with the now deleted "Puppies" tag
  • Imagine if "delete" is now "trash" - what's the end look like, and why?

This isn't a new scenario, it could happen today, but introducing the concept of statuses carries with it the user-expectation that they are reliable. We understood this with posts, so we introduced Post Locking a few versions back. Not to let perfection get in the way of the good-enough, but we'd probably eventually want some kind of Term Lock in place, too, so that in-progress terms don't get destroyed in some other way.

#8 @celloexpressions
8 years ago

Thanks for the feedback @johnjamesjacoby.

This also goes back to #34923. The challenge is that since we're getting into complex scenarios such as actually previewing drafted post or term pages in the customize preview, and associating them with nav menu item objects, it's difficult to emulate all of the functionality we need without having actual term objects.

In other scenarios, though, it would be good to explore other options for previewing when actual terms aren't needed.

#9 @boonebgorges
8 years ago

  • Milestone changed from 4.7 to Future Release

#12 @celloexpressions
5 years ago

  • Milestone set to Future Release

This is still a feature that is necessary to completing the content-creation-in-menus project that was started in WordPress 4.7. Longer-term customize roadmaps would rely on this feature more heavily, particularly with functionality like changesets that require information to be stored in the database and savable/shareable, as opposed to session-specific.

It also seems inline with other improvements to term object data structure in recent years, although I would defer to Taxonomy component maintainers for additional input there.

Note: See TracTickets for help on using tickets.