Drupal Site Audit 1.0.11 Adds Drupal 12 Readiness and Drush Updates

Version 1.0.11 of the Drupal Site Audit contributed module adds Drupal 12 compatibility, security hardening, expanded Drush command options, and broader code-quality coverage. Drupal.org lists the release as created on 2 July 2026 at 15:54 UTC. The release works with Drupal 10.2, Drupal 11, and Drupal 12.

The release focuses on security hardening, Drupal 12 readiness, a broader Drush command surface, and code quality and test coverage work in preparation for Drupal.org security advisory coverage. The project page still states that the module is not covered by Drupal’s security advisory policy and should be used at the user’s own risk.

The Drush changes centre on audit:run, which now accepts multiple analyzer IDs or the keyword all. The release notes say the command can produce a combined JSON report with totals and per-analyzer results. A new --fail-on=error|warning|any|never option allows the command to return a non-zero exit status when findings reach a configured threshold, supporting continuous integration checks and automated review workflows.

The release also adds result filters named check and file, with findings tagged by their check key. The Views audit now excludes disabled views by default through an “Exclude disabled views” setting. The Twig audit no longer flags debug functions written inside Twig comments or docblocks as false positives.

Security-related changes include removing the |raw filter from module Twig templates, filtering module-generated HTML through Xss::filterAdmin(), and adding a CSRF token requirement to the route that runs all analyzers. The release notes also say unknown analyzer IDs now return a proper 404, and JSON output uses JSON_INVALID_UTF8_SUBSTITUTE to prevent invalid UTF-8 from corrupting command-line output. Multi-analyzer runs are described as resilient to individual analyzer failures.

For Drupal 12 readiness, all 27 info.yml files now declare ^10.2 || ^11 || ^12 as the core version requirement. The release notes say Project Update Bot findings were addressed and PHPStan with deprecation rules reports zero deprecated core API usages. Continuous integration now tests against Drupal 10, Drupal 11, the next minor release, and 12-dev.

Code-quality work is also broader than the earlier 1.0.10 bug-fix framing. The release notes state that the module is clean at PHPStan level 8, PHPCS with Drupal and DrupalPractice rules, ESLint, Stylelint, and CSpell. Test coverage is described as expanded to approximately 3,400 unit tests, approximately 290 kernel tests, and functional coverage for access control, settings persistence, and rendered output.

The module remains a first-pass audit tool rather than a replacement for senior review of custom code and architecture. The project page says it tracks installed modules and versions, flags pending updates including security releases, and reports category scores from zero to 100. Drupal.org lists 70 sites reporting use of the module.

Drupal Site Audit can be installed with composer require drupal/audit and enabled with drush en audit. The release-specific Composer command is composer require 'drupal/audit:^1.0'. After installation, the project page directs administrators to Admin > Reports > Site Audit.

Development-focused checks remain separate through audit_phpstan, audit_phpcs, and audit_phpunit. The project documentation says these submodules require development dependencies and should be enabled only in development or staging environments. Other submodules are described as read-only checks that do not modify files, configuration, or database content.

An optional connection to DruScan allows multiple Drupal projects to report aggregate audit scores and installed module versions to a central dashboard. According to the project page, the integration sends scores and module lists through cron, while code, content, user data, and configuration details remain on the Drupal installation. The project page also frames the module as a quality gate for AI-generated code, but that claim is presented as project documentation rather than independently benchmarked evidence.