Wysiwyg Field Bundle Laravel Package

Technical Evaluation

Architecture fit

• Despite the brief labeling this a "Laravel/PHP package," unite-cms/wysiwyg-field-bundle is a Symfony bundle for Unite CMS, not a Laravel package. It extends Unite CMS's field-type system to add a rich-text/WYSIWYG editor field to content types.
• It only fits an architecture that is already committed to Unite CMS on Symfony. In a Laravel application there is no integration surface — Laravel has no field-bundle registry or Unite CMS kernel to hook into.
• Scope is narrow and additive: it introduces a content-model field type plus the client-side editor assets. It is not a platform or infrastructure dependency.
• The value is almost entirely contingent on Unite CMS being the content backbone; if the CMS decision is still open, this package should not influence it.

Integration feasibility

• Standard Composer install plus bundle registration in the Symfony kernel and field-type registration with Unite CMS. Integration effort is low if the platform is already Unite CMS.
• No data migration is inherent to the package; migration effort is only in converting existing rich-text/plain-text fields into the new field type and re-rendering stored HTML.
• Because it is a field bundle, it composes with existing content types rather than replacing infrastructure — a low-blast-radius addition.

Technical risk

• Adoption signal is effectively zero: 0 stars, 0 dependents, a score of 0. That is the profile of an experimental, abandoned, or purely internal package. There is no downstream evidence anyone runs it in production.
• Maintenance risk is high: assume no upstream security patches. WYSIWYG output is a classic XSS vector; HTML sanitization and editor-version CVEs (CKEditor/TinyMCE-class libraries) would become our responsibility.
• Version-constraint rot: Symfony/PHP constraints are likely pinned to versions contemporaneous with Unite CMS's active period, which may conflict with a modern stack.
• Unite CMS itself appears low-activity, so the parent platform carries the same abandonment risk — this is a compounding, not isolated, concern.

Key questions

1. Are we actually standardized on Unite CMS/Symfony, or is this being evaluated for Laravel by mistake?
2. What is the last commit/release date, and what PHP/Symfony/Unite CMS versions are supported?
3. How is stored HTML sanitized on input and output, and where does that logic live — this bundle or core?
4. Which JS editor does it embed, and what is that editor's CVE/support status?
5. If the package is unmaintained, are we prepared to fork and own it?
6. What is the exit path if Unite CMS is retired?

Integration Approach

Stack fit

• Green light only for a Symfony + Unite CMS stack. For Laravel, treat this as out of scope and evaluate a native rich-text field (Filament/Tiptap, Nova field, or a custom Blade component) instead.
• If the organization runs multiple CMS stacks, this package should be scoped to the Unite CMS properties only — do not attempt to standardize rich text across platforms through it.

Migration path

1. composer require unite-cms/wysiwyg-field-bundle in a branch, confirming constraint resolution against the current lockfile.
2. Register the bundle and field type; validate in a non-production environment.
3. Model one representative content type with the new field; compare rendered output against existing content.
4. Backfill/migrate legacy rich-text fields with a scripted conversion; verify sanitization on migrated HTML.
5. Cut over per content type, not globally.

Compatibility

• Verify PHP and Symfony constraints against the current runtime before any planning; a failed composer update dry run is the cheapest gate.
• Confirm the embedded editor's browser support matrix and asset pipeline compatibility (Webpack Encore/AssetMapper).
• Check for conflicts with any existing sanitizer or HTML purifier already in the stack.

Sequencing

1. Platform confirmation (is it Unite CMS?) — hard gate.
2. Dependency and security spike — one engineer, timeboxed, produce a go/no-go memo.
3. Fork decision — if unmaintained, decide ownership and patch cadence before adoption, not after.
4. Pilot content type in staging.
5. Rollout with a documented sanitization policy and editor-version upgrade runbook.

Operational Impact

Maintenance

• Expect to own this code. With zero dependents there is no community patch flow; upgrades to PHP/Symfony will require us to carry or fork the bundle.
• Budget a recurring line item for dependency review — editor CVEs, Symfony deprecations, Unite CMS upgrades.

Support

• No vendor, no active issue triage, no documented support channel. Internal runbooks and an owner must be assigned at adoption.
• Documentation is likely thin; institutional knowledge will concentrate in one or two engineers — a bus-factor risk worth naming.

Scaling

• The field type itself is not a throughput concern; rich-text storage volume and render-time sanitization cost are. Large HTML payloads inflate content tables and API responses.
• If content is served headlessly at scale, sanitize on write and cache rendered HTML rather than re-sanitizing per request.

Failure modes

• XSS via sanitization bypass — highest severity; rich text is untrusted input.
• Editor asset failure — CDN/JS version drift breaks authoring without breaking the site.
• Composer constraint conflict on the next platform upgrade, blocking routine patching.
• Silent abandonment — no security advisories issued because no one is watching the package.
• Content lock-in — HTML shaped around this editor's output may be awkward to migrate to a successor.

Ramp-up

• Low for a team already fluent in Symfony and Unite CMS (hours to a working pilot); moderate for a Laravel-centric team that would first need to learn the Symfony bundle and Unite CMS field-type model.
• Plan for a half-day knowledge-transfer session and a written runbook covering editor upgrades and sanitization policy, given the absence of upstream docs.