#14761 closed task (blessed) (fixed)
unregister_post_type()
Reported by: | nacin | Owned by: | |
---|---|---|---|
Milestone: | 4.5 | Priority: | normal |
Severity: | normal | Version: | 2.9 |
Component: | Posts, Post Types | Keywords: | early has-patch has-unit-tests |
Focuses: | Cc: |
Description
Two use cases:
- 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.
- 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
Attachments (6)
Change History (63)
#3
@
14 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
#4
@
14 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.
#5
@
14 years ago
Ideally, though, you could de-register a post type and have it remove the menu item as well. There is a function to remove menu items here but it is a little 'hack-ish'
#7
@
14 years ago
Denying the caps will kill the menu. Killing the menu will not prevent the users from going to the page though.
#8
follow-up:
↓ 13
@
14 years ago
What about doing something like this: https://gist.github.com/769160
This will be overly simplistic, but just as a starter example?
#12
@
13 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.
#13
in reply to:
↑ 8
;
follow-ups:
↓ 14
↓ 15
@
13 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:
- Any associated taxonomies should probably also be unregistered when unregistering a post type.
- 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).
#14
in reply to:
↑ 13
@
13 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.
#15
in reply to:
↑ 13
@
13 years ago
Replying to johnbillion:
- Any associated taxonomies should probably also be unregistered when unregistering a post type.
...unless they are also being used by another post type.
#24
follow-ups:
↓ 25
↓ 27
@
12 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.
#25
in reply to:
↑ 24
;
follow-up:
↓ 26
@
12 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
#26
in reply to:
↑ 25
@
12 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.
#27
in reply to:
↑ 24
@
12 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.
#28
follow-up:
↓ 29
@
12 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.
#29
in reply to:
↑ 28
;
follow-ups:
↓ 34
↓ 35
@
12 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.
#33
@
10 years 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)
#34
in reply to:
↑ 29
@
10 years 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.
#35
in reply to:
↑ 29
@
10 years 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.
#37
@
9 years ago
14761.diff is the beginning of a patch for this, based on #28.
- 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.
Need to implement remove_rewrite_tag
and figure out how to properly remove meta caps. Any help appreciated.
#38
@
9 years ago
- Keywords has-patch has-unit-tests dev-feedback added; needs-patch removed
- Milestone changed from Future Release to 4.5
14761.2.diff fully implements unregister_post_type()
. The following changed compared to the previous patch:
- Properly removes the post type from the
$wp_post_types
global - Implemented
remove_rewrite_tag()
- Replaces
_unregister_post_type()
with the new function everywhere - Properly handles post type meta capabilities by storing them in a global instead of a static variable
All unit tests pass, of course.
#40
@
9 years ago
14761.4.diff is a refreshed patch with some more tests after feedback on #35227 and the other tickets related to this. Every bit of the function is now covered, so I'm certain that it works.
The main thing that I'd love to hear some feedback on is making $post_type_meta_caps
a global variable. Currently it's a static variable inside _post_type_meta_capabilities()
, which means deleting meta caps is not possible.
However, it's a fairly small change, so I'm not worried about it.
#43
@
9 years ago
- Owner set to swissspidy
- Resolution set to fixed
- Status changed from assigned to closed
In 36316:
#44
follow-ups:
↓ 45
↓ 49
@
9 years ago
- Resolution fixed deleted
- Status changed from closed to reopened
I think we should rename unregister_post_type()
to deregister_post_type()
. Semantics? Maybe. But I think it's worth discussing.
The basic issue is that "unregister" isn't really a word. In fact, the only context in which "unregister" is really valid is when describing the state of a post type registration. The action is registration vs deregistration.
For instance: An unregistered (state) post type is one that has been deregistered (verb).
#45
in reply to:
↑ 44
;
follow-ups:
↓ 46
↓ 47
@
9 years ago
Replying to DrewAPicture:
I don't disagree with the semantics, but WordPress already uses unregister_
in a few other places, and does not use deregister_
anywhere.
If semantics now matters more than consistency, we should open a new ticket to deprecate semantically incorrect function names and use them as wrappers for newly named ones.
#46
in reply to:
↑ 45
@
9 years ago
Replying to johnjamesjacoby:
If semantics now matters more than consistency, we should open a new ticket to deprecate semantically incorrect function names and use them as wrappers for newly named ones.
So the argument is essentially: we've always done it wrong so let's do it wrong in perpetuity.
It's too late for the others, but I think there's value in trying not to perpetuate consistent semantic incorrectness :-)
#47
in reply to:
↑ 45
;
follow-up:
↓ 48
@
9 years ago
Replying to johnjamesjacoby:
Replying to DrewAPicture:
I don't disagree with the semantics, but WordPress already uses
unregister_
in a few other places, and does not usederegister_
anywhere.
There is wp_deregister_style()
and wp_deregister_script()
, and their related dequeue functions.
If semantics now matters more than consistency, we should open a new ticket to deprecate semantically incorrect function names and use them as wrappers for newly named ones.
deregister vs unregister, prefixed vs not prefixed.
#48
in reply to:
↑ 47
@
9 years ago
Replying to GaryJ:
In that case, wp_deregister_
best fits all of our current philosophies, if we can consistently rename & deprecate across the board.
I enjoy the Orwellian sound of unregister
but think consistent environments are double-plus good.
#49
in reply to:
↑ 44
@
9 years ago
I think we should rename
unregister_post_type()
toderegister_post_type()
. Semantics? Maybe. But I think it's worth discussing.
The basic issue is that "unregister" isn't really a word. In fact, the only context in which "unregister" is really valid is when describing the state of a post type registration. The action is registration vs deregistration.
There's also unregister_taxonomy()
which would need to be renamed, see #35227.
I'm not opposed to renaming these two functions, but I'm also not a native speaker.
#50
@
9 years ago
The basic issue is that "unregister" isn't really a word. In fact, the only context in which "unregister" is really valid is when describing the state of a post type registration. The action is registration vs deregistration.
I am unconvinced by the "isn't really a word" argument. If it's widely used, then it's a word. And it's used in many places throughout WP: wp_embed_unregister_handler()
, wp_unregister_sidebar_widget()
, unregister_nav_menu()
, unregister_setting()
, as well in other software projects (eg TinyMCE).
I like deregister
a bit more, but it's really just an aesthetic thing; to my ears, deregister
more clearly says that it was once registered and now is not. TBH, both of them sound very awkward, and I don't think there's a "right" one. We should just make an arbitrary decision and standardize for new functions like these. There is no reason to go back and change existing function names.
Given that it's register_post_type()
and register_taxonomy()
, we should not use the wp_
prefix for the new functions.
#51
@
9 years ago
All of the entries, and comments (like the one about undo) on http://english.stackexchange.com/questions/25931/unregister-vs-deregister may be influential to any naming decision.
#52
@
9 years ago
- Keywords commit removed
- Owner swissspidy deleted
- Status changed from reopened to assigned
This ticket was mentioned in Slack in #core by jorbin. View the logs.
9 years ago
#54
@
9 years ago
- Type changed from enhancement to task (blessed)
As it's just some finalization of naming at this point, I'm blessing this as a task.
#55
follow-up:
↓ 56
@
9 years ago
Just stumbled upon wp_embed_unregister_handler()
today. In the test suite, _unregister_post_type()
has been around for quite some time. I feel like we should just keep this one as-is.
#56
in reply to:
↑ 55
@
9 years ago
- Resolution set to fixed
- Status changed from assigned to closed
Replying to swissspidy:
Just stumbled upon
wp_embed_unregister_handler()
today. In the test suite,_unregister_post_type()
has been around for quite some time. I feel like we should just keep this one as-is.
Yeah, I think it's fine. Let's call this fixed.
+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.