webjoke.de

With so many blogging platforms available in 2025, why should you consider Drupal over WordPress, Ghost, or Joomla? While WordPress is widely known for personal and small-scale blogging, Drupal excels in flexibility, security, and scalability, making it an excellent choice for professional bloggers and content-heavy websites. If you’re serious about blogging and need a powerful, future-proo

Project: Drupal coreDate: 2025-March-19Security risk: Moderately critical 13 ∕ 25 AC:Basic/A:User/CI:Some/II:Some/E:Theoretical/TD:DefaultVulnerability: Cross Site ScriptingAffected versions: >= 8.0.0 < 10.3.14 || >= 10.4.0 < 10.4.5 || >= 11.0.0 < 11.0.13 || >= 11.1.0 < 11.1.5Description: 

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.

Solution: 

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.

Reported By: 

• Samuel Mortenson (samuel.mortenson)

Fixed By: 

• 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

Adding Sidebars to the Radix base theme for Drupal James Oakley Wed, 19/03/2025 - 18:25

This is the third post in a series. I wrote about my experiences moving this website from Drupal 7 to Drupal 10, and then zeroed in on theming the site using Radix as a base theme. Out of the box, Radix subthemes don't generate sidebar regions for block placement, something many websites want.

As a way to illustrate theme development using Radix, and as a recipe for a common site-building requirement, this post will walk through how to add sidebars to a Radix subtheme.

You might find it helpful to go to Home > Administration > Configuration > Development >  Development settings, and check the box "Twig development mode". This makes Drupal include a load of HTML comments in your page so that you can see which Twig components are being included where. It can be very helpful trying to find what files to adjust to get the changes you want.

Step 1: Install Radix composer require drupal/radix drush then radixStep 2: Create a subtheme

For the purpose of illustration, I'm going to name my subtheme cherry. You'll obviously pick your own name, so throughout the recipe simply substitute your name for mine.

In this and the next few steps I'll follow the Radix theme getting started guide.

drush --include="web/themes/contrib/radix" radix:create cherry drush then cherry -y drush config-set system.theme default cherry -y cd web/themes/custom/cherry

Before you go any further, refresh your memory from the previous post about the wisdom of creating a copy of what templates and (base theme) components look like at this moment in time, so you can merge in any base theme changes later.

Step 3: Initialise the required node packages

Note: You may not need to run nvm use if your server already has npm enabled and ready to go. If you get an error that nvm is not found, and you've installed NodeJS as you need to, try moving to the next line npm install. If that doesn't work, then check your NodeJS installation, beyond the scope of this post.

nvm use npm install cp .env.example .env.local # Update DRUPAL_BASE_URL in newly created .env.local file to match your local environment URL.

That last step requires you to edit .env.local manually. You only need to do this if you wish to use Browsersync to work on your theme while the site is loaded in a browser.

Step 4: Generate the initial CSS npm run watch

At this point, if you clear your caches, you should be able to view your site using the cherry theme. It won't look much, because the Radix theme assumes you'll design yourself, something I described in my previous post.

Assuming that works, you'll see your website, with black text on a white background, with few margins between elements, and little colouring besides obvious things like links in blue.

For minor tweaks of .scss files, you'd leave the watch process running so that the CSS is automatically recompiled as you work. You'd have to do your edits in a new console session. However we're making some bigger changes, so it will be easier to exit watch and come back to it.

Ctrl+CStep 5: Declare your sidebar regions

We're not going to be able to do anything with sidebars unless Drupal is told that our theme has those regions to work with.

The .info.yml file for a theme declares all the regions that the theme makes available for block placement.

So go into cherry.info.yml in a text editor. You'll see the section headed regions:, where each line is indented by two spaces. Assuming your cherry theme is freshly created (as per this example), there will be navbar_branding, navbar_left, navbar_right, header, content, page_bottom, and footer. Below footer, create two new lines, so the regions: section ends thus:

footer: Footer sidebar_first: 'Sidebar First' sidebar_second: 'Sidebar Second'Step 6: Create a new component

We're going to create a new component for our sidebars. This is an elegant way to keep all the twig and css code for sidebars in one place, and when you come to setting the styling for your sidebars it will make your site a whole lot more maintainable. It also gives an opportunity for this post to illustrate how to do create and use a brand new component.

We'll use the CLI tool that Radix ships with. That CLI may not be in your path. By all means fiddle around with your $PATH, but (for now) I'll just reference it by its relative path. Assuming you're still in the directory for your cherry theme, run the following command:

./node_modules/.bin/drupal-radix-cli generate

You'll be asked:

◆ What is the name of your component?

Just type sidebars and press Enter.

That's it. Look in the components folder of your subtheme, and there's a folder there named sidebars.

For documentation purposes, you may as well edit the sidebars.component.yml file. The last three lines, by default, read as follows:

name: sidebars status: experimental description: 'The sidebars component auto-generated by drupal-radix-cli'

Change to

name: sidebars status: experimental description: 'Render sidebar_first and sidebar_second' slots: sidebars: title: Sidebars description: 'The sidebars'Step 7: Create the HTML for your sidebars

We'll create the HTML to include your sidebars in your site in a moment. First, let's create the HTML for them.

Simply edit the file sidebars.twig to read as follows:

