- How do I temporarily disable an Eloquent observer in Laravel?
- Install monooso/unobserve and use its helpers to mute the observers registered on a model, run your saves, updates, or deletes, then restore observation. This avoids the usual workarounds of unregistering observers in a service provider or wrapping calls in conditionals inside the observer itself. Check the README for the exact method names, since the package offers both a persistent toggle and a scoped form for one-off operations.
- How do I install monooso/unobserve with Composer?
- Add it as a normal Composer dependency with composer require monooso/unobserve, then confirm the installed major matches your Laravel version. Laravel package discovery handles the service provider, so no manual registration is normally required. If Composer resolves a version that conflicts with your framework constraint, pin an older tagged release rather than forcing the framework upgrade.
- Which Laravel and PHP versions does monooso/unobserve support?
- Version 7.0.0 targets PHP 8.3 and Laravel 13, and the maintainers have moved to a latest-major-only support policy. That means Laravel 10, 11, and 12 applications should pin an earlier tagged release such as the latest v6.x line. Treat v7 as a fast-follow dependency tied to your Laravel upgrade cadence rather than a long-lived compatible library.
- Can I mute observers for a single save instead of disabling them globally?
- Yes. The package is designed around toggling observers at will, so you can scope the mute to the specific block of work and restore observation immediately afterwards. That keeps observer side effects like notifications, cache invalidation, and audit logging active everywhere else in the application. Prefer the scoped form over a global mute in request-handling code so long-running processes cannot leak a disabled state.
- Does unobserve let me disable all observers on a model at once?
- The package operates at the model level, so muting a model suppresses the observers attached to it for the duration you choose. That is useful for bulk imports, seeders, and mass updates where per-row observer work would be prohibitively slow. If you need to skip only one specific observer, unregister or conditionally guard that observer instead of muting the whole model.
- Is monooso/unobserve useful for imports, seeders, and bulk operations?
- Yes, this is the primary use case. Disabling observers around a CSV import, database seeder, or large bulk update prevents thousands of observer callbacks from firing events, sending notifications, or writing audit rows that you do not want. Restore observation as soon as the batch finishes so normal application behaviour resumes. For very large jobs, combine this with chunking and queue the work so a failure mid-import does not leave observers muted.
- Do I need to restore observers manually after muting them?
- With the direct toggle form you restore observation yourself, so wrap the muted section in a try/finally block or use the callback-scoped form where the package restores state automatically. If an exception escapes while observers are muted and you never restore them, subsequent requests handled by the same long-running worker will silently skip observer side effects. Always prefer the scoped API in queue workers and Octane-style long-lived processes.
- Is monooso/unobserve safe to use in production?
- The runtime behaviour is simple and low risk, but the support policy is the real concern: v7 only supports the latest Laravel major, so each Laravel release will likely require a matching package major. Plan for a recurring upgrade cadence and assign an owner for any pinned older version. Also verify that your CI still enforces static analysis and tests, since the project removed its Scrutinizer integration and pre-push hook.
- How do I test code that mutes observers with unobserve?
- Use Event::fake or your observer's own mocks to assert which side effects did and did not fire while observation was disabled. Add a test that asserts observers are restored after the muted block, including the failure path where an exception is thrown. Running the suite on PHP 8.3 and Laravel 13 in CI will match the v7 support baseline; restore equivalent static-analysis and test gates if you were relying on the removed pre-push hook.
- What changed in v7.0.0 and should I upgrade from v6?
- Version 7.0.0 drops support for older Laravel majors in favour of Laravel 13 and PHP 8.3, switches formatting to Pint, and removes the Scrutinizer and pre-push quality gates. Only upgrade if your application is already on PHP 8.3 and Laravel 13, and do the framework upgrade first as a separate, reversible step. Teams on Laravel 10 to 12 should pin the latest compatible tag and record it as technical debt with a dated review rather than forcing an early platform upgrade.