Replace menu node form additions with entity reference field [#1911080]

Now that #1801304: Add Entity reference field is in and #916388: Convert menu links into entities is Rtbc I think we should be giving consideration to using an entity reference field to replace the menu module's node form additions. We have issues to convert path #1751210: Convert URL alias form element into a field and field widget and comment #731724: Convert comment settings into a field to make them work with CMI and non-node entities to field API. This would
*let us have menu integration for more than node entities
*Let us keep track of multiple menu links for one node
*Remove code that looks up link path in the menu links table in order to find an association and instead use a first class reference
*Unify the way to add form elements to an entity form, less form alter, more field API

With the entity reference field slated to replace taxonomy reference there already has to be logic to auto create taxonomy terms, it could be extended to auto create menu links for this instance and would be utilised on the node form when adding a new link

Comments

Comment #1

sun

German

Karlsruhe

CreditAttribution: sun commented 7 February 2013 at 20:32

Issue tags:

+API clean-up

+1 Absolutely.

Just to clarify one detail: Path/URL aliases are not entities right now, so #1751210: Convert URL alias form element into a field and field widget currently turns the comparable Path module node form addition into a Path field + widget (but without formatter). The field saves the actual user input (mainly for posterity, but also for maintenance operations). However, the field widget dynamically loads the actual path/URL alias record, so the user is guaranteed to work on the latest/current values.

This separation turned out to be very helpful for the concrete case of path/URL aliases, since the user input does not necessarily map 1:1 to the actually stored records. It also allows you to wipe out your entire {url_alias} table + regenerate it from the actual stored field values.

After converting menu links into entities, we'll face a similar problem space with the (entity reference) field widget:

We need to be able to create a new menu link entity from within the wrapping node/content entity form.
Changes to menu links need to be reflected in the field values of all content entities.

Just trying to think a bit through this ahead of time. Not meant to state any/actual unresolvable blockers. We'll work it out. :)

Comment #2

andypost

he/him

Russian

CreditAttribution: andypost commented 11 February 2013 at 16:08

+1 to this. Also we have landed #1803586: Give all entities their own URI and coming #1839516: Introduce entity operation providers
The only question how to make a multiple language dependant url_aliases as currently we have in D7

PS: Taxonomy term has url_alias but does not have menu item which could be easily done here

Comment #3

larowlan

🇦🇺🏝.au GMT+10

CreditAttribution: larowlan commented 22 February 2013 at 06:12

So had a think about this and bounced some ideas of timplunkett.

At the moment menu_links is a required module.
So entity reference can rely on it always being available.
We don't want to make entity reference required by node or menu_link.
So I see this being done in the following parts:
* menu_link includes a widget (if required) that does the new menu link entity creation from a widget form callback or via hook_field_insert as needed
* entity reference includes a util function like node_add_body_field() that allows simple creation of a pre-configured menu link entity reference field, it accepts an entity type and bundle
* standard.install includes creating this field on both node types it ships with by calling the util function
* standard needs a dependency on entity reference

Questions:
* Do we have hook_node_type_insert() somewhere that auto-adds this field to any new node types?
* Or do we assume that this isn't required? I've always found it annoying that core assumes you want menu links (just like it assumes you want comments and a body field) so maybe not auto-creating these isn't a big deal.
* If we do want auto-creation of these, where does the hook_node_type_insert() sit? In entity_reference? In the install profile?
* We're assuming that auto-creation is required for entry level site builders, but some experienced site builders might want entity_reference but not the auto-creation of menu link reference for each new node type.
* If we put it in standard profile (because profiles are just special modules) we could bundle it in the most suitable spot for an entry level site builder - most new site builders would use standard so would get the auto-creation for new node types. Experienced site builders would use their own install profile and forego this convenience for flexibility.

Thoughts?

Comment #4

amateescu CreditAttribution: amateescu commented 22 February 2013 at 15:56

Component:

menu.module

» menu_link.module

That sounds like a good plan. Let's take it step by step :)

* entity reference includes a util function like node_add_body_field() that allows simple creation of a pre-configured menu link entity reference field, it accepts an entity type and bundle

Created a separate issue for this: #1924774: Add a helper function for easier creation of a entity reference instance programatically

* standard needs a dependency on entity reference

This is already happening in #1847596: Remove Taxonomy term reference field in favor of Entity reference

* menu_link includes a widget (if required) that does the new menu link entity creation from a widget form callback or via hook_field_insert as needed

I'm not sure we should restrict ourselves to a menu link entity widget, why not create a generic one? Anyway, that could be split into its own issue as well.

After all that, what's left to do here is only:

* standard.install includes creating this field on both node types it ships with by calling the util function

which should be a pretty small change once we get everything else in.

About the question wheter we want to autocreate this field on each node bundle like the body field, I would say NO :) It's easy enough to add an existing field from the Field UI..

Comment #5

Gábor Hojtsy

he/him

Hungarian

Hungary

CreditAttribution: Gábor Hojtsy commented 2 May 2013 at 15:02

Issue tags:

+D8MI, +language-content

This would be AMAZING for multilingual, because it would cleanly let you edit the menu item related to the proper language version of the entity and/or set certain entity types to not have translatable menu items, etc. This would open so many possibilities, it is mind-blowing. Who is up to working on this? (Putting on D8MI for tracking but I don't actually have anybody idle to work on this for the foreseeable future unfortunately).