Menu Editing Slow (Again)

In older versions of X/Pro, menu editing was very slow (even dragging menu items around would freeze the browser tab). It was clearly an issue with X/Pro–switching to another theme fixed it. The solution at [Menu Editing VERY slow] worked for me, but it looks like that no longer fixes it in X 10.x and Pro 6.x. What’s the new solution?

1 Like

Hey Andy,

Thanks for writing in! Be advised that custom PHP coding is beyond the scope of our support under our Support Policy. If you are unfamiliar with code and resolving potential conflicts, you may select our One service for further assistance.

Meanwhile, we will forward this thread to our developers for them to investigate your issue and/or might some insight about the issue that you are having.

Best Regards.

All of those filters in the linked thread should still disable our custom field mappings. I would check the event timings to make sure those are running after we have set our custom field map actions. In a future release we can have an option or filter to prevent that code from running at all.

We do have a new integration too. cs_use_dynamic_content_in_nav_menu setting this filter to false will disable dynamic content in the menus. However I don’t think that would affect the front-end.

I’ve never actually seen this issue even with a menu with 20+ items. If you have a site I could check out and post in a secure note that would great at seeing what’s going on. Thanks have a great day.


Thank you for the responses.

@ruenel I totally understand, and appreciate the heads up. I’ll look at One if I need it in the future, but if you could forward this thread (and the one I linked to) to the devs for now, I’d appreciate it.

@charlie I have a couple of sites that I can direct you to, but they’re live so we can’t change any settings (e.g., switching themes). Would you like me to clone a site to a staging server (which will require something like a hosts file override on your end), or direct you to a public site?

I don’t plan on saving the menu or changing settings at all so public is fine with me. I just want to see what script is running slowly and why. I have no problem doing some host things for a staging site so whatever you are more comfortable with. Runel has forwarded this to me so we are good. Thanks!

Perfect, thanks. I’ve created you accounts on two sites: one’s a more common example with a dozen or so menu items. That menu editor runs slowly, but not terribly. The other is a more extreme example, with a huge menu and a nearly-unusable menu editor. That code was deployed to both child themes, and their menu editors have been performing very well until the latest update.

Let me know if you’d like to do things like change themes or go ham on functions.php and I’ll stand up a staging server.


Honestly the first example was fine for me. I couldn’t login into the second. What browser were you on? Is this just with saving or is everything slow?

I did determine you are not disabling our custom fields. I would try adding a higher priority to your hooks. We run the nav menu stuff in init. But, I also think we’re going to add a new filter where you can turn all this off instead of having a number of random remove filters in your child theme. I will keep the release notes and this thread updated on what that new filter will be.

Thanks have a great day!

I’m using Chrome. I believe that I’ve tested it with Edge as well, but I just tested it with Firefox and it works fine, so I’ve at least skipped some of my testing :man_facepalming:t2:. When in Chrome, the issue is with the entire page–rearranging items causes extreme amount of lag, expanding a menu item takes 1-30 seconds, etc. Switching to another browser tab and then back is also extremely slow, often causing the entire page to go blank while it rerenders.

This is largely anecdotal since I have a million other tabs and I’m only looking at the bottom line in task manager, but opening appearance > menu on the “more extreme” example site immediately causes Chrome’s total memory usage to climb by ~1GB.

At this point, it sounds like the code I’ve been using is largely useless. I think that, instead of trying to raise the priority and adding filters until I find the magic band-aid, I’ll wait until you add the filter and update your documentation accordingly. Thank you for the update, and let me know if I can help with any testing!

Even on Chrome the second example was okay. I’m all for filters and options that disable features you’re not going to use so we’ll go ahead and have this ready. Look for cs_use_custom_fields_map in the next release. Let us know if you have any issues when the time comes. If you are seeing fields in the menu relating to images that’s how you know the custom nav fields are running and double check your filters are running at all.

add_filter("cs_use_custom_fields_map", '__return_false');

This topic was automatically closed 10 days after the last reply. New replies are no longer allowed.