Blog Bundle Laravel Package

Getting Started

Before writing any code, establish whether this package can run at all in your project. The bundle is abandoned, its last release was October 2013, and it targets the Symfony 2.2/2.3 era with PHPCR-ODM 1.0 and PHP 5.x. On Symfony 4+, PHP 7.2+, or any modern PHPCR-ODM it will not install or boot. That means there are exactly two realistic starting points:

• Legacy maintenance: you already have a Symfony 2.x CMF application pinned to doctrine/phpcr-odm ~1.0 and Jackalope. Vendor the source (fork to a private repo or use --prefer-source) and treat it as read-only reference code.
• Evaluation / harvest: you want the content model and controller flow as a reference for building blog functionality on today's CMF ContentBundle or plain Doctrine ORM. Clone the repo, do not require it.

Minimal steps for a legacy app:

{
    "require": {
        "symfony-cmf/blog-bundle": "dev-master",
        "doctrine/phpcr-odm": "~1.0",
        "jackalope/jackalope-doctrine-dbal": "~1.0",
        "symfony-cmf/routing-bundle": "~1.1",
        "symfony-cmf/core-bundle": "~1.1"
    },
    "minimum-stability": "dev"
}

Register Cmf\Bundle\BlogBundle\CmfBlogBundle in AppKernel, configure a doctrine_phpcr session with Jackalope, then enable cmf_core and cmf_routing. Expect to fight Composer resolution; pin every transitive dependency or copy the bundle into src/.

Where to look first, in this order:

1. Document/ — the persistence model (blog post and any tag/category documents). This is the package's real value.
2. Controller/ — the frontend list/show actions and their template calls.
3. Resources/config/ — routing definitions and service wiring; this tells you which controller IDs you can override.
4. DependencyInjection/Configuration.php — the actual config keys; do not guess them from blog posts, the docs for this bundle are thin.
5. Resources/views/ — the template names you will need to override.

First use case: create one post in PHPCR via a console command or data fixture, expose it at a URL through CMF routing, and render the bundle's index action. That single vertical slice proves the ODM mapping, the routing document, and the template override all work before you invest in customization.

$post = new Acme\BlogBundle\Document\BlogPost();
$post->setTitle('Hello');
$post->setBody('First post');
$post->setParent($dm->find(null, '/cms/blog'));
$dm->persist($post);
$dm->flush();

Verify method names against the vendored source — the API is 2013-vintage and not what modern tutorials show.

Implementation Patterns

Extend the document, don't edit the bundle. Create your own Document/BlogPost in your app namespace extending the bundle's class (or implementing its interface, if one exists) and re-declare the full PHPCR-ODM mapping. Old ODM versions do not reliably inherit class-level annotations, so copy the mapping metadata and add your fields (author, publishedAt, tags) alongside it. Keeping your class separate means the bundle's controllers accept it via the interface while your app owns the schema.

Persistence and lookup. Always resolve a parent node before persisting; PHPCR is a tree and orphan documents are the most common beginner error. Use DocumentManager::find(null, '/cms/blog/my-post') for path lookups and the ODM query builder for listings (order by a date property stored as a date type, not a string). Cache query results only after you have confirmed the Jackalope backend invalidates correctly.

Routing. Two viable patterns:

• CMF dynamic routing: attach a CMF Route document to the post and let cmf_routing resolve /blog/{slug}. This is the intended design and gives you editable URLs, but it means every post has two documents to persist and a route cache to clear.
• Static routes: point a normal Symfony route at the bundle controller and pass the slug. Simpler, faster to debug, and the right choice if editors do not need to change URLs.

Templates. Override in app/Resources/CmfBlogBundle/views/... (Symfony 2 convention). Read the controller's getTemplate() calls rather than guessing filenames.

Admin and workflow. Pair the documents with Sonata Admin via doctrine/phpcr-odm-admin-bundle, or use the CMF tree browser for a lighter touch. Publishing is not built in — the bundle predates cmf/publish-workflow-bundle, so wire publish/unpublish states yourself with an ODM prePersist listener, or accept immediate publication.

Integration tips. Keep blog content under a dedicated base path away from system routes and menus. Use data fixtures for local development so every developer gets the same tree. If you are harvesting rather than maintaining, port Document/ to Doctrine ORM entities or CMF ContentBundle documents and preserve the URL shape with redirects — that is where the migration value sits.

Gotchas and Tips

• Abandonment is the headline risk. No security patches, no PHP 8 compatibility, no Symfony 4+ support. Do not introduce this into anything with a multi-year lifespan; budget for migration at the same time as adoption.
• Version skew. The bundle assumes PHPCR-ODM 1.0 APIs (getReferrers, old PersistentCollection behavior, annotation driver defaults). Newer ODM releases change these silently or loudly. Lock composer.lock and never run composer update on a working legacy app.
• Backend differences. Jackalope Doctrine DBAL and Jackalope Jackrabbit differ in node type support and query features. Develop against the backend you deploy; a query that works locally on DBAL may fail on Jackrabbit.
• Mapping inheritance. As above: re-declare fields when extending documents. Missing one field produces a document that saves but silently drops data.
• Routing cache. CMF routes are documents; after changing a route you often need cache:clear plus a check of the cmf_routing dynamic route provider config. A 404 on a persisted post is almost always a route document that was never flushed or a stale provider cache.
• Debugging. Use the PHPCR dump command (check doctrine:phpcr:dump vs phpcr:dump for your version) to inspect the tree, and the CMF tree browser in dev. Log the DocumentManager during persist/flush; PHPCR exceptions are terse.
• Extension points. Prefer overriding service definitions and template paths over editing the bundle. If a service ID is unclear, read Resources/config/*.xml; controller IDs follow the bundle's naming and are stable enough to override. ODM event listeners are the cleanest place for slugs, timestamps, and publish state.
• Testing. There is no maintained test suite. Write your own functional tests against an in-memory Jackalope DBAL session, and assert both the rendered output and the resulting PHPCR tree — the tree assertion catches the mapping and routing failures that a 200 response hides.