i am using drupal_add_tabledrag and weight fields on a very large form page to order the items, around 500 items right now, it works fine for a lower number
having more items added, the load time and memory usage increases exponentially, after the page is loaded, jQuery will also make the page unresponsive
At least part of the problem is that weight fields are select fields with potentially thousands of options; not only does this cause resource limits to be met - but even before this point the select widgets become unusable manually never have a benefit when the field is hidden with javascript.
to fix it, i can use textfields instead of weight fields, and the drag handles will work correctly, the other problems go away as well, and you can still use the interface without javascript, granted you need to write the weight manually in the text fields
you will also need to provide some validation for the textfield
ive created a test module to see this happening and the fix, you can download it from here
| Comment | File | Size | Author |
|---|---|---|---|
| #7 | weight_does_not_scale-941310-7.patch | 6.22 KB | idflood |
| #6 | weight_does_not_scale-941310-6.patch | 6.22 KB | idflood |
| #4 | weight_does_not_scale-941310-4.patch | 659 bytes | idflood |
| #1 | wieght-does-not-scale-941310-1.patch | 675 bytes | seanburlington |
Comments
Comment #1
seanburlington commentedI ran into this via a large taxonomy #1241654: Reduce memory usage of taxonomy terms overview page
one solution I proposed there is to reduce the size of the options array.
But on reflection I don't see the need for a select box at all
given issues like #491022: Remove weight field from menu item entity forms
It seems there is a push to hide this UI element and mainly rely on the javascript sorting option.
In the case that a user falls back to non-js sorting textfields still work and will do where a select box with thousands of options becomes unusable.
The attached patch makes all weight fields into textareas.
This seems to work for me (js and non-js)
I suspect some additional validation would be beneficial - and I'd be happy to work on it if this appraoch is likely to be acceptable as a bugfix on Drupal 7.
Comment #2
idflood commentedsubscribing
Comment #4
idflood commentedI've tested it a little, seems to be working well. Here is a simple reroll.
edit: there will certainly modifications required in tabledrag.js. It's working, but the weight doesn't behave exactly like before. There is some "reset weight" missing that leads to bigger and bigger weight. Take the last menu item of Navigation and move it at the top. With a "select" weight it will have -50, with "textfield" it will keep it's actual weight.
Comment #6
idflood commentedSame patch as above. This one also contains fixes for the tests. Mainly had to change the asserted number of textfield and the assumption that weight is a select.
Comment #7
idflood commentedwrong version, patch is against 8.x
Comment #9
idflood commented#7: weight_does_not_scale-941310-7.patch queued for re-testing.
Comment #10
idflood commentedI did a little performance test before and after patch #7.
1000 terms (admin/structure/taxonomy/tags)
before: Page execution time was 32583.82 ms. Memory used at: devel_shutdown()=76.3 MB, PHP peak=181 MB
after: Page execution time was 1118.51 ms. Memory used at: devel_shutdown()=19.17 MB, PHP peak=24.25 MB
Comment #11
pfrenssenMarked #1241654: Reduce memory usage of taxonomy terms overview page as a duplicate of this issue.
Comment #12
xjmThis is a duplicate of #1346760: Add a scalable weight select element.
Comment #12.0
xjmadding to the explanation if the problem with select fields