Remove Shortcut module from core

I am working on it

+1 for all of the reasons mentioned above. This module is an attempt to do something generic for all sites, that really should be a site specific customization. This could also be handled in the contrib space. For example, in D7 the workbench suite does a much better job than dashboard and shortcuts.

Replace the "Shortcuts" link at the top of the toolbar with a hard-coded "Add content" link (the only useful default shortcut)

This does exactly that. Well, it says "Create content" I see now, but that's easy to change. :)

EDIT: obviously this should be moved into node_toolbar(), since the node module owns this route.

Updating the IS with reasons from IRC discussion, to provide a more coherent list of reasons.

Wow,
-10000.

I had already written a huge rant about the wording of the issue summary but you have already improved it in the meantime.

Still points 4. and 5. do not make much sense.

Re 4.: The ability to install a module from contrib has never been an argument for whether or not we ship a module in core. Drupal core is supposed to be a product and we make decisions based on features that we want to have in that product vs. their maintenance burden. First of all Shortcut is super useful even without multiple roles if you have a small site with only authenticated user that does most of the content management but is only allowed to access ~3-5 admin pages. And the argument that it's geared towards sites with multiple roles is a complete strawman as well. There are tons of features in core that are geared towards that. You can e.g. make it so that some roles see the node edit form in the admin theme and others in the frontend theme. We ship a bunch of text formats in core which only start being remotely useful with ~>3 roles. You can configure block visibility per role and thus control the whole page layout differently for different roles. We've invested a lot of work to make the toolbar menu respect different role's access to different menu items, which is also overkill out of the box. Need I go on? With that argument you could basically move half of Drupal's codebase into contrib.

Re 5.: I don't even know what this is supposed to mean? It's completely trivial to set-up site-specific shortcuts, I do that for pretty much every site. The functionality is not site-specific at all, the links themselves are. This is in fact quite ironic, because the hardcoded node/add link you are adding: that is site-specific and something I will have to disable on every single site. Especially with the shortcut set feature and its per role usage make this quite a versatile tool. Sorry, but this is just bogus.

Personally, I think Shortcut is one of the most useful modules we have in core. I'm not saying that we should keep it at all costs, but this does not seems like an open and honest discussion, sadly.

I agree with Tobias, hard coding one link is something I'd have to undo on most sites

#11: I mostly agree that Shortcut is useful. But its current implementation is not; it's very, very confusing. It's incredibly convoluted to switch to a different shortcut set (it's at /user/UID/shortcuts), it's impossible to assign a different set of shortcuts depending on the role, when you have permission to edit the shortcuts, you're modifying it for other users as well (who might have a different role and hence different permissions and hence they won't be able to see those links — well, shouldn't, until #2216271: Regression: Shortcut links access is not checked is fixed, they can).
I'd be +1 to make Shortcut make sense again (e.g. global default set of shortcuts, with the ability to "fork it" into a user-specific set of shortcuts). I use it too, and I'd miss it too!
But it has been broken many times, and still is, even when ignoring the UX flaws pointed out above. That's why this issue was filed.

Don't worry, we're not rushing this in, we're just posting this up for discussion, and doing an initial patch to see what the impact would be.

#12:

hard coding one link is something I'd have to undo on most sites

The idea is that a D8 contrib Shortcut module would remove it for you. Besides, that link could be configurable.

...only really makes much sense on sites with multiple roles.

So ... pretty much every site then?

I'm not sure I get the "site-specific" part of this? Menus and blocks and content types are site specific, too. I understand the ROI issues with trying to get some of this fixed, but a lot of these points seem thin.

I'm also -1 on this. Well, probably more like -10, but not quite -1000. :)

If anything, I think Shortcut gained importance as a feature in D8 given the "mobile age." At any time, but especially when on a relatively crippled device, you don't want to dink around clicking 3+ levels deep to get to pages you access 99% of the time. I always add a link to Devel's "Clear cache" link, for example.

Also, Admin content is just as important as Add content. Admin content is the "node orphanage" where you go to find the pages and other piece of content where you forgot to add them to a menu and they're not checked to show on the front page view.

It sounds like the main concern in the issue summary that's based on fact rather than opinion is that Shortcut needs an active maintainer to replace the intrepid '?' who can take a look at things like the architecture, security, and caching aspects. tstoeckler is that something you'd be willing to take on?

...only really makes much sense on sites with multiple roles.

