Ux Vvvebjs Laravel Package

Product Decisions This Supports

• Build vs. buy for visual editing. ux-vvvebjs is a credible "assemble, don't build" option for drag-and-drop HTML/page editing — a form type plus a Stimulus controller instead of a multi-month editor project. At v0.1.0 it supports a prototype/spike decision, not a platform bet.
• Roadmap input on low-code / no-code surfaces. If visual page building, landing-page authoring, email/template composition, or CMS block editing is on the roadmap, this release is cheap enough to convert an open roadmap question into a validated yes/no within a sprint or two.
• Framework gating. The brief frames this as a Laravel/PHP package; the release is a Symfony UX Bundle (Symfony 6.4/7.x/8.x, symfony/stimulus-bundle, PHP 8.1+). For a Laravel product this is effectively a no-go without a port — the decision it informs is "is the underlying VvvebJs library worth integrating ourselves?", not "can we install this?"
• Use cases it unblocks quickly: admin/CMS content authoring (EasyAdmin via VvvebJsAdminField, one-liner), marketing landing pages stored as HTML in a hidden field, template editing with Bootstrap 5 component groups, read-only preview workflows (readOnly), and multi-editor pages.
• Infrastructure decisions it forces early: where uploaded media lands (local public/, Flysystem/S3/GCS/Azure/SFTP, or a custom UploadHandlerInterface), max file size (10 MB default), allowed MIME types, and whether assets come from jsDelivr CDN or are self-hosted via cdn_url.
• Bundle-size and dependency posture. Default CDN delivery and dynamic plugin asset loading mean you inherit an external runtime dependency; the cdn_url override keeps a self-hosted path open, which is the option to standardize on if it ships.
• Explicitly not supported by this release: any commitment to API stability. The maintainers state backwards compatibility is not guaranteed between releases.

When to Consider This Package

Consider it when:

• The product is Symfony 6.4, 7.x, or 8.x on PHP ≥ 8.1 with symfony/stimulus-bundle ≥ 2.9.1 already present.
• You need a visual editor embedded inside a form and want the value to land in a hidden field with no bespoke JavaScript — the "zero JS required" promise is the core value.
• You use EasyAdmin and want an editor field in one line.
• You are time-boxing an experiment and can absorb churn — this is an experimental 0.x release.
• AssetMapper or Webpack Encore; both are supported.
• You need pluggable media storage and are happy implementing UploadHandlerInterface or pointing Flysystem at your bucket.

Look elsewhere when:

• The stack is Laravel or any non-Symfony framework — nothing here is installable as-is; the realistic fallback is integrating VvvebJs directly or evaluating a framework-agnostic editor.
• You require semantic-versioning guarantees, an LTS, or a security-review-cleared dependency; pre-1.0 with no BC promise fails a typical vendor gate.
• The design system is not Bootstrap-flavored — the component groups skew Bootstrap 5 / common HTML widgets, so a bespoke design system means custom component work.
• You cannot tolerate an external CDN in the default path and are unwilling to configure self-hosting.
• The upload endpoint (POST /vvvebjs/upload) needs hardening beyond what's shipped, or your threat model treats a public write endpoint as a blocker without an audit.
• You need mature accessibility, i18n, or a large maintained community — this is a young, single-maintainer-scale package.
• You need headless/structured content rather than raw HTML blobs in a hidden field.

How to Pitch It (Stakeholders)

To executives: This is a low-cost experiment, not a platform commitment. A first experimental release now exists that drops a full drag-and-drop page builder into Symfony admin forms with no custom front-end work, including six component groups, six plugins (Google Fonts, CodeMirror, JSZip, Animate on Scroll, AI assistant, media), and three storage backends for uploads. The ask is one short spike to answer a roadmap question — "is visual page authoring worth investing in?" — before we spend real engineering quarters on it. Framing caveat: this is a Symfony package, so if we are building on Laravel, the honest version of the pitch is "the underlying editor is worth evaluating; this wrapper is not usable for us." Either way, the downside is bounded to spike effort, and the answer is a decision, not a dependency.

To engineering: Symfony-native integration — VvvebJsType renders the builder inline and writes HTML into a hidden field; multiple instances per page are supported; a Stimulus controller manages the iframe lifecycle with HTML sync on submit and unload; works with both AssetMapper and Encore. Uploads go through a built-in controller with local, Flysystem, or custom-handler backends. The constraints are real: v0.1.0, no backwards-compatibility guarantee, default assets from jsDelivr (override with cdn_url), and a new public upload route that needs a security pass on MIME validation and size limits before anything customer-facing. Recommended posture: pin the exact version, wrap the form type and upload handler behind our own thin adapter so an upstream breaking change costs us an afternoon, self-host the assets, and treat the editor as an internal-tool capability first — then re-evaluate at 1.0.