[meta-2] Finalize module-facing API of declaring menu links

Thoughts on all these;

#1. While it 'matches' routes, routes/local tasks etc. aren't entities, and we don't have a UI for creating/updating them. Sometimes it's better to be inconsistent, than misleadingly consistent.

#2 would be leaving the status quo of the current patch that's RTBC. I don't think anyone thinks that's great, but it's a relatively simple port from 7.x if we decide none of the other options are better.

#3 I really like. chx suggested that in 2010 and it seemed a good idea then too "Menu links should be simply saved from install files and not generated from router": #653784: Separate out menu links from hook_menu. We'll lose some features (like magic updating of menu items, this is only really useful for the admin menu structure, don't think I'd miss it for anything else), but those are features that are quite minor compared to the effort maintaining them.

#4 please no.

Use the Entity API exclusively: i.e., create the menu link entities directly in hook_install(), and update them in hook_update_N().

If we do this, we would have to figure out how to properly "update" menu links when a view config is synched. Something like storing the used UUID somewhere could be one approach.

So one of the questions is if you update do you have to check if the link is customized? How would all this work with translations?

Also, as much as I think the port in #2047633 is the correct next step and needs to go in ASAP, It would be nice to find a way to improve the DX for the very common use case of creating a module admin page that should show up in the various admin listings.

So one of the questions is if you update do you have to check if the link is customized?

Seems like that'd be optional, and depend on what the change is.

With translations, seems like if fields aren't translatable there's no problem. If they are it'd need to update the English version, then the others would be marked as outdated?

Please note that 1-3 are attacking technical issues only, and out of those, (3) would certainly be most logical (although the still required auto-re-parenting logic might block it).

(4), however, addresses the DX/UX of defining menu links in code for the primary use-case of associating exactly 1 link with a route, which requires you to figure out 3 independent IDs:

Architectural internals aside, I think we should primarily focus on core product experience. → How hard can it be to place my module's menu link next to or below /admin/structure/types? — Are you able to give advice to a newcomer without looking at the code/definitions?

---

system.admin.config.system
∟ action.admin.actions
  ∟ mymodule.settings

→ Menu link machine names will be completely arbitrary and will make absolutely no sense.

Care to remind me, why can't we use the route name as key + parent again?

Aside from perhaps a few edge-case modules, I've the impression that diverging from our existing 1:1 route to link mapping only causes problems with no gain for the >95% of API consumers?

Perhaps the use-cases in my entire Drupal history were not advanced enough, but I never actually felt limited by that 1:1 mapping. I think we should explore whether we cannot move the "more than one link for a single route" edge-case/use-case to a different construct; e.g., a separate hook or routing event subscriber.

---

Perhaps — and this is borderline silly, but then again possibly not — we should go back to mixing "default menu link" information into the routing definitions?

