[wp-trac] [WordPress Trac] #14761: unregister_post_type()
WordPress Trac
noreply at wordpress.org
Sun Feb 14 18:23:35 UTC 2016
#14761: unregister_post_type()
-------------------------------------------------+-------------------------
Reporter: nacin | Owner: swissspidy
Type: enhancement | Status: reopened
Priority: normal | Milestone: 4.5
Component: Posts, Post Types | Version: 2.9
Severity: normal | Resolution:
Keywords: early has-patch has-unit-tests | Focuses:
commit |
-------------------------------------------------+-------------------------
Comment (by boonebgorges):
> 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.
--
Ticket URL: <https://core.trac.wordpress.org/ticket/14761#comment:50>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform
More information about the wp-trac
mailing list