- What is ivanmercedes/flex-fields and what problem does it solve?
- Flex Fields is a Laravel package, packaged as a Filament plugin, that lets administrators define dynamic entities and custom fields at runtime so you can ship products, employees, events, or other content types without writing a new migration for every schema change. Fields, field groups, repeaters, and visibility or validation rules are managed through Filament forms, tables, imports, and record history. It is aimed at CMS-style and admin-panel applications where the schema is expected to keep evolving.
- How do I install ivanmercedes/flex-fields in a Laravel app?
- Install it with Composer using composer require ivanmercedes/flex-fields, then follow the README to publish and run the package migrations and configuration and to register the plugin in your Filament panel provider. Because the package is pre-1.0, pin the exact version you test against and read the changelog before bumping. Verify the published assets and migration output in a staging environment first.
- Which Laravel, PHP, and Filament versions does flex-fields support?
- The package targets Laravel 10 or 11 and newer with Filament 3.x on PHP 8.2+, with MySQL or PostgreSQL as the usual backing stores. Confirm the exact support matrix and CI coverage in the repository before committing, since pre-1.0 releases can change requirements. Because the plugin is built on Filament, its upgrade risk tracks Filament's own release cadence, which has historically included breaking changes across majors.
- How do I add custom fields to an Eloquent model without writing a migration?
- You keep a conventional Eloquent model per record type and let the package define and store the extra fields at runtime, so adding a field is an admin action rather than a schema change. Values are persisted by the field engine instead of as columns on your model table. Because the data lives outside your table, plan up front for how exports, raw SQL reporting, and indexing on custom fields will work.
- What field types can I define with flex-fields?
- The package supports typed fields including text and formatted text, boolean, image, color, and repeaters with declared sub-field keys, along with per-field visibility and validation rules. Version 0.6.1 added table-column rendering for boolean, image, color, and formatted-text fields. Field definitions are editable at runtime, so the set of available types is a package concern rather than your application's migration history.
- Is it safe to upgrade flex-fields to 0.6.1, and does it break existing data?
- 0.6.1 is low-friction and largely additive: the repeater fix now reads and writes the declared sub-field keys and normalizes legacy ff_-prefixed data on read, which helps existing installs keep working. Existing records are not rewritten, so the read path and write path are not fully symmetric until you run a backfill job. Also check any custom table views that manually enumerated columns, since they may now double-render.
- How do I display custom fields as columns in a Filament table?
- Set the is_shown_in_list flag on a field definition and the package renders it as a table column, with searchability inherited from that field's searchable flag. In 0.6.1 this rendering covers boolean, image, color, and formatted-text fields. If you need row-level control, confirm whether the rendering respects your panel's authorization and role-based field visibility or is purely presentational.
- Can I use flex-fields for API ingestion and imports instead of only Filament forms?
- Yes, the 0.6.1 repeater fix makes the API, import, and AI-tool path explicitly viable, so headless ingestion workflows are supported in addition to manual admin entry. However, form rendering does not substitute for server-side validation of API payloads, so you need a parallel serialization and validation contract for any non-Filament client. Treat the field schema as shared configuration between the Filament UI and your API layer.
- How does validation work on dynamic custom fields?
- Validation rules are defined per field at runtime and applied when values are submitted through the package's Filament form components. Data that arrives via an API, an importer, or an artisan script does not automatically get those rules, so validate it against the stored field definitions yourself. Because the schema is defined at runtime, validation guarantees depend on package internals, which makes debugging a two-layer problem.
- Is flex-fields production ready, and how does it compare to alternatives?
- At version 0.6.1 the package is pre-1.0, so minor bumps may carry breaking changes and there is no long-term support guarantee; assess the maintainer posture and test coverage before relying on it in a critical system. A runtime field engine is effectively a schema inside a schema, so query performance, indexing, and sorting on custom fields all depend on package behavior at scale. If you do not need the Filament admin UI, simpler options such as JSON columns or spatie/laravel-schemaless-attributes may be lower risk, while the package's value is highest for teams already standardized on Filament.