Web Patches

Web Patches shows the patches — and the ignored patches — declared for your site, right in the admin UI.

Patches are applied by Composer, through cweagans/composer-patches and the webship/patches Composer plugin. This module does not apply, download or write patches — it never even fetches a URL. It reads the same declarations Composer reads and applies the same allowlist and ignore rules, so a site owner can finally see what is patched and what was filtered out, without opening a terminal.

The report

Reports → Web Patches lists:

• Patching sources — the declaration files (root composer.json, the Composer Patches patches file, an optional custom file), and every installed package that declares patches with the allowlist verdict for each: Allowed, or Not allowed with the reason. A module that ships its own unwanted patches — AI Context declares a Drupal Canvas patch in its composer.json, for example — is plainly flagged as Not allowed, and its patches never touch your site.
• The patch lock — whether patches.lock.json exists and matches the declarations. When it is out of sync, the report lists the differences both ways — declared but not locked and locked but no longer declared — with the composer command that fixes it.
• Patches — every declared patch, linked all the way: the package to its drupal.org project page, the #1234567 issue reference to the drupal.org issue, the patch file to itself, and an MR !id link to the merge request on git.drupalcode.org when the file name carries it.
• Ignored patches — every declared patch that is not applied, with the reason: not in the allowlist, matched by an ignore rule, or listed in patches-ignore (for example, skipping a single Drupal core patch you do not want).

By default the report shows only patches for packages installed on the site. A settings form at Configuration → Development → Web Patches selects the sources and can point at a custom patches file.

Why

Contrib modules sometimes ship their own extra.patches pointing at stale or third-party URLs, and a curated patch set changes with every release. Composer knows exactly what it applied — but that knowledge lives in lock files and build logs. Web Patches puts it on a report page: what is declared, where it came from, and why something you expected is not applied.

Documentation

Full documentation, with screenshots of every state: project.pages.drupalcode.org/webpatches

Works with

• cweagans/composer-patches v2 (and reads the v1 declaration keys too)
• webship/patches — the Webship curated patch list and Composer plugin
• webship/drupal-patches — the Webship curated Drupal core patches, one branch per core minor

Both permissions are restricted: the report reveals server paths and installed package versions, so it belongs to administrators. Requires Drupal core ^11.1.

Credits

The Webship patch packages build on the excellent work of Vardot: Varbase Patches and Vardot Drupal Core Patches are the upstream projects — and still carry the more advanced patching management methods, powering Varbase.