joe_bopper

I think I’ve found a solution but am having server connection issues at the moment; will have to check tomorrow morning (UK) instead.

Basically the fix involves checking if the core php ajax action in admin-ajax.php on line 72 and ajax-actions.php on line 1063 is registered. Then, if it isn’t registered, add my own action first; else, remove the core action, add mine and then re-add the core action. (I think this is the best way to not potentially interfere with other plugins).

My action then checks if the menu item type is a search box and, if so, process some nice code that works before issuing wp_die(). Otherwise, do nothing and move onto the next hooked action (presumably the core one).

Thanks again for letting me know about this and I’ll send an update tomorrow.

Thanks for drawing this to my attention.

This is happening due to a bit of rubbishness in the wordpress core code. The code doesn’t declare the $_object variable and then proceeds to define $_object in a switch statement without a default choice. This leads to the notice you are seeing for strict error reporting.

The trouble with this output is that it distracts the ajax call from the desired return. If you leave the admin menus page and return, you’ll find it has added the search box.

I will try to find a workaround resolution to this and post up a new version soon.

Cheers.

Hi thosandro,

Yes, you can edit the html code output for the search box. You use the hook ‘get_nav_search_box_form’ in the same way as ‘get_search_form’ in your code. A typical and simple way of doing this would be:

In your theme’s functions.php –

function my_nav_search_form(){
  ob_start(); //Start an output buffer
?>
<form action="<?php echo esc_url( home_url( '/' ) ); ?>" method="get">
  <input type="text" value="<?php echo get_search_query() ?>" name="s" />
  <input type="submit" value="<?php echo esc_attr_x( 'Search', 'submit button' ) ?>" />
</form>
<?php
  return ob_get_clean(); //get buffered output as string and return
}
add_filter( 'get_nav_search_box_form', 'my_nav_search_form', 10, 0 );

If you want to see the html and php used by default by the plugin, go to Trac and scroll to the function called walker_nav_menu_start_el.

Let me know if you need any more info or if this topic can be considered resolved.

Hi,

Thanks for the rating and review.

In terms of working with Max Mega Menu, I haven’t especially coded this plugin to use its features and I reckon the same is true vice versa for MMM. That said, this plugin should be suitably simple and in keeping with the WordPress setup that there shouldn’t be any conflict between the plugins.

I have just made an attempt of using both MMM & my plugin together and there doesn’t seem to be any troubles. In fact, it appears to me that MMM provides much of my plugin’s functionality already as MMM allows for a submenu to include a search widget. Where MMM seems to fall short is that the search box cannot be in the top level of a menu and the configurability of the search form design is a little more limited.

I’m not against adding a small amount of code supporting MMM (though I do want to keep my plugin lightweight). However, I’m unsure how a submenu of a search form would make sense (which it appears to me is the effect MMM has). Though, if you have an idea of the kind of thing you’re after for integration, do let me know.

Thanks very much for your positive review.

I went through the same hassle of sifting through all the tutorials and plugins which hack into the nav-walker class or some other unsatisfactory method, only to find that a satisfactory solution didn’t exist. So, in the end, I gave up the fight and built my own. It was more hassle than I expected as modifying the menu administration area has very little documentation.

Anyway, I’m glad the plugin is of use to you and pleased to hear it is working as expected.

Cheers,
Joe