Wordpress Core Laravel Package

Product Decisions This Supports

• Build vs. buy for hook intelligence. This package answers "do we need to write our own PHP parser to extract WordPress hooks?" with a credible no. It ships a versioned JSON catalog of WordPress core actions and filters — names, arguments, file/line locations, docblocks, and deprecation status. That is 1–3 sprints of parsing and normalization work we can skip and spend on the product surface instead.
• Feature scoping for developer-tooling products. If we are building anything that reasons about WordPress code — an IDE extension, a linter/CI check, a hook reference site, an upgrade-compatibility scanner, or an AI assistant for WP developers — this dataset is the retrieval layer. It determines what is cheap to build (signature lookup, autocomplete, "which hook fires here") versus what stays expensive (runtime behavior, conditional logic, cross-plugin interactions).
• Roadmap sequencing around WordPress release cadence. Because releases track WP versions, we can diff catalog versions to produce a "what hooks changed in WP 6.x" view. That is a defensible recurring feature (compatibility matrices, deprecation alerts) rather than a one-off.
• AI/LLM grounding strategy. For any generative WP feature, this is a deterministic, citable source of truth for hook signatures — a far cheaper and more accurate alternative to letting a model hallucinate hook names and argument orders. It also gives us an evaluation corpus to measure hallucination rates against.
• Market sizing signal (weak). 126 stars tells us this is infrastructure a small number of tool-builders depend on, not a mass-audience asset. Useful as a sanity check that "WordPress developer tooling" is a real but narrow segment — not as evidence of demand.

When to Consider This Package

Adopt when:

• The product needs structured, offline, machine-readable hook metadata for WordPress core, and we do not want to maintain a scraper against developer.wordpress.org.
• We need the data in CI or at build time (static analysis, codegen, docs generation) where a live API call is unacceptable.
• We are already in the WordPress/PHP ecosystem and GPL-3.0 is compatible with our distribution model.
• Coverage of core hooks is sufficient — most hook-usage problems live in core, not in a given plugin.

Look elsewhere when:

• We need hooks from third-party plugins or themes. This package covers core only; the sibling generator (wp-hooks/generator) is the tool for arbitrary codebases, and it means owning a generation pipeline.
• Licensing is incompatible. GPL-3.0 is copyleft; embedding this dataset in a proprietary or SaaS product requires legal review. Treat this as a gating question, not a footnote.
• We need runtime semantics. The catalog describes what hooks exist, not when they fire or what state is available. That still requires instrumentation or manual curation.
• Vendor-risk tolerance is low. Single-maintainer, low-star, release-cadence-dependent project. If the product's core value rests on this data, we must be prepared to fork and regenerate it ourselves.
• The product isn't WordPress-adjacent. No transferable value.

How to Pitch It (Stakeholders)

For executives: This is a free, structured dataset of every WordPress core hook, maintained by a recognized WordPress contributor and released in step with WordPress versions. It converts an expensive data-acquisition problem into a dependency. Roughly: weeks of engineering and ongoing parser maintenance avoided, in exchange for a GPL-3.0 licensing constraint and a single-maintainer dependency. Neither risk is a blocker; both are known and cheap to mitigate (pin a version, mirror the JSON, retain the option to regenerate). Recommendation: adopt for internal tooling and prototyping now; confirm licensing posture before it touches anything we sell.

For engineering: It's JSON, not a runtime library — no service, no API keys, no network calls in production. You get hook names, argument lists, source locations, and docblocks per WordPress version, which means autocomplete, linting, docs, and static analysis all read from the same source of truth. Caveats: core-only, no runtime semantics, GPL-3.0 propagates to derivative data, and it's a low-activity repo — so vendor the artifact at a pinned tag rather than pulling main, and assume we may eventually own the generation step.