Block Bundle Laravel Package

Product Decisions This Supports

• Block-based content composition — whether to model reusable, orderable content blocks (heroes, CTAs, rich text, embeds) as first-class entities that editors assemble into pages, rather than hard-coding templates per page.
• Ecosystem commitment — the real decision is Symfony + Sonata versus Laravel + a block/page builder. This package only makes sense inside a Symfony application already using SonataAdmin or SonataPage; it has no bearing on a Laravel roadmap.
• Build vs. buy vs. fork — a fork with 0 stars, 0 dependents, and archived status is a signal to evaluate the upstream sonata-project/SonataBlockBundle (actively maintained, security-advisory tracked) rather than treat this repository as a candidate.
• Migration/decommission planning — if any internal service already depends on this fork (Dependents reports 0, but check private mirrors), the decision is a remediation plan, not new adoption.
• Not a differentiator — content blocks are table-stakes CMS plumbing. Nothing here justifies roadmap investment or a competitive narrative; it should sit in the "commodity infrastructure" bucket.

When to Consider This Package

Consider it only if all of the following hold:

• The product is a Symfony application (this is a Sonata bundle, not a Laravel package — it will not install or autoload in Laravel without a full Symfony kernel).
• You are already running SonataAdmin and/or SonataPage and need block rendering consistent with that stack.
• You have a hard pin to the specific upstream version this fork targeted — i.e., the fork exists to carry a local patch (PHP version bump, dependency constraint, or bug fix) that upstream never merged.

Look elsewhere — or rather, at upstream — when:

• Maintenance matters. Archived repositories receive no security patches. A block renderer handles user-authored HTML; unpatched XSS or sanitization issues are a direct product risk.
• You need support or hiring signal. 0 stars / 0 dependents means no community, no Stack Overflow corpus, no candidates who have seen it. Onboarding cost is entirely yours.
• You're on Laravel. Use a native block/page solution (e.g., a Filament page builder, Twill, or a headless CMS) instead of bridging Symfony bundles.
• You want upstream features. Bug fixes and PHP/Symfony version support land upstream, not in a stale fork.
• Supply-chain hygiene is a gate. An unmaintained, single-maintainer, zero-audience fork is exactly the profile that fails most dependency-review policies.

The correct action is almost always: depend on sonata-project/SonataBlockBundle directly, and if you truly need a patch, submit it upstream or vendor it with a documented, owned fork — not adopt a third party's abandoned one.

How to Pitch It (Stakeholders)

For executives: This is a small, abandoned fork of a Symfony content-block library. It is not a platform, not a differentiator, and not something we should build a roadmap on. Content blocks — the ability for editors to assemble pages from reusable components — are commodity capability; the build-versus-buy question is about which maintained CMS/block layer we standardize on, not about this repository. Recommend we treat it as out of scope and, if we need this capability, evaluate the maintained upstream project or a stack-native alternative as part of the normal architecture review.

For engineering: Do not adopt rmzamora/block-bundle. It is archived, has zero stars and zero dependents, and is a personal fork of sonata-project/SonataBlockBundle — meaning zero security patching and zero upgrade path. It is also a Symfony bundle, so it is incompatible with our Laravel services in practice. If a team believes it contains a needed patch, the correct path is: identify the patch, apply it to the maintained upstream package or a fork we own and monitor, and record the decision in an ADR. Estimated effort to do this properly is hours, not days — there is no scenario where adopting an unmaintained third-party fork is the cheaper option once remediation risk is priced in.

Bottom line: Low opportunity, high tail risk. Reject for adoption; keep only as a reference for a patch we may want upstream.