[UX] Automatic menu link creation for nodes.

[klonos]

Use case: Force nodes of a specific content type to have links created under a specific menu (without allowing the end user to change parent menu or to not create a menu link). For example, each time a content author creates a new "Service" or "Product" node, there should always be a respective menu link created under the "Services"/"Products" menu items.

As it is now, this is not possible. The user has to remember to select "Provide a menu link" checkbox. Default Menu Link does this, but still does not handle menu parent and menu link title.

Also, there are cases where you want to force the menu link creation. Even with Default Menu Link that sets the checkbox to enabled by default, the user can still disable it even if the site admin means them not to. Modules like Menu Force come to play then.

Lastly, if you force menu creation, you need a way to also force menu link title creation/update (à la pathauto and/or pathauto_persist). Auto Menu Title to the rescue!

All these are tiny modules that count a little over 1.000 installations each, but I'm sure that these features are not uncommon. I guess others that need these resort to form_alter and the likes in custom code. Can we please consider these features for core?

[klonos]

...I was thinking perhaps now with token in core, allow the menu link title field to accept tokens?

[klonos]

The NodeAutoMenu sandbox (a D7 fork of Auto Menu) does all this in a very nice way I think:

The "Default the "Provide a menu link" item to checked." checkbox in the screenshot is because I have Default Menu Link installed.

The "Nodeautomenu handler" section is because NodeAutoMenu comes with a submodule that allows menu placement based on taxonomy. I don't think this is needed, but if someone sees a common use case for it, please let us know.

Also the "Chop first/last ancestor" options, I don't personally see a use for, but could be wrong.

So basically, an option to automatically create/update menu links and another to hide this setting from users (so to force the autocreation instead of give the option to) should be enough and at the same time not complicate the UI too much.

As I said, now that Token is going to be in core, perhaps we should add a field to allow tokens to be used for the node title and have it default to [node:title].

Here's how the node edit form looks when the "Hide menu settings" is enabled for the content type:

The text can be changed to simply say "Menu item is handled automatically. Configure" for the admin user while the whole Menu settings tab can be hidden entirely for the rest of the users.

[docwilmot]

Wouldnt that be better off in contrib though? Not a terribly common requirement, I'd think.

[klonos]

It is relatively common for most of my customers' sites. They keep coming back to me with the request to either have the option checked by default (because they forget to enable it the first time they create a piece of content and then they have to re-edit the same content just to add it to a menu) or because they find content authors having placed the menu links in the wrong (sub)menu and it messes their menu structure. Both use cases make the site owner believe that the site/Drupal/Backdrop "is not working right".

Think of this feature as the extension of what Pathauto does but for menus. "Menuauto" if you like.

[ghost]

I like this idea. I always use Auto Menu Title on my Page content type to make menu items by default and Simplify to prevent users undoing this.

Here's what I recommend (for either core or a contrib module, whatever's decided):

• A checkbox to set the default value of 'Provide a menu link' on node edit forms
• A textfield to allow tokens to make up the default menu link title
• Checkboxes to show/hide fields on the node edit form

I believe this combination of options should allow for everything discussed above...

[ghost]

I've started a contrib module with this functionality here: https://github.com/backdrop-contrib/auto_menu_settings

Nearly working. A few things todo that I'll add in the next day or two.

[ghost]

@klonos My module is ready now, so feel free to give it a test drive if you can. I'd love for some feedback before I make the initial release...

[olafgrabienski]

@BWPanda Thanks for the module, sounds useful! I've installed it on a test site and played a bit with the settings - not thoroughly tested, but at first sight it looks good!

Only issue so far: there are still some help texts using the term "node" in the menu settings tab. Can you replace them with "content" equivalents? Here's a list with the "node" terms:

• Set the default value of the 'Provide a menu link' checkbox on the node form.
• Set the default value of the 'Menu link title' field on the node form. This field supports tokens.
• Show these fields to the node author. Untick fields to hide them.

[ghost]

Thanks for the feedback @olafgrabienski! Here's the commit with those changes: backdrop-contrib/auto_menu_settings@5916238

[ghost]

Do we close this in favour of using the Auto Menu Settings issue queue, or keep it open to discuss adding this functionality to core?

[olafgrabienski]

Personally, I'd tend to close it in favor of the contrib queue but it would be good to get new feedback of @klonos and @docwilmot. (In my opinion, the menu settings based on the module look too complex for having them in core all the time.)

[klonos]

Thanks @BWPanda for putting the contrib module together 👍The use of tokens to provide a menu title is really awesome!! I cannot wait until I can put this into use next time this problem comes up 😄

...I have taken a quick look and I see some UX issues with the current implementation (some are core issues, but the many options that this module offers makes them stick out).

I agree with @olafgrabienski that too many options over-complicate things and this does not feel like core. I would like to flesh things out in contrib, and then perhaps return here to introduce a very minimal set of features. What I was going for here initially was some way that site admins/builders can use to "lock" their content types to alway create a menu item all the time, with specific settings. Exposing some/all of these settings to the end users (content authors) was not in scope when I was filing this ticket.

I promise to test this module more and provide feedback by means of ticket to its GitHub queue.

Thanks once again @BWPanda 👍

[stpaultim]

@klonos - Is this issue still relevant after #1610 was committed to core?
#1610 - [UX] Allow content to be placed into the menu by default

[klonos]

Sorry for the late response @stpaultim ...with #1610 we've allowed defaults to be set for menu options when creating content. What we are missing is a way to force these defaults. As soon as you give a user role the "Administer menus and menu items" permission, they are able to change the defaults specified, which in some (most?) cases defeats the purpose.

I would argue that even if we hid the options from the node edit form, people with this permission would still be able to edit the menu from the menu edit form. I guess we need #384 then.

[jenlampton]

What we are missing is a way to force these defaults.

I would argue that enforcing any of the defaults set on the content creation form should be left to a contrib project. Default values are always just a starting point.

I'm also not sure this request is an 80% use-case.

I agree we need #384, but I think this request was adequately handled in #1610. At the very least, we should create a new issue that specifically describes the need here, as this issue reads as a duplicate of 1610 (or rather, 1610 is a duplicate of this one)