Both items get reordered as planned.
One of the moved items is not placed in the correct position
OR
the whole submenu level is messed up and the items are in wrong order.
Apache/PHP 5.5/Jomla 3.3.3
The drag and drop triggers an AJAX request that starts a fairly long-running series of SQL queries (10-15 seconds). If the second reordering is performed while the queries are still running, the final result is not always correct.
The queries are of the type:
UPDATE #__menu SET lft = 4239, rgt = 4250, level = 3 path = 'something/something....
I don't like either of these two options, because both of them assume there is only one active user dealing with the menus.
Is it really necessary to go through the entire menu tree just to move one menu item from one place to another? If the same change is done by opening the menu item for editing and changing the value in the sort box, no such reordering process is triggered.
This comment was created with the J!Tracker Application at issues.joomla.org/joomla-cms/4303.
Quoting:
"assume there is only one active user dealing with the menus"
-- but the way ordering is done now this assumed already, please correct if i am wrong i have not researched it much but:
-- if you have menu list open and some other user changes the order of the menu,
your view does not get updated, the current solution ONLY saves your new order, it does not reload page (or update page via JS according to AJAX response) to show you the change of order done by someone else, so the someone else editing menus has an even worse effect ?
Also consider the big impact on server load of current solution, imagine reordering many items at once on large menus
Labels |
Added:
?
|
The same seems to be happening with ordering sub-categories some levels down.
Commenting out /media/jui/js/sortablelist.js:65 (//root.hideSameLevelChildrenNodes) fixes it here, maybe it's related?
I've posted a bug that can be related. Subitems loose parents while drag and drop
I'd like to second the performance issue presented in the comments. We have a site with over 3,000 menu items. Duplicating menu items, or re-organizing menu items is getting slower and slower. Since our users can create menu items, we will run into a point where this needs to be re-written. We experience this issue on every system we are running. Each is a flavor of Unbuntu, some running Apache, some running Nginx. The issue is the same on all systems.
Hi! You created this issue sometime ago but have not provided any code for people to evaluate. As no one else has shown any interest in providing the code and you have not then I am closing this issue at this time. If code is provided (a pull request) it can always be re-examined.
Status | New | ⇒ | Closed |
Closed_Date | 0000-00-00 00:00:00 | ⇒ | 2016-05-08 14:13:49 |
Closed_By | ⇒ | Kubik-Rubik |
@Kubik-Rubik What code do you expect? It's not a dev issue, but user issue....
Hello
i was wondering if this would give problems, wondering if this would result in RACE conditions, and it does !!!
i guess the queries are long because the menu have a tree structure unlike articles
and when multiple ordering are running or if server is loaded it makes it even more worse
i see 2 solutions:
-1- block the user until 1st ordering has finished (not acceptable would be very slow for the user)
-2- or save only once when user is done with page reload
(this is what we have done in a component of ours)
this can be made user friendly by open a small popup (half a second at the corner of the screen asking the user to save when done)