Wordpress Core Laravel Package

Technical Evaluation

Architecture fit. This is not a Laravel package in any conventional sense — it is a Composer-installable data artifact: a set of JSON files enumerating WordPress core actions and filters, each annotated with name, type (action vs. filter), originating core file, and parsed docblock metadata (@since, @param, @return). There is no service provider, no facade, no runtime API, no PHP classes to speak of. That reframes the evaluation: its fitness is not "does it integrate with the container" but "is the data trustworthy and is the access pattern cheap." For a Laravel codebase the only credible fits are (a) developer tooling — internal hook documentation, IDE/static-analysis rules, migration inventory for legacy WordPress plugins being ported to Laravel events/listeners; (b) a WordPress-bridge product where Laravel and WordPress coexist (headless WP, WP-as-CMS behind a Laravel API) and you need an authoritative registry of hook names and signatures for a compatibility layer or code generator; (c) an LLM/RAG corpus for an internal assistant answering "which hook fires on post save." Direct runtime use in a request path is an anti-pattern.

Integration feasibility. High and cheap. composer require wp-hooks/wordpress-core pulls a directory of JSON under vendor/; resolution is a single file_get_contents plus json_decode, or Composer\InstalledVersions::getInstallPath() to avoid hardcoding the vendor path. No PHP version constraints of consequence, no framework coupling, no transitive dependency risk. Realistic effort: half a day to spike, two to three days to build a cached ingestion command plus a query surface, and the remainder of the effort is not technical — it is curating the mapping from WordPress hooks to Laravel events/jobs, which is a product decision, not a package capability.

Technical risk. Low-to-moderate, and almost entirely around data semantics rather than code:

• GPL-3.0. Fine for internal tooling; a real review item if the JSON is redistributed inside a commercial product or embedded in a shipped artifact. Data may be fact-like, but the package is licensed GPL and legal should sign off before it lands in a distributed binary.
• Completeness. These artifacts are produced by static analysis of core source. Dynamically constructed hook names (do_action( "{$prefix}_saved" )), hooks registered at runtime, and anything outside core (WooCommerce, ACF, mu-plugins) will be absent or partially represented. Treat as "core hooks, best effort," never as ground truth for a lint rule that fails builds.
• Schema stability. The JSON shape is de facto, not a versioned contract. A shape change upstream silently breaks your parser unless you snapshot and pin.
• Provenance anomaly. The metadata shows a last release of 2026-08-20, which is inconsistent with normal release cadence and should be verified against the actual repository before it enters a dependency policy. More broadly, this is a small single-maintainer OSS project at 126 stars — bus factor is the dominant supply-chain risk, and the low composite score reflects that fragility rather than uselessness.

Key questions. Is the JSON schema documented and semantically versioned? Does each release pin to an explicit WordPress core version, and does it retain historical versions so we can target, say, WP 6.4 while running WP 6.7? How are dynamic and deprecated hooks represented? What is the artifact size and does it ship any autoloaded PHP? Is redistribution inside our product compatible with GPL-3.0 given our distribution model? Who upstream is on the hook for WP-version parity, and what is the lag after a core release? Do we need non-core hook coverage, and if so is a second data source required?

Integration Approach

Stack fit. Neutral-to-good. Requires only PHP and ext-json; compatible with any Laravel version and any PHPStan/Psalm setup. It will not conflict with framework constraints because it contributes no runtime code. The natural Laravel-side consumers are an artisan command that ingests the JSON into a hooks table or a cache-backed repository, and a HookRegistry service consumed by tooling — not by HTTP controllers.

Migration path. Two distinct paths depending on the use case. For tooling: install, snapshot the artifact, write an ingestion command, expose a read model. For runtime bridging (Laravel app dispatching or listening to WordPress hooks): do not read the JSON at request time — generate typed constants or an enum from the JSON at build time and commit the generated file. That converts an opaque data dependency into reviewable source, which is the right trade for anything on a hot path.

Compatibility. Watch three axes: the WordPress core version the artifact was generated against versus the version you actually deploy; Composer install-path assumptions if you resolve files by path; and JSON schema drift across package releases. Pin the package to an exact version (not a caret range) in composer.json and let Renovate open explicit upgrade PRs so that a schema change surfaces as a failing ingestion test rather than a production surprise.

Sequencing.

1. Spike (1–2 days). Install, parse the JSON, validate coverage against two or three real plugins or a Laravel–WordPress bridge you already run. Confirm the schema and the core-version pin.
2. Internal tooling (1 sprint). Ingestion command, cached read model, a docs generator or an inventory report for a migration candidate. No production exposure.
3. CI-grade checks (optional, next sprint). Static rule that warns — never blocks — on unknown hook names, with a suppression list for dynamic and third-party hooks.
4. Generated code (only if a bridge exists). Emit constants/subscriber stubs; review and commit; keep the JSON out of the deploy artifact if GPL distribution is a concern.
5. Runtime use: explicitly out of scope unless a measured need appears.

Operational Impact

Maintenance. Effectively zero runtime maintenance and modest pipeline maintenance. You own the ingestion command, the snapshot, and the upgrade test. Pin the dependency, commit the snapshot, and treat upstream releases as a quarterly review item rather than a continuous feed. If the project goes dormant, a frozen snapshot remains usable for the WordPress version it targets — degraded, but not broken.

Support. Community-only, GPL, small maintainer base, no SLA. Acceptable for internal tooling and unacceptable as a load-bearing dependency in a customer-facing correctness path without a fallback. Budget for the possibility of forking the artifact or generating it yourself from core source.

Scaling. Non-issue. The dataset is static and read-only; ingest once at deploy into a database table or Redis, or resolve from a committed generated file. The only scaling failure is the naive one — parsing multi-megabyte JSON on every request — which is easily avoided and should be an explicit review checkpoint.

Failure modes.

• Upstream schema change breaks the parser → mitigate with pinned version plus an ingestion smoke test in CI.
• Core-version mismatch yields false negatives in hook-name validation → surface the targeted WP version in the tool's output and never fail a build on a miss.
• Dynamic/third-party hooks absent → suppression list plus a documented "core hooks only" caveat.
• Composer install path assumptions break under a different installer or a monorepo layout → resolve via InstalledVersions, not string paths.
• Maintainer abandonment or a license challenge on redistribution → snapshot plus a pre-cleared legal position.
• Silent trust in the data → the real risk. Teams start treating the registry as authoritative and stop reading core source.

Ramp-up. A mid-level PHP developer is productive in a day; there is nothing to learn beyond JSON parsing. The genuine cost sits with whoever owns the WordPress domain knowledge to interpret docblocks and decide which hooks matter — that is a subject-matter constraint, not a package constraint, and it is where the schedule risk actually lives.