Problem/Motivation

When a vocabulary's term list exceeds an indeterminate amount, users may experience a WSOD. This is caused by a call to taxonomy_get_tree() from within taxonomy_overview_terms(). This produces a known memory limit issue.

Steps to reproduce the problem:

  1. Install Drupal 8.x with the standard profile.
  2. Install devel.
  3. Visit: Extend (/admin/modules).
  4. Enable Devel and Devel generate modules.
  5. Use Devel to auto-generate terms (/admin/config/development/generate/taxonomy).
  6. Generate for the "tags" vocabulary
  7. Number of terms: 10000.
  8. Browse to terms list for the tags vocabulary (/admin/structure/taxonomy/tags).
  9. Lower PHP memory limits and/or auto-generate more terms, until WSOD occurs in previous step.

Proposed resolution

Remaining tasks

  • screenshot of the current ui (a before screenshot)
  • decide what approach to implement

User interface changes

The proposed siblings browser may introduce new or changed features/functionality in the user interface at admin/structure/taxonomy/tags.
Comment #23 has most recent screenshot of taxonomy terms by vocabulary (before proposed siblings browser).

API changes

API changes/additions might be introduced in core's taxonomy module:

Original report by andypost

Vocabulary has hierarchy field with values from 0 to 2.
So overview page for vocabulary should take into accout hierarchy field.

This is a follow up from:
#762604: Taxonomy terms list broken, term add/edit forgets it's parent
#277200: Add tests for vocabulary hierarchy

catch:
I really dislike that we use taxonomy_get_tree() in taxonomy_overview_terms()

CommentFileSizeAuthor
#83 763380-83.patch6.66 KBmanojbisht_drupal
#75 763380-75.patch6.64 KBcupcakemuncher
#74 763380-74.patch6.65 KBcupcakemuncher
#73 763380-73.patch3.86 KBjesse_k
#61 763380-61.patch3.56 KBivelin.enchev
#60 763380-60.patch3.33 KBivelin.enchev
#53 763380-53.patch3.25 KBlebster
#52 763380-52.patch3.56 KBcenoura
#48 763380-48.patch6.89 KBpdenooijer
#44 763380-36.patch3.47 KBlegolasbo
#40 763380-40.patch5.6 KBlegolasbo
#40 763380-40-test-only.patch2.13 KBlegolasbo
#40 interdiff-36-40.txt3.39 KBlegolasbo
#36 763380-36.patch3.47 KBlegolasbo
#36 interdiff-35-36.txt2.38 KBlegolasbo
#35 763380-35.patch2.66 KBlegolasbo
#35 interdiff-33-35.txt668 byteslegolasbo
#33 763380-33.patch2.58 KBlegolasbo
#23 d8-listtags.png70.45 KBbdone

Issue fork drupal-763380

Command icon Show commands

Start within a Git clone of the project using the version control instructions.

Or, if you do not have SSH keys set up on git.drupalcode.org:

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

catch’s picture

We should use a similar scheme to #556842: taxonomy_get_tree() memory issues here IMO, disable taxonomy_get_tree() if the vocabulary is over a certain size, not depending on whether it's got hierarchy or not.

Anonymous’s picture

@catch I've got mixed feelings here. It sounds like we're suggesting that hierarchical vocabularies with more than a certain number of terms can't be supported in Drupal 7 core. The other issue #556842: taxonomy_get_tree() memory issues is about swapping out a form element, but the taxonomy_overview_terms form doesn't have an alternative but to use taxonomy_get_tree or just stop showing hierarchy.

Do we want to change from a tree view to a sibling browser?

Example:

North America (Y number of immediate children)
South America (Z number of immediate children)
Europe ..
Africa ..
Asia ..
Australia etc. ....

Clicking the term refreshes the page to show its children.

This requires only one query per term to show the number of immediate children (and there's sense in avoiding that query as well). Loading the terms on each page could require only one query, yeah?

andypost’s picture

Issue tags: +Needs usability review

Main trouble that we have no ability to change vocabulary hierarchy without saving a term or editing with taxonomy_overview_terms()

So I think first we should decide on usability of managing taxonomy vocabularies and terms.

1) managing vocabulary container
2) managing terms

