webjoke.de

Need better image galleries in Drupal? The Media Scroller module adds a large main image, synced thumbnail navigation, and simple configuration without custom templates.

I’m always blown away by the Driesnote slides

I’ve watched a lot of Driesnotes. A lot. Goodness me, I don’t even know how many.

Over the last few years, and I promise to find out exactly how many, Dries has had a lot of help with the design of them from an awesome designer at Acquia who I just have to shout about - ASH. 

(yes, absolutely go give the shout outs!!)

Rachel Tue, 10/13/2026 - 11:49 Tags

• Drupal

• Read more about I’m always blown away by the Driesnote slides
• Log in with GitHub or Google to post comments. Or, if you came across this post via Mastodon, just reply there!

Most Drupal site owners I talk to handle Drupal security updates the same way. These are the fixes the Drupal Security Team publishes for core and contributed modules. A developer sees the security advisory. A ticket goes into the next sprint. The patch goes live a few days later, sometimes two weeks later.

A Drupal update should come with confidence that your important workflows still work. Learn how to introduce Playwright, build useful browser tests, and make automation part of your release process.

Date: 2026-October-12Security risk: Critical 19 ∕ 25 AC:Complex/A:None/CI:All/II:All/E:Theoretical/TD:AllDescription: 

There will be a Drupal core security release for all supported branches on October 14, 2026 between 16:00 and 21:00 UTC. (To see this in your local timezone, refer to the Drupal Core Calendar.) Based on our analysis this vulnerability rates at 19/25 on our risk calculator.

The Drupal Security Team urges you to reserve time for core updates at that time because exploits might be developed within hours or days.

We recommend updating to the latest supported patch (bugfix) release for your site's version of Drupal before October 14, so that you can address any other upgrade issues before the security window.

This issue is being protected by Drupal Steward. Sites that use Drupal Steward are already protected from some known attack vectors, but the protection offered will not cover all possible exploits. Sites should upgrade in the near future in case additional attack vectors are discovered.

Affected versions

All currently supported versions of Drupal core are affected, including:

• Drupal 11.4.x
• Drupal 11.3.x
• Drupal 10.6.x

Drupal 12.0.0-beta1 is also affected. New beta releases will be provided following the security updates for the supported branches.

All versions of Drupal prior to 10.6.x, as well as all versions of Drupal 11 prior to 11.3.x, are end-of-life and no longer supported. Sites on those versions should update as soon as possible to avoid this and other publicly disclosed vulnerabilities.

Disclosure policy

Neither the Security Team nor any other party is able to release any more information about this vulnerability until the announcement is made. Security release announcements will appear on the Drupal.org security advisory page, which has RSS feeds. The announcement will also be made public on:

• The #security-team channel of the Drupal community Slack
• Bluesky
• Mastodon
• X (formerly Twitter)
• LinkedIn
• By email for those who have subscribed to our email list. (To subscribe to the email list: log in on Drupal.org, go to your user profile page and subscribe to the security newsletter on the Edit » My newsletters tab.)

Coordinated By: 

• Bram Driesen (bramdriesen) of the Drupal Security Team
• catch (catch) of the Drupal Security Team
• Damien McKenna (damienmckenna) of the Drupal Security Team
• Greg Knaddison (greggles) 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
• Michael Hess (mlhess) of the Drupal Security Team
• Juraj Nemec (poker10) of the Drupal Security Team
• Jess (xjm) of the Drupal Security Team

The eight-step Drupal 7 database cleanup we run before every migration: caches and logs, revisions, deleted fields, files, spam accounts, content you will not bring, and the module data you leave behind, in the order that costs least and saves most.

Questions about the pace of advanced artificial intelligence are no longer confined to the research teams building it. Former OpenAI safety leader David Robinson described his decision to leave the company in a 3 October essay for The Atlantic, challenging the assumption that developers can release increasingly capable systems and address risks as they emerge. Former Anthropic researcher Jacob Coxon had raised concerns about competition between AI laboratories in a September interview with WIRED. Their warnings point to a conflict between the speed of development and the time required to evaluate its consequences. Neither departure demonstrates that the industry has actually slowed down.

