Move the 'menu_link_content' 'link' base field widget overwrite into its own submodule

This would also mitigate the duplicate label issues in ✨ Rename "Attributes" to "Link attributes" to distinguish them from other (item) attributes Closed: won't fix as you can decide if you then have the option to NOT use the menu_link_content functionality and just use link_attributes for link fields! That's great!

Furthermore the menu_link_content part becomes more complex with ✨ Add Default menu_link_content attributes UI Needs review which is a further reason to split this into a submodule.

Great point @Grevil! :)

Will you work on this and provide a MR?

Please review!

Hello Guys
I have reviewed & Implemented the MR! on my Drupal website having version 9.5, PHP version - 8.1
The MR! has been implemented successfully. Can be moved to RTBC!
Please & Thank You.

@Grevil: Please re-review. I renamed the submodule to link_attributes_menu_link_content to align with the content type name. Additionally I think we should add a functional test which ensures the settings appear on a menu_link_content create and edit form.
Or is there already a test for that present that needs to be moved? Or prepared in ✨ Add Default menu_link_content attributes UI Needs review (which needs to be re-rolled once this is merged).

I moved the tests and adjusted them accordingly, changes by @Anybody LGTM!

Re-reviewed! Nice work @Grevil! Confirming RTBC.

@Raveen Thakur could you please review and test again?
Finally this should be signed off by @larowlan to finish 🐛 Duplicate menu item settings with menu_link_attributes Fixed and ✨ Add Default menu_link_content attributes UI Needs review which are currently postponed on this.

Sure, working on it @Anybody

Let's run the tests finally!

1. +++ b/link_attributes.module
   @@ -27,7 +14,7 @@ function link_attributes_help($route_name, RouteMatchInterface $route_match) {
   -      $output .= '<p>' . t('The link attributes module provides a widget that allows users to add attributes to links. It overtakes the core default widget for menu link content entities, allowing you to set attributes on menu links.') . '</p>';
   +      $output .= '<p>' . t('The link attributes module provides a widget that allows users to add attributes to link fields.') . '</p>';
   

   Can we mention the submodule here? Perhaps 'If you enable the Menu Link Content integration sub-module, it overtakes...'

2. +++ b/modules/link_attributes_menu_link_content/tests/src/Functional/LinkAttributesMenuLinkContentMenuTest.php
   @@ -9,9 +9,9 @@ use Drupal\Tests\BrowserTestBase;
   - * @group link_attributes
   + * @group link_attributes_menu_link_content
   

   Let's keep it using the same @group as the main module

Thanks @larowlan addressed #15, please review again.

I replaced the patch provided by https://www.drupal.org/project/link_attributes/issues/3046214 ✨ Add Default menu_link_content attributes UI Needs review with the patch in this issue 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

Just one minor thing

Commented!

See output of the current update hook:

Thanks looks good

Whoo thanks @larowlan :)

I think @larowlan forgets to credit me!

Hi Raveen, I did review the contributions and didn't feel your comment provided enough info to grant credit

What I would have liked to see testing wise in order to grant credit
- that you setup a site with the module without this change and configured some attributes on menu links
- that you applied the patch
- that you ran the update hook and it worked
- that after running the update hook the new module was enabled and that the functionality still worked for the menu links in step one

My advice would be to provide as much detail in your comments in future, IE this

I have reviewed & Implemented the MR! on my Drupal website having version 9.5, PHP version - 8.1
The MR! has been implemented successfully. Can be moved to RTBC!

is too generic for a maintainer to gauge the relevance of the contribution

I would encourage you to elaborate on what 'implemented successfully' means.

As it stands this comment doesn't give me anything to go on and hence I decided not to give credit

Thanks for asking for clarification and I hope you keep contributing 💪💧- see you in the next issue!

Automatically closed - issue fixed for 2 weeks with no activity.

@larowlan could you perhaps think about tagging a new release, containing these changes?

As described above, in certain situations, combined with other attribute modules, this will help a lot. Would be super nice to have a new release. Thanks :)

@Anybody happy to make a release, but I thought there was one other issue you were keen on.

If not, can make one now and another later

@larowlan thanks. Just went through all the issues and I think the release makes sense. We'll tackle some of the other issues soon, especially the related ones. Others could need your feedback, I think. Whenever you have the time to take a look... :)

I've used this as an opportunity to cut a 2.x branch

This went out as 2.0.0 - thanks!