WordPress.org

Make WordPress Core

Opened 4 years ago

Last modified 5 months ago

#14761 new enhancement

unregister_post_type()

Reported by: nacin Owned by:
Milestone: Future Release Priority: lowest
Severity: normal Version: 2.9
Component: Posts, Post Types Keywords: needs-patch 2nd-opinion
Focuses: Cc:

Description

Two use cases:

  1. Remove a core post type. Means that the admin menus should respond in kind, though certain aspects of core like query/rewrite might not like this. Not the main use case regardless.
  1. Removing a post type of another plugin, or potentially more likely, a parent theme.

Example barebones function: http://wordpress.pastebin.com/VexHkgig

Related, unregister_taxonomy() #11058 and unregister_taxonomy_for_object_type(): #14482

Change History (32)

comment:1 johnjamesjacoby4 years ago

+1 to this. Would want to use something like this in the bbPress plugin to unload posts and pages for users who only want forums and nothing more.

comment:2 scribu3 years ago

  • Type changed from defect (bug) to enhancement

comment:3 nacin3 years ago

  • Keywords needs-patch 2nd-opinion added
  • Milestone changed from Awaiting Review to Future Release
  • Priority changed from normal to lowest
  • Version set to 2.9

comment:4 nacin3 years ago

The simple workaround here -- particularly for built-in post types -- would be to simply deny the capabilities to that post type, i.e. edit_post and friends or edit_page and friends.

comment:5 johnkolbert3 years ago

Ideally, though, you could de-register a post type and have it remove the menu item as well (specifically for core post types). There is a function to remove menu items here but it is a little 'hack-ish'

Last edited 3 years ago by johnkolbert (previous) (diff)

comment:6 scribu3 years ago

There is a native function as well: remove_menu_page().

comment:7 nacin3 years ago

Denying the caps will kill the menu. Killing the menu will not prevent the users from going to the page though.

comment:8 follow-up: johnkolbert3 years ago

What about doing something like this: https://gist.github.com/769160

This will be overly simplistic, but just as a starter example?

comment:9 sorich873 years ago

  • Cc sorich87@… added

comment:10 mikeschinkel3 years ago

  • Cc mikeschinkel@… added

comment:11 GaryJ3 years ago

  • Cc gary@… added

comment:12 andy3 years ago

Deregistration would also be handy for plugins that are deactivating.

Typically you register post types on init. Some time after that, you get the deactivation action. A responsible plugin would remove its rewrite rules by flushing. However, it can't undo the registration, so the flush doesn't remove the plugin's rewrites.

The hacky workaround I've used is to just delete the rewrite_rules option on deactivation. They will be generated again when they are needed, so the only noticeable effect is that the next site view may take a bit longer.

comment:13 in reply to: ↑ 8 ; follow-ups: johnbillion2 years ago

I'm currently looking into whether it's workable to unregister the 'post' post type on a site. Two related issues I've found with unregistering post types:

  1. Any associated taxonomies should probably also be unregistered when unregistering a post type.
  2. The 'Right Now' dashboard widget has hardcoded output for posts, pages, categories and tags. These should only be shown if the corresponding post type / taxonomy is actually registered. I suspect there are other areas like this, this is the first one I've noticed.

Replying to johnkolbert:

What about doing something like this: https://gist.github.com/769160

You'd only need remove_menu_page() in there if you were unregistering a post type after the menu has been built. I'd say -1 on this, you should unregister post types on the 'init' hook (albeit probably with a later priority than normal).

comment:14 in reply to: ↑ 13 SergeyBiryukov2 years ago

Replying to johnbillion:

The 'Right Now' dashboard widget has hardcoded output for posts, pages, categories and tags. These should only be shown if the corresponding post type / taxonomy is actually registered.

See #19590.

comment:15 in reply to: ↑ 13 GaryJ2 years ago

Replying to johnbillion:

  1. Any associated taxonomies should probably also be unregistered when unregistering a post type.

...unless they are also being used by another post type.

comment:16 Ipstenu2 years ago

  • Cc ipstenu@… added

comment:17 scottbasgaard22 months ago

  • Cc mail@… added

comment:18 lkraav22 months ago

  • Cc lkraav added

comment:19 eddiemoya20 months ago

  • Cc eddie.moya+wptrac@… added

comment:20 lightningspirit20 months ago

  • Cc lightningspirit@… added

comment:21 sc0ttkclark20 months ago

  • Cc lol@… added

+100 on this

comment:22 ryanduff20 months ago

  • Cc ryan@… added

comment:23 DrewAPicture20 months ago

  • Cc xoodrew@… added

comment:24 follow-ups: ericlewis20 months ago

Introducing the function into the API is the first step. Something to think about in tandem is the ability to enable/disable specific core post types via a Settings page.

comment:25 in reply to: ↑ 24 ; follow-up: ryanduff20 months ago

Replying to ericlewis:

Introducing the function into the API is the first step. Something to think about in tandem is the ability to enable/disable specific core post types via a Settings page.

Not really sure I agree with the idea of more settings in the admin panel. Plugin material?

Should be easy enough to hook into the settings API to show checkboxes that would then filter on/off registered post types

comment:26 in reply to: ↑ 25 ericlewis20 months ago

Replying to ryanduff:

Replying to ericlewis:

Introducing the function into the API is the first step. Something to think about in tandem is the ability to enable/disable specific core post types via a Settings page.

Not really sure I agree with the idea of more settings in the admin panel. Plugin material?

Should be easy enough to hook into the settings API to show checkboxes that would then filter on/off registered post types

I'm reminded of BuddyPress' component administration here, in which end-users can easily enable/disable BP components.

End-users who don't want a blog on their site and just want to use WP as a CMS seems like a large demographic in my mind (no data to reference though), and giving the ability for an admin to enable / disable seems like a reasonable idea, while also supporting the "WordPress is more than just a blog" movement.

comment:27 in reply to: ↑ 24 DrewAPicture19 months ago

Replying to ericlewis:

Introducing the function into the API is the first step. Something to think about in tandem is the ability to enable/disable specific core post types via a Settings page.

+1 for introducing the function as a good first step.

comment:28 follow-up: nacin19 months ago

A unregister_post_type() function needs to un-roll quite a bit:

  • Remove the query var from the WP class, if one was registered.
  • Remove registered custom meta capabilities from _post_type_meta_capabilities().
  • Remove all post type support.
  • Remove any rewrite tags, permastructs, and rules.
  • Remove the callback for handling any meta boxes.
  • Remove the post type from any taxonomies.
  • Remove the future post hook callback.

An unregister_post_type() function should disallow the unregistration of core post types until core does not make existing assumptions all over the place. I'm not sure that will happen any time soon for 'post' and 'page'. The other types, revisions, attachments, and nav menu items, should probably never be allowed to be unregistered.

comment:29 in reply to: ↑ 28 MikeSchinkel19 months ago

  • Cc MikeSchinkel added

Replying to nacin:

The other types, revisions, attachments, and nav menu items, should probably never be allowed to be unregistered.

Agreed on 'revision' and 'attachment' but you might consider 'nav_menu_item' as something we can unregister. The current Nav Menu system is pretty heavy and for fully custom commissioned themes some professional site builders are just building menus directly into the themes since their designs don't anticipate new menu items without developer involvement. For those situations it would be nice to be able to fully disable the Nav Menu systems.

comment:30 sbruner15 months ago

  • Cc sbruner added

comment:31 ejdanderson11 months ago

  • Cc ejdanderson@… added

comment:32 jtsternberg5 months ago

  • Cc justin@… added
Note: See TracTickets for help on using tickets.