That tension has reached public hearings and internal disputes. At a 5 October hearing, New York City Council members questioned representatives of major AI companies and heard testimony from former researchers at Anthropic, OpenAI and Google DeepMind. Three other former OpenAI safety researchers, Jasmine Wang, Tomek Korbak and Mikita Balesni, subsequently disputed the company's stated grounds for their dismissal. They warned that uncertainty over acceptable contact with external evaluators could discourage scrutiny. OpenAI rejected the suggestion that they had been dismissed for raising safety concerns and said its policies on sensitive information had been breached. The underlying dispute remains unresolved.

Public oversight offers a possible route beyond those competing accounts, but proposals must be distinguished from protections already in force. New York City lawmakers have discussed third-party validation, reporting and protections for people who flag risks. These measures would need to be enacted and implemented before their practical effect could be assessed. Independent evaluation also raises a harder question than whether a company publishes safety reports: who receives the findings, who can challenge the evidence and who has the authority to require a change before deployment? A review process may identify dangers without having the power to alter a release decision.

These questions extend beyond arguments about catastrophic AI scenarios. Organisations that develop or operate software routinely face uncertainty, conflicting incentives and decisions that affect people outside their own teams. Open-source communities confront some of those problems through public issue histories, reviews and shared maintenance, although those processes are not substitutes for the legal and institutional oversight proposed for advanced AI. What matters is whether concerns can move from warnings to decisions, with clear accountability when evidence is contested. The question is not only whether someone is willing to say that development should slow, but whether anyone outside the organisation can make that warning count.

Follow The DropTimes on LinkedIn, X, Bluesky, and Facebook, or join #thedroptimes on Drupal Slack.

Kazima Abbas wrote and curated this issue of Editor’s Pick.

Author: Will Huggins

The narrative around enterprise AI is changing. Digital leaders — from CMOs looking for campaign velocity to CISOs managing vendor risk — are no longer just asking for new AI features. They are asking for AI infrastructure they can actually trust. They want to know how to maintain brand sovereignty, ensure content provenance, and scale AI operations without creating unmanageable compliance risks.

This shift in the market perfectly aligns with the mission of the Drupal AI Initiative: to establish Drupal as the premier open-source AI platform for digital experiences.

This October, the conversation takes a national stage at Digital Leaders' AI Week 2026, the UK's largest online festival of AI learning. And the Drupal community is front and center.

While Drupal AI is fundamentally a technology initiative, its real-world impact comes from the thought leadership of the people building it. At AI Week, members of the Drupal ecosystem will share strategies that go far beyond the CMS, showing how open-source principles are solving the hardest challenges in enterprise AI adoption.

Here is a look at two key sessions you won't want to miss.

The Technology Is Ready. Is Your Organisation? Why AIMS Will Define the AI Leaders

When: October 16, 2026

The technology to generate content, personalise experiences, and orchestrate complex user journeys is already here. But as many organisations are discovering, having access to an AI model is not the same as having a scalable AI operation.

In this session, we will explore the critical gap between technological capability and organisational readiness. The focus will be on the necessity of an AI Management System (AIMS) — a structured approach to governing AI adoption.

This is where Drupal AI's philosophy truly shines. When we talk about Drupal as an "AI platform," we are talking about built-in governance. Organisations locked into proprietary platforms often struggle to adapt their AI infrastructure as new models emerge or regulations change. Lightweight SaaS tools, conversely, often lack the rigorous audit trails enterprise IT requires.

This talk will illustrate why the organisations that win in the age of AI will be those that prioritise structural sovereignty — the ability to control their own data, choose their own models, and enforce their own brand guidelines at scale. It’s the exact reason why the Drupal AI Initiative developed the Context Control Center (CCC), ensuring that AI-generated content is always grounded in verified, human-authored brand rules.

