Much better.
I still think the Component Container stuff should be more proeminent and that batch may be useless as anyway Language is no use in back-end.

I still think the Component Container stuff should be more proeminent...

I agree. I tried to add it as a separate menu type. But it asks for more work. Other priorities took over.

@izharaazmi

After a good night sleep, I think I found the flaw in the conception of this new Feature.
Even if the user finds out about the Component Container (Hidden in the Page Heading System Links menu item), the fact that the Protected Menu items are displayed in the Menu Items Manager as a unique possibility to publish/unpublish the items which will be displayed in that container is wrong.
The reason is that one should not think in terms of a unique alternative admin menu but of multiple ones.
That is because it is possible to create multiple admin menus, each of them displayed by a menu module with different Access Level.

A specific group of users may be using adminmenu1, another adminmenu2.
Each of these admin menus should be able to contain a Component Container menu item.
As it is now, because the Main (Protected) Menu and its items status is unique, it creates the issue @laoneo rightfully pointed out in #13689.
And it forces all potential Admin menus using the Component Container to display the same components menu items.

There is a solution, if feasible.

1. Do NOT display the Main (Protected) menu and its items when filtering by administrator in the main Menu items Manager.
2. Create a specific Admin Menu Item called Component Container.
3. This menu item would contain a button to choose in a modal the Protected Menu items to publish or not for that instance of the Component Container Menu item and only for that instance of it.
4. Let's forget about Batch in that modal.

Do NOT display the Main (Protected) menu and its items when filtering by administrator in the main Menu items Manager.

I did something similar, but my local git is somehow not letting me push my changes since last night. I'll fix it soon.

Create a specific Admin Menu Item called Component Container. This menu item would contain a button to choose in a modal the Protected Menu items to publish or not for that instance of the Component Container Menu item and only for that instance of it.

Cool. That should be great.
What about the new installation afterwards? May be we let the users choose what to hide instead of what to show. This way new ones will always be shown until hidden.

What about the new installation afterwards? May be we let the users choose what to hide instead of what to show. This way new ones will always be shown until hidden.

