- How do I install alexstewartja/laravel-attribute-observer?
- Install it with composer require alexstewartja/laravel-attribute-observer. The package supports Laravel package discovery, so no manual service provider registration or config publishing is required. Integration is limited to Composer and your model classes; there are no migrations, schema changes, or configuration files to manage.
- Which Laravel versions does laravel-attribute-observer support?
- Version 1.8.0 is the release that adds Laravel 13 support, and the package targets modern Laravel applications on PHP 8.1 or newer. Before upgrading, check the composer.json diff to confirm the illuminate/support constraint was widened rather than replaced with a 13-only constraint, since a replacement would break Laravel 11 and 12 installs. If you are on an older framework major, stay on the matching 1.7.x release.
- How is this different from Laravel's built-in model observers?
- Laravel's built-in observers watch the whole model and fire on any create, update, or delete event. This package lets you attach an observer to a specific attribute, so logic runs only when that field actually changes. That keeps audit logging, notifications, and cache invalidation focused on the field they care about instead of guarding every model event.
- How do I register an attribute observer on an Eloquent model?
- You declare the observer on the model class using a PHP 8 attribute that references your observer class, rather than adding entries to a protected static $observers array or calling Model::observe() in a service provider. The observer class then contains the handler methods that react to the attribute change. This keeps the wiring next to the model where it is easy to see.
- Can I use attribute observers alongside the protected static $observers array?
- Both mechanisms hook into Eloquent's event dispatcher, so they can coexist, but you should confirm the precedence behavior for your version in the package's tests or source before relying on it. The recommended approach is to pick one convention per model to keep observer registration greppable and predictable. Mixing styles across a large codebase makes it harder to reason about which observers actually run.
- What PHP version does laravel-attribute-observer require?
- Because the package relies on PHP 8 attributes, the floor is PHP 8.1 or higher, though the exact constraint declared in 1.8.0 should be verified in composer.json. Confirm that 1.8.0 did not raise the minimum PHP version as part of the Laravel 13 support work. If your application still runs PHP 8.0, you cannot use this package.
- Why is my attribute observer not firing?
- The most common cause is a mistyped or unimported attribute class, which does not throw an error; the observer simply never registers. The failure then shows up as missing audit records, missed notifications, or absent cache invalidation, often in production rather than in tests. Double-check the fully qualified attribute name and add a test that asserts the observer's side effect.
- Does attribute-based observer registration add performance overhead at boot?
- Attribute registration typically requires reflection over model classes at boot or on first access, which is negligible with tens of models but worth measuring if you have hundreds. Laravel's config and route caching partially mitigates the cost. Benchmark your application's bootstrap time before and after adoption if you run a large domain model layer.
- How do I test attribute observers in my Laravel test suite?
- Observers registered this way run through Eloquent's normal event pipeline, so you can test them with the same techniques you use for conventional observers, including model event faking and asserting side effects after a save. Add a test that updates the watched attribute and asserts the observer's outcome, plus one that updates a different field and asserts nothing happens. That second test is your guard against the silent misregistration failure mode.
- Is it safe to upgrade to 1.8.0 and what if the package is abandoned?
- From 1.7.8 the upgrade should be a code-level no-op, but verify the composer.json diff first: a minor release that adds Laravel 13 support is safe only if the illuminate constraint was widened, not replaced. The package is a small, single-maintainer library with a low release cadence and has historically lagged framework majors, so plan for that at the next Laravel release. Because the surface area is tiny, vendoring or internalizing the code, or falling back to the standard $observers array or Model::observe() calls, is a realistic exit path.