- How do I install overtrue/laravel-like in a Laravel application?
- Install it with Composer using composer require overtrue/laravel-like:^6.0, then publish and run the package migration. Add the Likeable trait to models that can be liked and the Liker trait to your user model. No service provider registration or extra infrastructure is required. After that you can call like(), unlike(), toggleLike(), and hasLiked() directly on your models.
- Which Laravel and PHP versions does overtrue/laravel-like v6 support?
- Version 6.0.0 targets Laravel 13 and requires PHP 8.3 or newer. The Laravel constraint is exclusive rather than a range, so applications on Laravel 10, 11, or 12 must stay on the 5.4.x line. Check your CI images and container base images for PHP 8.3 before bumping the dependency, or Composer will fail at the platform check.
- How do I make an Eloquent model likeable?
- Add the Likeable trait to any Eloquent model that should receive likes, which exposes a polymorphic likes() relationship. Add the Liker trait to the model representing your user, typically App\Models\User. Once both traits are in place, the fluent helpers like(), unlike(), toggleLike(), and hasLiked() are available. The traits compose with existing models and require no schema changes beyond the package's own likes table.
- Can a user like different types of models with one package?
- Yes. Likes are stored through a polymorphic relationship, so a single user can like posts, comments, videos, or any other Eloquent model that uses the Likeable trait. Each like record stores the liked model's type and ID, so one likes table serves every likeable entity. This avoids creating separate pivot tables for each model type.
- How do I check whether a user has already liked a model?
- Call hasLiked() on the user for the target model, for example $user->hasLiked($post), which returns a boolean based on the polymorphic likes() relation. The method is part of the Liker trait and works for any model using the Likeable trait. Use it to set button states or guard against duplicate like actions. For lists, use the package's query scopes or eager-load the likes relation to avoid per-row queries.
- How do I count likes or filter models by like status?
- The Likeable trait exposes a likes() relationship, so standard Eloquent counting applies, such as $post->likes()->count(). The package also ships query scopes for filtering by like status and like counts, letting you build lists such as most-liked posts. Because likes are polymorphic, the same scopes work across all likeable models. For high-traffic pages, consider caching counts rather than running aggregate queries on every request.
- How do I publish the migrations and configuration for laravel-like?
- The package ships with its own migration and a publishable config file, config/laravel-like.php. Publish the migration with the vendor:publish command and run php artisan migrate to create the likes table. If you customize table names or the Like model, publish the config as well and re-test those overrides after every major upgrade. Version 6.0.0 is a support-matrix release with no expected schema change, but diff the published stub against your existing migration before deploying.
- Can I upgrade overtrue/laravel-like from v5 to v6 without upgrading Laravel?
- No. Version 6 pins to Laravel 13, so upgrading the package alone is not possible on Laravel 10, 11, or 12. Either stay on ^5.4 and pin it explicitly in composer.json, or complete your Laravel 13 upgrade first. Avoid widening the constraint to ^5.4 || ^6.0 unless you are prepared to test both branches. Once you move to v6, returning to v5 requires downgrading Laravel, so treat the change as one-way.
- Can I customize the Like model, table name, or traits?
- The package provides a publishable config file, config/laravel-like.php, where table and model customizations are typically registered. If you override the trait, model, or migration, those overrides are the most likely source of silent breakage when moving to a new major version. Re-run like, unlike, and hasLiked() regression tests against your customizations before shipping the upgrade. Also verify whether your published migration is byte-identical to the vendor stub rather than trusting the changelog.
- Is overtrue/laravel-like safe to use in production?
- It is a small, single-purpose package with full test coverage and a low architectural footprint: a trait, a model, and one migration, with no queues, caches, or external services. The main production concern is maintenance cadence, since it is a single-maintainer project and v6 pins to exactly one Laravel major, creating an upgrade every Laravel cycle. Pin ^6.0, commit composer.lock, and schedule the bump as part of your Laravel upgrade sweep rather than a standalone change. Confirm the maintainer's security-backport policy for the 5.4.x branch if you cannot move to Laravel 13 soon.