#ux

Patch for 8.x-2.x attached!

Ah I see it's not a bug in the patch, the patch is for 3.0.x and applies for 2.x but in 2.x there's no such use statement... -.-

So I'll create a separate MR for that.

Patch has a bug! Use statement for TranslatableMarkup is missing!

I'll fix that now.

We discussed this issue at ✨ Warn user when entity delete will cause menu item re-parenting Needs review . That issue will have a link to a recording of the meeting.

Thanks for working on this issue. At least one attendee has run into exactly this problem, and there were a lot of child menu items involved.

For the record, the attendees at the usability meeting were @benjifisher, @rkoller, @simohell, and @worldlinemine.

When you tag an issue for usability review, please make it easy for the usability team to review the issue. Update the issue summary:

• The "Proposed resolution" section should describe all the changes made in the issue.
• The "User interface changes" should show the existing UI and the proposed UI.
• The "Remaining tasks" should include one explaining the usability issue(s).

Most of the time, I prefer to have plain text in the "Proposed resolution" section and screenshots in the "User interface changes" section.

You can also attend the weekly usability meeting to present an issue.

Usability review

We have a few recommendations:

1. Shorten the text in the confirmation form.
2. Suggest changing the parent of the menu item before deleting it.
3. Special treatment when deleting custom menu links.
4. Follow-up issue: provide an option to delete the child menu items.

Shorten the text

There is room for improvement, but this is the best we could do during the meeting. After the standard "This action cannot be undone.", either

Deleting this [content item] will make these [count] child menu items top level:
...

or

Deleting this [content item] will move these [count] child menu items under [parent link]:
...

Make adjustments for singular or plural, as the current MR already does.

Suggest changing the parent

A good status message starts by describing the situation, but then it suggests what to do about it. In this case, a common action will be to change the parent of the menu item that is going to be deleted: then, after deletion, all the child menu items will be children of the new parent.

Changing the parent item can be done from the menu page (where all the items in the menu are listed, with a click-and-drag interface), from the edit page for the individual menu link (where the parent can be selected from a list) or from the edit page of the content item. We feel that the click-and-drag interface is problematic. There might be permission issues with editing the menu item, but that gives the most flexibility.

If the user is deleting a content entity (not a custom menu link ... see the next point) and the suggestion is to edit the related menu link, then it would help to give a link to that edit page.

We do not have suggested text, but this information can go after the list of affected child items.

Special treatment when deleting custom menu links

Custom menu links are content items, so the warning gets added to the confirmation form when deleting a custom menu link. So far, so good! But the text on the current MR, when deleting a custom menu link, includes "The menu items for this custom menu link", which does not make sense. Pay attention to the case where the content item being deleted is a custom menu link.

With the text proposed earlier, that entire sentence is removed, so maybe we do not have to worry about it. But keep this case in mind while continuing to work on this issue.

Follow-up issue

Sometimes, the user will want to delete the child menu items instead of move them to a different parent. There are a lot of things to be considered here, so we recommend adding a follow-up issue to discuss how to implement this. Maybe the right thing to do is turn the menu page into a form that allows bulk operations. Maybe there should be an option on the confirmation form, or the edit form for a custom menu link, to delete children. Should that include all descendants? How can we make it clear whether we are deleting content entities or their related custom menu links?

If you want more feedback from the usability team, a good way to reach out is in the #ux channel in Slack.

As per https://www.drupal.org/project/drupal_cms/issues/3460638 📌 Write content for Product Page/Section Active I believe this issue has now been delivered as https://new.drupal.org/drupal-cms which can be iterated in live. I will move status to 'needs review' for now, so please comment if you feel there is more to do here.

Hey @mattyg77,

I have reproduced the issue on version 6.0.0-rc2 on my local, and the issue seems to be of the configuration settings of the theme.

I have applied the settings you have mentioned in the screenshot attached and was also facing the same issue.
On some research I got to know that the cause of the issue is the "Fixed Position" Checkbox being enabled in your settings, under : "Header & Main Menu" > "Mobile Header" > "Fixed Position".

Disable the option ( remove the check from the checkbox ) and save the settings, see if the issue still persists. As for me it was resolved after doing this.
If it works as mentioned we either need to change the issue summary and check the functioning of "Fixed Position".

Please let me know if this works and anything else I can help with.
Thank you !