[wp-trac] [WordPress Trac] #56171: Unexpected behaviour and data loss with a post type called 'link' and Link Manager plugin active

[WordPress Trac]

#56171: Unexpected behaviour and data loss with a post type called 'link' and Link
Manager plugin active
--------------------------+------------------------------
 Reporter:  manfcarlo     |       Owner:  (none)
     Type:  defect (bug)  |      Status:  new
 Priority:  normal        |   Milestone:  Awaiting Review
Component:  Taxonomy      |     Version:
 Severity:  critical      |  Resolution:
 Keywords:  close         |     Focuses:
--------------------------+------------------------------

Comment (by manfcarlo):

 I think you're missing the point. The unexpected effects are not caused
 because `link` is on a disallowed list. They are caused because core
 specifies `link` as the object type for a taxonomy but does not register
 it as a post type.

 That brings me back to this part:

 > Interestingly, the function `register_taxonomy_for_object_type`
 [https://github.com/WordPress/WordPress/blob/6.0/wp-
 includes/taxonomy.php#L734 rejects any string that is not registered as a
 post type.] Of course, if the same check were included for immediate
 registration through `register_taxonomy`, link categories could not exist
 at all.

 If it is deemed acceptable for core to specify a string as the object type
 for a taxonomy without registering it as a post type, then why the early
 return?

 One would expect that the `$object_type` parameter has an identical domain
 of accepted values for the `register_taxonomy_for_object_type` and
 `register_taxonomy` functions. Not only does the domain of accepted
 `$object_type` values differ between the two functions, but the difference
 in the domain of accepted values is practically undocumented, there is
 only one instance of core passing an `$object_type` to `register_taxonomy`
 that would not be accepted by `register_taxonomy_for_object_type`, and
 it's within a feature that has been hidden for 10 years.

 These are some of the solution options that I can think of:

 **Option 1:** Remove the early return from
 `register_taxonomy_for_object_type` and fully allow (and document) the use
 of taxonomies for non-post entities. This may seem appealingly simple, but
 note that the ultimate hiding of links in #21307 appears to have been
 catalysed by the proposal to convert links to a post type in #14339 and
 #18781. In other words, if plugins are to be invited to use taxonomies for
 non-post entities, core is not leading by example by coming very close to
 making its one and only usage of the feature redundant.

 **Option 2:** Add the early return to `register_taxonomy`, explicitly
 disallow the use of taxonomies for non-post entities and convert links to
 a post type as was originally proposed. This is likely to be
 uncontroversial but it would be strange to upgrade a feature that remains
 hidden after 10 years.

 **Option 3:** Add the early return to `register_taxonomy`, explicitly
 disallow the use of taxonomies for non-post entities and implement link
 categories in some clever way without using a taxonomy. This could
 potentially be an effective solution but also likely very costly to
 engineer for a low benefit.

 **Option 4:** Add the early return to `register_taxonomy`, explicitly
 disallow the use of taxonomies for non-post entities and stop supporting
 the Link Manager. This would be simple but likely controversial.

 **Option 5:** Add the early return to `register_taxonomy`, explicitly
 disallow the use of taxonomies for non-post entities but allow `link` as
 an explicit exception, e.g. `if ( 'link' !== $object_type && !
 get_post_type_object( $object_type ) ) return false;`. I lean towards this
 option as it is a good balance between simple and effective.

 With shared terms and global terms, taxonomies already have a history of
 feature discontinuation. I'm not familiar with the details of those
 discontinuations, particularly how legacy compatibility was handled, but
 if it can be done for shared terms and global terms, then why not for
 this?

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