[wp-trac] [WordPress Trac] #34923: Introduce basic content authorship in the Customizer
noreply at wordpress.org
Mon May 30 03:25:02 UTC 2016
#34923: Introduce basic content authorship in the Customizer
Reporter: westonruter | Owner: westonruter
Type: enhancement | Status: accepted
Priority: normal | Milestone: 4.6
Component: Customize | Version:
Severity: normal | Resolution:
Keywords: needs-patch has-patch | Focuses: ui, accessibility,
Comment (by boonebgorges):
Replying to [comment:44 celloexpressions]:
> @boonebgorges following up on the discussion in devchat, we need some
guidance here with respect to terms.
> Are there any future plans to introduce a `term_status` field, similar
to `post_status`? In the customizer, there is currently no mechanism to
create draft terms that become published when the customizer is saved and
published. As a result, terms would need to be published immediately,
which goes against the customizer's principles of previewing everything
and publishing nothing before the user is ready, but aligns with the way
terms work everywhere else (for example, when added to post drafts).
> Another possible option might be an internal taxonomy for drafted terms
in the customizer. Would you foresee that creating issues with the
direction core is taking taxonomies and terms currently?
> For this ticket, the current question is whether we should wait for
future core support for draft terms, investigate the viability of an
internal taxonomy for draft customizer terms, or publish terms immediately
when they're added in the context of menus, similarly to what happens in
the post editor and elsewhere. There is currently some disagreement
regarding the acceptability of immediately publishing terms, but that may
be necessary based on your perspective on these issues.
I share your discomfort with the idea of immediately publishing draft
terms. This is highly likely to result in odd behavior that's hard to
There are no current plans for `term_status`. I did a couple Trac searches
and can't find any mention of the idea.
That being said, I think it's a decent idea. However, it's going to be
complex to implement. 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 drafted terms in the customizer" sounds more
conservative in the short term, but I'm unsure what it'd look like in
practice. Would there be a *single* internal taxonomy to represent all
registered taxonomies? It's hard to see how this would work: taxonomies
can be hierarchical or not, which will probably affect the UI and
functionality of the customizer "Add" experience; there are probably also
issues with internationalization/strings when you use a single taxonomy
for this purpose. 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.
My take is that `term_status` is a much more natural and elegant way to
solve this, but it's going to take a lot of work and may not happen for a
couple versions. One or more internal taxonomies for representing draft
terms is a clunky solution, but it can probably be implemented more or
less right away - especially now that taxonomies can properly be marked as
`public=false` #21949. I don't think that internal taxonomies like this
will pose any serious compat problems in the future. If the general
consensus is that it's important for there to be parity between posts-in-
the-Customizer and terms-in-the-Customizer in the relatively short term,
I'd go with the internal taxonomy idea.
Ticket URL: <https://core.trac.wordpress.org/ticket/34923#comment:46>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform
More information about the wp-trac