Add option to choose widget open by default or not

Great work! Confirming this works fine and is super helpful! :)

Still needs tests, I'll see what we can do.

Applied the patch as an MR and added appropriate tests.

Note, that the "default_open" test is currently not added for the menu test, because the test will get moved eventually inside 📌 Move the 'menu_link_content' 'link' base field widget overwrite into its own submodule Fixed , if it gets approved. Please review!

Thanks for the tests @Grevil! Wondering why automated tests for issues is not enabled?

As the tests are green locally and changes LGTM, I'll set this RTBC. @larowlan would you mind to enable tests for issues perhaps?

Let's run the tests finally!

+++ b/src/Plugin/Field/FieldWidget/LinkWithAttributesWidget.php
@@ -96,7 +97,7 @@ class LinkWithAttributesWidget extends LinkWidget implements ContainerFactoryPlu
-      '#open' => count($attributes),
+      '#open' => $this->getSetting('default_open'),

This will cause a regression for existing sites as we're defaulting to FALSE.

We either need to default to TRUE in defaultSettings or we need an update hook to loop over all form displays and set the default value to TRUE for existing items

We either need to default to TRUE in defaultSettings or we need an update hook to loop over all form displays and set the default value to TRUE for existing items

@larowlan I'd prefer the second option, as I think collapsed is typically what you want in the future for a better and comprehensive UX.
Do you agree?

Do you know about any snippet in core or another module for that loop? Might be complicated from scratch...

How about we make it support three options

1) Expand if any values set (Current behaviour)
2) Collapse
3) Expand

We could make the default 1 (current behaviour) but support the two new options.

Then we don't need an update path, which I'd rather avoid

I agree! I rewrote the logic and tests accordingly.

Please review once again!

All comments resolved, please rereview.

Nice work @Grevil, I like it! Let's see what @larowlan thinks about it finally.

Great work, a few things pointed out in the MR

Thanks @larowlan
@Grevil: Please have a look next week to finish this :)

Nice!!

All comments resolved! Please review again! :)

Code looks fine to me, tests are green. RTBC from the community :)

Thanks, committed and cutting 2.0.1

https://www.drupal.org/project/link_attributes/releases/2.0.1 →

larowlan → closed merge request !11

Please note that Drupal 9 still supports PHP 7.3 and 7.4. If you're going to set the minimum supported PHP to 8, then you should consider dropping support of Drupal 9 for this version of Link Attributes so you don't cause confusion and unnecessary issue tickets.

@Jonathan_W we added the php version limit into the info file thinking that would be taken into account by composer, but it appears it isn't

I think we should create a 2.0.2 with a composer.json change to prevent that

Thanks for reaching out

Cutting 2.0.2 now

Thought so too! It doesn't? That's quite annoying...
Anyway, thanks for the fast reaction @larowlan!

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