It would be a welcomed improvement.

When you remember the old tools from the JXtended Guys, where of one was the AdvancedAdminMenu that Andrew made,it was a joy to select your own administraion menu setup.

Would be great if we could have such kind of feature as you suggest Brian, inside core. Users would welcome it.

Brian,
One thing, that was also a concern in the past, was how would we handle documentation and training with such a liberal and user specific administration menu?

As you are one of the most experienced joomla trainers, how would you approach this side of a change?

That used to be my concern as well - but I am not really worried abthey out
it any more as the exact same argument can be made about admin templates.

Plus I think the reality is that heavy customisation will only be done
either by advanced users OR the type of user who would never read generic
documentation either as they have a customised experience

@brianteeman Instead of developing an entirely new component how about leveraging the current menu component? Perhaps it's just my OCD, but having two components that do nearly identical things doesn't seem practical.

New "client_id" column in jos_menu_types

• Flags different menus as front-end (0) or back-end (1)

New "adminmenus" model/view in com_menu

• Only displays administrative menus jos_menu.client_id = 1

Update com_menu "menus" model/view

• Only displays site menus jos_menu.client_id = 0

New components installed

• In same way that Joomla! comes with a default front-end menu created, it will come with a default back-end menu as well (which can't be deleted).
  • All new root menu items for components will be created at the root level of the default back-end menu.
    • Make this configurable in the back-end, where site administrators can choose a specific back-end menu item they want to act as the parent for all new component root menu items.

I'm a proponent of no longer lumping of all newly installed components into a generic "Components" bin, especially as more components get decoupled from core.

Right now the menu would look something like this:

But as components are made stand-alone from core it will approach this:

@jrseliga Re New components installed
Isnt that exactly what I said

+1 to this. This will be inline with the current road map where the Joomla core is being slimmed down making Joomla a better platform to build upon and allowing site owners the flexibility to prioritize what they want.

I think this is a good idea. Most of our clients only want to be able to login and edit text occasionally or add events etc. Most find all of the menu items a bit overwhelming and end up in places they should be and accidentally make changes. Many components install a menu item that has no function or is a set once and don't touch again situation that would be nice to be able to easily hide it. I'd love to be able to customize it to suit individual needs.

Yeah - thats the idea.

Personally I always want to create a Content Menu with content creating
components such as com_content, com_gallery and com_contact and a separate
menu for my utility components such as com_jce, com_admintools, com_backup

On 23 December 2014 at 07:49, Matthew Baylor notifications@github.com
wrote:

I think this is a good idea. Most of our clients only want to be able to
login and edit text occasionally or add events etc. Most find all of the
menu items a bit overwhelming and end up in places they should be and
accidentally make changes. Many components install a menu item that has no
function or is a set once and don't touch again situation that would be
nice to be able to easily hide it. I'd love to be able to customize it to

suit individual needs.

This comment was created with the J!Tracker Application
https://github.com/joomla/jissues at issues.joomla.org/joomla-cms/5492
http://issues.joomla.org/tracker/joomla-cms/5492.

—
Reply to this email directly or view it on GitHub
#5492 (comment).

Brian Teeman
Co-founder Joomla! and OpenSourceMatters Inc.
http://brian.teeman.net/

@brianteeman for the most part yes, though if you read my comment from the J!Tracker and not directly on GitHub you missed an important edit I made. (Does the J!Tracker ever update comments?)

On that section specifically I restated your remarks as means of prefacing the key idea:
Using the root menu item specifically as the parent for all new components.

You noted a concern that the top level menu item "Components" could have been deleted by the user, leaving no fallback menu item to set as the parent for new components. And offered a suggested idea of flagging a specific item, which I also recycled in my response. I meant for that last part to be a small caveat, as in my suggestion Joomla! defaults to installing a components root item as a child to the absolute root menu item, unless the site administrator specified otherwise.

Since it's impossible to delete the root menu item, aside from direct SQL manipulation, it is no longer a concern.

Though it's not completely unreasonable to completely let the component developers handle it, as is done with front-end menu items (?). From what I've seen some create a completely new menutype and populate that with their items some make no assumptions about how the user wants their menu structure and do nothing in the way of menu items.

In many cases the default behavior for site administrators for the front-end menu items is:
"I just installed a component, have to create a menu item so my visitors can access it"

Honestly I favor the idea of not automatically creating menu items at all. At least not having Joomla! do it. It would ship with all the necessary core back-end menu items, but as far as third party components there's no need. That might seem blasphemous at first but it's at least consistent to front-end administration.

I understand that is not the behavior site administrators are used to currently for backend menu items, but being able to completely customize the backend menus with the same granularity as the front-end is also not something administrators are used to either. This introduces a new use-case, and in those cases it's not unreasonable to require a different path for the user.

Whenever the user wants a new menu item created for the frontend, there is a modal that allows you to pick the type of menu item you want. Same would apply for the back-end.

I really really dont like the idea of not having components create menu
link to themselves in the admin. But even if I did like it that's never
going to get through the B/C checks as it would be a massive changeof
behaviour. "I installed com_whatever - where is it?"

PS Github sync edits with the issues tracker on a cron job iirc - so
patience is they key there

On 23 December 2014 at 08:13, Justin Seliga notifications@github.com
wrote:

@brianteeman https://github.com/brianteeman for the most part yes,
though if you read my comment from the J!Tracker and not directly on GitHub
you missed an important edit I made. (Does the J!Tracker ever update
comments?)

On that section specifically I restated your remarks as means of prefacing
the key idea:
Using the root menu item specifically as the parent for all new components.

You noted a concern that the top level menu item "Components" could have
been deleted by the user, leaving no fallback menu item to set as the
parent for new components. And offered a suggested idea of flagging a
specific item, which I also recycled in my response. I meant for that last
part to be a small caveat, as in my suggestion Joomla! defaults to
installing a components root item as a child to the absolute root menu
item, unless the site administrator specified otherwise.

Since it's impossible to delete the root menu item, aside from direct SQL
manipulation, it is no longer a concern.

Though it's not completely unreasonable to completely let the component
developers handle it, as is done with front-end menu items (?). From what
I've seen some create a completely new menutype and populate that with
their items some make no assumptions about how the user wants their menu
structure and do nothing in the way of menu items.

In many cases the default behavior for site administrators for the
front-end menu items is:
"I just installed a component, have to create a menu item so my visitors
can access it"

Honestly I favor the idea of not automatically creating menu items at all.
At least not having Joomla! do it. It would ship with all the necessary
core back-end menu items, but as far as third party components there's no
need. That might seem blasphemous at first but it's at least consistent to
front-end administration.

I understand that is not the behavior site administrators are used to
currently for backend menu items, but being able to completely customize
the backend menus with the same granularity as the front-end is also not
something administrators are used to either. This introduces a new
use-case, and in those cases it's not unreasonable to require a different
path for the user.

Whenever the user wants a new menu item created for the frontend, there is
a modal that allows you to pick the type of menu item you want. Same would
apply for the back-end.

—
Reply to this email directly or view it on GitHub
#5492 (comment).

Brian Teeman
Co-founder Joomla! and OpenSourceMatters Inc.
http://brian.teeman.net/

Perhaps the solution could be:
1. Create create a brand new menu for each component, then automatically create/publish a new menu module that points to that menu and assign that module to all of the menu items that were just created.
2. Create one alias item in the default administrator menutype that points to the component's "home" item just created.

Sorry - I dont like that idea and I dont see what the problem is you are
solving with that

On 23 December 2014 at 08:48, Justin Seliga notifications@github.com
wrote:

Perhaps the solution could be:
1. Create create a brand new menu for each component, then automatically
create/publish a new menu module that points to that menu and assign that
module to all of the menu items that were just created.
2. Create one alias item in the default administrator menutype that points
to the component's "home" item just created.

—
Reply to this email directly or view it on GitHub
#5492 (comment).

Brian Teeman
Co-founder Joomla! and OpenSourceMatters Inc.
http://brian.teeman.net/

I'm all for consistency as well. For those clients who need a complete customization I'm using one of the myriad components/plugins (for example Admin Menu Manage does the job well). For others I have a hard time to explain even the current menu. If almost every Joomla administration (Template Provider Demo Packages with pre-installed components) would come with different admin menus it would be a nightmare to support users.

Don't get me wrong; It would be great to see in the core but only with a consistent setup and hide it as much as possible with one click revert to the original structure.

One click revert is definitely an option

On 23 December 2014 at 09:45, Joseph Simony notifications@github.com
wrote:

I'm all for consistency as well. For those clients who need a complete
customization I'm using one of the myriad components/plugins (for example Admin
Menu Manage
http://extensions.joomla.org/extensions/extension/administration/admin-navigation/admin-menu-manager
does the job well). For others I have a hard time to explain even the
current menu. If almost every Joomla administration (Template Provider Demo
Packages with pre-installed components) would come with different admin
menus it would be a nightmare to support users.

