If you have a large taxonomy (200 terms in my case), visiting /admin/build/menu/trails essentially crashes the browser (Safari). Oddly, Firefox loads the page a bit faster (I say odd because Webkit's "nitro" engine is faster at most js tasks), but it can still take minutes to render the page.

Comments

tirdadc’s picture

tirdadc commented

I've also experienced this in the past with the larger vocabularies. You end up getting prompted to terminate the script.

grendzy’s picture

grendzy commented

A bit more information... even with javascript disabled, I noticed it takes about 15 seconds to load the page, and the HTML document is over 4 MB.

The crux of the issue seems to be that menutrails creates an option list for every taxonomy terms, containing all menu items. This means the number of options grows exponentially with the number of menu items and terms.

I have about 240 menu items and 300 terms, so that's 72,000 '#options'.

dman’s picture

dman commented

I'm getting this.
Working on an imported menu with ~7000 terms in the keyword vocabulary this continually murders my browser.
I only want to use menutrails on my (much more sane) 'sections' vocab, but now management has become impossible.

I'm thinking of a patch that would count the size of the vocab before trying to render it, and just refusing to work with anything over a few dozen.

dman’s picture

dman commented

... seems it wasn't just the big vocab - 'tags' vocabs (big ones) are already disallowed. It was a combination of my 7 vocabs, each with a 1-2 dozen items, and a menu tree that's up near a hundred.
Not sure which factor should be worked on then
A pre-select screen that let us choose the taxonomy, THEN proceeded to the menu placement would work..

grendzy’s picture

grendzy commented

themekey module solved this in an interesting way... rather than pre-rending every possible rule permutation, they are added one at a time. Rules can also be re-ordered via tabledrag.

I guess we can dream of the day there's a core (or even de-facto contrib standard) notion of "context". It seems like lots of modules are struggling with the right way to build this interface. (menutrails, themekey, context, panels, rules, conditional actions, etc...).

jonhattan’s picture

jonhattan
Primary language Spanish
Location Plasencia
commented

@dman: I've done a patch implementing your desire in #3 and #4 :) See #690068-14: Out of memory with large taxonomies

porg’s picture

porg commented

Also crashed my browser.

dafeder’s picture

dafeder
he/him
Location Philadelphia, PA
commented

Having this problem as well - very annoying. Maybe we could add an option to vocabs to expose them to menutrails, unchecked by default?

davidwhthomas’s picture

davidwhthomas commented

I actually posted a patch for this 4 years ago ;)

http://drupal.org/node/199365

aaronbauman’s picture

aaronbauman
he/him
commented
Title: Runaway javascript on admin page with large taxonomies » Runaway javascript on admin page

This issue is not limited to vocabularies with a great number of terms, or taxonomies with a great number of vocabularies,
but can also be induced if a site has a great number of node types or a great number of menus or menu items.

Here are some ideas for workarounds, in order of my personal preference:
* DRY: only send one <select> element to the browser.
every single <select> element, and its child <option> elements are exactly the same.
reduce document size by rendering only one <select> element.
use javascript to set the appropriate option, instead of rendering hundreds of duplicate elements and creating 4MB+ page requests.

* Add a layer: stop loading everything on one page
provide a wildcard callback like "admin/build/menu/trails/node" and "admin/build/menu/trails/%vid", in order to limit pageload size.

* Full AJAX: load menus only as needed.
use ajax/ahah to assign 'option' elements only when a particular 'select' element is clicked.
This could be used in conjunction with the first option above.

Without some kind of solution, the admin interface is nonfunctional.
Until then, I have found that disabling javascript -- while it does not reduce pageload size -- prevents my browser from crashing. YMMV.