Html Widget Laravel Package

Product Decisions This Supports

• Ecosystem fit check, not a feature decision. This is a Symfony bundle for Victoire DCMS — not a Laravel package. The first decision it informs is whether our stack assumptions are correct: if we're a Laravel shop, this package is out of scope entirely and the evaluation stops here.
• Build vs. buy on a trivial capability. The package provides one thing: an editable raw-HTML block in the page builder. That is a small, well-understood unit of work (a widget class, a form type, a template). It informs the "buy" side of the ledger only weakly, because the buy price includes inheriting an ecosystem.
• Roadmap signal for content tooling. If our editors are asking for "embed arbitrary HTML / third-party widget snippets" (analytics tags, ticketing embeds, custom forms), that is a real roadmap item worth scoping — but it should be scoped as a feature with a sanitization policy, not as a dependency adoption.
• Risk register entry. 0 stars, 0 dependents, 0 score. This is an unmaintained or effectively unadopted component. Any decision to depend on it creates a long-tail maintenance obligation we own by default.
• Use cases it legitimately serves: landing pages needing marketing-supplied embed codes, one-off promotional blocks, migration bridges where legacy HTML must be preserved verbatim in a CMS page.

When to Consider This Package

Adopt only when all of the following hold:

• We are already running Victoire DCMS on Symfony and this widget is the idiomatic way to extend its page builder — the value is ecosystem consistency, not the code itself.
• The need is genuinely a raw HTML escape hatch for trusted editors, and we have accepted the XSS surface with a policy (allowlist of editors, sanitization layer, Content-Security-Policy).
• We are comfortable vendoring or forking ~a few dozen lines, because the maintenance signal here is near zero.

Look elsewhere — or build in-house — when:

• We are on Laravel. No adaptation path exists; porting a Symfony widget abstraction to a Laravel page builder is more work than writing the field directly.
• We need active maintenance, security review, or a CVE response process. None of that is evidenced here.
• Editors are untrusted or numerous. Raw HTML passthrough is the wrong primitive; prefer a structured component library or a curated embed allowlist.
• Licensing, provenance, or supply-chain review is required. A near-zero-adoption dependency is hard to justify in a security review and easy to replace.

How to Pitch It (Stakeholders)

To executives: We evaluated a small open-source component for embedding custom HTML in CMS pages. It only works inside Victoire DCMS, a niche Symfony CMS we are not on, and it has essentially no adoption or maintainer activity — zero stars, zero downstream users. Recommendation: do not adopt. The capability our editors want is real and cheap to build ourselves (roughly a day of engineering), and building it inside our own stack keeps the security policy — which matters here, since raw HTML blocks are a script-injection vector — under our control.

To engineering: This is a Symfony/Victoire bundle, not Laravel, so it is not directly consumable. Even if it were, the payload is a single widget around an unescaped HTML field; we would be taking on a fork-and-own obligation for code we could write in an afternoon. If the raw-HTML block is genuinely on the roadmap, treat it as an internal feature: one form field, one render template, an editor permission gate, and a sanitizer with an explicit allowlist. Ship it behind a flag and log usage so we can measure demand before broadening access.