When trying to list terms in a tag vocabulary with 1000+ items (created via Devel Generate) I hit a memory size problem even when PHP is configured for 256MB of RAM.

Fatal error: Allowed memory size of 268435456 bytes exhausted (tried to allocate 293497 bytes) in /srv/www/core/includes/theme.inc on line 1891

Rather than not making big vocabularies and not letting users do that either, I propsose a fix to the way taxonomy terms are paged. Specifically, it seems to make use of a variable called taxonomy_terms_per_page_admin. That variable cannot be set via the UI, so the default of 100 is always used. If it were possible to change this number, the problem could be made to go away.

Rather than allow a user to specify the number of items per page on the taxonomy admin screen, I think a way of setting a number of items per page on all pagers would be a Good Thing™.

See #39954: Pager should allow changing the "number of items per page" (and allow "show all") for more info on the general pager limit question.

Slightly related, the variable taxonomy_override_selector is also only referenced in variable_get() and variable_del().

Comments

cafuego’s picture

cafuego commented

Hmm, this seems to be a bit random and I can't immediately reproduce it on a newly generated vocabulary. Maybe related to the vocabulary depth :-/

xjm’s picture

xjm
she/her
Primary language English
commented

See also #242324: Going to page 2 on "list terms" page doesn't display additional terms.

xjm’s picture

xjm
she/her
Primary language English
commented

See also #292073: Long hierarchies not displayed on Taxonomy admin page; maybe this is a duplicate of that?

firebird’s picture

firebird commented

I have the same problem. I've been looking at it, and I _think_ it happens when the second level has too many elements.

It looks like the taxonomy module wants to always show at least two root elements per page. But if the first element is the first root element, and that has, say, 300 children, we just run out of memory before they're all rendered. I've got too nearly identical installations. One tries to print 127 elements on the first page, successfully, but the other one is going for 375, and runs out of memory.

I'm not 100% sure this is what's happening; I'll keep at it.

cafuego’s picture

cafuego commented

I had a quick hack at a patch that dynamically changed the number of elements per page based on the maximum term depth, which seemed to work. Should I see if I can dig it up?

firebird’s picture

firebird commented
Status: Active » Closed (duplicate)

Now I got it. I've seen this before, and there's a patch that works for me, at least, in here: http://drupal.org/node/941310

I'm marking this as a duplicate. Feel free to re-open if it doesn't work for you.

xjm’s picture

xjm
she/her
Primary language English
commented

The weight select element has been fixed in D8 and D7 in #1346760: Add a scalable weight select element. This should be in 7.11. So, if that's the underlying issue, then updating to the latest 7.x-dev or applying the patch from that issue should resolve it. However, as the original post is a PHP memory exhaustion issue rather than a frontend performance issue, I'm not sure this issue is actually a dupe.