visiosoft/list-field_type
Visiosoft list-field_type is a Laravel/PHP field type addon that adds list fields to Visiosoft forms and entries, making it easy to define, store, and display multiple values in a simple ordered list within Streams-based admin interfaces.
This is not a general-purpose Laravel package — it is a Streams Platform field type addon (PyroCMS / OpenClassify lineage). It only makes sense inside an app that already has anomaly/streams-platform installed.
Install:
composer require visiosoft/list-field_type
Laravel's auto-discovery should register Visiosoft\ListFieldType\ListFieldTypeServiceProvider (confirm in the addon's composer.json extra.laravel.providers). On older 5.x apps you'll need to register it manually.
Confirm the addon is visible:
php artisan addon:list
You should see visiosoft.field_type.list.
Look first at (in the vendor package):
src/ListFieldType.php — the $view property and getOptions()/getConfig(); this is the whole behavior.resources/views/ — the input.blade.php that renders the <select>.src/ListFieldTypeServiceProvider.php — bindings, view namespace, any singleton overrides.First use case — a status dropdown on a Stream:
$stream->addField('status', [
'type' => 'list',
'config' => [
'options' => [
'active' => 'Active',
'inactive' => 'Inactive',
],
],
]);
Or through the admin UI: Content → Fields → Create, choose type List, supply key: label pairs, then assign the field to a Stream via a Field Assignment.
Options live in field config. The only supported shape is a flat key => label map. Store it in one place (a config file, a dedicated ListFieldOptions class, or a constants file) and reference it from migrations, so you don't drift between environments.
Store keys, render labels yourself. {{ $entry->status }} returns the stored key (active), not Active. To display a label you either:
$label = $field->getOptions()[$entry->status] ?? $entry->status;
or attach a Streams presenter / accessor that resolves the label at render time. Keep keys stable (slug or integer); renaming a label is safe, renaming a key silently invalidates existing rows.
Migrations + seeders. Define the field once in a migration, then use a seeder or an admin-driven config to populate/refresh options. Re-running streams:compile is part of the deploy loop (see Gotchas).
Querying. Because the key is stored raw, normal Eloquent works:
$entries = $repo->newQuery()->where('status', 'active')->get();
Overriding the input view. Publish the addon's views into your app and edit the blade to add class, wire:model, optgroups, or trans() wrapping:
php artisan addon:publish visiosoft.field_type.list
Then edit resources/views/visiosoft/field_type/list/input.blade.php.
Reuse via extension. If your options need to come from a table (enums, lookup rows), subclass the field type, override getOptions(), and register the subclass instead of the vendor class. This is the cleanest extension point since the package itself has no abstraction.
Pair with Streams Form Builders to use the field type inside user-facing forms, not just admin:
$builder->add('status', 'list', ['config' => ['options' => $options]])
The same view renders, so your published override applies everywhere.
anomaly/streams-platform constraints, and be prepared to fork it if a platform upgrade breaks it. It's small enough that forking in-place is often faster than hunting upstream.addon:list doesn't show it, the service provider never ran — check composer.json discovery and clear bootstrap/cache/packages.php.options = empty <select>. There's no built-in fallback. If options are missing (typo in config key, migration ordering), the form silently renders nothing usable. Add a migration guard or a validation step.list vs select slug collision. Streams ships an official anomaly/select-field_type with richer behavior (allow_empty, searchable, multi-select). This package's list is deliberately minimal — do not assume it supports multiple, placeholder, or optgroups. If you need those, use select instead; mixing both in one app is a source of confusion.{{ entry.status }} printing the key. Fix it in the view layer (or a presenter), not by "fixing" the field type.php artisan streams:compile
php artisan cache:clear
php artisan view:clear
Field assignments and option config are cached; this eats hours of debugging if you don't know it.dd($field->getConfig(), $field->getOptions()) into the published input view. Streams reads config through magic __get, so guessing key names is unreliable; the config is stored as JSON on the field record.trans() in your published blade, or map them through a presenter. There is no built-in translation mechanism for option labels.rules entry on the field assignment (e.g., in:active,inactive) if you care about data integrity; the field type alone won't reject an unexpected key on manual submission.getOptions() (source of options), $view (rendering), and the input.blade.php (markup) are the three knobs. There is no plugin API beyond them.How can I help you explore Laravel packages today?