Image Widget Laravel Package

Product Decisions This Supports

• Block-based page composition. This bundle supplies the "image" block type for Victoire DCMS (a Symfony-based CMS with a visual page builder). If your roadmap includes letting marketing/editors drag images into composed pages without engineering involvement, this is one of the primitive block types you need before any page-builder work is demo-able.
• Build vs. borrow for commodity UI primitives. An image widget is not a differentiator. The decision it informs is whether to spend internal sprint capacity re-implementing crop/alt-text/rendering plumbing or to consume an existing implementation and redirect that capacity to the parts of the product customers actually pay for.
• Platform lock-in assessment. The package is a Symfony bundle for Victoire DCMS — not a Laravel package. The PM-level decision it forces is whether the product stays on Victoire as its content layer, or whether the CMS is a replaceable component. Adopting this bundle is a small but real vote for "Victoire is our content platform."
• Media handling scope. It anchors the minimum viable scope for media in the CMS: a single image asset with display-time rendering. It does not answer questions about DAM, renditions, focal points, CDN delivery, or asset governance — those remain separate roadmap items with separate budgets.
• Roadmap sequencing input. Because the package is effectively unmaintained signal-wise (0 stars, 0 dependents, no visible community), any roadmap item that depends on it should carry an explicit maintenance allocation. That is a staffing decision, not just a technical one.

When to Consider This Package

Consider it only when all of the following hold:

• You already run Victoire DCMS in production, or you have committed to it for an imminent release.
• Your Symfony and Victoire versions match what this bundle targets (this is an older-generation bundle; verify compatibility against your composer.json constraints before anything else).
• The requirement is a plain image block in the page builder — one asset in, markup out — with no transformation, no DAM integration, and no multi-rendition art direction.
• You are willing to own it: fork it into your own VCS, pin the version in composer.lock, and treat it as vendored code rather than a dependency with an upstream support contract.

Look elsewhere when:

• You are on Laravel or any non-Symfony stack. This is a hard stop; there is no adaptation path worth the effort. Use a native media library (Spatie Media Library, Intervention Image) or a block editor with first-party image blocks.
• You need real image pipeline capability — responsive srcset, on-the-fly transforms, focal-point cropping, WebP/AVIF, CDN offload. Pair with or replace by LiipImagineBundle, Glide, Imgix/Cloudinary, or an equivalent. This bundle is presentation, not processing.
• You expect upstream fixes. Zero stars, zero dependents, and a zero composite score mean no community backstop. Assume no security patches arrive and price the internal ownership accordingly.
• You're on modern Symfony. If you're building greenfield, evaluate Symfony UX / a current block-editor bundle or a headless CMS instead of adopting an aging DCMS widget.
• Accessibility and compliance are gated requirements. Verify alt text is a required field, not optional, and that output markup is under your control — you will likely need to override templates.

How to Pitch It (Stakeholders)

Bottom line: a small, free, single-purpose component that saves us a few days of work if and only if we are already committed to Victoire DCMS as our content platform. It is not a strategic asset, and it should not be the reason we choose a platform.

For executives: cost is near zero in license terms, but total cost of ownership is not zero — assume we maintain a fork. The real risk is concentration: an unmaintained widget inside the content pipeline is a low-severity but permanent tax, and a platform dependency we should be conscious of. Recommendation: adopt as vendored code behind a pinned version, with a named owner and a documented exit path.

For engineering: treat this as borrowed source, not a dependency. Fork it, pin it, review the templates for accessibility and escaping, and confirm version compatibility with our Symfony/Victoire baseline before estimating. Budget roughly 2–5 engineer-days for integration, template overrides, and accessibility fixes — more if we need responsive renditions, in which case a separate image-transformation layer is the real work and this bundle is incidental.

Decision requested: approve a one-sprint spike to validate compatibility and output quality against our accessibility checklist; the spike's exit criteria are (a) renders correctly on our Symfony version, (b) alt text enforceable, (c) fork-and-pin path proven. If the spike fails, fall back to a hand-rolled block — the scope is small enough that this is a bounded, reversible decision either way.