Bug #71610

Save buttons configurable

Added by Rainer Becker almost 4 years ago. Updated almost 3 years ago.

Status:
Closed
Priority:
Should have
Assignee:
-
Category:
-
Target version:
-
Start date:
2015-11-16
Due date:
% Done:

0%

TYPO3 Version:
7
PHP Version:
Tags:
Complexity:
Is Regression:
No
Sprint Focus:

Description

The save buttons (save, save and close, save and preview) are in a dropdown in version 7.6.0 - is it possible to configure them to show up as separated buttons like in earlier versions?
I use the different actions very often and don’t get used to the more complicated dropdown action.


Related issues

Related to TYPO3 Core - Feature #78598: Expand save buttons on large screens Rejected 2016-11-07

History

#1 Updated by Mathias Schreiber almost 4 years ago

  • Status changed from New to Closed

Hi Rainer,

you can use the hook provided in typo3/sysext/backend/Classes/Template/Components/ButtonBar.php->getButtons() to change the buttons to a way you like.

In general we do not want to change the dropdown logic, since we are certain the way of adding text to the button action makes sense.
Given the fact that there are 6 save buttons in total, some with rather long text, and thinking about mobile devices for editing content, the only viable solution is the split button.

From personal experience I can at least say that it took me about two days to get used to the new way of saving things, but I haven't missed anything since.
Given the bigger area to actually click on, most times I have the impression I'm faster than before, because I don't need to "search" for the right icon to click in the first place.

#2 Updated by Rainer Becker almost 4 years ago

I still miss the direct access of "save and close" & "save and preview"...
What about a modifier key as shortcut (shift + click => save+preview, alt + click => save+close (for the non-touchonly people)?

#3 Updated by Riccardo De Contardi almost 4 years ago

My wish (but only if it is doable and is worth the work) is that the split button remembers the last used option (I mean globally, and if it is not available, falls to the default (save)

#4 Updated by Andreas Becker almost 4 years ago

Riccardo De Contardi wrote:

My wish (but only if it is doable and is worth the work) is that the split button remembers the last used option (I mean globally, and if it is not available, falls to the default (save)

+1 for that.
Or at least, make the default save action configurable via typoscript.

#5 Updated by Michael Stein almost 4 years ago

Rainer Becker wrote:

I still miss the direct access of "save and close" & "save and preview"...
What about a modifier key as shortcut (shift + click => save+preview, alt + click => save+close (for the non-touchonly people)?

+1 for that,

But I prefer:
shift+click => save+close
ctrl+shift+click => save+preview

because alt+click has an action in linux-context

#6 Updated by Markus Bischof over 3 years ago

Andreas Becker wrote:

Riccardo De Contardi wrote:

My wish (but only if it is doable and is worth the work) is that the split button remembers the last used option (I mean globally, and if it is not available, falls to the default (save)

+1 for that.
Or at least, make the default save action configurable via typoscript.

+1 for that

#7 Updated by Urs Braem over 3 years ago

Yes, many editors use the "save and close" button as standard. So for them it's a click more.
E.g. when editing page settings.

I would opt for a setting for the following variants
- Split without labels
- OR Remember last acton

(rather not the hotkey)

OR, simpler

- Always display "Save and Close" / "Save"
- Move Close without saving into dropdown, that's not so important (as you can always click anywhere to abort)

#8 Updated by Matthias Wehrlein over 3 years ago

Gonna chime in, since we recently made the switch to 7 for one of our customers.

So far no one (me included) has come to terms with the new save button since around 8 out of 10 times you just want to save and close.

Having mobile devices in mind is a nice thing but

  • I'm pretty sure mobile devices using the backend are still a very small minority (and probably will be for a long time),
  • sacrificing usability for desktop users is no real option and
  • saying that a split button is the only viable solution for mobile devices isn't really true. For starters, having to fiddle with two more clicks is even more of a burden on a mobile device and arguing with the amount of buttons is moot, since I'd have to click on the split button trigger to save and close, and that one is just as large as the other buttons.

I actually like what the guy in this forum thread did: http://www.typo3.net/forum/thematik/zeige/thema/121258/ (last post there)

He basically brought back the old buttons:

This would still scale up nicely on a mobile device and imho labels are not really necessary. Anyone taking the trouble to get into content editing with TYPO3 is able to memorize what every button does.

It appears to me that the new split button is a change just for the sake of change.

#9 Updated by Andreas Becker about 3 years ago

Sorry for bringing this up again.
Our customers and lots of my colleagues would also have an option to directly access the save and close button.
The extra click is just a waste of time, if you have to edit page settings, listitems, ...
As i can see, when searching for this problem, there is a need for making this configurable.
Why can't this be done by Typoscript?

#10 Updated by Wouter Wolters about 3 years ago

Because TypoScript is not meant for the backend ;-)

#11 Updated by Philipp Kitzberger about 3 years ago

Guess he meant TsConfig.

btw. +1

#12 Updated by Mathias Brodala about 3 years ago

Matthias Wehrlein wrote:

I actually like what the guy in this forum thread did: http://www.typo3.net/forum/thematik/zeige/thema/121258/ (last post there)

He basically brought back the old buttons:

Please no!

This would still scale up nicely on a mobile device

Not really since the hit area is way too small, no matter the device. And the TYPO3 backend is not suitable for mobile devices yet anyways. ;-)

and imho labels are not really necessary.

I'd argue otherwise. The labels vastly increase the hit area which was the no. 1 issue I always had with the old buttons.

Anyone taking the trouble to get into content editing with TYPO3 is able to memorize what every button does.

I'd argue that even this is hard since the buttons have a rather similar design. And please also keep in mind that there are cases where there are even more buttons than shown here. Separating them is really hard in this case.

It appears to me that the new split button is a change just for the sake of change.

I'd say it was necessary but we're simply not there.

#13 Updated by Clemens Riccabona about 3 years ago

Wouter Wolters wrote:

Because TypoScript is not meant for the backend ;-)

But TSconfig is, and it is kinda TypoScript, isn't it? ;)

#14 Updated by Clemens Riccabona about 3 years ago

+1 for adding the possibility to sort the dropdown entries in savebutton0 (at least) via TSconfig AND maybe (nice to have) via user-settings!

#15 Updated by Michael Christian about 3 years ago

Could you please reopen this.
I think it's very importent to add an option to use the "old, comfortable save buttons" in typo3 7 without the need to install a extension like:
https://typo3.org/extensions/repository/view/wh_save_buttons/
https://typo3.org/extensions/repository/view/rx_unrollsavebuttons/

#16 Updated by Karsten Madsen almost 3 years ago

Clemens Riccabona wrote:

+1 for adding the possibility to sort the dropdown entries in savebutton0 (at least) via TSconfig AND maybe (nice to have) via user-settings!

+1 Reopen this issue
+1 config by TSconfig, I always use save and close.

#17 Updated by Guillaume CARON almost 3 years ago

Karsten Madsen wrote:

Clemens Riccabona wrote:

+1 for adding the possibility to sort the dropdown entries in savebutton0 (at least) via TSconfig AND maybe (nice to have) via user-settings!

+1 Reopen this issue
+1 config by TSconfig, I always use save and close.

+1 for Reopen AND config by TSconfig

#18 Updated by Riccardo De Contardi almost 3 years ago

There is an open issue https://forge.typo3.org/issues/78598 that could be considered a compromise

Also available in: Atom PDF