Wp Hooks Laravel Package

Technical Evaluation

Architecture fit morningtrain/wp-hooks is not a Laravel package in any framework sense — it is a WordPress utility that wraps add_action/add_filter registration into organized class-based structures. Its runtime contract is the WordPress hook lifecycle (do_action/apply_filters), not Laravel's event dispatcher or service container. That means the fit is narrow and conditional: it is only viable in a Laravel-adjacent architecture where a real WordPress instance is being booted (Bedrock/Sage-style WP powering content behind a Laravel API, or a monorepo where Laravel and WP coexist). In a pure Laravel application the package has no execution context — there is nothing to dispatch hooks into — and the team should use native Events/Listeners instead.

Where it does fit, the architectural value is real but modest: it enforces convention over scattered procedural hook registrations, which is the classic source of "where is this filter attached?" sprawl in mature WP themes and plugins. Think of it as a code-organization tool for a WP codebase, not an integration layer.

Integration feasibility Composer-installable, MIT-licensed, PSR-4, small surface area — a spike is cheap (half a day). The blocker is environmental: the package requires WordPress core functions to exist at registration time. Without a booted WP runtime you get either silent no-ops or fatal errors. If you want it inside a Laravel service provider you would write the bootstrapping yourself and accept an unusual lifecycle dependency.

Technical risk High for a dependency decision, low for a code-volume decision. The signals are unambiguous: 2 stars, 0 dependents, single-organization maintenance, opportunity score of 20.2 against an overall score of 0.04. There is no evidence of CI, version support matrix, or a WP-version compatibility policy in the metadata provided. The realistic failure mode is not a security incident — the attack surface is tiny — it is abandonment and silent incompatibility with future PHP/WP releases while your codebase has already adopted its conventions.

Key questions for the maintainer/team

1. Which PHP and WordPress versions are supported and tested?
2. Is there attribute-based or array-config registration, and does it support priorities, accepted args, and hook removal?
3. What is the maintenance commitment and release cadence?
4. Does it fail loudly or silently when WP is not booted?
5. Can we fork cleanly under MIT if upstream stalls?

Integration Approach

Stack fit Adopt only in the WordPress tier of a hybrid stack — Bedrock/Sage projects or a WP content service consumed by a Laravel API. If the team's Laravel app never boots WordPress, this package is out of scope; the correct Laravel-native answer is Event::listen plus a thin adapter if you ever need to bridge WP hooks across a boundary.

Migration path Do not big-bang it. Wrap one bounded domain of hooks (e.g., admin-side hooks or a single custom post type's filters) into the package's class structure, keep the underlying add_action calls reachable via a shim, and measure whether discoverability actually improved before widening. Because the package is small and MIT, the pragmatic path is vendor/fork internally and treat it as first-party code from day one.

Compatibility and sequencing

1. Spike: install, register two hooks, confirm behavior under your exact PHP/WP matrix.
2. Decide fork-now vs. depend-on-upstream based on that spike.
3. Introduce a project-local convention (base class or interface) that sits above the package so you are not coupled to its API.
4. Roll out per-domain, one sprint of convention-setting included.
5. Add a CI check that hook registration count matches expectation, to catch silent no-ops.

If a Laravel bridge is ever required, sequence the bridge after the WP-side organization is stable — never both at once.

Operational Impact

Maintenance Effectively zero upstream velocity. Budget for owning it: pin a commit, vendor the source, and assign a named maintainer. The upside is that the code is small enough that "owning" it is a few hours a year, not a headcount.

Support No commercial support, no dependents to consult, documentation limited to a README. Onboarding knowledge lives entirely with whoever did the spike — capture that in an ADR.

Scaling Runtime cost is negligible; hook registration is O(number of hooks) at boot and this package does not change that curve. The scaling benefit is organizational, not performance: it scales with team size and codebase age, which is exactly where hook sprawl becomes a productivity tax.

Failure modes

• WordPress not booted → fatal or silent no-op depending on implementation; the latter is worse.
• Convention drift if the team half-adopts it — two registration styles is worse than one.
• Upstream abandonment leaving you on an untested PHP/WP combination.
• Conflicts with other hook-organizing libraries if the team already uses one.

Ramp-up Low for anyone fluent in WP hooks — the concept maps directly to existing mental models. Expect roughly half a day to evaluate, one sprint to establish the convention, and a short tail of review friction while the team internalizes it.

TPM recommendation Conditional adopt. The package solves a genuine problem (hook discoverability) but the ecosystem signals — 2 stars, 0 dependents, score 0.04 — make it a fork-and-own candidate rather than a trusted dependency. Greenlight only if there is a real WordPress codebase with measurable hook sprawl; otherwise the correct move is to skip it and solve the problem natively in Laravel's event system.