Make WordPress Core

Opened 2 years ago

Last modified 13 months ago

#23805 new defect (bug)

wp_ajax_add_menu_item() closed to user-created menu item types

Reported by: GaryJ Owned by:
Milestone: Awaiting Review Priority: normal
Severity: normal Version:
Component: Menus Keywords: has-patch
Focuses: Cc:


I'm building a new Menus meta box, that can add a new type of menu item, lets call it 'foobar'.

The conditional inside wp_ajax_add_menu_item() is slightly off. It checks that the menu item type is not 'custom', then proceeds to assume that it's either post-type or taxonomy so it can do some DB look-ups and create an $_object variable which is then used. This means it's closed to other types of menu items.

I've chosen 'foobar', so I can distinguish those items later on when walking through the front-end output.

Attachments (1)

23805.diff (1.5 KB) - added by GaryJ 2 years ago.

Download all attachments as: .zip

Change History (3)

@GaryJ2 years ago

comment:2 @GregLone13 months ago

I second that.

I have a plugin (http://wordpress.org/plugins/sf-archiver/) that builds a custom type, like @GaryJ. So far I couldn't find a way to avoid 2 php notices because of that problem (the variable $_object is not set).
Another way would be to add a filter in the switch, in a default: statement. Perhaps something like that:

    default :
        $_object = apply_filters( 'ajax_' . $menu_item_data['menu-item-type'] . '_menu_item_object', false, $menu_item_data );

if ( $_object ) {
    $_menu_item = wp_setup_nav_menu_item( $_object );

    // Restore the missing menu item properties
    $menu_item_data['menu-item-description'] = $_menu_item->description;

I guess something else would be needed for non-ajax.

Last edited 13 months ago by GregLone (previous) (diff)
Note: See TracTickets for help on using tickets.