fidzu : Drupal

A DAM decision changes more than where images are stored. Drupal teams also have to decide which system owns metadata, approvals, transformations, rights, and the published asset lifecycle.

24 Aug 2026 4:33pm GMT

24 Aug 2026 2:30pm GMT

Imagen

Imagen

Carlos

Ospina

·

Technical Account Manager / Drupal Advisor

24 Aug 2026 2:02pm GMT

24 Aug 2026 9:50am GMT

The latest three projects have limited reported use, but the pattern extends beyond their reach. For affected site teams, the recurring security response is to uninstall the project rather than install an update.

24 Aug 2026 7:30am GMT

This week's release of Drupal AI Context Beta 4 added taxonomy-based context selection, priority controls, workflow states, and token-budget visibility. Kristen Pol, primary maintainer of Context Control Center, said the project is moving towards its first release candidate, while Drupal.org release notes list 70 credited issues in the beta. The additions put more structure around deciding what information reaches an AI agent before it acts.

The release arrived as Drupal founder Dries Buytaert was asking a broader question about what happens when AI makes code cheaper to produce. In a 17 August 2026 blog post, Dries argued that as application functionality becomes easier to recreate, commercial value may shift towards dependable operation: deployment, security, scaling, monitoring, and reliable service over time. His argument is about software economics rather than AI context, but it points to the same larger change: implementation is no longer the only scarce input.

The DropTimes' 18 August interview with Kristen showed where that shift meets Drupal AI. Context Control Center can use moderation, revisions, permissions, scheduling, and scopes to govern the knowledge supplied to a model, but those controls cannot guarantee how the model will respond. Requirements that cannot tolerate probabilistic behaviour still need deterministic rules, validation, access controls, or human approval.

A similar distinction appeared in open-source development. Symfony founder Fabien Potencier began an issue-first contribution experiment for Symfony Language Tools on 19 August 2026. The experiment applies only to that repository. When coding agents can handle more of the implementation, the context supplied by the person reporting an issue - including the application setup, configuration, failure conditions, and intended behaviour - becomes a larger part of the contribution.

The same pressure appears after generation. Content Sync's Drupal governance argument is that faster content creation does not remove decisions about ownership, approvals, local adaptation, and which version remains authoritative. AI can reduce drafting time while leaving organisations with more material to review, maintain, and govern.

These developments put the difficult work somewhere other than generation alone. Faster implementation does not define the problem, determine which knowledge is authoritative, establish the constraints, review the result, or make the finished system dependable. Code may become easier to produce without making context, validation, operations, or human judgement easier to replace.

At The DropTimes' August Open Town Hall on 19 August 2026, the editorial team described a similar shift in its AI coverage: looking more closely at agent context, permitted actions, validation, and human review, alongside a broader effort to distinguish what sources claim from what available evidence establishes.

Follow The DropTimes on LinkedIn, X, Bluesky, and Facebook, or join #thedroptimes on Drupal Slack.

This issue of Editor's Pick was written and curated by Allen Jason.

24 Aug 2026 5:15am GMT

DDEV's generic project type will run anything that brings its own web server, and people already use it for Node and other stacks. Umbraco is a less-travelled case: .NET, Kestrel, and SQL Server. I wanted to know how much of the DDEV experience still holds up there. Clone a repository, run one command, have a working site and database a few minutes later.

Most of it holds up. The result is umbraco-clean-ddev, which runs Umbraco on .NET 10 with SQL Server and Adminer, and gets a new developer going with a single ddev start. What took the time was a handful of places where DDEV expected something I had not worked out yet.

What I wanted out of it

I wanted four things out of this, and nothing more ambitious than that.

1. One command for someone joining the project
2. Nothing installed on my own machine: no SQL Server, no .NET SDK, none of the project's other dependencies.
3. Projects that stay out of each other's way.
4. A way to take a backup from Umbraco Cloud and debug against it locally.

DDEV already does all of this elsewhere. The Umbraco Cloud backup turned out to be the least transferable: ddev import-db and ddev export-db work on the database container DDEV manages, and this project omits that container entirely. Anything equivalent I would have to write myself.