{# /** * @file * Template for sidebars component. */ #} {% if page.sidebar_first %} <div class="col-sm-6 col-md-2 order-md-1" id="sidebar_first">{{ page.sidebar_first }}</div> {% endif %} {% if page.sidebar_second %} <div class="col-sm-6 col-md-2 order-md-5" id="sidebar_second">{{ page.sidebar_second }}</div> {% endif %}

What does this do?

The {% if %} sections tell the Twig engine to render some HTML only if an expression evaluates to true. So the first three lines only kick in if page.sidebar_first is true (which, in this context, means non-empty). In other words, do what's inside the {% if %} ... {% endif %} section only if the sidebar_first region actually has some content.

If that's the case, we want to render the content of the region. That's this bit:

{{ page.sidebar_first }}

But we want them to be laid out as sidebars on the site, so we surround them in <div> tags. Why we want those particular classes will become clear later.

We do this for the sidebar_first region, then for the sidebar_second region. Whenever you ask the theme to display the contents of the sidebars component, you'll get the first sidebar, then the second sidebar, such as aren't empty.

Note that the <div> tags are not indented inside the {% if %} code blocks. That is deliberate, but counter-intuitive if you're used to indenting nested code. Intending there inserts whitespace into the rendered output at a crucial place. The whitespace can get displayed on the final page. It only becomes a single space, but it's enough to make the Bootstrap columns a whisker wider than they actually are. This then means all the columns don't fit into the single row, and your second sidebar ends up underneath.

You might expect we'd want to render sidebar_first first, then the central content part of the page, then the sidebar_second. That is indeed how we want things to appear on screen. However, Bootstrap lets you shift columns around so that the order on screen is not the same as the order in the HTML sourcecode for the page. Our HTML will contain the content first, then both the sidebars, but will display those three sections on screen in the way you'd expect.

We do it this way for two reasons. First, for SEO reasons, you want the content that is specific to each page to come high up the HTML source. You don't want a search engine to give the contents of your first sidebar as how it thinks the webpage begins. Second, on smaller screens, we want both sidebars to come after the text, because it's not just search engines that are most interested in the main content (people are too).

Again, I'll explain in a moment how we achieve this.

Step 8: Alter "Page Content" to include our sidebars

Here's where using your "Twig development mode" helps you. You discover that the Radix component that inserts the <main> HTML tag is the component page-content. So this is the one we'll need to alter if we want to have sidebars included inside that tag.

So our subtheme now needs to have its own copy of the Radix page-content component. This will enable our webpages to use the cherry page-content, not the radix page-content, and so have sidebars.

To bring across the Radix page-content ready for customising, we again use the Radix CLI tool. Last time, we used its generate function. This time, we use the add function.

./node_modules/.bin/drupal-radix-cli add

With generate, we typed the name of our new component. add is for bringing across a component that Radix already defines, so we pick from a list rather than typing the name. Sadly, you can't start typing to find the component you want; you have to use the arrow keys. So when you see:

◆ Pick a Radix component to add to your theme.

press the down arrow until "Page Content" is selected, then press Enter.

Now, your components folder has a page-content folder as well as a sidebars one. We're going to edit the twig file for page-content, so it includes our sidebars.

We're going to make use of the Bootstrap framework, specifically its responsive grids, to do that. Again, a tutorial on that is outside the scope of this post. At the moment, there's a load of HTML inside that <main> tag. We're going to declare that <main> is a Bootstrap grid container, and wrap all of that content, so that inside <main> there is a Bootstrap row. Within that row there will be (i) a column for the content (i.e., for everything currently inside the <main> tag), and (ii) columns for our sidebars. We already included some col- classes on the <div> wrapping each of the sidebars, so that work is done. We just need to wrap the current <main> content in a row and then a column, and render our sidebars.

Let's do that. Open up page-content.twig in a text editor.

Under the <main> line, add the following two lines of code

<div class="row"> <div class="page__header_content col-md-8 order-md-3">

Once again, notice that these <div> tags must be against the left-margin, not indented with spaces or tabs.

Above the closing </main> tag line, add the following three lines of code:

</div> {% include 'cherry:sidebars' %} </div>

So, before the previous <main> content, we open a row and open a column. After the previous <main> content we close the column, include our sidebars (which have columns of their own), and then close the row.

Lastly, we need to add the class "container" to the <main> tag. So change the <main> line to use  the Twig addClass function. Change it from:

<main{{content_attributes.addClass(page_main_classes)}}>

to:

<main{{content_attributes.addClass(page_main_classes).addClass("container")}}>

The <main> section of the twig file now looks like this:

<main{{content_attributes.addClass(page_main_classes).addClass("container")}}> <div class="row"> <div class="page__header_content col-md-8 order-md-3"> {% if page.header %} <header class="page__header"> <div {{ page_header_container_attributes.addClass(page_header_container_classes) }}> {% block page_header %} {{ page.header }} {% endblock %} </div> </header> {% endif %} {% if page.content %} <div class="page__content" id="main-content"> <div {{ page_content_container_attributes.addClass(page_content_container_classes) }}> {% block page_inner_content %} {{ page.content }} {% endblock %} </div> </div> {% endif %} </div> {% include 'cherry:sidebars' %} </div> </main>Step 9: A note on responsiveness

We can now see how the magic we discussed earlier works. You'll recall that the HTML source code runs in this order: Content, Sidebar First, Sidebar Second. The page will appear on screen as Sidebar First, Content, Sidebar Second. Unless, that is, you're on a small screen, in which case the sidebars appear after the content.

We used the responsive Bootstrap classes order-md-*. This allows you to specify the order in which grid columns will appear on screen. Sidebar First prints first with an an order of 1 (order-md-1), then Content (order-md-3), then Sidebar Second (order-md-5). So they'll display in the order we want.

The -md bit of those classes tells Bootstrap to use the responsive version of ordering. (Read about responsive breakpoints). Unless you've changed the dimensions of your breakpoints, -md stands for medium and means screens at 768px or wider. So we're saying to display the content in the order it appears in the HTML (Content, Sidebar First, Sidebar Second) unless we're at least 768px wide. If we're wide enough, display in the order indicated by those classes (Sidebar First, Content, Sidebar Second).

Then we decide how wide we want each of our (up to) 3 columns to be. Bootstrap grids have 12 columns, so (simplifying slightly) if you want a column to take up half the row you tell the column to be 6 units wide. The content column has the class col-md-8, which says it will be 8 columns wide. That's 2/3 of the page, but it's only that if we're 768px or wider (-md again). If we're narrower than that, the default behaviour is to use the full page width for the content. The sidebars will not only not be re-ordered on small screens; they'll appear below the main content.

Last thing to notice: The sidebars also have another column width class on them.

class="col-sm-6 col-md-2 order-md-1"

So, if we're medium or wider, each sidebar is two units wide. 2 sidebars (2 units each), plus the content (8 units) gives your full page-width of 12.

But if you're not medium or wider, then the sidebars would be full-width, and stack below each other. That may be what you want on a really small screen. But if we're size "small" or above (576px), there's room to put the two sidebars next to each other, below the main content. That's what col-sm-6 does. But if we're narrower than "small", we stack the page - Content, then Sidebar First, then Sidebar Second.

Step 10: Call our custom page-content

Here's another reminder to make sure you've read my previous post. Once you've created a custom component, you need to call it. Here's an opportunity to illustrate what I was saying.

Having made all those changes, if you run npm run watch, clear caches, and refresh the page, you won't see any sidebars. Why not?

Because the page-content component is called by the page component. Our cherry theme is still using the Radix page component, and that calls the Radix page-content component. So our cherry page-content component is never being used.

To fix that, we next need to customise the page component, so that our site uses a page that calls our page-content, not the Radix one.

This is very similar to what we just did for page-content, only the changes are really simple this time. Run:

./node_modules/.bin/drupal-radix-cli add

This time, we choose page as the component to add. Our components directory now contains page, page-content and sidebars. Within the page folder, edit page.twig. Find the line that looks like this:

{% include 'radix:page-content' with {

Change radix to cherry:

{% include 'cherry:page-content' with {

And that's it.

Guess what. It still doesn't work. And you guessed it. Our site is still calling the Radix page component, not the cherry one, so the cherry page component never gets called. We are nearly there, I promise.

This time, the solution is different. We've actually hit the top of the tree; there is no component that calls the page component. It's template time. Remember (previous post, anyone?) that a Radix subtheme only contains the new and overidden components, but contains its own copy of every template. So look inside the ./templates/page folder, and edit the file page.html.twig. We're now working with the Drupal theme engine, as this is where it will look for a template for a whole webpage, and the filename it will expect.

Once you've opened page.html.twig in a text editor, you can probably see what line to change. But just in case it's not obvious, you change

{% include 'radix:page' %}

to

{% include 'cherry:page' %}Step 11: Test

That's nearly it. Nearly enough, that it's time to test

npm run watch drush cr

Reload your site. You should have Sidebar First and Sidebar Second regions, where you can place blocks. Give it a try.

Step 12: Enhancement for only one sidebar

Now we know it works, let's make it better.

If you only have one contentful sidebar, it will have width 2 and the content will have width 8. This totals 10, so the two together only span 5/6 of the width of the screen. If you only have a left sidebar, that's not too bad: you just have an unnecessarily large right margin and waste a bit of the screen. But if you only have a right sidebar, it will look odd. The right sidebar needs to be at the right of the page, but instead it will look arbitrarily indented.

We can fix this. We need to detect how many sidebars any given page will actually use. We then set the width of the content column to 8 (if both sidebars have content), 10 (if only one does), and 12 (if none of them do).

We're going to use some Twig code. We'll create a variable that holds the required column width of the Content column. We'll then use that variable, instead of a static number 8. Go to ./components/page-content, and open page-content.twig in a text editor.

Above the <main> tag, add the following three lines of Twig code.

{% set mdwidth = 12 %} {% set mdwidth = mdwidth - (page.sidebar_first ? 2 : 0) %} {% set mdwidth = mdwidth - (page.sidebar_second ? 2 : 0) %}

It's fairly obvious what this does. We create a variable called mdwidth, and initialise it to 12. If the first sidebar has content, we deduct 2. If the second sidebar has content, we deduct 2.

Then, change the line that wraps the page content in a Bootstrap column. If you followed the instructions above, it currently looks like this:

<div class="page__header_content col-md-8 order-md-3">

Change it to this:

<div class="page__header_content col-md-{{ mdwidth }} order-md-3">

Save. npm run watch. drush cr. Reload page.

Now try only having a second sidebar. The content should be 10 units wide so that the second sidebar is flush with the right of the page. Try having no active sidebars for a page. The content should take the full width.

Step 13: Homepage

We're nearly done.

The ./templates/page has two Twig templates: page.html.twig and page--front.html.twig. The theming engine assumes you may want your site front page to be themed differently from the rest of the site, so it uses a different template. If you want your sidebars on the front page too, you need to edit page--front.html.twig as we did at the end of Step 10.

Step 14: CSS

Finally, get your sidebars looking how you want them. Maybe you want to add margins, shading, borders, spacing where there are multiple blocks in one sidebar, and so on.

Edit ./components/sidebars/sidebars.scss, and put whatever you want in there.

Voilà

And there you are: Your Radix subtheme has sidebars. This post has been lengthy because it goes through all the steps, but actually it's pretty simple:

• Install Radix.
• Create a subtheme and intialise.
• Alter the .info.yml for the theme to declare two sidebar regions.
• Create a subtheme component, and set its twig to render your sidebars if they have content.
• Override the page-content component to display the sidebars in a Bootstrap grid row.
• Override the page component to call your custom page-content component, and the page template to call your custom page component.
• Add some magic so the page uses its full width even if there's only one sidebar in use.
• CSS styling

Blog Category: Drupal Planet Add new comment

The Drupal community is divided over the future of Digital Experience Platforms (DXPs) after Pantheon’s Josh Koenig declared the category is crumbling. Dominique De Cooman, CEO of DropSolid, disagrees, arguing that OpenDXP and AI-driven personalization are shaping Drupal’s next evolution. In this detailed discussion, he presents data-backed insights on why DXPs are not failing but adapting, how AI is enhancing digital experiences, and why a hybrid approach combining DXP and composable stacks could be the best path forward.

Tired of the headaches in headless Drupal? Content Cloud by Content Sync automates content integration, cutting development time and complexity. See it live at DrupalCon Atlanta 2025.

Discover why we're striving to make Drupal AI accessible and secure to everyone in the Drupal community without compromising on data sovereignty.

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.
• …

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? 

package.json is not just a dependency tracker but a powerful tool for efficiency, automation, and scalability in Node.js and Drupal projects. Learn how to make the most of it by understanding its properties and how to use it in Drupal.

A Journey Towards Sustainability and Team Building jurgen.thano Fri, 07/05/2024 - 15:15 The drunomics team gathered for an event full of excitement and inspiration in Burgas, Bulgaria. From bonding activities to insightful discussions and workshops, it was a day full of energy and enthusiasm. Want to know more? Our blog post covers all the key moments and takeaways from this fantastic day!

Join us THURSDAY, March 20 at 1pm ET / 10am PT, for our regularly scheduled call to chat about all things Drupal and nonprofits. (Convert to your local time zone.)

We don't have anything specific on the agenda this month, so we'll have plenty of time to discuss anything that's on our minds at the intersection of Drupal and nonprofits.  Got something specific you want to talk about? Feel free to share ahead of time in our collaborative Google doc: https://nten.org/drupal/notes!

All nonprofit Drupal devs and users, regardless of experience level, are always welcome on this call.

This free call is sponsored by NTEN.org and open to everyone. 

• Join the call: https://us02web.zoom.us/j/81817469653

  • Meeting ID: 818 1746 9653
    Passcode: 551681

  • One tap mobile:
    +16699006833,,81817469653# US (San Jose)
    +13462487799,,81817469653# US (Houston)

  • Dial by your location:
    +1 669 900 6833 US (San Jose)
    +1 346 248 7799 US (Houston)
    +1 253 215 8782 US (Tacoma)
    +1 929 205 6099 US (New York)
    +1 301 715 8592 US (Washington DC)
    +1 312 626 6799 US (Chicago)

  • Find your local number: https://us02web.zoom.us/u/kpV1o65N

• Follow along on Google Docs: https://nten.org/drupal/notes

View notes of previous months' calls.

Today we are talking about The Drupal Developer Survey, Last year's results, and How it helps Drupal with guest Mike Richardson. We’ll also cover HTMX as our module of the week.

For show notes visit: https://www.talkingDrupal.com/493

Topics

• What is the Drupal Developer Survey
• How often does it come out
• How did it come to be
• What type of information does it collect
• Do you look at other surveys
• What were some of the most interesting stats last year
• Core contributors
• How do you expect last year to compare to this year
• Do you think the outlook will be more positive with Drupal CMS
• Drop off in Drupal 7
• Home users
• DDEV usage
• AI questions
• Security questions

Resources

• Drupal Developer Survey 2024 Results
• 2025 Drupal Developer Survey
• HTMX Sucks

Guests

Mike Richardson - Ironstar Dev Survey richo_au

Hosts

Nic Laflin - nLighteneddevelopment.com nicxvan John Picozzi - epam.com johnpicozzi Andrew Berry - lullabot.com deviantintegral

MOTW Correspondent

Martin Anderson-Clutz - mandclu.com mandclu

• Brief description:
  • Have you ever wanted to replace Drupal’s AJAX capabilities with a lightweight library that has no additional dependencies? There’s a module for that.
• Module name/project name:
  • HTMX
• Brief history
  • How old: created in May 2023 by wouters_f though recent releases are by fathershawn of Memorial Sloan Kettering Cancer Center
  • Versions available: 1.3.5 and 1.4.0, both of which support Drupal 10.3 and 11
• Maintainership
  • Actively maintained, latest release less than a month ago
  • Security coverage
  • Test coverage
  • Documentation included in the repo as well as online
  • Number of open issues: 3 open issues, 1 of which is a bug
• Usage stats:
  • 92 sites
• Module features and usage
  • To use HTMX, you need to attach the library to the render array of one or more elements where you want to use it, and then add data attributes to your render array that indicate how you want HTMX to react to user behaviour
  • HTMX can help make your Drupal sites more interactive by dynamically loading or reloading parts of a page, giving it a more “application-like” user experience
  • There is a planning issue to discuss gradually replace Drupal’s current AJAX system with HTMX, and a related Proof Of Concept showing how that could work with an existing Drupal admin form
  • A number of elements in the current AJAX system also rely on jQuery, so adopting HTMX would also help to phase out jQuery in core. HTMX is also significantly more lightweight than JS frameworks like React
  • HTMX is really a developer-oriented project, which is why I thought it would be appropriate for this week’s episode

This past week, the Drupal community was stirred by an open letter from Josh Koenig, Co-Founder of Pantheon, challenging Drupal’s positioning in the modern digital space. Koenig argues that Drupal must move beyond the traditional Digital Experience Platform (DXP) model and redefine itself as an "agile business driver"—a tool that empowers digital teams with flexibility and control without vendor lock-in.  

His perspective has ignited discussions on Drupal’s future, especially with DrupalCon Atlanta 2025 on the horizon. Is Drupal evolving fast enough to meet the needs of enterprise users? Should it shift focus to adaptability rather than chasing competitors? These questions are at the heart of Drupal’s next chapter.

Such debates and diverse perspectives are vital for open-source initiatives like Drupal, which rely on community-driven evolution. It is up to the community to pay heed, introspect, and ensure that Drupal continues to thrive—rather than risk fading into obscurity.  

Let's have a look at last week's important stories.

Happy reading,  
Thomas Alias K,
Sub Editor, 
The Drop Times

Interview

• Building Community-Driven Drupal Solutions: JD Leonard on Member Platform and Open Source

Discover Drupal

• Josh Koenig Writes an Open Letter to His Peers
• AI-Powered Content Translation Module Released for Drupal
• A New Initiative to Make Drupal Accessible for College and University Students
• Qwen AI Enhances Drupal Development and Advances AI Performance

Events

• The Wait Ends: Splash Awards Switzerland 2025 Winners Announced
• Drupal Events of the Week: March 17 - March 23, 2025
• Decoupled Days 2025 Opens Call for Session Proposals
• Esmeralda Tijhoff to Speak at European Women in Technology 2025
• DrupalCamp Asheville Seeks Trainers for 2025 Event
• Backdrop LIVE 2025: A Global Unconference on Backdrop CMS
• All Things Open 2025 Returns for Its 13th Year in Raleigh

Organization News

• FreelyGive Releases Video on AI Agent Swarms in Drupal AI 1.1.0
• Pantheon to Showcase Innovation and Collaboration at DrupalCon Atlanta 2025
• QED42 Integrates GenAI into Drupal’s Experience Builder

Read moreIntroduction

Over the past few weeks, the Drupal community has been buzzing with discussions about the future of Drupal.

From Craftsmanship to Innovation: Why Drupal’s Future Lies in AI driven Open DXPdrupalMonday, March 17, 2025 - 10:33

Thank you!

We just want to take a moment to thank all of the amazing sponsors of the DDEV open source project. All of you reading this know that we've been working for years now to make DDEV a financially sustainable project, so it can serve you into the future. So many have responded to that call. Thank you!

Even though we're going to mention the biggest sponsors first, we want all of you to know that your sponsorship matters too, and with care we can expand to many, many small sponsors to ensure DDEV's resilience and sustainability.

Major Sponsors

• Platform.sh has been a major sponsor of DDEV for a few years now. You may know that they recently reduced their sponsorship, but they remain our largest single supporter, and we appreciate it greatly. Platform.sh has also transferred the "ddev" domain names to the DDEV Foundation and will be transferring the "DDEV" trademark. And they're funding Randy's plane ticket to Drupalcon Atlanta!
• Tag1 Consulting stepped up to generously support DDEV at a very significant level so many years ago, and has continued doing that. And they don't just offer outstanding financial support, they're always making clear that they use and support DDEV, and we get to see them at conferences.
• Mobilistics and i-gelb both sponsor at the $500/month level.
• All these lovely organizations sponsor at the $100/month (or a bit higher) level: Lullabot, Affinity Bridge, Webikon, FameHelsinki, OPTASY, Gizra, Cambrico, Agaric, Centarro, Craft CMS, Redfin Solutions, b13. And brand new this week (welcome!) Full Fat Things.

So many more wonderful sponsors!

Here are some of many sponsors who help out via GitHub Sponsors.

In-Kind Sponsors

The open-source community has lots of folks helping out multiple collaborators. In our case, MacStadium provides us testing resources, and JetBrains provides a subscription to their IDE products, thanks!

But we never forget Docker. Docker has adopted us in the Docker-Sponsored-Open-Source (DSOS) program for a few years now, and this means that all of your image pulls are sponsored in that project. You may know that normal image pulls will be strictly limited starting April 1, 2025, but because of the DSOS, users of DDEV won't hit that restriction.

And please don't forget that the open-source Docker project underlies every single Docker provider. It doesn't matter if you're using OrbStack or Lima or Docker Desktop or whatever, they're all built on top of the amazing Docker open-source project.

JSON Detail about Sponsorships

We recently set up a full updated JSON feed that can be used to see exactly where DDEV's sponsorship comes from and how we're doing. You can see the latest data any day in the all sponsorships feed. And Mark Conroy has built a web component that can be used to show where we're at on any website. Thank you!

Many Ways to Sponsor

We have almost too many ways that you can sponsor, but we want to make it easy for you and your organization.

• For individuals and some organizations, GitHub Sponsors is super easy, takes moments and can be changed any time.
• We are happy to invoice your organization and do more of a "support contract" so that you don't have to explain open-source to your finance department. We accept ACH, Wise.com, bank transfer, IBAN, SWIFT, checks, we'll work with your organization to make it work for you. Just send us a note via the contact page or any other way.
• PayPal to DDEV

Oops, are you missing or did I forget you?

Is your name or your organization's name missing here? It's easy to get it here. How much does DDEV's support and ongoing maintenance mean to your organization?

(If I made a mistake and left you out, let me know and I'll edit this.)

Do you have questions or want to talk (about sponsoring or anything else)? Contact us! or join us in Discord.

Just recently I read a really interesting blog post found in the Weekly Drop Newsletter called “Say No to Auto-Updates: Why Your Website Deserves Better Than Subscription Overhaul”. I appreciate articles that take a strong stance, and this one certainly does. However, I strongly disagree with its conclusions.

First, to get that out of the way. I actually do agree with two things 

• Updates should be tested (manually, automatically or both)
• An experienced developer carefully running the correct composer commands is always better than a bad automation

But that's where my agreement ends. Many of the points in the article are in what I would call the “general skepticism category”. This is fine, and at this point quite expected. While skepticism is healthy, data and real-world experience tell a different story. So instead of speculating (and me making counter arguments to the article), let’s look at some numbers shall we? I have some numbers. It’s these specific numbers: 3, 8, 58, 9768.

3: My personal and professional experience is with 3 services: Violinist.io, Renovate and Dependabot. For Drupal (and PHP / Composer) updates mentioned in the article I use violinist.io.  

8: I have been automating Drupal updates for 8 years.

58: Currently (at the time of writing) I have 58 personal and professional projects running Drupal (Composer) updates automatically. Most of these are automatically merged after passing tests.

9768: Over the last 8 years exactly 9768 commits have been added by an automatic updater to the 58 projects. 

Personally, I think the numbers speak for themselves. But let’s put it in perspective- try converting 9,768 commits into billable hours. Imagine the sheer amount of repetitive work automated away. You can speculate all you want - whether automation fails half the time (spoiler: it doesn’t) or if it’s actually a massive time-saver (it is). But at the end of the day, the results are undeniable.

So, while some debate the risks, I’ll be over here letting automation do what it does best - saving time and getting things done. Here is an animated gif from the days from long before all of these fancy package managers and automation tools.

Using Radix as a Drupal base theme James Oakley Sun, 16/03/2025 - 18:30

I recently wrote about my experiences migrating this website from Drupal 7 to Drupal 10. In that post I said that I would write separately about my experiences theming the site. This is that post.

I was broadly happy with the look and feel of the Drupal 7 version of the site, so didn't want something vastly different. At the sametime, I wanted to make sure that I was using the most maintainable underlying code, behind what end-users see.

The Theming Spectrum: Base Themes

When it comes to theming a site, there is a spectrum. At one end of the spectrum, you build everything yourself. You write the HTML templates, using Twig from Drupal 8 onwards, that the site will use to render the content. You write all the CSS, laying things out, making sure they are responsive and designed for mobile devices first. At the other end of the spectrum, you pull an existing theme off the shelf, like the many excellent ones you can download from the Drupal website. (As I write, there are 3,190 themes on the Drupal website.)

In between those extremes, moving slightly more customised than starting with an off-the-peg theme, you can take an off-the-peg theme and create a subtheme where you tweak the things you want to change. CSS is easiest, allowing you to change fonts, margins, relative sizes, images, colours, and so on. But template tweaks are possible too.

But I'm most comfortable one level further of controlling things myself. I don't like to write everything myself — it's far too much work, and involves a lot of wheel re-invention. But I find customising someone else's theme constrains my ability to get things looking how I want. I've done that in the past, and end up changing colours and typeface but not a lot else; as soon as you want to move content around on the screen, things start to get messy.

So I like to start with a base theme. A base theme is one that does the heavy lifting for you by giving you lots of default HTML and sensible CSS, but that doesn't make assumptions about what you will want to do on your own site.

My dilemma was: Which base theme to use?

Use a stable theme, as far as you can.

Relatively few of the 260 actively maintained Drupal 10 themes are base themes.

Even fewer are stable.

One of the things I've learnt using earlier versions of Drupal is the importance of using themes that are actively maintained and will continue to be so. Too many times, I've customised a theme, only for the maintainer to wander off and stop updating it. I then have to choose a new base theme in order to keep moving through the versions of Drupal core. If I've customised a theme designed as a base theme, it means designing a new theme using that base theme as a starter. If I've tweaked a theme designed as a fully finished theme, it means swallowing the fact that the visual appearance of the site is going to have to change. Neither is great.

For example, in various previous versions of Drupal core, I've used:

• Omega. It was a very versatile base theme that was slightly further down the spectrum of doing things for you, but very capable with some great customisation tools. The maintainers started work on a Drupal 8 version of the theme, but never got one released. So, today, there are no releases available with current versions of Drupal core (Drupal 10 or 11). They got as far as 8.x-5.0-alpha7, and the project page says: “The current list of features for Omega Five is only a small sampling of the features available. This section will be updated with additional features and descriptions as it nears a stable release for Drupal 8.” Great in its day, but no more.
• Zen. Another very versatile theme. You have to do your customisations in code, rather than with the kind of UI you got with Omega, but I see that as a strength. Again, a workhorse of a base theme for me in Drupal 7. However the project page tells you the extra features you get with 7.x-6.x compared to 7.x-5.x, but no mention of the Drupal 8+ version. The most recent commit was in February 2021 (to help with getting things ready for Drupal 9), and the one before that was 3 years earlier. Sadly (because it was a great theme) it's also run out of steam.
• Pixture Reloaded. I loved this theme. It was more of a complete theme that you can recolour and adjust as you wish, but it was responsive and worked well. It was built on a base theme called Adaptive Theme. Back in the day, there were a good half dozen Adaptive Theme subthemes on the Drupal site. There was a website for Adaptive Themes where you could download any of them, or buy premium ones too. They offered a service to build a custom theme for your site. Sadly, none of this saw any releases beyond Drupal 7, and the Adaptive Themes website now just contains a domain-parking page.

You get the idea. Even since Drupal 8, there's been a whittling down. Just looking at themes that say they are actively maintained, and that have security team coverage, there are currently 210 themes that support Drupal 8, 181 that support Drupal 9, 162 that support Drupal 10, and 81 that support Drupal 11. So users of 129 of the 210 themes that support Drupal 8 are not able to move to Drupal 11, and nearly 50 of them can't use Drupal 10 either giving them no supported options. You'll recall that I'm using Drupal 10, not Drupal 11, because there are modules that haven't released Drupal 11 versions yet.

So as far as you can, try to find a base theme that is still being actively maintained. Look to see if code is still being committed. Look for two things in the issue queues. 1. Do the maintainers respond reasonably promptly? 2. Are there issues that have been stuck at "reviewed and tested by the community" for some time? If improvements / bug fixes have been tested, they should either be committed or moved to "won't fix" with a clear reason. Code stuck on RTBC is an amber flag in my book.

I also look for themes that are old. I don't want one that has just had its first release. I look for ones that have been around for several major versions of Drupal core, to demonstrate a maintainer who is active in moving it through the release cycles.

Bootstrap Barrio

My first attempt was a theme ecosystem named Barrio Bootstrap.

This is a really strong base theme. As the name suggests, it rewrites all of the Drupal templates to work within the Bootstrap framework. It is intended as a base theme. However, as you develop a sub-theme, it will help greatly if you can write your CSS using Sass; you get the benefits of the Sass mixins, you can use variables, and you can nest rules. There is a subtheme of Barrio Bootstrap called the Bootstrap 5 Sass Starter Kit. The maintainers recommend you extend that, rather than Barrio Bootstrap directly.

As I worked on site structure, I used the Sass Starter Kit unaltered. I think it was this that slightly put me off in the end. The fact I was able to use it out of the box means it made a lot of assumptions I'd want things coloured and laid out. As I came to start making the site look how I wanted it, it was harder work because I was editing to change inbuilt assumptions rather than working from scratch. I'm sure it can be quite intimidating to load an unaltered subtheme of a base theme, and to see just black text on white with no margins or borders between elements. However, if you're going to be using Chrome or Firefox developer tools to lay things out just how you want them, that is actually the best way to start and is going to be less work overall.

I was also slightly nervous that Barrio Bootstrap came with some colour editing tools in the UI. It wasn't immediately obvious where the theme saved the resulting CSS, or how that interfaced with the CSS that I had compiled myself from Sass. I found myself wishing all the configuration was in one place. If I was going to design a site myself, I don't want code potentially overwriting the CSS I've written; it could be hard to find where problems are coming from.

My final hesitation was the way it generates two CSS files, one with source links and one fully optimised. Shipping both, and changing which one is loaded in the theme's info file, felt clumsy. I'm sure to other people it feels really intuitive, but it didn't work for me.

So I looked to see what else was out there.

Radix

And I found the Radix base theme. The theme has a Drupal project page and a really good documentation site of their own. I am unclear what connection, if any, the Drupal theme Radix has with the wider Radix UI project. I suspect they're unrelated.

Unlike the Barrio family, this theme really is not designed to work on its own. In fact, it won't work properly. The theme ships with a starterkit for a subtheme, and sites will only render correctly if you have the elements from both a subtheme and the base theme in place. So your first step has to be to create your subtheme. Happily there are really good instructions for this on their website. I followed them, and everything just worked.

The more I use Radix, the more I like it as a base theme, and I can see this being my default base theme for future projects. Here are some of the things I like:

• It's well maintained. Development started in 2012, and the first non-beta release was for Drupal 7 in February 2014. That means it's an 11-year old project, with some continuity in the maintainers. The project has not one but three commercial organisations sponsoring development time, which is a great way to make sure things continue. (To give link-credit where it's due, those are Ramsalt Lab, Chapter Three, and O8). In February 2025 (last month), there were 10 commits to the 6.0.x branch. The latest release works with Drupal 10.3 and higher, and Drupal 11; it's current. The maintainers are really responsive in the issue queue. I've found a couple of (small) bugs or ways to improve, and they've been really proactive picking up merge requests and helping me improve what I was proposing so they can commit the changes. That's a really refreshing experience that encourages collaboration.
• It uses single-directory components. Once you get the hang of it, it's a great way to maintain a theme's code. There is a component directory for everything: headers, menus, nodes, pages, comments, and so on. The theme simply inherits the twig and CSS from the base theme unless you decide you want to override a specific component. It makes it easy to find any code you've changed; as long as you've used the component directory structure consistently, those changes will be exactly where you'd expect.
• There's a great CLI tool for creating components, called drupal-radix-cli. It can bring across a component from the base theme and create the directory in your subtheme for you, and it can also create a brand new component if you want it to.
• It uses Sass, and you can easily compile your CSS in either development or release mode. The former is ideal for seeing where particular lines of CSS come from so you can fix things; the latter is fully minimised and ready for production. I develop in development mode (npm run watch), then compile in release mode (npm run production) before I commit a series of changes to git. That keeps the git commit noise down, and means staging and production environments only ever pull the production-ready styling.
• It works with BrowserSync. Now, in fairness, Barrio Bootstrap can do something similar, but Radix does it out of the box. If you run npm run watch, a web server starts running on a port in the 3000s that will render a copy of your site showing the most current layouts. Any time you make a change to the source .scss or template files, the CSS is automatically recompiled and a signal sent to your browser to reload. So you can tweak things like margins and colours and watch the effects in near real-time. I don't develop on my local machine, so I had to open the requisite ports through my development server firewall, but other than that this is a really easy way to work on a site's appearance.
• It also uses Bootstrap; Barrio isn't the only way to get access to Bootstrap. Because this really is a base theme, you don't get a site that shouts visually "I was built with Bootstrap" unless you want that. But you get all the access to HTML classes to adjust things like margins, grid layouts and forms. You also get an easy way to make many adjustments using Bootstrap variables, as I'll discuss below. It means a really well-planned framework is behind the theme, so you get all those benefits, whilst giving you genuine freedom to control what your site looks like.

Tips for Working with Radix

As I've built a theme with Radix, I've learnt a few lessons along the way that are worth sharing.

• Keep track of changes.
  • Your subtheme contains a copy of all the templates from the base theme, so the subtheme/templates folder contains a mixture of original and altered templates.
  • Your subtheme contains only those components that you've chosen to override (or create), so the subtheme/components folder contains only your alterations.
  • When you update the Radix base theme to a new version, you'll want to know what changes affect components or templates you've altered.
  • Having created my subtheme, I create copies of the components and templates folders of the base theme at the time I created my subtheme.
    cp -ar ../../config/radix/src/kits/radix_starterkit/templates ./.templates.orig
    cp -ar ../../config/radix/components ./.components.orig
  • Then you can use diff -urq to compare templates / components in the new Radix version with .templates.orig / .components.orig in your subtheme.
  • You can then carefully test bringing those changes across to the subtheme before updating your .templates.orig / .components.orig folders so they're ready as reference points for the next base theme update.
• Link to components from templates.
  • When you create a component (deriving from a base template one, or generating a new one), your webpage won't automatically pick it up. That's possible to forget if your template uses custom twig, but very easy to forget if your template just contains CSS.
  • Your subtheme will use the templates in the templates folder to work out what HTML to render. The templates folder in the Radix theme is intentionally thin; most of the templates simply insert the HTML generated by a component, and let the components folder do the heavy-lifting. This helps keep your theme maintainable. Throughout the templates folder, you'll see code like this: {% include "radix:page-title" %}. That tells the theme engine to include the output from the page-title component within the radix theme.
  • The key thing is that all the templates embed the output of the radix components. Your custom component will not be included unless you change the template that calls it from {% include "radix:page-title" %} to {% include "your_subtheme:page-title" %}. As I say, it's easy to forget.
• Whenever you change a template, you should clear the caches on your site.
  • Drupal will often cache templates.
  • If your working on theme development, you should always go to Home > Administration > Configuration > Development and check the box labelled "Do not cache markup".
  • However I've found that can still cache templates themselves, so running drush cr after a template change can help ensure those changes appear on the site.
• Whenever you introduce new components that mean you have new CSS files appearing, you need to restart your laravel mix process.
  • When you first run npm run watch, the process seems to read all the files that need watching for changes.
  • If you change those files, the CSS will rebuild and the page will reload.
  • If you add a custom component that means an extra CSS file should be included in the page, this won't be picked up. You need to Ctrl+C, and run npm run watch again.
• Use Bootstrap variables wherever possible.
  • As you start tweaking your site, you'll want to adjust margins, colours, font sizes and so on.
  • It's really tempting to write lines of scss in the components to do this for you, and that is often the right thing to do.
  • But don't forget that Bootstrap is a really powerful framework. It has a lot of variables set to sensible defaults for these things.
  • Sometimes, instead of writing custom CSS to adjust how things look, it's far better to set one Bootstrap variable to a new value, and the change is made for you in a way that is consistent.
  • Within your subtheme folder is a folder named node_modules, within that is a folder named bootstrap/scss, within that is a file named _variables.scss. At this point grep is your friend. Find the variable you want to change, and go to src/scss/base/_variables.scss within your subtheme. Set the variable you want.
  • For example, I wanted to stop <a> tags from underlining. Rather than writing a { text-decoration: none; } in the scss of a component, all I needed to do was enter $link-decoration: none; in my _variables.scss file

Sidebars

One thing I noticed straight away was that Radix doesn't give you sidebar regions for placing blocks.

I was tempted to feel grumpy and move on to look for another base theme, but then I realised this is deliberate and a good thing. Not every site uses sidebars. So let those sites that want them add them, and let those that don't have leaner mark-up.

It turns out it's easy to add sidebars. Given this isn't a requirement for everyone, but because it will be quite a common wish, I'll write that up in a separate post. Watch this space!

Blog Category: Drupal Planet Add new comment

Speed of the light search using Algolia InstantSearch with a Typesense backend and Drupal Search API

Imagine waking up to discover that overnight, AI agents rewrote 500 product descriptions, reorganized 300 pages for SEO, and updated 9,000 alt-text descriptions on your website.

As you review the changes over coffee, you find three product descriptions featuring nonexistent features. If published, customers will order based on false expectations. Then you notice another problem: AI rewrote hundreds of alt-text descriptions, erasing the ones your team crafted for accessibility.

AI-driven content management isn't a distant scenario. Soon, Content Management Systems (CMS) may deploy hundreds of AI agents making bulk edits across thousands of pages.

The challenge? Traditional CMS workflows weren't designed for AI-powered editing at scale. What features should an AI-first CMS include? What safeguards would prevent errors? What workflows would balance efficiency with quality control? I'm outlining some rough ideas to start a conversation and inspire Drupal contributors to help build this future.

1. Smart review queues: scaling human oversight

AI-generated content needs different quality checks than human work. Current editorial workflows aren't optimized to handle its output volume.

I envision "AI review queues" with specialized tools like:

• Spot-checking: Instead of manually reviewing everything, editors can sample AI content strategically. They focus on key areas, like top-selling products or pages flagged by anomaly detection. Reviewing just 5% of the changes could provide confidence; good samples suggest the broader set works well. If issues are found, it signals the need for deeper review.
• Rolled-up approvals: Instead of approving AI edits one by one, CMS platforms could summarize large-scale AI changes into a single reviewable batch.

2. Git-like content versioning: selective control over AI changes

Say an AI translated your site into Spanish with mixed results. Meanwhile, editors updated the English content. Without sophisticated versioning, you face a tough choice: keep poor translations or roll everything back, losing days of human work.

CMS platforms need Git-like branch-based versioning for content. AI contributions should exist in separate branches that teams can merge, modify, or reject independently.

3. Configuration versioning: keeping AI from breaking your CMS

AI isn't just generating content. It is also modifying site configurations, permissions, content models and more. Many CMS platforms don't handle "configuration versioning" well. Changes to settings and site structures are often harder to track and undo.

CMS platforms also need Git-like versioning for configuration changes, allowing humans to track, review, and roll back AI-driven modifications just as easily as content edits. This ensures AI can assist with complex site management tasks without introducing silent, irreversible changes.

4. Enhanced audit trails: understanding AI decisions

Standard CMS audit logs track who made changes and when, but AI operations demand deeper insights. When multiple AI agents modify your site, we need to know which agent made each change, why it acted, and what data influenced its decision. Without these explanations, tracking down and fixing AI errors becomes nearly impossible.

AI audit trails should record confidence scores showing how certain an agent was about its changes (60% vs 95% certainty makes a difference). They need to document reasoning paths explaining how each agent reached its conclusion, track which model versions and parameters were used, and preserve the prompt contexts that guided the AI's decisions. This comprehensive tracking creates accountability in multi-agent environments where dozens of specialized AIs might collaborate on content.

This transparency also supports compliance requirements, ensuring organizations can demonstrate responsible AI oversight.

5. AI guardrails: enforcing governance and quality control

AI needs a governance layer to ensure reliability and compliance. Imagine a healthcare system where AI-generated medical claims must reference approved clinical studies, or a financial institution where AI cannot make investment recommendations without regulatory review.

Without these guardrails, AI could generate misleading or non-compliant content, leading to legal risks, financial penalties, or loss of trust.

Instead of just blocking AI from certain tasks, AI-generated content should be checked for missing citations, regulatory violations, and factual inconsistencies before publication.

Implementing these safeguards likely requires a "rules engine" that intercepts and reviews AI outputs. This could involve pattern matching to detect incorrect content, as well as fact verification against approved databases and trusted sources. For example, a healthcare CMS could automatically verify AI-generated medical claims against clinical research databases. A financial platform might flag investment advice containing unapproved claims for compliance review.

Strategic priorities for modern CMS platforms

I can't predict exactly how these ideas will take shape, but I believe their core principles address real needs in AI-integrated content management. As AI takes on a bigger role in how we manage content, building the right foundation now will pay off regardless of specific implementations. Two key investment areas stand out:

1. Improved version control – AI and human editors will increasingly work in parallel, requiring more sophisticated versioning for both content and configuration. Traditional CMS platforms must evolve to support Git-like branching, precise rollback controls, and configuration tracking, ensuring both content stability and site integrity.
2. AI oversight infrastructure – As AI generates and modifies content at scale, CMS platforms will need structured oversight systems. This includes specialized review queues, audit logs, and governance frameworks.

Installation instructions for end users and testers

We will use DDEV to setup and run Drupal on your computer. DDEV handles all the complex configuration by providing pre-configured Docker containers for your web server, database, and other services.

To install DDEV, you can use Homebrew (or choose an alternative installation method):

[code bash]$ brew install ddev/ddev/ddev[/code]

Next, download a pre-packaged zip-file. Unzip it, navigate to the new directory and simply run:

[code bash]$ ddev launch[/code]

That's it! DDEV will automatically configure everything and open your new Drupal site in your default browser.

Installation instructions for contributors

If you plan to contribute to Drupal CMS development, set up your environment using Git to create merge requests and submit contributions to the project. If you're not contributing, this approach isn't recommended. Instead, follow the instructions provided above.

First, clone the Drupal CMS Git repository:

[code bash]$ git clone https://git.drupalcode.org/project/drupal_cms.git[/code]

This command fetches the latest version of Drupal CMS from the official Git repository and saves it in the drupal_cms directory.

Drupal CMS comes pre-configured for DDEV with all the necessary settings in .ddev/config.yaml, so you don't need to configure anything.

So, let's just fire up our engines:

[code bash]$ ddev start[/code]

The first time you start DDEV, it will setup Docker containers for the web server and database. It will also use Composer to download the necessary Drupal files and dependencies.

The final step is configuring Drupal itself. This includes things like setting your site name, database credentials, etc. You can do this in one of two ways:

• Option 1: Configure Drupal via the command line [code bash]$ ddev drush site:install[/code]

  This method is the easiest and the fastest, as things like the database credentials are automatically setup. The downside is that, at the time of this writing, you can't choose which Recipes to enable during installation.

• Option 2: Configure Drupal via the web installer

  You can also use the web-based installer to configure Drupal, which allows you to enable individual Recipes. You'll need your site's URL and database credentials. Run this command to get both:

  [code bash]$ ddev describe[/code]

  Navigate to your site and step through the installer.

Once everything is installed and configured, you can access your new Drupal CMS site. You can simply use:

[code bash]$ ddev launch[/code]

This command opens your site's homepage in your default browser — no need to remember the specific URL that DDEV created for your local development site.

To build or manage a Drupal site, you'll need to log in. By default, Drupal creates a main administrator account. It's a good idea to update the username and password for this account. To do so, run the following command:

[code bash]$ ddev drush uli[/code]

This command generates a one-time login link that takes you directly to the Drupal page where you can update your Drupal account's username and password.

That's it! Happy Drupal-ing!