Move JS in line with WP core

[franz-josef-kaiser]

I've just taken a look at how core adds the Nav menu items: Click on some meta box, add an item and inspect the XHR request + result in the Chrome Dev Tools console.

Here's what I've found

XHR finished loading: "http://local.dev/wp-admin/admin-ajax.php". jquery.js:2
send jquery.js:2
v.extend.ajax jquery.js:2
v.(anonymous function) jquery.js:2
wpNavMenu.addItemToMenu nav-menu.js:572
(anonymous function) nav-menu.js:146
v.extend.each jquery.js:2
v.fn.v.each jquery.js:2
$.fn.extend.addSelectedToMenu nav-menu.js:121
(anonymous function) nav-menu.js:658
v.event.dispatch jquery.js:2
o.handle.u

The interesting part is wpNavMenu.addItemToMenu. When you look at the core object wpNavMenu, then you'll see the addItemToMenu function extending it. Later core loops through something and then extends the addSelectedToMenu function. This seems to be the preferred way to do it and we should go the same route.

Inspection of nav-menu.js on line 572 and 121 needed.

[stephenharris]

Maybe best leave this till after 3.5 - anything we improve now could be in vain with the Menu makeover (http://core.trac.wordpress.org/ticket/23119)...

[franz-josef-kaiser]

3.6 is far away and I guess the underlying JS structure won't change - at least what I can see from the ticket.

[franz-josef-kaiser]

Question also is if it wouldn't be better/easier to simply rework the MarkUp, so core does it all and we can drop the custom Script at all?

[stephenharris]

Not looked into it.. We would need to intercept the Ajax request ourselves before WordPress gets to it first, right? Otherwise WordPress won't understand it and kill it.

[franz-josef-kaiser]

I did some brief tests with adding MarkUp to the plugin output and console.log()s to the core, but didn't get to a point very quickly - core JS is in fact 99% not commented and the opposite of verbose. But from what I could see it's pretty generalized, so I guess it's possible without intercepting anything and just using the "right" MarkUp.

[stephenharris]

Ok, think I misunderstood, we couldn't leave it all to core-JS even if it was possible. But how much can be saved - we'd need to trigger the ajax request ourselves to set the request's action correctly?

[franz-josef-kaiser]

I know this is a bold statement, but I think we can leave it completely to core (script side) if we use the proper markup. Anyway, that's something I'd need to proof, but I ain't got enough time at the moment to give it another try.

[stephenharris]

Right, but the native wp_ajax_add_menu_item() (source) ajax callback doesn't support post type archives - so we'd have to intercept the request and check if its necessary to respond on its behalf. I.e.

add_action( '`wp_ajax_add-menu-item', 'our_callback', 5 );
function our_callback(){
     if ( ! ADDING_POST_TYPE_ARCHIVE ){
           //Leave to wp_ajax_add_menu_item().
           return;
      }
     //Add post types etc.
}

Assuming the js allows us to 'hijack' it, how do we determine if the request is for a post type archive? I'm assuming somewhere we can inject something into $_POST['menu-item']?

[ryanurban]

Yeah I'm not sure about this being possible either. I am actually using the "proper" markup already, and had updated the markup we were using to mirror what the other WP menu metaboxes were using.

I tried to get away with using the markup only, with very little js on our end, and couldn't get it to work correctly.

This left me with the assumption that the WP js is contingent upon contextually specific menu metabox classes or ids, otherwise our markup should work as it has all the general classes the others do.

[franz-josef-kaiser]

@ryanurban As far as I can remember there were quite a few IDs involved, making it impossible (with my JS knowledge level) to work around it.

@stephenharris Fully agree with a close over here?