Add Default menu_link_content attributes UI

A simple alternative would be to enable all available options for menu_link_content. I was just wondering, why the module page lists:
Supported attributes include

• id
• class
• name
• target
• rel
• accesskey
• aria-label (since 8.x-1.3)
• title (since 8.x-1.7)

but in the menu links there's only target, rel and class.

on 📌 Move the 'menu_link_content' 'link' base field widget overwrite into its own submodule Fixed , as this needs a reroll and finish (see #22) afterwards.

I replaced the patch provided by this issue with the patch in https://www.drupal.org/project/link_attributes/issues/3360374 📌 Move the 'menu_link_content' 'link' base field widget overwrite into its own submodule Fixed and I can confirm that the link attributes required for the project are still in place.
Drupal core 9.5.9
PHP 8.1.16
Link attributes 1.13.0

Back to NW not that 📌 Move the 'menu_link_content' 'link' base field widget overwrite into its own submodule Fixed is fixed!

Remaining steps:
#14
#22
#23

This applies to the 8.x-1.14 release. Note that it does not apply to the tip of the 8.x-1.14 branch, since oddly the 2.0 release was done against the 8.x branch. But it does apply to the 8.x branch at the 1.14 release tag. Changes to tests were removed since translation should not be done in PHP Unit tests per https://www.drupal.org/docs/automated-testing/phpunit-in-drupal/phpunit-... →

Re-roll for 2.1.1 release

Could someone please create a MR against 2.x to proceed here?

Opened MR

@lrwebks thanks for pushing things forward here. I left comments. Please check my assumptions, I just reviewed the code so far and didn't test it.

Before reverting the last commit or changing things, let's please talk about it and have a try. You should be able to check what I'm talking about by modifying some settings and using drush cex --diff to see what happens. I assume you'll also see the wrong results in UI, testing with 2 different fields, now (unexpectedly) sharing the same setting?

@larowlan we weren't quite sure if the existing approach was fitting this use case, as the orginal MR suggest to use field definition third party settings.

This would suggest that the settings page would have an "enabled_settings" region per field instance, but it doesn't. So if we simply want to globally set these specific settings enabled or not, we should simply stick with simple global settings instead of pivoting into using field definition third party settings (or field storage definition third party settings).

That's why @lrwebks created the global approach here in MR! 22.

If you feel like the other approach would be preferable, we need to do some UI adjustments first, along with the other adjustments mentioned in #14 ✨ Add Default menu_link_content attributes UI Needs review .

Maybe we are overseeing something, and It's not as simple as it seems at first! So feel free to give some feedback on this! 🙂👍