Drush Documentation

The following patterns are deprecated and should be replaced with modern approaches:

• drush.services.yml: Drush 11 and prior used service files for dependency injection. This is deprecated in Drush 12+ in favor of Autowiring.
• CustomEventAwareInterface: Commands should now fire their own events instead of implementing this interface.
• StdinAwareInterface: To read from stdin, use the approach implemented in ConfigSetCommand to allow for better testability.

Global generators are those that do not ship inside a Drupal module. To use a global generator, your class must follow these PSR4 requirements:

1. Namespace: The class namespace must be Drush\Generators relative to your library's base namespace. For example, if your library's PSR4 mapping is My\Custom\Library\ => src, your generator class must be My\Custom\Library\Drush\Generators.
2. File Location: The file must be located in the Drush/Generators directory within your source folder (e.g., src/Drush/Generators).
3. Naming Convention: The filename must follow the pattern [Name]Generator.php (e.g., FooGenerator.php).

"autoload": {
  "psr-4": {
    "My\\Custom\\Library\\": "src"
  }
}

Drush searches for drush.yml files in a specific order of precedence. When multiple files are found, they are merged. To see all discovered configuration files, run drush status --fields=drush-conf.

Discovery Order:

1. Drupal site folder (e.g. sites/{example.com}/drush.yml).
2. sites/all/drush, WEBROOT/drush, or PROJECTROOT/drush.
3. Any location specified via the --config option.
4. User's .drush folder (e.g. ~/.drush/drush.yml).
5. System-wide configuration folder (e.g. /etc/drush/drush.yml or C:\ProgramData\Drush\drush.yml).

Before running the cron command, you should verify the site's maintenance status. If a site is in maintenance mode, cron will not run and the command will return a failure. It is not safe to run cron while the site is in maintenance.

You can check the status using the maint:status command.

For simple value changes that vary by environment (e.g., changing the site name on a local development server), use Drupal's configuration override system instead of modifying configuration files. This is done by setting variables in the site's settings.php file.

When to use overrides:

• Use overrides for environment-specific values like site names, API keys, or connection settings.
• Limitation: Overrides do not work for certain structural changes, such as enabling or disabling modules.

When to use Drush config commands:

• Use config:export, config:pull, or config:import for structural changes or when you need the changes to be permanent in the configuration files.

$config['system.site']['name'] = 'Local Install of Awesome Widgets, Inc.';

If multiple environments share identical configurations except for their names, you can use a wildcard alias *. Use the ${env-name} variable to inject the environment name into values like host, root, or uri.

Warning: Wildcards will match any name provided, even typos. It is recommended to use an alias alter hook to validate environment names.

# File: remote-example.site.yml
'*':
  host: ${env-name}.server.domain.com
  user: www-admin
  root: /path/to/${env-name}
  uri: http://${env-name}.remote-example.com