Problem/Motivation
The Link render element supports supplying attributes both in $element['#attributes'] and $element['#options']['attributes']. These are combined with an array + operator, which does not combine classes when they are present in both array elements.
Steps to reproduce
As a site builder:
The Twig extension add_class() sets the class in the #attributes. For a link, there may already be a class in the #options. This happens in radix v6 for local tasks and is exhibited when viewing a page which is a secondary local task. The primary local task has a class of "is-active" and radix adds classes "nav-link" and "active", which fails.
- Install Radix v6.
- Create a page with primary and secondary local tasks.
- Visit the page with the secondary local task.
- Notice that the primary task tab is display incorrectly and contains only the "is-active" class.
As a developer:
- Create a custom module with a controller.
- Make the controller render this element:
[ '#type' => 'link', '#title' => 'title', '#url' => Url::fromUri('https://www.drupal.org')->setOption('class', ['url-option-class']), '#attributes' => [ 'class' => ['attributes-class'], ], '#options' => [ 'attributes' => [ 'class' => ['options-attributes-class'], ], ], ] - Visit the controller page, inspect the link and check that only
attributes-classclass is added to the link.
Proposed resolution
Merge the classes from ['#attributes']['class'] and ['#options']['attributes']['class'] when rendering a link.
Remaining tasks
Fix. DoneTests. Done
User interface changes
None
Introduced terminology
None
API changes
Now link elements render both ['#attributes']['class'] and ['#options']['attributes']['class'] classes.
Data model changes
None
Release notes snippet
Now link render elements render both ['#attributes']['class'] and ['#options']['attributes']['class'] classes. Some unexpected visual changes may arise due to new classes possibly being added to links.
| Comment | File | Size | Author |
|---|
Issue fork drupal-3494015
Show commands
Start within a Git clone of the project using the version control instructions.
Or, if you do not have SSH keys set up on git.drupalcode.org:
Comments
Comment #2
danchadwick commentedHere's a patch created on D10.3, but I suspect it applies fine to 11.x
Comment #3
quietone commentedChanges are made on on 11.x (our main development branch) first, and are then back ported as needed according to our policies.
Comment #4
danchadwick commentedArgh. Apparently core (and maybe contrib) creates attribute array class elements as both strings and arrays, so a cast to (array) is needed. I'd call that a bug, but that's another issue.
Here's a revised patch.
Comment #5
smustgrave commentedthank you for reporting
Fixes should be in MRs vs patches
Also will need a test case to show the problem.
Comment #8
vidorado commentedI've just created a MR and added a Kernel test :)
Comment #9
vidorado commentedComment #10
smustgrave commentedShows test coverage, reviewing that file too looks like a good number of scenarios covered.
Rest of the change appears fine
Not sure if this requires a CR for merging 2 arrays now but will let committer decide.
Comment #11
longwaveWhile this is a bug fix it's also a minor behaviour change as mentioned in the IS, so only committing this to 11.x to avoid breaking existing sites in a patch release. The MR also doesn't apply cleanly to 10.5.x so only committing this to 11.x; if you think this is worthwhile to backport please reopen with an MR against 10.5.x.
Committed ee78cfa and pushed to 11.x. Thanks!
Comment #14
longwave