[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