Contextual links are broken

There are 2 approaches we can take to address this:
1. Add support for `contextual` module as an exception to passthrough it's styles.
OR
2. Implement our own support for the contextual links if #1 is not possible.

I suggest doing a small POC for #1.

You will forward patch this to 1.8? Usualy it gets fixed in main and then backported?

Is this the issue about getting the contextual edit links to work? I recall we discussed it but I'm not sure if i need to create a new issue for it.

The `Version` field purpose from https://www.drupal.org/docs/develop/issues/fields-and-other-parts-of-an-... →

Normally, set this to the current development version of the project, rather than the exact release version where you noticed the problem. For Drupal Core, see also the page on backport policy.

This is puzzling me, because this means that all of the issues would need to have their version field changed every time we release. But I will comply.

It's your project! - however you like is fine. I didn't know if you changed it because you thought it was already fixed in 1.8.

Any update on this? The Drupal editing experience is super broken.

HI @sime, is there another way to access the links that are in this menu? If so, then I would not label it as a major priority.
I can consider this for the next release, but I would like to know how it affects the user experience. As a content editor, it has not been a problem for anyone as yet. No devs have reported it, you're the only person who has noted this issue (clearly it's an issue of course, but this is about priority). Thanks.

Thanks Fiona. I'm happy with you setting priority, as long as there is some engagement about it and I can point clients to the status.

Contextual is not a crucial module however it's one of the best tools to assist site builders. It's the easiest way for site builders to manages elements on a page regardless how the page is built/assembled. Without proper contextual link support, it's a hassle to figure out where to manage a piece of information on a page. Is it a block, a view, an entity, or just some static content? With Layout Builder, a page can be assembled from all kinds of building element and Contextual links help site builders not scratching their head digging in the admin area to figure out where to manage a small piece of content.

I think it's crucial in a highly abstracted setup. The editor does not always know where content is coming from.

@richardgaunt please check this out and provide SD so I can assign to get fixed. Thanks.

@sime I agree re: importance. I will look into and work out how to fix this week, apologies for slow reply.

I acknowledge it's potentially tricky btw. It was convenient to remove extra classes at some point, and maybe adding them back will introduce regressions.

I've debugged this and the problem is that the list of links does not receive the 'contextual-links' class. If this class is added - everything works (you can try this by editing a <ul> element with Contextual links in the Web Inspector console and adding the 'contextual-links' class).

It does not receive the class because CivicTheme does in `civictheme_convert_attributes_to_modifier_class()` function:

// Remove class from attributes to avoid duplicated 'class' attribute on
// the element.
unset($variables['attributes']['class']);

As it can be seen in the comments, the intention here was to remove duplicated classes: for modules and themes classes are added via `$variable['classes']`, some through `$variables['attributes']['class']` etc; this function tried to unify this and convert to a UIKit's `modifier_class` property - this property is used in all component to set a CSS class. It was deliberately separated from unexpected use of attributes like `class`, `classes` and `attributes` - try searching the Drupal core and contrib for `{{ class` and you will see that some use `{{ class }}`, some `{{ classes }}` and some `{{ attributes}}`) The problem lies in the Drupal API that treats classes as special attributes, allowing developers to use both `{{ classes }}` and `{{ attributes }}` in their Twig templates.

So, this function cannot predict how core, module and theme developers are going to build their twig templates. This is why CivicTheme uses an opt-in mechanism - to guarantee that visual consistency until a module or theme are explicitly opting in to have their classes correctly specified in the template. The opting-in itself could be in a form of a custom template override which uses `modifier_class` variable directly within `class` attribute on the HTML element OR a preprocess that sets `$variables['modifier_class'] = FALSE`, which disables removal of `$variables['attributes']['class']` value.

I hope this clarifies why CivicTheme strips away classes. Now back to the problem.

The Contextual links are rendered using the `links.twig.html` which are relying on attributes:

<ul{{ attributes }}>

---

Possible solutions
1. `links.twig.html` - override within CivicTheme to use a custom component consisting of the UIKit's menu/navigation, which use `modifier_class`.
OR
2. Add preprocess for the contextual links and set `$variables['modifier_class'] = FALSE`. This will prevent the processing.
OR
3. Remove the `unset($variables['attributes']['class']);` and hope that duplicated classes will not break websites (they will as history has shown).

We're now facing this issue on a sub theme based on civictheme

@alex.skrypnyk
I have tried out placing the links--contextual.html.twig in the subtheme but that didn't work well.

I tried to accomodate another advice by placing directly in civictheme_preprocess_block__system_branding_block and that also didn't work either.

$variables['modifier_class'] = FALSE;

Hi @naveenvalecha this work should be picked up next week. We're working on some form elements work at present, and once that is done we'll move onto this issue. I believe the team has a fix in mind for this one.

We have this issue being actively worked on, apologies for the delays.

A fix has been merged to develop and is being tested.

Verified and tested on 1.x-dev

Testing Results:
1. Contextual links are not broken - PASS
2. Tested contextual links for webform and on the layout builder pages, they work as expected - PASS

Screenshots: