Development site

A development site is a private copy of a Drupal site where developers build and try changes before anything reaches visitors. It can run on a developer's own computer. Code, settings and configuration change here first, then move to a staging site and the live site.

How it works in Drupal 11

Drupal.org names DDEV as the recommended local development tool for Drupal. It adds that other Docker-based tools support Drupal too. Whatever the tool, the copy needs its own database and its own settings file.

Core ships a starting point for those settings. Copy sites/example.settings.local.php to sites/default/settings.local.php and uncomment the include block at the bottom of settings.php. The example file then:

• loads sites/development.services.yml, which adds cacheability debug headers and a null cache backend;
• sets the error level to verbose and turns off CSS and JavaScript aggregation;
• lets you switch off the render cache, page cache and dynamic page cache by uncommenting lines;
• turns on rebuild_access and skips file permission hardening.

The comment in default.settings.php lists the same kind of use for secondary installations: disabling caching and compression, and rerouting outgoing email.

Moving work between sites

Configuration is the set of settings, such as content types, fields and views, as opposed to the content of the site. The Drush workflow on Drupal.org exports it to the sync directory on development with drush config:export, copies the directory to the live site, and runs drush config:import there. Core refuses an import whose system.site UUID differs from the target, so both sites must carry the same UUID.

To bring live data down, drush sql:sync copies a database from a source site to a target site. drush sql:sanitize then removes or obfuscates user data: it replaces email addresses with a test pattern and randomizes passwords by default. Core's example file also shows $settings['config_exclude_modules'], which keeps development modules such as Devel out of the exported configuration.

Example

A developer sets up the site in DDEV from a copy of the live database, runs drush sql:sanitize, builds a new landing page type, and runs drush config:export. The changed YAML files go into Git with composer.lock. The team tests the same commit on staging before it ships.

Common mistakes

• Keeping caches off for the whole project. The example file itself advises testing with the render cache, page cache and dynamic page cache enabled, to confirm that cacheability metadata is correct.
• Working on real customer data. A raw live database carries real email addresses. Sanitize it, and reroute outgoing email in the local settings.

For marketing and content teams

A development site is not for editing real content: what you type there does not reach the live site, because only configuration is exported. Use it to review a new template or form with a developer, then enter the real text on the live site once the change is released.

Sources

• Drupal.org: Local server setup
• Drupal core 11.4.10: example.settings.local.php
• Drupal core 11.4.10: default.settings.php
• Drupal core 11.4.10: SystemConfigSubscriber
• Drupal core 11.4.10: install.core.inc, site UUID on install from existing configuration
• Drupal.org: Configuration management
• Drupal.org: Workflow using Drush
• Drush sql:sync command
• Drush sql:sanitize command