Cms Sandbox Bundle Laravel Package

Getting Started

The first thing to understand is that this is not a Laravel package and cannot be installed into a Laravel application. presta/cms-sandbox-bundle is a Symfony 2 bundle sitting on Symfony CMF (Doctrine PHPCR-ODM), Sonata Admin, and Twig. The latest release clarifies its intended role: it has been refactored from a self-contained sandbox/demo application into a standalone bundle that is meant to be included by the separate symfony-prestacms project. So the repo is no longer the "run me" demo — it is a component of a larger Symfony application you would get from the other repo. It remains archived-era (last tagged release 2014-03-04) and there is still no maintained install path.

Minimal steps, if you want to evaluate it anyway:

1. Do not composer require it into a Laravel project. Expect resolution failures or an incompatible Symfony 2 / PHPCR / Sonata dependency tree.
2. Clone the repo and read in this order:
   • composer.json — confirms the Symfony 2.x / CMF dependency surface and, post-refactor, what the bundle now expects the host app (i.e. symfony-prestacms) to provide.
   • README.md — now points at symfony-prestacms as the place to actually stand up an application.
   • Resources/config/ and the bundle's DI extension — how PrestaCMS services are wired.
   • symfony-prestacms itself — that is where the app skeleton, config, and fixtures now live.
3. First real use case: treat the pair of repos as reference documentation. This bundle is the clearest end-to-end example of how PrestaCMS models pages, blocks, templates, and admin editing; read it to extract a content model, not to run it.

If you genuinely need to run it, you must stand up symfony-prestacms on a Symfony 2.x-era PHP runtime, not a Laravel app — which is almost never worth it today.

Implementation Patterns

There is no day-to-day Laravel usage pattern because the code is not Laravel code. The realistic pattern is concept mining and porting:

• Content tree → Eloquent. PrestaCMS stores pages as a hierarchical document tree (PHPCR). In Laravel, map this to a nested-set or adjacency-list table (pages with parent_id, path, position) and use route-model binding or a slug/path resolver for URLs.
• Block renderers → Blade components. PrestaCMS composes a page from typed blocks each with a renderer/service. Port this to Blade components or view composers keyed by a type column (blocks table: page_id, type, settings JSON), resolved through a small registry/service provider.
• Admin editing → Filament/Nova. The Sonata Admin editing experience is the part worth studying; rebuild it with Filament resources rather than trying to reuse anything.
• Fixtures → seeders. Demo fixtures (now living in symfony-prestacms) are a good template for what a seeded page/block graph should look like in your own DatabaseSeeder.
• i18n. PrestaCMS's per-locale content approach informs a page_translations / JSON-column design, or spatie/laravel-translatable.
• Dynamic routing. CMF's dynamic route provider has no direct analogue; use a catch-all route + a PageResolver that walks the tree, with a cached path→page map.
• Bundle/host split as a design lesson. The refactor is itself instructive: separating a reusable package from the host application (services, config, routes) is exactly the discipline you want in a Laravel package — src/ plus a service provider plus publishable config, with the app owning wiring.

If you must study the actual Symfony wiring (service definitions, bundle extension, template overrides), do it in a disposable Symfony 2 environment built from symfony-prestacms — but keep that entirely separate from any Laravel codebase.

Gotchas and Tips

• Archived and abandoned. Last release 2014; Symfony 2.x and PHP 5.x are long EOL. Do not deploy it, and do not pull it in as a transitive dependency — treat the repos as read-only documentation.
• The refactor changes packaging, not viability. It is now a bundle consumed by symfony-prestacms rather than a runnable sandbox. That removes an ambiguity ("where's the app?") but adds a dependency on a second archived repo — installing this alone gets you nothing runnable. Release notes are terse; verify against the actual tag before relying on paths.
• No stable public API. Even as a standalone bundle, the demo-era service IDs, template names, and DI extension surface were never a compatibility contract. Anything you "depend on" can change or vanish.
• Composer will fight you. Illuminate/Symfony version constraints, PHPCR-ODM, and Sonata packages collide with any modern Laravel (illuminate/* 10/11/12) install. Expect resolution failures, not a clean install.
• Config quirks. It assumes a full Symfony app skeleton (parameters.yml, PHPCR session config, registered CMF/Sonata bundles), now supplied by symfony-prestacms. There is no Laravel service provider, no config publishing, no facade — none of the ergonomics you expect from a Laravel package.
• Extension points are Symfony-shaped. Overriding means Twig template overrides and DI service decoration — concepts that don't translate to Laravel's container/Blade model. Don't try to bridge them.
• Debugging. Nothing here runs on a current PHP without a heavy downgrade and pinned legacy dependencies; invest debugging time in your own port instead.
• Practical verdict. For a Laravel developer, the day-to-day leverage is still essentially zero at runtime. The release is a maintenance/organization change (extract bundle, host app elsewhere), not a modernization. Its only value is as an architectural reference for page/block CMS composition and package/host separation — read it briefly and build the Laravel-native equivalent yourself.