So ... pretty much every site then?

Most of the features in core that support multiple roles, support anonymous vs. authenticated vs. admin roles.

Shortcut module is 99% about supporting different kinds of admin user, which implies a larger/more complex site.

The ability to install a module from contrib has never been an argument for whether or not we ship a module in core.

Well it's often been an argument for putting modules into core.

There's really three groups of modules in core:

Fields, entity, views - these all provided features that core modules/subsystems depend on, as do lots of contrib/custom modules. Before they were in core, we had one-off/hacky implementations because we couldn't depend on them.

Node/User/Comment/Forum/Taxonomy - provide end-user/site-visitor facing features and based on/enhance the previous category. Also often dependencies of contrib and custom modules. (visitor-facing)

Seven, toolbar, shortcut - modules that are only admin or content-editor facing, rarely dependencies of contrib or custom modules (admin-facing).

The site-building group of modules reflects Drupal's recent history in the past 1-6 years.

The visitor-facing group reflects Drupal as a Content Management System - some of which are still extremely central to site building, some not so much. We don't have per-module usage information to get exact numbers. Their inclusion does mean you can get a blog or brochure (or much more complex site in 8.x) running without having to go out to contrib. If there's bugs in these modules, they usually get reported/fixed pretty fast, since lots of people use them and there's complaints if they don't work properly.

Admin-facing modules reflect specific approaches to address UX/workflow issues in core, for common groups of tasks. Shortcuts I've worked on several client sites that use it, but I don't think I've ever actually added a shortcut to anywhere. I do usually leave the admin theme as Seven and use the toolbar though (which has an admin/content link, not sure why shortcut is necessary for that).

So the question isn't whether it's useful, it's whether it's so essential to the core experience that it was worth maintaining it through at least two critical link/routing storage issues (where if anything it served as a red herring rather than a useful use-case) and with an open security issue that was left major and untriaged for a year. Every time I've seen shortcut brought up in the link storage issues I've groaned, and I imagine that same feeling of despair is why people who just recently attended a sprint that involved fixing it opened this issue.

Thanks you all for your reasoned responses. Don't want to be a process nazi and and I'll also shut up now until I have something constructive to say, but I feel obligated to make one more point: #13, #15, and #17 all bring up valid arguments against having Shortcut in core, most of which are not in the issue summary. If they had been, I'd been a lot less pissed ealier today ;-)

Also, I'm relieved that this is not an effort to rush this in. Even though I could (barely) resist from using that language myself in order not to piss anyone off (even more), I had exactly that impression.