Don't get me wrong; It would be great to see in the core but only with a
consistent setup and hide it as much as possible with one click revert to

the original structure.

This comment was created with the J!Tracker Application
https://github.com/joomla/jissues at issues.joomla.org/joomla-cms/5492
http://issues.joomla.org/tracker/joomla-cms/5492.

—
Reply to this email directly or view it on GitHub
#5492 (comment).

Brian Teeman
Co-founder Joomla! and OpenSourceMatters Inc.
http://brian.teeman.net/

And I don't see why users have to pay for an option to do something that is
useful to everyone

On 23 December 2014 at 09:47, Brian Teeman brian@teeman.net wrote:

One click revert is definitely an option

On 23 December 2014 at 09:45, Joseph Simony notifications@github.com
wrote:

I'm all for consistency as well. For those clients who need a complete
customization I'm using one of the myriad components/plugins (for example Admin
Menu Manage
http://extensions.joomla.org/extensions/extension/administration/admin-navigation/admin-menu-manager
does the job well). For others I have a hard time to explain even the
current menu. If almost every Joomla administration (Template Provider Demo
Packages with pre-installed components) would come with different admin
menus it would be a nightmare to support users.

Don't get me wrong; It would be great to see in the core but only with a
consistent setup and hide it as much as possible with one click revert to