Running with scissors: Using AI to explore, build, maintain, contribute, and secure Drupal" is the title of my DrupalCon Orlando session proposal. I've been using and writing about AI as a Drupal developer for the past year, and I look forward to sharing my experience with fellow Drupalers at the conference. There is so much discussion about AI and Drupal, and I'd like your help with my DrupalCon session proposal.

We should assume most session proposals will focus on AI inside and outside Drupal from the perspective of site owners and builders. Meanwhile, if we want to encourage people to try Drupal, we also need to sell it to developers. My goal is to sell "using AI to explore, build, maintain, contribute, and secure Drupal" to developers and vibe coders, while acknowledging the challenges and risks by comparing how fast we've had to adopt AI to "running with scissors."

Running with scissors

I first heard the expression "Running with scissors" in the title of Augusten Burroughs' memoir. I enjoyed reading that book, and now I am listening to the audiobook while working on this blog post. A subtle takeaway from the memoir is that sometimes you may find yourself "running with scissors' involuntarily (or voluntarily), and you have to decide how to handle that scenario.

Related to AI, "running with scissors" captures the extremely fast, collectively exceptional pace we're in: a remarkably massive societal shift, comparable to the Industrial Revolution, is unfolding. The Industrial Revolution took decades to unfold, whereas the AI Revolution is unfolding in a few years, especially among software developers.

The AI Revolution is probably the right term, and it could foreshadow AI winning the revolution, leading to humankind's demise. BTW, this won't be the focus of my session...Read More

Shared code creates shared security needs. European product rules raise a more specific question: who must act?

Importing content with the Default Content module is really useful when populating a site with content. There's an increasing number of recipes and modules that can be used to populate a site with content either for setup or demonstration purposes.

Default content is really useful when figuring out how a system works as it can show relationships between content types that are not always simple to discern through the site itself. It also has a place when deploying content between sites as you can package up some default content and include that in a deployment step.

Occasionally, you'll want to tweak the content that is imported for different situations; with the reasons why you would want to do this being numerous. It might just be that you have a demo site and you wanted to tweak the content imported to better tailor it for the user. You could have a single recipe that contains the content and want to alter that for a specific demo.

I needed to do this selected default content import on a recent site as I was installing. A contributed module was used to populate the site with content to create a collection of examples. Although the content was good, I didn't want to import it all as some of it didn't make sense for a couple of scenario that I was looking at. That lead me to seeing if I could alter the content automatically as it was imported into the site, rather than manually delete content after the fact.

In this article we will look at some of the actions I tried to prevent content from being imported, before moving onto what the actual solution was. If you are following along at home, it is assumed that you already have a default content process setup and are just looking for change what content is imported without altering the source files.

Read more

Drupal's Form API comes with built-in tooling to allow any form element to initiate a submission. When combined the support for returning HTML fragments in htmx 4, it's very easy to make an interactive form for your users.

Drupal Meets Matrix part 2: Live Comments with ECA and HTMX John Locke Sat, 10/10/2026 - 12:00

A comment thread in Drupal works totally fine. You fill in a form, click submit, and your comment gets posted. Same way it has for over 20 years.

But if somebody else replies when you're on the page, you don't see anything change, you don't get any notification.

Dev Corner

• Read more about Drupal Meets Matrix part 2: Live Comments with ECA and HTMX
• Add new comment

Read more

Opening DrupalCon, a summit

DrupalCon Rotterdam: building Drupal’s AI future togetherdrupalSaturday, October 10, 2026 - 19:41

Can it be all so simple? Migrating a 13-year-old WordPress blog to Drupal CMS Image

Can it be all so simple? Spoiler: no, it can't. But it was fun.

Can It Be All So Simple (CIBASS for friends, and yes, the name comes from the Wu-Tang Clan song) is a Spanish blog about cinema, music, comics, TV series and culture that has been publishing since 2013. Some friends started it, and later a bunch of others joined, including me. I ended up hosting it and doing its maintenance for years. And we even ended up earning an award.

