fidzu : cms

Every Drupal or Backdrop site sooner or later needs a safe copy to experiment on - plenty of us still build one by hand and live with the quiet fear that the copy touches production, and plenty more click a dev-environment button inside somebody else's walled garden. On a BOA server the whole workflow is delegated: one Ægir task clones the site from a fresh backup, and the copy arrives with the handbrake pulled - cron off, HTTPS off, files in its own store - then dev-prefixed names mark the copies as dev sites with their own larger limits, a dev alias flips PHP errors and caching into dev mode on that hostname alone, allow-lists and HTTP auth lock the copy down, extra clones Migrate onto updated codebases for staging, and a rename promotes the winner when it earns the crown - while to the rest of the stack the sandbox is a site like any other, nightly backups and edge protections included. Capabilities, not an enforced workflow - the safe route is the easy one, never the only one.

12 Aug 2026 7:20pm GMT

JSON:API on its own gets you decoupled entities: fetch a node, fetch a set of IDs, done. It doesn't get you the filtering, sorting and pagination that most real content listings actually need - a list of articles by tag, a paginated product catalogue, an events calendar with a date filter. You either reimplement that logic on the frontend, or Drupal ships a hand-written custom resource for every list on the site. That gap is the same regardless of what's rendering on the other end, React and Next.js, Vue and Nuxt, or anything else that can call an API.

JSON:API Views closes it: whatever a View can already do, a decoupled frontend can ask for over JSON:API, using the access checks and query logic the view already has, no separate endpoint to write or maintain. It's also, not coincidentally, why I still maintain the module at all: it's the backend half of DruxtViews, the piece that makes Views work in Druxt, my own Nuxt-based decoupled Drupal framework.

Continue reading →

12 Aug 2026 6:50am GMT

When you hire a Drupal developer or change maintenance partner, do not ask only for a portfolio. Ask how they keep the system upgradable, testable and understandable for the next developer. In 2026, it is no longer enough to evaluate a Drupal developer simply by knowing that they have "worked with Drupal". Drupal is a broad enough platform that the same job title can cover very different types of work: configuring content types and Views; developing custom modules; migrations; performance optimisation; security updates; accessibility; integrations with external systems. A good developer does not need to be equally strong in every area. They should, however, be able to assess realistically where their strengths lie, where they need support, and how to keep risks under control throughout…

12 Aug 2026 6:00am GMT