Json Field Type Laravel Package

Getting Started

• Confirm you are on PyroCMS/Streams Platform. This is not a general Laravel JSON package; it is a field type addon. With 0 stars, 0 dependents, and a 2019 release, treat it as a small legacy addon and test before adopting.
• Install with Composer, verifying the package name in composer.json first:

composer require visiosoft/json-field_type

If the addon is not auto-discovered, install/register it through your PyroCMS addon workflow, e.g. php artisan addon:install visiosoft.field_type.json, or place it under your addons path.

• Look first at src/JsonFieldType.php, resources/views/, composer.json, and the README. The class name typically determines the field type slug: JsonFieldType becomes json.
• First use case: add a nullable JSON field to an existing stream for per-entry settings or metadata:

// Migration: prefer native json where supported, otherwise text
Schema::table('example_widgets', function (Blueprint $table) {
    $table->json('settings')->nullable(); // or $table->text('settings')->nullable()
});

// Stream definition
$stream->addField('settings', 'json', [
    'required' => false,
]);

Then edit the field in the control panel and read it from code/templates. Check whether the field type returns a raw JSON string or a decoded value before writing consumers.

Implementation Patterns

• Use it for flexible per-entry configuration: page layout options, widget settings, API response mocks, form schemas, or feature flags. This avoids creating many nullable columns for optional configuration.
• Template usage: if the field returns a raw string, decode in a presenter/accessor rather than relying on a Twig JSON-decode filter:

public function getSettingsAttribute($value)
{
    return json_decode($value, true) ?: [];
}

Then in Twig:

{{ entry.settings.theme|default('light') }}

• Model casting is convenient for ordinary Eloquent models:

protected $casts = ['settings' => 'array'];

Be careful with PyroCMS entry fields; if casting conflicts with Streams attributes, use a presenter or accessor instead.

• Validation: combine nullable with Laravel's json rule and normalize empty strings to null before validation:

$stream->addField('settings', 'json', [
    'rules' => ['nullable', 'json'],
]);

• Querying: use whereJsonContains() or settings->theme only when the database column is actually a native json type. For text columns, either query with LIKE sparingly or promote frequently filtered keys to real columns.
• Seeding/importing: always write json_encode($value), never a PHP array. Encode with JSON_THROW_ON_ERROR in your import scripts so bad data fails early.
• Reuse by subclassing the field type to change the input view, validation rules, or value accessor. Keep customization in your own addon rather than editing vendor code.

Gotchas and Tips

• Abandoned since 2019. Check compatibility against your PyroCMS/Streams/Laravel version before relying on it; do not assume Laravel 9/10/11 support.
• Field type slug collision: another addon may also register json. If the class slug conflicts, rename or namespace your own field type.
• Empty value ambiguity: '', null, '{}', and '[]' behave differently. Normalize empty input to null, and do not let an empty string reach a native json column.
• Admin UX is likely a plain textarea, not a structured JSON editor. Malformed JSON is the main day-to-day failure; add client-side validation or a custom input view if non-technical editors use it.
• Native json columns reject invalid JSON at the database level; text columns accept anything. Prefer json where MySQL/PostgreSQL supports it.
• Twig escaping: decode first, then output. Do not pipe untrusted JSON through |raw; when embedding into JavaScript, use json_encode.
• After install or schema changes, clear caches and recompile streams:

php artisan streams:compile
php artisan cache:clear

• Debug by dumping the raw attribute, e.g. $entry->getAttributes()['settings'], to determine whether the package returns a string or decoded array. This drives whether you need an accessor.
• Composer/autoload issues are common with old field type addons. Verify the addon is discovered, the service provider loads, and the field type appears in the control panel before debugging application code.
• Extension points: override $inputView, $rules, or getValue() in a subclass; override views only if the package supports publishing them. Keep patches out of vendor/ so upgrades or removal remain possible.