Product Decisions This Supports
- Build vs. buy for the page-authoring surface. This is a buy-side signal, not a buy recommendation: a reusable block/component model, templating, and translatable block values are a solved problem, and the real cost of a visual builder sits in the admin editor, not the front-end render. Use this package's scope to size what you'd otherwise build internally — if your need is a handful of block types on top of Twig, that's weeks, not quarters.
- Scope discipline on the "headless CMS" question. The bundle gives you pages composed of components, renderable via Twig with per-block i18n. That covers marketing pages, portals, internal dashboards, editorial landing pages. It does not give you an editorial workflow, versioning/draft-publish, approval states, or a media library — those are the things that actually determine whether content teams adopt a builder. Deciding "builder, not CMS" is the decision this enables.
- Roadmap: i18n as a first-class requirement, not a later migration. Translatable block values are baked in at the block level. If multi-language content is on your roadmap at all, retrofitting it into a self-built builder is a data-model rewrite. This is a genuine argument to adopt a block-based model early.
- Framework/platform modernization as a roadmap item. Release 8.0.2 exists solely because Symfony 8 removed
Request::get(), which broke admin component editing with an UndefinedMethodError. That tells you what this package is: version-coupled to Symfony's major release cadence. Budget an upgrade window each time Symfony majors — the package is tracking Symfony, not insulating you from it.
- Not a Laravel decision. Despite the framing, this is a Symfony bundle (PHP >= 8.4, Symfony ^8.0, hard dependency on
akyos/core-bundle). If the codebase is Laravel, the decision is closed: do not port, do not wrap. Evaluate Laravel-side equivalents (Filament builders, block-editor packages) against the same criteria below.
- Vendor concentration risk as a standing agenda item. 0 stars, 0 dependents, single-vendor (Akyos), French-only docs, and a transitive dependency on that same vendor's CoreBundle. That's a maintenance bet, not just a library choice — it belongs in the same conversation as any other single-vendor dependency.
When to Consider This Package
Consider it when all of the following hold:
- The stack is Symfony 8+ on PHP 8.4+, and you have a team that reads Symfony bundles comfortably (French docs are not a blocker).
- You need block/component-based page composition with translated values and Twig output — and your front-end is Twig, not a decoupled SPA.
- You are willing to own the integration layer: template overrides, custom block types via
AbstractBlockType, and your own admin smoke test around the component editor. Treat this as a starter kit you extend, not a product you consume.
- Multi-language content is a present or near-term requirement — that's where the package earns its keep.
Look elsewhere (or build) when:
- Any part of the stack is Laravel. Hard stop.
- You need editorial-grade CMS features: drafts, scheduled publishing, revision history, roles per page, media management. Nothing in this scope covers that, and you'll be building it on top of an unproven base.
- You need a decoupled/headless API-first builder. There are API Platform hints, but nothing that reads as a supported headless surface.
- You need vendor support, an SLA, or a community to lean on for debugging. Zero dependents and zero stars means zero external bug-finding. Your team is the community.
- You're mid-migration or can't absorb a Symfony-major-blocking dependency each cycle.
If you proceed: pin ^8.0.2 as the floor, run the admin component-editor flow (add → edit → save) as a day-one smoke test, and grep your own code for request->get( before you call the upgrade done.
How to Pitch It (Stakeholders)
For executives: A visual page builder is expensive to build and undifferentiated — the value is in your content and components, not the editor. This package offers a shortcut to a block-based, translatable page builder on Symfony 8, which is why it's worth a look at all. But be clear-eyed: it's a single-vendor, near-zero-adoption component (0 stars, 0 dependents, French-only docs) that we would be adopting as a foundation and maintaining ourselves. Recommendation is a time-boxed spike against our actual requirements, not a commitment — the go/no-go question is whether the editor and block model save us more time than we'd spend owning the dependency. It is also Symfony-only; if we're on Laravel, this evaluation is a comparison exercise, not a candidate.
For engineering: Symfony 8 / PHP 8.4 only, hard dependency on akyos/core-bundle. You'll extend it, not just install it — custom block types via AbstractBlockType tagged akyos_builder.block_type, template overrides by copying into templates/akyos_builder/. The 8.0.2 release is a Request::get() removal fix (Symfony 8 UndefinedMethodError in the admin component editor) — pin at or above it, and audit our own request handling for the same pattern, since our code around the editor will break identically. Expect this dependency to gate our Symfony major upgrades. Budget caching for block-heavy pages and a functional test on the admin editor as the first thing we write.