revolution
revolution copied to clipboard
modxcms
Update subMenuBuilder so "installer-entry" is always at the top
Due to the default-value of menuindex in menu-entries of newly installed extras being most of the time "0", the installer entry will jump up and/or down after an extra gets installed/updated.
Therefore it should at least be fixed at the bottom of the dropdown-menu.
Fixes #11694 pragmatically
With all due respect and appreciation for opening a PR, I don't consider putting it at the bottom an improvement. Posted an alternative suggestion in the issue.
Changed the behavior to suggested one.
@sebastian-marinescu did you look if this was possible?
What I'd suggest we try (I haven't looked at the relevant code yet) is to add some extra code into the menu builder that makes sure the installer is always first.
Something like an
ORDER BY field(modMenu.key, 'installer') ASC(but in xPDO) before the menuindex sort is applied.
Originally posted by @Mark-H in https://github.com/modxcms/revolution/issues/11694#issuecomment-472009581
Hey @sebastian-marinescu - did you determine sorting in the SQL as I suggested wasn't possible and that the html-replacement technique is best? Just hoping for some feedback from you here as I'm not clear on what this PR is at and 2.7.2 is coming soon.
Even better would be to make the installer/updater scripts NOT CHANGE the menuindex on already installed items. Every time an extra gets updated, its position in the menu changes. Whatever order has been set by users should be retained after updates. New extras could go at the bottom, and then people could drag them where they want in the menu.
The same thing goes for menu parents. For example, I use the ClientConfig extra, and it makes the most sense to me and my clients to keep that under the Site (Content) menu. Every update moves it back under the Extras menu, and I have to move it back where I want it manually.
That's not something the core does - that's each extra saying their menu object should be updated.
@Ibochkarev In the related issue I posted an alternative solution before this PR was created that handled it in the menu generation and I've asked if @sebastian-marinescu tried that or not. If my idea, which seems like a cleaner solution, was not feasible I'd happily merge this but I'm not sure if it was tried.
Sorry for ghosting people.
I just wasn't sure back then where/how the menu gets grabbed. Trying to re-track it, I think I found it:
-
The modManagerController loads the header, which is just an include of the header.php in the default manager-theme
-
Inside the header.php the
buildMenu-method gets the menus from cache -
If it's not already cached, it rebuilds the menu-cache
-
Inside the
getSubMenus-method it sorts bymenuindex
So this is where you would add an extra sort-criteria @Mark-H ?
$c->sortby($this->xpdo->getSelectColumns('modMenu','modMenu','',array('menuindex')),'ASC');
FYI: @Ibochkarev
So I think I found the solution and pushed it to my patch-3 branch - but it doesn't show here on the PR like it used to do...
Anyone any idea how I can update the commits here?
Oh okay, the friendly cla-bot unfroze the situation - nice :) Hopefully this is the right way now @Mark-H @opengeek
Would it be possible to have folders first (maybe by an option)?
I'm not sure I understand. Do you mean for the two entries in "Manage"?
Would probably be possible, by checking if it is a parent - but I don't want to mix this PR up: I just want the "Installer" entry to not jump around anymore, and I'm hoping to get that into the next release.
I often put folders first in the Extras menu to avoid things like in this screenshot at the bottom of the browser window.
With your patch a submenu could start only at the second entry, which is a little less space to the bottom. it would be great, if entries with a submenu could stay in the before the Installer (by enabling a system setting).
With your patch a submenu could start only at the second entry, which is a little less space to the bottom. it would be great, if entries with a submenu could stay in the before the Installer (by enabling a system setting).
Maybe we should add this fix to the 2.x branch - https://github.com/modxcms/revolution/pull/14300? And for 3.x right away.
With your patch a submenu could start only at the second entry, which is a little less space to the bottom. it would be great, if entries with a submenu could stay in the before the Installer (by enabling a system setting).
@Jako I see now, thx. So your setting should/would only be relevant to the "Extras" main-menu or to all? And while I understand your use-case, I'd still be in favor of having the "installer" as first, always - then your special-folders. It would still work.
Another thing I wanted to point out is, that your component descriptions take a lot of space away - maybe you could check out "AdminTools", which hides the descriptions and therefore gives much more space:
I really don't understand why the consensus is that the installer should always be at the top. Once a site is set up, that is going to be the LEAST USED item in the list. Putting it at the bottom, or else just sorting it like everything else, makes a lot more sense to me.
Once a site is set up, that is going to be the LEAST USED item in the list.
Personally, I am enraged that the "Installer" jumps in menu :) And while you set up the site once, you get tired of looking for the installer in the menu.
Once a site is set up, that is going to be the LEAST USED item in the list.
Personally, I am enraged that the "Installer" jumps in menu :) And while you set up the site once, you get tired of looking for the installer in the menu.
If it's sorted alphabetically, you can find it. If it's always at the bottom, you can find it. When everything is jumping around, as they do now, you can't find any of the plugins, including the installer.
If it's sorted alphabetically, you can find it. If it's always at the bottom, you can find it.
- Alphabetically, it is located only for the English language.
- The bottom location is not convenient, because the menu item can be clipped by the screen (@Jako pointed out about this above).
- Positioning on top is the most effective UX option, in my opinion.
If it's sorted alphabetically, you can find it. If it's always at the bottom, you can find it.
* Alphabetically, it is located only for the English language. * The bottom location is not convenient, because the menu item can be clipped by the screen (@Jako pointed out about this above). * **Positioning on top** is the most effective UX option, in my opinion.
If it gets clipped by the screen at the bottom, then moving it to the top will make something else get clipped by the screen instead. That's a separate issue, which also needs to get fixed. As for alpha sorting, the sorting would have to be done depending on the language selected for the manager itself. There is a separate thread, I believe, asking for alpha sorting of plugins rather than using menuindex as is now done, and which is responsible for making the menu a mess since the menuindexes get reset with every update. Any custom permission you've put on a plugin also gets wiped out when the plugin is updated, which is yet another issue.
Why can't we just install a system setting to determine where to put the installer, instead of trying to force everyone to have it in the same place?
Or, better yet, why not just remove the possibility for package updates to reset the menuindexes at all. That would fix everything, and everybody could position the plugins and installer exactly where they want them, without them jumping around after every update.
As for alpha sorting, the sorting would have to be done depending on the language selected for the manager itself.
Sorting will be done by lexicon key, not translation. Make sorting by translation - is a difficult task.
Why can't we just install a system setting to determine where to put the installer, instead of trying to force everyone to have it in the same place?
In my opinion, the fact that the menu will be on top suits most of the users (based on the discussion in the issue/PR), I didn't think there would be any disputes :)
I really don't understand why the consensus is that the installer should always be at the top. Once a site is set up, that is going to be the LEAST USED item in the list. Putting it at the bottom, or else just sorting it like everything else, makes a lot more sense to me.
@rainbowtiger I strongly disagree, as it still remains the most important menu-link inside the components-menu (e. g. for maintenance/updates or by the fact that a website is constantly growing and in need of new or swapped extras over time). The corresponding issue #11694 has been around for years, and the consensus is clear.
That's why I also feel like @Ruslan-Aleev when it jumps around.
Personally, I am enraged that the "Installer" jumps in menu :)
And as it is the most important link, putting it as first is a good choice for UX, as also pointed out.
However, you have valid points in your comment about the different other issues, especially that maybe the rest of the menu should be sorted alphanumerically and not by menuindex 👍
Top +100. After you have set up a site you should still maintain your extras and keep them up to date. This makes that ever-so-slightly less inconvenient.
I doubt a discussion about its location would have ever cropped up had it been pinned at the top from the beginning.
As for alpha sorting, the sorting would have to be done depending on the language selected for the manager itself.
Sorting occurs by lexicon key, not translation.
If plugins were to be sorted alphabetically, they would be sorted by the lexicon values (the translations), not the "keys". No menus are sorted this way now, so this would have to be an added feature. The complexity of this approach is just another good argument for preventing plugin updates from altering the menuindexes at all, so that nothing would jump around after an update.
I strongly disagree, as it still remains the most important menu-link inside the components-menu (e. g. for maintenance/updates or by the fact that a website is constantly growing and in need of new or swapped extras over time).
Keeping plugins updated is what is important, not the location of the installer menu item. It you know where that menu item is always going to be, regardless of location, then what's the problem? Adding or swapping plugins over time is a very occasional need. I use SiteDash to do my plugin updating across all sites, so it's not AT ALL important to me to have the installer at the top of the menu in individual sites. An intuitive and useful menu arrangement for my clients is far more important to me. I want to be able to find ALL of my plugins easily, not just the installer. And, I would argue that other plugins in my sites are just as "important" as the installer.
However, you have valid points in your comment about the different other issues, especially that maybe the rest of the menu should be sorted alphanumerically and not by menuindex 👍
Actually, alpha sorting is only a second-best option, as far as I'm concerned. Leaving the menuindexes alone is by far the most preferable, because then everybody could set up this menu however they want, and nothing would shift after updates. "Creative Freedom", right? For example, if I have a client who uses a particular plugin every day, I want that to be at the top of the menu, not the installer or some other plugin that comes before it alphabetically.
I realized this PR is still open, so I attempted to add a new system-setting package_installer_at_top, which puts the installer-menu-entry at the top, if activated.