catch’s picture

@catch I've got mixed feelings here. It sounds like we're suggesting that hierarchical vocabularies with more than a certain number of terms can't be supported in Drupal 7 core.

Yep. I have a site where this page white screens, so that's the case currently, I'd prefer it if rather than wsoding, it just didn't allow drag and drop.

Sibling browser sounds good, but not necessarily possible at this stage of the release cycle, and would still require #698918: Reduce memory usage from \Drupal\taxonomy\TermStorageInterface::loadTree() when parent is specified since taxonomy_get_tree() does the same query regardless of arguments.

klausi’s picture

Priority: Normal » Critical
Issue tags: +D7 upgrade path

Subscribing. Experiencing this nice WSOD at the list term page, when I upgraded a site with a large vocabulary from Drupal 6.

catch’s picture

Priority: Critical » Normal

It's bad, but it's been this way forever, downgrading but adding 'major' tag.

klausi’s picture

Priority: Normal » Critical

I disagree, it has not been forever this way, as it was working in D5 and D6.
1) Upgrade path is broken.
2) a WSOD is not acceptable.

So just because this is lying around for long, it does not mean that it is not critical.

Anonymous’s picture

Priority: Critical » Normal

@klausi, the upgrade path is broken for different reasons. #706842: Improve comments for the taxonomy upgrade path It would be helpful if you could explain how your vocabulary is larger or deeper than the ones I've tested with already. What causes WSOD? memory or time?

klausi’s picture

SELECT COUNT(*) FROM `taxonomy_term_data` WHERE `vid` = 2
7184 terms in the vocabulary.

SELECT COUNT(*) FROM (SELECT * FROM `taxonomy_term_hierarchy` group by `parent`) as th JOIN `taxonomy_term_data` ON th.tid = taxonomy_term_data.tid WHERE `vid` = 2
498 terms are parents of at least one other term.

I'm not sure how to get maximum or average depth. The WSOD is caused by a lack of memory and appears after about 8 seconds page loading time.

Tested another vocabulary:
3785 terms, 2 terms are parents of at least one other term. No WSOD, but 17 seconds page loading time to display the first page. Firefox freezes for about 4 seconds while rendering the huge page. Seems like the page contains all terms because they are all children of one single term.
Another bug: there is a pager on the bottom of the page, but when I click next it says "No terms available".

Anonymous’s picture

Klausi: You should open a new issue. If you're in IRC, ping me with the node ID when you have posted it.

marcingy’s picture

Priority: Normal » Major

Changing to major as per tag.

MustangGB’s picture

Tag update

sun.core’s picture

1) Upgrade path is broken.

Can someone clarify what needs to be fixed here? The WSOD mentioned earlier is a known issue and exists since Drupal 5.

klausi’s picture

The exact same vocabulary works fine on the term admin pages in D5 and D6 but causes a WSOD in D7. However, we administer the vocabulary with the taxonomy manager module in D7 now, so investigating this is not a priority anymore for me (I guess one could generate x terms with devel.module in D6 and D7 for comparison and to reproduce the WSOD).
http://drupal.org/project/taxonomy_manager

catch’s picture

Version: 7.x-dev » 8.x-dev

Memory issues with taxonomy_get_tree() may well have regressed since D6, at least one example is #870528: taxonomy_get_parents(), taxonomy_get_children(), and taxonomy_get_tree() do not return a full term objects. However I think this needs to be worked on against Drupal 8 and backported if possible, since whatever we do here is going to mess things up for someone without a major refactoring.

catch’s picture

Issue tags: -D7 upgrade path

Removing upgrade path tag.

Bojhan’s picture

What needs review?

xjm’s picture

Issue tags: -Usability

I don't know where that tag came from since this is a DX and performance issue, not a UX one.

andypost’s picture

Is this issue still major? Anyway need a better summary

YesCT’s picture

I'm also wondering if this is still major.

Anyway.. :) tagging and adding links to contributor task docs to hopefully someone to jump into this.

bdone’s picture

Status: Active » Needs work
Issue tags: -Needs issue summary update, -Novice

