Checksum Command Laravel Package

Product Decisions This Supports

• Security incident response and forensics: wp core verify-checksums and wp plugin verify-checksums give an investigator a fast, scriptable way to answer "has anything in this WordPress install been modified outside the official release?" after a suspected compromise — core files, plugins, and (with --include-root) stray files in the webroot.
• Build vs. buy (buy/adopt): The verification logic, WordPress.org checksum fetching, locale/version handling, and edge cases (mu-plugins, plugins without a main PHP file, soft vs. strict mode) already exist and ship inside WP-CLI. There is no defensible reason to build this in-house.
• Roadmap input for platform/hosting products: If we operate or sell managed WordPress hosting, this command is a natural input to a site integrity score or post-deploy/post-update gate in the control panel. The --format=json|csv|count output makes it consumable by automation without screen-scraping.
• CI/CD and release pipeline gating: As a pre-release or post-migration step, checksum verification catches drift introduced by hotfixes, manual edits, or a botched deployment. --exclude handles the known-legitimate local modifications.
• Managed-site compliance and audit artifacts: --format=json output can be stored as evidence for periodic integrity attestations (SOC2/host hygiene reporting, customer-facing "your site is clean" reports).
• Support triage: Customer support can ask for the verify-checksums output to distinguish "you edited a file" from "a plugin update broke it" before escalating to engineering.
• Not a product decision this supports: malware detection, vulnerability scanning, or WAF behavior. Checksum verification catches deviation from the official package, not malicious-but-valid plugins or database-level compromise.

When to Consider This Package

Adopt when:

• You run WP-CLI anywhere in your toolchain (hosting control plane, CI, site-management automation). The package is bundled with WP-CLI by default — there is effectively no adoption cost; you are only deciding whether to depend on the command's output contract, not whether to install it.
• You need a cheap, deterministic, offline-ish integrity check that does not load WordPress (the command deliberately avoids bootstrapping WP, which is both a security and a reliability advantage).
• You need scriptable output — JSON/CSV/YAML/count formats make it viable as a data source for dashboards.
• Your sites are standard WordPress core + WordPress.org-hosted plugins. That is the core assumption of the whole tool.
• You have an existing --exclude list discipline or can maintain one (files like wp-config-sample.php, readme.html, or intentional core edits must be excluded to avoid false positives).

Look elsewhere / de-scope when:

• Heavily customized sites with extensive core patches, custom wp-config-sample.php, or vendored files in the root. --include-root will generate noise, and --exclude lists become a maintenance burden and a blind spot.
• Premium/private plugins — WordPress.org checksums do not exist for them. You will get "no checksums available" gaps, and the tool cannot verify the majority of a commercial plugin stack.
• Composer-managed WordPress installs or other non-standard layouts where core files are symlinked or relocated; checksum comparison assumptions may not hold.
• You actually need malware/vulnerability detection. Pair with a dedicated scanner (WPScan, Wordfence CLI, Patchstack); do not market this as AV.
• You need real-time alerting or a UI. This is a CLI command; you must build the scheduling, alerting, and presentation layer.
• You need SLAs or vendor support. It is an MIT community package under the WP-CLI org with a small star count; releases are maintenance-driven, not roadmap-driven. Treat it as "well-maintained commons," not "supported product."
• You need a stable API surface. You are depending on CLI command names, flags, and output shape. Historically flags and command names have been renamed (see wp checkum core → wp core verify-checksums), and output is human-oriented with formatting layered on top. Wrap it and pin versions.

Risk notes for the decision record: 0 dependents and 33 stars understate real usage (it is bundled in WP-CLI, so the "dependents" metric is misleading — this is a reason to check the WP-CLI release cadence rather than to dismiss it). Verify plugin checksums are downloaded in parallel as of v3.0.1, which matters for --all performance on large fleets. The --insecure flag exists for TLS failure fallback — explicitly disallow it in any automated pipeline to avoid accepting MITM'd checksums.

How to Pitch It (Stakeholders)

For executives (one paragraph): We can use a free, MIT-licensed, officially-maintained WP-CLI command to automatically prove that a WordPress site's core and plugin files are byte-identical to the official releases published by WordPress.org — the same mechanism behind "is this site clean?" questions after a breach, after an update, or before we declare a deployment successful. It ships with WP-CLI, so adoption cost is near zero, and its structured output (JSON/CSV) plugs directly into our dashboards and audit reports. It does not replace a malware scanner; it gives us a fast, cheap, deterministic integrity signal we can put in front of customers and auditors.

For engineering (summary):

• Two commands: wp core verify-checksums and wp plugin verify-checksums. Both download published checksums from WordPress.org and diff against on-disk files. Core verification intentionally does not load WordPress.
• Key flags: --version, --locale (must match the site's actual version/locale or you get false failures), --include-root (also flags non-WordPress files in webroot), --exclude, --strict (plugin readmes count as changes), --exclude-mu-plugins, --insecure (TLS fallback — do not use in automation), --format=plain|table|json|csv|yaml|count (note: core defaults to plain, plugins default to table).
• Integration plan: pin the WP-CLI version, run on a schedule and after every core/plugin update, capture --format=json, exit-code non-zero triggers alerting. Maintain a per-site --exclude allowlist in config, not in code. Run one verify per site, not per plugin, to amortize the checksum downloads (v3.0.1 parallelizes plugin checksum downloads).
• Limitations to document: no coverage for premium/private plugins, no DB coverage, no malware detection, and false positives on intentionally modified files. Pair with a scanner for security coverage.
• Recommendation: Adopt as a bundled capability / integrity signal, not as a standalone product. Wrap it behind our own service so the CLI contract is not our public API.