[wp-trac] [WordPress Trac] #16856: When registering custom post type, menu_position isn't honored if it's a number passed as a string
WordPress Trac
wp-trac at lists.automattic.com
Mon Mar 14 16:52:19 UTC 2011
#16856: When registering custom post type, menu_position isn't honored if it's a
number passed as a string
----------------------------+------------------------------------
Reporter: nathanrice | Owner:
Type: defect (bug) | Status: new
Priority: normal | Milestone: Awaiting Review
Component: Administration | Version: 3.1
Severity: normal | Keywords: has-patch dev-feedback
----------------------------+------------------------------------
When registering a custom post type, if you use '50' instead of just 50,
is_int() will fail and the position will be set to
++$_wp_last_object_menu. Seems safer to use isset() instead, since
position doesn't technically need to be an integer. ($menu gets sorted
before being output, and '50' is the same as 50 in that case)
This has the added benefit of allowing MANY more spaces in the $menu
variable. For instance, if you passed '50.555' as menu_position, there's
very little chance that this will conflict with another theme/plugin
register a custom menu or custom post type, and will successfully go
between 50 and 51 in the $menu array.
There are currently no checks on $position when using add_menu_page() ...
but the checks on register_post_type() currently make this an invalid
universal solution.
Personally, I don't see a downside to letting menu_position be a string.
Anything other than a number (whole or decimal) will just go to the bottom
of the $menu array, anyway, after the sort.
I'm submitting two patches ... one is type independent, and the other
casts menu_position as (int) after the isset() check.
--
Ticket URL: <http://core.trac.wordpress.org/ticket/16856>
WordPress Trac <http://core.trac.wordpress.org/>
WordPress blogging software
More information about the wp-trac
mailing list