Editor Field Type Laravel Package

Getting Started

This is a Streams Platform field type addon for Anomaly/PyroCMS — not a standalone Laravel package. It only makes sense inside an Anomaly install, so verify that first:

composer require anomaly/streams-platform anomaly/editor-field_type
php artisan addon:install anomaly.field_type.editor

The addon is auto-registered by the Streams Platform addon service provider; no manual service provider edits are needed. If the field type doesn't appear in the admin dropdown, re-run php artisan addon:install and check storage/streams/{app}/addons/addons.php.

Where to look first:

• src/EditorFieldType.php — the field type definition (slug, inputView, outputView, form/table column modifiers)
• resources/views/input.twig / output.twig — what the user actually interacts with
• resources/config/settings.php — available per-field config knobs
• src/EditorFieldTypePresenter.php — output helpers exposed in Twig/Blade

First use case — add a rich-text "Body" field to an existing stream via an assignment. In the admin UI: Content → Streams → {Stream} → Assignments → + New Field → Editor. Or programmatically in a migration:

Schema::create('default_pages_fields', function (Blueprint $table) { /* ... */ });

\Anomaly\Streams\Platform\Database\Migration\Migration::class; // ...
// in the migration's `$fields`:
protected $fields = [
    'body' => [
        'type'   => 'anomaly.field_type.editor',
        'config' => [
            'height'   => 300,
            'line_breaks' => false,
            'remove_buttons' => ['source'],
        ],
    ],
];

Once assigned, the field is available as $entry->body (rendered HTML) in templates.

Implementation Patterns

Define fields declaratively in migrations. Prefer $fields + $assignments in a StreamsMigration so environments stay in sync. Treat the editor field like any other: it stores plain HTML/text in its own column, so no post-processing is required to render it.

Per-assignment configuration. Editor appearance should live in the assignment config (height, toolbar, plugins, line breaks), not in a single global default. Each stream can then use a lightweight inline editor for a "Summary" field and a full editor for a "Body" field.

Render-safe output pattern. Because the field stores raw HTML authored in a WYSIWYG, render it deliberately:

{{ entry.body|raw }}

In Blade:

{!! $entry->body !!}

For structured output (e.g. stripping tags for meta descriptions), use the presenter:

{{ entry.body.presenter().strip_tags() }}

Form integration. In custom form classes, reference the field by assignment like any other field:

$form->add('body', 'anomaly.field_type.editor', [
    'config' => ['height' => 400],
]);

The field type provides its own input.twig, so you rarely need to author a custom view — pass overrides through the input_view config if you do.

Pair with a text field for plain-text variants. A common day-to-day pattern is to expose body (editor) alongside a hidden/derived body_text populated with strip_tags, keeping search and APIs consistent.

Use assignments for content reuse. Because the field type is standard, you can share a "body" field across page, post, and article streams via a single assignment, then reuse a shared partial to render them.

Gotchas and Tips

• Not a Laravel package. It won't work standalone. composer require outside an Anomaly install will install but do nothing. The anomaly/streams-platform dependency is mandatory.
• Column size. Editor content is stored as text — for long articles or embedded markup, use LONGTEXT/MEDIUMTEXT in the migration to avoid truncation, otherwise you'll see silent cut-offs at ~64KB.
• XSS by design. The editor outputs HTML verbatim. If untrusted users submit content, sanitize on output (htmlpurifier / HTMLPurifier middleware or a presenter) — don't rely on the toolbar to block anything.
• Asset publishing. The addon ships its own JS/CSS. If the editor renders as a plain <textarea>, the addon assets weren't published; run php artisan addon:publish anomaly.field_type.editor or check that public/addons/default/anomaly/editor-field_type/ exists.
• CKEditor/Redactor version pinning. Editor config options are forwarded to the underlying editor. Options valid in one version are silently ignored in another — check the version bundled in resources/js/ before chasing a config bug.
• Height config expects pixels. height => '100%' works in some versions but is unreliable; prefer an integer.
• line_breaks vs paragraphs. Switching this after content exists changes rendering output but not stored data. Document the setting if you change it in production.
• View overrides. Override input.twig/output.twig per project via resources/views/vendor/... or the admin "Addon customization" feature rather than forking the package — forks fall out of sync on update.
• Zero stars / no recent activity. Treat version pinning as your friend: pin to a specific commit/tag in composer.json and be ready to patch the editor skin yourself. The addon is a thin wrapper, so if it goes stale, extracting its 50–100 lines of input view into a private field type is often faster than debugging it.
• Debugging. Enable APP_DEBUG=true and check storage/logs/laravel.log; the field type rarely logs, so failed saves usually show as the assignment not appearing at all — start with the addon registration file, not the editor JS.