It ran on WordPress all that time. Maintenance was painful. In 2021, I alleviated part of that pain by migrating it to roots/bedrock and managing updates with Composer, but still, I wanted to migrate it to Drupal at some point. If you explore its contents, you will end up finding quite a few articles written by Drupal people. 

On October 1st, 2026, thanks to Drupal CMS 2.2.0 and its multilingual support improvements, that could finally happen. Even if activity on the blog has been at its lowest, I still wanted to do that to keep the site online with minimal maintenance, while I refuse to accept that the project is almost dead. 

What we were migrating

The first step: an inventory. By setting up both the WP project and the new Drupal CMS one in DDEV, we made sure they could see each other. Looking at what was actually in the database:

• 717 published posts (and 5 drafts), 2013 to 2022.
• 4,110 attachments. 3,741 of them JPEGs.
• 545 approved comments, 104 pingbacks, and 1,190 spam comments that stayed behind.
• 13 categories and… 5,861 tags. For 717 posts. Yes.
• 3 users. Bylines lived in the post body as "Por NAME, @HANDLE".

Audit your content before the migration too, not only after. The database will surprise you.

In 2021 I said that upgrading your site is the best time for taking the trash out. Still true: the spam and 5,580 revisions stayed in WordPress.

The shape of it: Drupal CMS, recipes and a direct database source

The site is built on the Drupal CMS project template. Everything specific to CIBASS lives in project recipes: one per vocabulary, one per content type, one per media type, all bundled in a site template recipe. A fresh clone installs the whole site, in Spanish, with a single command. Then the migrations fill it.

For the source I didn't use the XML export of wordpress_migrate. wordpress_migrate_sql reads the WordPress database directly. With DDEV, the WordPress clone runs as its own project, and the Drupal one connects to its database container. 24 migrations, run in order by a script that stops at the first failure.

The development happened on a parallel branch of the same repository, and at cutover it was a plain git merge into master, plus running the migration live. The WordPress code is now only in git history. RIP.

The content model: let the data decide

WordPress had "posts". CIBASS had three different things pretending to be posts: critiques, interviews and articles. So the plan was to split them, and the first plan said "around 337 critiques".

The data said otherwise. A critique on CIBASS is a post with a rating, and the rating is… an image. A picture of a score at the end of the post. So the rule ended up being "a critique is a post with exactly one rating image". Posts with several ratings are compilations ("our 10 favorite movies of the year"), and those became articles flagged for editorial review.

The final numbers: 185 critiques, 22 interviews (plus 2 manual overrides) and 513 articles. Ratings are now a real field, and a custom field formatter outputs that same image.

Bylines became a contributor vocabulary. Parsing "Por NAME, @HANDLE" sounds easy until you find multiple authors, authors joined with " y ", and the same person written in 61 different ways. A small overrides table at migration time brought it down to 46.

Twelve rules to read a blog post

This is where most of the work went. Thirteen years of hand-written HTML, three generations of WordPress editors (classic, shortcodes, Gutenberg), and a lot of copy-paste from YouTube. While at it, we wanted to use the power of media in Drupal, so we needed to ensure we could unify all these different kinds of embeds from several different social networks this site has outlived (hey Vine!).

As an example, every critique body goes through a chain of twelve process plugins, in this order:

field_content: - plugin: wp_strip_byline_blocks - plugin: wp_rewrite_inline_formatting - plugin: wp_strip_rating_image - plugin: wp_rewrite_gallery_shortcodes - plugin: wp_rewrite_manual_galleries - plugin: wp_rewrite_caption_shortcodes - plugin: wp_rewrite_gutenberg_blocks - plugin: wp_rewrite_embed_shortcodes - plugin: cibass_image_override - plugin: wp_rewrite_img_urls - plugin: wp_relativize_links - plugin: wp_rewrite_search_to_tag

