Prevent CPTs/Taxonomies from using "custom" as their name

[RachieVee]

This is a bug that includes the .menu-item-object-{custom} class that gets added to wp_nav_menu items:

​http://codex.wordpress.org/Function_Reference/wp_nav_menu#All_Menu_Items

I ran a test locally on WP 4.4. The Codex claimed this class, .menu-item-object-{custom}, gets applied to menu items that are CPTs and Custom Taxonomies.

However, I was seeing it applied to Custom Links. (Edited the Codex to reflect that.) So now it's clear to me that .menu-item-object gets applied to Custom Links but then I got curious about the CPTs/Custom Taxonomies.

CPTs and Custom Taxonomies get a class of .menu-item-object-{slug-of-cpt-or-taxonomy}.

I discovered that I can register a CPT or Custom Taxonomy using the slug "custom". So that on the front-end the CPT/Custom Taxonomy menu items get a class of .menu-item-object-custom, therefore conflicting with that class used for custom links instead. I get the impression that the class for custom links and class for CPTs/Custom Taxonomies should be entirely different entities? Or if anything, the slug "custom" shouldn't be allowed to be registered or it may conflict due to custom links using the same class.

See tags/4.4/src/wp-includes/nav-menu-template.php#L536​ for reference.

[RachieVee]

Lines 365ish of wp-includes/nav-menu-template.php

[RachieVee]

Dashboard Menu with CPTs, Custom Links and Custom Taxonomies

[RachieVee]

Front-end of menu with CPTs, Custom Links, and Custom Taxonomies

[morganestes]

After some research and discussion, it seems that 'custom' is used throughout the codebase to mostly refer to menu items (with the exception of its use in media-template.php and in permalinks). It's the default for 'menu-item-type' in wp_update_nav_menu_item(), the type registered for the "Home" link in load_available_items_query(), and is the default for menu items in the Customizer. Allowing post types, terms, meta, etc. to register and use 'custom' as the name may cause collisions with these other objects when creating menus.

I suggest either 1) changing the string from 'custom' to 'custom-link' to make it clearer what its purpose is inside the menu, and/or 2) blacklisting 'custom' from being registered for posts or terms.

If we go the blacklist route, it looks like we'd have to add checks inside each of register_(post_type|post_status|meta|taxonomy|taxonomy_for_object_type) to prevent registration, since no blacklist appears to be in place yet. Another alternative would be to silently register 'custom' using $_builtin but do nothing with it, but that seems a bit hacky to me.

[SergeyBiryukov]

We don't currently enforce a blacklist in core, but there's a ​list of reserved terms in Codex. I've added custom there.

[SergeyBiryukov]

Related: #31154

[swissspidy]

Duplicate of #31154.