Website Bundle Laravel Package

Technical Evaluation

Architecture fit The critical framing issue a TPM must internalize before scoping: integrated/website-bundle is a Symfony bundle, not a Laravel package, despite being catalogued as a Laravel/PHP dependency. It supplies a rendering layer — routing, controllers, Twig templates — for content managed in the Integrated CMS. Architecturally it is not a library you add to an existing application; it is a public-facing website surface you deploy. That reframing matters for TPM planning because the effort model shifts from "add dependency and configure" (days) to "stand up and own a separate PHP runtime and site" (weeks). It is a strong fit only if the target is a Symfony/Twig estate already using Integrated. In a Laravel-first org it is a second runtime, not an import.

Integration feasibility Three viable patterns, each with a different TPM story:

1. Native adoption — full Symfony app with the bundle installed. Lowest engineering friction, highest platform divergence; requires a team that can own Symfony.
2. Satellite site — run the bundle as a standalone service reverse-proxied from the main app. Preserves the Laravel core; adds a second deploy pipeline, session model, and design-system duplication. The bundle delivers its value but at the cost of an operational seam.
3. Headless bypass — skip the bundle, consume Integrated's content API directly from Laravel or a JS front end. Loses the prebuilt templates; eliminates the runtime split. The bundle's only remaining value is as a reference for Integrated's content model.

Only Pattern 1 realizes the package's stated lift. Patterns 2 and 3 convert it from "dependency" to "reference implementation," which changes the procurement and ownership story entirely.

Technical risk

• Zero social proof. 0 stars, 0 dependents, no public issues to mine for failure modes. Every defect is discovered by us.
• Single-vendor coupling. Published by the organization that sells Integrated. Compatibility is bound to a commercial relationship, not a community contract — a procurement and vendor-management concern, not just engineering.
• Unverified platform constraints. PHP version, Symfony major, Twig version, and content delivery mechanism (API vs DB vs service container) are undocumented in reviewed metadata. Any of these is a hard blocker discoverable only at spike time.
• Rendering-layer lock-in. Front-end bundles encode template structure, route conventions, and SEO logic. Once design lives inside bundle templates, customization becomes fork maintenance.
• Score interpretation. Composite 0.03 with opportunity 4.16 signals a genuine capability gap in CMS front-end scaffolding but essentially no evidence of production readiness. Read this as "investigate," never "adopt."

Key questions

• Supported Symfony/PHP/Twig versions, and is there a published support/EOL matrix?
• Does it require a hosted Integrated, self-hosted, or either — and what does the backend cost?
• Content delivery mechanism (API / DB / in-process) and degradation behavior during backend outage?
• What is overridable (templates, routes, assets) versus opinionated, and what is the documented override mechanism?
• Release cadence, semver discipline, security disclosure process?
• Multilingual, multi-site, preview/draft, editorial workflow coverage — bundled or build-ourselves?
• Is an upgrade path across Symfony majors documented, and who owns it?

Integration Approach

Stack fit Good for Symfony 5/6+ and Twig shops already committed to Integrated. Poor for Laravel-only teams unless a satellite-service pattern is acceptable. The determinant is not PHP compatibility but whether the team can own a Symfony deployable — that is a hiring and roadmap decision, not a technical one. If the answer is no, evaluate Integrated's API directly and leave this bundle out of the architecture.

Migration path

1. Timeboxed spike (1–2 weeks). Stand up a throwaway Symfony app against a trial Integrated instance. Exit criteria: confirmed PHP/Symfony/Twig constraints, observed template override mechanism, observed route behavior, backend connectivity from CI, and a documented list of anything that would require a fork. This resolves most open questions cheaply and produces an evidence-based go/no-go.
2. Pattern decision. If the spike is clean and the team can carry Symfony, adopt Pattern 1 for the public site only, keeping Laravel for authenticated/app surfaces. If rough, fall back to Pattern 3 and re-scope the bundle as documentation of Integrated's content model.
3. Contain the blast radius. Keep design tokens, asset pipeline, and SEO metadata generation outside the bundle so a later swap does not require re-implementing the site.
4. Define the exit before committing. Document which templates are overridden, which routes point at bundle controllers, and the cost of re-reading content from the API — so "replace the bundle" is a known number, not a surprise.

Compatibility Unconfirmed across PHP, Symfony, Twig, and the Integrated backend version. With no dependents there is no community folklore to lean on. Pin exact versions, run the full suite against our own PHP matrix in CI, and treat every minor bump as a reviewable change rather than an automatic update.

Sequencing Spike → architecture decision (native / satellite / headless) → security and license review of the Integrated backend contract → design-system and template boundary definition → production build. Do not sequence the bundle before the backend commercial terms are settled: technical evaluation is meaningless if the content platform itself is not approved.

Operational Impact

Maintenance The bundle becomes a maintained dependency with no community buffer. Expect to read the source to answer routine questions and to carry a fork if upstream goes quiet. Symfony's ~12-month major cadence means a standing allocation for framework catch-up is unavoidable — the classic cost of a single-vendor bundle. MIT licensing makes forking legally trivial, which is the primary mitigant but also the ceiling on how much "support" we should expect.

Support No meaningful community channel. Support runs through the vendor relationship with Integrated and must be negotiated explicitly: defect response times for the bundle itself, notice period for breaking changes, and whether bundle updates are included in the platform subscription. Get this in writing before adoption — it is the only safety net, and procurement, not engineering, owns it.

Scaling The rendering tier is stateless and scales horizontally in the ordinary Symfony way — not a scaling concern in itself. The real scaling questions sit behind it: content API latency and rate limits, cache invalidation when editors publish, and whether the bundle ships caching primitives or expects us to front it with a CDN or HTTP cache. Assume we own the caching layer until proven otherwise. For high-traffic, cache-heavy sites, validate cache-tag and purge behavior during the spike, not after launch.

Failure modes

• Backend outage → site outage. A rendering layer bound to a remote CMS fails visibly. Requires full-page caching or static fallback; confirm during the spike whether the bundle degrades gracefully or errors hard.
• Bundle upgrade → template breakage. Overridden templates silently diverge from upstream. Mitigate with visual regression tests on key pages.
• Route collisions. Bundle-registered routes can collide with host-app routes; enumerate and assert them in CI.
• Version drift. A Symfony upgrade forces a bundle upgrade upstream has not shipped — the most likely long-term failure and the strongest argument for the satellite pattern, which isolates the damage to one deployable.
• Undocumented assumptions. Content-model changes on the Integrated side that the bundle does not tolerate, discovered in production.

Ramp-up Non-trivial. Even in a Symfony shop, the team must learn Integrated's content model and the bundle's override conventions. In a Laravel shop, add Symfony and Twig fluency for whoever owns the satellite — realistically 2–4 weeks to productive contribution per engineer, plus ongoing single-owner risk until a second person is trained. Weigh that against the template scaffolding the bundle saves: for a small marketing site the trade may still be favorable; for anything with complex interaction or strict SLAs it likely is not. Recommend a two-week spike with explicit exit criteria and a written adopt/fork/bypass decision at the end, so the go/no-go is a product decision made on evidence rather than an engineering default.