Wordpress Autoloader Laravel Package

Product Decisions This Supports

• Code organization standard for WordPress themes and plugins. The package lets you split code into small files named after the WordPress hook they belong to (e.g. init.php, wp_loaded.php, save_post.php) and have them required automatically at the right moment. The PM decision it informs is whether to standardize on a file-per-hook convention across your WordPress codebase instead of large procedural functions.php files or bespoke bootstrap classes.
• Build vs. buy for internal glue tooling. This is a small, single-purpose utility rather than a framework. It supports the decision "do we write and maintain ~100–200 lines of autoloading glue ourselves, or take a dependency?" — useful input when scoping a platform-standard repo template for agency or in-house WordPress work.
• Roadmap scoping for plugin/theme scaffolding. If your roadmap includes a reusable starter theme, mu-plugin loader, or shared component library, this package can be the loading mechanism, which shortens the estimate for "set up project skeleton" tasks and reduces per-project boilerplate.
• Onboarding and cognitive load as a product concern. Convention-driven loading means a new engineer can find the code for save_post by opening save_post.php. This is a defensible argument for standardizing when your team size or contractor churn is growing.
• Migration sequencing. Adoption is incremental — it can be introduced file-by-file in an existing theme without a rewrite, which affects how you phase WordPress modernization work rather than treating it as a big-bang refactor.
• Use cases where it fits well: mu-plugin directories, VIP-style enterprise WordPress builds with many small hook files, themes with dozens of independent customizations, and shared codebases maintained by multiple squads.

When to Consider This Package

Adopt when:

• You are building or maintaining WordPress themes/plugins where code is naturally organized by hook and you want that convention enforced by the loader rather than by documentation.
• Your team is already in the Alley Interactive / WordPress VIP orbit, or follows similar conventions — the package exists to serve that style, and alignment is the main source of value.
• PHP 7.4+ and Composer are already in your stack; the package is a thin Composer dependency, not a new platform.
• You need faster onboarding and easier code review more than you need architectural sophistication.
• You are prepared to treat it as vendored infrastructure: pin the version, read the source (it's small), and accept that you may fork it.

Look elsewhere when:

• You want class autoloading — that is Composer's PSR-4 job; this package is about requiring hook files, not resolving classes. Do not buy it for the wrong problem.
• Your project is not WordPress, or your WordPress code is already structured around a framework (Roots/Sage, Themosis, Timber, or a custom DI container). Layering this on top adds a second, competing convention.
• You need vendor support, SLAs, or an active community. The adoption signals here are weak — roughly 10 stars and zero known dependents at review time — so the realistic support model is "you, the source, and your fork."
• You are shipping a distributed plugin to third-party sites and want a minimal dependency surface; a few lines of glob()/require in your own bootstrap may be the better trade.
• You need guarantees around long-term maintenance. Last release is recent (April 2025), which is a positive signal, but bus factor is the dominant risk.

Due-diligence checklist before committing: read the loader source end-to-end, confirm hook-ordering semantics match your expectations, verify behavior on your PHP version, confirm file-discovery performance on large theme directories, and write down the exit plan (typically: replace the Composer dependency with an in-repo copy).

How to Pitch It (Stakeholders)

For executives: This is a small, low-cost utility that standardizes how our WordPress code is organized and loaded. It reduces per-project setup work and makes code easier to hand off between teams, which matters as we scale delivery and contractor turnover. The risk profile is low and bounded — it is a thin dependency we can pin or replace with in-house code in a day — but it is also a low-adoption package, so we should treat it as an internal convention tool rather than a strategic platform bet, and avoid making it a hard dependency across many client deliverables without an exit plan.

For engineering: Adopt it as the loading convention for hook-oriented WordPress code: one file per hook, discovered and required at the correct time, no manual require lists to maintain. It is additive and incremental — you can migrate one directory at a time — and it removes boilerplate from functions.php. It does not replace PSR-4 class autoloading, so keep Composer doing that job. Because the project is small and lightly adopted, we pin the version, review the source once, and keep a fork-ready posture: if upstream stalls, we vendor it.