Keeping the dependencies off my machine also makes the project easier to hand to someone who has never worked with .NET. The SDK and SQL Server both live in containers, so trying Umbraco does not start with installing either of them locally. Clone the repository, run one command, and the CMS is there to look at.

The parts that needed working out

The generic project type

DDEV's generic type doesn't start nginx or PHP-FPM, which is what you want when the application brings its own web server:

# .ddev/config.yaml
name: umbraco-clean
type: generic
docroot: ""
webserver_type: generic
omit_containers: [db]
disable_settings_management: true

omit_containers: [db] drops DDEV's MariaDB, since SQL Server runs as a separate service and MariaDB would only sit there idling.

A generic web server type also emits no default router configuration, so without one, every request 404s. web_extra_exposed_ports supplies it:

# .ddev/config.yaml
web_extra_exposed_ports:
  - name: umbraco
    container_port: 80
    http_port: 80
    https_port: 443

Those two port numbers being equal matters. DDEV builds the Traefik backend URL from http_port rather than container_port, so an otherwise reasonable pairing of container_port: 8080 with http_port: 80 sends traffic to port 80 in the container and returns a 502. I lost a while to that one before reading the router configuration it generates.

The .NET SDK is not in the web image

DDEV's web image has no .NET SDK, so .ddev/web-build/Dockerfile.dotnet adds one. The important thing about that file is what it does not contain:

