Cms Bundle Laravel Package

Getting Started

The first thing to understand is that this is not a Laravel package. Despite landing in a Laravel-focused workflow, vince/cms-bundle is a Symfony 2.3 bundle — its service providers are Symfony Bundle classes, its configuration is services.yml / config.yml, and its extension points are Symfony DI compiler passes and Twig. If you are on Laravel, there is no adapter and no realistic path to using it directly; treat this assessment as guidance for the scenario where you have inherited a Symfony 2.3 application and this bundle is already in composer.json.

Confirm the environment before anything else:

# You must be on the Symfony 2.3 LTS line (PHP 5.3.3 – 5.5.x)
composer show vince/cms-bundle
php -v

Registration in a Symfony 2.3 app happens in app/AppKernel.php, not a service provider:

// app/AppKernel.php
public function registerBundles()
{
    $bundles = array(
        // ...
        new Vince\CmsBundle\VinceCmsBundle(),
    );
}

Look first at DependencyInjection/Configuration.php and Resources/config/services.yml inside the bundle — those files reveal the actual configuration tree and the services the bundle wires up. Then inspect Entity/ to understand the content model (expect Page, Content, Block, Menu style entities) and Resources/views/Admin/ for the admin Twig templates.

First use case: render a CMS-managed page by slug from a controller, typically through a repository call rather than a Laravel-style facade:

// src/AppBundle/Controller/PageController.php
public function showAction($slug)
{
    $em  = $this->getDoctrine()->getManager();
    $page = $em->getRepository('VinceCmsBundle:Page')
               ->findOneBySlug($slug);

    if (!$page) {
        throw $this->createNotFoundException();
    }

    return $this->render('VinceCmsBundle:Page:show.html.twig', array(
        'page' => $page,
    ));
}

Because the bundle is archived with zero dependents, do not expect a working README walkthrough that matches modern dependency versions. Pin the bundle to the last tag and freeze your Composer lock file; treat any upgrade as a fork-and-maintain operation rather than a routine composer update.

Implementation Patterns

Entity-driven content, not configuration-driven. This bundle predates the "headless CMS" pattern. Content lives in Doctrine entities you can query and hydrate like any other; there are no content-type "models" configured in a control panel. Day-to-day work means writing Doctrine DQL/SQL against the CMS tables, joining on slug or path, and caching the results because PHP 5.3-era code rarely has query caching enabled by default.

Controller → repository → Twig. The idiomatic flow is a thin controller that pulls a page or block from the Doctrine repository and hands it to a Twig template. For reusable page fragments (headers, footers, sidebar blocks), look for a Twig extension or render(controller(...)) pattern in Resources/views/:

{# Twig: render a managed block by name #}
{% block sidebar %}
    {{ render(controller('VinceCmsBundle:Block:show', { 'name': 'sidebar' })) }}
{% endblock %}

Routing conventions. With no auto-magic router, register bundle routes explicitly — either import them or define catch-all page routes:

# app/config/routing.yml
vince_cms_pages:
    resource: "@VinceCmsBundle/Resources/config/routing.yml"
    prefix:   /

catch_all_page:
    path: /{slug}
    defaults: { _controller: VinceCmsBundle:Page:show }
    requirements: { slug: "[a-z0-9\-]+" }

Admin integration through Sonata. Bundles of this vintage commonly piggyback on sonata-project/admin-bundle for the admin UI. Inspect Admin/ in the bundle — if it ships PageAdmin, ContentAdmin classes, the daily workflow is: configure Sonata, register those admin classes in app/config/config.yml, secure them behind a firewall, and let editors manage pages there. If it does not ship admins, you will be writing the CRUD forms yourself in the style of the era (FormBuilder with createForm(...), handleRequest($request)).

Service extension for custom logic. The intended extension point is the service container. Override a bundle service by declaring a class with the same service ID in your app's services.yml and configuring it with the bundle's parameters. For custom content rendering, create a Twig extension that resolves a content entity to its rendered output rather than embedding entity-aware logic in your controllers.

Gotchas and Tips

The archived status is the headline gotcha. Zero stars, zero dependents, archived, described as "basic features for Symfony 2.3." Do not adopt this bundle for new work, and if you inherit it, treat every composer update as potentially breaking. Freeze composer.lock, and plan a replacement path — usually rewriting the handful of Doctrine queries you actually use against a maintained alternative (or plain Doctrine) rather than trying to modernize the bundle.

PHP and Symfony version walls. Symfony 2.3 is EOL, and this bundle's code targets PHP 5.3/5.4 idioms (array() syntax, no scalar type hints). It will not run under Symfony 3+, and it will not load on PHP 8 without a compatibility shim. If your CI runs modern PHP, you need a separate legacy container or a pinned Docker image.

Doctrine mapping drift. Entity annotations (@ORM\Entity, @ORM\Column) in an old bundle frequently conflict with your app's Doctrine version — mismatched doctrine/orm minors cause silent mapping errors (missing nullable, unrecognized enum column types). Run php app/console doctrine:schema:validate before and after enabling the bundle, and inspect the generated schema with doctrine:schema:update --dump-sql rather than blindly applying it.

No Laravel-style package discovery or facades. There is no config/cms.php, no CMS::page(), no Eloquent model to ->with() and paginate. Everything goes through Doctrine + the Symfony container, and configuration is tree-based YAML. If you are a Laravel dev helping out, budget time for Symfony 2 mental model differences: explicit service registration, no auto-wiring, Twig instead of Blade.

Debugging the wiring. When a page renders empty, the failure is usually in service registration, not the entity. Use app/console container:debug (Symfony 2.3) to list registered services, debug:router to confirm routes, and Symfony's profiler at /_profiler to inspect Doctrine queries and rendered Twig. If Twig throws a "service not found" error, the bundle is registered in AppKernel but its services.yml was not imported — check VinceCmsBundle/DependencyInjection/VinceCmsExtension.php.

Template overriding. The reliable extension point is Twig template override: copy a template from Resources/views/ into app/Resources/VinceCmsBundle/views/ at the same relative path and Symfony's loader picks yours first. This is the safest way to restyle the admin or front-end without touching vendored code.

Security of the admin area. Do not expose bundle admin routes without a firewall. In Symfony 2.3's security config, put them behind a form_login or http_basic provider:

# app/config/security.yml
access_control:
    - { path: ^/admin, roles: ROLE_ADMIN }

Migration off-ramp. Because the schema is simple Doctrine entities, the cleanest path is to keep the database, drop the bundle, and re-point your controllers at your own repositories. Backfill a lightweight read layer over the existing CMS tables first, verify parity, then replace the admin UI with whatever your team standardizes on. Do not attempt to port the bundle to a newer Symfony — the effort exceeds a rewrite.

No vendor support. With no maintainers and no dependents, there is no upstream to file issues against. If you fork, that fork becomes your maintenance burden; document every patch you apply inside the vendored directory, or better, copy the code into src/ so it is unambiguously yours.