Cms Theme Basic Bundle Laravel Package

Getting Started

This is a Symfony 2 / Symfony CMF bundle, not a Laravel package — there is no service provider, no config/*.php, and no artisan command. If you are a Laravel developer inheriting a PrestaCMS project, treat it like a legacy Blade/Livewire theme package you did not write: you consume it, you rarely extend it, and you should expect to read its source more than its docs.

Minimal path:

1. Confirm the host stack first. You need a PrestaCMS application running Symfony 2.x with presta/cms-theme-bundle already installed and configured. This bundle only supplies theme definitions, templates, and assets; it does nothing on its own.
2. Install into the existing app (Composer V1-era metadata, so expect to fight version constraints):

   composer require "presta/cms-theme-basic-bundle:dev-master"
   php app/console assets:install web --symlink
   

3. Register the bundle in app/AppKernel.php inside registerBundles().
4. Look here first, in this order:
   • DependencyInjection/Configuration.php — the actual knobs (theme name, paths).
   • Resources/views/ — layout and page templates; this is the real API.
   • Resources/public/ — CSS/JS/images the theme ships.
   • The theme definition class/Resources/config/*.yml — how the theme registers itself with PrestaCMSThemeBundle.
5. First use case: enable the Basic theme for a site/channel in app/config/config.yml under the PrestaCMS theme section, clear the cache, and load a page in the admin to confirm the layout renders. This is the fastest smoke test that the bundle is wired correctly.

Implementation Patterns

Treat the theme as a starting point, not a dependency. The upstream description says it exists to give beginners a working theme and serve as an example for custom themes. The highest-value pattern is: copy Resources/views and Resources/public into your own bundle, rename the theme, and stop upgrading the vendor package.

Theme selection per site/channel. PrestaCMS supports multiple themes across sites. Configure the Basic theme as the active theme for one site while developing your own, so front-end output is stable during migration.

Template override via Symfony bundle inheritance. Don't edit the vendor directory. Override in:

app/Resources/PrestaCMSThemeBasicBundle/views/

This is the Laravel equivalent of publishing vendor views — but Symfony does it automatically by path convention, so a file with a matching name silently wins. Use this for layout tweaks; fork the bundle only for structural changes.

Block/zone composition. PrestaCMS pages are assembled from CMS blocks rendered into theme zones. Most day-to-day work is editing block templates in your override path and leaving the theme's page skeleton untouched. If a zone looks empty, the problem is almost always block/zone configuration, not the theme.

Asset pipeline is Assetic-era. Reference theme assets through the bundle path (@PrestaCMSThemeBasicBundle/Resources/public/...) and run assetic:dump after changes. Modern webpack/Vite will not integrate without you replacing the asset tags in the layout templates.

Use it as a reference implementation. When building a custom PrestaCMS theme, keep Basic installed alongside yours and diff your theme definition and directory structure against it. That is genuinely the most useful thing this package does in 2024.

Gotchas and Tips

This package is archived, unmaintained, and last released in September 2013. There will be no fixes. Pin it to an exact commit in composer.json or vendor it into src/ so a future composer update cannot silently change or drop it.

Composer will likely refuse to install it cleanly. Release metadata predates modern Symfony/PHP constraints. Expect to either add "minimum-stability": "dev" temporarily, use a repositories entry pointing at a fork with a patched composer.json, or install with --ignore-platform-reqs in an isolated environment only.

Symfony version ceiling. Written for Symfony 2.1–2.3 with the CMF bundle set of that era. Running it on Symfony 3+ requires patching deprecated Twig syntax, service definitions, and possibly app/console references. Do not attempt this casually.

Assets break silently. Relative asset paths in 2013-era templates commonly 404 after assets:install if the target directory differs. Run assets:install --symlink and check web/bundles/prestacmstheme basic/ exists; if not, the layout will render unstyled and look like a Twig bug.

Theme "not applying" is usually configuration, not the bundle. Check the site's theme setting, then app/console debug:container | grep presta (or container:debug on 2.1) to verify the theme is registered. app/console config:dump-reference presta_cms_theme shows the accepted keys.

Twig inheritance causes "wrong template" confusion. A same-named template in app/Resources/... beats the bundle version with no warning. When debugging unexpected output, search the whole project for the template name before reading the vendor bundle.

Security. Outdated dependencies with no security patches. Never expose this stack to the public internet without a full dependency audit and isolation; for greenfield work, use a maintained CMS with a supported framework version instead.