"Save & Edit" redirect to wrong page

I'm unable to reproduce this on either a fresh Drupal 10 install or an established Drupal 9 site using Workflows.

Are you sure the issue only comes up in 1.4 and not in the more recent 1.5 release? If you narrow it down to a specific release, could you check the release notes to see which bugfix changed the behavior for you?

https://www.drupal.org/project/save_edit/releases/8.x-1.4 →
https://www.drupal.org/project/save_edit/releases/8.x-1.5 →

Finally, see if you have any custom code affecting the module's behavior.

Hi caesius,

our system is running on 9.5.10. I have downgraded from 1.5 to 1.4. With version 1.3 the module works as expected. I think there is a bug in the function save_edit_form_alter. If I replace the code:

if (in_array($content_type, array_values($enabled_node_types), TRUE)) {
      // Let save_edit button inherit all actions from submit action.
      $form['actions']['save_edit'] = $form['actions']['submit'];
      if (isset($form['actions']['submit']['#attributes']) && is_object($form['actions']['submit']['#attributes'])) {
        $form['actions']['save_edit']['#attributes'] = clone $form['actions']['submit']['#attributes'];
      }
      $form['actions']['save_edit']['#value'] = $config->get('button_value');
      $form['actions']['save_edit']['#name'] = 'save_edit';
      foreach ($form['actions']['save_edit']['#submit'] as $key => $action) {
        if ($action == "::submitForm") {
          array_splice($form['actions']['save_edit']['#submit'], $key + 1, 0, ['save_edit_form_submit_presave']);
        }
      }
      foreach ($form['actions']['save_edit']['#submit'] as $key => $action) {
        if ($action == "::save") {
          array_splice($form['actions']['save_edit']['#submit'], $key + 1, 0, ['save_edit_form_submit_redirect']);
        }
      }
      $form['actions']['save_edit']['#weight'] = $config->get('button_weight');

with the source code from 1.3

if (in_array($content_type, array_values($enabled_node_types), TRUE)) {
      $form['actions']['save_edit'] = [
        '#type' => 'submit',
        '#value' => $config->get('button_value'),
        '#name' => 'save_edit',
        '#submit' => [
          '::submitForm',
          'save_edit_form_submit_presave',
          '::save',
          'save_edit_form_submit_redirect',
        ],
        '#weight' => $config->get('button_weight'),
      ];

Everything is working correctly. I also checked our custom code..

Looks like that code was changed in 🐛 Inline entity forms are not saving with 'save edit' button Fixed

https://git.drupalcode.org/project/save_edit/-/commit/6aa929b29913cfda95...

This may be the same sort of issue that came up and was fixed in 🐛 save_edit may share the same #attribute instance; leads to incorrect label Fixed where $form['actions']['submit']['#attributes'] needs to be a "deep copy" rather than a reference to the same attributes in the submit button.

It may be that making $form['actions']['save_edit'] a deep copy of $form['actions']['submit'] will resolve both this new issue and the issue in 3381269, making the code from that update that specifically targets the attributes unnecessary. Could you check if this idea resolves your issue?

However, I'll still need steps for reproduction on a fresh install of Drupal. Please double-check contributed modules, theme code, etc. for anything that may cause this bug to surface.

Does this patch work for you when applying against 1.5?

We have tried several ways. We have applied and reapplied all patches between the last bugs and releases. Maybe it really is an issue with the deep copy.

Thanks for the patch! Unfortunately, it does not solve my problem.

All custom modules have been removed, and the theme were checked, the bug persists.

We will test it again on a fresh installation.

Thank you for your time and the fast answer!

Hi caesius,

We have uninstalled all custom modules and also our custom theme. The problem still occurred.

Then we used the hard copy from your patch.

$form['actions']['save_edit'] = unserialize(serialize($form['actions']['submit']));

We also added several loggers to look at the form array in the different states. Then we noticed the following log of the save_edit array:

Array
(
    [#type] => submit
    [#value] => Save & Edit
    [#submit] => Array
        (
            [0] => ::submitForm
            [1] => save_edit_form_submit_presave
            [2] => ::save
            [3] => save_edit_form_submit_redirect
            [4] => Array
                (
                    [0] => Drupal\content_moderation\EntityTypeInfo
                    [1] => bundleFormRedirect
                )

        )

    [#access] => 1
    [#weight] => 5
    [#name] => save_edit
)

In [4], the content moderation module makes a redirect. Maybe you don't have this module installed and therefore couldn't adjust it?

If we delete the [4] out of the array, the module works as it should!

unset($form['actions']['save_edit']['#submit'][4]);

Hope this is helpful!

I do have Content Moderation enabled on the Drupal 9 site which has been using Save & Edit v1.4 for a while with no issues. I have also tried enabling Content Moderation on a Drupal 10.1 fresh install and applying it to the OOTB "Basic Page" content type along with Save & Edit default configuration. I still am unable to reproduce this issue on a fresh install.

Try to reproduce the issue on a fresh install of Drupal with only Save & Edit and Content Moderation enabled (plus other core modules if you find they're needed) and narrow down the issue very specifically to something in your setup or configuration.

Also, we shouldn't just be unsetting the 4 key of the submit handler since we have no way of knowing that that element will always be the one we need to unset; at the least we should be checking if it's the one that has bundleFormRedirect in it before unsetting it. But first we need to find out how it gets there in the first place.

The submit handler you're unsetting seems to come from this line of code: https://git.drupalcode.org/project/drupal/-/blob/10.1.2/core/modules/con...

You will notice that it only triggers within an elseif block; I have not checked to see if the initial if normally gets triggered instead with an OOTB setup like the one I've tested.

Does this patch work for you? It's only experimental/proof-of-concept and won't necessarily be applied to the project even if it works and we find steps to reproduce the issue.

The patch is working great and resolved our problem! Next, we try to reproduce this issue on a fresh D9 install.

One thing I'd suggest if you're having trouble reproducing the issue is checking the weight of the Save & Edit and Content Moderation modules.

Hi caesius,

I can recreate the behavior with a standard installation (https://simplytest.me/).

For this, I simply called the page https://simplytest.me/ and selected as module the save_edit in version 1.4.

After deploying the instance, I only activated the modules "Workflows" and "ContentModeration". It is important that the workflow is then also enabled for the content type.

Now, I just created a new article and saved via save_edit from Draft→Draft status. Here it jumps to the last version.

Hope this helps!
Daniel

Attached is a video that starts from login on a brand-new instance and installs / configures the required modules here.
Following an example, which shows that clicking in Save & Edit it redirects to the latest version and not in edit mode.

BR
Daniel

Thank you, Daniel! I was also able to reproduce it on a fresh install with these steps.

Okay, I see that the issue comes up when editing content that is Published but has a newer revision in a Draft state. I think this may only rarely come up in my client's case because "Save & Edit" is usually only used when making substantial edits to content, which is most often when drafting brand-new content rather than making edits to drafts of published content.

I'll commit my patch to dev shortly, and if nobody finds any issues with the patch I'll prepare a stable release.

Thanks for the patch and the quick solution to the problem.

I just want to note that this is not a special case for us to work on a draft which already has a published version.

We use Drupal to write manuals and product documentation. There are permanently new drafts written from already published pages to cover the changed requirements or extended functionalities. An intermediate saving of a draft (draft to draft, where there is a published version of the page) is very common in such a case.

So thanks again for the fix, which we will of course integrate and test on our pages.

This fix is now in 8.x-1.6

Thank you for the fix, works great!

Well, this issue came up for me again, this time when upgrading the Group module to version 2.

The problem was this redirect:
https://git.drupalcode.org/project/group/-/blob/4dc40e9660f25b5e1c5f2178...

  if ($entity->access('view')) {
    $form_state->setRedirectUrl($entity->toUrl());
  }

Looking over the save_edit module code, I realized there is an easier way to solve this issue in more contexts:

      foreach ($form['actions']['save_edit']['#submit'] as $key => $action) {
        if ($action == "::save") {
          array_splice($form['actions']['save_edit']['#submit'], $key + 1, 0, ['save_edit_form_submit_redirect']);
        }
      }

I don't think it's necessary to have the submit redirect come right after ::save -- the old, pre-1.4 code hardcoded #submit to look like this:

        '#submit' => [
          '::submitForm',
          'save_edit_form_submit_presave',
          '::save',
          'save_edit_form_submit_redirect',
        ],

So, I think all we have to do is ensure our redirect handler is last.

Okay, I think this should be resolved for real this time. I'll let this sit on 1.x-dev for a bit before releasing it in 1.7.

Updated fix is now in version 1.7.

Works great!