Come together with the global Drupal community in Rotterdam, 28 Sept – 1 Oct 2026. Sessions, contribution, connection, and Early Bird savings until 8 June.Is there an upper limit for children to a parent node? When sorting 50+ children, the sort order is not maintained. It could seem that 50 is the magic upper limit, but why is this so?
| Comment | File | Size | Author |
|---|---|---|---|
| #3 | nodehierarchy-965490.patch | 817 bytes | markhalliwell |
Comments
Comment #1
ronan commentedThere is no fixed upper limit in the module but it uses the core menu system for storage and that system uses a maximum range of 50 for sorting in the UI, so this is certainly a possibility that you're running into this. I may be able to fix that in my ui, but if you use the core menu system ui (admin/build/menus) then the core code will take over and stop sorting after 50.
Comment #2
achtonNot sure if this is the core UI, but it is visible at
node/<nid>/children. In fact, as the JS takes over the weight dropdowns during page load, the weights are briefly visible, particularly on pages with many children, and here it is apparent that many of the children are fixed at 50.I have hundreds of nodes that make heavy use of NH, and quite a few of them have 100+ child nodes. Are there any workarounds that you can think of right now for that scenario?
Thanks for your response!
Comment #3
markhalliwellFirst, I would like to reference #809468: Redesign children form for usability and permission based management.
There is a considerable amount of work to be done on the children form.
This is a relatively easy fix. This is relative to how the form is rendered and the delta has been limited to 50 when in fact it should reflect the number of child nodes.
Comment #4
markhalliwellComment #5
achtonThis works perfectly. Thank you for the swift help.
Filing as a bug report, since there's a patch involved, hope that is correct.
Comment #6
dgorton commentedThis is really straightforward. Has anyone tested with large numbers of children? At one point in time (maybe a few years ago?) we had issues with large numbers of children (e.g. several thousand children on one parent). That required some work in different places and I honestly don't know how that may be impacted here (or even if it's still relevant). So - it would be great to try that code against large sets of children to make sure nothing explodes.
Comment #7
achtonWell, I've not tested this patch with thousands of children, but certainly in complex scenarios on several occasions with hundreds. On that account, I'd say this is RTBC for the dev version. If anything, that may expose any edge case issues that may remain.
What bothers me though, is that this is not a common problem. But I suppose an upper limit of 50 children is sufficient for most use cases (it seems so).
Comment #8
ronan commentedThis is a pretty good fix, but it's not more than a stop gap since it's not really scalable. If you think about a situation where you have 100 nodes, you are generating a page with 100 items each of which has a pulldown containing 200 items in it (-100 to 100). Then you're manipulating that with javascript. That's a lot code to push at the browser and a lot of processing for it to do. If you have 1000 nodes it's 1000 x 2000 which will probably bring your computer to it's knees.
We should, at a minimum, be able to switch the pulldown to a text field, and possibly even come up with something that lets us scale to thousands of children per node. Pagination is the usual fix for that problem, but sorting and paginating don't go too well together.