Block Bundle Laravel Package

Technical Evaluation

Architecture fit. enhavo/block-bundle is not a Laravel package. It is a Symfony bundle extracted from the Enhavo CMS fullstack monorepo, and it is published as a read-only subtree split. Its runtime contract assumes Symfony HttpKernel/DI, Symfony Form, Twig, Doctrine ORM (block types are modeled as a Doctrine inheritance hierarchy with a discriminator/type column), and a set of sibling Enhavo bundles (EnhavoResourceBundle, EnhavoFormBundle, routing/backend bundles). There is no Laravel service provider, no facade, no config bridge, and no attempt at framework-agnosticism. For a Laravel codebase the fit is effectively zero without a port.

Integration feasibility.

• Laravel target: Not feasible as an install-and-use dependency. A port would mean running Symfony's container and form component inside Laravel, replacing Eloquent with Doctrine for the block entities, and reimplementing the block renderer and admin UI. That is a multi-week effort to obtain a content-block primitive, with a permanent dual-framework maintenance burden. Low ROI.
• Symfony target: Feasible, but only as part of adopting Enhavo as a CMS, not as a standalone library. The bundle's value is realized through Enhavo's resource/backend layer (admin CRUD, block preview, block rendering pipeline).
• Either way: you must pin against a matching Enhavo release set; the subtree split is generated from the main repo and does not carry independent semantic-version guarantees beyond whatever tag the split was cut at.

Technical risk. High, and concentrated in ownership rather than code quality (the upstream Enhavo project is a legitimate, longstanding Symfony CMS). Specific risks:

• Read-only mirror: issues and PRs belong in the main repo. Anything filed against this repo can silently disappear.
• No community signal: 0 stars, 0 dependents. No third-party usage means no field testing outside Enhavo, no Stack Overflow corpus, no independent security triage, and no CVE response path you don't create yourself.
• Documentation: the README is a logo, a one-paragraph project description, and "this is a subtree split." There is no bundle-level usage documentation; you are reading the monorepo docs or the source.
• Implicit coupling: the bundle depends on internal Enhavo APIs that are not stability-guaranteed, and Doctrine schema changes in a block-type refactor can require content migrations.
• Licensing is clean (MIT), so the risk is engineering and support, not legal.

Key questions.

1. Is our target stack Laravel or Symfony? If Laravel, this evaluation likely terminates at "reject."
2. What problem are we actually solving — a block-based content model, an admin editing experience, or a full CMS? Only the third justifies pulling in Enhavo.
3. If Symfony: are we willing to adopt Enhavo's resource/backend bundles and Doctrine entity model wholesale, rather than cherry-picking BlockBundle?
4. Who owns the fork if we need a fix upstream won't take? Subtree splits make local patching awkward.
5. What is the actual release cadence of the Enhavo monorepo, and which tag does this split correspond to?
6. Are there PHP/Symfony version constraints that conflict with our platform?

Integration Approach

Stack fit. Assume a Symfony 6/7 + Doctrine ORM + Twig application. Laravel applications should treat this as out of scope; the remainder of this section assumes Symfony.

Migration path.

• Preferred: adopt Enhavo as the CMS and accept BlockBundle transitively. Install the Enhavo metapackage / application skeleton at a pinned version, and let dependency resolution pick the matching block-bundle split. Do not require enhavo/block-bundle in isolation — you will get an unresolvable or mismatched dependency graph.
• Content migration: export existing block/page content into Enhavo's block entity schema. Expect a per-block-type mapping exercise; plan for a one-way import plus a manual QA pass on rendered output.
• Rejected path (Laravel port): if someone insists, sequence it as a spike only — extract the block data model and renderer contract, reimplement against Eloquent and Blade, and validate on one block type before committing. Budget it as a build, not an integration.

Compatibility.

• Pin Enhavo packages as a coherent set (same minor line); subtree splits from different cut points can drift.
• Verify PHP and Symfony minor-version support against the monorepo's composer.json, not this repo's.
• Doctrine inheritance strategy (single-table vs. joined) is a schema decision you inherit; changing it later requires a data migration.
• Frontend assets: Enhavo's admin uses its own asset build (Webpack Encore lineage). Confirm it coexists with your existing asset pipeline before wiring it in.

Sequencing.

1. Spike (1–2 weeks): stand up Enhavo in a scratch Symfony app, define two custom block types, render them in Twig, confirm the admin editing flow is acceptable.
2. Fit assessment: compare the block model against your content requirements; identify block types you'd have to author.
3. Integration decision gate: adopt whole-CMS vs. build a bespoke block layer vs. drop. Document the fork-ownership answer before proceeding.
4. Pilot: integrate into one section of the real application behind a feature flag, with real content.
5. Rollout: content migration, editor training, cutover.

Do not begin at step 4. The failure mode here is discovering mid-integration that the admin UX or block model doesn't match requirements, after the Doctrine schema is already in production.

Operational Impact

Maintenance. The dominant ongoing cost is upstream tracking. Because this is a generated mirror, you cannot meaningfully fork-and-patch without either patching the monorepo upstream or abandoning the split and vendoring. Realistically you will upgrade in lockstep with Enhavo releases, which means every Enhavo minor bump is a coordinated upgrade of a bundle set plus a Doctrine migration review. Budget recurring maintenance, not one-time integration.

Support. There is no commercial support implied, no dependents to consult, and no issue tracker on this repo. Your support channels are the Enhavo project's own channels and your team's reading of the source. Assume you are on your own for anything non-obvious, and that response times for upstream PRs are unmeasured. If this becomes business-critical content infrastructure, name an internal owner explicitly.

Scaling. Content blocks are read-heavy, latency-sensitive, and structurally simple — the scaling profile is a caching problem, not a compute problem. Front-load block-render caching (Twig fragment or HTTP cache keyed on block content version), keep the block entity graph shallow, and avoid N+1 loading of block relations in list/render paths. The admin write path is low-volume and can run on modest infrastructure.

Failure modes to monitor.

• Missing block template / unregistered block type: renders a hard error or a silent blank region on the page. Add a render-time guard and alert on it; a broken block type fails the whole page, not just its section.
• Orphaned block references: deleting a block type or a referenced entity leaves dangling IDs. Enforce referential integrity or add an integrity check job.
• Schema drift on upgrade: Doctrine inheritance changes are the highest-severity upgrade risk; always run migrations in staging against a production data copy.
• Asset build breakage: admin UI depends on Enhavo's asset pipeline; a build failure takes out content editing entirely, even though the public site keeps serving.
• Upstream abandonment: the 0-star/0-dependent profile means if Enhavo development stalls, you inherit a frozen dependency. Track upstream commit activity as a leading indicator.

Ramp-up. Expect 2–4 weeks for a competent Symfony developer to become productive with Enhavo's block/resource model, longer for the admin customization layer. The thin documentation raises this materially — plan for source-reading time, not just onboarding docs. Laravel-background developers face a second learning curve on Symfony's DI, form, and Doctrine patterns; factor that into team assignment.

Recommendation. Reject for a Laravel target. For a Symfony target, evaluate Enhavo as a CMS decision, not a bundle decision — this package has no standalone value and carries the support and upgrade profile of a mirror dependency. If the requirement is narrowly "structured content blocks," cheaper and better-supported options exist in both ecosystems.