Feed aggregator
DXPR: 2.7 "Baby AI" Is Here: DXPR Builder Delivers Free AI Writing to Every Drupal Site
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.
Quick Tour of DXAI in CKEditor 5- Slash command: Type /write a blog post about future Drupal 12 release (or any prompt) in an empty paragraph.
- Watch it stream: DXAI writes live, so you can stop, continue, or tweak on the fly.
- One-click refine: Select any text → choose “Improve clarity”, “Shorten”, “Change tone”, or your custom commands.
1. Adding a new AI text to the DXPR Builder page
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.
2. Adding a new AI text to the DXPR Builder page
Demo of rewriting a text section in a different tone of voice. The tone of voice dropdown is managed with a Drupal Taxonomy.
3. Writing a new text from scratch.
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:
- Select primary and fallback AI vendors
- Set token limits per role
- Map taxonomy terms to command and tone menus
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.
Improved Drupal 11 Integration- Resolved JavaScript crashes in the editor chrome
- Aligned media dialogs with new core markup
- Verified compatibility with Drupal 11’s CKEditor 5 update stream
- Marquee element: Add scrolling announcements with fade edges and reduced-motion support.
- Saved templates UI: Filter by layout and see thumbnails at a glance.
- Inline editing upgrades: Edit buttons, alerts, progress bars, and more without opening popup windows (AI supported everywhere).
- Drupal Media Library & Acquia DAM integration: Browse all your assets in one place.
- composer require 'drupal/dxpr_builder:^2.7'
- Grab a free product key—no credit card, free forever for smal sites.
- Enable the DXPR Builder AI Agent module and run update.php.
- Configure DXAI settings, assign permissions, and start prompting!
Today’s release is just the first step. Coming soon:
- One-prompt landing pages: Describe your offer; DXAI designs and writes a complete page in DXPR Builder.
- Clone from URL / PDF / image: Rebuild existing designs in minutes with structured, editable content.
- Conversational refinement: DXAI will chat with editors to clarify goals, add citations, and align with strategy.
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.
Ready to Build Smarter Drupal Experiences?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 {} Category Drupal Layout Builder DXPR Marketing TeamAcquia.com - Drupal Blog: Drupal SEO: Best Modules, Optimization Tips & Advanced Strategies
DDEV Blog: DDEV Add-on Maintenance Guide
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.
Recommendations for Add-on MaintainersHere are some high-level practices to follow:
- Take inspiration from the official add-ons, see how they're structured and follow similar practices
- Keep an eye on updates in ddev-addon-template
- Track changes in DDEV releases
- Configure your add-on repository settings
- Add the 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.)
- Write a clear description and include relevant keywords to improve discoverability
- Use #!/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.
- Ensure your add-on cleans up after itself: both 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 removal
- Remember to publish a new release after any update (unless it's just a README.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!
What's New in the DDEV EcosystemDDEV 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!
Better Testing with Bats LibrariesWhile 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:
Issue and PR TemplatesMake sure your add-on includes:
These improve the quality of contributions and bug reports.
Recommending DDEV Version ConstraintsYour 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.
Add-on BadgesThe 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:
Advanced Customization with FlagsStarting 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:
- https://github.com/ddev/ddev-adminer#advanced-customization
- https://github.com/ddev/ddev-adminer/blob/main/docker-compose.adminer.yaml
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:
- https://github.com/ddev/ddev-solr/blob/main/docker-compose.solr.yaml
- https://github.com/ddev/ddev-opensearch/blob/main/docker-compose.opensearch.yaml
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:
Support for Optional Compose ProfilesThe 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:
- https://github.com/ddev/ddev-mongo/blob/main/docker-compose.mongo.yaml
- https://github.com/ddev/ddev-mongo/blob/main/commands/host/mongo-express
To keep your add-on repository tidy, safe, and aligned with community standards, consider adjusting the following GitHub settings:
General SettingsGo to Settings → General in your repository:
- Uncheck features you don’t use, such as Wikis, Discussions, and Projects
- Enable Allow squash merging with Pull request title
- Disable Allow merge commits and Allow rebase merging
- Enable Always suggest updating pull request branches
- Enable Automatically delete head branches
Go to Settings → Rules → Rulesets:
- Click New ruleset → New branch ruleset
- Set Ruleset name to main
- Under Enforcement status, select Active
- Under Targets, click Add target → choose Include default branch
- Under Rules, enable:
- Restrict deletions
- Require a pull request before merging (set Allowed merge methods to only Squash)
- Block force pushes
- Click Create to apply the ruleset
Keeping 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!
Centarro: Revisiting semantic versioning in Drupal Commerce
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 moreThe Drop Times: Behind the Scenes of DrupalCamp Ottawa 2025: How This Free Event Came Together
The Drop Times: What Happens When a Podcast Outlives a Decade? Talking Drupal Knows
Jacob Rockowitz: Back to the basics: Learning how to build a Drupal module using AI
Preamble
I began my last blog post, "My Drupal, AI, and Schema.org Manifesto," with an introduction that helped me to start discussing the use of AI in my daily Drupal work. This introduction reveals that I feel overwhelmed about where to begin exploring integrating AI with Drupal.
A Drupal AI module and ecosystem exist that have accomplished remarkable feats. I am eager to delve into the implementation and extensibility of the Drupal AI module; however, diving immediately into the code is daunting and could hinder my need to familiarize myself with using AI and comprehending how it works. Therefore, I am returning to the basics and revisiting one of my first Drupal achievements: building a module… using AI.
Hypothesis
AI will soon replace basic Drupal tasks, including creating simple modules. When this happens, the definition of entry-level development skills will evolve. AI will not eliminate jobs; instead, it will enhance workers' productivity and efficiency. Therefore, I want to explore how capable AIs are at building a Drupal module. I also want to explore if AI can help a new Drupal developer create their first module.
Theories
Below are some theories I want to explore and keep in mind.
- Keep it simple and small.
AIs can comprehend vast amounts of data and relationships - we cannot. - Provide a lot of context.
AI performs significantly better when given as much context as possible. This ensures that both people and machines understand each other. - Failure is part of the process.
Assume there will be mistakes and dead ends. An iterative approach leads to a better solution and understanding.
Goals
I've already used the word 'overwhelmed' a few times, and to keep my exploration and experimentation from...Read More
Drupal Association blog: Extended Support on Drupal 7 vs. Drupal 10 Migration: Which Path Should You Take?
As the digital landscape evolves, organizations relying on Drupal 7 (D7) face a pivotal decision: opt for Extended Support or embark on a migration to Drupal 10 (D10)?
Both options have their pros and cons, depending on your timeline, budget, and long-term digital strategy. Let’s break it down so you can make the best decision for your organization.
Option 1: Extended Support – A Temporary Safety NetExtended Support ensures your D7 site remains secure and functional beyond the official end-of-life deadline, giving you extra time to plan a migration.
Benefits of Extended Support:- No rush – Your site remains secure, with critical security updates and patches, without having to migrate immediately
- Budget flexibility – Spread out costs instead of making a big investment all at once
- Strategic breathing room – More time to evaluate your business goals and plan a migrations in the future
- Not a permanent fix – In the long run you’ll need to migrate
- Potential rising costs – Maintaining older technology can become more expensive over time
- Limited innovation – You won’t benefit from the latest features and improvements in D10
Migrating to D10 is a long-term investment in security, performance, and innovation. While it requires upfront effort, it ensures that your digital platform is modern, scalable, and ready for future growth.
Benefits of Migration to D10:- Future-proof technology – Stay ahead with the latest security updates and performance enhancements
- Better User Experience (UX) – New features, improved accessibility, and a more flexible design
- Long-term cost efficiency – Reduce maintenance costs for outdated technology
- Upfront investment – Migration requires planning, resources, and budget allocation
- Complexity – The process can be challenging, especially for highly customized sites
- Learning curve – Teams may need time to adjust to the new system
At Dropsolid, we understand that not every organization is ready to migrate immediately. That’s why are part of the Drupal 7 EOL program.
What sets us apart?
Only 3 companies globally qualify for the EOL program and offer Extend Support for D7. We are the only partner in Europe, with offices in Europe and the US. This makes us the go-to-expert in the region for maintaining your D7 site securely while you work on a seamless transition to D10.
At the same time, we know that migration is inevitable—and when you’re ready, we can evolve your D7 and can help you migrate to D10 too.
What we offer:
- We keep your D7 site secure with ongoing updates and maintenance
- Migration to D10: customized migration roadmap, tailored to your business needs, covering everything from technical setup to team training
- Future-proof growth: our roadmap ensures that your site isn’t just D10-ready, but also DXP-ready, seamlessly integrating with your existing tools
Find all info about our related services here.
Key considerations: How to Decide?When choosing between Extended Support and Migration to Drupal 10, ask yourself:
- What’s your timeline? Do you need more time, or are you prepared for transition?
- What’s your budget? Can you invest in migration now, or do you need to spread costs over time?
- What are your long-term goals? Do you want to future-proof your site, or is short-term maintenance enough for now?
- How complex is your current setup? A highly customized site may require extra planning before migrating.
- If you need more time to plan and budget, Extended Support can provide a temporary solution.
- If you’re ready to future-proof your digital platform, migrating to D10 is the smart choice.
Either way, Dropsolid has your back—whether it’s keeping your current site secure or guiding you through a seamless migration. Let’s make the right move together.
Ready to explore your options? Get in touch with us today!
Specbee: Programmatically creating a Block in Drupal
Drupal Starshot blog: Marketplace Share Out #2: Surfacing Critical Assumptions
Over the past few weeks, the Marketplace Working Group and volunteers have been busy laying the foundations for the months ahead. As a reminder, our goal is to determine whether a Drupal Site Template Marketplace can be designed in a way that is trusted, inclusive, sustainable, and viable—and to reach a go/no-go recommendation before DrupalCon Vienna.
From Idea to Critical AssumptionsOver the past few weeks, the Marketplace Working Group has been focused on a key early step: identifying the assumptions that must be true for a Drupal Site Template Marketplace to succeed.
Rather than moving directly into planning and building, we are working transparently with the community to surface and stress-test our most critical assumptions before making any final decisions.
In this update, we’ll share where we are now—and where we still need your help to validate what matters most.
Why Focus on Critical Assumptions?The Marketplace is an exciting idea, but it brings with it real risks. Some assumptions, if wrong, could seriously harm Drupal’s ecosystem, community trust, or financial health. We’ve identified the early critical assumptions—those with:
- High impact if we’re wrong, and
- High uncertainty based on what we know today.
Rather than ignoring or minimizing these risks, we are bringing them forward, openly and early, so the community can engage with them directly.
Critical Assumptions Emerging So FarFrom the emerging community feedback (Survey #1: Shaping the Drupal Marketplace: Contributor Perspectives, slack prompts, and deep discussion in this thread), several high-risk assumptions have emerged:
1. There will be enough demand for site templates to sustain a marketplace.If we build it, will they come? And will they pay?”
Without real demand, the Marketplace won’t achieve its goals—and may strain community resources without impact.
How we’ll validate: Ongoing surveys to Drupal users and agencies; testing via Drupal CMS starter templates; scenario-based surveys during Real-Time Collaboration (RTC) sessions.
2. High-quality templates will be created and maintained.We need to avoid a freemium wasteland of abandoned templates.”
Success depends on attracting contributors with design and UX skills—and ensuring long-term maintenance.
How we’ll validate: Contributor surveys about incentives, motivations, and barriers; prototype pilot tests; deeper exploration in RTC sessions.
3. The operational complexity of running a marketplace is manageable.The DA can’t afford to build and maintain a marketplace that requires millions to operate."
The Marketplace must be financially and operationally sustainable from day one.
How we’ll validate: Modeling operational costs; evaluating automation options; benchmarking against other marketplaces.
4. A commercial element can be introduced without undermining open source values.Commercialization must not erode what makes Drupal different.”
If done poorly, a commercial marketplace could fragment the ecosystem, damage trust, and alienate contributors.
How we’ll validate: Community consultation on licensing models; exploring models for attribution, revenue sharing, and code stewardship.
5. Governance structures can maintain trust and quality at scale.If trust fails, the marketplace fails.”
The Marketplace must earn and maintain user and contributor trust through clear standards, quality controls, and transparent processes.
How we’ll validate: Testing community expectations through surveys; prototyping governance models; pilot feedback loops.
Important Tensions EmergingThrough open discussion, several important tensions have also surfaced:
- Open Source vs. Monetization:
Balancing the spirit of FOSS with the need for financial sustainability. - Support Expectations:
Clarifying who provides support for templates—and setting fair boundaries. - Future Risks:
Avoiding the slippery slope toward undermining Drupal collaborative ecosystem model or a poor signal-to-noise ratio from low quality or unsupported templates.
We recognize that these are not easily solved with a single conversation. They will require ongoing community engagement, transparency, and iteration.
Where We Are NowHere’s what’s been accomplished so far:
- Roadmap finalized for how we'll reach a go/no-go decision.
- Volunteer team onboarded, and we're beginning weekly coordination around community engagement.
- Community framing completed, based on early signals from surveys, Slack prompts, and discussions.
- Critical assumptions identified through our Week 2 Assumption Slam.
Over the coming weeks, we’re moving systematically through key questions:
- Contribution Value: What would make it worthwhile for someone to contribute a template?
- Governance & Trust: What signals would make users feel confident using a marketplace template?
- Ecosystem Fit: How can the marketplace align with, not compete against, existing agency and contributor models?
- Contributor Experience: What support is needed to help contributors succeed?
Each week, we’ll continue to validate assumptions, evolve our thinking, and ensure that what we’re building—if we build it—is something the community truly wants and can stand behind.
Thank you to everyone who has already shared feedback, challenged assumptions, and raised important questions. Your voices are helping shape this work.
Stay tuned—and stay involved.
How You Can Get Involved- Respond to weekly Slack prompts.
This week: What would make it worthwhile for you to contribute a template? - Join our upcoming Real-Time Collaboration (RTC) session
First session: 1 May 2025 at 15:30 UTC about Co-creating Value and Incentives - Share your perspective on the surveys when they open.
How could a Drupal Site Template Marketplace Help You? for Agencies and potential End Users of templates. - Bring forward your own assumptions and risks we may have missed.
Nextide Blog: Maestro and ECA Integration
When Maestro first hit the Drupal scene, it was 2011, Drupal 7 was the main release and the Rules module was the primary mechanism you'd use to react to events happening in your Drupal system. Maestro integrated easily with Rules to allow site builders to fire off Maestro workflows when events happened in Drupal. Fast forward to 2025, and the ECA module is rapidly gaining traction. Just like with Rules, Maestro can integrate with ECA.
Talking Drupal: Talking Drupal #499 - Contact Form Initiative
Today we are talking about The Contact Form Initiative, What it is, and how it helped Drupal with guest J. Hogue. We’ll also cover Local Tasks More as our module of the week.
For show notes visit: https://www.talkingDrupal.com/499
Topics- What is the Contact Form initiative
- What makes up the contact form recipe
- Why did you want to run this initiative
- What are the responsibilities of an initiative lead
- Were there any unexpected speed bumps
- Who was involved
- As a non-backend developer, any hesitation to lead this effort
- What was onboarding like
- What was the timeline
- Any tips for others thinking of leading an initiative
J. Hogue - oomphinc.com artinruins
HostsNic Laflin - nLighteneddevelopment.com nicxvan John Picozzi - epam.com johnpicozzi Kathy Beck - kbeck303
MOTW CorrespondentJacob Rockowitz - jrockowitz.com jrockowitz
- Brief description:
- Nodes can have too many local tasks. Only the first few, like View, Edit, Layout, Revisions, and Translate, are used daily. Would you like to hide or reorder less commonly used local tasks, which include Usage, Clone, Devel, and Convert. There is a module for that
- Local Tasks More (local_tasks_more)
- Brief history
- How old: created on November 6th, 2024
- Versions available: 1.0.0-beta2 r
- Maintainership
- Actively maintained
- No security coverage
- Has test coverage
- Does not require much documentation
- No issues
- Usage stats:
- 22 sites
- Maintainer(s):
- jrockowitz (me)
- Module features and usage
- Enter the base routes that support the show more/less task link and alterations.
- Enter the local task id and the altered title and weight. Set the local tasks to FALSE to remove it.
- Enter the number of links to trigger show more/less tasks link/icon from primary and secondary tasks (aka tabs).
The Drop Times: Strengthening Drupal, One New Developer at a Time
If you’ve been keeping an eye on Drupal community updates, you’ve probably seen the IXP Fellowship making some waves — and for good reason. It's the kind of program that feels long overdue: giving new Drupal developers, the ones who know their way around but haven't had their first real break yet, a way into the industry. Michael Anello, in his blog post, highlighted how the IXP is about recognising that real-world experience needs a starting point — and it’s refreshing to see that truth backed by genuine incentives. With early adopters like Seed EM and Digital Polygon already on board, the IXP Fellowship isn’t just an idea anymore; it’s producing real graduates and real results.
The real story here isn’t just that there’s a new pipeline — it’s that the Drupal community is finally getting serious about building for the future. On LinkedIn, Carlos Ospina praised the program's impact on both developers and companies, noting its potential to reshape the way new talent enters the field. Too often, companies talk about wanting fresh talent without providing meaningful opportunities to beginners. IXP changes that put mentorship at the centre and reward companies for stepping up. In his blog, 'A Drupal Couple,' he emphasised the value of bringing in new faces who now have a clear way to gain professional experience without hitting the usual barriers. That's not just good news for the Fellows; it's a necessary move for Drupal’s long-term growth.
If the community embraces this the way it should, the IXP Fellowship could quietly shift how Drupal brings in and develops new talent. It's not about overnight transformation; it’s about making sure newcomers aren’t left out simply because they’re new. Giving people a real start, with mentorship built in from the beginning, could mean stronger teams and a more sustainable community over time. It’s a small step that, if done right, could make a real difference where it matters.
Now, let's dive into the most important stories from last week.
DISCOVER DRUPAL- Drupal in Government: Top Indian States That Run Official Websites on Drupal
- IXP Fellowship Graduates from Initiative to Functional Drupal Program
- Metadrop Releases Updated Entity Mesh Module for Drupal Content Visualization
- Blocked from Contributing, Helped by a Veteran: How a Small Drupal Module Exposed a Bigger Problem
- Executive Voices Wanted: Take the Drupal Executives Network Community Survey
- Inside Edmonton’s Drupal Meetup Revival: Organizers Share Goals, Challenges, and What’s Next
- DrupalCamp Burkina Faso 2025: Igniting Africa’s Digital Future Through Community and Code
- International Splash Awards 2025 Now Accepting Submissions Ahead of DrupalCon Vienna
- Become a Volunteer at DrupalCon Nara 2025
- Drupal Open University Initiative Expands with "Drupal in a Day" Workshop at Drupaljam 2025
- April 2025 Drupal for Nonprofits Chat Open to All Users and Developers
- DrupalCon Vienna 2025 Seeks Proposals for Community & Health Track
- Drupal Café Lutsk #27 Held in Person and Online with Technical and Community Sessions
- Drupal Mascots Get AI-Generated Starter Packs Ahead of DrupalCon Vienna 2025
- Inside Releem: How AI Is Reshaping MySQL Performance—Insights from Roman Agabekov
- Teun Van Veggel Announces New Mapsemble Module for Drupal
We acknowledge that there are more stories to share. However, due to selection constraints, we must pause further exploration for now.
To get timely updates, follow us on LinkedIn, Twitter and Facebook. You can also join us on Drupal Slack at #thedroptimes.
Thank you,
Sincerely
Kazima Abbas
Sub-editor, The DropTimes.
Smarter Digital Health: See the Future in Action
Nuvole: More peace of mind when applying recipes or letting AI configure your site
Last week I attended the Drupal Dev Days in Leuven and many of the sessions and also conversations in the hallway and the contribution room were about Drupal CMS and AI.
The foundational engine behind Drupal CMS is the recipe system, which allows a bunch of configuration changes to be bundled and applied to your site. This is really cool, but it may do things you are not completely aware of. Unfortunately there is no way to “undo” a recipe. The same problem occurs if one is letting AI change configuration.
DDEV snapshots and git commitsThe proper solution of course is to export the configuration and version it in git before starting to play with recipes, as well as periodically in between applying recipes to have more save points to go back to. Since recipes can also add default content and some configuration can not be deleted when there is content for it, it means that sometimes a previous git checkout of the configuration can not be imported. Therefore, the best solution is to create database backups and roll them back when needed. DDEV makes this very easy to do, and so that would be the first recommendation to address the problem and it will always work.
However, the ddev snapshots do not really give one a lot of information of what changed. The configuration in git is a lot better, but it requires an extra manual step to create the export and commit it to git. That may not be instinctive to most drupal users, especially not the target audience of Drupal CMS.
What if Drupal could help us with that?It turns out that Drupal core introduced the concept of configuration checkpoints when recipes were added. The idea is that before a recipe is applied a checkpoint is set, then when the recipe application fails the configuration is rolled back to the checkpoint.
There is an issue for adding a command to revert to checkpoints but no work has even started.
I had the idea already at Drupalcon Barcelona 2024, but after discussions in Leuven I decided to implement a UI for the configuration checkpoints.
How does Config Checkpoint UI work?So far the first version is very simple: It exposed some of the basic API to the UI. One can create new checkpoints, delete checkpoints and revert the site configuration to an older checkpoint. The reverting is done essentially the same way as the core command does: importing from the checkpoint storage. This is very similar to what Config Split does and the reason for which I thought it was a good idea to try.
Future and LimitationsThere are a few bugs in other projects to watch out for: Project browser does not set a checkpoint, and core has a bug when deleting checkpoints. Of course there may be lots of bugs in the new module itself. In particular one of the things I have ran into is that the uninstall validation is a bit broken, so some of the recipes can not be rolled back when they add fields that depend on a module added at the same time. I will have to check where exactly this bug is hiding. More advanced things could also be explored, for example merging checkpoints or deleting checkpoints without deleting everything that came before.
Tags: Drupal PlanetThe Drop Times: Drupal in Government: Top Indian States That Run Official Websites on Drupal
MidCamp - Midwest Drupal Camp: MidCamp Needs You!
If you've been looking for non-code opportunities to give back to the Drupal community, we have the perfect solution! Volunteer to help out at MidCamp 2025.
We’re looking for amazing people to help with all kinds of tasks throughout the event including:
Setup/TeardownFor setup, we need help making sure registration is ready to roll, getting hats ready to move, and getting the rooms and walkways prepped for our amazing sessions.
For teardown, we need to undo all the setup including packing up all the rooms, the registration desk, cleaning signage, and making it look like we were never there.
We need ticket scanners, program dispersers, and people to answer questions.
Help us to count heads, introduce the speakers and make sure they have what they need to thrive, and help with the in-room A/V (by calling our Fearless Leader / A/V Genius)
- We won't turn away any help, so if there's something you'd like to do to help, just let us know!
Every volunteer will receive credit on Drupal.org, so be sure to include your profile name when you sign up to volunteer.
If you’re interested in volunteering or would like to find out more, please reach out to the #volunteers channel on the MidCamp Slack.
There will be a brief, online orientation leading up to the event to go over the volunteer opportunities in more detail.
Questions?Don’t miss a beat!
- Join us on MidCamp Slack to chat and get updates.
- Follow us on socials, including Bluesky and Mastodon, for announcements and news.
Keep an eye on our news page and subscribe to our newsletter for updates on the venue, travel options, social events, and speaker announcements.
MidCamp 2025 is your chance to learn, grow, and connect—don’t miss out!
Do volunteers still need a ticket?Yes. While we appreciate your help, we still ask volunteers to purchase a ticket. We have flexible ticket options for you to choose from. As a volunteer you'll also get dibs on the MidCamp Archives... our seemingly endless box of vintage swag.
Phase2 Launches Pharma iCX: Delivering Impactful, Compliant Digital Solutions for Pharmaceutical Companies
The new platform builds on Health iCX success, combining consumer engagement with regulatory compliance for healthcare professionals and patients.
Arlington, VA, April 24, 2025 – Phase2, a leading digital agency with deep healthcare ecosystem expertise, today announced the launch of Pharma iCX, an intelligent customer experience platform designed for pharmaceutical organizations. This expansion of Phase2's iCX suite applies proven methodologies from the successful Health iCX platform to address the distinct needs of pharmaceutical communications.
Pharma iCX solves key challenges pharmaceutical companies face in creating compliant, information-rich digital platforms. The pre-configured solution enables rapid deployment of compelling digital destinations where audiences can quickly find, understand, and act on critical information. The platform specifically supports pharmaceutical needs including merger and acquisition onboarding, PRC to FDA approval processes, and seamless management of both HCP and patient-facing content.
Key features of Pharma iCX include:
- Compelling Content Frameworks: Creative templates that drive message retention and action while maintaining regulatory compliance.
- M&A Digital Integration: Streamlined processes for rapidly harmonizing digital assets during mergers and acquisitions.
- Regulatory Pathway Support: Specialized workflows supporting the journey from PRC to FDA approval throughout product development cycles.
- Dual Audience Engagement: Unified platform for managing both HCP and patient-facing content with tailored messaging.
- AI-Enhanced Compliance: Artificial intelligence tools that maintain regulatory compliance while identifying opportunities for creative engagement.
"Pharmaceutical organizations need digital solutions that combine nimble, creative engagement practices with unwavering compliance," said Emily White, SVP, Marketing at Phase2. "Pharma iCX applies our healthcare ecosystem expertise to address specific pharmaceutical needs, empowering companies to deliver influential, compliant information that drives action from both healthcare professionals and patients."
Pharma iCX can be built on robust platforms including Drupal, Sitecore, Adobe Experience Manager, and Optimizely. It features specialized tools for industry-specific integrations, creative content development, regulatory document management, and audience-specific messaging. The platform complements regulatory submission systems and marketing automation tools, ensuring speed to market while maintaining compliance.
Early adopters report significant improvements in specialty drug education, message comprehension and audience engagement, particularly around product launches and merger activities. The platform's approach to compliance has proven valuable for delivering effective information across audience segments while respecting regulatory boundaries.
For more information about Phase2’s iCX suite and to schedule a demo, please reach out below. About Phase2Phase2 is a digital experience agency dedicated to advancing the human experience through technology. Specializing in healthcare, Phase2 combines data-driven insights with innovative solutions to create impactful digital products. With a commitment to excellence and a passion for improving patient outcomes, Phase2 partners with organizations to navigate the complexities of digital transformation.
Media InquiriesLindsey Di Costa
Marketing Communications Manager, Phase2
ldicosta@phase2.io
Lindsey Di Costa brings a proven track record in effective brand launch and marketing, creating and implementing integrated campaigns, and coordinating communications to her role as Phase2's Marketing Communications Manager. With a diverse background in healthcare, startup, and tech, she brings a unique point-of-view to internal and external communications.
DrupalEasy: The new IXP program: Ushering in needed fresh Drupal talent with bona fide incentives for employers
Organizations can now be rewarded with Drupal contribution credits (among other enticements) for hiring new, inexperienced (IXP) Drupal developers.
After many months (years?) of planning, the Drupal IXP program is open and accepting applications for hiring organizations. From now forward, any participating organization that hires a new Drupal developer (with less than 3 months of paid experience) can earn 250 contribution credits upon successful program completion.
I'm super proud to have been working with Carlos and Anilu (A Drupal couple) and a number of other volunteers on this effort and am really happy to see it launched.
Why?The Drupal developer community is getting older. With modern Drupal being more challenging to learn for new developers (especially compared with Drupal 7), fewer and fewer new Drupal developers have been joining our ranks. In order to survive, we need to build up the pipeline of new, fresh-minded, Drupal talent.
How does the program work?Interested organizations can apply to participate at Drupal-IXP.site. After a quick manual review, accepted organizations will be provided with a coupon code to post an IXP position on jobs.drupal.org for free.
We have worked with the Drupal Association on creating a dedicated area for IXP positions on jobs.drupal.org.
Interested IXP developers apply for positions, and upon an offer from one of the participating organizations, both parties notify the Drupal-IXP site that the engagement has begun.
Both the IXP developer and hiring organization are required to submit periodic reports to Drupal-IXP to ensure all program requirements are being met (including a minimum number of mentoring hours.)
Once the minimum program length has been met (160 hours of paid work,) the hiring organization is eligible to receive 250 contribution credits upon a final review by IXP program volunteers.
What types of tasks are IXP developers suited for?Keeping in mind that individual IXP’s will have diverse backgrounds, and, based on research we've done, IXP developers may be well-suited for tasks like:
- Drupal core and module updates
- Drupal site-building
- Quality assurance
Depending on the non-Drupal background, IXPs might also be well-positioned to take on more complex or specific tasks.
We realize that the more guidance we can provide hiring organizations, the more successful this program will be; so we’ve started a Best practices for hiring organizations document and plan on collecting data from more organizations to help provide additional information (and case studies) to help with the IXP hiring process.
What are the program requirements?The complete Drupal IXP requirements for interested parties are available at https://www.drupal.org/ixp
The IXP for new developers page details the minimum recommended skills level (although hiring organizations are welcome to hire at any skill level) as long as the IXP developers being hired have less than 3 months of paid experience.
The IXP for organizations page details mandatory program requirements including, but not limited to, at least 160 hours of paid work and a minimum of 1 hour of mentoring for every 10 hours of work.
Moving forwardThis is only the beginning of the Drupal IXP program. We are looking forward to learning valuable lessons along the way, and fully expect the program to evolve as more and more organizations get involved.
Have questions? Fee free to use our Contact page or ping us in #ixp-fellowship channel of the Drupal Slack workspace.
Pages
