WordPress.org

Make WordPress Core

Opened 5 years ago

Last modified 3 weeks ago

#14761 assigned enhancement

unregister_post_type()

Reported by: nacin Owned by: chriscct7
Milestone: Future Release Priority: normal
Severity: normal Version: 2.9
Component: Posts, Post Types Keywords: needs-patch early 4.4-early
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 (35)

comment:1 @johnjamesjacoby5 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 @scribu5 years ago

  • Type changed from defect (bug) to enhancement

comment:3 @nacin5 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 @nacin4 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 @johnkolbert4 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 4 years ago by johnkolbert (previous) (diff)

comment:6 @scribu4 years ago

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

comment:7 @nacin4 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: @johnkolbert4 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 @sorich874 years ago

  • Cc sorich87@… added

comment:10 @mikeschinkel4 years ago

  • Cc mikeschinkel@… added

comment:11 @GaryJ4 years ago

  • Cc gary@… added

comment:12 @andy4 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: @johnbillion3 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 @SergeyBiryukov3 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 @GaryJ3 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 @Ipstenu3 years ago

  • Cc ipstenu@… added

comment:17 @scottbasgaard3 years ago

  • Cc mail@… added

comment:18 @lkraav3 years ago

  • Cc lkraav added

comment:19 @eddiemoya3 years ago

  • Cc eddie.moya+wptrac@… added

comment:20 @lightningspirit3 years ago

  • Cc lightningspirit@… added

comment:21 @sc0ttkclark3 years ago

  • Cc lol@… added

+100 on this

comment:22 @ryanduff3 years ago

  • Cc ryan@… added

comment:23 @DrewAPicture3 years ago

  • Cc xoodrew@… added

comment:24 follow-ups: @ericlewis3 years 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: @ryanduff3 years 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 @ericlewis3 years 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 @DrewAPicture3 years 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: @nacin3 years 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 ; follow-ups: @MikeSchinkel3 years 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 @sbruner2 years ago

  • Cc sbruner added

comment:31 @ejdanderson2 years ago

  • Cc ejdanderson@… added

comment:32 @jtsternberg20 months ago

  • Cc justin@… added

comment:33 @chriscct76 weeks ago

  • Keywords early 4.4-early added; 2nd-opinion removed
  • Owner set to chriscct7
  • Priority changed from lowest to normal
  • Status changed from new to assigned

I'm not sure why, but this ticket doesn't show up on the {43} report even though it qualifies under the params.

That being said this is a great idea and something that should proceed.

This is going to require alot of time to test it thoroughly, but I wouldn't mind tackling this for 4.4, so let's call it 4.4-early, unless someone wants to give this a go for 4.3 (which would need to happen *very* soon given the major feature freeze is in 2 weeks)

comment:34 in reply to: ↑ 29 @chriscct76 weeks ago

Replying to MikeSchinkel:

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.

That's an interesting point of view. The problem with that is it could have unintended circumstances (plugins doing weird things or having a dependency somehow on that post type), but I'll take a look at it after 4.3 is out.

Last edited 6 weeks ago by chriscct7 (previous) (diff)

comment:35 in reply to: ↑ 29 @kraftbj3 weeks ago

Replying to MikeSchinkel:

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.

There's probably a cleaner way to deactivate the nav menu system (even if, initially, it simply remove all admin UI items) instead of deactivating the dependent post_type. That post type exists for the nav menu system, the nav menu system doesn't exist to support the post type.

Note: See TracTickets for help on using tickets.