the original structure.

This comment was created with the J!Tracker Application
https://github.com/joomla/jissues at issues.joomla.org/joomla-cms/5492
http://issues.joomla.org/tracker/joomla-cms/5492.

—
Reply to this email directly or view it on GitHub
#5492 (comment).

Brian Teeman
Co-founder Joomla! and OpenSourceMatters Inc.
http://brian.teeman.net/

Brian Teeman
Co-founder Joomla! and OpenSourceMatters Inc.
http://brian.teeman.net/

I'm not sure I'd classify it as a problem, I will concede to automatically creating a menu item that is the entry point to a component in the main menu to keep consistent with current behavior, but not every menu item for that component. All components have some sort of "submenu" built-in including default Joomla! components.

I can't imagine it's common practice for you to return the top menu bar, click on Content, then Article Manager when trying to get to the Articles page when you're already on the Categories page. I would assume you'd take the more efficient route and click the Articles link in the sidebar.

Assuming is a dangerous game, but I would say that most people use the top menu as a means to hop from one component to another. Currently all the corresponding child items are created in the main menu, which then are also hand coded to load into each views sidebar by JHtmlSidebar::addEntry(). Looking at the image above is there really a logical reason for a user to have the same set of links accessible more than once on every page? The redundancy clutters the environment and is painful.

Thus full circle, I suppose I ultimately am trying to solve a few problems.

1. Main menu component entry point would be created automaticaly as to align with current behavior, the "submenu" module would be populated and assigned appropriately.
2. Developers no longer have to maintain those links each view of their component, as Joomla! handles creating a main menu item to get the users into their component, creates all supporting menu items, and publishes them to a module in the sidebar of all of their pages.

Just trying to find a solution that allows the most amount of flexibility with least amount of decision making by Joomla! on behalf of the user while ensuring all features are accessible.

I'm not saying the last solution I gave was the best option, but the entry point is "smooth" for everyone. If I'm a more casual user I have my main component links at the top, all the supporting links on the actual component page.

However if I'm a power user, I don't have to spend time removing all of those sub items from the main menu everytime I install a new component or a component is upgraded with a new menu item. If I want to create a dashboard environment that has some of my most commonly used submenu items I have the ability to publish a menu module to any back-end menu item.

As you said the heavy customization is more for the power users, why "punish" them with having to go and cleanup all of these decisions Joomla! made for them?

