When you switch development ecosystems, especially after spending over a decade in one, you expect trade-offs. My move from a 12+ year focus on WordPress to building with Laravel was no different. I gained a world of power, elegance, and modern tooling, but I also lost a few familiar comforts.
The biggest one? A built-in, first-party hooks system.
After more than a decade with WordPress, the add_action() and add_filter() system was second nature. It’s the engine that makes the entire platform so incredibly extensible.
As I started architecting my own ambitious projects in Laravel—tools like ArtisanPack UI and Digital Shopfront CMS, all designed to empower small businesses—I knew I needed that same level of flexibility. I had to find a way to allow for deep, safe customization.
My Initial Solution: The Eventy Package
My quest for a solution quickly led me to the tormjens/eventy package.
It was an excellent find, as it essentially ports the WordPress actions and filters system directly into a Laravel application. For someone with my background, it was the perfect bridge.
From a developer’s perspective, hooks are invaluable for building extensible software. They provide a clean, decoupled way to allow for customizations and modifications based on specific situations, and they’re perfect for letting third-party packages or themes integrate deeply.
This functionality was absolutely critical for my own projects. I knew from the start that I needed to empower other developers and users to customize my tools without ever needing to edit the source code.
For a time, Eventy was the perfect solution for that job.
Why I Created My Own Package
To be perfectly clear, I have no functional issues with the tormjens/eventy package. It performs its job exceptionally well.
My concern arose a few weeks ago when I reviewed its repository. I noticed the version number had remained at 0.9.4, meaning it hadn’t yet reached a stable 1.0 release.
More importantly, it hadn’t received an update in roughly a year.
For me, as a package author myself, that raised a significant red flag.
I am very cautious about using potentially abandoned projects in my professional work. That caution is doubled for any packages I integrate into tools and applications intended for others, especially the small businesses I aim to empower.
Relying on unmaintained dependencies creates a cascade of potential problems down the road, from security vulnerabilities to future PHP or Laravel version incompatibilities.
So, after that realization, and now armed with much deeper knowledge of Laravel’s inner workings, I decided it was time to create my own modern solution.
Creating the ArtisanPack UI Hooks Package
I got to work building my own package, which is now available as artisanpack-ui/hooks on Packagist.
I’ll be transparent: I leveraged modern AI tools to accelerate this process significantly.
I had a clear vision for what I wanted to build and a solid idea of the required architecture. Crucially, I did not want to simply fork or copy the tormjens/eventy package; I wanted to build it from the ground up to fit my specific needs and modern coding standards.
I worked with Gemini to brainstorm and create a detailed development plan.
As I’ve learned in this new world of AI-assisted development, the key is refinement. I didn’t accept the first output; I drilled down, challenged its assumptions, and iterated until the plan was robust and efficient.
From there, I used Junie in PHPStorm to handle much of the boilerplate implementation and smooth out any rough edges. It was also an invaluable asset in creating a comprehensive test suite for my CI/CD pipeline and then generating the initial documentation.
The entire process, from concept to a tested, documented package, was completed in about two days.
The Future of the Hooks Package
With the artisanpack-ui/hooks package now stable and in use in my other projects, I don’t foresee a large number of new features.
It feels largely feature-complete for its intended purpose.
Its goal is to be a simple, lightweight package that does one job and does it well, providing that solid, WordPress-like hook functionality for any Laravel application.
This means it is effectively in a maintenance phase.
However, “maintenance phase” absolutely does not mean “abandoned.” Far from it. It will receive fixes and patches if and when any issues are reported by the community.
I am also certainly open to feature requests where they make sense and align with the package’s simple, focused philosophy. It’s built to be a reliable, long-term tool for any developer who needs it.
