pagetree->expand branch destroys parts of BE_USER->uc
Clicking "expand branch" twice in a huge pagetree expands all pages (~thousand in my case). Besides the fact that this feature does not make much sense in a huge pagetree it resets parts of the saved settings in BE_USER->uc which is quite anoying.
make some changes in the "user settings" module that differ from the default values, or click some of the checkboxes below the list module (e.g. enable the localisation view)
Then click "expand branch" twice in a huge pagetree. When you think the pagetree is fully expanded reload the list module or check the values in user settings.
All changed settings are set back to their default values.
(issue imported from #M17396)
Updated by Rupert Germann about 13 years ago
while analyzing some queries in BE I found a possible reason for the broken/resetted uc:
with a fully expanded tree (1000pages + ) the Pagetree tries to write roughly 90KB Data in a mysql TEXT field (allowing only 64KB)
But please don't "fix" this by just enlarging the field to mediumtext.
the question is, why is the pagetree writing a serialized array with 89348 entries for ~1000 visible pages?!
Updated by Jo Hasenau over 12 years ago
- Target version changed from 0 to 4.5.4
Since we had similar problems with a project having > 10.000 pages we started investigating on this issue.
The current version of the state provider creates a key/value pair with the ID of a node as the key and the full path to this node as the value.
mp-0-12345 = /mp-0-0/mp-0-1/mp-0-12/mp-0-123/mp-0-1234/mp-0-12345
When the user does a relogin this information will be used to create the last visible representation of "his" tree via ExtJS' expandPath function.
Of course this generates a huge overhead on the DB-side since a string like that has to be kept for each and every visible node, on the other hand it generates the same overhead on the client side, since these strings are kept in memory, while ExtJS handles the tree for the user.
The first thing we changed was the ID itself, since it always contains the "mp-0-" part even if there are no DB mounts at all. We changed it to "p12345" for pages without any mounts and "p12345-123" for pages belonging to DB-mount 123, so we can still be sure to have unique IDs but with less overhead.
After that we reduced the stuff to be kept in memory and to be saved to BE_USER->uc by cutting off the path completely. Instead the key/value pair now looks like this
p12345-123 = 1
and for pages without any mount it's even shorter
p12345 = 1
This will reduce the overhead significantly especially for deeply nested page trees.
We were able to do so because we found out that it's just not necessary to save the full path for each node. Instead it is much easier to expand nodes recursively while opening the tree, since you just have to call the restoreState function on each expand.
This way you make sure that the tree checks for new IDs that have been loaded during the last expand action and expands these as well, if they can be found in the array of visible nodes.
We still have to change the field type from TEXT to MEDIUMTEXT or maybe even LONGTEXT to make sure it can take even a few thousand entries with larger UIDs, but we were able to make a really large tree usable this way.
Currently we are investigating if there might be any side effects, but it looks promising. So hopefully I will be able to provide a patch until tomorrow afternoon.
IMHO this is a bug that must be fixed even in 4.5.x since the current version makes the system unusable for users with large pagetrees especially when these trees have got a deeply nested structure, which is why I set the target version accordingly. Someone should change it to "must have" as well.
Updated by Jo Hasenau over 12 years ago
It could even be useful to convert the uids used to create the ID of the page tree entries from DEC to HEX to reduce the length of the generated strings up to 50%.
And we could even get rid of the "p" since this doesn't have to be saved to the DB at all, because it is just necessary for W3C compliance of the HTML-Attribute and therefor can be added while rebuilding the tree.
Updated by Stefan Galinski over 12 years ago
Wow, that sounds like a real performance booster patch as this is also a show-stopper while using mobile devices. Performance improvements are definitly allowed to go into the 4.5 branch, so don't hesitate to add this to the "Release" tag of your review request.