Streams Ckeditor Integration Extension Laravel Package

Technical Evaluation

Architecture fit

• This is not a general-purpose Laravel package. It is a Streams Platform addon (PyroCMS 3.x lineage, anomalylabs/*) that registers a new field type into the Streams field-type registry.
• Fit is binary: if the target system is a PyroCMS 3 / Streams Platform application, it slots into the existing addon + assignment + field type architecture (service provider registers the field type class, views, and publishable CKEditor assets). If the target is vanilla Laravel, Lumen, Filament, Nova, or a modern CMS, there is no integration surface — it cannot be adapted without effectively rewriting it.
• Functionally it is a thin wrapper: a FieldType subclass, an options view (toolbar/config), a service provider, and a vendored CKEditor bundle. There is no business logic worth inheriting.

Integration feasibility

• Feasible on a legacy stack only: composer install → enable addon in config/addons.php (or addon scan) → publish assets → assign the field type to a stream in the admin. No database migrations of substance.
• Blockers a TPM should expect to surface immediately:
  • Composer constraints almost certainly pin Laravel 5.x / PHP 7.x, which will conflict with PHP 8+ and Laravel 9+ dependency trees.
  • The addon depends on anomaly/streams_platform_extension-era APIs that were renamed and later closed-source when PyroCMS went commercial; upstream coordination is no longer possible.
  • No test suite, no CI, no README depth beyond install steps — every integration question becomes an internal investigation.

Technical risk

• Abandonment risk: critical. 0 stars, 0 dependents, no maintainer activity signal. Anomaly Labs wound down; the parent ecosystem is effectively frozen.
• Security risk: high. The bundled CKEditor is a pre-v5 build (CKEditor 4 reached end-of-life and carries known XSS/HTML-sanitization CVEs). Vendored JS assets are invisible to Composer audit and Dependabot.
• Licensing risk: low, but verify (Anomaly packages are typically MIT) — the vendored CKEditor bundle has its own GPL/LGPL/MPL tri-license terms that must be tracked separately.
• Supply-chain risk: moderate. Pulling an unmaintained, zero-audit package into a production CMS admin surface is a poor trade versus writing ~150 lines of field-type code yourself.
• Redundancy risk: high. The Streams Platform already ships a WYSIWYG field type in the core/anomaly/wysiwyg-field_type package. Confirm whether this extension adds anything (custom toolbar? alternate CKEditor version?) or is simply a duplicate — in many cases the answer is "duplicate."

Key questions to resolve before commitment

1. Which CKEditor major version is bundled, and is it still receiving security patches?
2. Does the existing Streams WYSIWYG field type already cover the requirement? What is the delta?
3. What are the exact composer.json constraints (PHP, Laravel, streams platform)?
4. What is the license of the addon and of the bundled CKEditor assets?
5. Is server-side HTML sanitization handled anywhere, or does the field type trust client input verbatim (stored XSS exposure in admin-rendered content)?
6. Who is the named internal owner of the fork if we proceed?
7. Is there any requirement (regulatory, accessibility, browser support) that a modern editor is needed anyway — making a legacy CKEditor wrapper moot?

TPM verdict: Score 0.03 and zero dependents is a correct signal. Default position is do not adopt; the package only becomes rational as a forked, vendored, security-reviewed artifact inside an already-committed PyroCMS 3 estate, and even then only if the built-in WYSIWYG field type genuinely falls short.

Integration Approach

Stack fit

• Compatible target: PyroCMS 3.x / Streams Platform, Laravel 5.4–5.8, PHP 7.0–7.4, MySQL 5.7. Anything newer is a fork-and-port exercise, not an integration.
• Not compatible with Laravel 9/10/11, PHP 8.1+, or headless/API-only deployments where the admin UI is not part of the product.

Migration path (if we proceed)

1. Fork and vendor the repository into an internal namespace (e.g. internal/streams-ckeditor-field-type) rather than depending on the public package. This is the single most important step — it converts an unmaintained dependency into owned code.
2. Update composer.json constraints to the application's PHP/Laravel versions; run composer why-not and composer update --dry-run to expose conflicts early.
3. Replace the bundled CKEditor 4 assets with a maintained editor (CKEditor 5 build, TinyMCE 6+, or Tiptap) behind the same field-type contract; keep the field type's storage contract (plain text column) unchanged so existing content remains readable.
4. Register the addon in config/addons.php, publish assets as part of the deploy pipeline (not manually), and add the field type assignment in a seeded migration so environments are reproducible.
5. Add a sanitization layer (e.g. HTMLPurifier or an allow-list sanitizer) at render time, independent of editor output.

Compatibility and sequencing

• Sequence: (a) confirm core WYSIWYG gap → (b) fork + PHP/Laravel compatibility spike (2–3 days) → (c) editor replacement + sanitization (3–5 days) → (d) deploy-pipeline asset publishing → (e) QA across stream assignments.
• Do not sequence this before an upgrade decision. If there is any active plan to move off PyroCMS/Streams, this work is throwaway and should be scoped as a stopgap with a defined sunset date.
• Asset publishing must be idempotent and run at container build time; a container-per-deploy model will 404 the editor if assets are published only once on a developer machine.

Operational Impact

Maintenance

• Effective maintenance burden is 100% internal from day one. Budget a named owner and ~1–2 engineer-days per quarter for editor/security patching alone, plus the cost of periodic PHP/Laravel compatibility reviews.
• Dependabot/Snyk will not see vendored CKEditor JS. Add a manual or scripted scan of published assets to the security calendar.
• Keep the fork close to upstream's last commit in a single branch with all changes documented, so a future maintainer can diff intent from noise.

Support

• No upstream support channel, no issue triage, no roadmap. Every defect is an internal ticket.
• Ramp-up for a developer already fluent in Streams field types is low (half a day); for a team new to PyroCMS it's 2–3 days to become productive, mostly in learning the addon registration and field-type lifecycle rather than this package's code.
• Requires an internal runbook covering: addon enable/disable, asset republish, editor config changes, and sanitization policy.

Scaling

• Low operational footprint: static JS/CSS assets served from the public directory (CDN-friendly), no server-side processing cost beyond rendering the textarea, and content stored as a plain text column — no schema surprises.
• Horizontal scaling is fine provided asset publishing happens at build time; multi-node deployments with per-node manual publishing is the primary scaling failure mode.
• No queue, cron, or external service dependency, which is genuinely the package's strongest operational property.

Failure modes

Recommendation and effort

• Default: reject. Do not add a zero-adoption, abandoned, EOL-editor wrapper to a production dependency graph.
• If the PyroCMS estate must be supported: fork, replace the editor, add sanitization, and publish assets in CI — roughly 5–8 engineer-days for a developer familiar with the platform, plus ongoing ownership.
• Preferred alternative: implement a minimal custom Streams field type in-house (one FieldType class, one options view, one service provider, one asset registration) around a maintained editor. Comparable effort, materially lower risk, and the code is understood by the team from day one. Present this as the recommended path in the decision record, with the fork as a fallback if timeline pressure dominates.