Cms Sandbox Laravel Package

Getting Started

The premise of the previous assessment is now obsolete: this is no longer "an application you clone, it is a bundle you require." The release refactors the sandbox into a standalone bundle explicitly intended to be consumed by the separate symfony-prestacms project (the new home for the runnable demo/application skeleton). Adjust your mental model accordingly:

• presta/cms-sandbox-bundle (this repo) = the demo/reference bundle. It ships sample fixtures, demo theme templates, and example block service definitions — but no kernel, no app/, no parameters.yml.
• symfony-prestacms = the application. That is now where you clone, composer install, configure the DB, and boot.

Minimal steps:

1. Get the application first, not this package: clone symfony-prestacms, run composer install against its lock file. This bundle will arrive as a dependency (or be wired in a path repository during the transition — check its composer.json).
2. Register the bundle in app/AppKernel.php if it is not already registered, and import its config fragment in app/config/config.yml.
3. Copy parameters.yml.dist → parameters.yml, create the database, then the standard Symfony 2 sequence: doctrine:schema:create, doctrine:fixtures:load, assets:install --symlink, assetic:dump.
4. Boot app_dev.php and log into /admin.

Where to look first, in order:

• DependencyInjection/ and Resources/config/ — this is the new front door. With the application shell gone, the bundle's service definitions and extension class are the authoritative answer to "what does this wire up, and under which presta_cms_* keys."
• DataFixtures/ (if retained in the bundle) or the corresponding fixtures in symfony-prestacms — the page-tree and block fixtures remain the most instructive artifact: Page → Areas → Blocks composed programmatically.
• Resources/views/ — theme and block-template override conventions.
• composer.json of both repos — the split means version constraints between bundle and app are now a real compatibility surface, not a formality.

First use case: unchanged in spirit — stand up symfony-prestacms, edit a page in admin, drop a block into a zone, and trace fixture → page tree → rendered output. That loop still teaches the PrestaCMS content model faster than the nonexistent docs.

Implementation Patterns

The bundle split actually improves the viable patterns, because "harvest" can now mean "depend and override" rather than "fork the app."

• Depend-and-extend, not clone-and-strip. composer require the bundle into a Symfony 2 app, then delete/disable the demo fixtures and demo theme via config. This is the workflow the refactor was designed to enable; it is now the primary pattern instead of a workaround.
• Bundle inheritance for overrides. With a real bundle boundary, getParent()-style inheritance and app/Resources/<Bundle>/... template overrides are the clean extension points. Keep all overrides in your own bundle; never patch vendor/.
• Fixture-as-specification. Still the best way to author content: copy the fixture shapes for pages, routes, and block placement into your own bundle's fixtures rather than clicking through admin.
• Block service registration. Blocks are services tagged for the block bundle; the packaged service definitions are a working catalog for text, media, menu, and gallery block types. Copy the tag, not the class, when writing your own.
• Config fragment extraction. Lift the presta_cms_* blocks verbatim, but pin Symfony and CMF versions to whatever symfony-prestacms resolved. Bundle/app version skew is now the number-one breakage source — it replaces the old "mismatched core bundles" risk with a sharper one, because the split is fresh and tags may be inconsistent.
• Legacy maintenance: vendor both lock files (app and bundle), treat the tree as frozen, and isolate every upgrade attempt.

Gotchas and Tips

• The refactor is described in one sentence of release notes. No migration guide, no changelog detail, no version bump called out. Assume the split is mid-flight: check whether this repo still contains app-only artifacts (app/, web/, parameters.yml.dist) that the docs no longer mention, and whether a stable tag exists before pinning to dev-master.
• Old instructions no longer work. The previous "clone this repo and composer install" path is dead — the app lives in symfony-prestacms. Anything you read elsewhere that says otherwise predates this release.
• Still archived, still EOL, still PHP 5.4/5.5-era Symfony 2. The refactor is a maintenance convenience, not a revival. No security patches will arrive; do not put this in front of production traffic or the public internet.
• composer install remains fragile. Abandoned transitive dependencies, Packagist metadata drift, and old minimum-stability settings mean you often need --ignore-platform-reqs, an old PHP runtime (5.6 in a container), and a committed lock file. The split adds a new failure mode: the bundle and the app may disagree about which side owns a given dependency.
• Fixtures fail on modern MySQL. Strict mode and utf8mb4 defaults break the 2014-era schema and inserts; run MySQL/MariaDB permissively with utf8 defaults.
• Missing parameters.yml is still the classic first-run error — now in the application repo, not here.
• Asset pipeline is still the debugging rabbit hole. assets:install --symlink then assetic:dump, in that order; read app/logs/, not the browser console. In a bundle context, also confirm Resources/public/ is actually published by the install command.
• Debugging tools that still work: app/console debug:router, debug:container --tag=... to enumerate block services, debug:event-dispatcher for CMF listeners. With the bundle split, debug:container is more useful than ever for confirming the bundle's services loaded at all.
• For a Laravel shop specifically: nothing here changes the recommendation. If the goal is "a CMS on Symfony," modern Symfony CMF, Sylius Content, or a headless CMS behind an API are better investments. If the goal is learning PrestaCMS concepts for a legacy project, read the core bundles (presta/cms-core-bundle and friends) — this bundle shows what to configure, the core bundles show why.