Takeover, maintenance and new features for an institutional Drupal website built on the DSFR

Taking over code you did not write, without breaking everything

An agency rarely needs its website rewritten: it needs back-up able to take over what exists and keep it running. That is the starting point of this project — an institutional Drupal website already live, rich, with its own habits and its own debt. Before any change, we audit: the actual version of Drupal and its dependencies, the patches in place and how traceable they are, the state of the configuration (can it be deployed without surprises?), accessibility debt, and the presence — or absence — of a quality chain. The first deliverable is not code, it is a prioritised diagnosis: what is risky, what is urgent, what can wait.

The foundation: a Drupal 9 DSFR website, brought back up to standard

The website runs on an industrialised Drupal 9 foundation and a custom theme compliant with the DSFR. The front end is not a theme pasted on top: it is a set of Twig components and SCSS styles compiled by a tooling chain, backed by a styleguide that documents the components. Taking over properly means first understanding this model: where the components live, how they map onto Drupal fields, how the DSFR is versioned. Once this map is drawn, developing a page or creating a new one becomes safe and quick — not a gamble.

Quality, tooled on every commit

On a project taken over by several pairs of hands, quality cannot rely on individual discipline: it has to be automatic. Every commit triggers a set of checks orchestrated by GrumPHP: PHPCS to Drupal standards (Coder), PHPMD (complexity, dead code), copy-paste detection (PHPCPD), PHP / YAML / JSON linting, composer.json normalisation, and even hygiene rules — forgotten var_dump, dd() or console.log calls are blocked, branch names must follow a convention, and commit messages must reference a ticket. The threshold is clear: zero style errors tolerated. The result: consistent code whoever wrote it, and reviews that discuss the business logic rather than semicolons.

Tests and continuous integration

Taking over a website without a safety net means deploying blind. We rely on automated tests — PHPUnit for logic, Behat for functional journeys — run in continuous integration (GitLab CI) with coverage tracking. Every branch goes through the pipeline before merging: CI is the safeguard that turns “it works on my machine” into “it has been checked”. It is also what makes ongoing maintenance sustainable over time: you can fix and develop without fearing you will break an existing journey at the other end of the website.

Deploying without surprises: configuration per environment

A public website lives on several environments — development, acceptance, production — and is managed by several people. The configuration is versioned and driven per environment (config_split / config_ignore): what must differ between acceptance and production is cleanly isolated, and the rest is deployed reproducibly. The local environment is containerised (Docker) and tooled with automated tasks (Phing) — database import, file synchronisation, reset — so that a new developer is up and running in minutes, not days. Deployment stops being a tense moment.

Maintaining dependencies: version upgrades and tracked patches

The heart of ongoing maintenance is keeping the foundation up to date — for security as much as for longevity. Dependencies are managed with Composer, and when a community module has a defect, we never edit its code “in place”: we apply a tracked patch (composer-patches), documented and replayed on every installation. This is what distinguishes a maintainable website from a black box: a version upgrade does not make the fixes disappear, and any developer can understand why a given patch is there. Useful fixes are, where possible, contributed back upstream to the community.

DSFR accessibility, GDPR and observability

Three non-negotiable requirements on a public website, held by the foundation rather than patched in at the end. Accessibility (RGAA): the markup comes from standardised DSFR components documented in the styleguide, so accessibility is produced at the source. GDPR: consent management (banner and preferences), a password policy, anti-spam protection for forms, and controlled email sending (disabled outside production so a real user is never emailed by mistake). Observability: production errors are reported continuously to Sentry and logged, so they are seen and fixed before users are affected.

Search and editorial content

A rich institutional website must remain easy to navigate. Search relies on Search API and facets to filter large volumes of content, with a dedicated results page. On the editorial side, content is built from reusable components (Paragraphs), configurable entity lists and a controlled display — the editorial team assembles its pages from approved blocks, without asking for development work for every campaign. Technical SEO (metadata, clean URLs, redirects, sitemap) is built into the foundation, not added afterwards.

Taking over or developing your Drupal DSFR website

This is the question that interests an agency: can you hand over an existing Drupal DSFR website and see it looked after properly? Yes — because the takeover is tooled. We audit the actual version, the patches, the configuration and the accessibility debt; we deliver a prioritised plan; then we take charge of maintenance and new features, under your brand. The website remains easy to take over after us: consistent code, versioned configuration, tests, CI, tracked dependencies. It is exactly what an agency delegating ongoing maintenance is looking for.

Frequently asked questions

In short: taking over an existing Drupal DSFR website is not about “tinkering” with a site delivered by others. It is engineering: audit, tooled quality, tests, controlled configuration and tracked dependencies. Done properly, the website stays secure, up to date and — above all — easy to take over.