Add an indication of disabled menu items when they are disabled because of their parents

Interesting!

My first concern on reading this approach is that it would say "(disabled by parent)" five, ten, dozens of times if a disabled menu item had a lot of disabled children. That maybe wouldn't be the best UX.

Edit: Missed the screenshot. I'll embed it in the IS so the next person doesn't. :)

There's probably actually enough here already for a UX review; it's not too hard to look at the given screenshot and imagine "disabled by parent" 20 more times or whatever.

Also, I notice that there's still a disconnect in the form between the enabled checkboxes and the disabled label. That would also be confusing for a user. Programmatically unchecking the box would be bad too because it'd be data loss, since the user might want to retain which of a disabled menu item's children are enabled or not if they plan to turn it off only temporarily (or other usecases). And disabled form elements are also bad UX... Not sure what the best fix would be.

Usability review

We discussed this issue at #3451446: Drupal Usability Meeting 2024-06-07. That issue has a link to a recording of the meeting.

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

We tested the patch from Comment #2, and we have four recommendations:

1. Instead of adding the text, "disabled by parent", add a new column to the table. We suggest the column header "Visible", between the "Enabled" and "Operations" columns, and each row should be "Yes" or "No". If a menu link is disabled, or if any of its parents are disabled, then the new column should be "No".
2. Add a CSS class to the table row (<tr> element) with the same information. Then the admin theme has the option of using a background color as another way to indicate the state.
3. When a menu item is moved to a different parent, the new column should be updated. For example, if the original parent is disabled and the menu item is moved under an enabled parent, then the new column should update from "No" to "Yes" immediately, not when the form is submitted. The CSS class from (2) should also be updated.
4. Add the same information to the edit page for the menu item, like /admin/structure/menu/link/entity.entity_view_mode.collection/edit (for the "View modes" link in the Structure menu).

The reason for (1) is that the current solution creates too much "visual noise". The feature is most useful when the disabled menu item has a lot of children. (If it has only 2 or 3 children, then it is usually easy to see the parent item when looking at the children.) But "a lot of children" implies a lot of repetitive "(disabled by parent)" notices. We also feel that it will be easier to scan if the information is in a separate column. Since the menu titles have different lengths, the notices in the current solution do not line up.

We are not sure we like the current "(disabled)" notice. It duplicates the information in the Enabled column and is not easy to scan. But we are not suggesting that you change that: it is out of scope for this issue.

If you disagree with (1), then it would help to implement it anyway. Once we see it, we may be convinced that it is not a good idea after all.

We considered a few ways to implement (4). If we end up with the current solution instead of (1), then it would be consistent to add the same information ("disabled by parent") to the "Parent link" select list. Or we could add something to the help text (description) of the "Enable menu link" checkbox. But we prefer a third way: if the selected Parent link (or one of its ancestors) is disabled, then add a new text element below the "Enable menu link" checkbox. We did not discuss the exact wording, but something like this should work:

This menu link will not be shown because one of its ancestors in the menu tree is disabled.

If we can say which ancestor is disabled, then I think that will be even better.

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

Attempted to address the point 1, 2, and 3 from the

#6
Took the initial logic from the #2

The changes need to be reviewed along with point 4 implementation and update/write tests as well.

Thanks!

Triaging my issue queue and came across this one.

We already got a main MR just needs a rebase. Also could use a summary update to use the standard template. Also minor assertions could be added to existing tests I feel.

Seems like a good task for new users.