Roger Cms Bundle Laravel Package

Getting Started

Read this first: theodo/roger-cms-bundle is not a Laravel package. It is a Symfony2 bundle (a port of Radiant CMS), and it predates Laravel 4. There is no service provider, no config/roger-cms.php, and no php artisan commands. As a Laravel developer you will only touch this if you inherit a legacy Symfony 2.0/2.1 application that already depends on it — you cannot composer require it into a modern Laravel app, and you should not try to port it.

If you do inherit such a project, look at these files first, in this order:

1. composer.json — pin down the exact symfony/symfony constraint. Anything below 2.1 means the controller/request APIs are the pre-2.1 style ($this->get('request'), $this->render() with different signatures).
2. DependencyInjection/TheodoRogerCmsExtension.php and Configuration.php — the config tree shows every knob (theodo_roger_cms: root key), including which entity classes and tag handlers are wired.
3. Resources/config/*.yml|xml — service wiring for the page repository, renderer, and tag handlers. This tells you what is overridable.
4. Entity/Page.php, Entity/PagePart.php, Entity/Layout.php, Entity/Snippet.php — the Radiant content model: a page tree, each page owning page parts, inheriting a layout, with snippets as shared fragments.
5. The tag/parser directory (look for a Radius-style tag handler or parser class) — this is where <r:content />-style tags are resolved.

First use case: register the bundle in app/AppKernel.php, import its routing in app/config/routing.yml, run php app/console doctrine:schema:update --force (this era predates Doctrine migrations), then build a three-page tree with one layout and render it through the bundle's catch-all front controller.

Implementation Patterns

Page tree as the content model. Pages are Doctrine entities with a parent/child relation and a slug. URLs are resolved by walking the tree by slug path rather than by Symfony routes — the bundle typically exposes one catch-all route (/{slug} with a default) that hands off to a page-resolver service. Keep that route last in routing.yml so your real application routes win.

Layouts + page parts. A layout is the HTML shell containing tag placeholders; each editable region is a page part. Editors change page parts in the admin, developers change the layout. Treat layouts as code (version them), page parts as data (do not).

{# layout stored in the DB or in Resources/views — check which this build supports #}
<html><body>
  <r:content part="body" />
  <r:snippet name="footer" />
</body></html>

Snippets for reuse. Snippets are global named fragments referenced by tag, the Radiant equivalent of a partial. Prefer snippets over copy-pasted markup across layouts; they are the one place a non-developer can safely edit shared chrome.

Custom tags as the extension point. When you need dynamic content, implement a tag handler and register it as a tagged service. This is the idiomatic way to add "latest 5 posts" or a contact form into a page body without giving editors raw PHP. Keep handlers thin — resolve data via your own services, return a string or a rendered template.

Caching. There is no cache invalidation layer worth relying on. The pragmatic pattern is to render a page to a string, store it keyed by page id + updated timestamp, and purge on the Doctrine postUpdate/postPersist events for Page. Do not cache inside the tag handlers.

Admin integration. The bundle ships CRUD controllers and form types. Extend the form types rather than editing vendor code, and override templates by shadowing them under app/Resources/TheodoRogerCmsBundle/views/. Protect the admin routes behind a firewall in security.yml — assume the bundle's own access control is minimal.

Gotchas and Tips

• It will not install on modern PHP. Expect each(), old-style constructors, and Doctrine annotations using the pre-@ORM namespace aliases. Running it on PHP 8 is a rewrite, not a config change. If you must keep it alive, pin PHP 5.6/7.0 in a container and freeze the dependency tree.
• Symfony 2.0 vs 2.1+ API drift. Controller::render(), request access, and the getRequest() deprecation all changed mid-2.x. If you are on 2.1+, some controllers in this bundle may already be subtly wrong; check for $this->get('request') and $this->container->get(...) patterns before debugging your own code.
• Config tree strictness. The extension validates its config; unknown keys throw at cache warmup, not at runtime. When something "silently doesn't work," run php app/console config:dump-reference theodo_roger_cms (2.1+) or read Configuration.php directly.
• Tag parsing and escaping. These parsers are usually regex-driven and are the number one source of "my HTML disappeared." Test tags in isolation with a minimal layout before blaming the page. Escape user-supplied page-part content at render time, not at save time, or you will double-escape when switching renderers.
• Doctrine schema is manual. No migrations in this era. doctrine:schema:update --dump-sql before --force, every time; the page tree's self-referencing foreign key is easy to break on a partial update.
• Cache clearing after content edits. The bundle's page resolution and any layout compilation are cached in app/cache. Editors who "don't see their change" usually need a cache clear — wire that into your publish action early.
• Zero dependents, 60 stars. There is effectively no community to ask. Read the source; it is small enough to fully audit in an afternoon, and you will need to.
• Extension points worth using: tag handlers (dynamic content), overriding the page/layout entity classes via the config tree if the bundle supports it, and template shadowing. Avoid subclassing the controllers — they are coupled to the container.
• Migration advice: if this is a greenfield project, do not adopt it. Model pages as Eloquent/Doctrine entities in your own app, store layouts as Blade/Twig files, and use a real editor integration. The only durable idea worth stealing from Roger is the layout/page-part/snippet separation, which maps cleanly onto any modern CMS or a small custom implementation.