Any new component installation would by default add to the list its menu items as published (does'nt it do that now in the present UI?)

Yes it does. But in the proposed concept, if we let the use choose what to "show" then new ones will not be "shown". However, if we let them choose what to "hide" then new ones will not be "hidden".

Fine by me, as long as it is clear. ?

@infograf768 I'll be working on the above proposal by this weekend. For now can be move ahead with this PR, as this one is not related.

Not sure it is not related as the proposal would take off Main (Protected) from the Menu Items Manager.
BTW, I succeeded in the part concerning creating a specific Component Container menu item, separated from the System Links with a itemadmin_container.xml.
That was the easy part. remains to create the parameter in that menu item to display a modal (which will be different from the existing modal), or a list of all components admin menu items with show/Hide buttons.

If it may help, here is a diff
admin_menus.txt

DO NOT let people create All Components menu items with a different set of displayed components. It's unintuitive and will lead to people thinking that Joomla or 3PD extensions are broken. THIS HAS ALREADY HAPPENED WITH 3PD ADMINISTRATOR TEMPLATES. You wouldn't know because you don't publish extensions like I do. Invariably, the user thinks that it's Joomla or the 3PD extension at fault, not their choice 3 months ago to only allow certain components to be displayed.

You DO NOT need this. The need to create custom lists of extensions per backend user type is exactly why the administrator menu manager feature was implemented to begin with! If I want to offer my not-so-bright client a simplified menu I now can. You don't need to give me Yet Another Obscure Option that has the potential to catch me of guard several months after I used it (and no longer remember that it even exists). Also, feature creep does not a good software make!

DO promote All Components as its own menu item type under System. Otherwise it's unintuitive and has obvious UX issues (discoverability), i.e. unless you are told how to do it you will never figure out how to do it yourself.

Finally, about languages. It doesn't matter if the language drop-down is shown in the modal or not at this point. I'd even say leave it there and document it as "reserved for future use". I can see how this menu manager could be extended in the future to support languages. I mean, Joomla is the only CMS which will allow custom menus. If by some miracle we discover it's not a silly idea that confuses people (as I suspect will happen and as I had told @brianteeman back in 2012 when he first mentioned that idea to me) then I don't see why we wouldn't allow localized menu items without using translation keys. Maybe my Greek content author needs to access a different set of tools than my English content author (I can think of use cases in the context of a financial news site) and I could do so without having to set up different groups and access levels just for back-end menus.

In the end of the day the word you need to remember is K.I.S.S. (Keep It Stupidly Simple)

@nikosdion I'd agree here. There is certainly a big confusion coming to the users with this.

I will try to come up with an intermediate solution when I work on it. We can then discuss it further over there.

@nikosdion
I am confused, whatever you said to whoever 5 years ago.
Let me try to make myself clear.

Any custom admin menu, containing or not a Components Container menu item, may exactly have the same consequences you describe: some components may not be displayed and confuse a user who forgot what has been parametered 3 months ago... as many other parameters in all CMS.

As for the All components menu item, what I proposed above is only my proposal. The new menu item can be displayed among the System links instead of by itself. It is anyway necessary to create it separately from the Page Heading menu item.

My proposal would take care of the UI confusion which displays the Main (Protected) components menu item in the Menu Items Manager, giving users the false impression (as already largely pointed at by testers that one can publish/unpublish these directly in the Manager and get an immediate effect on the current core admin menu.

BUt, if I understand you well, one should never publish/unpublish (Hide/Show) any components menu items displayed by the All Components Container. All should always be displayed.
If you get support with that (PLT/release maintainers please decide), then the new Component Container menu item would just not propose to show/hide any components menu items and it is no use to display them anyway in the Menu Items Manager.

Last, I agree for languages. We can indeed imagine that this field could be used in the future in back-end. It would require though that the field be reinstated when editing an adminmenu menu item.

@infograf768 We are saying the same things. Let me recap :)

All Components: Appears under System. Shows all third party components, always.

Menu items manager regarding the protected status: the best way is to NOT let people modify what is being displayed in the All Components menu of custom menus.

BUt, if I understand you well, one should never publish/unpublish (Hide/Show) any components menu items displayed by the All Components Container. All should always be displayed.

That. I meant exactly that. If you have an All Components container then all components must be shown. Otherwise we have to explicitly name it Only Non-Protected AND Published Components Container which is a mouthful, accurate and immediately obvious why it's a bad idea.

If you get support with that (PLT/release maintainers please decide), then the new Component Container menu item would just not propose to show/hide any components menu items and it is no use to display them anyway in the Menu Items Manager.

No, no no no no no no no. You are missing the entire point of the menu manager. Follow my scenario.

Alice is a site integrator. She builds sites for a living. Alice has a client, Bob, who's not too smart but has paid her to build him a site. Alice want to let Bob edit content (articles) and take backups but NOT manage anything else on his site while she has him on a site maintenance contract. Therefore, Alice wants to show three things to Bob when he logs in to his site: Articles, Take a Backup, Log Out.

The first and last items are core components and you already see how to do it. Splendid! How about Take a Backup which requires access to Akeeba Backup? Alice doesn't want to display all components because she also has Admin Tools, Kunena and AcyMailing in there and she doesn't want Bob to screw up her perfect setup for Bob's security, forum and mailing list. Security setup is none of his business, forum he can manage from the front-end and the newsletters are sent to her to process anyway. Up to and including Joomla! 3.6 there was no way to do that. With Joomla! 3.7 (and thanks to Akeeba Backup's author, yours truly, adding the required XML files) she can now create a menu item directly to Akeeba Backup's backup feature. Mission accomplished!

THEREFORE the very existence of the menu manager feature fulfills the needs of site integrators.

CAVEAT! If the developer of the component has NOT added XML files for his component's views the menu manager will NOT let you create a link to that component (unless you use the Link type and you enter the URL index.php?option=com_whatever, which is NOT user friendly). What I would suggest is having the menu manager provide links to the default system menu's Components sub-menus. It's more work but more user friendly.

But wait, there's more than meets the eye here. Alice still needs to manage Bob's site. They have a contract, remember? She can't go every single time to index.php?option=com_modules to switch the menu type. The solution she prefers is having two different menu modules, one for her and one for Bob. Thanks to user groups and access levels that's possible. In her menu she wants to have a menu item Applications which displays all components.

Now, Alice is a busy woman. She manages four dozen sites. She doesn't remember every single option she has clicked on every single site. Bob asks her to add a downloads manager because he wants to make PDFs with his economic wisdom available only to people who have registered on his site. Alice goes ahead and installs Phoca Downloads. What happens?

It doesn't appear under Applications. WTF?! Alice thinks the installation failed. She tries again. Nothing changes. She now thinks that either Joomla or Phoca is broken. But she has already installed other extensions so it's not Joomla, it's Phoca! BOO! Files a 0% review on JED. Only that Alice didn't realise that this happened because she chose which extensions to display under Applications. Therefore such a feature would be stupid, frustrating to the users and unfair to developers. That's what I'd told Brian it'd be stupid to implement. We NEED a way to display ALL components, ALWAYS because people will always, ALWAYS, ALWAYS screw up.

