- How do I install grazulex/laravel-snapshot in a Laravel app?
- Run composer require grazulex/laravel-snapshot. Laravel's package auto-discovery registers the service provider and facade, so no manual wiring is needed on Laravel 11 or 12. Publish the package config and migrations, then run php artisan migrate to create the snapshot table. After that you can capture your first snapshot from tinker or an Artisan command.
- What PHP and Laravel versions does laravel-snapshot require?
- Version 2.1.0 declares a hard minimum of PHP 8.4, while the 2.0.x line still supports PHP 8.3. The package is compatible with currently supported Laravel releases, including Laravel 11 and 12. If any of your environments run PHP 8.3, Composer resolution will fail up front rather than the package misbehaving at runtime.
- How do I take a snapshot of an Eloquent model?
- Add the package's trait to the model you want to version and call its snapshot method, or call the facade/API directly with the model instance. Each call stores the model's current attribute state as a point-in-time record. You can capture on demand, from model observers, or from a scheduled Artisan command. Check the README for the exact trait and method names in your installed version.
- Can I compare two snapshots and see what changed?
- Yes. Snapshots are stored as discrete records, so you can diff any two of them to see which attributes were added, changed, or removed. This is useful for auditing, debugging regressions, or reviewing what a record looked like before an edit. The package exposes this through its Eloquent-friendly API and Artisan commands rather than requiring raw queries.
- Can I restore a model to a previous snapshot?
- Yes, restoring is a first-class feature: the package ships Artisan commands and an API for writing a snapshot's values back onto the model. Treat a restore as a data-mutating operation and rehearse it in staging before using it in production. Note that a restore does not undo side effects such as queued jobs or notifications triggered by the original change.
- Why did composer update break my build with a PHP version error?
- Version 2.1.0 raised the minimum PHP version to 8.4 and shipped as a minor release, so a floating ^2.0 constraint will pull it on the next composer update and fail resolution on PHP 8.3 hosts. The good news is that the failure happens at install time rather than at runtime. Either move the affected environments to PHP 8.4 or pin the package below 2.1.0 until you can.
- How do I keep using laravel-snapshot on PHP 8.3 for now?
- Add a constraint such as grazulex/laravel-snapshot:^2.0 <2.1, or 2.0.*, to composer.json and commit the lockfile so CI and deploys stay on the 8.3-compatible line. Raising a platform floor in a minor release is a semver judgement call, so ask the maintainer whether 2.0.x will keep receiving fixes and for how long. Track an expiry date against that answer rather than leaving the pin open-ended.
- How should I test snapshot capture, diff and restore in my test suite?
- Use Laravel's normal test database tooling, such as RefreshDatabase, and assert against the snapshot records the package writes. Cover the paths you depend on: capture, compare/diff, and restore, including a model that uses casts and relations. Run the suite on PHP 8.4 in CI before you lift any version pin, so deprecation warnings surface ahead of production.
- Is laravel-snapshot safe to run in production, and how do I manage table growth?
- Every snapshot is a stored row, so write volume and table growth are the main production concerns. Snapshot only the models that genuinely need versioning, prune old records on a schedule, and index the columns you filter or diff on. For high-traffic writes, capture from queued jobs so the request path is not paying for the extra insert.
- How does laravel-snapshot compare to spatie/laravel-activitylog or owen-it/laravel-auditing?
- Spatie's laravel-activitylog and owen-it/laravel-auditing focus on logging changes as they happen, while laravel-snapshot focuses on point-in-time captures you can diff and restore. If you need a complete event audit trail, a logging package may be the better fit; if you need to answer what a record looked like at a specific moment and restore it, this package is the narrower tool. They can be combined, though that leaves you maintaining two sources of change history.