Drupal core Link field attributes are not sufficiently sanitized, which can lead to a Cross Site Scripting vulnerability (XSS).

This vulnerability is mitigated by that fact that an attacker would need to have the ability to add specific attributes to a Link field, which typically requires edit access via core web services, or a contrib or custom module.

Sites with the Link module disabled or that do not use any link fields are not affected.

Install the latest version:

• If you use Drupal 10.3.x, update to Drupal 10.3.14
• If you use Drupal 10.4.x, update to Drupal 10.4.5
• If you use Drupal 11.0.x, update to Drupal 11.0.13
• If you use Drupal 11.1.x, update to Drupal 11.1.5

All versions of Drupal prior to 10.3 are end-of-life and do not receive security coverage from the Drupal Security Team.

• Samuel Mortenson (samuel.mortenson)

• Benji Fisher (benjifisher) of the Drupal Security Team
• Bram Driesen (bramdriesen) Provisional Member of the Drupal Security Team
• Alex Bronstein (effulgentsia)
• Jen Lampton (jenlampton) Provisional Member of the Drupal Security Team
• Lee Rowlands (larowlan) of the Drupal Security Team
• Dave Long (longwave) of the Drupal Security Team
• Drew Webber (mcdruid) of the Drupal Security Team
• Joseph Zhao (pandaski) Provisional Member of the Drupal Security Team
• Adam G-H (phenaproxima)
• Samuel Mortenson (samuel.mortenson)
• Jess (xjm) of the Drupal Security Team

Efficient caching in Drupal significantly boosts performance, ensuring fast load times and a smooth user experience. However, misconfigured caching can lead to stale content, broken functionalities, or unnecessary server load. In this article, we’ll explore best practices for Drupal caching and how to effectively troubleshoot common caching issues.

I've been busy on other work since early January, so great to get back to contributing to LocalGov Drupal.

It’s been a while since there was a screenshotless for Experience Builder (XB) week overview, but this is one of those. Solely adding more infrastructure and evolving existing ones.

You may recall that last week, a “Publish” button was introduced that was supposed to be short-lived. It’s still around, but the server-side support for the intended UX did land this week: Ted “tedbow” Bowman and Lee “larowlan” Rowlands expanded XB’s internal HTTP API to be able to publish all auto-saved entities. In a future blog post, you’ll get to see the UX this enables!

Two weeks ago we added the Page content entity type for landing pages. We described the rationale for this more tightly controlled content entity type. We already ensured it integrates with the Metatag module, and this week Matt “mglaman” Glaman landed another step: he added a (media) image base field for SEO purposes.

On the client side, Bálint “balintbrews” Kléri and Ben “bnjmnm” Mullins refactored the foundations of XB’s Redux-integrated field widgets (which allows XB’s semi-real-time previews) into presentational components and behavioral wrappers, enabling those presentational components to be used elsewhere in the UI, not just in field widgets.

Missed a prior week? See all posts tagged Experience Builder.

Goal: make it possible to follow high-level progress by reading ~5 minutes/week. I hope this empowers more people to contribute when their unique skills can best be put to use!

For more detail, join the #experience-builder Slack channel. Check out the pinned items at the top!

Accurate previews thanks to HTML comments

Our intent is to eventually have actual real-time previews with in-place editing wherever possible (see #3453690: [META] Real-time preview: supporting back-end infrastructure for details), which requires knowing where in the DOM which component inputs appear. In Single Directory Components (SDC) terminology: where which props appear.
And before that, something far simpler: where component instances themselves begin and end. Otherwise, XB wouldn’t be able to know what hovered or selected HTML corresponds to which component instance in the XB component tree!

An important step towards landed this week thanks to Lee, Jesse Baker and Dave “longwave” Long: a Twig extension is now wrapping:

• rendered SDCs in <!-- xb-start-{{UUID}} --> + <!-- xb-end-{{UUID}} --> comments
• SDC props in <!-- xb-prop-start-{{prop name}} --> + <!-- xb-prop-end-{{prop name}} -->
• SDC slots in  <!-- xb-slot-start-{{slot name}}--><!-- xb-slot-end-{{slot name}} --> comments.

Why comments? Why not use SDC’s native data-component-id attribute? 🤔

That last question is the easiest one to answer: while SDC’s Twig extension indeed is adding that data- attribute1, this is not reliable, because SDCs are not guaranteed to have an attributes prop, and even if they do, it’s not enforced that it’s applied to the SDC’s outermost tag.2
If XB were to rely on this, it’d result in some SDCs being either incorrectly highlighted by XB’s UI, or even impossible to highlight.

Plus, 4 weeks ago XB introduced the concept of ComponentSource plugins, so we need a mechanism that can be implemented by any source of components, an SDC-only solution is a partial solution.

The intuitive (and naïve) answer might be: “well, just add the necessary wrapping markup!” — but this would break the preview! 😅 The preview MUST NOT use any additional markup: CSS selectors would no longer match, JS (think Drupal.behaviors.*) would have to be made aware of multiple possible structures, and so on.

That’s how we arrive at HTML Comments as the solution outlined by Jesse six months earlier: it can work for any ComponentSource plugin, and it doesn’t interfere with the components’ CSS and JS. And actually … XB does use the naïve but wrong approach of using a wrapper element: we couldn’t wait for all this infrastructure to exist, so now we’ll have to refactor that away.

Fun fact: I used this a decade ago for similar reasons in my renderviz proof-of-concept! 🤓

Grab bag

We noticed that tests are failing on Drupal 11.0. This is because XB added a ComponentSource plugin to support block plugins, and Drupal core only made Block plugins’ settings fully validatable in 11.1! Dave, Lauri “lauriii” Timmanee, Jesse and I solved it  by making XB require not any version of Drupal 11, but Drupal 11.1 or newer, while still retaining support for Drupal 10.4.
That means XB needs to do some backwards compatibility work for Drupal 10.4 support, but when testing against the latest and greatest version of Drupal core, XB takes full advantage of what it offers.

Week 30 was December 2–8, 2024.

• 1

  It’s adding it in  \Drupal\Core\Template\ComponentsTwigExtension::mergeAdditionalRenderContext().

• 2

  Pierre “pdureau” Dureau’s research shows that ~87% of the SDCs across a wide range of contributed Drupal themes use the attributes prop. That means that XB relying on this SDC infrastructure would inevitably lead to a frustrating experience with some SDCs “inexplicably” not working in XB.

February was a month of significant advancements, with a focus on security, accessibility, performance, and open-source contributions. Our clients benefited from the implementation of dark mode, proactive security measures, new Drupal modules and features, and improvements in AI-driven automation.

This report highlights key improvements that enhanced the security, usability, and efficiency of the platforms we support, as well as the next steps to continue delivering value.

Major accomplishments

Dark mode implementation for Syensqo

To enhance usability and accessibility, Syensqo and its network of sites now support dark mode:

• CDM USA: A platform serving US-based space and defense customers.
• Syensqo Fund: Supporting education, sustainability, and innovation initiatives.
• …