Block Bundle Laravel Package

Product Decisions This Supports

• Build vs. buy for a block-based editor. The bundle is the content-composition layer of the Enhavo CMS (Symfony fullstack). Relevant to the decision "do we build our own page-builder/block system, or adopt an existing Symfony-native one?" — but only as part of the wider Enhavo evaluation, not as an independent component.
• Content-modeling roadmap. If our roadmap includes editors assembling pages from reusable blocks (text, media, teaser, gallery, etc.) with a UI on top of Doctrine entities, this is a reference implementation to benchmark against — both for capability and for how the data model is structured.
• Stack standardization. Supports a decision to keep content tooling inside a Symfony/PHP monolith rather than adding a separate headless CMS vendor — which matters if we value one runtime, one deploy pipeline, and one team skill set.
• Time-to-market for editorial tooling. A buy/adopt path can shortcut months of internal page-builder work, if the parent CMS fits our requirements. Treat this as an input to that estimate, not a finished answer.
• Explicitly not supported: replacing an existing CMS with "just this package." It is a subtree split — a read-only mirror of files from the main Enhavo repository — so the real decision unit is Enhavo CMS, not this package. There is no standalone integration story here.

Signal check before you use it in any decision doc: 0 stars, 0 dependents, README-level maturity, description is a placeholder, and the README itself says "This is a subtree split of the main repository." That is a distribution artifact, not a product. Any roadmap commitment should cite the parent project's release cadence and issue activity, not this repo's.

When to Consider This Package

Consider it when all of the following hold:

• We have already (or are seriously about to) adopt Enhavo CMS as our content platform, and we want its block layer as part of that stack.
• Our stack is Symfony/PHP fullstack and we intend to stay coupled (server-rendered or Symfony-templated), not headless-first.
• We have in-house Symfony depth — Doctrine, form types, bundle wiring, DI — to debug and extend a bundle whose documentation lives in a different repository.
• We are comfortable consuming an open-source, single-vendor project with no commercial support contract, and we can tolerate contributing fixes upstream or maintaining a fork.
• We are evaluating via Composer from the main repository, treating this split as the read-only artifact it is.

Look elsewhere when any of these are true:

• Headless / API-first is a requirement — evaluate API Platform, Strapi, Contentful, or Sanity instead.
• We need a standalone, drop-in block component with its own versioned docs and API guarantees. This bundle is not designed for that; installing a subtree split directly is a maintenance trap (no independent issue tracker, PRs belong upstream).
• We need SLA, security patching commitments, or vendor escalation — nothing here suggests that exists.
• The team isn't a Symfony shop. The value is inseparable from the framework's conventions; the cost of entry is the framework.
• We need documented, stable public APIs today. Maturity is at README level; treat the API surface as unstable until we've read the parent repo's release history and changelog.
• Zero dependents is not proof of poor quality, but it is proof of an unproven ecosystem — assume we are early adopters bearing integration risk.

How to Pitch It (Stakeholders)

For executives (one paragraph): This is a component of Enhavo, an open-source Symfony CMS, not a product we license. It would support a decision to adopt an existing block-based content editor instead of building one, which could save meaningful engineering time. The trade-off is risk: the project is MIT-licensed and free, but it has effectively no independent adoption, no commercial support, and documentation that lives in another repository. The honest framing is "a low-cost option worth a time-boxed spike," not "a safe standard." We should approve a short evaluation of the parent project, not adoption of this bundle.

For engineering (bullets):

• Do not composer require this split. Evaluate enhavo/enhavo and pull the block bundle transitively.
• Validate first: supported Symfony and PHP version ranges, release frequency in the parent repo, test coverage, and whether the block model is extensible without forking.
• Estimate the real cost as integration + ongoing fork maintenance, not zero — we own upgrades, security patches, and any upstream contribution.
• Timebox a spike: stand up Enhavo, model two or three of our actual content types as blocks, and report back on extension friction.

Recommendation to state plainly: Keep this on the evaluate list, not the adopt list. The decision that matters is Enhavo CMS vs. alternatives (headless vendor, or build in-house); this bundle is evidence for that decision, not a decision of its own.