- How do I install millat/laravel-hooks in a Laravel application?
- Install it with Composer using composer require millat/laravel-hooks. The package ships a service provider with Laravel auto-discovery, so no manual registration is normally required, and its configuration file is publishable if you need to tweak behaviour. There are no native extensions or system dependencies, so the install is a low-friction, afternoon-sized spike. Confirm the resolved version against your Laravel target before rolling it out beyond a branch.
- How is millat/laravel-hooks different from Laravel's built-in events and listeners?
- Laravel already provides an event dispatcher, listener registration in service providers, and the Pipeline for value transformation, which covers most of the same ground. This package ports the WordPress add_action, add_filter, do_action and apply_filters model instead, adding named, priority-ordered, value-mutating extension points. The practical difference is the plugin contract: third parties can attach to hooks you document without touching your core code. If your team owns the entire codebase, native events are usually the more explicit choice.
- Does millat/laravel-hooks support priority ordering for hooks?
- Yes. Priority-ordered execution is a core part of the WordPress hooks model the package ports to Laravel, so callbacks can be registered to run before or after others on the same hook name. That ordering matters when multiple listeners transform the same value, because the sequence determines the final result. Verify the exact default priority and tie-breaking behaviour in a spike before relying on it in a documented public extension API.
- Can I remove or deregister a hook after registering it?
- A hooks system without clean removal becomes a memory-leak and test-isolation hazard, so confirm removal support before adopting it. Check the package source or README for a remove_action or remove_filter equivalent that matches on the callback and priority, since mismatched priorities are a common source of hooks that silently refuse to detach. If removal is not supported, restrict registration to boot-time service providers and avoid dynamic registration in long-running workers such as Octane or queue daemons.
- How do I test code that uses millat/laravel-hooks?
- Because hooks are registered at runtime, leftover callbacks can bleed between tests and produce order-dependent failures. Register hooks in test setup, then reset or clear the hook registry in tearDown so each test starts from a known state. Asserting behaviour is straightforward: apply the filter to a known input and assert on the returned value, or fire the action and assert the expected side effect occurred. If the package has no dedicated assertion helpers, wrap these checks in your own base test case.
- Which Laravel and PHP versions does millat/laravel-hooks support?
- Check the maintainer's compatibility matrix on the GitHub repository and in the Composer constraints before committing. This is a single-maintainer package with low download volume, so it can lag behind major Laravel releases. Validate that it supports your current Laravel version plus your next twelve-month upgrade target, and treat a missing major-version constraint as a signal to fork or vendor it.
- When should I use hooks instead of Laravel events?
- Use hooks when the extension model is a product requirement, for example a CMS, plugin ecosystem, extensible commerce platform, or a product where customers write integration code against your internals. Avoid refactoring existing internal control flow into hooks purely for decoupling, because that trades compile-time clarity for runtime discovery with no external consumer to justify it. A good rule is native events for internal cross-domain communication and hooks only for the versioned public extension surface.
- Does millat/laravel-hooks support wildcard matching or did_action and did_filter counters?
- The overview focuses on the WordPress add_filter, add_action, do_action and apply_filters model and does not document wildcard matching or did_action and did_filter style counters. Treat those as questions to answer in your spike by reading the source rather than assuming parity with WordPress core. If your extension API depends on counters or wildcard hook names, verify them explicitly or plan to layer that behaviour yourself.
- Is millat/laravel-hooks safe to use in production?
- The MIT license and clean Composer install make it easy to adopt, but the project has a bus factor of one, modest star count, no dependents and no visible organisational backing. Treat it as a vendored dependency rather than a strategic one: pin the version, read the source, and be prepared to maintain a fork. Also watch the failure mode when a filter returns null or an unexpected type, since silent corruption in a price or permission filter is far worse than a hard error.
- What are the alternatives to millat/laravel-hooks for building extensible Laravel apps?
- Laravel's own event dispatcher, service-provider listener registration and Pipeline cover roughly seventy to eighty percent of the hooks use case without any third-party dependency. For a formal extension contract you can also document your own named extension points backed by events, or use Laravel's container bindings and interfaces for swapping implementations. Reach for a dedicated hooks package only when you specifically need WordPress-style priority-ordered, value-mutating filters that outside developers attach to.