destination parameter in link prevents reaching "discard changes" confirmation page

Created on 17 June 2021, over 3 years ago
Updated 4 September 2024, 5 months ago

Problem/Motivation

I appreciate the existence of this module (I honestly wondered why this didn't come with core LB). I noticed an issue, however, when recently using the link it provides (my apologies if it's possibly related to other factors of my site ... I couldn't get simplytest.me to spin me up an instance today). When using it from /admin/content to get to the Layout tab of a node, I seem unable to "Discard changes" (which unlike "Save layout" has a 2nd confirmation step). I'm just returned to /admin/content after clicking it without the changes discarded.

Steps to reproduce

  • With this module installed, find a node at /admin/content that uses LB and allows overrides
  • Follow its "Layout" operations link
  • Notice that the URI is /node/{nid}/layout?destination=/admin/content instead of just /node/{nid}/layout
  • Make some change to trigger the "You have unsaved changes" status message
  • Click the "Discard changes" button. Instead of being taken to the "Are you sure you want to discard your layout changes?" page, you're instead moved back to /admin/content
  • Return to the Layout page and notice that you still have unsaved changes.

Looks like this is also true with the "Revert to defaults" button (though for my site I've removed that button via a custom module).

Proposed resolution

I'm not sure? While I happen to be no fan of ?destination parameters in most Drupal admin contexts, it could be that removing them for the link this module provides might interrupt somebody else's workflow who is using the operation link to get to the Layout tab and mostly just save changes (and wants to return to the content list). It could also be that maybe this isn't necessarily this module's problem to resolve (i.e. like maybe these core buttons should be able to more robustly handle LB pages with ?destination parameters in the first place)? So I guess I'm kind of just putting this issue out into the world; maybe other modules have also dealt with this kind of situation in ways I'm unaware of. Thanks.

Remaining tasks

User interface changes

API changes

Data model changes

πŸ› Bug report
Status

Fixed

Version

1.0

Component

Code

Created by

πŸ‡ΊπŸ‡ΈUnited States maxstarkenburg Washington, DC

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.

  • πŸ‡ΊπŸ‡ΈUnited States Chris Burge

    πŸ› Allow form redirects to ignore ?destination query parameter Fixed was committed and released in D10.2.0: https://www.drupal.org/node/3375113 β†’

    Here's the code I used to attempt to implement the fix:

    function layout_builder_operation_link_form_alter(&$form, \Drupal\Core\Form\FormStateInterface $form_state, $form_id) {
      if ($form_state->getFormObject() instanceof \Drupal\layout_builder\Form\OverridesEntityForm) {
        $form_state->setIgnoreDestination();
      }
    }
    

    I confirmed with my IDE that ->setIgnoreDestination() is firing; however, the destination query parameter is still being rendered. I don't believe the "fix" addresses the use case for operation links. I think we might just need to update the comment in layout_builder_operation_link_preprocess_links() to remove the reference to the core issue we were waiting on.

Production build 0.71.5 2024