Hmm would this be not more a extension resposibility? IMO not the menu should take care of that kind of things.

The way I'm reading this is basically to start making admin menu items behave the same way as frontend menu items with regards to their parameters.

Yes if the admin menus allowed config options like the frontend but at present they do not. I'm currently talking about com_content.

On 4 Aug 2017, 12:32 +0100, zero-24 notifications@github.com, wrote:

Hmm would this be not more a extension resposibility? IMO not the menu should take care of that kind of things.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub, or mute the thread.

Honestly, I would be very careful about making some of the frontend behaviors available in the backend. Implementing this change makes us VERY close to having Itemid on backend routing.

Ok ok, so let's go for a less usable approach but a better approach and have an additional query string box? So we could enter catids or native filtering into the URL? Without the need to just create external URLs for the whole menu admin.

On 4 Aug 2017, 12:37 +0100, Michael Babker notifications@github.com, wrote:

Honestly, I would be very careful about making some of the frontend behaviors available in the backend. Implementing this change makes us VERY close to having Itemid on backend routing.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub, or mute the thread.

No matter the solution if you incorporate it into the menu manager each individual component and its MVC pieces has to be updated to read the data and apply it. Which is also going to mean tracking whether a specific menu item was loaded which has a specific configuration, hence the Itemid thing. And honestly, a "append query string" input would probably not pass most usability tests as most people wouldn't understand how to construct those values (that's why we have all the form fields to do that in the first place ? ).

It's not that the idea is bad, but looking at the actual implementation of it, how close does this leave us to dealing with all the complexity of the frontend routing in the backend (including handling having the right routes built consistently, ensuring the correct parameters are merged in the right order in the right places, etc. etc.)?

I was thinking of keeping it simple for the building of the URL. The biggest issue with the frontend routing is SEF. We have to build and parse the URL structure. In the backend it wouldn't matter anywhere near as much?

Just a thought given how flexible the backend admin menu could be opposed to at the moment it's just a reordering of items.

On 4 Aug 2017, 12:45 +0100, Michael Babker notifications@github.com, wrote:

No matter the solution if you incorporate it into the menu manager each individual component and its MVC pieces has to be updated to read the data and apply it. Which is also going to mean tracking whether a specific menu item was loaded which has a specific configuration, hence the Itemid thing. And honestly, a "append query string" input would probably not pass most usability tests as most people wouldn't understand how to construct those values (that's why we have all the form fields to do that in the first place ? ).
It's not that the idea is bad, but looking at the actual implementation of it, how close does this leave us to dealing with all the complexity of the frontend routing in the backend (including handling having the right routes built consistently, ensuring the correct parameters are merged in the right order in the right places, etc. etc.)?
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub, or mute the thread.

It would still not have the SEF part unless we REALLY want that kind of URL structure for the backend, but at least the admin router would have to add the logic so that JRoute::_() calls resolve the correct menu item consistently (and the noted pieces of ensuring menu item configs get loaded in at relevant spots).

I can see real value in being able to create a menu item called Blog that would go directly to the article manager with blog category filter selected.

exactly @brianteeman, even if it's merely just setting the default filters on load of that menu item. Since we have the filters built in. In my case now we have custom fields I am trying to get my clients to go native core. Since they are relatively small site clients with no more than a few thousand pages.

So to have their blog on the backend and showing it pre-filtered etc will make their life massively easier. With it showing all articles by default is becoming somewhat troublesome for them to understand by default.

In case it's not clear, I never intend to sound like I'm shooting down things, unless I'm pretty much explicitly saying "this is a bad idea and why". In at least this case I'm just trying to point out technical challenges to reaching the desired end state.

I fully appreciate that @mbabker :D.

Lets simplify this... Can we then allow 'Filter options' to be pre-loaded into the Admin Menu Item? All this would do is preset the filtering? for example:

administrator/index.php?option=com_content&filter.category_id=14

Works perfectly. Even if it's only handled for com_content for now.

For reference I am already doing this on a client site but I had to use the External URL and set it up manually

Same here, I had to build all them manually pretty much. But a simple select field that chucked it into the route... would be fab

On 4 Aug 2017, 17:07 +0100, Brian Teeman notifications@github.com, wrote:

For reference I am already doing this on a client site but I had to use the External URL and set it up manually
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub, or mute the thread.

I just scratched the surface with my personal tests, but my first thoughts were very similar to @tonypartridge 's. Somehow I expected more parameters, but I also understand the technical concerns made by @mbabker .

Although I am a big fan of J! frontend submission, I would use the new backend menu feature to build an easy client/manager UI. The client should get a tailored dashboard and menus. Not too abstract and general, wording and titles should match his business terms and he should reach his tasks with "1-click".

The current admin menus seem to fit best into the TOP MAIN menu, including subitems. Current code and markup seem to be "optimized" for dropdown support etc.

Unfortunately, it's almost impossible to create other menus. At least it is not easy to create a CPANEL sidebar menu with icons, nor QUICK ICON menus. I had to play with Alt-Layouts and Module-Chrome to get close: (see screenshot)

The latter ones would really benefit, if there were support for the supplied parameters in tab LINK TYPE. Currently they are not used. Those custom CSS CLASSES, LINK IMAGE would help a lot: (see screenshot)

The separator and heading types do not appear at all.

The URL type is the most useful item to reach specific targets. The manual link building is a bit cumbersome and techie though. A simple wizard or constructor would save time, but also bloat things up.

Overall the custom Admin menus have great potential. It just needs more "love" ;)
Customization options beyond the typical main menu usage:
Link type param output, maybe a different Chrome and Alt-Layout in core.

Thanks for reading.

I agree with @pepperstreet I think we need to take a long look at how this can be improved from a logical code stand point. The way I am also having to build multiple menus etc for clients when it could be done much easier with a little ACL and the odd config option.

Closing as #20890 addressed this request.

Set to "closed" on behalf of @jwaisner by The JTracker Application at issues.joomla.org/joomla-cms/17407