Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.
If you are attaching some option attributes to a link field (using a custom module for example), those attributes are removed on node save.
One solution is to use link_attributes, but you might not want to allow users to edit those attributes from node edit.
Comment | File | Size | Author |
---|---|---|---|
#25 | drupal-link-related-module-breakage-3056652-25.patch | 3.38 KB | maxstarkenburg |
#19 | interdiff-3056652-17-19.txt | 1.38 KB | yogeshmpawar |
#19 | 3056652-19.patch | 3.38 KB | yogeshmpawar |
| |||
#17 | interdiff-3056652-15-17.txt | 870 bytes | yogeshmpawar |
#17 | 3056652-17.patch | 3.36 KB | yogeshmpawar |
Comments
Comment #2
aalin CreditAttribution: aalin as a volunteer commentedchanging $element['attributes'] = .. to $element['options']['attributes'] is fixing this
Comment #3
aalin CreditAttribution: aalin as a volunteer commentedComment #4
idebr CreditAttribution: idebr at iO commented@aalin Can you add a test case showcasing the current failing behavior?
Comment #5
aalin CreditAttribution: aalin as a volunteer commented1. Set some custom option attributes to a field (consider that the field is not empty):
2. check that the custom options exists:
this will output: [data-ga-event] => my-event
3. go to: /node/1/edit and save
4. check again custom options on field_link:
this will output NULL
Comment #6
mashermike CreditAttribution: mashermike commentedComment #8
mashermike CreditAttribution: mashermike commentedComment #9
mashermike CreditAttribution: mashermike commentedComment #15
ranjith_kumar_k_u CreditAttribution: ranjith_kumar_k_u at Zyxware Technologies commentedRe-rolled #8 for 9.4.
Comment #17
yogeshmpawarHope updated patch will fix test failures.
Comment #19
yogeshmpawarAnother try to fix test failures.
Comment #21
smustgrave CreditAttribution: smustgrave at Mobomo commentedThis looks valid. and the test cases seem to pass.
Comment #22
smustgrave CreditAttribution: smustgrave at Mobomo commentedComment #23
catchCommitted/pushed to 10.1.x, cherry-picked to 10.0.x, 9.5.x, 9.4.x, thanks!
Comment #25
maxstarkenburgI'm finding that this change is breaking some link-related contrib. For example,
link_class
andlink_target
no longer allow edits to their respective attribute values once a field has been saved the first time (#3301937: Link classes can't be edited/updated after core 9.4.5 update and #3302123: Targets can't be updated after core 9.4.5 update (ok as of 9.4.6)), andmenu_link_attributes
has a more "additive" problem now, with replacement values just being concatenated onto the previous one (#3302105: As of core 9.4.5, can't remove link attribute values once applied). Haven't (yet) testedlink_attributes
and other modules I might not be aware of that might be affected.I don't know if the onus is on core to make a further change for this issue to work better with these modules, or whether it's on contrib to "get with the [new] program", so to speak, but in any case, since I have some affected sites where I can't just remove these modules, and also because I'm not sure about those modules' maintenance statuses, I've made a patch for core that basically reverts the change made here, to use in the meanwhile.
Comment #26
maxstarkenburgAlso, please let me know if best practice in a case like (especially where the change was already released) is to file a new issue instead of tacking on comments to the originating one?
Comment #27
smustgrave CreditAttribution: smustgrave at Mobomo commentedThink it's best to open a new issue referencing this one.
Comment #28
maxstarkenburgThanks @smustgrave, I've created #3302472: Multiple link-related contrib modules broken by #3056652 to address the breakage (should probably port the patch over there too, though am already using the above one on a few of my composer.json files, heh).
Comment #29
idebr CreditAttribution: idebr at iO commentedRestoring the issue status to 'Fixed' as a follow-up issue is available at #3302472: Multiple link-related contrib modules broken by #3056652
Comment #30
idebr CreditAttribution: idebr at iO commentedComment #32
catchI've just reverted this from the 9.4.x branch, so those modules will work again with no changes in the next patch release of 9.4.x. If the contrib modules need adapting to work with both versions of the form structure, then they should end up working with the (old) 9.4.x and (new) 9.5.x versions anyway.
Comment #33
catchComment #34
catchfwiw if an issue has very recently been committed and introduced an obvious regression, it's OK to re-open it for a revert. For every other case, it's better to open a follow-up.
I thought about this some more and went-ahead and reverted from all branches.
If the contrib module just need to adapt to the new form structure, we can possibly re-commit this to 10.1.x-9.5.x with a release note and change record.
If this was a form element I probably would have thought about this before commit, but I wouldn't have expected contrib modules to be relying on a #type => value that wasn't working in core, so it'd be good to understand why the contrib modules broke due to this.
Comment #36
segx CreditAttribution: segx commentedPatch #25 seems to be implemented and the problem is fixed in the 9.4.6 update. Please verify ... thank you!
Comment #37
maxstarkenburg@segx I did a quick test with
menu_link_attributes
on a site after updating to core 9.4.6 and can verify that the problem is now absent with regard to that module (I would assume the other modules affected are now fine again too). The original issue posted at top however is, I suppose, back to square one.