Extra menu links are created on responsive preview

Created on 15 June 2021, about 3 years ago
Updated 10 November 2023, 8 months ago

Problem/Motivation

We are using the responsive preview module in conjunction with the token and menu_ui modules. When creating a node that have menu links but before saving it, when viewed via responsive preview, we are getting duplicate menu links. Some of those menu links point to /node/{uuid}. After saving the node these extra links persist and lead to 404 when clicked because node/{uuid} no longer exists. In the end we have a number of duplicate links where some of them are junk.

Steps to reproduce

Enable responsive preview, token and menu_ui.
Configure the menu block to show unlimited depth and exposed at all times.
Create a couple of basic pages (nodes) and give them menu links.
Add a new basic page.
Give it a menu link with one of the previous pages as the parent.
Select a responsive preview mode.
Exit out of the responsive preview mode.
Save the node.
You should now see 2 links for the page. One correctly pointing to itself and a duplicate pointing to /node/{uuid}.

Proposed resolution

What happened: on responsive preview the token module creates a menu link via MenuLinkContent which points to internal:/node/{uuid}.
Then when the node is saved, the real menu link is created with the correct url, but the other link is also present.

The token module checks if ($form_state->getTriggeringElement()['#id'] == 'edit-preview') before moving into the MenuLinkContent::create.

The 'edit-preview' is provided if the normal Drupal preview is used.

I propose that we set the $form_state to "edit-preview" or is_preview = TRUE. That way the responsive preview is treated like the Drupal preview by modules that would interact differently between save/isNew/update vs preview.

Remaining tasks

Patch to set $form-state in responsive_preview.

✨ Feature request
Status

Fixed

Version

1.9

Component

Code

Created by

πŸ‡ΊπŸ‡ΈUnited States oheller

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.

  • πŸ‡§πŸ‡ͺBelgium kriboogh

    might be related also to #3036077 ( https://www.drupal.org/project/token/issues/3036077 πŸ› Bug with menu item uuid when first save a node Needs review )

    I was also looking into this as some of our clients reported to have rogue menu items with uuid's.

    Looking at the condition to return if preview is being engaged, why is it only done when a new node is created? suppose an existing node without a menu item is being updated and you select a menu item and preview it? wouldn't this be the same situation? I think the menu item should only be created when an actual safe is performed.

    What @berdir said also is more logical to implement, and independent on the id naming strategy of the triggered element.
    > Maybe check what kind of submit #submit callbacks are defined and only do it for those that contain ::save?

  • First commit to issue fork.
  • Open in Jenkins β†’ Open on Drupal.org β†’
    Core: 9.5.x + Environment: PHP 7.3 & MariaDB 10.3.22
    last update 10 months ago
    77 pass
  • @kriboogh opened merge request.
  • Open in Jenkins β†’ Open on Drupal.org β†’
    Core: 9.5.x + Environment: PHP 7.3 & MariaDB 10.3.22
    last update 10 months ago
    77 pass
  • πŸ‡§πŸ‡ͺBelgium kriboogh

    I created a MR for the solution @berdir mentioned. It now checks if ::save is in the submit handlers array, and only does the create if a save is performed (new or updated).

  • πŸ‡ΊπŸ‡ΈUnited States banoodle San Francisco, CA

    Just want to report that this patch works for me and that I had this problem even though I'm just using Drupal core's previewing and not the responsive preview module.

    In my case, the extra menu link doesn't get created every time I preview the node, but in the course of several attempts I can see it happen once. Not sure why it is sporadic, but patch 6 seems to fix it.

    Thanks!

    I'm not going to set this to RBTC because I think someone using Responsive Preview should also validate this.

  • Open in Jenkins β†’ Open on Drupal.org β†’
    Core: 9.5.x + Environment: PHP 7.3 & MariaDB 10.3.22
    last update 8 months ago
    77 pass
  • Open in Jenkins β†’ Open on Drupal.org β†’
    Core: 9.5.x + Environment: PHP 7.3 & MariaDB 10.3.22
    last update 8 months ago
    77 pass
  • Status changed to Fixed 8 months ago
  • πŸ‡¨πŸ‡­Switzerland Berdir Switzerland

    Merged !43. Thank you.

  • Status changed to Needs work 8 months ago
  • πŸ‡ΊπŸ‡ΈUnited States clayfreeman Paragould, AR

    This issue introduces a major bug that breaks AJAX for form elements without a #submit key:

    TypeError: in_array(): Argument #2 ($haystack) must be of type array, null given in in_array() (line 675 of /code/web/modules/contrib/token/token.module)

    #0 /code/web/modules/contrib/token/token.module(675): in_array('::save', NULL)
    #1 [internal function]: token_node_menu_link_submit('node', Object(Drupal\node\Entity\Node), Array, Object(Drupal\Core\Form\FormState))

    The condition also needs to check whether the key exists, otherwise we may pass NULL to in_array().

  • πŸ‡ΊπŸ‡ΈUnited States DamienMcKenna NH, USA

    I opened πŸ› 3218969 breaks some AJAX forms Active for the bug, but will leave Berdir to re-close this one so the attribution isn't lost.

  • Status changed to Fixed 8 months ago
  • πŸ‡¨πŸ‡­Switzerland Berdir Switzerland
  • Automatically closed - issue fixed for 2 weeks with no activity.

Production build 0.69.0 2024