small request / add the ability to remove or move TAB and MENU items

[seansan]

Currently extension are clogging up our tab and menu bars. And esp the last couple of years everybody seems to add their company name and extension name in every menubar they can.

Wlould be nice for the admin to stop or circumvent this.

Pref. All extensions also in one place in the backend

[Vinai]

👍 one of my pet hatreds, too.
Why does everybody think they are so important? There are plenty of good places to add new options that would match any use case!

[pronto2000]

I agree ... totally screws up interface on mobile devices, too!

[tzyganu]

@seansan I don't think that restricting all non-core modules in one menu item is the best approach. It kind of kills the concept of flexibility.
And, in M2 you can already move around the menu items .
Here is a simple example of what you can do to group all your third party extensions in one menu.
Let's say you have 2 extensions called Namespace1_Module1 and Namespace2_Module2. Each one adds a top menu item with the ids Namespace1_Module1::menu and Namespace2_module2::menu. It's not important if the main menus have submenu items.
What you can do is to create your own module (let's call it Easylife_AdminMenu) that adds a menu item to the top and moves the 2 third party modules menus inside it.
The adminhtml/menu.xml file should look like this:

 <config xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:noNamespaceSchemaLocation="../../../../Magento/Backend/etc/menu.xsd">
    <menu>
        <add id="Easylife_AdminMenu::third_party" title="Third Party Modules" module="Easylife_AdminMenu" sortOrder="1100" dependsOnModule="Easylife_AdminMenu" resource="Easylife_AdminMenu::third_party"/> <!-- declare one main menu to rule them all -->
        <update id="Namespace1_Module1::menu" parent="Easylife_AdminMenu::third_party"/> <!-- move module1 menu inside the third party modules menu -->
        <update id="Namespace2_Module2::menu" parent="Easylife_AdminMenu::third_party"/> <!-- move module2 menu inside the third party modules menu -->
    </menu>
 </config>

Now each time you install a third party module all you need to do is identify the main menu item id and add one line inside your new module.

[seansan]

Try to keep an open mind

In WP most external options are parked quite good together
And I am not about restricting at all
But what I do think is that the user should be in control, and not the
programmer
So no one should have to code to keep a clean interface

On Mon, Oct 27, 2014 at 2:13 PM, Marius Strajeru notifications@github.com
wrote:

@seansan https://github.com/seansan I don't think that restricting all
non-core modules in one menu item is the best approach. It kind of kills
the concept of flexibility.

And, in M2 you can already move what menu items around.

Here is a simple example of what you can do to group all your third party
extensions in one menu.

Let's say you have 2 extensions called Namespace1_Module1 and
Namespace2_Module2. Each one adds a top menu item with the ids
Namespace1_Module1:menu and Namespace2_module2:menu. It's not important
if the main menus have submenu items.

What you can do is to create your own module (let's call it
Easylife_AdminMenu) that adds a menu item to the top and moves the 2 third
party modules menus inside it.

The adminhtml/menu.xml file should look like this:

Now each time you install a third party module all you need to do is
identify the main menu item id and add one line inside your new module.

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

[tzyganu]

@seansan Ah...but you as a user should not install third party modules. You should let developers to that. I think that @Vinai can give you a lot of reasons why.
So if one developer can install a module he can move the menu item where ever you want.
And as far as the user control, I think this is an other issue. I already requested here #679 for some control on the dashboard. A user defined dashboard would be nice and enough for a user to configure what he wants/needs. The work needed to make a configurable menu may not justify the added value of this feature. But this is just my opinion.

[seansan]

Ah...but you as a user should not install third party modules. You
should let developers to that

Does this not defy the whole concept of flexibility you mentioned?

I for one DO think a user admin should be able to install modules via
Magento Connect. After that go to config and config. In ALL our wordpress
site I have never changed a single line of code in all these years. It
just works also with the extensions.

Developer should >> develop the extensions >> for admins to install it >>
and users to use it

On Mon, Oct 27, 2014 at 2:24 PM, Marius Strajeru notifications@github.com
wrote:

@seansan https://github.com/seansan Ah...but you as a user should not
install third party modules. You should let developers to that. I think
that @Vinai https://github.com/Vinai can give you a lot of reasons why.

So if one developer can install a module he can move the menu item where
ever you want.

And as far as the user control, I think this is an other issue. I already
requested here #679 #679 for
some control on the dashboard. A user defined dashboard would be nice and
enough for a user to configure what he wants/needs. The work needed to make
a configurable menu may not justify the added value of this feature. But
this is just my opinion.

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

[tzyganu]

@seansan Like I said...that is my opinion.
A non-technical admin should NOT install extensions using Magento connect.
Here are @Vinai's points on this. (@Vinai sorry for dragging you into this, but you brought be best arguments on this topic).
And here are more views on this.
I don't think an argument like "Wordpress does it this way" is not the best one. Wordpress is not the god of all CMS-es and it has a lot of issues on his own.

I think we are looking at this from 2 completely different positions. You as a user, myself as a developer. I'm not saying your ideas are not valid and should not be implemented. I'm just saying that they might not bring enough value to justify the time spent implementing them.
Of course I would love to have a customizable menu so I can drag around the menus to make them fit my ideas, but this is a very very low priority feature specially if the same result can be achieved through a few code lines. If I was the decision maker on Magento2 I would not implement it.

[seansan]

I am going to stop this conversation.

(and you presume a lot I think)

My original request was and is: would be great if the admin could have
some config influence on what/who puts menu items where

On Mon, Oct 27, 2014 at 2:43 PM, Marius Strajeru notifications@github.com
wrote:

@seansan https://github.com/seansan Like I said...that is my opinion.

A non-technical admin should NOT install extensions using Magento connect.

Here are @Vinai's points on this
http://vinaikopp.com/2014/10/17/magento-connect-for-merchants/. (@Vinai
https://github.com/Vinai sorry for dragging you into this, but you
brought be best arguments on this topic).

And here are more views on this
http://magento.stackexchange.com/q/40359/146.

I don't think an argument like "Wordpress does it this way" is not the
best one. Wordpress is not the god of all CMS-es and it has a lot of issues
on his own.

I think we are looking at this from 2 completely different positions. You
as a user, myself as a developer. I'm not saying your ideas are not valid
and should not be implemented. I'm just saying that they might not bring
enough value to justify the time spent implementing them.

Of course I would love to have a customizable menu so I can drag around
the menus to make them fit my ideas, but this is a very very low priority
feature specially if the same result can be achieved through a few code
lines. If I was the decision maker on Magento2 I would not implement it.

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

[verklov]

Thank you for your suggestion, @seansan and an interesting discussion between all participants in the thread! We will record this improvement and think it over.