It appears in the Applications menu, magically. That's how Joomla has been working ever since it was called Mambo and had user installable components back in 2003. That's because the All Components menu type displays (you guessed it) all components. This is what old users expect because they are used to it. This is what new users expect because that's what ALL COMPONENTS implies. "All" means "all", not "some". Therefore not letting them choose which components to display / hide is the smart thing to do. That's what I propose that we should do: the smart thing. Because we are smart people.

. What I would suggest is having the menu manager provide links to the default system menu's > Components sub-menus. It's more work but more user friendly.

Already, If I get you right.

It doesn't appear under Applications. WTF?! Alice thinks the installation failed.

Same argument can be made when publishing a module, remember you may have assigned to selected pages and wondering why they don't appear on homepage.
But, ignore this. I'll handle it somehow when working.

I agree to almost everything above, except I have a situation.

Lets assume you installed several components and also created your custom links at your will. Now you don't want them to show up in the components container (to avoid duplicates) and still want to keep the container for new components, as you rightly pointed. How do you accomplish this if you don't let them hide items selectively?

PS: Where do we call it "ALL Components Container"?

Here's the thing. The Components container MUST always display ALL components. Why? Because this is what users expect. In their mind the Components menu contains all installed components.

Also, why would I ever need to display SOME components under menu item X and SOME OTHER components under menu item Y? The obvious reasons would be "I want to group components by intention". So, perhaps, I could put Admin Tools, Akeeba Backup and JCE under "System Tools". I would then put Community Builder, Kunena and Magma Helpdesk under "Interaction". And then I'd put Articles, Media and Phoca Downloads under "Content Management".

There are two ways to go about it.

METHOD A. I create the three top level menu items (System Tools, Interaction, Content Management). Then I create each of the component menu items under each of the top level menu item. Under a fourth top level menu item ("Joomla System") I will also have a link "All Components" which lists all of the above components and also whatever else I hadn't linked to already. That's my fallback in case I screw up... and I can have it unpublished by default. If I install more extensions I will know which top level menu they belong to and decide what to do with them.

METHOD B. I create three top level menu items (System Tools, Interaction, Content Management) which each one is a Component root menu item. Then I have to go OUTSIDE the management of my CURRENT admin menu to choose which components will appear under each of these admin menus. I NEED TO DO SOMETHING NON-OBVIOUS TO ACHIEVE MY GOAL. Moreover, since we are WHITElisting components to appear under each menu I CANNOT have a fourth submenu "All Components". Therefore I have no fallback.

Method A is intuitive and accomplishes the goal of customising the administrator menu structure while still providing a fallback.

Method B is what you implement if you want me to sue you for wasted support time, lost income and damages when people start accusing ME for YOUR stupid decision to have your code not show MY component's menu item. Got it?

I have tested this item ✅ successfully on b6602a5

Whatever the decision concerning the usage of the Component Container (will create an issue to get a decision from CMS Release maintainers), this has to go in to prevent deleting/trashing components menu items.

@izharaazmi
After a discussion with maintainers, I looks like we could go on being able to customize the Components Container menu item to choose there which components should be hidden or displayed for each instance of the item.

I have an idea that would make it easier on Nicolas, if it is feasible:
Force the creation of a Component Container menu item in each admin menu, as we already do for menus and modules, but only display it IF there are published items in the list.
This would mean that in the case a user has unpublished/hidden all menu items, but installs a new extension, the Component menu item would display with that extension menu items until decided to hide it if decided.

In the mean while I worked on the Manager and I can get this result quite easily:

The Notice can be easily customized to fit.

Force the creation of a Component Container menu item in each admin menu..
I don't think there is a need to force, but should not be a problem if we really want to.

Only display it IF there are published items in the list.

This is already implemented. Any container or heading type menu is only shown if they contain something. Similarly, repeated or edge positioned separators are squashed/removed.

... in the case a user has unpublished/hidden all menu items, but installs a new extension, the Component menu item would display with that extension menu items until decided to hide it if decided.

True, this is what we discussed earlier. Hiding would be an option, so that new ones are always shown.

This anyway needs something done similar to what I posted above for the Manager AND adding the possibility of choosing to Hide/Show the components menu items in the Components Container menu item itself.

I'm on it

Ok. When ready, I guess you can close this one.

@izharaazmi

This is already implemented. Any container or heading type menu is only shown if they contain something. Similarly, repeated or edge positioned separators are squashed/removed.

tested this and nope. As it is now if one unpublishes all Main[Protected] menu items, the Components menu still displays with no menu items when clicking it.

@infograf768 Yes, I noticed that. It broke when we split the container out
from header type. Its included in my current work - for next PR.

Closing as we have #13830 that includes this.