Streams Ckeditor Integration Extension Laravel Package

Getting Started

This is a Streams Platform (PyroCMS 3.x) addon that registers a CKEditor WYSIWYG option for the textarea field type. It is not a standalone editor package — it plugs CKEditor into the addon config slot that anomaly/field_type-textarea already exposes.

Prerequisites

• A working Streams Platform install (anomaly/streams-platform) on a compatible Laravel version.
• The standard anomaly/field_type-textarea field type, which is what actually stores the value.

Install

composer require anomaly/streams_ckeditor_integration-extension

# then install the addon (confirm the exact slug first)
php artisan addon:list
php artisan addon:install anomaly.extension.streams_ckeditor_integration

# publish assets and clear caches
php artisan addon:publish anomaly.extension.streams_ckeditor_integration
php artisan view:clear && php artisan cache:clear

Where to look first

• src/*Extension.php and src/*ServiceProvider.php — registration, asset bindings, view namespaces.
• resources/ — the CKEditor view/partial and the JS that initialises the editor.
• resources/config/ — any toolbar or asset configuration you can publish/override.
• composer.json — check the anomaly/streams-platform constraint; with 0 stars and 0 dependents, compatibility is your responsibility.

First use case

Open Streams → Fields, edit (or create) a textarea field, and look for the new Addon dropdown. Select ckeditor, assign the field to a stream, save, and open the entry form. That is the entire happy path — no code required.

If you prefer seeding it:

'body' => [
    'type'   => 'anomaly.field_type.textarea',
    'config' => [
        'addon' => 'ckeditor',
        'rows'  => 20,
    ],
],

Implementation Patterns

Declarative field config (recommended for repeatability)

Keep CKEditor selection in migrations/seeders rather than clicking through the UI, so fresh environments match production:

protected $fields = [
    'body' => [
        'type'   => 'anomaly.field_type.textarea',
        'config' => [
            'addon' => 'ckeditor',
            'rows'  => 25,
        ],
    ],
];

Per-field, not global

The addon setting lives on the field assignment, not on the addon itself. A stream can have three textareas where only one is CKEditor and the others stay as plain textareas — use that intentionally (e.g. short excerpts as plain textareas, long body copy as CKEditor).

Rendering stored HTML

The textarea field stores the raw HTML string. Render it explicitly:

{# Pyro/Twig #}
{{ entry.body.render|raw }}

Do not assume the field type sanitises. Treat the output as untrusted user HTML (see Gotchas).

Form integration

Anywhere you use Streams form builders ({{ form('entries').fields(...) }} or the FormBuilder), the field type handles the editor automatically once the addon is set. You do not need to manually enqueue CKEditor assets in your own layouts.

Extending the toolbar

If the package exposes a view/partial for the editor init (check resources/views), copy it into your own extension and override the view namespace — this is the cleanest way to add/remove toolbar buttons without patching vendor code. If only a config file is exposed, publish it and adjust there.

Asset strategy

The editor JS is served from the published addon assets directory. In deployments, make sure public/addons/ is part of your build artifact or re-run addon:publish during deploy; otherwise the editor silently fails to initialise.

Gotchas and Tips

• Very low adoption signal. 0 stars and 0 dependents means almost no community validation. Pin the version in composer.json, test against your exact Streams/Laravel combination, and be ready to fork if an upstream API changes.
• Confirm the addon slug before installing. The Composer package name (anomaly/streams_ckeditor_integration-extension) and the Streams addon namespace (anomaly.extension.streams_ckeditor_integration) are not always identical. php artisan addon:list is the source of truth.
• Assets not loading = cache problem, usually. If the textarea renders as a plain box, check the browser console for 404s on addons/.../ckeditor*.js, then run addon:publish, view:clear, and cache:clear in that order.
• XSS risk on render. CKEditor output is full HTML. If you render with |raw, pipe it through a sanitiser (HTMLPurifier or an equivalent allowlist) before output, especially for user-submitted streams.
• No built-in file/image uploads. CKEditor's image/file browser needs a backend endpoint and CSRF-safe upload adapter. The extension generally does not provide one — wire your own controller or configure CKEditor's upload adapter.
• Changing a field's addon after data exists is safe at the storage level (still a string column) but will change the editing UX; existing HTML pasted from another editor may look odd. Plan the switch during content migration, not mid-flight.
• Debugging tip: view-source the rendered form and confirm the textarea carries the expected data-addon="ckeditor" / addon class. If the attribute is present but the editor doesn't mount, the problem is JS/asset loading, not config.
• Extension point: if the toolbar config isn't configurable via published config, your cleanest override is the view partial in resources/views. Avoid editing vendor files directly — a composer update will erase them.
• Keep a plain-textarea fallback in the field's config docs for non-technical editors; CKEditor can paste in markup that breaks tightly-styled front-end layouts, and there is no server-side cleanup in this package.