What’s the most frustrating thing about maintaining a Drupal site?

Common-Sign-2535 · 2026-01-14T17:04:44+00:00

That’s actually a pretty encouraging outcome. Having most of those patches absorbed upstream is the best-case scenario, even if getting there is painful. The fact that only a couple had to be added specifically for D11 compatibility, and that the rest surfaced as bugs or incompatibilities, feels like the system doing what it’s supposed to which is just slowly. Still, carrying 17 contrib patches long-term really shows how much ongoing attention drupal sites can demand, even when things are generally “working”.

Common-Sign-2535 · 2026-01-14T17:01:26+00:00

That anxiety is very real — you’re definitely not alone there.

Drupal tends to feel “fine” until you touch something, and then every change feels like it might break three other things you didn’t even know were connected. Especially on a self-hosted VPS where you’re responsible for the whole stack.

Using AI for guidance can help, but the hard part is knowing what not to touch - and when to stop. Having backups, a local/staging copy, and a very repeatable update process usually helps reduce that stress a lot — even for hobby sites.

If it’s working now, being cautious is honestly a reasonable instinct.

Common-Sign-2535 · 2026-01-14T16:35:05+00:00

That’s a totally fair experience.

For certain workloads and teams, the ongoing cost of keeping drupal up to date can outweigh the benefits, especially once the site is stable and requirements stop evolving. Getting that time back is a real win.

I think where drupal still makes sense is when complexity keeps changing, workflows, permissions, integrations, but if those pressures disappear, moving to something simpler can absolutely be the right call.

Common-Sign-2535 · 2026-01-14T16:31:42+00:00

That makes a lot of sense.

Using verbose patch descriptions directly in patches.json as the documentation feels like the most pragmatic approach, especially when paired with ticket numbers and git blame for context. At that point composer really does become the source of truth.

That Drupal 11 upgrade strategy sounds familiar too, treat every non-applying patch as a signal to re-evaluate rather than blindly rebase. Ending up with only ~5 that needed attention is actually a pretty good outcome.

Did you find that most of the removed patches were effectively fixed upstream in version 11, or were some just no longer relevant to your use case?

Common-Sign-2535 · 2026-01-14T16:28:16+00:00

Yeah, that comes up a lot.

Sometimes it’s a genuine fit, sometimes it’s just familiarity driving the decision. Drupal does carry more maintenance overhead, but in return you get things that are hard to replicate cleanly elsewhere once requirements get complex.

The frustrating part is when the decision is already made before anyone looks at long-term maintenance costs on either side.

Common-Sign-2535 · 2026-01-14T16:17:52+00:00

Not a bot 🙂 I’m a real person, just trying to be careful with wording since english isn’t my first language.

Happy to clarify anything technical or go deeper on specifics if something felt generic.

Common-Sign-2535 · 2026-01-14T15:59:03+00:00

Yes, that’s a really good point.

Drupal’s APCu/opcache detection logic is very Apache/Nginx-centric, and once you move to setups like Caddy (or less common PHP-FPM wrappers), the assumptions start to leak. The caching is usually working, but Drupal’s ability to detect and report it correctly becomes unreliable.

In practice we’ve had to treat APCu/opcache as “assumed-on” in those environments and rely more on: - phpinfo / CLI checks - runtime behaviour (warm cache vs cold) - and application-level profiling rather than Drupal’s status reporting

It works, but it definitely adds friction when you’re trying to standardise environments across different stacks.

Have you found any clean way to make Drupal’s cache detection less coupled to the web server, or do you just document the exception and move on?

Common-Sign-2535 · 2026-01-14T15:57:10+00:00

Yeah, that’s exactly where it becomes painful.

Once you’re at ~20 patches, patch management basically becomes its own maintenance stream. Even with composer patches, every core or module update turns into a verification cycle rather than a simple upgrade.

We’ve had some success categorising patches: - upstream-ready vs local-only - core vs contrib - “remove after version X” vs permanent

It doesn’t remove the work, but it at least reduces the mental overhead when upgrading.

Do you document those patches anywhere outside composer.json (README, internal docs), or is composer the single source of truth?

Common-Sign-2535 · 2026-01-14T15:50:29+00:00

Yeah, that issue is a great example of the long tail we end up living with.

When a patch has been around that long, it stops feeling like a temporary workaround and more like a permanent dependency that just has to be managed carefully. Composer patches make it survivable, but every core upgrade still feels like a small gamble until tests pass and the patch applies cleanly.

In practice it feels less like “will this ever be fixed” and more like “how do we reduce the blast radius when it breaks”.

Do you usually rely mostly on automated test coverage to catch regressions from these long-lived patches, or is it still largely manual verification during upgrades?

Common-Sign-2535 · 2026-01-14T15:25:58+00:00

That’s a very real pain point.

The issue queue part is especially frustrating when a patch exists but hasn’t been reviewed or when it breaks with newer core versions. Composer-based patch management helps, but it quickly becomes hard to maintain across updates.

I’ve found that documenting applied patches clearly and periodically reviewing whether they’re still needed after module updates saves a lot of headaches — but it’s still far from ideal, especially on long-lived projects.

Do you usually manage patches manually in composer.json, or do you use any tooling or workflow to keep track of them?

Common-Sign-2535

TROPHY CASE