friendsofvictoire/html-widget
A small Symfony bundle that adds an HTML widget to the Victoire CMS, letting editors drop raw HTML, embeds, and custom markup into any widget slot without touching templates.
This bundle is an add-on for Victoire DCMS (a Symfony-based page-builder CMS), not a standalone package. It adds an "HTML" widget so editors can drop raw markup into a page zone.
Minimal steps:
composer require friendsofvictoire/html-widget (verify the exact Packagist name — the repo is WidgetHtmlBundle, which often maps to a different composer name).FriendsOfVictoire\WidgetHtmlBundle\WidgetHtmlBundle in config/bundles.php (or AppKernel on older Symfony).bin/console cache:clear) and warm it, then open a page in the Victoire editor and look for the HTML widget in the widget picker.Where to look first:
src/Widget/ — the widget class. This defines the name, category, icon, and any form fields.Resources/views/ — the Twig template that actually renders the widget (this is where the |raw output lives).Resources/config/services.yml — the service tag that makes Victoire discover the widget.First use case: open a page in the builder, drag the HTML widget into a zone, paste an embed (iframe, third-party snippet, custom markup), save, publish, and confirm it renders on the front end.
Treat it as an embed widget, not a layout tool. The useful day-to-day pattern is dropping in iframes (maps, videos), third-party script snippets, or one-off markup that doesn't justify its own structured widget. For anything reused across pages, build a proper Victoire widget instead.
Service registration is the integration point. Victoire discovers widgets via a tagged service. If the bundle autoloads its services (Symfony 4+ services.yml convention), there is usually nothing to configure. If not, check the tag name against Victoire's docs for the version you run and register it explicitly.
Content field access. The widget entity typically exposes a single field (html, content, or similar). In the template it is read via the widget object — confirm the exact property by dumping the widget in the template ({{ dump(widget) }} with the profiler on) rather than guessing.
Overriding the template. Copy the bundle's template into your app (templates/bundles/WidgetHtmlBundle/... on Symfony 4+, app/Resources/... on older) and adjust it. This is the cleanest extension point for adding a wrapper <div>, scoping classes, or applying a sanitizer filter.
Sanitization pattern. If editors are untrusted, do not rely on the widget. Either:
{{ widget.html|purify }} if you have an HTMLPurifier Twig extension), orComposition workflow. HTML widgets live inside zones. Keep snippets self-contained: no global IDs, no assumptions about surrounding markup, responsive iframes (width="100%"), and CSS scoped to a wrapper class you control in the overridden template.
Fork-and-extend pattern. Because the package has no community traction, plan to fork it. Add fields (title, wrapper class), add sanitization, or convert it into a reusable "embed" widget with a provider dropdown. The widget class is small — extending it is faster than waiting for upstream.
composer.json, and check its Symfony/Victoire constraints before requiring it.|raw. If markup appears as literal text, that is the cause. Conversely, |raw is an XSS vector — see permissions above.<script> in the widget may be blocked by your Content-Security-Policy, or stripped by whatever sanitizer the editor applies. Embeds often need a nonce or an external JS include instead.config/bundles.php; older projects use AppKernel. The package may predate the modern convention — check its composer.json symfony/* constraints.templates/bundles/WidgetHtmlBundle/ on modern Symfony; the old app/Resources/ path will silently do nothing on Symfony 4+.How can I help you explore Laravel packages today?