[wp-trac] [WordPress Trac] #34923: Introduce basic content authorship in the Customizer

[WordPress Trac]

#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,
  ux-feedback ui-feedback needs-     |  javascript
  testing                            |
-------------------------------------+-------------------------------------

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
 debug.

 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