fidzu : Drupal

Today we are talking about Laravel, Marketing, and The PHP Foundation with guest Matt Stauffer. We'll also cover Formdazzle as our module of the week.

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

Topics

• What Is Laravel
• Writing Laravel Books
• AI and Technical Writing
• Laravel Versus CMS
• Drupal as Framework
• Integrating Laravel and CMS
• Laravel and Symfony
• Marketing Modern PHP
• Laravel Community Marketing
• Jigsaw and Onramp
• Drupal Marketing Lessons
• Onboarding Focus in Laravel
• Laravel BDFL Changes
• Onboarding And Docs
• Drupal Framework Perception
• What PHP Foundation Does
• Marketing PHP Vs Laravel
• AI Answers And Positioning
• Cross Ecosystem Collaboration

Resources

• Jigsaw
• Onramp
• Native php
• Alpine
• Tailwind
• Vue
• Laravel herd
• php.new
• Blog post on how to contribute to php
• Laracon talk Kent C. Dodds The Last Software Engineer (how in the AI era, we need to all become Product Engineers)

Guests

Matt Stauffer - mattstauffer.com

Hosts

Nic Laflin - nLighteneddevelopment.com nicxvan John Picozzi - epam.com johnpicozzi Amber Matz - tugboatqa.com [amber himes matz](https://www.drupal.org/u/amber himes matz)

MOTW Correspondent

Bernardo Martinez - bernardm28

• Brief description:
  • This week's module is Formdazzle, a developer tool that makes theming Drupal forms easier.
  • Drupal's Form API is a powerful abstraction, but when you want to target one specific field, label, button, or form wrapper, the default Twig template suggestions can be limited.
  • The module works by taking information Drupal already knows about the form, like the form ID, element type, and element name, and using that to generate more targeted Twig template suggestions.
  • For example, in a Drupal View with exposed filters, you may want to style the Reset button differently from the Submit button. By default, Drupal renders both buttons through the same input-submit.html.twig template, which makes it difficult to customize them independently. This module lets you assign different templates to individual form buttons-such as Submit, Reset, or Filter-based on their action, type, and other properties.
  • This module has no configuration. Just enable the module and it starts working and look at the twig debug comments including extra template suggestions.
• Module name/project name:
  • formdazzle
• Brief history
  • How old: created in 13 September 2019 by johnalbin
  • Versions available: ^10.1 ^11 ^12
• Maintainership
  • Actively maintained
  • Last release was 1 September 2026, currently the module has two maintainers Stephen Mustgrave and John Albin.
  • The module includes both test and security coverage.
• Usage stats:
  • 3,956 according to drupal.org
• Module features and usage
  • There's no configuration. Just enable the module and it starts working, including with Views exposed forms and Webform.
  • Formdazzle automatically adds more specific theme suggestions based on the form ID, element type, and element name.

17 Sep 2026 6:00pm GMT

Your fields can now think. Route any Drupal field automator through a tool-using AI Agent and let RAG pick the answer.

17 Sep 2026 12:00pm GMT

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.

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").

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.

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.

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.

17 Sep 2026 12:00am GMT

16 Sep 2026 4:29pm GMT

16 Sep 2026 4:21pm GMT

Everybody Orchestrates. Most Do It by Hand.

Photo by Giorgio Tomassetti on Unsplash

Jürgen Haas Wed 16 Sep 2026 - 12:15

16 Sep 2026 10:15am GMT

Credentials still travel by email and by Slack on projects that are otherwise carefully built. Every integration with an external service needs them, and forwarding them from one party to the next is so routine that the risk rarely gets questioned. That habit is avoidable, and avoiding it changes who holds the secrets and who never has to see them.

The habit of sharing passwords over email or Slack

Receiving a password in plain text over email or Slack is a common occurrence on any Drupal project. It happens because every integration with an external service, whether a payment gateway, a CRM, or a third-party API, requires access credentials. Username and password pairs, tokens, private URLs, and other sensitive data that at some point need to travel from one place to another.

These credentials should never go into a code repository or into Drupal's YAML configuration files. The exposure risk is too high. The most common alternative, however, does not solve the underlying problem.

The burden of provisioning credentials in a project

The most widespread practice is to store secrets in a file outside the webroot, or to define them as environment variables accessible only to PHP. This works, but carries an operational cost that becomes apparent as soon as a password needs to change: those files must be edited by hand, and if environment variables are used, reloading Apache or Nginx may be required.

The deeper problem is the…

16 Sep 2026 10:00am GMT

One rulebook for your AI: make every generated intro, summary and alt text follow the exact same governance as your chatbot.

16 Sep 2026 7:20am GMT

Drupal 10 reaches end of life on 9 December 2026. Drupal 12 is planned for the same week. Our recommendation for Drupal 10 site owners is to start the Drupal 11 upgrade now instead of building the whole plan around a new release. Release week leaves no room for discovery As of 16 September, the official Drupal release schedule places Drupal 12 in the week of 7 December. Drupal 10 reaches end of life on 9 December. A planned release date does not promise that every module your site needs will be ready that day. Waiting until December to attempt an upgrade combines two problems: evaluating a new major version and dealing with the end of support for the existing one. Drupal 11 is already available for a trial upgrade. Our Drupal 10 end-of-life article covers the readiness checks. This…

16 Sep 2026 6:00am GMT

Choosing between monolithic, decoupled, and hybrid Drupal should start with publishing cost - not a frontend framework preference.

Drupal architecture determines how many systems your team must maintain to deliver server-rendered HTML that readers and AI crawlers can use on the first response. Here is how to compare the three options by preview, metadata, cache invalidation, and operating work.

16 Sep 2026 4:15am GMT

Joomla 3 has been unsupported since 2023. An honest look at the three destinations - Joomla 5, WordPress or Drupal - what actually breaks, and what it costs.

15 Sep 2026 6:17pm GMT

15 Sep 2026 4:46pm GMT

The safest way to add JSON-LD to Drupal is to map Schema.org properties to existing content fields with Metatag and Schema.org Metatag.

JSON-LD in Drupal should come from the same field model that supplies the visible page - not from hand-written scripts that drift when prices or availability change. Here is how to map tokens, export config, validate rendered pages, and catch missing bundles in CI.

15 Sep 2026 3:53pm GMT

15 Sep 2026 1:00pm GMT

Drupal Code Search now index recipes

theodore September 15, 2026

15 Sep 2026 12:25pm GMT

Wondering why Drupal needs another page builder? Here's what I learned installing Drupal Canvas, exposing my SDCs, and writing React right in the browser.

15 Sep 2026 10:38am GMT