(→ so as to remove two layers of indirection and go with direct route name references for the >98% use-case instead; the remaining poor 2% can happily use a bad-ass complex facility in order to be able to register multiple links for a single route, unless their use-case isn't to be solved via routes in the first place.)

Because I believe it would be a big win for DX, I'd like to better understand the reservations of others against this.

From my perspective, I'd understand the concerns, if we hadn't cleanly separated the internal subsystems yet. But given that this is the case already, it all boils down to finding the best DX for developers only.

Perhaps as a concrete example:

 node.overview_types:
   path: '/admin/structure/types'
   defaults:
     _content: '\Drupal\Core\Entity\Controller\EntityListController::listing'
     entity_type: 'node_type'
     _title: 'Content types'
   requirements:
     _permission: 'administer content types'
+  link:
+    parent: system.admin_structure
+    title: 'Content types'
+    description: 'Manage content types, including default status, front page promotion, comment settings, etc.'

In words:

1. No more need to manually specify a link machine name.
2. No more need to separately locate the route name to associate the link to.
3. Instead of having dig out the parent link machine name (and very possibly also its associated route in order to validate that it is actually the link for the route that you intended), you simply specify the parent route name.
4. If any of the related definitions is changed, there is only one place that needs to be updated.

The data is still cleanly separated. Their definition is merely moved to the most sensible place to achieve the best DX for module authors.

To produce the above example, I had to open exactly two files: node.routing.yml and system.routing.yml. In HEAD, that's at least four files (+ node.module + system.module).

I agree with @sun here. Automatic definition of menu links from the router just makes sense. That's precisely why we have had that all those years.

(But of course, it's way better to use schema-less YAML files to define them then to use an anonymous arrays.)

The DX of #3 would be horrible for simple tasks, but another problem with it is that it solidly anchors menu links in the realm of content, instead of the one of configuration. In my experience, menu links tend to fall more frequently in "configuration" rather then "data", so this feels very backward.

So #2047633: Move definition of menu links to hook_menu_link_defaults(), decouple key name from path, and make 'parent' explicit wanted to remove the runtime t()-ing of strings for items provided by modules, but it does not do that in its current (still uncommitted) form. If/once that is removed, the translations open up to be solved for the built-in items as well. That requires having menu titles translatable (or incurring *serious* regressions). I'm not fully up to date on the effects of #2047633: Move definition of menu links to hook_menu_link_defaults(), decouple key name from path, and make 'parent' explicit for translatability. The format to be used to set default menu items needs to be defined in a way to support translatability-integration as well especially when item updates are concerned.

For me the 'simple tasks' is configuration pages under /admin, because we still have this hard-coded administration interface in system module, which in turn is based entirely on menu links.

ConfigFormBase and entity administration links gets us closer to a situation where administrative pages could be derived from information other than which routes/links happen to live under admin/* and its top-level directories, but we're obviously not there yet.

Well, if we are committed to using routes in Drupal 8, the PATH pattern admin/* shouldn't be used to determine anything, and in general paths are not canonical. So you always need both the route for the link and the machine name for the parent link.

re: #8 we do also need to start thinking of menu links as content - maybe more like book module than whatever we thought of them before.

So, possibly we should not be using this system to define the administrative interface at all?

If we want to "automate" it for the simplest cases, maybe the .info.yml file? Modules are already putting some links there using configure, e.g.:

configure: contact.category_list

I too am in favor of #3, for the reasons that catch alluded to in #1 - "We'll lose some features (like magic updating of menu items, this is only really useful for the admin menu structure, don't think I'd miss it for anything else), but those are features that are quite minor compared to the effort maintaining them.".

Menu link rebuilding is so painful, we had to invent a locking system to pause all requests until rebuild is done (more or less). I love #3 because it bypasses all that complexity and poor performance.

Can we see an example of what proposal #3 would actually look like? How much trouble is this going to be for developers of contrib modules that want to have something listed on admin/config or admin/structure?

Yep, @effulgentsia said today that he will post a mockup of what proposal #3 would look like for a module implementing it.

The issue @DamZ raises with menu links being content (versus configuration) is a relevant concern, but I think it's out of scope for this issue. It also affects other content entities that might also be more like configuration in some circumstances; for example, taxonomy terms. So far we've chosen to make both entity types content, and the scope of CMI has been that we will leave it to contrib to solve the issue of content deployment or managing situations where something we have classified as content should be treated like configuration.

Having default menu items as configuration entities instead of content would still require something like #3 anyway. The difference would be that one could also provide the menu entities in the default configuration folder to be installed automatically, rather than a hook_install(). The problem of updating from modified default configuration on a module update is still unsolved for configuration as well. Conceptually, we would make a lot of the same changes as for #3 if they were configuration entities instead.

So, I'm also in favor of the proposal in #3.

This discussion still focuses exclusively on (1) API usage and (2) maintenance, but (3) ignores DX entirely.

Perhaps my brain is simply not able to make the logical connection, but:

How can there be an agreement on #2178725: Make all core menu link machine names and the corresponding route names match to synchronize route names and menu link machine names, but at the same time, the exact proposal that would truly ensure synchronization without human interaction in #5 is dismissed?

That proposal exclusively talks about (3) DX. Because (2) the topic of whether to maintain that info is a decision internal to the system, and (1) API usage is [mostly] abstracted away.

Can you enlighten me, please?

My fundamental stance is still the same: Humans are not able to reliably synchronize any data set that is larger than 3 items. — Do NOT rely on humans for any task like that.

PS: It also helps to clarify that people are in support of option 3) in the issue summary (as opposed to comment #3) when referring to #3...

RE comment #14, the proposal for how modules would create menu links seems OK to me. As compared to hook_menu_link_defaults(), it is pretty similar and only a line or two more of code (because you have to put in the module and machine name into the function call, and call save() afterwards).

Some improvements:
- It would be really helpful if this function menu_link_create() -- which many many module developers are going to need to use, and they probably have zero use for really digging into the menu link entity otherwise -- had some documentation on which array elements in $values are actually required to create a menu link. And as you can see from the code, there are some special things like $values['description'] and $values['parent'], which are not part of the menu link entity at all. So, docs are necessary.
- If this menu_link_create() function is primarily for use in the hook_install() for modules to create their menu links, why not let it go ahead and call ->save() inside, rather than forcing developers to do that everywhere? Are there really use cases where someone would call this function and not immediately call ->save()?

RE comment #15... It seems like the main concern you are raising (if I am understanding correctly?) is that this proposal does not encourage/force people to use the same machine name for the link as the route, although we would prefer that people do that. So... Would it be possible for the new menu_link_create() function to do something like this:

if (!isset($values['machine_name'])) {
   $values['machine_name'] = $values['route'];
}

It really seems like most modules that create menu links are just trying to get something displayed on the Configuration or Structure page, and they don't care about what the machine name is for the link. At all. Why not make it easy on them and assign it automatically? There are already helpers in there for description and parent... why not one more?

Also, regarding the patch in #14 and concerns in #15, it looks like this proposed specific example of a menu link for Actions does not follow the convention of "route machine name and link machine name match"... ???

Since multiple links (in the same or different menus) can point to the same route (with the same or different route parameters) forcing the machine name to be the same as the route name is fundamentally a flawed proposal.

I also fear that doing this at install time open a real can or worms around correctly building the correct hierarchy. We depend on finding all links as part of the current process, while install-time means (I think?) that you only get the data for the one module being installed at a time?

In terms of performance, I think we should figure out a way to run this hook only when a module is enabled or uninstalled? Modules that want to programmatically create/remove links (e.g. Views) should be using the entity API.

That is a really good point about the route parameters, and I don't think anyone is advocating forcing all menu entries' machine names to match their route machine names. But I think most modules that would want to declare menu entries would be so they can get listed in the whatever-it-is-now, Tools menu? The one that generates the Structure and Configuration admin landing pages. And in most cases there, they probably should use the same machine name for their route and menu entry. So why not have the API function they have to use have this default?

So... Thinking about the proposal (3) from the issue summary, as in the patch in comment #14, am once again confused about the DX of how this would work during the module development process.

So if I am developing a module, let's say I put some stuff in my routing.yml file to define where my settings page is, and I implement hook_install() to define my admin menu link to that page to be on Configure.

Then I (oops!) realize that I had a typo in the route machine name. So I edit my routing.yml file and the hook_install() and clear the cache. Would I need to uninstall/reinstall the module in order for the menu link to be recreated correctly? It seems like I would... but actually, I guess my bad link would still be there after uninstalling -- do modules also need to implement hook_uninstall() and remove the link, or would links to non-existent routes automatically go away? Or would I need to do a hook_update_N() during my development process (ugh)?

None of this seems too great for the DX of a module developer who's early in the development process and editing things right and left, if I'm understanding correctly. Is there one of the proposals that would work better for this? And does the current system of hook_menu_link_defaults() work better for DX?

Right, so here's my proposal:

• Move the hook into the module .install file
• Restrict menu link rebuilds to module install and uninstall
• Have a button some place (e.g. menu ui module?) that does a manual rebuild
• Ask drush to add a menu links rebuild option.

Wow, that proposal in comment #24 sounds almost sane! :)

@effulgentsia

However, I don't know yet if we want to standardize/force a particular content removal decision on all modules like that. We do that for config, but we haven't really discussed yet whether to do that for content.

It'd be straightforward enough to remove links for which there's no corresponding route, that'd take care of admin routes easily enough.

Where it gets tricky is if a module adds a link for the route of another module. In that case I don't see any particular reason to remove (nor for config entities where there's no actual dependency). For those you can always just go in and delete. Annoying if you're trying out a module, less so if your site is actually using stuff it provides and you didn't know where it came from.

@pwolanin
Moving the hook to .install is interesting - worth adding that as a new option to the issue summary?

How does the explicit install/update/uninstall approach work for menu links that depend on another module, which wasn't installed yet when my module was installed, but gets installed later?

Will I have to implement hook_modules_installed() to check every module installation for whether that module has been installed, in order to create my menu links...?

RE comment #27 - how can you install a module before one that it depends on? That isn't supposed to happen?

This is a problem for soft dependencies in config entities as well:

#2082117: Install default config only when the owner and provider modules are both enabled
#1776830: [META-1] Installation and uninstallation of configuration provided by a module that belongs to another module's API
and etc.

On option #4 it's the mixing of information in the routing file, especially after so much effort has been expended to clearly separate all of this out.

The config entity issue I was actually thinking of: #2090115: Don't install a module when its default configuration has unmet dependencies

We left this as a hook because we didn't have a better idea for default content.

I feel like it's fine to ship as-is and we are wasting effort on a non-problem, versus actually dealing with all the entity API conversions and other things that need to happen.

If it's contributing to excessively slow rebuilds, then my suggestion in #24 would help alleviate that.

OK, can we add this as proposal #5 in the issue summary, to take into account that Module A might want to define different menu links based on whether module B is enabled or not?

5. Leave it as a hook, but put it into the .install file. Call the hook on all newly and previously enabled modules when any module is either installed or uninstalled, to rebuild the menu links. Have a button someplace (e.g., menu ui module?) that does a manual rebuild, and ask drush to add a menu links rebuild command.

Actually, maybe the best spot for the button would be next to the "clear cache" button on Performance, if "clear cache" would not also rebuild the menus?

I would see this new button as 95%+ a developer tool - it's not really performance related.

Clearing the cache is also 95% a developer tool. :) Agreed that rebuilding the menu is not performance-related at all; however, if you need to rebuild the menu, it's probably also true 95% of the time that you need to clear the cache (and at least sometimes, vice versa). For DX, I think it would be nice if they were available on the same page, for situations where you happen to be working in the UI (testing your new site feature etc.) rather than using Drush.

Or maybe the "rebuild the menu" button could just have another button next to it that is "rebuild the menu and clear the cache"?

That's why it's under admin/config/development...

RE #38 - well there's the root of the problem: Someone apparently made a decision at some point that menu items are Content.

It seems to me that providing a link to a module's main config page, from either Structure or Config or whatever, is really a very basic thing that pretty much every module needs to do -- and "The location of the main config page" and "whether this page logically belongs in Structure or Config and in what category" also seem like very basic module information. So telling Drupal this information should be straightforward, and it isn't really very logically like "I want my module to create a content item and then make sure it goes away when my module is uninstalled". In other words, I don't think it's "Content". I'm not even sure it's "Configuration" really... is that really something you want people to change?

So... I realize it is most likely way too late to change the fact that (apparently?) menu items are Content and not Config, and it is also probably too late to change the fact that (apparently?) the Config and Structure pages are generated from Menu content items... but these decisions seem to be problematic for the very basic need of nearly all modules to have a straightforward way to tell Drupal where their config page belongs.

effulgentsia's summary of the reasons is pretty good. I'd add that they are often programmatically created along with content entities (i.e. core did this until the book patch landed a couple of days ago), and that would get very messy with syncing configuration. Similarly per-user shortcuts were using menu links until fairly recently too - don't want those staged either.

We have a similar conceptual/implementation problem with path aliases, except we didn't even try to resolve that one at all yet and left them as a 100% special case.

Catch objects to that in #1.1, because that risks misleading people into not recognizing the architectural difference between local tasks (non-UI-editable, non-entities) and menu links (UI-editable entities)

I also think a bad implementation of content entity defaults in YAML would be worse than the current implementation in a hook. With the hook we can hold our hands up and say sorry we didn't have any better ideas. With YAML it's not going to be a proper default content API at all, but it might superficially look like an attempt to create one. And if we bake it into the router files then come up with something better for 9.x, we'll need to go into all the routing YAML and remove it again, whereas the hook is self contained.

and it is also probably too late to change the fact that (apparently?) the Config and Structure pages are generated from Menu content items...

If we had declarative admin navigation not using menu links, then just let people create menu links in hook_install() for other stuff, that would solve some of the issues here. While no-one is working on this at all, I do not think it's necessarily too late to change that - after all we're discussing changing this API and 99% of the difficulties are due to administrative link handling.

#1316692: Convert hook_admin_paths() into declarative properties on routes is relevant here, but we'd need to add descriptions and top level categories /somewhere/ to re-implement what we currently have at a minimum.

Yeah adding to what catch said, menu items are often tied to nodes too like related taxonomy terms and uploaded files, and therefore make more sense to be considered content attached to other content (like terms and files). Admin menu links are different but I've only seen proposed recently that they should use their own system instead of "the menu system". That would be interesting but way too late now?! I think.

Given that the menu system is something that almost all module developers are being exposed to, I would really like to see us move to YML files for this, for consistency with the rest of the system. Whether that means changing admin menu links from content entities to something else or not, I leave to you all to hash out. I think fixing this API is more important than fixing other API that are more 'under the hood' and only used by a select few.

RE #42, catch said in #41 that it is "not necessarily too late" to change admin navigation to not use menu links.

So, if I can summarize recent discussions:

a) There are good reasons for having menu links be Content Entities, in general (see comment #40 for a nice summary).

b) There aren't really compelling reasons for having admin menu navigation be Menu Link entities, because they're just created by modules, and it's not really necessary to have the ability to edit in the UI and add fields to etc. The reasons that they are menu item entities are: (1) they always have been menu links in the past and (2) they do have a hierarchical structure, so they share some structure with menu links.

c) Nearly every module has at least one admin navigation item to declare, so it would be good DX if declaring admin navigation items is easy to do (and a major DX regression if it is difficult to do). Because they are closely tied to routes, YML is probably preferable to a hook.

d) Creating Menu Item content entities and making sure they are updated/deleted appropriately would be a pain for a module developer (bad DX).

e) catch has stated that it may not be too late to change how the admin navigation works.

====> Could we (in a reasonable amount of time):

Devise a YML-file-based system for modules to declare their admin navigation items (including a way to declare the categories, such as Structure, Configuration, Configuration/Development, etc.), and caching/storing the admin navigation efficiently, with a "Rebuild" button somewhere (and otherwise assuming that the only time we need to rebuild the admin nav is when a module is installed/uninstalled).

Devise a YML-file-based system for modules to declare their admin navigation items (including a way to declare the categories, such as Structure, Configuration, Configuration/Development, etc.), and caching/storing the admin navigation efficiently, with a "Rebuild" button somewhere (and otherwise assuming that the only time we need to rebuild the admin nav is when a module is installed/uninstalled).

If we do make the admin navigation a 100% different subsystem, we will see problems when people use tools like panels/views
to build their own custom admin pages. Admin navigation is certainly not that static as you think.
The problem comes down that config entities "dynamically" create content entities. The current hook_menu_link_defaults rebuilding
handles that pretty nice automatically, so I would like the first alternative.

@dawehner: well, then if views would need to define an admin menu item, it would need to create a config entity then I guess? The problem is Views, etc. would need to have duplicate solutions, if the person wants to place it in /admin or /somethingelse, different code paths would run and different setup would be needed for items.

BTW a static YAML approach would work really well for translation, since we don't need to be bothered with updating the items. Especially if using config entities for that, then translation is already solved :)

There is really a deep split in the desired behavior of menu links. Some of them are very close to configuration or plugin definitions, and are rarely modified by site admins, while others are clearly content, and we want them to behave like translatable entities.

Discussing in person with xjm, dawehner, and Gabor, here's a slightly radical proposal, but which might actually satisfy the competing concerns here:

Taking a lead from the block system (and local tasks and local actions) let's make the base implementation of menu links be a plugin using YAML discovery. The custom menu links would be plugin derivates each of which has an associated content entity (like custom_block).

• The most common DX would be also defining a link in a YAML file that's similar to the admin route they just defined.
• As with local actions/tasks if you really need to do something special, you can provide a non-default class.
• The localization team has already been working out how to localize the titles from local task and action YAML files, so this could be easily extended to these module-provided menu links.
• The content entities corresponding to each custom link could use our existing machinery for content entity translation.

Some further thought/details:

• The hierarchy can essentially be reconstructed by knowing the menu name and parent ID, so the content entity should not have any knowledge of the SQL optimized storage of the hierarch (i.e. p1-p9 columns, etc).
• In place of using a simple cache, the menu link plugin manager can still use essentially the menu tree service proposed in #2207893: Convert menu tree building to a service..
• The current enabled/disabled state of each link in tracked by the manager, even though a default value is in the YAML.
• You would not be able to delete or edit in the menu UI the title of a module-provided link, but you could disable it and replace it with a custom link.
• Views module would define plugin derivates for menu links it creates, as it does now for blocks

@dawehner also made the suggestion that we could break these changes into more manageable chunks by converting to the yaml definitions first, so that the public API is complete for contributed module developers, and then continue architecting it properly internally once that change is made.

The localization team has already been working out how to localize the titles from local task and action YAML files, so this could be easily extended to these module-provided menu links.

To clarify this bit: For non default yml file ones we can extend the class and not call t(), for the ones defines in static yml files we will call t() and this is it.

+1 for the summary

@dawehner: agree with that translation direction.

+1 for the proposal in #47. Maybe it should be added to the issue summary?

added to the issue summary

Um. I think it should have been added to the end of the list, because previous comments already were referring to "proposal 1 from the issue summary" etc.

Moved it, it's now proposal #5.

Discussion last night seemed to have some reasonable comfort going forward with #47, though amateescu expressed some misgivings and desire to continue down the path purely of content entities.

An amendment to the plan concerns customizing the module-provided menu links. For those that are customized we could create a config entity per link only when it's customized OR (likely more performant) have a single config for all admin links. In either case this config would essentially record the different compared to the default for parent (maybe? using a uuid?), weight and enabled/disable. We would still block title editing so as to preserve localization. This could allow changes to the admin section to be deployable.

All the menu link plugins would have a way to invoke methods on save that allow custom data to be persisted.

In the case of module-provided links, this would involve updating the config. For custom menu links, updating the content entity. for e.g. views-provided links, updating the associated view config entity.

User entered strings in config should not be localized (passed though t()). However, we should get other people to weigh in on this part.

Here is step one: use the yml files: #2226903: Step 1: Move static menu links to yml files

@effulgentsia - I think one of the most serious Drupal WTF moments (though one people rarely discover) is that admin links are localized normally, but if you edit them, might suddenly stop being localized. I think that violates the principle of least surprise :)

Proposed the second step: #2227179: Step 2: Move the menu tree storage to a separate service. which will potentially allow us to work on parallel on some components.

Can we call this fixed? Do we need a new Meta issue?

@pwolanin meta issue would be great, so once everything is done contrib maintainers can adjust the recent changes (again).

Let's use this as a meta. I nearly had a heart attack when I saw this marked fixed. ;)

I'm just now catching up here. So that's what broke my demo module right before MidCamp... :-)

I am actually extremely wary here. We've already put a ton of work into making links entities, because entities are designed to scale. The old menu links system supported tens of thousands of links without falling over.

I am fairly confident that a content entity can scale to "tens of thousands". If it can't, then we're kinda hosed anyway because there are Drupal sites with millions of nodes.

I am not at all confident (due to lack of data) that config entities or plugins can scale to thousands. Blocks are scaling to dozens, not thousands. Are we talking about having *tens of thousands* of menu link derivative plugins? Can the system even handle that? I don't know, but we've never pushed it that far and I am very very worried that going down this route will come back to haunt us for years to come.

That's exactly the concern I raised when this plan was proposed/discussed in a call during Dev Days.

Agreed with #69, there's potentially new problems with this, but some of them are obvious and can be ameliorated.

Note I would be fine with forcing static/config entity links for admin menus, and content entity menu links anywhere else (i.e. split the system in two, avoiding the need for content menu link plugin derivatives), but I think I'm the only person that thought that was an entirely OK restriction when this came up.

You weren't the only one ;)

@amateescu, that's good to know. So I think it's OK to proceed with static + config entities as menu link plugins. Then when we get to fitting content entities to work with that, we should be prepared for the possibility that it just won't, in which case splitting it is still possible at that point. Or maybe we should re-open that discussion in a dedicated issue now?

For whatever it's worth, the distinction between "module-provided thingies" and "custom UI-created thingies" makes sense to me, too. We have already established this pattern with blocks, so it's something both developers and end-users will have some familiarity with.

The only thing I'd ask is that we take care to make the UI for "using" the thingies look and work the same regardless of what the underlying implementation looks like. In other words, we have one "place blocks" UI, and it lists both module-provided/custom-created blocks. The end user shouldn't need to know the origin of these menu links when building out their menus; the UI should work the same for both.

I'd like to reiterate what @effulgentsia said in #69 above, "The current proposal does not involve config entities", the proposed static YAML solution for admin menu items would be similar to the current local tasks and local actions solution, not as a config entity.

@Gabor, in Szeged we discussed that it would be necessary to use configuration entities (or a state() entry but that sounded bad to me) in the case that a module-provided link is overridden (title/parent/weight/disabled). Has that plan changed?

If we're not going to allow admin menu links to be overridden by the UI, then I don't see any reason for those to be treated as menu links at all - they could then use exactly the same approach to tasks/actions - just parse the YAML and create a UI from that. No editing at all.

Yeah it makes sense to somehow store the customisations in config yup.

I've posted a new meta issue for those who wish to discuss the plan we've developed to use plugins #2256497: [meta] Menu Links - New Plan for the Homestretch

I propose to mark this issue fixed if that plan is acceptable.

Removing beta blocker tag in favor of #2256497: [meta] Menu Links - New Plan for the Homestretch since this is a meta.