- How do I install zachleigh/laravel-property-bag?
- Install it with composer require zachleigh/laravel-property-bag on a project that matches its original constraints, then run the migration shipped with the package to create the polymorphic properties side table. The package auto-registers its service provider on supported Laravel versions. Note that the repository is archived with a final release in January 2020, so on modern Laravel you will need to fork and vendor the code rather than pulling it straight from Packagist. Check the package source for the exact trait and namespace names before wiring it into a model.
- Which Laravel and PHP versions does zachleigh/laravel-property-bag support?
- The final release dates from January 2020, which places it in the Laravel 5.5 through 6.x era. Its illuminate/* Composer constraints will almost certainly refuse installation on Laravel 9, 10 or 11, and the code has not been exercised against PHP 8.x. Treat the published support matrix as Laravel 5.5-6.x on PHP 7.x only.
- Does zachleigh/laravel-property-bag work with Laravel 10 or 11?
- Not out of the box. Composer will block installation because the illuminate/* version constraints predate Laravel 9. The realistic path is to fork the repository under your own namespace, loosen the constraints, and vendor it as first-party code. The surface area is small, just a trait, a couple of value and collection classes, and one migration, so taking ownership is a matter of days rather than weeks.
- How do I add custom settings to an Eloquent model with this package?
- You add the package trait to any Eloquent model and run its migration, which creates a single polymorphic table holding key/value rows linked to the model. After that you can set, get and manage arbitrary properties through the trait's helper methods without touching the model's own schema. Because values live in a side table rather than a JSON column on the model, no per-entity migrations or nullable settings columns are needed.
- Can I query, filter or order models by a property value?
- You can, but you should not rely on it. Every such query becomes a join against a key/value side table plus a string comparison, which defeats normal indexing and gets slower as the table grows. If a setting must be used in WHERE, ORDER BY, JOIN or aggregate clauses, promote it to a real indexed column or a native JSON column with a generated index instead. This package fits sparse, read-mostly values that you load for a model you already have.
- Why am I getting N+1 queries when loading many models with properties?
- The properties relationship is lazy-loaded, so iterating a collection and reading a setting per model fires one query per model. Eager-load the relationship on the consuming models so the whole set is fetched in a single additional query, and add a request-scoped cache if settings are read on hot paths. Because the data lives in a side table, this is the most common performance pitfall with the package.
- How do I stop properties from showing up in JSON API responses?
- The relationship is a normal Eloquent relation, so it can leak into toArray() output and anything you add to $appends. Explicitly add the relationship to the model's $hidden array and never append it, and exclude it from any resource or transformer you use. If settings can contain secrets, encrypt them at rest and make sure they never reach serialization at all.
- Are property values type-safe with this package?
- Values are stored as strings in a key/value table, so booleans, integers and nulls drift unless you handle casting yourself. Define cast metadata per key and cover it with contract tests so a value written as true does not come back as the string "true". Without a typed accessor layer, the bag behaves like an untyped shadow schema.
- What are the alternatives to zachleigh/laravel-property-bag?
- For per-model settings, a native JSON column with a typed cast and accessor often covers the same ground without an extra table or a dependency. Deploy-scoped values belong in config/, and if you want a maintained settings package, spatie/laravel-settings is a common choice. Since this package is archived, forking and vendoring it is effectively choosing to maintain it yourself.
- Is zachleigh/laravel-property-bag safe to use in production?
- The repository is archived, so there will be no security or framework-compatibility patches from upstream, which is a medium-likelihood, medium-impact risk. If you adopt it, fork it under your organisation's namespace, pin the version, add it to your dependency review queue and document a key registry with an owner per key. Also plan for table growth, orphan rows on model delete, and transactions around multi-key writes, because none of that governance comes built in.