Add additional parameters to the url to simplify navigation in the manager panel

[Ruslan-Aleev]

From a recent time Google Chrome (maybe other browsers) to save RAM clears tabs in the background, i.e. when you open the background tab - the tab updates content completely. MODX navigation is built on tabs and filters and happens that tabs and filters are reset if you work with several tabs.

It's worth adding parameters to the URL to save the filtering and the active tab, for example: Settings:

Resources:

Lixicons:

The parameters will allow to share specific links with users and improve the documentation for MODX - you can specify a link to the section, for example, "Friendly URL" in "System Settings": site.com/manager/?a=system/settings&filter-area=Friendly%20URL

p.s. Perhaps there were discussions about the parameters, I did not find it in the issues.

[mrhaw]

For reference: Action List modAction

[JoshuaLuckers]

Great proposal. Especially the one where it remembers which tab you are on.

It would be a nice to have this in MODX 3.

[GulomovCreative]

Addition: Limit of per page

[Ibochkarev]

Added #15086 @modxbot close

[Ibochkarev]

@modxbot reopen

[Ibochkarev]

Done.

[Ruslan-Aleev]

Some sections have not been completed yet :) Let the issue be open

[smg6511]

@Ruslan-Aleev - I'm bringing over our conversation about the “remembering” of tabs from PR #15935, where you’d asked if I could help out on that aspect of your proposed functionality. You were looking for a global solution, but I need to get clear on exactly what behavior you're looking for. My assumption was that on your PRs related to making grid filtering available/remembered via the URL, and where those grids are on a panel other than the first one, you needed a way for the grid tab to be selected upon accessing or re-accessing the page (having the new URL params). But I get the feeling after our conversation so far that I'm not completely connecting with what you're envisioning. Please outline in a bit more detail what you're looking for and I should be able to help getting it done.

Also, one thing I don't know how to do (or if it's possible) is suggest new code in your PRs. I pulled your PR for the plugin page (#15935,) and made an addition in there, but don't know how best to share that with you. Depending upon whether the solution to what you're looking for can be implemented globally, I may need to submit additions to individual PRs.

[Ruslan-Aleev]

@smg6511 I don't know if it is possible to implement this in extJS, but how do I imagine it in general:

1) All IDs (classes) of active tabs must be passed in an array in a separate url parameter, for example, &tabs=modx-tree-element,modx-plugin-sysevents,... This url contains the tree tabs ("Elements") and the plugin form tab ("System Events"), see the picture.

2) When you click on the tabs, the IDs of the tabs are changed / added to the url separated by commas (or otherwise).

3) Alternatively, only tabs whose activity differs from the default tabs should be passed to the array of tabs IDs. For example, when editing a plugin, the "Create/edit plugin" tab is active by default, its ID does not need to be passed to the parameter, but as soon as we click on another, for example, "System Events", the ID of the "System Events" tab will already be passed to an array of tabs in url.

4) Perhaps, we should not take into account the resource tree tabs and pop-up windows, but only pass the ID of the grid tabs and editing forms.

5) When open/updating a page with a &tabs parameter in the url, the script iterates over the passed array of IDs and sets the activity of the tabs with these ID (like .click()).

I hope I have explained the point :) Maybe there is a simpler and clearer variant, I just explained my vision.

[Ruslan-Aleev]

Also, one thing I don't know how to do (or if it's possible) is suggest new code in your PRs. I pulled your PR for the plugin page (#15935,) and made an addition in there, but don't know how best to share that with you. Depending upon whether the solution to what you're looking for can be implemented globally, I may need to submit additions to individual PRs.

I also don’t know how to transfer your edits to my branch, I tried earlier - it didn’t work. But I don’t think it’s worth adding tab accounting to a separate PR. After all, the PR was about filters in url, and clicking on a tab is not difficult. Perhaps I will raise the discussion in PR, because even the current version (excluding the tab) solves this problem and improves the current state.

[Jako]

I have some different approach:

• each tab group has an ID (i.e. modx-plugin-tabs) that can be referred in the url as property, the value is the active tab (ID or number - I prefer an ID).
• each tab group can have an option that adds a tabchange listener (if none exist - maybe it can be extended), that changes the url property value.
• the same option will trigger opening the right tab on load.

This would create longer urls, but not all tabs have to use that option and it would avoid to look if there is a duplicate tab ID somewhere.

[smg6511]

OK, I think what you want to do is pretty clear. Now my question is why? I'm asking this seriously, not with any judgement or position on the matter. Depending on your motivations/use cases, there may be a better way overall to tackle this. And, I'd like to avoid creating big, ugly URLs if possible.

[Ruslan-Aleev]

Now my question is why?

Doesn't the issue describe "why"? At a minimum, to share a page with a specific active tab (or filters) with someone. Or specify a specific tab in the documentation. Or specify the link with the active tab (filters) in the menu for extras. Or load a specific page tab when re-opening it from the background (if the page was unloaded from the browser memory). Etc.

Those here the goal is not to solve any specific problem, but to add a global functionality for catching filters, tabs (pagination in the future) based on the url.

[smg6511]

Ok, just trying to be crystal clear about the needs of the feature you want. If it weren't for the desire to provide direct links to specific editing views/states to be shared or used in what I assume is in-manager documentation/help, I would've gone the route of making views cacheable/saveable to and retrievable from local storage. But it looks like persisting the view via the URL as you've been doing is the only way to go.

This definitely can and should be done within Ext; how abstracted the code can be to implement this globally is the question. I'd anticipate being able to provide some global methods in the main MODx.FormPanelclass, but probably having to create listeners in each of the child panel classes. As @Jako mentioned, for tabs the id would be the reference of choice as the indexes can sometimes shift (depending on how the tabs are ranked).

I'll look into it further over the next week or so...