06 Oct 2026
Drupal.org aggregator
Gábor Hojtsy: Meet Dashi, the 'new' multilingual demo for Drupal CMS
Meet Dashi, the 'new' multilingual demo for Drupal CMS
On September 29, Dries Buytaert showed a multilingual food magazine demo in his DrupalCon Rotterdam Driesnote. That was Dashi, the culmination of our work to give Drupal CMS 2.2 standout multilingual features. Here is what it is, how you can try it and how it came to be.
06 Oct 2026 2:17pm GMT
Jacob Rockowitz: Vibing Drupal: Tale 2 - Using AI to maintain a module, exploring the AI-possible
Introduction
Adopting AI can feel overwhelming, so I am sharing a few tales from my experience creating, maintaining, and assisting with contributed Drupal modules. AI can do a decent job building a "greenfield" Drupal module from scratch, so my first tale is about using AI to build and contribute a module. For my next tale, I want to talk about using AI to maintain an existing "brownfield" Drupal module.
Growing up in NYC, I found brownfields often intimidating, with some so toxic that it can take years for backhoes and dump trucks to remove the contaminated topsoil before construction can begin. With code, a brownfield can contain technical debt, orphaned code, missing tests, etc. Simply put, a brownfield contains unknowns, which means more things can go wrong while working on it. Sometimes a brownfield is so big you need heavy machinery to maintain it, and that is exactly how I felt about using AI on the Schema.org Blueprints module.
Maintaining a large module using AI
Gradually, I have been experimenting with AI to help maintain the Schema.org Blueprints. At first, I would just throw a one-shot prompt at the AI to address a single issue, and it would do a decent job diagnosing and resolving the problem. As I became more confident steering the AI, I started asking it to create issue forks, commits, pushes, and even MRs. As I previously stated in my AGENTS.md I always have "Require me to review all changes before committing and pushing code." and most models respect this rule.
My comfort level reached a point where I am creating {module}-issue-maintenance agent skills that extend my drupalorg-issue-maintenance skills. These maintenance skills have agents to track remote issues in...Read More
06 Oct 2026 9:40am GMT
joshics.in: Drupal 12 and the End of Legacy Debt: A Forced Modernization for Enterprise Engineering
Drupal 12 and the End of Legacy Debt: A Forced Modernization for Enterprise Engineering bhavinhjoshi
Just last month, a prospective client came to Joshi Consultancy Services asking for a cheap cron script to fix a runaway disk usage issue. The reality? They were bleeding money on a deep architectural flaw in their Drupal ingestion pipeline. We see this constantly. For years, the enterprise software industry tolerated a quietly expensive habit: carrying technical debt forward.
Historically, major CMS upgrades were treated as little more than UI refreshes. Agencies seamlessly dragged deprecated code, outdated PHP environments, and fragile database structures from one major version to the next. The result? Senior engineers stuck acting as caretakers for legacy code, while CXOs bled budget on endless maintenance retainers just to keep the lights on.
With the December rollout of Drupal 12, that loophole permanently closes.
The platform is fundamentally altering the rules of engagement. Instead of merely suggesting best practices, Drupal 12 enforces strict architectural modernization right at the server level. Here is why this shift is a massive win for both engineering teams and business leadership.
The Eradication of Deprecated APIs
Spaghetti code. We all hate it. But until now, deprecated code could linger in a system for years, propped up by complex workarounds.
Drupal 12 changes this by aggressively stripping out all deprecated core APIs. The system physically rejects structural laziness. If an agency attempts to stack new logic on top of a legacy foundation, the application simply will not run. You build within clean, modern boundaries from day one. Period.
Enforcing Modern Infrastructure Floors
Previously, organizations delayed server upgrades to save short-term costs, forcing modern applications to run on aging environments.
No longer. Drupal 12 introduces non-negotiable infrastructure floors: a PHP 8.5 minimum runtime alongside raised database requirements (MySQL 8.0 / PostgreSQL 18). This isn't just backend housekeeping. By enforcing these modern tiers, the core framework guarantees a baseline of performance that cannot be compromised by budget-saving shortcuts.
Security as a Structural Guarantee
Enterprise security is too often treated as an expensive, opt-in audit layer applied long after development is complete.
By making Argon2id the default for password hashing, Drupal 12 integrates military-grade resistance against GPU-driven brute-force attacks directly into the core blueprint. For the C-suite, this is an immediate reduction in liability. Security transitions from an ongoing maintenance headache to a baseline structural guarantee.
The Business Outcome: Eliminating the Maintenance Drain
The most profound impact lands directly on the balance sheet.
For CXOs, these forced architectural boundaries solve the most expensive problem in enterprise software: unpredictability. When the core framework refuses to execute legacy PHP and automatically enforces top-tier security standards, the financial drain of technical debt is cut off at the source. Organizations can finally stop paying agency retainers to manage bloated, unmaintainable code.
Drupal 12 is not just a feature upgrade. It is a forced modernization of your engineering culture.
If your organization treats this version bump as a standard IT afterthought, you are actively funding your own future liability. Stop paying for temporary bug fixes. Engineer the blueprint first.
Are your servers, and your budgets, ready for the rollout?
06 Oct 2026 8:32am GMT
Add new comment