- How do I install overtrue/laravel-vote in a Laravel application?
- Install it with composer require overtrue/laravel-vote, then publish and run the package migrations to create the votes table. There is essentially no configuration surface: the service provider is auto-discovered and the table uses polymorphic votable columns plus a voter foreign key. After migrating, add the votable trait to the models that should receive votes and the voter trait to your User model.
- Which Laravel and PHP versions does overtrue/laravel-vote support?
- Version 4.x requires PHP 8.2 to 8.4 and Laravel 10.x through 13.x, and CI is run against PHP 8.2, 8.3 and 8.4. Version 4.0.0 dropped PHP 8.0/8.1 and Laravel 9 support, so Composer will refuse to resolve if any service using the package is still below that platform floor. Treat the advertised Laravel 13 support as maintainer intent rather than as evidence you should plan a Laravel 13 migration around it. If you need Laravel 9 or older PHP, stay on the 3.x branch.
- How do I make an Eloquent model votable with laravel-vote?
- Add the package's votable trait to any Eloquent model that should collect votes; it sets up a polymorphic morphMany relationship to the Vote model. Because the relationship is polymorphic, the same votes table serves posts, comments, products, or any other model without schema changes. You can attach the trait to as many models as you like, and each one gets its own independent vote set.
- How do I let users vote on models using overtrue/laravel-vote?
- Apply the voter trait to your User model, or to any other model that should act as a voter. The trait wires up the inverse polymorphic relationship to votes and exposes upvote and downvote helpers so you can call them directly from a controller or service. Because the voter side is a trait as well, you can support multiple voter types, such as users and teams, in the same application.
- How do I get the total vote count or score for a model in laravel-vote?
- The package exposes vote totals through the votable relationship, so you can sum the stored vote values for a given model to get a score rather than just a raw count. You can either query the relationship or eager load votes to avoid N+1 queries when listing many models. For ranked listings, aggregate the votes in the database query rather than in PHP so sorting and pagination stay efficient.
- Does overtrue/laravel-vote support weighted votes, vote reasons, or custom vote types?
- The package is deliberately thin and centres on upvote and downvote semantics with a small votes table, so weighted voting, vote reasons, and audit history are not features it ships. If you need those, the practical path is to extend the Vote model or add your own columns via a migration, accepting that you now own that customisation. If weighted or auditable voting is core to your domain, evaluate whether a bespoke implementation fits better than extending this package.
- How do I upgrade overtrue/laravel-vote from 3.x to 4.0?
- Bump the constraint to ^4.0 and run your full test suite; the 4.0.0 release is a platform-floor and tooling release with no functional API changes, so application code changes should be zero or near zero. The real work is the platform track: PHP 8.2+ and Laravel 10+, including dependency resolution and deprecation cleanup independent of this package. Also search your codebase for pinned ^3.4 constraints that would silently keep you on an unsupported branch.
- How do I test voting behaviour in a Laravel test suite with laravel-vote?
- Use RefreshDatabase so the votes table is migrated for each test, then create voters and votable models with factories and assert against the votes table with assertDatabaseHas. Asserting on persisted rows is more reliable than asserting on relationship caches, which can go stale after a vote is cast. If you extend the Vote model with custom columns, cover those cases explicitly since the package itself will not validate them.
- Is overtrue/laravel-vote actively maintained and safe to use in production?
- It is a single-maintainer package in maintenance mode: the changelog is dominated by CI and code-style housekeeping, and 4.0.0 contains no bug fixes, API additions, or security patches. That is low regression risk but also means an upgrade buys continued update eligibility rather than new capability. For production, decide whether vote data is business-critical; if it is, keep a fork or vendor patch plan in place given the bus-factor risk.
- What are the alternatives to overtrue/laravel-vote for adding voting to Laravel?
- Common alternatives include rtconner/laravel-likeable and cyrildewit/eloquent-voteable, both of which offer comparable polymorphic like or vote traits for Eloquent models. For simple requirements, a small custom votes table with a polymorphic relationship is often less risk than any dependency, especially if you need weighted votes or audit history. Compare on Laravel and PHP version support, maintenance activity, and whether the data model matches your ranking needs before choosing.