Checksum Command Laravel Package

Technical Evaluation

Framing correction (important for scoping): wp-cli/checksum-command is not a Laravel package and not a general-purpose PHP library. It is a WP-CLI command package — a set of Symfony-Console-style commands that register against the WP-CLI runtime (wp core verify-checksums, wp plugin verify-checksums). It is bundled inside WP-CLI itself and has 0 Composer dependents, so it is consumed as a CLI tool / operational capability, not as an in-process dependency. Any Laravel-side "leverage" is therefore an orchestration story (invoke the binary, parse structured output), not a composer require story.

Architecture fit

• Fits into the verification/assurance layer of a WordPress estate: pre/post-deploy integrity gates, incident-response triage after a compromise, drift detection on long-lived customer sites, and audit evidence generation.
• Does not fit inside a Laravel request lifecycle. There is no service provider, no facade, no public API surface. Its only contract is CLI arguments + exit codes + --format=json|csv|yaml|count payloads.
• Natural home: CI/CD pipeline step, container image build check, or a cron'd ops job — adjacent to your Laravel apps where they front WordPress content (headless CMS, marketing sites, multisite backends).

Integration feasibility — high, with caveats

• Trivial to run in any environment with PHP + WP-CLI; no installation needed where WP-CLI is already present (wp package install only to override the bundled version).
• Structured output (--format=json) makes it machine-consumable, which is the single most valuable property for a TPM: it converts a human-facing check into a pipeline assertion.
• Non-invasive: the README explicitly states checksum verification avoids loading WordPress, so it is safe to run against production file trees without bootstrapping the app or hitting the DB.
• Caveats: success/failure signalling is exit-code + Error:/Warning: text; --insecure retry exists as a tempting escape hatch; MD5-based comparison means integrity vs. published manifest, not cryptographic authenticity.

Technical risk

• Manifest trust boundary. Checksums are downloaded from WordPress.org over TLS; MD5 gives corruption/tamper detection against that manifest, but the root of trust is the remote endpoint plus TLS. Treat --insecure as a policy violation in prod.
• External dependency on api.wordpress.org / downloads.wordpress.org. Availability, latency, and rate-limiting become your CI reliability. No offline/vendored manifest mode documented.
• False positives are the dominant operational risk. Version/locale drift (--version, --locale), custom files in root (--include-root surfaces them), readme.txt soft changes (--strict flips behaviour), plugins not hosted on WordPress.org (no checksums → cannot verify), and mu-plugins (--exclude-mu-plugins) all produce noise that erodes trust in the gate.
• Governance/adoption risk. 33 stars, 0 dependents, single-maintainer-adjacent project. Mitigated substantially by being bundled with WP-CLI — you are relying on WP-CLI's release train, not this repo's popularity. Still, feature requests here have a high bar ("open an issue to discuss fit first").
• Version skew between bundled and standalone package (v1.x → v2.x --include-root/--version, v3.0.1 parallel checksum downloads) can make the same command behave differently across hosts.

Key questions

1. Is the deliverable a CI gate, an incident-response playbook step, or continuous fleet drift monitoring? Each implies different cadence, thresholds, and alert routing.
2. Which WordPress surfaces are in scope — core only, all wporg-hosted plugins, or third-party/premium plugins (which this tool cannot verify)?
3. What is the acceptable failure policy: fail-the-build on any mismatch, or warn-and-report except for a curated allowlist (--exclude)?
4. Do we require an offline/air-gapped verification path? If yes, this package is insufficient as-is.
5. Who owns version pinning of WP-CLI across the estate, and how do we guarantee a consistent --version/--locale pair per site?
6. Given opportunity: 61.43 vs. overall score: 30.4, is the intent to adopt the command or to build a wrapper product on top of it? The gap reads as "high unmet need, low current mindshare" — a signal to wrap, not fork.

Integration Approach

Stack fit

• Runtime: PHP 7.4+/8.x (v2.1.1 added PHP 8.1 support; v3.x is the current line). Runs anywhere WP-CLI runs — same container/host as the WordPress install.
• Laravel side: treat it as an external binary. Recommended pattern:
  • A queued Job or Artisan command (php artisan wp:verify-checksums) that shells out via Symfony\Component\Process\Process, captures --format=json, and persists results to an integrity_checks table (site, version, locale, checked_at, mismatches JSON, exit_code).
  • Surface via a Nova/Filament dashboard or Slack notification — this is where TPM value is realized: turning a CLI exit code into a tracked, auditable signal.
