Wysiwyg Field Type Laravel Package

Technical Evaluation

What this package actually is. anomaly/wysiwyg-field_type is not a standalone Laravel package — it is a PyroCMS 3 addon that plugs into the anomaly/streams-platform field-type registry. It contributes a wysiwyg field type so that a Streams field definition renders a rich-text editor in the control panel and stores HTML in the underlying entry column. It is a thin integration layer: a FieldType class, a service provider that registers the type and its assets, a presenter for output rendering, and a Twig view + JS/CSS assets for the admin input.

Architecture fit.

• Fit is binary, not gradual: it is usable only inside a PyroCMS 3 application whose Streams Platform version satisfies the addon's constraints. In a generic Laravel/Symfony app there is no seam to attach it to — the field-type contract, the addon manifest, the Twig admin layer, and the addon:publish asset pipeline are all CMS-specific.
• The package carries no business logic we would want to reuse. Even inside the target stack, its value is "editor widget wiring," which is the lowest-differentiation layer of a CMS.

Integration feasibility. Low-to-moderate, and entirely gated on ecosystem alignment:

• Prerequisite is a running PyroCMS 3 instance with Streams already configured. Time-to-first-value inside that context is short (install addon → publish assets → add field to a Stream definition).
• Outside that context, integration cost is effectively "re-implement," not "integrate." Porting would mean extracting the editor binding into our own form component — at which point we are not consuming this package at all.

Technical risk (ranked).

1. Ecosystem capture. The package's lifecycle is bound to PyroCMS 3.x / Streams Platform. Anomaly Labs' commercial and open-source activity has been thin for years; abandonment risk is the dominant factor, not code quality. Zero dependents on record reinforces that there is no downstream community to absorb or patch it.
2. Content security surface. A WYSIWYG field is an HTML injection vector by definition. Risk depends entirely on whether sanitization happens server-side on save/render or only in the browser. If it is client-side only, every stored entry is a latent XSS payload, and our trust boundary becomes "whoever can submit the form."
3. Editor dependency drift. The bundled editor (Redactor vs. CKEditor varies by version) is a third-party JS artifact with its own licensing and CVE history, pinned by whatever the addon shipped.
4. Framework compatibility. Laravel/PHP version constraints in composer.json will be narrow and unlikely to track current Laravel releases.

Key questions to resolve before spending a single engineering hour.

• Which editor library and major version does this ship, and under what license?
• Is HTML sanitized server-side (e.g., HTMLPurifier) on save and/or render, or is the editor the only gate?
• What are the exact composer.json constraints for php, laravel/framework, and anomaly/streams-platform?
• Last commit / release date, and are the maintainers responsive to security reports?
• Is this already a transitive dependency of a module we intend to adopt? (If not, the answer is almost certainly "do not adopt.")

Integration Approach

Stack fit. This is a greenfield-only, PyroCMS-3-only fit. The decision rule is simple: if the roadmap already commits to PyroCMS 3 as the content platform, this addon is a candidate — but a replaceable one. If the roadmap is "Laravel app with a CMS-ish admin," this package is out of scope entirely; the correct move is a maintained editor integration (Tiptap, Filament RichEditor, TinyMCE) at the form layer, which is where a TPM should be steering the conversation.

Migration path.

• Adopting: install into an existing PyroCMS 3 app, publish assets, add the field type to the relevant Stream definition, then backfill. Existing text/textarea field data is HTML-compatible in principle, but the field type change is a schema-level operation on Streams field metadata — plan a dry run and a data snapshot, and validate rendering of pre-existing entries, which were never authored under an editor's constraints.
• Departing: because the payload is plain HTML in a column, exit cost is low. Any replacement editor reads the same column; the work is form-layer, not data-layer. That is the package's one genuine architectural virtue and worth stating explicitly in the ADR.

Compatibility. Verify the triad — PHP / Laravel / streams-platform — against our pinned versions before anything else. Expect to be one to two Laravel majors behind; if our platform runs a current Laravel, this is likely disqualified on constraints alone.

Sequencing.

1. Confirm PyroCMS 3 commitment and the pinned streams-platform version (gate).
2. Static review focused solely on sanitization and asset inclusion (~1 day).
3. Spike: install in a throwaway instance, publish assets, author and round-trip content with adversarial HTML payloads (<script>, onerror=, javascript: URLs).
4. Only then decide build-vs-adopt; in parallel, price the alternative (a maintained editor behind a custom field type) as the comparison baseline.

Operational Impact

Maintenance. Assume we are the maintainers. With 4 stars and 0 dependents, there is no upstream community, no security mailing list, and no realistic expectation of a timely CVE patch — particularly for the embedded JS editor, which is the most likely thing to need one. Budget a standing "vendor" line item: periodic dependency audit of the editor bundle, plus a fork-and-patch contingency. MIT licensing makes the fork legally clean; it does not make it cheap.

Support. No vendor SLA, no commercial backer, no issue-triage signal. Internal support burden falls on whoever owns the CMS admin. First-line triage questions ("editor didn't load," "formatting stripped," "content mangled on save") will be ours to answer, and they are notoriously hard to reproduce because they combine browser, editor config, and stored-HTML state.

Scaling. Rendering is cheap — it is a stored HTML string. The scaling concerns are adjacent, not throughput: (a) content hygiene at volume — unvalidated HTML across thousands of entries cannot be retroactively sanitized without a migration and a rendering regression risk; (b) asset weight — editors are heavy bundles loaded in the admin, which matters for editor-experience but not for public traffic; (c) no server-side rendering contract — if we later need headless or API delivery, we inherit whatever markup was authored, with no schema guarantee.

Failure modes.

• Silent data corruption: editor config changes the HTML it emits (wrapping, entity encoding); content round-trips differently each save. Detect with a golden-file test on save/render.
• Asset publishing drift: addon:publish not run after deploy → editor fails to load, field degrades to a broken textarea. Add to the deploy checklist and smoke test.
• XSS via stored content: highest-severity mode; mitigated only by server-side sanitization we may have to add ourselves.
• Constraint deadlock: a Laravel/PHP upgrade blocked by this addon's pinned constraints, forcing an emergency fork. This is the most probable failure and the one that most damages roadmap predictability.
• Upstream abandonment: not a discrete event — an ambient condition. Treat as the default assumption.

Ramp-up. Low for the mechanics (one developer, half a day: install, publish, define field). Non-trivial for the risk ownership — someone must own the fork, the sanitization policy, and the upgrade-blocker watch. That ownership must be assigned before adoption, not after.

TPM recommendation. Do not adopt as a new dependency. Composite 0.68 with 4 stars and 0 dependents reads as "narrow ecosystem utility, no downstream validation." If PyroCMS 3 is already the platform, this is a defensible convenience addon provided we accept fork ownership, add server-side sanitization ourselves, and log it as a known upgrade constraint. In any other scenario, the correct decision is to build the editor binding at the form layer with a maintained library and keep the stored-HTML contract — which this package demonstrates is the durable part anyway.