Save & Edit functionality in core

This is a simple idea that would greatly improve usability and should be in core. This is one of the most common annoyances we hear from clients the first time they edit content through their Drupal interface.

I am using it in Drupal 6 and it's very useful and is working well.
I would agree this should be considered for core from a user experience point of view.

Izzy

I see only 90 users for Save & Edit, and 5445 for Node Clone. Some of that could just be from people who found node clone a long time ago and stuck with it as their solution. Seems like some sort of option like this could be desired with that many users of like or similar functionality.

actually, deekayen, you're one of the committers to Submit Again which, IMHO, is also should be considered as the sort of option for core as the above...
Himerus and I talked yesterday about how easy it would be to add that sort of 'Save & Add Another' functionality to Save & Edit, as yet another button.

What I'd really like see in core is a _checklist_ of buttons that can/will appear for a given node type:

(current core)
Submit (aka normal save)
Preview (aka normal preview, no save)
Delete (delete node)
(optional examples below)
Save & Edit (save, then re-edit, with publish or not option)
Un/Publish (ie whichever state to change to, so show 'Publish' only if currently unpublished)
Submit and Add Another (ala the way Taxonomy works, where that is the default behavior)

Maybe a hook for node_form_buttons to allow modules to easily define new buttons per content type (with corresponding function for that behavior)?
You can do this now with form_alter, but as examples of something where you usually have to custom code or use an existing module, and maybe be in core:

I want a given content type to have no preview button. Not an optional preview, but no preview button at all.
I want this other content type to behave just like Taxonomy does, keep adding items on save, until I quit
I want a button to save and also promote content to the front page, not a checkbox hidden behind a fieldset, (but only if I'm allowed to promote).

Perhaps instead of more buttons, the configuration for the content type could have a dropdown selection for handling the redirect after the save, from which the options include "View node," "Continue editing," and "Create another." Default should continue to do what it does now, show the node.

Button management is a pretty cool idea. folks will soon want to specify which roles get which buttons which tips the scale into too complex for me. if we can leave that for contrib, i'd support a core patch like this.

Note that term add already assumes save and add another. Should admin/user/user/add do the same?

You don't have to build improvements in one huge whammy. Try increments, we'll discuss the merits, and see where it goes.

re: Moshe's concern of increased complexity for button management, what about just using (mostly) existing permissions to control this?

We already have per nodetype permissions for create (aka save) and edit (own or any), and delete (own/any), and that would cover most cases (leaving edge cases for a contrib module to handle), for people allowed to deal with particular nodetypes...

Using himerus's list of potential buttons, as a (large) example :
* Save (aka: Save & Close, Save & View Node)
* Preview
* Delete
* Save & Continue Editing (aka: Apply)
* Save & Add Another
* Save & Create a Copy
* Publish (On un-published nodes)

Using 'page' as an use case example for the above:
Users lacking a 'create page' permission likely wouldn't see any of these buttons for 'page' at all, no matter what content type settings were, since they shouldn't be on a node/add/page anyway... but if they were assigned an edit permission anyway (?), Buttons for Save&Add, or Save&Copy wouldn't appear, regardless of button setting/permission (see below), since they still require a 'create' permission to function.

Similarly, users lacking 'delete page' permission wouldn't see the Delete button, regardless of button setting/permission.

Users lacking an 'edit own page' permission (but having create page) wouldn't see Save & Edit.

Users lacking 'administer nodes' wouldn't see the Publish button, regardless of button setting/permission, since they can't affect the publish default/current state without the admin permission.

Next level (contrib?): if desired, adding a per button (but not per nodetype) permission, this would add only minimal new permissions: one per button, per role. Ok, Editor role can see Save, Preview, Save & Edit, and Publish, but not the others, while a Blogger role can see Save, Delete, Save & Edit, and Save & Add Another, but not the others.

Finally: Contrib could certainly implement a per nodetype, per button, per role, permission option, but I doubt many would need to use that.

I fully support the Save and Edit button. And to jump back a bit, Node Clone is a good module for simple nodes. Although in my experience it has a hard time with CCK Filefields and other more complex CCK types. sethcohn - Good idea about the buttons. I agree 100%.

Chiming in with my two cents.

I think this functionality would be a boon to having something like hook_buttons() (hook_page_buttons? hook_alter_buttons?) in core because it certainly does improve on the user experience of drupal. All button options listed above are applicable in many different situations. One of drupal's greatest strengths (if not THE greatest strength) is pure extensibility. (e.g. add more legos to your lego ship if you want to make it cooler :)

Contrib can take care of most anything you can think of. When it comes to core user interaction, buttons which perform actions that are quickly identifiable are beneficial to all. What's the difference between Save, Publish and Release? Semantics? You can always change the text on a button. But, when it comes to functionality, users (and drupal in-turn) benefits from the following.

Apply (Save & Edit) = save 1 click
Publish (Save & Publish) = save 1 click (clicking the publish checkbox)
Duplicate (Save & Clone) = save at least one click (I would think)

Ignoring the button names used (I'm not pushing for certain button names) my point is, any time you realize a savings, and put the user closer to their goal quicker, you tend to win.

I totally think this would be a great feature to have - programmaticly and functionally.

Count me in. Great idea.

Absolutely essential for productivity, count me in too!

Sounds like a very useful function, add me to the 'core' vote.

One other thing is that a few clients have asked if it's possible to flag a warning when they shut down a window or navigate away from a page their editing. Basically, they've spent 10 minutes writing something, forgot to save it and have shut down firefox or gone to a different page by mistake (e.g. to do some research to add content to the page they're editing) and everything they've entered is suddenly gone.

If an auto-save feature or a reminder to save feature could also be included in core, that would be most handy!

It is late in the D7 release cycle. Bumping this feature request to D8.

Himerus - where did this get to?

Should this be bumped to 8.1 or 9?

I'd also like to see this. Quite annoying. Should have an option to save and continue to edit.

From the Save & Edit description:

saves the newest content edits while keeping the user on the node edit page. This feature allows users to manually save drafts as they work on site content without getting distracted by a redirect to the content page.

This should be the default action for the Save button: the user should be able to decide by themselves if they want to see the front-end of the node or to go to the list of content. And the same should happen for Taxonomies and other entities. We should decouple the action for Saving, the action for Publishing and the action for Redirecting. In here, I would focus on decoupling the Save from the redirect itself.

Moving out of the Node category as this is entity type agnostic functionality.

We have what looks like a well maintained and well used contrib module with this functionality https://www.drupal.org/project/save_edit

Do we need this in core? Given this was originally created in 2009 and there hasn't really been a huge amount of input especially since 2016 I'm not sure it has the backing required given how much it would impact.

I think #239715: UMN Usability: Where do forms redirect to? is still a problem in that there's no consistency where entity forms redirect to after saving. However if this the agreed solution to that it could use an issue summary update.

Save and edit has worked fine for me for a few projects. Maybe this should be closed and re-opened if the issue you mentioned @catch ever gets a decision.