- How do I install and set up Engageify in a Laravel application?
- Install it with Composer (composer require cjmellor/engageify), then publish the package migrations using the engageify-migrations tag and run php artisan migrate. After that, add the relevant traits to the Eloquent models you want to make engageable and, where needed, to the model representing the user or actor. The package registers its own service provider, so no manual provider registration is required on supported Laravel versions.
- Which Laravel and PHP versions does Engageify 2.1.2 support?
- Engageify is a conventional Laravel package built around a service provider, publishable migrations, and Eloquent traits, so it follows standard Laravel version constraints. The exact Laravel and PHP floors for 2.1.2 are declared in the package composer.json on Packagist and should be checked before upgrading an older application. If your application is on an older Laravel release, treat the Composer constraint resolution as part of your upgrade test plan rather than assuming compatibility.
- Why did the Engageify migrations fail on MySQL in versions 2.0.0 to 2.1.1?
- Those releases could not create the engagement_counters table on MySQL at all, because the generated composite index name was 69 characters long against MySQL's 64-character identifier limit. Version 2.1.2 fixes this by giving the index an explicit, shorter name. Because no v2 release could ever be installed on MySQL before that fix, there is no historical counter data to back-fill or reconcile when you upgrade.
- Should I pin a minimum version of Engageify in composer.json?
- Yes. Require at least ^2.1.2, since a ^2.0 constraint can resolve to versions that simply cannot install on MySQL. Unless the maintainer has explicitly marked the broken 2.0.x to 2.1.1 releases as abandoned or broken on Packagist, wide constraint ranges remain a trap for anyone running MySQL. Pinning the floor is the cheapest safeguard you can put in place.
- Why is the engagements type column case-sensitive after upgrading to 2.1.2?
- The 2.1.2 release adds a pin_engagement_type_collation migration that sets the type column to utf8mb4_bin, which compares byte-exactly, so values are now case-sensitive on MySQL and MariaDB. Engageify itself writes and matches its enum values verbatim, so package behaviour is unaffected. However, any raw where clause on engagements.type, case-insensitive admin search, or warehouse export that normalises strings can silently stop matching, producing undercounts rather than errors.
- Can I use emoji or other backed enum values as engagement types?
- Engageify does allow backed-enum values, including emoji, to be stored as the indexed type column, and the 2.1.2 collation pin is what keeps distinct emoji from collapsing into the same counter row. That correctness guarantee lives in a column setting rather than in application code, so a future schema change, a manual ALTER, or a restore from a differently collated dump could quietly undo it. Corruption would show up as merged counters, not as a failed query, so verify the collation after any database-level operation.
- Is the Engageify migration safe to run on a large production table?
- The collation migration alters the type column in place on both the engagements and engagement_counters tables, which is trivial on a fresh install but requires a lock window on anything sizeable. Plan the deploy accordingly and test the timing against a production-sized copy first. Note also that the reversibility of the migration's down method is not documented, so take a backup before running it.
- How do I add likes, bookmarks, ratings, subscriptions and follows to an Eloquent model?
- Engageify ships traits that you attach to your models, giving you methods to like, bookmark, rate, subscribe to, and follow resources. Engagements are stored through polymorphic relationships, so the same traits work across any model without schema changes per resource type. Query scopes are included for querying engaged or engaging records, which keeps controller and Blade code short.
- How do the engagement counters and Hot and Top ranking work?
- Alongside the polymorphic engagement rows, Engageify maintains a denormalised engagement_counters table keyed by engagementable_type, engagementable_id, and type. That keeps aggregate counts cheap to read instead of requiring an aggregate query over every engagement row. The package builds its Hot and Top ranking scopes on top of those counters, so ranking stays a single indexed lookup per resource.
- How should I test my application against Engageify if the package CI only runs on SQLite?
- The package test suite runs on SQLite, and MySQL and MariaDB are absent from its CI matrix, which is why the two MySQL-only defects fixed in 2.1.2 were invisible to it. If MySQL is your primary engine, run the migrations and a handful of engagement and ranking assertions against MySQL in your own pipeline. Until upstream coverage changes, your application owns regression detection on that engine.