I am definitely with you about the duplication of the top menu links and
the sidebar - but I lost that argument already last year ;(

The "problem" with your suggestion is that not all components have submenus
and sidebars. Some have submenus only and some have sidebars only. By
automating it as you propose you are potentially breaking extensions

On 23 December 2014 at 10:00, Justin Seliga notifications@github.com
wrote:

I'm not sure I'd classify it as a problem, I will concede to automatically
creating a menu item that is the entry point to a component in the main
menu to keep consistent with current behavior, but not every menu item for
that component. All components have some sort of "submenu" built-in
including default Joomla! components.

I can't imagine it's common practice for you to return the top menu bar,
click on Content, then Article Manager when trying to get to the Articles
page when you're already on the Categories page. I would assume you'd take
the more efficient route and click the Articles link in the sidebar.

[image: redundant-items]
https://cloud.githubusercontent.com/assets/3277067/5536299/0c0d9c5e-8a5d-11e4-808a-4ab411f107b0.png

Assuming is a dangerous game, but I would say that most people use the top
menu as a means to hop from one component to another. Currently all the
corresponding child items are created in the main menu, which then are also
hand coded to load into each views sidebar by JHtmlSidebar::addEntry().
Looking at the image above is there really a logical reason for a user to
have the same set of links accessible more than once on every page? The
redundancy clutters the environment and is painful.

Thus full circle, I suppose I ultimately am trying to solve a few problems.

1. Main menu component entry point would be created automaticaly as to align with current behavior, the "submenu" module would be populated and assigned appropriately.
2. Developers no longer have to maintain those links each view of their component, as Joomla! handles creating a main menu item to get the users into their component, creates all supporting menu items, and publishes them to a module in the sidebar of all of their pages.

Just trying to find a solution that allows the most amount of flexibility
with least amount of decision making by Joomla! on behalf of the user while
ensuring all features are accessible.

I'm not saying the last solution I gave was the best option, but the entry
point is "smooth" for everyone. If I'm a more casual user I have my main
component links at the top, all the supporting links on the actual
component page.

However if I'm a power user, I don't have to spend time removing all of
those sub items from the main menu everytime I install a new component or a
component is upgraded with a new menu item. If I want to create a dashboard
environment that has some of my most commonly used submenu items I have the
ability to publish a menu module to any back-end menu item.

As you said the heavy customization is more for the power users, why
"punish" them with having to go and cleanup all of these decisions Joomla!
made for them?

—
Reply to this email directly or view it on GitHub
#5492 (comment).

Brian Teeman
Co-founder Joomla! and OpenSourceMatters Inc.
http://brian.teeman.net/

I meant to say this earlier and I think it's worth considering. The current roadmap guarantees that all of a single series (3.x.x - 3.y.y) will be compatible.

There will certainly be a considerable amount of discussion to follow, all I hope is:
If the best solution breaks b/c, I'd rather it be done right, and introduced into a series that expects to break b/c (4.0).

Well I dont want to wait x years for the perfect solution - I am inpatient
and I want it now in 2014 ;)

On 23 December 2014 at 10:18, Justin Seliga notifications@github.com
wrote:

I meant to say this earlier and I think it's worth considering. The
current roadmap guarantees that all of a single series (3.x.x - 3.y.y) will
be compatible.

There will certainly be a considerable amount of discussion to follow, all
I hope is:
If the best solution breaks b/c, I'd rather it be done right, and
introduced into a series that expects to break b/c.

—
Reply to this email directly or view it on GitHub
#5492 (comment).

Brian Teeman
Co-founder Joomla! and OpenSourceMatters Inc.
http://brian.teeman.net/

I like the idea and I would keep it as simple as possible as Brian suggested.
No multilanguage and components still create their menu items automatically. Seriously, not creating them would be a very bad decision and would only add work for the users.

I want it now in 2014

I doubt it will be 2014, but hopefully 2015

Also I'm missing how my idea breaks extensions. Doesn't every extension register a set of menu items to jos_menu when it's installed? My suggestion just adds to that step, by first creating a menutype only for them, registering them to jos_menu with that menutype, and then creating a separate component entry point menu item (just an alias item to the component's "home") in the admin menu.

Some context from the past: http://ux.joomla.org/forum/Roundtable-Discussion/402-administrator-menu-manager?limitstart=0

Question:
If I understood well from some of the comments: when you think in customising the Administrator is because you as web "integrators" want to make the life easier to "webmasters". Wouldn't be the current administrator the right place for "integrators" while we could create a customised "webmasters" administration application in frontend (some manager options only for special users)?

Creating a front end control is beyond the scope of this.

On 23 December 2014 at 12:14, javier gomez notifications@github.com wrote:

Some context from the past:
http://ux.joomla.org/forum/Roundtable-Discussion/402-administrator-menu-manager?limitstart=0

Question:
If I understood well from some of the comments: when you think in
customising the Administrator is because you as web "integrators" want to
make the life easier to "webmasters". Wouldn't be the current administrator
the right place for "integrators" while we could create a customised
"webmasters" administration application in frontend (some manager options
only for special users)?

—
Reply to this email directly or view it on GitHub
#5492 (comment).

