Vocabulary consisting of set amount of parents and a lot of children breaks pagination

I can confirm that we're seeing the issue as well with a top level item with a lot of children.

In our case, changes to the page don't save.

I've got the same issue, only it's worse because I'm looking at ~2000 children split over 5 or 6 levels.

All these are contained within 3 top level parents and actually causes the browser to freeze for long periods of time as it init's the drag and drop.

I believe this a functionality breaking bug for some use cases and should be considered more important than 'Minor' as it renders the interface completely unusable for large hierarchical taxonomy (like categories). I'm bumping to Normal in the hope it gets some more attention.

There should really be a separate vocabulary configuration option available which allows only one level of terms to be displayed at a time, perhaps showing the number of children contained underneath and the option to dig down to the next level or navigate back up to a higher level within the taxonomy.

Does anyone know of a contrib module which solves this problem?

EDIT: taxonomy_manager seems to do a pretty decent job at solving this, but it would still be nice to have something included in the core.

I spent some time looking into this and I agree it does run painfully slowly when a large number of subordinate terms are linked. The code section in question does indeed ensure that the tree rendered to the page must start on a root item.

Design-wise, I could see a solution where we permitted a continuation of listings on a subsequent page, such as:

<page 1>
Category 1
  {...items 1-10 out of 10}
Category 2
    {...items 1-90 out of 140}

<page 2>
Category 2 (continued)
    {...items 91-140 out of 140}

That would not be too difficult to accomplish, but I see 2 major issues with the design:
1) Re-ordering weights via dragging would not be workable. Granted they would work super-slowly with a large data set, but they would not work at all if the page truncates the list.

2) Multiple layers of nesting would be visually confusing. The above example isn't awful, but what if we ended up in a place where we had this:

<page 5>
Category 2 (continued)
  Subcategory 3 (continued)
     Sub-subcategory 1 (continued)
        {...items 18-118 out of 130}

That would be pretty nightmarish, if rare.

The way I see it, what we have may be the least-worst scenario already. taxonomy_manager may be the best way to go for edge cases.

The one thing I would point out, though, is that the pager is currently buggy. If you have 1000 sub-categories nested in 2 categories, and a max of 100 records per page, you get a pager with 11 pages, all of which have the exact same content on them, because apparently the pager just divides the number of records total by the number per page. Clearly it would be better if we ensured that the 2 root categories ended up each with their own page and only had 2 pages in the pager.

I am having the same issue as well. Any solutions or patches?

Bumping into this as well.

I can confirm this bug as well.

I have 200+ parent terms and have 21000+ its child and its child (3 Level). The pagination is correct.
One parent has 1050 child+sub-child. This parent located on /admin/structure/taxonomy/manage/VOCAB_NAME/overview?page=48 and all 1050 terms is rendered on the same page.

Technically, 1050 terms should have 11 pages in pager and 1st page starts at /admin/structure/taxonomy/manage/VOCAB_NAME/overview?page=48 for this parent. These 1050 terms repeats on the next 10 pages as well until we reach at 58.

Looking forward from the community for solution.

As #3 said

this a functionality breaking bug for some use cases and should be considered more important than 'Minor' as it renders the interface completely unusable for large hierarchical taxonomy.

This issue should not be on Normal priority. We should consider it as critical.

https://www.drupal.org/core/issue-priority has the criteria for issue priority. Given this is causing browsers to lock up on those pages, it can probably be considered major, but given it's isolated to one admin page, it would be more properly normal. Moving to 'major' for now.

Note that there are contrib modules that replace the taxonomy administration interface like https://www.drupal.org/project/taxonomy_manager

This probably can't be fixed without a complete refactoring of drag and drop hierarchy.

Bear in mind that https://www.drupal.org/project/taxonomy_manager is currently not being properly maintained in D8 afaik.

For example https://www.drupal.org/project/taxonomy_manager/issues/3046752 which makes the module pretty much unusable for fielded terms has been opened for a year.

Can also confirm this is an issue on parents with several hundred children.