Simplecontactform Widget Laravel Package

Product Decisions This Supports

• Build vs. buy for a contact-form block: This package answers a very narrow question — "should we hand-build a contact-form widget inside a Victoire DCMS page builder, or install one?" It bundles a form widget (fields, submission handling, admin-side configuration) as a drop-in content block for Victoire, so the decision it informs is encapsulation, not contact-form functionality itself. Any framework can render a contact form; the value here is that it plugs into Victoire's widget registry and editing UI.
• Roadmap scoping for CMS-editor experience: It is a useful reference artifact for how a page-builder widget should be packaged — registration, template overrides, editor-facing configuration, translation hooks. If your roadmap includes "marketing can add a contact block without a deploy," this is a pattern to study, not a dependency to adopt.
• Due-diligence / dependency-hygiene decisions: With 1 star, 0 dependents, no release since March 2017, and a composite score of 0.095, the package itself is a negative signal. It supports the decision "do not add this to our dependency graph" and, more usefully, supports writing a policy for how unmaintained packages get flagged.
• Use-case fit check: It is relevant only to teams running Victoire DCMS on legacy Symfony. It is not a Laravel package despite the framing — this is a Symfony bundle (FriendsOfVictoire), and that mismatch alone should trigger a procurement/architecture review before anyone scopes work against it.
• Not supported: anything involving spam protection strategy, deliverability, CRM routing, GDPR/consent capture, or form analytics. Those are product requirements this widget does not address and that you would own regardless.

When to Consider This Package

Consider it only if all of the following hold:

• You are already running Victoire DCMS on a legacy Symfony version and cannot migrate off it in the current planning horizon.
• You need a contact-form content block inside the page builder, and the alternative is custom widget development against Victoire's API — which is more expensive than vendoring this code.
• You are willing to fork and own it: read the source, vendor or mirror it internally, pin the commit, and accept full maintenance responsibility including security patches to form handling.

Look elsewhere — decisively — if any of these are true:

• You are on Laravel or modern Symfony. There is no path here; use the framework's own form/mail stack plus a maintained package (e.g., a Laravel form package or Symfony Form + a mailer), which will be better supported and better understood by your team.
• You need active maintenance, security advisories, or a support channel. A 2017 last release is a hard stop for anything touching user-submitted data.
• You need spam mitigation, rate limiting, file uploads, or multi-recipient routing. Assume none of this exists and budget for it explicitly.
• You are greenfield. Choosing a dormant CMS-specific widget as a foundation is a bet against your own hiring and upgrade path.

How to Pitch It (Stakeholders)

For executives: This is a small, single-purpose plugin for a specific legacy CMS (Victoire), last updated in 2017, with essentially no community adoption. It is not a strategic component and should not appear on an architecture diagram. Recommendation: treat it as a reference implementation only — a worked example of how to package a page-builder widget — and explicitly exclude it from any new build. If a team is currently running Victoire, the honest framing is that this reduces near-term widget effort by a small amount in exchange for owning unmaintained code; that trade is acceptable only inside a system already scheduled for replacement.

For engineering: The code is small enough to read in an afternoon; do that rather than adding it as a dependency. If you must use it, fork it, pin it, and add it to the security-review queue. Note the packaging mismatch — it is a Symfony bundle, so any Laravel-adjacent assumption in the request is a scoping error worth correcting before estimation.

For the portfolio: The real deliverable from this evaluation is a decision record: "dormant, zero-adoption, CMS-specific widget — reference only; pattern documented, dependency declined." Log it, close it, and move the contact-form requirement onto the standard framework stack.