Brian Teeman
Co-founder Joomla! and OpenSourceMatters Inc.
http://brian.teeman.net/

@brianteeman I have a feeling it would be a relatively painless process in implementing the ability for users to rearrange items in any desired combination, publish/unpublish/trash, and handle all new component installations.

Many features would be disabled from what is currently available in the front-end menu manager, most notably not being able to empty the trash (as manually creating new items wouldn't be ready yet), set a default, menu assignment, template style, etc.

When I finish the tags filtering PR I'm going to dig into it a bit and see how far off I am.

Looking forward to seeing it

On 23 December 2014 at 12:32, Justin Seliga notifications@github.com
wrote:

@brianteeman https://github.com/brianteeman I have a feeling it would
be a relatively painless process in implementing the ability for users to
rearrange items in any desired combination, publish/unpublish/trash, and
handle all new component installations.

Many features would be disabled from what is currently available in the
front-end menu manager, most notably not being able to empty the trash (as
manually creating new items wouldn't be ready yet), set a default, menu
assignment, template style, etc.

When I finish the tags filtering PR I'm going to dig into it a bit and see
how far off I am.

—
Reply to this email directly or view it on GitHub
#5492 (comment).

Brian Teeman
Co-founder Joomla! and OpenSourceMatters Inc.
http://brian.teeman.net/

Ok, if the idea is to do it in the admin, witch I would love to see it I have the same doubt mentioned at http://ux.joomla.org/forum/Roundtable-Discussion/402-administrator-menu-manager?start=8#1332 regarding this:

Multilanguage issues

Unlike the frontend I would suggest that the admin menu manager can only manage ONE menu and not one per language. Instead of user created menu titles as in the front end we can continue to use the strings from the language files. This will ensure that a site with multiple admin languages installed will only need to manage one menu and that everything will be in the same place in all languages.

For monolingual sites I see no issuse but I don't see it clear for multilingual sites. Would it be the idea to store in the database the translation strings? that would mean that we will have to add the constants instead of text:

that I'm sure is not the idea.

We could probably allow in the same component to create it's own .ini files (something like com_languages does with language overrides) for each language so you can create new constants and new translations

The other option would be to keep the standard menu module and allow our Translation team to continue translating it to all languages:

But add a new module unpublished in that same position:

This customized menu could be activated and used in the place of the current menu module or, you can activate only for a special group of users:

.
This module shows a multilingual menu. So in administrator you could have this:

Please if you have a better approach share your ideas, this is just what it came to my mind.

I would not allow to change the title of the menu in the manager. It should be fixed by the extension since it's translated using hardcoded strings.
All we really need is the ability to move the menu items around and hide selected items.

Exactly
On 23 Dec 2014 17:57, "Thomas Hunziker" notifications@github.com wrote:

I would not allow to change the title of the menu in the manager. It
should be fixed by the extension since it's translated using hardcoded
strings.
All we really need is the ability to move the menu items around and hide
selected items.

—
Reply to this email directly or view it on GitHub
#5492 (comment).

To be clear. I am talking about one and only one admin menu used for all
languages. The strings are not editable and are generated exactly as they
are right now.

The only thing that I would like to do which is not covered by this is the
name of the top level link eg components. As ideally we want to allow the
ability to create more top levels eg utilities, content, tools there would
need to be a way to name and translate this.

I believe this can be handled by having a user entry field for this AND if
the site detects multiple admin languages then an extra field is displayed
for each language with the OPTION to translate. Fairly easy to write that

The theory I'm working on right now (keep in mind this is just prototyping):

Current Admin menu

1. All of the Administrator Component menu items already exist in jos_menu with client_id = 1. Including non-core component installations.
2. However, items like administrator home (index.php?option=com_cpanel), Users, Menus, Content, Extensions, etc. are hard coded into the Administrator mod_menu.

Leveraging com_menus

1. Create rows in jos_menu for all of those hard coded links in Administrator mod_menu with client_id = 1 and menutype = 'adminmenu'
   • One row needs to be the administrator home (index.php?option=com_cpanel), which will have the column home = 1
2. Add new MVCs to /administrator/com_menus of "adminmenus" and "adminitems"
   • They will be an exact copy of MVC "menus" and "items" except the views will look only for items with client_id = 1 instead of client_id = 0 and menutype = 'adminmenu'
   • When viewing that menu (list of menu items in 'adminmenu') wrap each item title in JText::_() to preserve the value of the language strings.
   • For testing purposes, disable the ability to actually click on one of these admin menu items to edit it.
3. Should allow for items to be reorders, published, etc, as it should operate like the front-end menuing system.
4. Create a new menutype "adminmenu"
5. Take an exact copy of mod_menu from the front-end, and convert it into it a back-end module.
   • Don't allow the option of selecting a menutype, and hard code "adminmenu"
   • Wrap the title of each menu item in JText_::($item->anchor_title) to ensure it gets printed with the value from the language file.
   • Publish this to the "menu" position in the Administrator template.

As I said, everytime a component is installed, it's menu items are created in jos_menu, all that needs to happen is to ensure that when it is inserted, it gets inserted with menutype = 'adminmenu' and client_id = '1', and it should automatically be accessible to users upon component installation.

This wouldn't change the behavior of the front-end menus because they are all flagged with client_id = 0, only thing that would be necessary is to update the front-end model to exclude menutype = 'adminmenu' from being an option in dropdowns when selecting a menutype to publish in the front-end.

That would definitely be a good starting point and I look forward to seeing it

I've got a rudimentary version working which includes a new module. In the screen shot you'll see the new "Administrator Menu", it's menu items, and in the top navigation menu I published the module to display the links from that menu after the current Joomla! Administrator menu.

I will wait to review until you complete an alpha version

On 24 December 2014 at 07:46, Justin Seliga notifications@github.com
wrote:

I've got a rudimentary version working which includes a new module. In the
screen shot you'll see the new "Administrator Menu", it's menu items, and
in the top navigation menu I published the module to display the links from
that menu after the current Joomla! Administrator menu.

[image: admin-menu]
https://cloud.githubusercontent.com/assets/3277067/5546688/f1f56634-8b16-11e4-9588-d819c0ac0cfc.png

—
Reply to this email directly or view it on GitHub
#5492 (comment).

Brian Teeman
Co-founder Joomla! and OpenSourceMatters Inc.
http://brian.teeman.net/

@brianteeman A general question on "RFC" issues: Can occasional volunteer testers and contributors like me issue such RFCs, too? Or is it intended to be done by team members, and I should join the Joomla! CMS development Google group for proposal/discussion?

I am not part of any team and I submitted this
On 24 Dec 2014 17:57, "Richard Fath" notifications@github.com wrote:

@brianteeman https://github.com/brianteeman A general question on "RFC"
issues: Can occasional volunteer testers and contributors like me issue
such RFCs, too? Or is it intended to be done by team members, and I should

join the Joomla! CMS development Google group for proposal/discussion?

This comment was created with the J!Tracker Application
https://github.com/joomla/jissues at issues.joomla.org/joomla-cms/5492
http://issues.joomla.org/tracker/joomla-cms/5492.

—
Reply to this email directly or view it on GitHub
#5492 (comment).

Regarding this RFC: Personally I do not need configurable admin menus for my small little site, but I think maintainability will be dramatically increased if things are not hard-coded in many different ways at many different places but driven by data from database tables.

I agree to all conclusions made in the discussion above, especially the simplified multilingual handling, which I even wish to have as an option for the frontend, too.

I am not deep enough into Joomla! to help with implementation, but I am looking forward to a prototype and will help with testing and if necessary small corrections as far as I can and have time.

Finally, I think about making an RFC to load database table records for inital data or example data from CSV files or similar, easy to compare with diff tools, so it does not require to maintain anymore such initial data in multiple SQL scripts for multiple database types. This also could improve maintainability of what is proposed here with this RFC.

I would actually prefer RFC discussions on the mailing list and not as an issue on GitHub. I think we have enough open issues and PRs here
Also the email list is better suited for discussions.

@Bakual Which email list? Or did you mean the Google group?

The google group is also an email list
For reference: https://groups.google.com/forum/#!forum/joomla-dev-cms

@richard67

I agree to all conclusions made in the discussion above, especially the simplified multilingual handling, which I even wish to have as an option for the frontend, too.

As far as I understood, there is no change in multilanguage handling in this proposal (and there should not be any as I see it).

@jrseliga I agree with most of your proposals so far. I would change 3 things:

1. Re-use the home column for the adminmenu to define which entry should be the entry under which to install new components. I think its fine to define com_cpanel as hard-coded home.
2. Don't use any editing view at all. As far as I can see, we don't want to allow people to edit existing items. What should they edit there anyway? The title, URL, type, etc. is fixed and the access rights to a component are handled by the ACL options set elsewhere anyway. There are also no parameters to be set. In the list view, I would only allow to "unpublish" a menu item (meaning that you hide its sub-entries) or to reorder the top-entries for the components. I don't think its usefull to be able to reorder the entries in a components sub-menu. Reordering should be possible by drag&drop.
3. Allow new top-entries by having a simple modal with a single input field.

This would allow you to move your most used extensions to the top level (webshop or com_content) and organize the rest of the components into respective sub-menus like tools, content, etc.

If you are interested in some help, I'd be happy to work with you on this together.

@brianteeman Thanks for bringing this up again.

@infograf768 Well, sorry when I was not precise: Multilingual handling is not changed, but there is one menu structure only for language all, and menu titles and so on come from language files. For multilingual websites having identical menu structure in all languages, this could be nice, too.

In doing some investigation before actually diving into changes, I realized there is not a need to create an entire new MVC. The current one works just fine, all that is needed is for the jos_menu_types table to have a client_id column, which could then be easily sorted on in the model.

@Hackwar, I would greatly appreciate help. I've got a few things to iron out before I push a new branch.

After getting a bit of a working version going there are some issues with your list.

home column

• All of menu items will exist in jos_menu (front-end/back-end), which means there will be one front-end item that is marked as a home and one back-end item that is marked as home. With your suggestion the same column, in the same table, will have to different meanings when set to 1. In the front-end it will mean the default menu item to show when a user browsers your website, but in the back-end it will mean the default place certain things get created. In my opinion that is a terrible precedent to set.
  • From my perspective the back-end should also support the default menu item someone is taken to upon login. Perhaps, some users will never change this while some users may only go into the back-end to run system upgrades. I come back to the idea of why remove a feature that could be useful, is already available in the code, won't hinder average users, and would require significant modification to achieve?
• I realized there is actually a need for 2 flags. One that indicates the root for all new components as we've discussed, and one that indicates a root for all new menus created. Menus are currently retrieved and displayed in the menu by a separate query directly in the admin menu module. A mechanism will need to be created on menu create, that adds a new row to jos_menu for 'adminmenu' each time a new menu (menutype) is created (or deletes the corresponding row when that menu is deleted).
• The solution as I can see it right now, is to create two new system configuration fields for:
  • Menu root for all new components
  • Menu root for all new menus
  • A check is built-in that looks to see a menu item of that id exists, if it does, make it a child. Otherwise default to a location we decide, perhaps the admin menu's root.

Editing view

The idea here is to leverage as much existing code as possible, in fact what I'm working on now brings very little in the way of changes. There are very clear things we've discussed that can't be changed, but removing the edit feature by proxy removes the create feature. I envision this operating exactly the same way as front-end menu item creation/editing. Though this isn't something I'm trying to implement in the first pass, the modal that allows you to pick the type of menu item you are creating would use the flag of the client_id of the menutype you are creating an item in to either pull a list of available front-end or back-end items.

I really don't see any reason not to allow the ability create new menu items, remove others, or create a secondary admin menutype and display it in a module on specific pages. So long as the system doesn't allow the menutype of 'adminmenu' to be deleted, and build in a fail-safe for handling the location for all new component installations and menutypes menu items the complete power of front-end menu management is brought to the back-end with some fields hidden on the edit/create form.

Also, the edit view is necessary, without it there would be no way to truly rearrange the admin menu. The most you could do is drag and drop within the confines of that menu level. The user wouldn't be able to move "Joomla Update" under the "System" menu item instead of under "Extensions". It would just forever live under "Extensions", and be limited to the order in which it was displayed under it.

I agree that it's not a good idea to reuse the home field for another purpose. It just asks for troubles later. Just add a new field to the database or use a configuration setting.

Originally I suggested creating an entirely separate MVC to handle the administrator menu. I followed that up with scrapping the idea of an additional MVC and simply modifying the current.

I was able to get a elementary version of the latter working, but realized potential problems from an administrative perspective. Taking a step back, I approached the problem with the former in mind (creating an entirely new MVC for the administator menu), and after getting a similarly basic version working realized that too has issues.

I'm going to return to approaching the problem from the "modify the current MVC" perspective.

• Creating an additional MVC is wasteful when accounting for maintenance. In reality it would be a one-to-one copy of the current MVC files in com_menus with a small number of modifications. Why manage almost identical code twice?
• The only difference between a site menu and administrator menu would be a single column (client_id) in the database. As a result displaying site or administrator menus is best handled with a simple filter.

I'll try and push an early stage alpha branch within the next few days. I will list the most glaring issues here that prevent it from even being labelled "beta" with the hope that it will be a foundation or catalyst for others to provide perspective and assistance.

Awesome - really looking forward to trying it out and to "make it happen®"

On 3 January 2015 at 18:44, Justin Seliga notifications@github.com wrote:

Originally I suggested creating an entirely separate MVC to handle the
administrator menu. I followed that up with scrapping the idea of an
additional MVC and simply modifying the current.

I was able to get a elementary version of the latter working, but realized
potential problems from an administrative perspective. Taking a step back,
I approached the problem with the former in mind (creating an entirely new
MVC for the administator menu), and after getting a similarly basic version
working realized that too introduces it's own set of problems.

I'm going to return to approaching the problem from the "modify the
current MVC" perspective.

• Creating an additional MVC is wasteful when accounting for maintenance. In reality it would be a one-to-one copy of the current MVC files in com_menus with a small number of modifications. Why manage almost identical code twice?
• The only difference between a site menu and administrator menu would be a single column (client_id) in the database. As a result displaying site or administrator menus is best handled with a simple filter.

I'll try and push an early stage alpha branch within the next few days. I
will list the most glaring issues here that prevent it from even being
labelled "beta" with the hope that it will be a foundation or catalyst for
others to provide perspective and assistance.

—
Reply to this email directly or view it on GitHub
#5492 (comment).

Brian Teeman
Co-founder Joomla! and OpenSourceMatters Inc.
http://brian.teeman.net/

See also #5131 (comment)

That sounds really interesting!
Based on still existing com_menu with just a flag adminmenu :-)

Just one question why not indicating with a second flag, let's say fff to make it possible for using in frontend too?
With a little component for com_menu looking for that flag to add it to an existing frontend menu,
For users who are allowed to access the backend.

The visible admin menu items in frontend would be still based on the acl they belong to, the designated user have an admian(sub)menu with shortcuts to the components he is allowed to access.
And for customization the Administrator / super user can steer if an backend menu item is additionally visible for a user group in front end or not.
For the security aspect there would be still the backend authentication w /wo TFA, etc.

Just my 2c

@jrseliga did you ever manage to push something to review

I'm assuming there has been no action on this ? I'm planning to get this done & will submit a PR

GREAT!!!!

On 3 March 2016 at 11:26, Parth Lawate notifications@github.com wrote:

I'm assuming there has been no action on this ? I'm planning to get this
done & will submit a PR

—
Reply to this email directly or view it on GitHub
#5492 (comment).

Brian Teeman
Co-founder Joomla! and OpenSourceMatters Inc.
http://brian.teeman.net/

@parthlawate Could you please share your work on this, as we have added this suggestion as one of the project idea's for GSoC https://docs.joomla.org/GSOC_2016_Project_Ideas#Project_III:_Administrator_Menu_Editor

One of the student has started preparing proposal around this, if you could help, it would be great. Just join our GSoC Group to take part in the conversation https://groups.google.com/forum/?hl=en#!forum/jgsoc-2016

Regards,
Puneet Kala

@puneet0191 Yes @coolbung showed me that. I need to do this anyways for some work stuff so need to do it quickly maybe in the like the next 6 weeks or so. Not sure if via GSOC it will go that fast ? I will ask @coolbung to talk to you see how we can coordinate !

@parthlawate Actual coding doesn't start on this until 23rd April, so more than 6 weeks before we have someone working on this. https://developers.google.com/open-source/gsoc/timeline?hl=en

We need to make a decision on this project soon, if you are going to cover complete scope of the suggestion than according to me it makes no sense to have the project on the Idea's list. @coolbung Please let me know about this soon.

Regards,
Puneet Kala

Oh ok.. in that case let me see if i can schedule this part for later so that we can still have it as a GSOC project. We are preparing a document which builds on this RFC to detail how it all needs to work. Let me ask @coolbung to share that with you. Based on that you can discuss if GSOC plans for that entire scope or part of it. If its part of it, we can take up the GSOC code and add to it to complete the same. I can also have someone from our team help mentoring this

@parthlawate
Hey,
I am looking forward to work on this project in GSoC 2016 and i have been advised by one of the mentors to get some information on what changes exactly is required under this project.If you can give some feedback on the modifications to be done in the Joomla administrator menu,it would be of great help.
Also i would like to si=uggest some of my own modifications.

@parthlawate Do you have any update on this please? student has started preparing the draft proposal, it will be very helpful if you could share details. @coolbung Do you have any thing on this?