• Do not add it to composer.json of the Laravel app. If you must install it explicitly, install it in the WP-CLI context (wp package install wp-cli/checksum-command) or bake it into the ops image.
• CI: a pipeline step inside the WordPress build/deploy stage, before artifact promotion; cache WP-CLI and pin the WP-CLI version.

Migration path

1. Discover — inventory sites by WP core version, locale, and plugin provenance (wporg vs. premium/custom). Establish the verifiable subset.
2. Baseline — run wp core verify-checksums --format=json and wp plugin verify-checksums --all --format=json in report-only mode for 2–4 weeks; catalogue every mismatch class (custom root files, locale mismatch, soft changes, unverifiable plugins) and build the --exclude allowlist from evidence.
3. Gate — promote to blocking in CI for new deployments only; keep legacy sites in report-only until their baselines are clean or allowlisted.
4. Extend — add plugin-level verification with a curated --exclude list and --exclude-mu-plugins where mu-plugins are vendored; wire --version/--locale from the site's actual metadata rather than defaults.
5. Operationalize — scheduled fleet checks + alerting; run as a documented step in the security incident runbook.

Compatibility

• Works on standard WP-CLI installs with no extra install; the standalone package is only for version override.
• Constrain: PHP version per site, WP-CLI version, WP core version, locale string source of truth. Enforce --insecure prohibition via lint/review — no config flag should enable it on production paths.
• Watch --strict semantics for plugin checks: default tolerates readme.txt-class "soft changes." Decide explicitly per environment; strict in CI, lenient in monitoring, or vice versa — but document it.
• Output schema is per-command and format-dependent (core defaults to plain, plugin defaults to table); always pass --format=json explicitly and version your parser against the payload shape ({"file": ..., "message": ...} for core).

Sequencing (recommended)

• Phase 0 (1 sprint): spike in one non-critical site; validate JSON output, exit codes, runtime, network egress requirements.
• Phase 1 (1–2 sprints): Laravel wrapper job + persistence + dashboard; report-only.
• Phase 2: CI gate for core checksums; allowlist governance process (who approves exemptions, expiry).
• Phase 3: plugin-level verification; expand to fleet; add incident-response runbook entry.
• Phase 4: evaluate gaps (offline manifest, premium-plugin verification) and decide build-vs-buy for the residual.

Operational Impact

Maintenance

• Low code-maintenance burden for us — we consume a CLI contract, not internals. Upstream is actively released (v3.0.1 adds parallel plugin checksum downloads; recent fixes for PHPStan/PHPCS, --exclude whitespace trimming, and plugins without main PHP files).
• Our maintenance cost sits in the wrapper: parser tolerance to output changes, allowlist hygiene, and WP-CLI version pinning across the fleet. Budget ~10–15% of one engineer ongoing.
• Track upstream releases for behaviour changes (v2.0.0 framework v2 adaptation, v2.2.0 --include-root, v3.x parallelization) and re-baseline after each WP-CLI bump.

Support

• Upstream support is community-only: GitHub issues for bugs (with strict bug-report norms), WordPress.org handbook for general support — not for "how do I use this." No vendor SLA. Escalation path for a broken gate is: pin/downgrade WP-CLI, fall back to report-only, file upstream.
• Internal support model needed: one owner for the allowlist and one for the pipeline step; documented runbook for "gate red — what now."

Scaling

• Scales linearly and cheaply per site (seconds per run; v3.0.1 parallelizes plugin checksum downloads, which was previously the bottleneck for plugin-heavy sites).
• The real scaling constraint is upstream API politeness: hundreds of sites × frequent runs against WordPress.org downloads. Mitigate with staggered schedules, caching of fetched manifests per version/locale, and running checks at deploy time rather than on aggressive cron.
• No horizontal state to manage — stateless, file-tree-read only, no DB writes. Very container-friendly.

Failure modes (ranked by likelihood × impact)

Ramp-up

• Engineer: hours. Running the two commands is trivial; the README examples cover 90% of usage. Building the wrapper and JSON parser: ~2–3 days.
• Organization: weeks. The hard part is policy, not technology — defining what "clean" means, who grants exemptions, whether --strict applies, and how a red gate blocks a release. Budget a policy doc plus an allowlist review cadence (quarterly).
• Training: a single runbook page for on-call ("gate failed → check locale/version → check allowlist → check for genuine modification"), plus a short note in the deploy docs. Do not attempt to teach the team the package internals; teach the two commands, the three flags that matter (--version, --locale, --format=json), and the one forbidden flag (--insecure).
• Adoption signal to watch: time-to-green on a fresh site. If the allowlist grows monotonically, the gate is misfiring and will be disabled — that is the primary failure risk for this initiative, and it is a process problem, not a package problem.