Each one does one thing. Remove the byline, because it's a field now. Remove the rating image, same reason. Turn [gallery ids="…"] (62 of them, 828 images) and the galleries people built by hand into gallery media. Turn 521 [caption] shortcodes into embedded media with captions. Turn [embed], bare URLs and raw iframes into the right remote media. Turn every <img src="…/uploads/…"> into a <drupal-media> token. Make links relative. And convert old ?s=query search links into tag pages.

Order matters. If the rating image isn't stripped (step 3) before images are converted (step 10), the rating image ends up as a media item in the body.

And then there's the rule that is not a rule: CIBASS editors use [sic], [mos] and [habla] as editorial brackets in Spanish. They look exactly like shortcodes. They are not. Leave them alone.

Write each transformation as its own small process plugin, with its own tests. You'll rerun the migration dozens of times, and you want to know which rule broke.

That's around 2,250 lines of process plugins and 186 test methods in the migration module. It sounds like a lot. It's the reason I could rerun everything without fear.

Media: eleven types for one blog

Those rules need somewhere to put things. The site ended up with eleven media types, and some of them deserve a story:

• Images (4,102): caption and description moved from the post to the media item, so they travel with the image.
• Remote video (344, YouTube and Vimeo): 73 of them were dead. Some got curated replacements; the rest went into an editorial backlog, created automatically during the migration, for human review.
• Gallery (65): a custom media source that holds a list of images. A gallery is a media type referencing other media types

A customer submits a web enquiry. Someone reads it, copies the details into the CRM and asks for missing information. When that happens every day, enquiry preparation is a useful place to test whether AI can save time. Choose one task with a clear finish line AI business process automation becomes easier to evaluate when the task has a defined start and end. For a web enquiry, it starts with submission and ends when the responsible person has checked the information and knows the next action. Our recommendation is to begin with a summary, a suggested category and a draft response. A person approves prices, delivery dates and commitments. This gives the team a bounded task whose time savings can actually be measured. The approach may suit a manufacturer receiving descriptive quotation…

Drupal is changing how developers organize some of the code behind your website. Here’s what the transition means for custom functionality, theme maintenance, and planning your next upgrade.

This is a cross-post of a blog by Nathaniel Catchpole, Senior Performance Engineer and Technical Lead at Tag1

At DrupalCon Vienna, Tim Lehnen presented on the main costs for running Drupal.org. Around 50% of the total cost of running drupal.org, or approximately $1.5m, is infrastructure costs. A significant slice of infrastructure costs comes from drupal.org's self-hosted GitLab, and in turn much of that cost is due to GitLab CI for Drupal core and contributed modules.

Figure 1: Drupal Engineering activities compared to the various funding sources

Drupal core is the single biggest project in terms of CI minutes, both due to the sheer number of tests as well as the level of activity in Drupal core issues, with hundreds of commits per month and activity on thousands of issues and Merge Requests ("MRs").

Figure 2: Drupal CI minutes by project, July 2026, core issue forks are treated as separate projects

Since Drupal originally moved to Gitlab CI from our previous Jenkins-based CI infrastructure in 2023, we've been working on reducing the time taken for Drupal core test runs.

The primary end goal of this work was to reduce the wall time for pipelines on MRs. These started at around 55 minutes when we originally moved to Gitlab CI (approximately the same as they were on Drupal CI), and now generally finish in 5-7 minutes. The 55 minute runtimes already relied on previous known optimizations like using a ramdisk for both the database and filesystem, applied to GitLab runners. GitLab does not support this out of the box.

Five minute turnaround times on pipelines have made a huge difference to Drupal core velocity. Whereas core contributors used to push to a branch, then go and eat lunch or dinner while waiting for the pipeline to finish, there's now barely enough time to make a cup of coffee, let alone drink it.

Figure 3: Contributors recognizing and commenting on the time improvement of waiting for the pipeline to finish

