Drupal 9 marketing site, ~180 pages, 40 blog posts, the one contractor who knew it left. PHP and module updates were piling up, so instead of going to Drupal 10 I pointed Claude Code at it and rebuilt in Next.js.

What it did:

• Read the modules and theme to map content types, fields and views, then pulled the actual content out via JSON:API into MDX files. Fields became frontmatter, embeds became components.
• Rebuilt the theme as React components, close enough that nobody noticed
• Recreated the blog/tag listings as filtering over the files
• Wrote the redirect map for old URLs
• Set up SST with OpenNext: CloudFront, S3, Lambda, Route53 in one config. sst deploy, done.

Where it struggled: ~600 images in weird paths took a few passes, webforms had to be rewritten against Lambda + SES (and I lost spam protection for a week without noticing), and it kept trying to add a headless CMS until I told it Markdown in git IS the CMS.

Drupal's been off two months. Hosting went from $90/mo to ~$4. Content changes are now "open Claude Code, describe the edit, review PR, merge."

Downside: nobody non-technical can edit anything without me. Fine for us now, but I'm wondering if I've just made myself the new single point of failure, same as the contractor was.

What am I missing? Anyone running content-in-git + AI as the CMS past a couple hundred pages?

The Drupal Association is conducting its first-ever Drupal Ecosystem Retrospective. This is a good opportunity to directly give the Drupal Association your candid feedback and thoughts about what you feel is going well and what needs improvement in the Drupalverse.

The due date for filling this out is September 20, 2026 (I have no idea if there’s a specific time; I’m just a random Drupaler who wants as many people in our community to be heard). The due date happens to be the weekend before the Drupal Association’s board retreat and shortly before DrupalCon Rotterdam.

Anyways, please consider filling this out and/or sharing with other fellow Drupalists!

https://docs.google.com/forms/d/e/1FAIpQLSdgHEgx9QbutXygHlgxcJjgLn24gMQok2h2ujB9ePH_JpH9dg/viewform?usp=send_form

Hi everyone!

I'm a Drupal developer from Argentina and I'm considering starting to offer my services as a freelance developer, mainly working with clients from the US or other English-speaking markets.

I have 5+ years of hands-on Drupal experience, working with custom modules, content types, hooks/events, custom blocks, Layout Builder, Twig/CSS, SDC/Storybook, integrations, caching and performance optimization. I also have a broader Full-Stack background with React, Next.js, Node.js/NestJS, PHP/Laravel, Docker, AWS and CI/CD.

I've been working remotely with US-based teams, but most of my current work is through a company rather than directly with clients. So I'm trying to understand what the current freelance market looks like for Drupal developers.

A few questions for those of you already freelancing:

• What hourly rate would be reasonable for someone with my experience?
• What rates are you currently charging or seeing in the market?
• Is it realistic to get freelance work with basic spoken English but good written English, especially for remote work?
• How important is spoken English in your experience? Are most interactions with clients meetings, or is a lot of the communication done asynchronously through Slack/email/tickets?

I'm not necessarily looking to charge US senior rates from day one. I'd rather start with a reasonable rate, build some direct client experience and gradually increase it.

I'd really appreciate any advice or experiences you can share. Thanks!

I've been making Drupal sites for about 12 years, so it's rare that I get stumped when trying to figure out a good solution to a problem, but this one is tricky...

Okay so this is quite a big site (approx. 5000 nodes), with like 10 taxonomy vocabularies. One of them is Tags, with like 2000 tags.

And for almost all of those vocabs, the standard Taxonomy Term view (that appears on route /taxonomy/term/%) that appears on their term pages is just fine.

But for one of the vocabs - called Organisations - I need to use a different view. This view needs to have different fields and filters, and a different treatment for the Title override.

