Cms Core Bundle Laravel Package

Getting Started

Before anything else: this is not a Laravel package. PrestaCMSCoreBundle is a Symfony2 bundle built on the Symfony CMF stack (RoutingBundle, MenuBundle, BlockBundle, ContentBundle) with a Sonata Admin backend. Composer will happily resolve it on Packagist (presta/cms-core-bundle), but it will not boot inside a Laravel application — there is no service provider, no facade, no Eloquent anything. If you are staying on Laravel, treat this repository as reference material, not a dependency: read it to harvest patterns (page-tree routing, block-based composition, admin-editable content), then reimplement those on top of Laravel packages like spatie/laravel-menu, a nested-set/kalnoy/nestedset page table, and a livewire/filament block editor.

If you genuinely need to run it, you are committing to a legacy Symfony 2.x application (see composer.json in the repo — expect Symfony ~2.3, PHP >=5.3.3, Doctrine, and Sonata Admin of the same era). Minimal path:

1. Scaffold a Symfony Standard Edition app pinned to the versions the bundle's composer.json constraints allow.
2. composer require presta/cms-core-bundle (you will need minimum-stability tweaks and to pin old dependencies manually — Packagist metadata for 2015-era packages is unreliable against a modern PHP).
3. Register PrestaCMSCoreBundle plus its hard dependencies (PrestaCMSBlockBundle, PrestaCMSPageBundle, Symfony CMF bundles, SonataAdminBundle) in app/AppKernel.php.
4. Run the bundle's install command/migrations to create the page and block tables.
5. Look first at Resources/config/ (services and routing), then Entity/Page.php / Entity/Block.php, then Controller/ for the front-end rendering flow.

Your first real use case is the canonical one: a CMS page tree where each page is a route in the CMF chain and its body is composed of editable blocks. Create a page in Sonata Admin, assign it a template and a set of block containers, then visit its URL and watch the CMF router resolve the page before your application's controllers do.

Implementation Patterns

The bundle's whole value proposition is composition: a page is metadata + layout, and content lives in independent, admin-placeable blocks. Patterns worth studying (and porting):

• Page-as-route. PrestaCMSPageBundle hooks the CMF ChainRouter. Pages carry their own path and are matched before static routes, so editors create URLs without a deploy. Pattern to reuse: a Page model with path, template, parent_id, resolved by a catch-all route that runs last in your route table.
• Block containers. Pages are rendered from a template that declares named zones (main, sidebar, footer); blocks are attached to zones with a position. This is the "admin composes layout, developer owns the shell" split — the same idea behind Filament/Nova page builders.
• Block service/type system. Each block type (TextBlock, SimpleTextBlock, GalleryBlock…) is a service implementing a BlockServiceInterface with getType(), getFormSettings(), getFormFields(), render(). Reuse exactly this shape: a registry mapping a type string to a renderer class, plus a settings schema the admin UI can introspect.
• Twig-driven rendering. render(BlockInterface $block, Response $response) populates the response and returns template variables. Blocks render into the CMS's Twig layout; there is no JSON API here, so don't try to bolt a SPA onto it.
• Admin as the editor surface. Sonata Admin gives you CRUD for pages/blocks plus WYSIWYG fields. The integration tip: keep block settings in a serialized JSON column rather than a dedicated table per type — PrestaCMS mostly does this, and it saves a schema migration per new block type.
• Events for extension. The bundle dispatches lifecycle/exception events around page resolution (e.g. page-not-found), which is where you hook redirects, SEO metadata, or access checks. Register a listener rather than forking the controller.

Day-to-day workflow in such an app: developer writes a block service + Twig template → designer/editor drops blocks into a page zone via Sonata → routing is handled entirely by the page tree. Most "feature work" is adding a block type, not touching controllers.

Gotchas and Tips

• Archived, 2015, zero dependents. There will be no security fixes, no PHP 8 support, and no compatibility with modern Symfony. Running it means pinning an end-of-life PHP and a Symfony 2.3/2.4-era stack — a compliance problem, not just an inconvenience.
• Not installable on a fresh box without pinning. Composer's resolver will fight you on transitive constraints (Doctrine, Sonata, CMF). Use composer require --no-update and hand-edit composer.json, or vendor the source.
• CMF routing overrides everything. If your app's routes suddenly stop matching, the page tree probably has a catch-all page shadowing them. Debug with php app/console router:debug and remember the chain order matters.
• Symfony 2 debugging only. There is no Telescope equivalent. You get app/console, app_dev.php, and the (very good, for its time) Symfony profiler — the CMF panel shows the resolved content/page, which is the fastest way to understand a broken render.
• Extension points beat forks. Sonata Admin classes, block services, and event listeners are all overridable via bundle inheritance and service tagging; the bundle was written to be extended, so check Resources/config/*.xml for tags before patching vendor code.
• Templates are global. Twig template names are resolved by convention from the page/block config; a typo in template silently gives you an empty page rather than an error. Enable Twig strict variables in dev.
• Config quirks live in presta_cms_core: in config.yml — block container names and default templates must match the Twig files exactly, or blocks appear assigned but render nothing.
• Treat it as a design reference. For a Laravel codebase today, the honest move is to read Entity/, Block/, and Controller/ here for the page-tree + block-registry model, then build it with nestedset, a Filament resource for pages/blocks, and Livewire/Alpine for the block editor. That gets you the feature set without inheriting a decade-old EOL Symfony runtime.