# .ddev/web-build/Dockerfile.dotnet
RUN curl -fsSL https://packages.microsoft.com/config/debian/13/packages-microsoft-prod.deb -o /tmp/pmp.deb \
    && dpkg -i /tmp/pmp.deb \
    && rm /tmp/pmp.deb \
    && apt-get update \
    && ACCEPT_EULA=Y apt-get install -y dotnet-sdk-10.0 mssql-tools18 \
    && rm -rf /var/lib/apt/lists/*

RUN dotnet tool install --tool-path /usr/local/share/dotnet-tools microsoft.sqlpackage

ENV PATH="$PATH:/usr/local/share/dotnet-tools:/opt/mssql-tools18/bin"

There is no FROM line. DDEV prepends its own, and adding one starts a fresh stage that throws away the user setup, supervisord, healthcheck and tooling that make the container a DDEV container. You would have to rebuild all of that yourself, which I do not recommend as a way to spend an evening.

Debian trixie ships no .NET packages, so the SDK comes from Microsoft's feed, registered by installing packages-microsoft-prod.deb. Only .NET 10 publishes an ARM64 build there, so anyone on Apple Silicon has a floor of 10.0.

I also left webimage_extra_packages out of config.yaml on purpose. DDEV injects it ahead of the web-build Dockerfile, so any package listed there is looked up before the Microsoft feed exists.

SQL Server on Apple Silicon

Full SQL Server publishes no ARM64 image, so the database service is Azure SQL Edge. It speaks the same TDS protocol and Umbraco cannot tell the difference.

DDEV does have an add-on for SQL Server, ddev-sqlsrv, which runs full SQL Server and works on Apple Silicon through Rosetta 2 emulation. Apple has announced Rosetta is going away, and I wanted to see what was possible without installing it.

This is the choice I would most like to revisit. If Microsoft ever publishes an ARM64 image, I would rather be running full SQL Server than Azure SQL Edge.

# .ddev/docker-compose.umbraco.yaml
services:
  sqlserver:
    container_name: ddev-${DDEV_SITENAME}-sqlserver
    image: mcr.microsoft.com/azure-sql-edge:latest
    environment:
      - ACCEPT_EULA=Y
      - MSSQL_SA_PASSWORD=${MSSQL_SA_PASSWORD}
    volumes:
      - sqlserver-data:/var/opt/mssql
    healthcheck:
      test:
        - CMD-SHELL
        - python3 -c "import socket; s=socket.create_connection(('localhost',1433),2); s.close()"
      start_period: 30s

The healthcheck is a raw socket connection because Azure SQL Edge ships no sqlcmd to query with. It only proves the port is open, and the server accepts logins a moment after that, so the check is weaker than I would like. The 30 second grace period covers the initialisation of the system databases on a first run, which takes about 20 seconds and would otherwise exhaust the retries.

The named volume is why the database survives a ddev restart: without it every restart would hand Umbraco an empty server and trigger the unattended install again.

Alongside sqlserver and adminer, the compose file carries a short web block, the one place this project reaches into the container DDEV owns:

# .ddev/docker-compose.umbraco.yaml
services:
  web:
    depends_on:
      sqlserver:
        condition: service_healthy
    environment:
      - Umbraco__CMS__WebRouting__UmbracoApplicationUrl=${DDEV_PRIMARY_URL}

condition: service_healthy is what the healthcheck above exists for. It holds the web container until SQL Server answers, so dotnet watch is not racing a database that has not finished booting. UmbracoApplicationUrl hands Umbraco the site's real external address rather than letting it infer one from a request that arrived over plain HTTP from the router. Everything else about the web container is configured through config.yaml, so DDEV keeps ownership of its lifecycle.

Keeping Kestrel alive

The application runs as an extra daemon rather than as a container command:

# .ddev/config.yaml
web_extra_daemons:
  - name: umbraco
    command: "dotnet watch run --non-interactive --no-launch-profile"
    directory: /var/www/html/MyProject

That puts dotnet watch under the web container's supervisord, so supervisord restarts it on failure. Overriding the compose command instead would displace DDEV's own entrypoint, and a build error would leave you with a container that is up but serving nothing.

TLS is terminated on the router

Five environment variables, two of them there because the router sits in front of Kestrel:

# .ddev/config.yaml
web_environment:
  - ASPNETCORE_ENVIRONMENT=Development
  - ASPNETCORE_URLS=http://0.0.0.0:80
  - ASPNETCORE_FORWARDEDHEADERS_ENABLED=true
  - DOTNET_CLI_TELEMETRY_OPTOUT=1
  - NUGET_PACKAGES=/mnt/ddev-global-cache/nuget

Kestrel has to bind 0.0.0.0 because the router reaches it across the Docker network rather than over loopback. The forwarded headers setting is easy to miss and confusing when it's absent: the router terminates TLS and forwards plain HTTP, so without it Kestrel decides the request was insecure and generates http:// links on an https:// site.

The NuGet line has nothing to do with the router. It moves the package cache onto a DDEV volume, so a rebuilt container no longer re-downloads every package. The remaining two are ordinary .NET settings that happen to belong here rather than in a launch profile.

Getting it running

ddev start

A pre-start hook copies appsettings.Local.json.example into place when it is missing:

# .ddev/config.yaml
hooks:
  pre-start:
    - exec-host: "bash -c '[ -f MyProject/appsettings.Local.json ] || cp MyProject/appsettings.Local.json.example MyProject/appsettings.Local.json'"

pre-start rather than post-start, because Kestrel comes up with the container: a post-start hook would write the file after the application had already read its configuration. That phase also forces exec-host, since there is no container yet to run the command inside.

On first boot Umbraco runs its unattended install, creating the schema and the default admin user, admin@example.com with password 1234567890.

:::warning[Error 4060 on first boot] The first boot logs Cannot open database "UmbracoDb" with error number 4060. The database does not exist until the unattended install creates it, so Umbraco logs the error a couple of times during startup until it can connect and action the unattended install. :::

After that, ddev dotnet is a passthrough that runs the CLI in the project directory, so nobody needs the SDK on their host to run ddev dotnet build.

Moving the database around

This is the one I care most about: pulling a backup down from Umbraco Cloud and running it locally to test or debug against real content. A local environment that cannot take a copy of the site's actual database will not reproduce the bug you are chasing. DDEV's own import-db and export-db talk to the container this project does not have, and Umbraco Cloud backups come as .bacpac files, so I wrote two commands to handle them:

ddev bacpac-export              # writes UmbracoDb.bacpac to the project root
ddev bacpac-import UmbracoDb.bacpac

Both wrap sqlpackage, which has no apt package and so gets installed via dotnet tool install in the web image build. Import is the harder of the two: sqlpackage requires an empty or nonexistent target, and Kestrel holds an open connection to the database being dropped:

# .ddev/commands/web/bacpac-import
sqlcmd -S sqlserver -U sa -P "${MSSQL_SA_PASSWORD}" -C -Q "
IF DB_ID('UmbracoDb') IS NOT NULL
BEGIN
    ALTER DATABASE UmbracoDb SET SINGLE_USER WITH ROLLBACK IMMEDIATE;
    DROP DATABASE UmbracoDb;
END"

SINGLE_USER WITH ROLLBACK IMMEDIATE forces that connection closed so the drop can proceed. Both commands read and write /var/www/html, which is the host-mounted project root, so a .bacpac downloaded from Cloud goes next to the solution file and imports from there.

Things that look wrong and are deliberate

.ddev/.env holds the SA password, the Umbraco connection string and the SMTP configuration for mailpit, and it is committed. That is a fixed local development credential in the same spirit as DDEV's own db/db/db, and committing it is what makes a fresh clone work with no manual step. On a project with real secrets I would not do this: the file would move somewhere untracked, and a setup step would have to prompt for the values.

appsettings.Local.json is git-ignored and exists for per-developer overrides such as logging levels. Program.cs registers it after CreateBuilder has already added the environment variable provider, so that file wins over .ddev/.env. A ConnectionStrings block there will override the environment, and someone who then edits the password in .ddev/.env will find it has no effect.

Both files the Adminer add-on provides are committed here, the compose file and the ddev adminer launcher, so ddev add-on get never has to run and a clone starts with Adminer already working. docker-compose.adminer.yaml carries one edit: its default depends_on: [db] is gone, because this project has no db container. Adminer's connection defaults are set in docker-compose.umbraco.yaml instead, pointing it at the sqlserver service. Neither committed copy carries a #ddev-generated marker, so DDEV treats them as mine and leaves them alone. The cost is that they no longer update with the add-on.

Try it

The repository is at millnut/umbraco-clean-ddev, built on Paul Seal's Clean starter kit. Clone it, run ddev start, and you should have Umbraco and SQL Server running without either of them touching your machine directly.

It is still a bespoke setup rather than something reusable. The .NET SDK install, the SQL Server service and the bacpac commands are all things I now maintain by hand, and an add-on would be a better home for most of them. If you work with Umbraco or .NET and want to try it, I would be glad to hear what breaks: I have only run this on my own machine, against one project.

24 Aug 2026 12:00am GMT

Nineteen months after Drupal 7's final end of life, 29.7% of all Drupal websites still run it - and half the Drupal web runs a version with no security support. The numbers, the methodology, and the four ways out. Updated quarterly.

23 Aug 2026 12:55am GMT

The definitive configuration guide to Drupal's SEO module stack: Pathauto, Redirect, Metatag, Simple XML Sitemap vs XML Sitemap, Schema.org Metatag, and five more - with the exact settings I use on every build and the mistakes I keep finding in audits.

21 Aug 2026 11:07pm GMT

When you move a Drupal site to a headless CMS, the thing most likely to break silently is not your content. It is the invisible wiring between pieces of it. Drupal stores relationships as numeric IDs (node 4127, term 88, media 903), and almost every headless platform mints brand-new IDs the moment you import. So every taxonomy tag, every embedded image, every "related articles" block that pointed at an old number now points at nothing, or worse, at whatever content happened to inherit that number. The pages still render. The links inside them just quietly go nowhere. Here is the scene that keeps happening. The migration "succeeds." Every article is present, the word counts match, everyone high-fives. Then two weeks later someone notices the related-content sidebar is empty on 8,000 pages, half the article hero images resolve to a 404, and the tag pages that used to rank now list either…

Read the rest at Replatform Radar

21 Aug 2026 2:00pm GMT

Drupal turns decoupled architecture into a governed AI harness, combining live visual editing with agent-ready content schemas.

21 Aug 2026 5:17am GMT

Today we are talking about Drupal, AI, and learning to use it responsibly with guest Mike Anello. We'll also cover Entity Mesh as our module of the week.

For show notes visit: https://www.talkingDrupal.com/566

Topics

• Course overview
• Fast moving modules
• Inside vs outside AI
• No code approach
• Keeping curriculum current
• Essentials vs add ons
• Chat Claude Code setup
• Inside vs Outside AI
• Rules and Provider Calls
• Guardrails in Drupal UI
• Model QA and Testing
• Local Models and Costs
• Token Budgets and Logging
• Course Use Cases Overview
• RAG and Vector Basics
• Class Schedule and Pricing
• AI Predictions and Wrap

Resources

• New DrupalEasy class: Responsible Drupal AI Basics
• Training at orlando
• amazee ai
• Jrockowitz losing my skill
• AI module ecosystem
• AI browser provider (LLM in Google Chrome)
• amazee.ai Private AI Provider
• Derecho

Guests

Mike Anello - drupaleasy.com ultimike

Hosts

Nic Laflin - nLighteneddevelopment.com nicxvan John Picozzi - epam.com johnpicozzi JD Flynn - dorficus

MOTW Correspondent

Martin Anderson-Clutz - mandclu.com mandclu

• Brief description:
  • Have you ever wanted a way to analyze and visualize the ways in which the content on your Drupal site is interlinked? There's a module for that.
• Module name/project name:
  • Entity Mesh
• Brief history
  • How old: created in Jan 2025 by Jorge Tutor (gedur) of Metadrop
  • Versions available: 2.1.0 and 2.0.3, both of which work with Drupal 11
• Maintainership
  • Actively maintained, latest release last month, and a commit just yesterday
  • Security coverage
  • Test coverage
  • Documentation? Project page is pretty descriptive
  • Number of open issues: 13 open issues, 4 of which are bugs, but 2 of those were marked fixed in the past week
• Usage stats:
  • 437 sites
• Module features and usage
  • With Entity Mesh installed, the module will analyze the rendered output of your nodes using a chosen account, looking for links to other content
  • That means it will find not just links in entity relationship fields, but also links within formatted text, menus, and more
  • The results can be visualized in a D3.js 3D visualization, displayed as a table, or exported as a CSV
  • The report also exposes a set of Views-style filters, to help you narrow down to the specific set of information you want to understand
  • Entity Mesh analyzes the DOM of your rendered nodes, looking for links, iframes, and images. Internal paths are further analyzed and categorized, for example based on whether the specified path redirects, is broken, points to something that is access-denied, and so on
  • From a marketing perspective, that allows you to understand the paths available to navigate from a source page to a target page, the content linked to or from a specific page, and will also augment the content deletion confirmation form to advise the user of any existing links to the content being deleted
  • There are obvious SEO advantages to being able to find redirect chain, broken or access denied links, and there are GDPR compliance implications for being able to identify iframes that might load third-party cookies
  • The project page also mentions that this module could be very useful to run after a content migration, for QA
  • The actual analysis of your site content be triggered by drush, an admin form, or by cron, and you can set limits on the size of the batch to run, because of the weight it puts on your site by rendering every node it analyzes
  • The current versions Entity Mesh also depend on the Entity Registry and Entity Render Context modules, that have essentially the same maintainers, so if there's only part of Entity Mesh that you really need, you could also give those a look
  • Back in episode #321 we covered Entity Usage, and there are some definite similarities, but also some differences. While they both provide reporting on content relationships, Entity Usage does so by examining structured field values at save time. So, the information gathered is different, and collects data that can be displayed in views or custom code.

20 Aug 2026 6:00pm GMT

I'm Joining Acquia! mherchel Thu, 08/20/2026 - 11:10

20 Aug 2026 3:10pm GMT

Imagen

Imagen

Carlos

Ospina

·

Technical Account Manager / Drupal Advisor

20 Aug 2026 2:59pm GMT

Running on DotNetNuke (DNN)? We highly recommend a CMS migration to the latest release of Drupal. It is packed with all the features you have been wishing for! Learn why you should make that move and how you can do it.

20 Aug 2026 9:31am GMT

The International Splash Awards 2026 have reached a new milestone, with 40% more submissions compared to last year.

Image

A huge thank you to everyone who submitted a project and helped make this year's edition even bigger.

The jury is now reviewing the submissions, with nominations set to be announced in early September.

We look forward to celebrating the projects and teams behind them during DrupalCon Rotterdam 2026.

Stay tuned. The nominations are coming soon.

20 Aug 2026 9:30am GMT