Open source projects thrive because of the people and institutions that nurture it behind the scenes empowering innovation, collaboration, and digital freedom. One impactful institution is the Oregon State University Open Source Lab (OSL). The Drupal community owes much of our success and growth to Open Source Lab when they supported the project in 2005 by hosting our servers.
Today, OSL needs our support.
The Oregon State University Open Source Lab is a nonprofit organization with a powerful legacy in the open source ecosystem. For years, it has provided secure, reliable hosting services to some of the most widely used and mission-critical open source projects like Apache, CentOS, Debian, Django, Docker, Eclipse, Mozilla Firefox, GNOME, Go, KDE, Node.JS, OpenBSD, OpenSSL, postgreSQL, Rust, sqlite, The Tor Project, Yum, and yes, Drupal.
In 2005, when a surge of interest melted down the shared server that was being used by Dries to host Drupal.org, Sun Microsystems donated a server but there was nowhere to host it. Open Source Lab stepped forward providing managed data center services, offering not only hosting but also long-term support through its student mentorship model. This commitment shaped the careers of many open source leaders, including former Drupal Association Infrastructure Manager Rudy Grigar and current Infrastructure Manager and Tag1 CTO Narayan Newton, both Open Source Lab alums.
While the Drupal Association has now moved to a hybrid cloud architecture, we still operate some critical infrastructure at the Open Source Lab, including pre-production environments, mail transport, and legacy systems that are still mid-migration, and will be repurposed for things like our testing infrastructure. It is our hope for Drupal to continue to be present at the Open Source Lab for years to come.
In recent years, the Open Source Lab has faced a steady decline in corporate donations, leading to an operational deficit. Today the Open Source Lab is under threat, placing Open Source Lab’s future in jeopardy.
Unless they secure $250,000 dollars in commitments by 14 May 2025 they will have to close their doors.
If Open Source Lab shuts down, we lose a backbone of the open source world and a value-driven infrastructure provider. It would ripple across dozens of projects and thousands of contributors, setting back years of progress and community building.
Together, we can keep Open Source Lab alive
This is an opportunity for all of us to come together to support an unsung pillar of open source.
Your donations are vital to keep this precious resource for the public good open. Consider making a donation to support Open Source Lab’s future. Donate today.
If you are able to make a major gift, you can also reach out to: donations@osuosl.org
Help raise awareness by sharing this post within your network and with anyone you think could help support Open Source Lab.
The Open Source Lab has played an important role in supporting the open source community, now it’s our turn to give back. By contributing today, you’re helping secure the future of open source innovation and sustaining essential digital infrastructure. It's time to come together to ensure the Open Source Lab’s legacy continues to thrive.
DDEV has really changed the game for developers by making it easier to set up local development environments in no time! When you team it up with the amazing automation features of Selenium, you get a powerful duo for doing thorough functional tests. In this article, your favorite Drupal development team looks at how this combination can boost your development efficiency and enhance the quality of your projects.
With all the advancements in CSS over the past few years, it's surprising to discover a technique that's been available all along. If you're well-versed in CSS, you might already know this little nugget: selector > * + * {...}. Let's dive into it.
The Lobotomized Owl (* + *), or Owl selector, is one of my favorite techniques for managing document flow and achieving consistent spacing in a highly manageable way. While the Owl selector can be used for various style settings, my preferred use is to add spacing between sibling elements.
The Owl selector targets elements that are preceded by an immediate sibling. This means that if you apply the Owl selector to a group of HTML elements, the styles will apply to all elements except the first one, as the first one doesn't have a preceding sibling. We'll see some examples shortly.
The Lobotomized Owl isn't a new CSS concept; it's been around since the beginning of CSS and was first discussed back in 2014 when A List Apart wrote about it. Read that article for a more in-depth description of the Owl selector.
The Owl selector allows you to manage the document flow by using the next sibling combinator (+), along with the universal selector (*).
Consider the following HTML:
<div class="parent">
<div class="child"></div>
<div class="child"></div>
<div class="child"></div>
<div class="child"></div>
</div>Using the Owl selector in its original form (* + *), could result in unexpected updates due to its broad scope. Narrowing the scope is prefered.
Chaining the Owl selector with .parent >:
.parent > * + * {
margin-block-start: 2rem;
}Nesting it within .parent along with other rules that may exist:
.parent {
/* other rules here. */
> * + * {
margin-block-start: 2rem;
}
}By narrow the scope as shown above, and using the child selector (>), a 2rem top margin is added to "direct" children of .parent, but only if they have a preceding sibling.
A more visual representation of what the CSS is doing can be seen here:
FIG 1: Each white box represents a div while the purple boxes represent top margin.
Instead of writing styles, we’ve created a style axiom: an overarching principle for the layout of content flow. - Heydon Pickering.
In the past I would do something like this to handle margin on a group of elements.
.my-list {
li:not(:first-child) {
border-block-start: 1px solid #000;
}
}That's not terribly bad, but the problem with this approach is that it increases the specificity of the rule, which could complicate overrides.
Before :not was a thing, I would also do something like this (please forgive me):
.my-list {
li {
border-block-start: 1px solid #000;
}
}
.my-list {
li:first-child {
border: 0;
}
}There's nothing wrong with this example except that it's more code and you're overriding rules. Ultimately, it works, so don't feel too bad if you've done this. Just don't do it again 😉. Instead, do this:
.my-list {
> * + * {
border-block-start: 1px solid #000;
}
}The examples above are pretty simple, but in many cases, our HTML may not be as clean or uniform as the examples we've seen. Here's a more realistic example where our markup is a combination of different HTML tags.
<article class="blog-post">
<div class="blog-post__tag">
<a href="#" class="eyebrow">Drupal</a>
</div>
<header class="blog-post__header">
<h1 class="blog-post__title">
Using modern image formats to improve performance
</h1>
<p class="blog-post__subtitle">
Small wins, when added up can make a big difference.
This is one of those small wins which can result in
performance gains for your website.</p>
<div class="blog-post__date">
<time datetime="2025-xxx-xx">April 12, 2025</time>
</div>
</header>
<div class="blog-post__share">
<ul class="social-share" role="list">
<li class="social-share__item">...</li>
<li class="social-share__item">...</li>
<li class="social-share__item">...</li>
</ul>
</div>
<div class="blog-post__content">
...
</div>
</article>The HTML above is actually the code used on each of the blog posts on this site. Let's break it down in an illustration form for a better visual representation.
FIG 2. Illustration of the markup structure of a Blog post.
From the code and FIG 2 above, we notice the following:
<article> tag is the top parent element with four direct child elements (Tag, Header, Share, and Article content).<header> tag is also a parent element itself with three direct child elements (Title, Subtitle, and Date).Let's start with the <article> parent selector:
.blog-post {
> * + * {
margin-block-start: 2rem;
}
}The result of this CSS rule is a 2rem top margin on direct sibling children of the .blog-post selector, except the first/top one. I have highlighted in purple how this looks in FIG 3. below:
FIG 3. The purple boxes represent the space added by the CSS above.
Now let's apply the same treatment to the <header>:
.blog-post__header {
> * + * {
margin-block-start: 2rem;
}
}To make it easier to diferentiate, this time I highlighted the margin in direct sibling children of the <header> tag, in blue. See FIG 4. below:
FIG 4. The blue boxes represent the space added by the CSS above.
With very little CSS code we have been able to achieve consistent spacing in direct sibling children of the <article> as well as nested ones inside the <header>. In the spirit of staying DRY, we could even combine both rules to reduce code repitition.
.blog-post,
.blog-post__header {
> * + * {
margin-block-start: 2rem;
}
}It's not uncommon for the HTML of a document to change. Some of my blog posts, for example, have subtitle text while others don't. The beauty of the Owl selector is that it doesn't depend on specific HTML tags or structure in your document. If new sibling elements are added or some are removed, the spacing previously defined with the Owl selector will continue to work as intended without breaking the document flow.
Oh yes, enough about Owls 🦉, Gap is a beautiful thing and can even be used similarly to the Owl selector for adding space in between sibling child elements.
.parent {
display: flex;
flex-direction: column;
gap: 2rem;
}
FIG 5. Visual of Gap on column and row mode.
If you opt to use Gap for spacing, this means you either need to use display: flex or display: grid on the parent element. This is not a bad thing if you are already using flex or grid on that parent element, but if your only reason for using gap is for spacing purposes, then I would recommend using the Owl technique instead as it requires not additional properties on your parent selector.
I don't think there has ever been a more exciting time to work with CSS than now. The capabilities of CSS and browser support have never been better. Sometimes however, using some of the most basic techniques can make a great impact in our projects.
If you found this post useful, stay tuned for more like it.
Maintaining a DDEV add-on is more than a one-time task. As DDEV evolves, so should your add-ons. This guide will help you stay in sync with recent changes and keep your add-ons up-to-date, reliable, and aligned with current standards.
As part of preparing this guide, I also updated all official DDEV add-ons to reflect the latest recommendations and improvements.
Here are some high-level practices to follow:
ddev-get topic to your GitHub repository if it should be discoverable by the wider community. (If your add-on is currently just an experiment or a fork, wait until it matures to add the topic.)#!/usr/bin/env bash instead of #!/bin/bash at the top of your command scripts, it's more portable and works better across different environments.ddev add-on get and ddev add-on remove should be idempotent. All files added via project_files and global_files must include a #ddev-generated stanza to support proper removalREADME.md change)I'm currently working on a script to streamline the update process. It's a work in progress and available here. I'd appreciate any feedback!
DDEV development is moving fast, and new features are introduced regularly. Here are some recent updates you should be aware of:
ddev get DeprecationThe classic ddev get command is deprecated in DDEV v1.23.5 and replaced by ddev add-on get.
Huge thanks to @GuySartorelli for implementing this feature, and also for proactively updating many add-on README.md files. You've likely already seen a pull request for your add-on!
While all add-ons use the Bats framework for testing, many are still missing Bats libraries that simplify assertions and test writing.
Consider adopting these libraries to enhance test clarity and maintainability.
Example:
Make sure your add-on includes:
These improve the quality of contributions and bug reports.
Your add-on should encourage users to keep DDEV updated. The current recommendation is to add this stanza to install.yaml:
ddev_version_constraint: ">= v1.24.3"
This ensures compatibility and resolves known issues, such as those related to the Mutagen Problem Report.
The old maintained badge required yearly updates, which became a maintenance burden, especially for contributors with many add-ons. It's now replaced by a last commit badge.
To improve visibility and engagement on the DDEV Add-on Registry, add the registry badge to your README.md.
Example:
Starting with DDEV v1.23.5, you can now use ddev dotenv set to manage environment variables more cleanly. This allows your add-on to read custom environment variables defined in .ddev/.env.* files, and use them inside your docker-compose.*.yaml configuration.
This feature is especially useful for advanced setups where flexibility and dynamic configuration are needed.
Example:
If your add-on needs a customized Docker image, the typical approach is to create a separate Dockerfile and configure your add-on to use it. However, for minor tweaks, you can take advantage of the dockerfile_inline option in your docker-compose.*.yaml file.
This approach lets you define a small Dockerfile directly in the YAML, avoiding the overhead of maintaining a separate file.
Examples:
With DDEV v1.24.4, custom commands can now use the MutagenSync annotation.
You should use this annotation if your host or web commands modify, add, or remove files in the project directory. It ensures that file sync is handled correctly when Mutagen is enabled, preventing unexpected behavior or sync delays. (It does no harm and causes no performance issues if Mutagen is not in use.)
Example:
The same DDEV v1.24.4 release introduced support for optional docker-compose profiles, which can be used by add-ons to offer more flexible configuration.
Example:
To keep your add-on repository tidy, safe, and aligned with community standards, consider adjusting the following GitHub settings:
Go to Settings → General in your repository:
Go to Settings → Rules → Rulesets:
mainKeeping your add-on current means less work for users and fewer issues for you to manage. Use this guide as your checklist and stay in sync with the DDEV ecosystem.
Have questions, suggestions, or something cool to share? Join the conversation in our Discord, open an issue, or reach out via email. Your feedback helps improve the tools we all rely on.
If DDEV is helping you or your organization, please consider supporting its ongoing financial sustainability. Every bit helps keep the ecosystem growing and maintained.
Happy maintaining!
In a move to empower the Drupal community, DXPR is providing free access to AI models through the release of DXPR Builder 2.7 “Baby AI.” This initiative allows developers and content creators to leverage the power of advanced AI tools without additional costs or complex integration.
By integrating top vendors including OpenAI's GPT-4o, Google Gemini 2.5 models, Anthropic's Claude 3.7, Grok 3 by XAI, Perplexity AI, and state-of-the-art EU based models by MistralAI.
DXPR ensures that every Drupal user can experience enhanced content creation and management. This free access underlines our commitment to fostering innovation and creativity within the Drupal ecosystem.
These AI providers are integrated in "DXAI" — our own AI platform that ties it all together to provide superior web content writing capabilities.
/write a blog post about future Drupal 12 release (or any prompt) in an empty paragraph.Demo of writing new text in DXPR Builder landing page, the AI is aware of all contents around the new text and therefore requires only a very basic prompt.
Demo of rewriting a text section in a different tone of voice. The tone of voice dropdown is managed with a Drupal Taxonomy.
The DXAI AI server integrates with state-of-the-art AI providers including Perplexity AI which is used for web research, fact checking, and preventing hallucinations.
Site builders can enable DXAI under /admin/dxpr_studio/dxpr_builder/ai_settings (run update.php first). Key options:
2.7 ships a modernized editor chrome with clearer icons, higher contrast, and full keyboard / screen-reader compatibility. Mobile editing is smoother too—perfect for last-minute tweaks on the go.
composer require 'drupal/dxpr_builder:^2.7'update.php.Today’s release is just the first step. Coming soon:
Because the AI beta is free, the only thing we ask in return is insight. Share your triumphs, glitches, and wish-list items on the issue queue or in our commercia support system.
Test the Live Demo | Learn More About DXPR Builder
Happy building—and happy writing—with DXPR Builder 2.7 “Baby AI”!
.hover-style-gby4h650fj:hover {}.hover-style-gbwr97fs50:hover .az-image-content{}.hover-style-gb9a5lwwld:hover {}.hover-style-gbfhe9wze0:hover .az-image-content{}.hover-style-gbexyk080u:hover {}.hover-style-gbdk6ko2m4:hover .az-image-content{}.hover-style-gb619n0fmh:hover {}.hover-style-gbl7pspv26:hover {}.hover-style-gbv4lavke5:hover .az-image-content{}.hover-style-gbqh3tz5cv:hover {}How do you find your niche and become a Drupal Core maintainer?
by daniel.veza / 1 May 2025There are still roughly 23 subsystems of Drupal Core without maintainers. These gaps need to be filled.
While some people may be daunted by this task, rather than trying to learn everything in Core, Daniel explains why it is more valuable to become an expert in one area. This was how he became a Drupal Core maintainer for Layout Builder.
In this video, you will learn about:
Drupal modules are primarily maintained in Git repositories controlled by the Drupal Association on Drupal.org. Before the DA added support for semantic versioning in March 2020, our modules had version numbers like 7.x-1.0 or 8.x-2.1, with the first portion identifying Drupal API compatibility and the second identifying the major and minor version of the module.
However, with modern Drupal (Drupal 8+), a module can support multiple major versions so long as it does not depend on any deprecated APIs in Drupal, its dependencies, or PHP itself. Using the Drupal version number in module version numbers means many of our releases that support Drupal 9, 10, or 11 still start with 8.x-, never mind the fact that we don't support Drupal 8 at all any more.
Semantic versioning allows us to use branch names and tag releases for our various modules based on their own lifecycles. We don't need a new branch for each new major version of Drupal, and we can distribute more predictable updates to end users through Composer with major, minor, and patch versions of our modules.
When we first switched to semantic versioning, we created new branches based on the minor version. Thus, we went from an 8.x-2.x branch off of which we tagged releases to a 3.0.x branch. We never quite knew when to tag a patch versus a minor release in this scenario (i.e., 3.0.1 vs. 3.1.0) and created a situation where we'd have more branches to maintain than we really cared to (3.0.x, 3.1.x, 3.2.x, etc.).
We determined instead to start creating branches named only for the major version (3.x, 4.x, etc.) with release tags that still primarily use minor versions (3.0.0, 3.1.0, 3.2.0, etc.). This will permit us to focus on maintaining a single branch for each module until we need to introduce breaking changes while accommodating the occasional need to backport bug fixes to previous minor versions.
Read more