08 Jul 2026

feedDrupal.org aggregator

DDEV Blog: TYPO3 Projects on Coder.ddev.com

TYPO3, DDEV, and Coder logos stacked vertically

coder.ddev.com gives you a full DDEV environment in the cloud, no local Docker required. This is a quick look at using it for a TYPO3 project with the freeform template.

For general background on coder.ddev.com, including access requirements and the other available templates, see the announcement post.

Watch the Video

What You'll See

Steps

  1. Get access to coder.ddev.com either via your organization having "partner" status with DDEV Foundation or by asking for access.
  2. Log in to coder.ddev.com with GitHub and create a workspace using the freeform template. The project name you choose matters, since coder.ddev.com uses it to set up proxying.
  3. Open a terminal in the workspace (web terminal, VS Code Web, or SSH via the coder CLI) and clone your TYPO3 project.
  4. Run ddev coder-setup once in the project directory, then ddev start. If the project has a post-start Composer install hook, like rfay/typo3demo, it'll finish setting itself up automatically.
  5. If ddev launch shows a trusted-host error, it's because Composer brought in the rest of the code after the first ddev start already generated additional.php. Run ddev restart to regenerate it, then reload.

Sharing What You Built

The workspace can be shared with other coder.ddev.com users directly, without any extra setup.

It can also be shared with ddev share, since rfay/typo3demo uses a relative base (/camino) instead of a hardcoded URL. Projects that do hardcode a full URL in base need the pre-share/post-share hook fix described in Sharing Your TYPO3 Project with ddev share.

Learn More

If you have questions, reach out in any of the support channels.

Follow our blog, Bluesky, LinkedIn, Mastodon, and join us on Discord. Sign up for the monthly newsletter.


This article was edited and refined with assistance from Claude Code.

08 Jul 2026 9:55pm GMT

The Drop Times: Yii3 Offers Drupal Teams a PHP Framework Reference Point

Architecture choices become clearer when the CMS is not the whole application. Yii3 helps frame where Drupal should lead and where a separate PHP service may belong.

08 Jul 2026 11:51am GMT

joshics.in: The Drupal Paradox: Why Enterprise Complexity Becomes a Liability

The Drupal Paradox: Why Enterprise Complexity Becomes a Liability bhavinhjoshi

The Drupal Paradox: Why Enterprise Complexity Becomes a Liability by Joshi Consultancy Services


In the enterprise world, Drupal is often chosen for its unparalleled flexibility and power. Organizations, including large-scale research institutions like CERN, have historically relied on Drupal to manage thousands of complex, interconnected websites. Yet, we are witnessing a trend where massive Drupal ecosystems are migrated to alternative platforms.

This migration is rarely about the CMS engine itself. It is a symptom of The Drupal Paradox: the same flexibility that makes Drupal the ideal choice for an enterprise also creates the conditions for its eventual mismanagement.

The Anatomy of Mismanagement

When an organization manages hundreds of websites, Drupal's modular nature can become a double-edged sword. Mismanagement typically creeps in through three specific avenues:

  • The "Module-First" Trap: Teams often prioritize speed by installing pre-built modules to solve business-critical problems rather than architecting a robust, custom solution.
  • The Accumulation of Technical Debt: Over time, "vibe-coded" configurations and amateur patches are layered on top of the core architecture. This turns a stable system into a brittle, unmaintainable mess that becomes increasingly difficult to upgrade.
  • The Documentation Void: When teams treat documentation as an afterthought, the system becomes a "black box." Once the original architects leave, the remaining team is paralyzed by the fear of breaking an undocumented system.

The Migration Fallacy

Many organizations view migration as a clean slate. They assume that moving to a new platform will solve the underlying technical and process issues. This is a mistake.

If an organization lacks the governance to manage a Drupal ecosystem, they will inevitably reproduce the same technical debt on any other platform they choose. Migration is not a cure for poor architectural discipline, it is simply a very expensive way to reset the clock on systemic failure.

Preventing the Paradox: A New Governance Standard

To ensure the longevity of an enterprise CMS, organizations must shift from a "content-editing" mindset to an "engineering-discipline" mindset:

  • Enforce Architectural Governance: Every new module or custom feature must be vetted for its impact on performance and long-term maintenance. Decisions must be based on trade-offs, not convenience.
  • Prioritize Documentation as Code: Documentation should be a mandatory component of the development lifecycle, not a "nice-to-have" add-on. If a change is not documented, it is not considered complete.
  • Decouple Business Logic: Keep the CMS focused on content orchestration and move heavy business logic into independent microservices or APIs. This reduces the blast radius of any individual CMS failure.
  • Reject "Vibe-Coding": Demand that your engineering team articulates the technical trade-offs of their decisions before they commit code. A professional engineer must be able to justify the "why" behind the "what."

Final Thoughts

Drupal is not failing, enterprise governance is. If you find your organization trapped in a "paradox" where your CMS feels like a burden, stop looking at migration as your only option. Start looking at the structural integrity of your team's processes.

We don't believe in "quick fixes." We believe in building systems that respect your investment. If you are struggling with a paradox of your own, we approach enterprise architecture differently.

Add new comment

08 Jul 2026 11:07am GMT