[wp-trac] [WordPress Trac] #11531: Some taxonomy names should be disallowed

[WordPress Trac]

#11531: Some taxonomy names should be disallowed
-------------------------------+------------------------------
 Reporter:  Denis-de-Bernardy  |       Owner:  ryan
     Type:  defect (bug)       |      Status:  reopened
 Priority:  normal             |   Milestone:  Awaiting Review
Component:  Taxonomy           |     Version:  2.9
 Severity:  normal             |  Resolution:
 Keywords:  dev-feedback       |     Focuses:
-------------------------------+------------------------------
Changes (by boonebgorges):

 * keywords:  has-patch needs-unit-tests => dev-feedback
 * resolution:  duplicate =>
 * status:  closed => reopened
 * component:  Cache API => Taxonomy
 * milestone:   => Awaiting Review


Comment:

 Many tickets have duplicate chains that lead to this one: #12929, #23213,
 #31154 et al. The current ticket was closed because it was decided to
 address the cache key conflict elsewhere. But registering a taxonomy using
 a reserved term causes many more problems than just cache-clash, such as
 rewrite conflicts. See eg #36997.

 I'd like to reopen this ticket for consideration. There are a few ways
 forward.

 1. A blanket moratorium on using reserved terms for taxonomies/CPTs. This
 is easy to implement, but may be overly harsh, and will definitely have
 back compat concerns. See @danielbachhuber's comment here:
 https://core.trac.wordpress.org/ticket/31155#comment:1
 2. Do some digging to figure out what the specific conflicts are in the
 case of taxonomies/CPTs registered using reserved terms, and either (a)
 fix them, or (b) only block registration in the case of the specific
 conflict (ie, rewrite base). Option (a)  essentially means that there will
 no longer be reserved terms. Eg, we could refuse to register a taxonomy
 with conflicting query vars, or force a non-conflicting slug, or something
 like that. But there are likely other potential points of conflict. Some
 of these conflicts won't arise in core. It's likely we'll never be able to
 make them work 100%. So while this strategy is nice because it
 accommodates the greatest breadth of use, it's likely to be the buggiest
 and hardest to figure out.
 3. Allow registration of taxonomies/CPTs with reserved terms, but throw a
 `_doing_it_wrong()` notice warning that it's probably not going to work.
 Big downside here is that plugins that are using reserved terms without
 any problems now see an annoying notice that they can't easily get rid of.
 And building a tool in a plugin to migrate to a new CPT/tax name is non-
 trivial and subject to lots of breakage. Maybe we could add a filter that
 allows the suppression of this specific notice - `if ( ! apply_filters(
 'i_know_what_im_doing', false ) ) { _doing_it_wrong( ... ); }`
 4. Do nothing in core, but improve the documentation. The inline docs
 currently say nothing about reserved terms, and the codex page is not
 easily found https://codex.wordpress.org/Reserved_Terms. This is the
 easiest and poses the fewest compatibility concerns.

--
Ticket URL: <https://core.trac.wordpress.org/ticket/11531#comment:18>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform