Remove the default limit of 7 shortcuts per shortcut set

If this came from the UX-Team, then this is a definitive mistake - lets lose the limit. People can decide for themselves to break it or not.

Agreed with Bojhan. Let's just get rid of it altogether. Most anybody is smart enough to realize that you can't keep adding shortcuts if there's no room, and if you do, then it will overlap/break.

If you like I can come up with something like how browsers handle multiple tabs (button on left and right of toolbar to scroll horizontally). Somebody needs to design those buttons however...

Edit
On the other hand... its about shortcuts. Hard to reach shortcuts aren't really useful.

I totally support this. With my current settings and the browser window being about 3/4 of the screen width, the shortcuts do not extend to 1/3 of the window itself...

I agree, this limit should be configurable by the site admin, there could be a different limit for the toolbar and the shortcut bloc too. I added the shortcuts bloc to the dashboard, and it's limited to 7 shortcuts there too...

Just hit this limit myself and thought it was a bug.

If I create a new set of shortcuts, it says "The new set is created by copying items from your default shortcut set" and will import all the shortcuts from the default set, BUT all the shortcuts will be enabled, so, it does not take in consideration the imposed limit. Though, if you want another shortcut to the menu, it defaults to 7 active shortcuts.

my steps to reproduce:
1)add a number of shortcuts (more than seven)
2)click on edit shortcuts
3) click on "Show row weights"
4) check the "Enabled" status on all the shortcuts, click "Save"
5) refresh the entire page or go somewhere (so that the page is refreshed) => you have more than 7 links

unfortunately, it goes away when adding another shortcut (defaults to 7). but you can redo those steps until you are satisfied :)

i do not know if this is a bug...

but, in my opinion, it could be nice to let someone decide (at least the admin) how many shortcuts you can get...

hacking the core is never a good solution

i attached a print screen of my overlay menu, if it is helpful in some way

Great! This is just a workaround but greatly improves the overall experience of site management! Thanks je jorhe!

Nice trick - thanks for sharing it.

Tested patch in #4. It's working nicely.

First, i created 8 shortcuts to reproduce the issue ( one beeing automatically disabled ). I then applied the patch. 2 new empty slot appeared and I was able to enabled the disabled shortcut. I then created another one so I had a total of nine shortcuts. After adding the last shortcut 2 new empty slots were available. And by the way, the shortcuts are all displayed correctly in the shortcut bar.

Je_jorhe, thank you! Though it's pity a bit, that we have to use such a hack.

This is horrible UX, no novice Drupal site creator would ever figure this out. They'd just be confused as to why when they add a new link, the last one disappears. Then you'll get bug reports on d.o about this non stop.

It needs to provide a warning, that you're only allowed to have 7 links and then it should link to a configuration page where you can change this setting at the very least.

IMHO, I don't really see a point of limiting it at all. I assume the point was to restrict overzealous site builders, but really. If they add too many and it messes up their theme, so be it. They can remove additional ones manually. It should wrap down anyways. If I wanted to be baby-sat, I'd use wordpress :)

Commit patch #4 to Drupal 7.2. Some hunk offset warnings, but otherwise works for me. We should push to get this into next months Drupal 7.3.

Can I have a screen, what we will do when the screen size is to small to display all the shortcuts?

#17 here is a screenshot with 6 long shortcuts and a small window size. It doesn't look as pretty as it could be but it works, adding more shortcuts would just make it even worse. But I think this design issue correspond to #1137920: Fix toolbar on small screen sizes and redesign toolbar for desktop

You guys are "optimizing first" and placing limitations for everyone, when not everyone has a small screen. You guys are not using the 80/20 rule. Aka, stuff should work well for 80% of the people, not force everyone into the 20% camp.

If you have a small screen, don't add many shortcuts. It will look bad on your screen. But don't force everyone to 7 shortcuts. That doesn't make any sense.

The overflow issue should be solved properly in the theme layer, not by a limitation on the number of items.

Additionally the "Admin" bar above has 13 items, but my shortcut bar can only have 7. How does that make any sense?

Personally, I work on a screen with a 1920 pixel width. 7 items takes up like 1/5th of my screen.

This limitation needs to get removed. I see no good reason for it being here. If it stays, it needs to be configurable in the admin and people need to be warned via drupal_set_message, when they reach it.

@j0rd Sorry, but we are doing what you are asking - I dont understand the rant.

I think we might want something like a > that scrolls to more items? I don't think it's really "small" screens that are a problem here.

RTBC? It looks good, and yes scrolling should be a new issue.

Just a reroll, didn't apply cleanly with patch p0 - and not even with git apply.

great.I just stepped onto this and it was a big WTF!

Mmm, if we want to remove the limit, why don't we _truly_ get rid of by removing the 'slot support' in Drupal 8?

In other words, I'd be in favor of getting rid of functions like shortcut_max_slots() and variables like variable_get('shortcut_max_slots').

@Dries This confuses me a bit, does this mean we have to roll two patches? One to fix the D8 complete API removal of the limit, and one D7 to just remove variable of the limit? Honestly I never really got the whole backport thing, everything seems on a per case basis - and it tends to end up on having to roll two patches and reviews on two patches.

I already looked at this the other day, and it still looks ok to me.

Also agree that removing the limit entirely is D8-only material. (...but then again, we're hitting the essential question of what should and needs to evolve in the slow/stable pace of core here once more; this is a pure, single-purpose product feature [and thus a patch which I'd love to simply won't fix, ignore, send to hell, and don't care about], but since it is in core already, we have to care for it, regardless of whether we like or not. So in terms of that, adjusting the baked-in default seems more backwards-compatible to me than entirely removing it. That said, tagging appropriately.)

To clarify, I've looked at this twice and I believe it's acceptable to do this change (also in D7).

sun, we're not asking you to care about every patch. There are patches you can ignore, instead of sending them to hell. ;-)

I'd like some one to care about this issue. It's been 9 months and still no fix for this simple problem. It's making the shortcut module useless for my installs and patching every time after an upgrade is getting annoying.

This is one reason, I wish this module was in contrib instead of core. Then less people would care about backwards compatibility and this would have been resolved and long long time ago.

@j0rd I suggest you make a D7 patch to remove the limit. And a D8 patch that removes all functions etc.

I think we need to add a drupal_set_message in here when the max slots variable is set to a non-zero number and the user tries to add too many shortcuts.

@cweagons No, we are removing the limit.

Not according to the patch in #23. It changes the max slots to a variable in the variables table.

For D8, perhaps it will be removed altogether, but we can't just remove the limit in D7.

In my opinion, we should commit this to 7.x and than upgrade this to 'major' or 'critical' so we can fix it the right way in 8.x.

It's RTBC. Go for it. :)

So let's move it to #7 for webchick per #36.

subscribe

Patch no longer applies, but makes sense.

simple reroll of patch in #23 line by line

I can confirm it's just a re-roll.

The testbot ignores any patches with -d7 or -d8 at the end (those extensions should just be used when explicitly trying to prevent testbot from failing a patch for a different version).

Re-uploading patch from #41 for D8.

I'm not clear what's supposed to be committed where, but the D8 patch doesn't remove the variable, so needs work per previous comments suggesting that's what would happen.

This is why keeping track of patches for multiple versions of drupal core and/or modules in a SINGLE THREAD is not only counter-intuitive but also counter productive. The latest patches now no longer resolve the original issue, which got lost somewhere as folks started changing the version number of this, plus, anyone looking for a solution for 7.x by filtering for 7.x issues now no longer see this as a potential solution, because its assigned to 8.x.

Come on community! Get organized! Separate versions = separate issues! They have separate solutions, after all! (for example, here we simply patch 7.x, however for 8.x there has been proposed more drastic measure).

Contributing for Drupal, and finding patches at all is becoming chaotic and aggravating, primarily for this reason. I strongly urge that stopping mid-thread version modifications be considered for addition to best practices! It benefits no one, except people more concerned with keeping the issue count down.

Separate versions = separate issues!

That's not how it is. We patch the most recent version, then backport what we can.

Patch #41 works for me in Drupal 7.12

argh, here we go again, why do I run into every bug there is? ;) When will this fix be part of a core upgrade? Instead of the entire patch, couldn't I just change the one line that sets the limit to 7, to my own limit, say 10? Or is 7 hard-coded elswhere?

@flightrisk, the max slot can be configured through a variable called 'shortcut_max_slots' (see shortcut.admin.inc). Just set the variable to a number you'd want. You can use, eg. drush vset shortcut_max_slots 10 or a simple variable_set() call in a custom module somewhere.

#43: shortcut_no_limit-682000-43.patch queued for re-testing.

Re-uploading patch from #43 for D8 again.

Maybe this one works... with correct paths.
Re-uploading patch from #43 for D8 again.

Maybe this is the final? :)

For anyone wanting a non-patch quick-fix solution for this then you can always add your shortcut menu to the standard menu interface with SQL like so:
INSERT INTO menu_custom(menu_name,title) VALUES('shortcut-set-1', 'shortcut-set-1');

Then you can just enable all the items :-)

I found another way of changing the limit so that one could increase it temporarily.

Open settings.php and add this line:

$conf['shortcut_max_slots'] = 10;

Credit goes to (not me):
http://coderoach.blogspot.com/2012/05/drupal-7-increase-number-of-shortc...

The maintainer of shortcut should probally take a look at this

Well, I'm going to be honest, we should simply ditch this completely, there's a patch for D8 at #1304486: Completely remove the ability to limit the number of shortcuts per set which is so ridiculously easy to backport we can get rid of all this misery. I vote getting that in, backporting and we're done with it.

Agreed.

@j0rd #19

Well said. I found this bizarre and unintuitive. Why not do a CSS "overflow:hidden" on the shortcut bar, so the menu items just slide behind; or a fluid transition into two rows.

I knew I wasn't the only one bothered by this. =)

#66 2 years, 6 months, 9 days of waiting for D8 to bring us back to patch #4 for D7.

This is certainly one time where the patch workflow has failed miserably for something that required a simple fix.

Not sure what the best patch for D7 is, but ideally this would make it into D7 before D7 is End Of Life :)

[edited]In Drupal 7 you need to click “display line weight” to show the enable/disable select widget. Then enable as many shortcurt as one wants and save. All enable shortcuts will be displayed without any limit.

Not an efficient fix, but that works.

That being said, what it the status of this issue for Drupal 7? Looks like it's the JavaScript part that limits the number on links to 7.

Here is the D7 patch reroll (for #60 approach), i've tested, and it works well :)

So quick solution (patch) for fix D7 shortcut limit issue is #70.
Another fix (hacking settings.php): #62.
And follow #1304486: Completely remove the ability to limit the number of shortcuts per set.

A word on fix #62:
It's a very nice solution. But I think there is one pitfall. When configuring a site with multiple users/roles the extra shortcuts (number > 7) remain hidden. By enabling 'Use the administration pages and help' under permissions/roles this problem is fixed, but then you probably give the user/role a little bit too much access...

Found a nice workaround to this in Drupal 7.

Just add

$conf['shortcut_max_slots'] = 12;

To your settings.php

Credit to http://dropbucket.org/node/531

I can't have a broad smile and thank nicktr for the simplest way to deal with this issue. His suggestion may let reconsider all other suggestions and pachts draws and let think of just introduce/add this simple line of code: #$conf['shortcut_max_slots'] = ?; in the default.settings.php. Maybe its the simpelst because everyone installing a Drupal may read throughout this file sooner or later and become aware of this.

giving a try to set an end to this.

Resume
1. 3 years ago #66 bojhan set: Closed (won't fix)
2. If site admin, themer want to hack core, OK, just do it.
3. Drupal 8 next in RC
4. Leave as is or someone make the final step and go for ready to code RTC.

OK?

Thanks to everybody!

Applied manually and worked like charm, thanks a lot :)

Thanks a lot, worked on Drupal 7.38. I uploaded the file with the changes.
I am totally new so I don't know if I can actually do that or if it's safe, so do tell me if this is wrong...

uncompress the file and rename to shortcut.admin.inc and place in modules/shortcut. Make sure to change the original shortcut.admin.inc file name so you can keep it as backup.

@MahmoodZ please provide a patch according https://www.drupal.org/node/707484

elements already counted early in code

+1 rtbc

oh, missed count + no reason to call this function in loop

+1

+1, used the previous patch on two productions sites a couple years back.

+1

Re-rolling

#92 works great, thank you!