However, the bulk of the initial gains we made to core CI pipeline performance was in wall time, with much less impact on CPU minutes. This is now starting to change, as we're finding ways to reduce the CPU minutes while also keeping wall times as short as possible.

Reducing Pipeline Wall Times

We reduced pipeline wall times via the following approaches.

Concurrent Test Running and Parallel CI Jobs

Drupal's run-tests.sh has supported running tests concurrently for a long time. We added support for Gitlab's parallel test runs, splitting test groups with thousands of tests into smaller groups so that they can be run on multiple test runners at once. For example Drupal's functional test group is executed in 8 parallel jobs, at 15 concurrency, with a CPU request of 10 per job. This runs 150 test classes at a time on 100 CPUs. By running smaller sized individual jobs, there is also a higher chance of them fitting into test runners that become available rather than requiring a new AWS instance to be spun up.

Slowest Tests Run First

Tests are always run slowest first. Drupal's test runner has supported a #slow group for a long time, so that very slow tests can be run first. We now also order tests by the number of methods, so that tests with more methods, which overall tend to be slower, run first too. This is critical for other optimizations to be effective. If a single class takes three minutes to run, starting it at the beginning when the rest of the tests can also be completed in three minutes means the entire test run can be finished in three minutes. But if that job started last, the job could take six minutes, with just that one test being run for half the time, leading to slower wall times and idle CPUs.

Optimize or Split Up the Very Slowest Tests

In some cases we have had individual test classes that took more than 10 minutes to run. For these very slow running tests, we've split them into smaller test classes so that they can be run in parallel, and/or optimized the test set-up requirements so that no individual test takes longer than a full run.

Reducing CPU Time for Test Pipelines

With these techniques, we've been able to balance CPU requests and concurrency across the various core test types, so that every job finishes within approximately 3-4 minutes. This has given us a solid framework for keeping pipeline wall times to a minimum while allowing us to adjust CPU requests and concurrency for individual test types to match the scope of core's overall test coverage. As far as we know there are no longer obvious optimizations to make via tweaking concurrency and test running order.

While we've been working on optimizing the tests themselves, in recent months focus is increasingly shifting in that direction as the best way to further optimize test runtimes, but more importantly, reduce CI minutes and the resulting infrastructure cost for the Drupal Association overall.

Test Types

Drupal core started with only one type of test: SimpleTest 'functional tests' that require a full Drupal install into a separate site that the tests are then run against. Over time with the adoption of PHPUnit, we've added unit tests, 'kernel tests' which include a full dependency injection container but don't do a full install, functional JavaScript tests which use a real browser, and build tests which allow creation of a completely separate code base in its own directory. There is an ongoing effort to convert functional tests to kernel and unit tests where this can be done without losing test coverage, with the recent addition of http request testing to kernel tests making many more tests eligible. Converting a functional test to a kernel test can reduce the time it takes by 3/4, so for the tests where this is possible it's one of the most effective ways to make gains, although the conversions have to happen test by test across dozens or hundreds of test classes.

