Are there any reasons you can’t use strings for admin menu positions?

1 Views

When interacting with the admin menu, for instance via add_menu_page, there is a $position parameter. The inline docs indicate that this should be an integer. The Codex agrees, but adds a note that you can use a float if you make it a string (e.g. '63.3'). In wp-admin/includes/menu.php the array is sorted by comparing the keys with strnatcasecmp.

With this in mind, one could set a menu position of '63-foo' or '63-bar' to avoid position conflicts. This would be especially helpful for plugins, where they currently may set a position which can cause conflicts in some themes or with other plugins.

Read More

Using strings appears to work just fine. I combed the source and didn’t find any issues, but maybe I’ve missed something. Are there any reasons why a string can’t or shouldn’t be used for the menu position?

Post Views: 1

Related posts

2 comments

  1. Other than sorting with strnatcasecmp(), the only other place I see where the key might be used is if someone is applying custom menu ordering. However, since the menu is already being sorted based on the key order, it is unlikely that the keys would play any role in custom sorting. I can see no other reason why it would cause a problem, so it is probably safe to do. I would open up a ticket to get the inline docs changed though.

  2. This is part of a script I’m using for my theme. It looks for an empty position that’s close to your desired position. Seems a simple enough solution to me? 

    //work out "safe" menu position
    global $menu;
    $safe_menu_position = 30;
    //while there IS a value
    while( !empty( $menu[$safe_menu_position] ) )
    {
        --$safe_menu_position;
    }

Comments are closed.