Updated issue summary per comment #20.

YesCT’s picture

Issue tags: +Needs screenshots

thanks for updating the issue summary.

I think a screenshot of the current ui would be helpful (a "before")

and another next step would be to decide which of the proposed approaches to the solution to take.
(updating issue summary with those next steps)

YesCT’s picture

Issue summary: View changes

bdone issue summary

bdone’s picture

Issue tags: -Needs screenshots
FileSize
70.45 KB

Adding screenshot from: /admin/structure/taxonomy/tags

Taxonomy terms, by vocabulary (before proposed siblings browser)

bdone’s picture

Issue summary: View changes

updated remaining steps: screenshot and decide on approach. -c

bdone’s picture

Updated issue summary to refer to screenshot in #23.

bdone’s picture

Issue summary: View changes

bdone: adding (before) screenshot

jibran’s picture

Title: Do not use taxonomy_get_tree() in taxonomy_overview_terms() » Do not use \Drupal\taxonomy\TermStorageInterface::loadTree() in \Drupal\taxonomy\Form\OverviewTerms::buildForm()
YesCT’s picture

Status: Needs work » Active
Issue tags: +Performance

can we reverify this?

is this a performance bug?

setting to active since there is no patch.

Version: 8.0.x-dev » 8.1.x-dev

Drupal 8.0.6 was released on April 6 and is the final bugfix release for the Drupal 8.0.x series. Drupal 8.0.x will not receive any further development aside from security fixes. Drupal 8.1.0-rc1 is now available and sites should prepare to update to 8.1.0.

Bug reports should be targeted against the 8.1.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.2.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.1.x-dev » 8.2.x-dev

Drupal 8.1.9 was released on September 7 and is the final bugfix release for the Drupal 8.1.x series. Drupal 8.1.x will not receive any further development aside from security fixes. Drupal 8.2.0-rc1 is now available and sites should prepare to upgrade to 8.2.0.

Bug reports should be targeted against the 8.2.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.3.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.2.x-dev » 8.3.x-dev

Drupal 8.2.6 was released on February 1, 2017 and is the final full bugfix release for the Drupal 8.2.x series. Drupal 8.2.x will not receive any further development aside from critical and security fixes. Sites should prepare to update to 8.3.0 on April 5, 2017. (Drupal 8.3.0-alpha1 is available for testing.)

Bug reports should be targeted against the 8.3.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.4.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

pcambra’s picture

Version: 8.3.x-dev » 8.4.x-dev

Drupal 8.3.6 was released on August 2, 2017 and is the final full bugfix release for the Drupal 8.3.x series. Drupal 8.3.x will not receive any further development aside from critical and security fixes. Sites should prepare to update to 8.4.0 on October 4, 2017. (Drupal 8.4.0-alpha1 is available for testing.)

Bug reports should be targeted against the 8.4.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.5.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.4.x-dev » 8.5.x-dev

Drupal 8.4.4 was released on January 3, 2018 and is the final full bugfix release for the Drupal 8.4.x series. Drupal 8.4.x will not receive any further development aside from critical and security fixes. Sites should prepare to update to 8.5.0 on March 7, 2018. (Drupal 8.5.0-alpha1 is available for testing.)

Bug reports should be targeted against the 8.5.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.6.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

legolasbo’s picture

Status: Active » Needs review
FileSize
2.58 KB

We're running into this issue on a media website with 45K tags which runs out of memory trying to display a single page of terms. I've raised the memory limit to over 1GB on my development machine which replaced the out of memory issue with a execution time limit issue. Which made me look into the code that runs this form.

After having looked into this I've found that the main memory issue is caused by the fact that we're calling loadTree() with the load_entities option set to true. This causes all 45K term entities to be loaded into memory, which A fills up the memory and B takes a very long time.

I've worked on a quick fix to at least get the overview page accessible again. Reordering the items and then submitting the form still doesn't work, because it runs out of memory because this also loads all entities. I've tried changing the submission handler to use the same approach as I used in the form builder. This does solve the memory issue but even at 250 terms causes time outs. For my current project I don't need the reordering So the attached patch just fixes the overview timeout, but I'd rather have a functional overview which allows me access to term edit pages and such than no overview at all.

