I saw elsewhere online this may be related to Chrome… when I use a different browser (I tested with Edge) the slow down wasn’t as bad. There’s still some slight delay, but the difference is large. I’m not sure what with Chrome is causing it though… I don’t see any errors…
@mywebmaestro,
That definitely was not the intent. Are you storing the collapsed states on a user-by-user basis or are you just having everything collapsed by default? How many items are in the menu that you are working with? Do you have any other nav menu-related plugin installed, and if so, which one(s)? I did some testing in Chrome on a menu with 60+ items nested down to the maximum 10 levels and didn’t experience any major slowdowns.
If you could provide a more detailed scenario on what you are doing/how you are doing it to get this slowdown, that would be helpful in pinpointing where the issue may lie.
Thank you,
Robert
I’m not sure what you mean about user-by-user… everything is collapsed by default, though in Chrome it takes a few seconds after going to the navigation page for it to show the collapsed state (it takes about a minute for the page to load.) There are about 180 menu items, most nested within one section, with about 4 levels maximum depth. The only other navigation related plugin installed is Nav Menu Roles (https://wordpress.org/plugins/nav-menu-roles/). I found pages like this https://wordpress.org/support/topic/menu-admin-panel-nav-menus-php-page-is-extremely-slow/ that seemed to indicate it might be a Chrome thing rather than your plugin, but I don’t know how to tell for sure. It did seem to work faster when I used Edge instead, though there was still a noticeable lag. As far as details – I’d had the menu in place before installing the plugin. WordPress and PHP are current versions. I recorded a screencast I can send you if you can let me know where to forward it…
180 nav menu items is quite a few. When the page loads, buttons are added to each item and processed individually via jQuery. I did away with the walker for the sake of compatibility. I’ve never personally had a menu with so many items and never thought to test that kind of load. How quick does it load if you have both Nav Menu Collapse and Nav Menu Roles disabled? WordPress already processes each item individually, I’m just tapping into that functionality, so I’m curious to see if there is any significant delay without the plugins enabled.
It loads right away without the plugins… the delay is between it loading the default view and then collapsing with the numbers in ()
Couldn’t blame me for hoping. 🙂 I’ll poke into the code and see if I can find any leaks
I’m thinking it could be the code that gets the direct children of a menu item. I’m wondering if you could try the following test:
1. Turn on Script Debugging for the site in question. That is done by adding the following line to the config.php:
define('SCRIPT_DEBUG', true);
2. In /wp-content/plugins/nav-menu-collapse/debug/scripts/script-6d68032c40.js, change lines 499-515 from:
var target_depth = (next.length === 0) ? depth : next.menuItemDepth();
var current_depth = target_depth;
while (next.length > 0 && current_depth > depth)
{
if (next.hasClass('deleting'))
{
result = result.add(next.nmc_direct_child_menu_items());
}
else if (current_depth === target_depth)
{
result = result.add(next);
}
next = next.next('.menu-item');
current_depth = (next.length === 0) ? depth : next.menuItemDepth();
}
To:
if (next.length > 0 && next.menuItemDepth() > depth)
{
result = result.add(menu_item.nextUntil('.menu-item-depth-' + depth).filter('.menu-item-depth-' + (depth + 1)))
}
I believe this will remove a lot of repeated code and may improve performance *fingers crossed*
-
This reply was modified 3 years ago by
Robert Noakes. Reason: Removed leading tabs to make the code easier to read
-
This reply was modified 3 years ago by
Robert Noakes.
During some testing, I found that the new code proposed above didn’t work totally right. Here is revised replacement code that stops correctly at any menu item at or above the current menu depth:
var child = menu_item.next('.menu-item-depth-' + (depth + 1));
if (child.length > 0)
{
var next_until = '';
var i = 0;
for (i; i <= depth; i++)
{
next_until += (i == 0) ? '' : ',';
next_until += '.menu-item-depth-' + i;
}
result = result.add(menu_item.nextUntil(next_until).filter('.menu-item-depth-' + (depth + 1)));
}
Unfortunately, a loop is still required in that call to make sure the nextUntil
call stops correctly, but I believe it is still much less resource-intensive.
There is another while
loop deeper in the code which could probably be refined as well, but I don’t want to go too far until I know I’m headed in the right direction. 🙂
Thank you,
Robert
I’ve not had a chance to try the code out – however, it does seem to be largely a Chrome issue, and quite possibly is related to the number of menu items. Edge works faster, though still a small lag, possibly still the number of items. I’ve been swamped with a server upgrade and haven’t had a chance to try out different scenarios.