Over the past couple of years there has been a concerted effort to improve Drupal core performance. Many runtime performance improvements don't necessarily make a lot of difference to test runtimes as a whole. But because functional and functional JavaScript tests install a full Drupal site and request real pages, anything which improves installer or cold cache performance tends to have an outsized effect on test runs. Installer performance generally doesn't affect production sites (because they're already installed!) and cold cache performance is often not a priority for production sites because it tends to affect a low percentage of overall requests, however as well as CI times, it can also make huge differences to the user experience for new users as well as improving responsiveness after deployments and cache clears.

Installer Improvements for Functional Tests

In 11.2.0, we changed module install to support installing multiple modules at once without a separate dependency injection container rebuild between each module. Instead of doing 50 or 60 container rebuilds during an install, we do more like 11 or 12. This took tens of seconds off Drupal installs, whether via the UI, Drush, or during test runs.

Figure 4: Installing multiple modules in Drupal 11.2

Source: Figure 4: Installing multiple modules in Drupal 11.2.

In Drupal 11.4, we made container rebuilds during the installer more conditional, reducing container rebuilds during a functional test from 11 to 8.

Recently, I've been looking at whether it would be possible to reduce the 8 remaining container rebuilds further, without necessarily an expectation that there would be much room for improvement, and found some. With all of those changes, some of which are not committed yet, we should be able to get down to an absolute minimum of 2 container rebuilds in tests. While some of the optimizations are test-specific, a real-life Drupal install of the minimal profile takes less than 2 seconds.

This investigation also uncovered further possible performance improvements in the installer.

While the combination of these changes probably saves only around 5 seconds at most from an install during a test run, this saving is multiplied by every install that occurs, with thousands of Drupal installs on every test run, this adds up to several minutes of CI time.

This has already allowed us to reduce the total CPU request for functional tests from 128 to 80 with no increase in wall time. We expect to be able to reduce the CPU request for both functional and functional JavaScript tests further once more optimizations land.

Kernel Test Performance Improvements

Kernel tests in general run much faster than functional tests, however there is still a per-method overhead which is a lot higher than unit tests. We are looking at adding an option to kernel tests to share the database state between test methods which will remove a lot of that overhead. This in turn will allow us to re-use the dependency injection container between methods. As we move functional tests to kernel tests, this should increase the impact of that change on resource usage even more.

Re-Evaluating On-Commit Pipelines

Drupal core has daily, weekly, and on-commit jobs on its branches, as well as those that run on individual MRs. In looking at the information we get from those jobs, we realised that the on-commit jobs, which on average run several times per day, and run the full test suite against multiple different database types (Mysql, MariaDB, SQlite, PostgreSQL) don't necessarily give us information that we can't otherwise get from MR, daily and weekly runs. For release branches, we need immediate post-commit feedback in case something is unexpectedly broken, which sometimes happens when two independent commits are fine individually, don't have merge conflicts, but break when combined anyway. However, we're in the process of trialling running our development branches without on-commit pipelines whatsoever. This should reduce CI minutes for core purely via running pipelines less often, on top of the in-pipeline optimizations above.

Reducing Wall Time for Contrib CI Runs

While individual contrib projects are not the biggest user of CI minutes, there are thousands of contributed projects. Several of the performance optimizations for the installer, functional tests, and kernel tests will apply to contributed module tests too, since those have to install core the same way as core tests do.

Additionally, there has been recent work to switch contrib's gitlab_templates shared pipeline definitions to running concurrent tests by default. Contrib tests previously used raw phpunit which runs each test sequentially with an option to switch to concurrent test running via run-tests.sh; the default flipped to run-tests.sh by default in September 2026. Because contrib tests should also benefit from core's 'slowest test first' strategy, this should compress pipeline times in contrib and it may have a positive impact in reducing CI minutes overall if runners are able to complete jobs in a shorter time with the same CPU request.

Effect on the Drupal Association's Hosting Costs

Taken together, these changes lower the cost of running core's CI run by run, through shorter wall times, fewer CPU minutes, and fewer pipelines overall. As Figure 2 shows, core is the single biggest consumer of CI minutes on drupal.org, so that work is aimed at the largest single driver of the GitLab CI costs behind the Drupal Association's infrastructure bill.

What that adds up to on the bill itself is a separate measurement, and will take longer to validate. Total cost depends not only on the cost per run but on how many runs happen, and core activity (commits, issues, and merge requests) is holding steady or rising. So the effect on the DA's hosting costs has to be read from same-month comparisons year over year, or averages across several months, rather than any single snapshot. We’ll be keeping a close eye on this as the latest round of changes are committed.

So, Where Have I Been?

Henadzi Koltun argues that Drupal’s value lies in durable engineering rather than short-term gains. He discusses when headless architecture is justified, why AI still needs human oversight and how accessibility becomes an organisational responsibility.