WordPress.org

Make WordPress Core

Opened 5 years ago

Last modified 3 years ago

#31154 new enhancement

register_post_type function does not check reserved post_types

Reported by: sebastiaandegeus Owned by:
Milestone: Awaiting Review Priority: normal
Severity: normal Version: 4.2
Component: Posts, Post Types Keywords: needs-patch
Focuses: Cc:
PR Number:

Description

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.

Attachments (2)

check_reserved_post_types.diff (1.3 KB) - added by sebastiaandegeus 5 years ago.
31154.patch (2.4 KB) - added by tyxla 5 years ago.
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.

Download all attachments as: .zip

Change History (16)

#2 @danielbachhuber
5 years ago

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?

#3 @sebastiaandegeus
5 years ago

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

#4 @tyxla
5 years ago

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
5 years ago

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.

#6 @tyxla
5 years ago

  • Keywords has-patch added

#7 @valendesigns
5 years ago

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

#8 follow-up: @tyxla
5 years ago

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

#9 @DrewAPicture
5 years ago

  • Keywords needs-patch added; has-patch removed

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.

#10 in reply to: ↑ 8 @valendesigns
5 years ago

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.

#11 @SergeyBiryukov
4 years ago

#33125 was marked as a duplicate.

#12 @WraithKenny
4 years ago

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

#13 @swissspidy
3 years ago

Slightly related: #34413.

#14 @swissspidy
3 years ago

#35267 was marked as a duplicate.

Note: See TracTickets for help on using tickets.