On balance, I think I'm -1 on this as well, at least at this time. I agree with #11 that Shortcut is useful, and has advantages over node.module hard-coding its own top-level toolbar link. I also agree with #17 that it's not so essential to Drupal being functional as to be worth keeping in if it's a huge burden to core maintenance. But, looking at the list of its currently open criticals and majors, that doesn't look to me to be a huge pile of technical debt (at least of known technical debt, maybe there's a huge pile of debt not reflected in that list).

I like webchick's suggestion in #16 to try to find a maintainer for it first, and only consider removal if that search proves unsuccessful after some reasonable amount of time.

[was it] worth maintaining it through at least two critical link/routing storage issues (where if anything it served as a red herring rather than a useful use-case)

that's an interesting question. don't know.

The Drupal 7 sites I see that use the core Toolbar module generally also use the Shortcut module (and by "use" I don't just mean they have it installed, I mean they have actually customized the shortcuts and have added links to it besides the default ones). The toolbar on its own is significantly less useful without the shortcuts because it requires way more clicks and page loads to get things done. Removing both from core and replacing it with Admin Menu (like Backdrop did) might be an option, but I don't think that's going to happen for Drupal 8. Therefore the Shortcut module should not be removed.

I decided not to be Shortcut maintainer for Drupal 8 because I didn't really have the time, but indirectly because the module was complex enough (and getting more complex in Drupal 8) that it would take too much time to maintain it meaningfully. I personally think the module should work the way we wanted to make it work in 2009 (https://www.drupal.org/node/511286#comment-2115920), basically:

1. Core should only support a single shortcut set which uses the menu system as much as possible (at least on an API level, maybe partially on a UI level too). It should just be a special menu which is displayed in the toolbar and has the special one-click UI for adding links to it.
2. Per-user shortcut sets should be removed from core and left to a contrib module, just like per-role shortcut sets already are (https://www.drupal.org/project/shortcutperrole).

With these changes the module would be a lot simpler and easier to maintain. I might be willing to maintain it for Drupal 8 (but I'm not sure I'm willing to do all the work to try to get it to that point, especially at this point in the Drupal 8 cycle).

One thing I do like about the proposal in this issue, though, is that by putting "Add content" as its own link in the toolbar, it solves the biggest part of #1852346: [discussion, no patch] Toolbar UI regression: shortcuts and menu not visible at same time (or more specifically, #1847116: Provide users with an easy-to-access action to create content from the toolbar)...

We don't have per-module usage information to get exact numbers

For what it's worth, in theory we have that information in the drupal.org logs for most sites using Drupal 7.17 and higher (see #1036780-54: Drupal.org should collect stats on enabled sub-modules and core modules and other comments in that issue). But no one's done the work to get the stats out into a useful form.

It should just be a special menu which is displayed in the toolbar and has the special one-click UI for adding links to it.

Why the one-click UI part? Or rather, why that part in core? If it's a single menu rather than per-role or per-user, why not just a special menu like "User account menu", and that's it?

Or alternatively, if we have the one-click UI, then can we also *not* make the links generated from that UI editable from the Menu UI? Similar to how the menu links defined in *.links.menu.yml aren't. Deleted, disabled, or re-ordered: yes. But if you want to edit, then delete and add a new (custom) one instead, same as for the Administration menu.

Core should only support a single shortcut set

That sounds wonderfully simple :)

[…] which uses the menu system as much as possible (at least on an API level, […]

This would be one *massive* change… it'd be up to D8 core committers to say whether this can still happen.

It should just be a special menu which is displayed in the toolbar

Sounds great!

[…] has the special one-click UI for adding links to it.

To be clear: this is the star icon that we currently already have, right? Or does this mean something else?

Per-user shortcut sets should be removed from core and left to a contrib module, just like per-role shortcut sets already are

… but that means the same set of shortcuts is shown to all users? Well, minus those they can't access, of course. That's also what #511286-97: D7UX: Implement customizable shortcuts says. I'd be fine with that. I just wanted to confirm that's the case. I agree that this would remove almost all fragility and complexity (yes, even only this change, not even taking into account the "shortcuts are just a special menu" bullet).

If we reduce the Shortcut module to just that, why is it not just "Menu module" at that point? Like why would we have a separate module for the ability to add a static menu item with optional static list of menu items underneath it? Menu already shows/hides links based on permissions.

(EDIT: Oops, basically copied effulgentsia @ #22.)

To be clear: this is the star icon that we currently already have, right? Or does this mean something else?

Yes, by "one-click-UI" I meant the star icon :)

Why the one-click UI part? Or rather, why that part in core?

I think it's a key part of the user experience which makes the module much easier to use. When you find yourself on a frequently-visited admin page, you just add it directly from there with one click.

For example I do this on local dev sites if a patch I'm working on requires me to go back to the same admin page for testing over and over again; usually the third or fourth time I do that I realize I'm wasting time navigating there, so I just quickly add it as a shortcut.

Or alternatively, if we have the one-click UI, then can we also *not* make the links generated from that UI editable from the Menu UI? Similar to how the menu links defined in *.links.menu.yml aren't. Deleted, disabled, or re-ordered: yes. But if you want to edit, then delete and add a new (custom) one instead, same as for the Administration menu.

It is news to me that Drupal 8 lost the ability to edit/override module-provided menu links via the admin interface (and I can't find a change notice), but testing it now... apparently it did. This is kind of sad, as the workaround is pretty awkward.

The Shortcut module's default choice for the link title is not always the best so I think people do edit them sometimes. Nonetheless, there is a workaround, and it wouldn't be much worse to lose the editing capability for shortcuts than for other menus. (I assume you have a technical reason you think this would make things easier.)

… but that means the same set of shortcuts is shown to all users? Well, minus those they can't access, of course.

Correct.

Hi

I do not use Shortcut in my projects becouse default shortcuts (in standard profile) set not usable and I use admin menu instead (becouse admin tasks in left top corner and to access any settings I need just two click).

I propose to create a voting about "which shortcut set is more offten used".
1. for contenters (Add content, Taxonomy, Add user ...)
2. for developers (Clear cache, panels, ....)
3. .....

and create switchable sets of shortcuts or modify the default one that with a lot of votes

Shortcut is useful. Being able to add shortcuts to deep configure pages is really helpful for users I work with regularly.

How much effort has been expended in finding a new maintainer?

Could it be simplified?

Knee jerk remove x because y issues like this are really frustrating. Too often developers make these pronouncements with no understanding of how users actually manage their work.

-100 from me.

Knee jerk remove x because y issues like this are really frustrating. Too often developers make these pronouncements with no understanding of how users actually manage their work.

There are 9 points in the issue summary (and many more points in comments). Only three of the points in the issue summary are talking about how the module is used. The rest are about the impact that shortcut has had on recent critical issues, its outstanding technical debt and maintenance cost - all of which impacts on volunteer time trying to get the release done. This is not a 'pronouncement with no understanding'.

I agree with others here who have said that this module is useful enough to be important to
remain in core. And while I appreciate David_Rothstein's suggestion to simplify down to one global shortcut menu, I disagree with it: I believe that the ability for different types of users to have different shortcuts is important functionality from a product point of view. If it made it easier to find a maintainer, I'd be open to simplifications of how shortcut sets are managed and mapped to different users. Just one of many possible ideas: I'd be open to removing all shortcut set management UI, and make shortcut sets map 1:1 to user: each user gets their own shortcut set; period. But, I think it's too late to do this for 8.0.0, unless doing this would save more work between now and then than it adds, which I suspect it won't.

I'm sorry that Shortcut has caused some teeth-gnashing among contributors working on menu system criticals. And it's unfortunate that it doesn't have its own maintainer. However, we can't recover the past losses.

The question is whether new critical and difficult issues will emerge due to Shortcut, and not have a maintainer at that time. If/when that happens, let's have a discussion about how to deal with that based on the specific technical challenges that emerge. So, postponing this issue until then.

So I spent the day looking at Shortcut module's code and looking through the issue queue and tl:dr; I would be fine signing up as a maintainer of the module.

There are a bunch of minor things I found with the module which I'll open issues for and a few major ones, that I'd like to see. The most important one already exists with #2083123: Shortcut cleanup: Remove duplicated code and deprecate legacy functions and I'll also open an issue for turning the {shortcut_set_users} table into a proper field on the User entity.

The current issue queue isn't very big and there's nothing major sticking out at the time of writing.

I agree with previous commenters that the shortcut-sets-per-user functionality is non-essential but since @Dries wants to keep it in core, I guess that's out of the discussion. I could see us splitting that functionality into a separate module, though, in the future. I.e. have a base shortcut module that just provides the whole shortcuts api and provides a single set of shortcuts, and then have a shortcut_user module that handles the per-user assignments. That's all talk and no code at this point and in any case probably too late for D8.

All in all, though, I feel comfortable maintaining the module. I would - needless to say - feel a lot more comfortable if @David Rothstein signed up as well, and I've also spoken with @jibran who is considering this also, but I've made my decision regardless.

Will open an issue for that now.

Here we go: #2426935: Make jibran and tstoeckler maintainers of Shortcut module

Thanks @tstoeckler! At this point I'm not interested in maintaining the D8 version of Shortcut, but I'm glad to see that you are :)

I really do wonder how often the per-user-shortcut-set functionality is used. Personally I've never seen it used on a Drupal 7 site. If we can find a way to remove it from the module or simplify it, I'd still consider being a maintainer again.

I'd be open to removing all shortcut set management UI, and make shortcut sets map 1:1 to user: each user gets their own shortcut set; period.

This seems like it would make the primary use case of the module (a site builder adds shortcuts for administrators to use) very difficult... they'd have to log in/masquerade as each individual administrator and set them up one by one?

(By "primary use case" I mean for a site where those roles aren't all the same person, of course... but for a single-administrator site you only need one shortcut set regardless.)

As discussed in Barcelona and agreed by pwolanin.

Lol, didn't know this still existed. This is definitely won't fix if I have a say in it, but let's have that fight when we get there.

@Crell That is not argumentation.

I would rather won't fix, than leaving a decision open forever. I am not sure removing it makes sense, given its use.

A usability maintainer on my side is enough to trigger a little boldness :-)

There's no technical argument here, this was originally opened because that would ease the menu system revamp, that's now long gone. If there are new arguments, for D9 or if we want to deprecate the module for some obscure reason, in 8.6.x or whenever, then someone can open a new issue, or re-open this one.

But ATM won't fix is the correct status, this is not actually postponed on anything.