Contrib.social

Save & Edit functionality in core

Open on Drupal.org →
Created on 24 June 2009, almost 16 years ago
Updated 25 April 2023, almost 2 years ago

I would like to start off a "paper trail" of my efforts to get Save & Edit functionality in Drupal 7 core. This will be my first time proposing a feature or discussing a feature that I actually plan to implement myself, and provide patch(es) for, so keep that in mind.

Outline

I recently created the Save & Edit module for D6. This module adds some simple functionality to the node adding/editing interface. I have received some great feedback so far on the module, and now hate it when I come to a site where I can't Save & Edit to avoid losing any changes. The following features are what it currently does, and with the items I would likely need to trim out for a core patch marked through, and important core features bolded.

  • Add a Save & Edit button to node add/edit forms of selected node types
    • This, while nice would not be a part of core. It is easy enough to form_alter and change the weights and titles of buttons without having this as a built in feature. Makes sense to remove it for "trimming" the code down.
  • Allow the ability to select preference for "Auto-Unpublishing" a node .
    • This currently has 2 settings. (, and 1 to ONLY unpublish on new nodes)
    • I think only the setting for auto-unpublish on NEW nodes is actually valid. The other setting was there just in case, but doesn't seem to have a likely use case.
    • When this option is enabled, a new "Publish" button is added to the form as well helping a user quickly identify that the node is unpublished, and needs to be published in order to be visible. This can still be modified using the normal checkbox to publish or unpublish, but I felt this was needed for usability to quickly understand that a node is not "active"

Now with the features lined out that are current, and should IMHO go into core, what I need is the appropriate path to take in developing this. It is obvious that little "trim" features like this don't get some crazy configuration page under admin/settings, thus why features like custom titles and weights would be removed. It seems to me that with the minimal features that are likely valid for core, that the configuration options (enable/disable & auto-unpublish setting) should likely reside under the content type editing pages. Something that by default would be an enabled feature, but the ability for users to toggle at will.

Feedback

I guess now my next step is to see that this is a desired feature, that there is some community feedback that really thinks this really would be a good addition to core, and not just a feeling I have personally.

Please feel free to chime in with both feedback of if this should be in core or not and remain a contributed module AND a proper impelentation path that should be followed on exactly HOW the feature is integrated.

✨ Feature request
Status

Active

Version

10.1 ✨

Component
Node system  →

Last updated about 10 hours ago

No maintainer
Created by

🇺🇸United States himerus

Live updates comments and jobs are added and updated live.
Sign in to follow issues

Comments & Activities

Not all content is available!

It's likely this issue predates Contrib.social: some issue and comment data are missing.

  • Comment almost 2 years ago →
    🇩🇪Germany Anybody Porta Westfalica
  • Comment 9 months ago →
    🇪🇸Spain ckrina Barcelona

    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.

  • Comment 9 months ago →
    🇪🇸Spain ckrina Barcelona
  • Comment 9 months ago →
    🇪🇸Spain ckrina Barcelona
  • Status changed to Postponed: needs info 3 days ago
  • Comment 3 days ago →
    🇦🇺Australia acbramley

    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.

  • Comment 3 days ago →
    🇬🇧United Kingdom catch

    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.

contrib.social Blog FAQ Discussions
Production build 0.71.5 2024