Site with large taxonomy.module vocabularies causes context to run out of memory.

Hi, thanks for the feedback, I think I'd prefer to go with option #1.

Option #1 committed in http://drupal.org/cvs?commit=361078

I'm having the same problem with drupal 6.22 and Context 6.x-3.0 when trying to edit a Context I get "Fatal error: [cut] /taxonomy/taxonomy.module".
Updating to drupal 6.22 from 6.19 seems to have made this worse, it now happens every time.

7.x-3.0-beta2

Out of memory when attempting to edit the default "global" context. This site also has a very large taxonomy.

I have not been using Context on this site. I was trying to enable it today.

Is there a work around?

Hello @bangpound and @retosteffen.

Could you tell us how large were the vocabularies that caused problems? And what memory limits were you using? That could be incredibly useful to understand to what extent can Context deal with large taxonomy vocabularies and plan future solutions.

Thank you.

SORRY, I just noticed this thread is for D6 and I have moved to D7.
-------

This has become a problem for me again. I have a site running without Context and trying to enable it now, but this site has a large taxonomy.

There are about 30 vocabularies with thousands of items. I am not sure the total. I stopped trying to increase memory at 800 MB.

Should I disable some code in Context?

Thanks for Context.

Getting this 7.x-3.x with a vocabulary with ~40,000 terms, even with high memory limits (~256mb is the highest I tested).

The main culprit here are the two calls for taxonomy_get_tree in context_condition_node_taxonomy.inc -- when I comment those out the memory error goes away.

As a workaround, I have added caching to the context_condition_node_taxonomy.inc field. Patch attached.

I applied the patch in #9 but ran into an error because continue was used outside of a loop. I changed the code to set the $options array and return the form instead of using the continue. I also fixed two trailing whitespace errors on new lines. Patch seems to be working well.

Patch in #10 is working for me as well in the testing environment for a site which had begun throwing out-of-memory errors on context save.

Tags for this site number ~21,000.

Here's a temporary workaround that eliminates taxonomy_term_tree() calls from context_condition_node_taxonomy by replacing the multiple term selection widget with a single Term ID textfield. This is clearly not the long-term solution, but providing it here as a starting point.

I was trying to replicate this issue but didn't succeed. If you are still facing the same issue please update your context module to 7.x-3.6.

I have tried even with bulk taxonomies creation. please refer the attached screenshot.

#12 works for me! well done sir!

This patch allows me to open the context edit, but when I try to save (even without making any changes I get an error message: An illegal choice has been detected. Please contact the site administrator.

And this shows up in my logs:

Sep 28 12:26:01 sitename drupal: http://sitename.local|1506601561|form|192.168.10.1|http://sitename.local/admin/structure/context/list/frontpage_context/edit|http://sitename.local/admin/structure/context/list/frontpage_context/edit|1||Illegal choice  in Taxonomy Term ID element.

Patch also needs a reroll:

[vagrant@sitename context]$ patch -p1 < context-remove_taxonomy_get_term.patch
patching file context.plugins.inc
Hunk #1 succeeded at 87 (offset 5 lines).
patching file plugins/context_condition_node_taxonomy.inc

Tested Patch #12 with Context 7.x-3.7:

It does handle the memory issue, but as it states, it only allows 1 taxonomy term per filter and you need to look up it's ID.
Thanks for the contribution, it's a great temporary solution!

Ideally the solution would be to have checkboxes of every vocabulary and when checked, we get a list of all their terms which can be selected to avoid load problems.

The challenge is that context_condition class expects only 1 field to be returned making it difficult to have a complex set of fields here.

Without making a change at a higher level of context, the only way I can think of handling this is to set the possible values into a hidden field and retrieving them the same way this patch does. Then we use JS to inject interactive fields: Checkbox for each vocabulary, loading terms once they are selected and compiling the tid of all the selected into the hidden field to return in condition_form method.