My first thought was to use a unique alias pattern (from Pathauto) to show those term pages at different URLs (e.g. /organisations/*), and then make the new view and make it show on the same route. However that doesn't matter, because the Taxonomy Term view shows on the route /taxonomy/term/%, so it applies to the Organisations pages no matter what I make their URLs / aliases.

And that Taxonomy Term view still applies even if I add a filter that excludes the Organisations taxonomy. In other words, the filter only reduces the results, but it doesn't affect whether the view is applied to that page or not.

Then I though perhaps I could make new pages for each organisation, then place block views on those pages to simulate the term fields and the grid of tagged content, similar to the other term pages. But this doesn't really work, because for those block views, they have to get their "contextual filter" value of the term ID from somewhere. The Taxonomy Term view just gets it from the URL, but with these new pages, the term IDs wouldn't be in their URLs (or I could put the ID in the URL, but that would look bad).

Do you have ideas on how to solve this in a practical way?

the Webflow Source announcement sent me back into Acquia’s Source CMS product guide.

it explicitly says "customers can’t modify the underlying Drupal code or install contributed modules".

I understand the deal: less maintenance responsibility, fewer opportunities to make a beautifully customized disaster.

buttttt Drupal’s flexibility is also why a lot of people chose it.

where does that tradeoff work for you?

for a straightforward marketing site, I can see the appeal. for a project with specific integration or editorial requirements, I’d want to know where the escape hatches are.

what’s the requirement that would make you say “managed SaaS is fine”... or immediately ask for the keys?

I covered the two Sources on my Headless show, but this is the part I’d rather hear from people building and maintaining Drupal sites.

maybe it's just the projects landing on my desk but the last few months have been different.

had two clients come in asking about moving off WordPress. not because anything dramatic happened one had a plugin conflict that took down their checkout for six hours, the other just got tired of updating things every week and something always breaking anyway.

neither of them came in saying "we want Drupal." they came in saying "we're done with this."

the checkout one was a 720 page site. we moved it to Drupal, load time went from just under 6 seconds to under 2. organic traffic was up about 12% in the first quarter after. not sure how much was speed vs the redirect work, probably both honestly.

the other one is still in discovery. some integrations that are going to be annoying regardless of platform.

wondering if this is a wider pattern or just a weird few months on my end. feels like something shifted in how clients think about their CMS but maybe i'm reading too much into it.

Goal is to help keep patches up to date, warn when a patch is not necessary anymore (if it's been included in the newest module release), or if there are conflicts before doing the module update.

This only works on modules published on drupal.org, custom/private modules can't get checked by design, let me know what you think :) full disclosure it's using an API I'm hosting and control, I'm on the leadership team of Drupal, and beside being useful for people, the data will be used to see what people keep applying so we can prioritize some issues over others down the line.

https://tresbien.tech/blog/composer-drupal-patch-check/

https://packagist.org/packages/tresbientech/drupal-patch-check

I had a MCP server doing the same thing couple of weeks ago .The plugin is better and agents pick it up without doing anything special, win-win. Using this over a bare LLM session where you ask "update my site to the latest Drupal version" can cut the time and cost in two when there are many patches to check. Not that I'm a huge fan of these tools but people do use them and the plugin makes it so they have less work to do for a better result.

I'm building a reproducible Drupal CMS 2.1 (Drupal 11) demo/starter/showcase project and I want the whole setup to live in the CLI and in git, no UI clicking. This is my current flow and I'd like to know where it diverges from best practice.

I work as a developer advocate for CKEditor and I need the boilerplate for my showcases/demos/workshops/...

Initial scaffold:

```sh ddev config --project-type=drupal11 --docroot=web ddev start ddev composer create-project drupal/cms # Initial installing of the packages mostly CKEditor pack + premium features, but it does not matter that much ``` 

Day-to-day setup (fresh clone):

This is mostly when I need to have a PR deployment/preview build/feature branch for specific event/or something similar.

I plan to use Render to have the PR-based deployments.

```sh ddev start ddev composer install ddev drush site:install --existing-config -y \ --account-name=admin --account-pass=admin ddev drush php:script scripts/import-demo-content.php ```sh 

Conventions I started with:

• ddev is optional, anything else is fine, I just saw it being used as kinda base
• All config changes go through drush config:export and get committed to config/sync, so site:install --existing-config rebuilds the exact site.
• Repeatable setup steps (text formats, module wiring) live as drush php:script files in scripts/, not as one-off UI actions.
• Demo content ships as a recipe (recipes/<name>/content YAML) and is imported with core's DefaultContent at build time, instead of committing a database dump. (I plan to use sqllite for these demos for simplicity).
• Secrets and endpoints come only from env vars read in settings.php, the file itself is committed.

Where it hurts/"not sure about" parts

1. drush site:install --existing-config crashes in the installer's configure-form step ("Field user_picture is unknown") after config import already succeeded. A fresh bootstrap of the same DB is fine, so it looks like a stale field-map cache inside the installer process. I currently tolerate the exit code and finish the installer work (user 1, site name) via drush. Anyone hit this / know the issue number?
2. drupal/core-recipe-unpack removes recipes from composer.lock after unpacking, so composer install can't restore them and I have to commit the recipes directory. Is committing unpacked recipes the intended workflow?
3. Keeping license keys out of config/sync: I inject all CKEditor Premium Features credentials (license key, and for the self-hosted stack the websocket + API URLs) as runtime $config overrides from env vars in settings.php. Nothing is ever saved through the module's settings form, so config/sync stays secret-free. It works, but the admin form at /admin/config/ckeditor5-premium-features/settings renders completely empty, because Drupal forms only show stored config, not overrides. So the site is fully configured and the form says otherwise. Worse, if someone "helpfully" fills it in, those values get saved to the DB and either shadowed by the overrides or accidentally exported later. Is there an established pattern here: Key module support, a config_exclude approach, or modules showing an "overridden by settings.php" hint on the form? Or is an empty-but-overridden form just the accepted price of env-driven config?

How do you find it? Would you change something? Anything completely wrong?

Hey everybody... Webfllow dropped Source by Webflow yesterday and I wanted everyone's first thoughts on trademark rights, and any other thoughts they might have?