Save-Button Solution

Discussion Topic

The save-split-buttons have been a controversial topic over the last months.
The idea of this thread is to discuss a final ™ solution.
Since there are several solutions possible I’d like to discuss first and keep this initial post up to date.


  • tbd

Possible Migrations

  • tbd


  • tbd


  • tbd

Remarks and notes

none yet


Topic Initiator: Mathias Schreiber
Topic Mentor: Mathias Schreiber

Here is my rundown of the feedback I received over the last months together with an analysis of the impact.

1. Remember the last action

this offers more possible behaviors:

1.1. Remember last action per record

Example: be_user.uc.tx_news.1324.lastAction = SaveAndClose
This needs to be stored somewhere, thus bloating up the user settings too much.

1.2. Remember last action per table

Example: be_user.uc.tx_news.lastAction = SaveAndClose
Same problem as 1.1.1 in case of a lot of record types being available in the system.

1.3. Remember last action for all records in one

Example: be_user.uc.lastAction = SaveAndClose
Conceptual error: What happens if the last action is not available for the given type? Imaging news having “Save and New”, while pages does not have this action.

2. Set a default action

2.1. Set central default action

See 1.3.1, what happens if that action is not available?

2.1. Set a default action per table.

3. Responsive Approach

The current idea is to show all buttons, based on the available screen width. So on a bigger screen all actions are available and once the space is not there anymore, it collapses down to the current splitbutton.
Another feedback we got regarding “auto-learning” buttons was that supporters did not like the idea because that would mean that every system looks different in terms of “Editors call us and they have a different button than I have”.

For me, it should be like this:

  • Auto-save last action for each table by default (user settings)
  • User can configure one button to show for all tables on top
  • Integrator can force the user setting (like with all user settings) or set a different default
  • Integrator can force a behavior for each table
  • Button order is fixed, but one (the active button) can be moved to the front
  • Responsive behavior show as many buttons as possible
  • Integrator can turn labels off for all, but the active button (thus the first button always has a text, making it bigger too)
  • Save & new should fallback to Save if not available

I do not thing that storing one setting per table is a problem. Per record saving is overkill and very confusing, because then the order of buttons would appear random.

I personally would select Save&Close as default for all tables and hide the labels for all, but the active button.

1 Like

There are currently more than 3 extensions in TER.

A small feature rundown of them:

  • Enable/Disable “button-unrolling”, per user
  • Show/Hide labels for buttons (individually), per user
  • Sort buttons via pageTS config

In general we need:

  • Revisions (autosaving / revisions / reset to revision)
  • Preview (not persisted / unpublished data / revisions)
  • Clone
  • Save
  • Publish

Still the major topic is how to preselect a button.

  • We introduced the “Split-Button” to make the interface more self explaining and also group options if they are almost identical to reduce the ammount of buttons shown and have more space for descriptions
  • We decided against a preselected value for each record type because we can not guarantee that every option is available for all records also building that interface that would be nessesary because is also has to include options based on pagets for behaviour changes and userrights all of this may lead more or less to an inconsistency based on setup or just create confusions
  • We decided against a adapting value because it could lead to unintended actions - instead we preferred consistency

Example of what happens if you just want to preview data and forget about your automation.

Found some extensions in this area (mentioned by Markus):

Agree mostly with Philipp, except for:

In general we should let the editor configure the environment to their likings. Regarding support issues: there is all kinds of software to share screens and mice/keyboard.

Hello everybody :slight_smile:
I propose a different approche:
maybe the user don’t want to choose between save, save and view, save and close, save and new.
maybe the user would like that we propose him to save when he makes an action (close or view or add or quit), an only when it’s necessary.
here is a little image of what I imagine:



For me, the criteria are:

  1. One click action (when you repeat the actions, you loose a lot of time if you have to do 2 click)
  2. Buttons always at same place (having to seach of a button makes you loose time)
  3. Prevent user to do a miss-click (miss-click = loading = loosing time)

Pro of today solution:

  • User know exacly what they do (for casual user, having only icons is not enough)
  • Buttons position is fixed
  • User has less chance to do a miss-click (closing instead of saving)

Cons of today solution:

  • User don’t see all possibility at first sight
  • When you want to “Save and new” you have need 2 click

I like Rachel solution.
Instead of “don’t ask again” it would be great to have a checkbox “autosave”. In that case, you can activate “autosave” when you have repeatable actions to do, like “Save and new”


Hello, I also agree with the proposals of pgampe but I fear that it would be very hard to have everything.
so I think that it should be better to concentrate on the shortest list of features possible.
For me, they would be:

  1. decide what should be a “preferred” action (User TS or Group TS) with a fallback to “save” if the action is not available (for me, “save and close”)
  2. “responsive uncollapse” of the buttons on larger screens.
  3. make the button more visible (bigger or with a different color)
1 Like

Hi, I would suggest to take the unreleased master branch of rx_unrollsavebutton. It has a maximum flexible configuration of reordering buttons. It also has a small bug with save buttons in scheduler tasks, but I’ve fixed it already in my own fork (EXT:unroll)^^.

Take it, fix it and streamline the configuration names. Done. This feature (in general) would be the cherry on the cake for 8 LTS :slight_smile:

Hi everyone,

a usefull thing I discovered recently is opening the save menu on hover. The one click saved feels much better already and the effect is propably most achievable with 3. Responsive Approach as it potentially saves the additional click aswell.

I like the fact that the current implementation forces an active decision what to do when saving/closing. When everything is available at once it’s accessible while still having the active decision.

My concern with Approach 1 and 2 is when they fail, so you still have to be on your toes. On the other hand, working systems that take decisions from the user feel pretty great.

I like your ‘responsive approach’. While I do not like to use Webapplications on Smartphones in general, I understand, that people sometimes wish, they could. And in respect oft that, the responsive solutions feels just ‘right’.

I suggest to keep things simple for users and developers. Therefore, I support approach no. 3 because of the following reasons:

  1. Transparency: All possible actions are visible at once
  2. Ease of use: only one click needed
  3. Consistency: buttons always stay in the same position, so users find them instantly.
  4. Strong defaults for integrators: in 99% of the cases, you don’t have to configure anything
  5. No surprises, no hard-to-understand magic
  6. Low implementation and maintainance cost: Low complexity so nothing needs to be documented and nothing can get broken :slight_smile:

The approach should be combined with:

  • make “save & close” default and move it to the front, maybe highlight it (because buttons look very much alike right now)
  • a good API, so people who need customization or complex scenarios can still use extensions and extension developers have an easy job

A little off-topic:

  • I also like Rachel’s Idea regarding the separation of (pre)viewing and saving. Typically, editors want to be in control of the publication process and be able to check their work before actually publishing it. So they expect the following functionalities:
  • View last-published state of the record (if it exists) in frontend
  • Preview new record / see modified state of the record in frontend (modifications applied temporarily)

Of course de-coupling the preview from the save functionality has some technical implications but I think we should somehow move towards that. Maybe also the workspace feature, which is powerful yet a little hard to use, can be helpful in this context.

  • A “copy” or “clone” functionality would be nice for certain records

This topic was automatically closed after 28 days. New replies are no longer allowed.