Reports

Reports provides a plugin type for site reports. Reports are shown as sortable, searchable tables (with DataTables and filters above the table, like a Views exposed form) or like core's status report, can be downloaded as CSV or Excel, and can be run with Drush. While a table's filters or search hide rows, the rows shown can be downloaded as CSV, in their current order.

Expensive reports are generated on demand with the Batch API and stored in the private file system. Each report shows when it was generated, and warns when it's older than a configurable interval or when the data it was built from has changed (using cache tags). A report can't be generated twice at the same time with the same options.

Submit bug reports and feature suggestions, or track changes, in the issue queue.

Requirements

• Helper
• OpenSpout, installed by Composer.
• Symfony CSS Selector, installed by Composer, for the HTML elements report.
• The private file system, for generated reports (or another non-public directory, see Configuration). Realtime reports work without it. The status report warns when generated reports can't be stored.

Installation

Install as you would normally install a contributed Drupal module. For further information, see Installing Drupal Modules.

Configuration

• Each report has its own page under Reports, e.g. /admin/reports/absolute_urls, listed on the Reports page (/admin/reports). By default, they need the View site reports permission; each report can require other permissions. Unused files also needs Access the Files overview page, Unused taxonomy terms needs Access the taxonomy vocabulary overview page, and Site audit needs Administer site configuration.
• Set when generated reports are out of date at Configuration » System » Reports (/admin/config/system/reports).
• Generated reports are stored in private://reports. To use another directory, such as a private S3 bucket, set $settings['reports_directory'] = 's3private://reports'; in settings.php. It must be writable. public:// works but the status report warns about it, since anyone with a file's URL could download reports, which can contain unpublished content and site details. temporary:// also works with a warning, since it can be cleared at any time and isn't shared between web servers.
• Generated report files are deleted on cron once they're older than Delete generated reports after (30 days by default), and generated again when next viewed. drush reports:clean does the same on demand.
• Generated reports process $settings['reports_batch_size'] items per batch pass, set in settings.php. It defaults to core's $settings['entity_update_batch_size'] (50).

Included reports

• Absolute URLs: links in content (link and URI fields, Custom Field link and URI subfields, and <a> elements in text fields) that use absolute URLs to the site's own domains, or to any domain when Domains is left empty. Checks text as displayed (after text format filters) or as entered.
• HTML elements: elements in formatted text fields (and formatted Custom Field Text (long) subfields) that match an HTML tag, CSS selector or XPath expression, with their text and HTML. Checks text as displayed or as entered.
• Field list: replaces Field UI's Field list (/admin/reports/fields), with a sheet for each of its tabs: the fields, the fields used in views (Views UI) and field permissions (Field Permissions), so each can be filtered and downloaded.
• Content counts: the number of items of each bundle of each content entity type, and how many are published. Useful to find unused bundles.
• Duplicate values: content that shares the same value in a single-value text field, such as the title (the default) or a summary. Fields that must already be unique are left out.
• Site audit: an Excel workbook (download only) with, for each entity type, a sheet listing its bundles (description, URL patterns, new revisions, workflow, translation, Layout Builder, and for content types their available menus, preview and author display settings, or for media types their source) and a sheet per bundle listing its fields (field type, allowed values, cardinality, required, widget, formatter, character limit, help text), with custom field subfields as their own rows; plus a sheet of text formats. Entity types whose fields are managed in the UI but have no bundles, such as users, get only their field sheet. The bundle summaries and the text formats sheet are options (Also include), on by default.
• Unused files: files that nothing uses (no file usage records), optionally including temporary files.
• Unused taxonomy terms: terms that no entity reference field references, optionally limited to some vocabularies. Requires the Taxonomy module.

Drush commands

• drush reports:list (alias drush reports): lists the reports and when they were generated.
• drush reports:run <id> [--config=key=value] [--sheet=<sheet>] [--generate] (alias drush report <id>): outputs a report. Without an ID, it asks which report to run. Asks to regenerate a generated report that's missing or out of date, unless --generate is given. For download-only reports, such as Site audit, it gives the download URL instead of the rows (set --uri so the URL uses the site's address).
• drush reports:generate <id> [--config=key=value]: generates a report. drush reports:generate --all generates every generated report with its default options.
• drush reports:clean: deletes generated report files older than Delete generated reports after, and unfinished ones, as cron does.

Developer documentation

Other modules can add their own reports as plugins. Writing reports, in the developer documentation, covers the #[Report] attribute, realtime and generated reports, the base classes to start from, sheets, columns and cells, options, requirements and caching.

AI disclosure

Most of this module's code, tests, and documentation were written with Claude Code (Anthropic's Claude Opus models), from my design and engineering decisions: the plugin API, realtime and generated reports, sheets, storage and downloads, and the DataTables integration. I directed and reviewed each change and tested it personally on both a client implementing site and an independent local site.