Reduce memory usage of taxonomy terms overview page

> I don't know if this is D7 Core-specific or module-specific error.

Then disable i18n, try again .

If this happens on Structure --> Taxonomy --> List Terms it doesn't look like it is i18n.

I have the same problem. In may case, I had problems importing the database (allowed-max-packet issue in a shared hosting); the table cache_menu didn't up properly.

Now, I can't edit menu links:
Fatal error: Allowed memory size of 33554432 bytes exhausted (tried to allocate 1289048 bytes) in /home/xx/public_html/includes/database/database.inc on line 2108

and i can't access into a page created with de view module:

Fatal error: Allowed memory size of 33554432 bytes exhausted (tried to allocate 317784 bytes) in /home/xx/public_html/includes/bootstrap.inc on line 2680

I used the taxonomy.module on Drupal 7.7

worked like a charm for us here http://drupal.org/node/1261162

php memory limit set to anything over 128mb for example was not reflected to the server for a reason we actually dont know. We needed to fix the memory limit by another apache setting in .htaccess called «Rlimit». and it worked no more fatal memory error

This happens on the Taxonomy terms overview page (admin/structure/taxonomy/%taxonomy_vocabulary_machine_name) when showing a vocabulary that has many child terms inside a parent term. I have a vocabulary of 2750 terms spread over 9 parent terms, and over 700MB memory is needed to generate this page:

Page execution time was 59992.86 ms. Memory used at: devel_boot()=6.67 MB, devel_shutdown()=528.43 MB, PHP peak=737.25 MB.

The terms overview page (taxonomy_overview_terms()) will always show at least 2 root elements to make it possible to order them using drag and drop. If they have many children this can result in a very large page. In my case 283 terms were output to the page, and each of these terms have weight select lists ranging from -2750 to 2750. This takes up a large amount of memory.

Here are some profiling results:

tags

The problem seems to be that complete re-ordering of the vocabulary is allowed on a single page (at least in terms of the weight field)

http://api.drupal.org/api/drupal/modules--taxonomy--taxonomy.admin.inc/f...

Because there might be hundreds or thousands of taxonomy terms that need to be ordered, terms are weighted from 0 to the number of terms in the vocabulary, rather than the standard -10 to 10 scale.

In fact this comment seems wrong - the weight field does not start at zero but -$delta where $delta is something like the size of the vocabulary

I believe that this results in a weight field generated has an options array twice the size of the vocabulary

It seems to be this large array (repeated for each term listed) that is causing memory problems, timeouts - and just very slow pages.

I have made a quick patch which works for me.

I have just hardcoded the maximum delta to 100 - realising that this limits the ability to sort taxonomies - but the current version doesn't work at all for me.

This may not be right for core at the moment - but maybe it will at least be helpful to some people and point others in the right direction ....

see #941310: FormAPI select/weight fields do not scale

subscribing

subscribing

Hello
Have the same problem. Over 10K taxonomy terms in my vocabulary and get "Allowed memory size of 134217728 bytes exhausted (...) /taxonomy/taxonomy.admin.inc on line 388" :/ .... subscribing

#17: you can try the patch in #7 of #941310: FormAPI select/weight fields do not scale. It should help and with some luck it can even be enough.

The issue in #941310: FormAPI select/weight fields do not scale is indeed the same as this one, but is more general. Marking this as a duplicate.

Striked out references to i18n, since this is not related to i18n.

I have a taxonomy made of 36184 terms with a single root term. I know this might seem wrong but we plan to add more root terms soon.
My problem is that the terms overview page is already not usable due to its memory usage. It tries to build a page containing everything under the root item.

I wonder if it would be possible to use a configuration variable for the lower level we would like to use to start the pages, cf. suggested patch.

PS: sorry to reopen this ticket but though it is an old one its description matches very well the problem I am facing. Let me know if you would prefer a new ticket for that.

New patch attempt

I think the only option here if we want to keep current features (reset to alphabetical) is getting the terms ordered by the database itself and marking the vocabulary somehow as being 'alphabetical' or not. Also that page cannot rely on taxonomy_get _tree or you'll need an extra parameter for that function.

Anyway it looks pretty complex, api changes etc, so maybe best advice would be to use some contrib module that replaces this page, maybe
https://drupal.org/project/taxonomy_manager

Good luck -me unsubscribing from this one.

Thanks for the prompt reply. I understand that there are very few chances that Drupal 7 is updated for this in a near future.
So, as you suggested, I will look for an alternative.

However, this is not the first time that I find the default taxonomy terms management unsuitable to big taxonomies. Anytime we have to deal with more than 3 pages of terms, this screen is not very helpful (when not unusable due to its memory usage).