When registering custom post type, menu_position isn't honored if it's a number passed as a string
|Reported by:||nathanrice||Owned by:|
|Component:||Plugins||Keywords:||has-patch needs-testing needs-refresh 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.
Change History (23)
- Keywords dev-feedback removed
- Milestone changed from Awaiting Review to 3.1.1
- Milestone changed from 3.1.1 to Future Release
- Type changed from defect (bug) to enhancement
3 years ago
- Component changed from Administration to Menus
- Focuses administration added