register_post_type function does not check reserved post_types

[sebastiaandegeus]

the function register_post_type() in wp-includes/post.php does not check for reserved post types. But later on this will cause malfunctions or unexpected behaviour and bugs.

I wrote a very simple patch that checks if any of the reserved post_types are being registered and if so it notifies the developer by _doing_it_wrong and WP_Error as a fallback.

Projects and plugins that are using reserved post_types in the wild will not break. But the developers will be notified via the logs or on their development environments where WP_DEBUG is true.

ps. I will submit a similar ticket for taxonomies after this one.

[danielbachhuber]

Related #31155

[danielbachhuber]

Wouldn't this break registering core post types? Why shouldn't I be able to change the registration arguments for a core post type by re-registering the post type?

[sebastiaandegeus]

That's a very good question. I will take a look at the code where core post_types are being registered.

[tyxla]

I agree that something must be done on this one, as using one of the reserved/disallowed post types may result in unexpected results which can be difficult to locate/debug for some developers.

The above solution can work for core post types too, if we build the logic around the _built_in property. Basically, register_post_type() should allow the reserved post types post, page, attachment, revision and nav_menu_item to be registered again, but only with _built_in = true. And the disallowed post type names action, 'order' and theme should not be allowed at all.

Attaching a patch for that.

[tyxla]

Call a _doing_it_wrong() when reserved post types post, page, attachment, revision and nav_menu_item are used with _built_in = false, and when disallowed post types action, 'order' and theme are used. Including unit tests.

[SergeyBiryukov]

Related: #12929, #18263.

[valendesigns]

@tyxla why are action, order, and theme disallowed post types?

[tyxla]

@valendesigns these are disallowed by design, as they are used internally by WordPress. You can read more about these three here: ​register_post_type#Reserved_Post_Types - quoting:

In addition, the following post types should not be used as they interfere with other WordPress functions.

action
order
theme

In a nutshell, using any of these as the post type's name would conflict with the built-in WordPress parameters. The action is internally used to send a specific action (often in the administration, or in an AJAX call), the order is a built-in query var for specifying ASC or DESC for a query, and the theme is internally used by theme installer, editor and upgrader in the administration.

[DrewAPicture]

Worth mentioning that there's actually a ​whole list of reserved terms that should not be registered as post types or taxonomies.

Also, I think these _doing_it_wrong() strings could be reworked a little bit. It's much less about the post types being registered as non-built-in and more that post types cannot be registered with select reserved terms.

[valendesigns]

Replying to tyxla:

@valendesigns these are disallowed by design, as they are used internally by WordPress. You can read more about these three here: ​register_post_type#Reserved_Post_Types - quoting:

Thank you for the response. And yes, I understand the potential conflicts and have read that article before. However, it says "should not be used", it does not say they are disallowed. This patch is making the decision for you even though the documentation says something different. Are they 100% NOT allowed to be register or are they edge cases that could present a conflict but only under a certain situation and as a developer if I know the pitfalls shouldn't I be able to make that decision. If they are not allowed then the documentation needs to be updated, as well.

[SergeyBiryukov]

#33125 was marked as a duplicate.

[WraithKenny]

Just an idea, but what about an API for registering reserved terms, perhaps for 4.5? Core code, when registering post_types for example, would call register_reserved_term('post') or somesuch. Perhaps and array of terms, with a reference to the __FILE__ (might be useful for debugging), a descriptions, whether its added by core, etc. Then, other functions (core and user) could check this list (like for tax identifiers, page slugs, etc), and plugins could extend the list from the same API. Might be better than the adhoc convention...

[swissspidy]

Slightly related: #34413.

[swissspidy]

#35267 was marked as a duplicate.

[SergeyBiryukov]

#55216 was marked as a duplicate.