Sulu Form Landing Page Bundle Laravel Package

Product Decisions This Supports

• Post-submission experience design. Today, a Sulu form's "success" behaviour is largely a developer concern (re-render, flash message, or hardcoded forward). This bundle turns the destination into editor-managed configuration per form — which is a product decision, not an implementation detail: does the user land on a thank-you page, a gated asset, a booking calendar, or a campaign-specific page with tracking pixels?
• Conversion funnel ownership. Redirect targets are where analytics events, conversion pixels, and nurture sequences get attached. Moving this from code to CMS config shortens the marketing iteration loop from a sprint to minutes.
• Build vs. buy vs. configure. Scope is genuinely small (a form-submit handler that reads a configured landing page and issues a redirect). The real decision is not "which package" but "do we own ~100 lines of Symfony code, or take a dependency?" For a team already maintaining a Sulu app, an in-house listener is often cheaper over 24 months than tracking an upstream bundle.
• Platform roadmap signal. If post-submit routing is a recurring request, it's evidence your marketing stack is outgrowing a CMS-native form builder. That's an input to the "stay on Sulu forms vs. adopt a marketing automation tool (HubSpot, Marketo, Formstack)" decision — this bundle buys time, it doesn't answer that question.
• Use cases it unblocks: lead-gen landing pages, webinar/event registration confirmations, gated whitepaper downloads, localized (per-locale) thank-you pages, and campaign-specific post-submit pages that need their own UTM/pixel setup.

When to Consider This Package

Consider it when all of these hold:

• You are on Sulu CMS (Symfony) — flag this immediately: the package is PHP, but it is not Laravel. It extends Sulu's form bundle (SuluFormBundle) and will not drop into a Laravel app.
• You have multiple forms needing different post-submit destinations, and the people who want to change those destinations are editors, not developers.
• You need per-locale or per-form redirect targets, and a single global "thanks" template override won't cover it.
• You can accept vendor risk: 1 GitHub star, 0 dependents, a single maintainer. The v3.0.1 release (a Symfony version-compatibility update) shows the maintainer is still tracking framework upgrades, but adoption is still negligible and there is no second maintainer. Treat it as a small vendored dependency you may need to fork.
• You verify Symfony compatibility before upgrading. v3.0.1 is a dependency-constraint change, not a feature change — which means it may have raised the minimum (or dropped older) Symfony versions. Confirm the new constraint matches your pinned Symfony release before scheduling the bump.

Look elsewhere when:

• You're not on Sulu — this is a non-starter; a Laravel equivalent is a RedirectResponse from your form controller or a FormRequest hook.
• You need conditional branching, multi-step forms, A/B testing of destinations, or CRM/ESP hand-off — that's a marketing automation platform decision, not a bundle decision.
• Your need is a single, org-wide thank-you page — a template override is zero dependencies and zero maintenance.
• Your team has a low tolerance for unmaintained dependencies in the request path (a broken submit handler is a visible, revenue-affecting failure). v3.0.1 improves the maintenance signal but does not change the bus-factor or adoption picture.

How to Pitch It (Stakeholders)

To executives: This is a small, cheap capability that closes a gap in our conversion funnel. It lets marketing set where a visitor lands after submitting a form — thank-you pages, gated downloads, campaign pages — without filing an engineering ticket each time. Expected cost is a day or two of integration; the return is faster campaign iteration and cleaner conversion tracking. The latest patch (v3.0.1) is routine framework-compatibility maintenance, so the dependency is still alive, but it remains a single-maintainer project.

To engineering: It's a Sulu bundle that adds a configurable landing-page redirect to form submissions, so the destination becomes editor-managed content rather than a hardcoded forward. Integration surface is small and it sits alongside SuluFormBundle rather than modifying it. v3.0.1 only updates the Symfony version constraint — no new features, no intentional API changes — but a constraint bump is the one change class that can silently break installs, so read the new composer.json requirement against our pinned Symfony version before upgrading. The upstream risk is unchanged: one maintainer, negligible adoption. Recommend we pin the version, isolate the integration behind our own form-submit listener interface, and budget for a fork if it goes stale — or simply reimplement the ~100 lines internally if the team prefers zero external dependencies.