This obviously needs follow up, but I'm hoping this patch can land and help other people in the mean time.

Status: Needs review » Needs work

The last submitted patch, 33: 763380-33.patch, failed testing. View results

legolasbo’s picture

Status: Needs work » Needs review
FileSize
668 bytes
2.66 KB

Oops, I missed setting the depth.

legolasbo’s picture

FileSize
2.38 KB
3.47 KB

This patch cleans up the code a bit.

timKruijsen’s picture

Status: Needs review » Reviewed & tested by the community

The patch seems to solve at least a part of the issue and therefore I'd say it's good to get this in ASAP. The rest of the problem should be solved in the future.

klausi’s picture

Version: 8.5.x-dev » 8.6.x-dev
Status: Reviewed & tested by the community » Needs work
Issue tags: +Needs tests

Super, the next step is to include a test case in the patch. How can we do a meaningful test?

alexpott’s picture

@klausi fortunately there is some existing test coverage of the pager - \Drupal\Tests\taxonomy\Functional\TaxonomyTermPagerTest and \Drupal\taxonomy\Tests\TermTest::testTaxonomyTermChildTerms() but in the review below I point out one thing that might be improved.

  1. +++ b/core/modules/taxonomy/src/Form/OverviewTerms.php
    @@ -137,7 +137,7 @@ public function buildForm(array $form, FormStateInterface $form_state, Vocabular
    -    $tree = $this->storageController->loadTree($taxonomy_vocabulary->id(), 0, NULL, TRUE);
    +    $tree = $this->storageController->loadTree($taxonomy_vocabulary->id(), 0, NULL, FALSE);
    

    Can be $tree = $this->storageController->loadTree($taxonomy_vocabulary->id()).

  2. +++ b/core/modules/taxonomy/src/Form/OverviewTerms.php
    @@ -402,6 +402,36 @@ public function buildForm(array $form, FormStateInterface $form_state, Vocabular
    +   *   @see TermStorageInterface::loadTree()
    

    This should be at the bottom of the doc block underneath the @return. You can't put @see's every where.

  3. +++ b/core/modules/taxonomy/src/Form/OverviewTerms.php
    @@ -402,6 +402,36 @@ public function buildForm(array $form, FormStateInterface $form_state, Vocabular
    +  private function loadTermsByStubs(array $stubs) {
    

    There's no need for this to be private - should be protected

  4. I've been looking for test coverage that we haven't broken ordering on term overview pages once there is a pager - I can't find any. Can we make sure there is some test coverage - \Drupal\taxonomy\Tests\TermTest::testTermReorder() doesn't invoke the pager.
  5. The test coverage I've found leads me to think that the current Taxonomy overview pager logic is quite flawed. If you look at \Drupal\taxonomy\Tests\TermTest::testTaxonomyTermChildTerms() we testing that the same 12 terms appear on the first and second page. I don't get that. I understand that we want to display all the child terms on a single page but when on the next page too? Lots of interesting comments in \Drupal\taxonomy\Form\OverviewTerms::buildForm() about this. Definitely seems somewhere a javascript based UI that only loaded what's necessary could be very helpful. Obviously this doesn't impact this issue but none-the-less this UI needs work.
legolasbo’s picture

Attached patch addresses the feedback by @alexpott and I fully agree with point 5, this UI needs a lot of work over the course of many iterations probably.

As for adding a test that proves that the memory issue has been resolved, I don't think that's easily done because it requires loads of terms to be created and loaded, which either blows up because of memory consumption or just makes tests run really really long. It's easily tested by hand though.

  1. Clean Drupal install on a server with moderate memory limit
  2. Create 15.000 terms
  3. Open the overview page
  4. BOOM

The last submitted patch, 40: 763380-40-test-only.patch, failed testing. View results

Status: Needs review » Needs work

The last submitted patch, 40: 763380-40.patch, failed testing. View results

legolasbo’s picture

Hmm, I can't get any tests to run locally. (Getting 50X errors when running them through the simpletest interface) and I don't have time to figure out why. I did test the functionality manually and the pager acts as it is supposed to.

Someone else is going to have to add the missing test coverage.

legolasbo’s picture

Status: Needs work » Needs review
FileSize
3.47 KB

After looking into this some more, I found out that pagination with nested terms actually IS tested. See Drupal\taxonomy\Tests\TermTest::testTaxonomyTermChildTerms. I'm therefore re-uploading the patch from #36 and setting this back to Needs Review.

Status: Needs review » Needs work

The last submitted patch, 44: 763380-36.patch, failed testing. View results

legolasbo’s picture

?? Test failed with no failed tests?

alexpott’s picture

@legolasbo there's a problem with bots. In #39 I already pointed out the existing test coverage. But said that it needs to be improved to cover re-ordering terms not on the first page. This is directly related to the patch because it changes how they are loaded.

All the other points from #39 still need to be addressed too.

pdenooijer’s picture

Fixed the code changes from #39, the test coverage still has to be extended. Also did some boy scouting, like setting all unset variables to a default value and changed all the checks to identical. I tried to get the simpletest running, but it keeps failing at \Drupal\taxonomy\Tests\TermTest::testTaxonomyNode as it cannot find the node that is created.

pdenooijer’s picture

Status: Needs work » Needs review
pdenooijer’s picture

Issue tags: +DevDaysLisbon

Version: 8.6.x-dev » 8.7.x-dev

Drupal 8.6.0-alpha1 will be released the week of July 16, 2018, which means new developments and disruptive changes should now be targeted against the 8.7.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

cenoura’s picture

FileSize
3.56 KB

Reroll over 8.5.0 (763380-36 was failing to apply)

lebster’s picture

Patch #52 can't be applied via composer. Updated patch is attached. Tested on 8.6.9.

Status: Needs review » Needs work

The last submitted patch, 53: 763380-53.patch, failed testing. View results

Version: 8.7.x-dev » 8.8.x-dev

Drupal 8.7.0-alpha1 will be released the week of March 11, 2019, which means new developments and disruptive changes should now be targeted against the 8.8.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

jimkeller’s picture

While it's an improvement to not load entities when rendering the tree, this is still a poor solution. The code for loadTree still slurps in the entire table even if you're only showing 50 rows. We have a site with over a hundred thousand terms in a vocabulary (it's storing product serial numbers) and the overview screen throws a 500 due to memory limit (which makes sense).

The overview page needs to be rebuilt using a range() for the query; loading in the whole table here is ridiculous.

For those looking for an interim solution, you can create a view that lists taxonomy terms; it doesn't call loadTree. You'll also want to set the following in settings.php to keep the edit screen from bombing:

$config['taxonomy.settings']['override_selector'] = true; 
pdenooijer’s picture

Status: Needs work » Closed (outdated)

Fixed in 8.7.x/8.8.x dev, so this can be closed.

lhridley’s picture

Status: Closed (outdated) » Needs work

I'm going to reopen.

We are running into this issue on 8.7.3 so I would dispute that this is outdated and that the problem has been addressed. There is no commit associated with the fix, it was simply closed as outdated.

Please provide a link to the relevant "fix" that was included in 8.7 so we can assess whether or not this is still an outstanding issue.

ThomWilhelm’s picture

Yeah same just ran into this same issue on 8.7.3. None of the previously supplied patches apply anymore.

ivelin.enchev’s picture

FileSize
3.33 KB

Reroll #53 for 8.7

Disregard this, as it's from the wrong directory. The below one should be fine.

ivelin.enchev’s picture

pdenooijer’s picture

We do encounter the problem again, so your right lhridley, this is not outdated.

Version: 8.8.x-dev » 8.9.x-dev

Drupal 8.8.0-alpha1 will be released the week of October 14th, 2019, which means new developments and disruptive changes should now be targeted against the 8.9.x-dev branch. (Any changes to 8.9.x will also be committed to 9.0.x in preparation for Drupal 9’s release, but some changes like significant feature additions will be deferred to 9.1.x.). For more information see the Drupal 8 and 9 minor version schedule and the Allowed changes during the Drupal 8 and 9 release cycles.

acb’s picture

I can confirm this is still a problem. esp. with fielded terms

Alex Razumov’s picture

I can confirm. I have the same problem on site with over 30K terms in vocabulary.
Possible solution will be creation of views page for terms overview. In this case all works as expected, but terms manipulation with weight will not work. Also action link "Add new term", term tabs should be rebuilded for views page because route name will be changed.

Version: 8.9.x-dev » 9.1.x-dev

Drupal 8.9.0-beta1 was released on March 20, 2020. 8.9.x is the final, long-term support (LTS) minor release of Drupal 8, which means new developments and disruptive changes should now be targeted against the 9.1.x-dev branch. For more information see the Drupal 8 and 9 minor version schedule and the Allowed changes during the Drupal 8 and 9 release cycles.

nord102’s picture

I'm currently on 8.8.8 and this is still an issue, the patch did not work for me, as I have over 300K terms in one of my vocabularies, I just made a Views page, as others did, to allow to the terms to be paginated and still provide a way to get to the edit page for them without a WSOD

seth.e.shaw’s picture

Currently on 8.9.x and just ran into this issue on a dev site I'm building with 12k terms and no hierarchy. Fortunately upping my max memory was sufficient for now. But I shouldn't have to double my max memory for a single page; not to mention the eventual problem of timeouts as the taxonomy grows (which I'm sure it will).

seth.e.shaw’s picture

I've tested the patch on #61 for 8.9.5 and it works well for me. I realize that the version for this ticket was bumped to 9.x, but I would *really* like it as a bug-fix on the 8.9.x branch. Who do I need to convince to make that happen?

Version: 9.1.x-dev » 9.2.x-dev

Drupal 9.1.0-alpha1 will be released the week of October 19, 2020, which means new developments and disruptive changes should now be targeted for the 9.2.x-dev branch. For more information see the Drupal 9 minor version schedule and the Allowed changes during the Drupal 9 release cycle.

Version: 9.2.x-dev » 9.3.x-dev

Drupal 9.2.0-alpha1 will be released the week of May 3, 2021, which means new developments and disruptive changes should now be targeted for the 9.3.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

jesse_k’s picture

The latest patch did solve the memory issues on Drupal 8.9.14, but we did run into a bug when trying to display terms with multiple parents:

The website encountered an unexpected error. Please try again later.
TypeError: Argument 1 passed to Drupal\Core\Entity\EntityRepository::getTranslationFromContext() must implement interface Drupal\Core\Entity\EntityInterface, instance of stdClass given, called in /app/docroot/core/modules/taxonomy/src/Form/OverviewTerms.php on line 359 in Drupal\Core\Entity\EntityRepository->getTranslationFromContext() (line 99 of core/lib/Drupal/Core/Entity/EntityRepository.php).

Drupal\Core\Entity\EntityRepository->getTranslationFromContext(Object) (Line: 359)
Drupal\taxonomy\Form\OverviewTerms->buildForm(Array, Object, Object)
call_user_func_array(Array, Array) (Line: 532)
Drupal\Core\Form\FormBuilder->retrieveForm('taxonomy_overview_terms', Object) (Line: 278)
Drupal\Core\Form\FormBuilder->buildForm(Object, Object) (Line: 91)
Drupal\Core\Controller\FormController->getContentResult(Object, Object)
call_user_func_array(Array, Array) (Line: 123)
Drupal\Core\EventSubscriber\EarlyRenderingControllerWrapperSubscriber->Drupal\Core\EventSubscriber\{closure}() (Line: 573)
Drupal\Core\Render\Renderer->executeInRenderContext(Object, Object) (Line: 124)
Drupal\Core\EventSubscriber\EarlyRenderingControllerWrapperSubscriber->wrapControllerExecutionInRenderContext(Array, Array) (Line: 97)
Drupal\Core\EventSubscriber\EarlyRenderingControllerWrapperSubscriber->Drupal\Core\EventSubscriber\{closure}() (Line: 151)
Symfony\Component\HttpKernel\HttpKernel->handleRaw(Object, 1) (Line: 68)
Symfony\Component\HttpKernel\HttpKernel->handle(Object, 1, 1) (Line: 67)
Drupal\simple_oauth\HttpMiddleware\BasicAuthSwap->handle(Object, 1, 1) (Line: 57)
Drupal\Core\StackMiddleware\Session->handle(Object, 1, 1) (Line: 47)
Drupal\Core\StackMiddleware\KernelPreHandle->handle(Object, 1, 1) (Line: 106)
Drupal\page_cache\StackMiddleware\PageCache->pass(Object, 1, 1) (Line: 85)
Drupal\page_cache\StackMiddleware\PageCache->handle(Object, 1, 1) (Line: 84)
Drupal\shield\ShieldMiddleware->handle(Object, 1, 1) (Line: 47)
Drupal\Core\StackMiddleware\ReverseProxyMiddleware->handle(Object, 1, 1) (Line: 52)
Drupal\Core\StackMiddleware\NegotiationMiddleware->handle(Object, 1, 1) (Line: 23)
Stack\StackedHttpKernel->handle(Object, 1, 1) (Line: 708)
Drupal\Core\DrupalKernel->handle(Object) (Line: 19)
jesse_k’s picture

I created a patch that fixes the multi-parent issue I described above.

cupcakemuncher’s picture

I am also subscribing to this.
When you have a large vocabulary where the bulk of the terms is located in the leaves of the hierarchy-tree and this tree has 3-5 levels a significant portion of the tree will be loaded for a lot of pages, especially when there are only 1 or 2 root elements.
You do not necessarily encounter WSOD but you will be unable to change the hierarchy via drag and drop using the form.
A submit would display the changes but a following reload or look into the DB-tables will show that the change was not written to DB.

The problem is that the form will always do a recursion until it finds a root element.
I only ran Unit-tests on the patch and based it on jesse_k's patch, but it is meant as a discussion point, because fixed page sizes will allow for more stability when faced with a deep and wide hierarchy tree.
In the example you could still manipulate the tree to you liking, but, admittedly, the usability does suffer without some update to the frontend code.

//Edit
The form will then also suffer from terms who's key is not in the user-input. This will generate a lot of notices
> Notice: Undefined index tid:883883 in Drupal\taxonomy\Form\OverviewTerm->buildForm()(line256 of ......)

//Edit 2:
Please also note: meant as a discussion point only to show how keep the vocabulary editable, the current patch is not stable in regards to the weights ATM. --> changing the hierarchy alters the position in regards to the weights.

cupcakemuncher’s picture

Version: 9.3.x-dev » 9.4.x-dev

Drupal 9.3.0-rc1 was released on November 26, 2021, which means new developments and disruptive changes should now be targeted for the 9.4.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 9.4.x-dev » 9.5.x-dev

Drupal 9.4.0-alpha1 was released on May 6, 2022, which means new developments and disruptive changes should now be targeted for the 9.5.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 9.5.x-dev » 10.1.x-dev

Drupal 9.5.0-beta2 and Drupal 10.0.0-beta2 were released on September 29, 2022, which means new developments and disruptive changes should now be targeted for the 10.1.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 10.1.x-dev » 11.x-dev

Drupal core is moving towards using a “main” branch. As an interim step, a new 11.x branch has been opened, as Drupal.org infrastructure cannot currently fully support a branch named main. New developments and disruptive changes should now be targeted for the 11.x branch, which currently accepts only minor-version allowed changes. For more information, see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

nathandentzau made their first commit to this issue’s fork.

Amavi’s picture

I correct it on my website Drupal 10:

I up the SQL "max_allowed_packet" on my hosting to maximum 64MB and all is oki, it is configured at 1MB basically and too low for Drupal, best ways may be is to write in Tutorial to check this??? I read 8MB is a minimum for Drupal 9....

manojbisht_drupal’s picture

Patch 74/75 is not applying for 10.2, so created a new patch for 10.2

catch’s picture

Status: Needs work » Postponed

I think this is a duplicate of (or technically duplicated by, since the other issue is newer than this even though it's also a decade old) #2183565: Avoid loading all terms on the taxonomy overview form.

Postponing on that issue given it's RTBC.