Wysiwyg Field Bundle Laravel Package

Product Decisions This Supports

• Content-modeling capability in a headless CMS. If you run (or are evaluating) Unite CMS, a WYSIWYG field type is the difference between content editors writing plain/markdown text and marketers authoring formatted body copy. It directly enables the "can our content team work without engineering" question.
• Build vs. buy vs. borrow for editor UX. This is a "borrow" option: use an existing field-type bundle instead of building a custom rich-text field or swapping CMS platforms. The decision it informs is whether a small open-source bundle is an acceptable foundation for your editorial experience.
• Roadmap sequencing for content operations. If the roadmap includes self-serve content editing, landing-page copy management, blog/help-center authoring, or product descriptions with formatting, this is a candidate dependency for the first increment — not the final one.
• Platform-consolidation trade-offs. Adopting it keeps you inside Unite CMS rather than adding a second CMS or a standalone editor (Contentful, Sanity, a hosted editor). Useful when the decision is "extend the current CMS" vs. "migrate."
• MVP and internal-tool scoping. For internal tools, back-office admin, or a time-boxed MVP where rich text is table stakes but not differentiating, this represents the lowest-effort path.
• Risk register input. With zero stars, zero dependents, and a zero score, the package itself is a data point: it tells you there is no community proof of production use, and therefore no free maintenance. That feeds directly into the "who owns this code" decision.

When to Consider This Package

Consider it when all of the following hold:

• You are already committed to Unite CMS. Note the framing correction up front: this is a Symfony bundle for a Symfony-based headless CMS, not a Laravel package. If your stack is Laravel, this does not apply to you — look at Filament's rich editor, Trix, TinyMCE, or a Laravel-native editor integration instead.
• You need a formatted-text field quickly and the alternative is a multi-week custom field-type build.
• Your team has PHP/Symfony capacity and is willing to fork, pin, and own the code. Treat the bundle as a reference implementation or starting point, not a supported dependency.
• The blast radius is contained: internal CMS, editorial back office, non-regulated content.
• Rich text requirements are modest — bold/italic/links/lists. Anything beyond that (tables, embeds, footnotes, track changes) is a signal to look elsewhere.

Look elsewhere when:

• You need vendor support or a security commitment. Zero stars, zero dependents, and an unmaintained footprint mean no upstream SLA. For public-facing, regulated, or high-traffic content, that is disqualifying on its own.
• Sanitization and XSS posture matter and you cannot audit them. A WYSIWYG field is an HTML injection surface by definition. Without an active maintainer or your own review, you are accepting unquantified security debt.
• You need collaborative editing, real-time co-authoring, comments, or versioning — that is a different product category.
• Accessibility and authoring quality are product requirements. Rich-text editors have wide variance in keyboard/screen-reader behavior; verify before committing.
• Your stack is Laravel or JS-first. Not a fit without meaningful adaptation work.

Recommended de-risking if you proceed: time-box a spike, fork the repo, pin a commit, add your own sanitizer (e.g., HTML Purifier) and content round-trip tests, and write down an exit path (custom field type or platform swap) before it reaches production.

How to Pitch It (Stakeholders)

To executives (one paragraph): This is a small, free, open-source add-on that gives our CMS a rich-text editing field for content teams. The upside is speed and cost — days rather than weeks, no license fee. The trade-off is that it has essentially no community or maintainer behind it, so we would own the code and its security review ourselves. I recommend it only as a scoped, internal-facing accelerator with an explicit exit path, not as a platform commitment.

To engineering (the ask): Small integration surface, one job — register a field type and wire an editor into the CMS admin. Because upstream signals are effectively zero, we should vendor/fork it, pin a version, and treat it as first-party code. Budget for HTML sanitization, an XSS review, and a couple of round-trip tests. Confirm the Symfony/Unite CMS version fit early — that is the most likely blocker.

To the content/editorial lead: It delivers formatted body copy, links, and lists — the baseline you need to publish without engineering tickets. Advanced authoring (embeds, tables, co-editing) is out of scope and would be a separate evaluation.

Bottom line for the decision meeting: low cost, low adoption risk to the business, non-trivial maintenance and security ownership. Approve as a time-boxed spike for internal content; do not approve for customer-facing or regulated content without a fork-and-harden plan.