Weave Code
Laravel Custom Fields Laravel Package
asseco-voice/laravel-custom-fields
Extend Laravel Eloquent models with user-defined custom fields, no schema changes needed. Define fields per model, store values flexibly, and use them in forms, validation, and queries—a simple way to let apps add their own attributes dynamically.
Extensible Laravel models without the need for additional database attributes
Frequently asked questions about Laravel Custom Fields
- What is asseco-voice/laravel-custom-fields used for?
- It lets you add user-defined custom fields to Laravel Eloquent models without adding columns to your existing tables. Field definitions are stored per model, and values are kept in a companion table so applications can add attributes dynamically. Typical uses are admin-defined metadata, optional form fields, and per-tenant or per-record extensions. The package fits sparse, low-change metadata better than fields that need heavy filtering or reporting.
- How do I install and set up laravel-custom-fields?
- Install it with Composer using composer require asseco-voice/laravel-custom-fields. Laravel auto-discovery registers the service provider; publish the package config and migrations, then run php artisan migrate. Add the package trait to each Eloquent model that should expose custom fields. A first vertical slice is usually doable in under a day for a mid-level Laravel developer.
- Which Laravel and PHP versions does laravel-custom-fields support?
- The v3.3.1 evaluation did not verify the exact Laravel and PHP version matrix, so check the package composer.json constraints before adopting it. Also confirm that the supported matrix is enforced in CI rather than only declared. This matters most if you are on older Laravel versions or plan to upgrade Laravel soon. Pin a tested version instead of assuming broad compatibility.
- How does laravel-custom-fields store custom field data without schema changes?
- The package uses an entity-attribute-value pattern: field definitions live in a custom_fields table and values live in a companion table keyed to the owning model. That means adding new custom attributes does not require altering your domain tables. It is appropriate for sparse, admin-defined metadata. It is a poor fit for fields that need heavy filtering, sorting, or reporting unless you add careful indexing and query design.
- What is the renderer column in v3.3.1 and does it affect my app?
- Version 3.3.1 adds a renderer column to the custom_fields table, likely to describe how a field should be drawn in a UI. The evaluation did not verify whether it is nullable with a default or how null and unrecognized values are handled. Treat renderer as presentation metadata and define an allowed contract rather than free-text values. Test fallback behavior before relying on it across admin and consumer surfaces.
- Do I need to publish migrations for laravel-custom-fields?
- If you published the package migrations into database/migrations, the new v3.3.1 column will not arrive automatically. Diff the package migration directory against your project-owned migrations after upgrading. Then create a project migration that adds the renderer column if needed. This published-migration drift is the most likely upgrade failure mode.
- How should I upgrade an existing install to laravel-custom-fields v3.3.1?
- Pin or bump explicitly to ^3.3.1 rather than floating on ^3.0, then diff the package migrations against your published migrations. Add any missing column, such as renderer, in a project-owned migration and run migrations before deploying code that expects it. Test form rendering and data writes with null and unknown renderer values. Treat the change as additive and forward-only.
- Is laravel-custom-fields a good fit for filtering, sorting, or reporting?
- Because values are stored in a companion table, watch for N+1 queries when listing many models with custom fields. The evaluation flags index strategy for model_type/model_id and field key as an open question, and eager loading support is unverified. For heavy filtering, sorting, or reporting, EAV storage can become slow and complex. Measure with realistic data before using it for high-traffic query paths.
- What happens to custom field values when the owning model is deleted?
- The provided context does not document what happens to custom field values when the owning model is deleted. Check the package migrations for foreign keys or cascade behavior, and test deletion in a throwaway environment. If cleanup is not automatic, add an observer or scheduled cleanup to avoid orphaned values. This is especially important for business-critical metadata.
- What are alternatives to laravel-custom-fields and what maintenance risks should I consider?
- Alternatives include storing optional attributes in JSON columns, building a dedicated EAV layer, or using a more actively maintained custom-fields package. This package is a simple fit for sparse admin-defined metadata, but it appears to be a single-maintainer, low-cadence dependency. A patch release that changes table structure means you should pin versions and run migrations deliberately. Treat supply-chain and bus-factor risk as manageable but real for metadata you cannot easily lose.
Weaver
How can I help you explore Laravel packages today?