With TYPO3 V7 the layout and handling of the Save – Button was changed. This lead to many (not ending) discussions in the TYPO3 community. As a follow-up some extensions were developed in order to change this. In this post I will show you the current alternatives and what my wish is for TYPO3 core.
In the “ancient“ TYPO3 4.x and 6.x times there were tiny not so shiny buttons in the top bar while editing a page or any other record. They represented the actions „Save“, „Close“ , „Save and Close“, „Save and New“ and „Save and Preview“. This was one of the most criticized things from not very active TYPO3 users. With TYPO3 V7 this changed to a dropdown containing a icon and a text description. The close functionality is still there as a standalone „x“ icon.
Publishing this change lead to many discussions within „heavy” TYPO3 integrators and editors. The overall response is „I want the old behaviour back“. In the following months three TYPO3 extensions found their way into the public to change the default behavior. Each of the is addressing this issue.
Current solutions
EXT:wh_save_buttons
This extension adds the two buttons „Save and View“ and „Save and New“ to the top bar while editing a record. The default „save“ in the drop-down and the other options will stay there as provided by TYPO3 by default.
While writing this blog post and testing it … the button „save and close“ is missing. This is the one most integrators, who I know for their daily work, need.
The extension is available at https://typo3.org/extensions/repository/view/wh_save_buttons
EXT:rx_unrollsavebuttons
This extension take all the default drop-down values, removes the drop-down and displays them side-by-side, as we were used to in the ancient versions of TYPO3. The only difference is, that the icons are shown together with the text, describing the function of the buttons. From version 1.1.0 on there is an option to hide the text available in the extension manager settings.
The extension is available at https://typo3.org/extensions/repository/view/rx_unrollsavebuttons
EXT:savebuttonsorting
The third extension takes care of the sorting of the buttons. It allows to adjust the sorting of the different save and close buttons. The User-TsConfig is the place where the TYPO3 admin adjusts the setting.
The extension is available at https://github.com/georgringer/savebuttonsorting
Conclusion
There are several extensions which might solve your wishes for the „save issue“. An interesting fact is that two of the three extensions are provided by the core team members Marcus Klein (EXT:rx_unrollsavebuttons) and Georg Ringer (EXT:savebuttonsorting).
I totally agree with the strong defaults, that are currently used in this area. But I know also many power users, who would like to have it more configurable. A hint, that this might be necessary is, that two of the three solutions are provided by core team members.
My Idea for the future
There are three levels of possible configurations:
-
Keep the configuration as is
Strong defaults are really necessary to have a common understanding of the system. This must be kept for all users as default.
-
The TYPO3 admin may change the sorting of the buttons
As with the extension „savebuttonsorting” of Georg Ringer an admin should be able to change the sorting of the buttons for all editors over the complete TYPO3 instance.
-
The TYPO3 admin enables individual configuration for BE usergroups or users
This level provides the most freedom for editors. If enabled, a editor can adjust the display of the buttons for his account. This can be the sorting, unroll the buttons or even the switch back to the tiny old icons, we were used to for ages ™.
Why … all this discussion?!
On the one hand I understand that we need strong defaults. And I’m all in for that. But strong defaults does not mean that there is no room for customization. The last years we had all options open and it needed much (some) effort to strip it down. This case is the other way around. In this case we have now a strong default which we cannot open up for power users. Each step needs explicit action for the integrator or admin to open up the possibility. Looking back to the recent years, most (a rough estimate of approx. 92.5%) of the will stick with the defaults and will not configure the backend …
The image for the blogpost was taken from pixabay and edited with Pablo. Thanks to Couleur providing this image.