Avada will interfere with ShiftNav’s back button functionality when using “shift” submenus.
Avada takes the “back” button and tries to follow the link via javascript. However, it doesn’t check for an href, and therefore it causes a 404. Here’s the problematic code in avada/wp-content/themes/Avada/assets/js/main.js
jQuery('.sub-menu li, .fusion-mobile-nav-item li').not('li.menu-item-has-children').on("click", function (e) {
var link = jQuery(this).find('a').attr('href');
if(jQuery(this).find('a').attr('target') != '_blank') { // fix for #1564
window.location = link;
}
return true;
});
The problem is that this code, using the selector .sub-menu li, is too generic, and will apply to all standard WordPress menus, not just Avada menus. And the theme should only be applying javascript to its own markup. Moreover, it is not doing an existence check for an href value (which is not required in HTML5), so when that doesn’t exist, it tries to redirect to “undefined”
Possible Solution with ShiftNav 1.4+
In ShiftNav 1.4+, you can try to avoid this script from Avada by changing the Back Button Tag to a span in the ShiftNav Control Panel > General Settings
This has worked for some users – it may depend on the Avada configuration.
Manual solution
The solution should be as simple as changing this line
jQuery(".sub-menu li, .fusion-mobile-nav-item li").not("li.menu-item-has-children").on("click", function(a) {
to target only Avada menus. Something like this should work (just adding the '.fusion-menu' so it doesn’t affect non-Avada menus)
jQuery(".fusion-menu .sub-menu li, .fusion-mobile-nav-item li").not("li.menu-item-has-children").on("click", function(a) {
Note that if you are using the minified version of the script, the change will need to be made in that file instead.