When I go to admin/content/category/### (where ### is container ID - this is via the links "list categories" for each container), the pager behavior is obviously wrong. It gives several pages listed in pager, but I see all categories shown together on the first page. After clicking the pager, only START of the listing moves, the END is always at the very last category. In other words, the rendering starts correctly, but never stops (until the total end is reached).
This denies the very purpose of having a pager (i.e. to make it scalable to huge amount of categories), and the behavior is the "obviously broken" kind.
I found the problem at the line, where custom pager code counts root level elements, checking for their parent ID being zero. This finds nothing, since no such categories exist: The parent is either another category, or the container being listed. With a check for the listed container ID, the pager works just fine (including the adjustments to keep the sub-trees together).
But however, after this fix, the categories-per-page constant really comes into the game, revealing that 10 per page is a crazy low amount for any effective management of larger containers. I changed that to 25 per page, which looks reasonable (doesn't make JavaScript unresponsible even on my VERY slow computer - I would say even 50 per page might be safe).
I'm a little unsure about multiple parents (may it catch a category somewhere down in the tree, that have the container as its second parent?), but even if there's some problem with that, it won't cause anything worse than the list being less extended, without any serious harm (everything still accessible through the pager), am I right? This is a rare case, while the most common case of a plain single-hiearchy tree is fixed by this patch.
| Comment | File | Size | Author |
|---|---|---|---|
| category-admin-pager.patch | 1.04 KB | JirkaRybka |
Comments
Comment #1
Jaza commentedCommitted to HEAD. Thanks.