Cmf Laravel Package

Getting Started

• Confirm the fit first. This is a Symfony CMF fork, not a Laravel package. Day-to-day use means a Symfony application with Doctrine PHPCR ODM, Symfony bundles, and a PHPCR content repository (Jackrabbit or doctrine/phpcr-dbal). If you are in a Laravel codebase, do not expect an Eloquent-style integration; you would be running a Symfony kernel or extracting concepts rather than installing this directly.
• Install and inspect what it replaces. Run composer require goldbroker/cmf, then read vendor/goldbroker/cmf/composer.json. The fork exists to merge abandoned symfony-cmf/* packages, so check its replace/provide entries and confirm whether it is a drop-in for the old packages or uses renamed namespaces such as GoldBroker\CMF\....
• Register the bundles it ships. Enable the CMF bundles in config/bundles.php — typically the core, content, menu, routing, and block bundles. If the fork kept Symfony CMF namespaces, these will look like Symfony\Cmf\Bundle\...; if it renamed them, use the classes actually present under vendor/goldbroker/cmf.
• Configure PHPCR early. Create config/packages/doctrine_phpcr.yaml with a session, workspace, and connection. For local development, the simplest path is usually doctrine/phpcr-dbal with a relational database; for production parity with Jackrabbit, configure the Jackrabbit session instead.
• Initialize the workspace and node types. Run the PHPCR initialization commands, for example bin/console doctrine:phpcr:database:init and bin/console doctrine:phpcr:workspace:create <workspace>. Missing node types are a common first-run failure.
• First use case: a page tree with routing and a menu. Model a Page document with a title, body, parent, and children; let RoutingAuto create a route from the page hierarchy; render the page through a content controller; render navigation with the CMF menu provider. That single vertical slice exercises the package’s main value: content documents, automatic routes, tree-based menus, and admin editing.
• Where to look first. Read the package’s composer.json, bundle registration, and tests before the upstream Symfony CMF docs. The upstream docs are still the best conceptual reference, but the fork’s source and tests are the source of truth for namespace and version differences.

Implementation Patterns

• Use PHPCR documents as your content model. Extend the CMF content base classes and map fields with Doctrine PHPCR ODM annotations or attributes. Keep business logic out of documents; put it in services and controllers.
• Model hierarchy explicitly. Use ParentDocument and Children mappings for page trees. This is what enables tree browsing, menu generation, and parent-aware routing. Avoid ad-hoc parent references that bypass the hierarchy.
• Prefer automatic routing for editorial content. RoutingAuto is the day-to-day workhorse: a page gets a route based on its title and parent path, so editors do not create routes manually. For custom URL rules, implement a route provider or a custom route enhancer rather than hard-coding routes in controllers.
• Generate menus from the content tree. The CMF menu provider turns document children into menu items. Customize with menu voters and builders for visibility, publishing state, and permissions. Do not maintain a second navigation structure in parallel with the content tree unless you have a strong reason.
• Use blocks for reusable content. Treat blocks as content documents rendered through the block helper. This is the cleanest way to handle promos, sidebars, and shared fragments without duplicating fields across pages.
• Keep controllers thin. Use the provided content controller for standard page rendering, and write custom controllers only for application-specific behavior. Resolve content through the content repository or route provider rather than querying PHPCR directly in templates.
• Integrate incrementally into an existing Symfony app. Mount CMF under a content subtree and keep your existing Doctrine entities separate. Map between them by ID or reference where necessary; do not try to make CMF the persistence layer for the whole application.
• Plan for multi-language and publishing from the start. Use translatable documents and locale-aware routes if you need i18n. If you need editorial workflows, model publishing state explicitly and enforce it in route providers, menu voters, and controllers; otherwise unpublished content can leak through generated routes.
• Use Twig helpers rather than custom rendering code. cmf_render_block, menu rendering helpers, and content helpers keep templates consistent with the package’s expectations.
• Extend through services and tagged extensions. Custom document classes, route providers, menu voters, block services, and admin extensions are the supported extension points. Prefer these over monkey-patching vendor code.

Gotchas and Tips

• This is a low-adoption fork. Zero stars and zero dependents mean you are effectively the maintainer of your own fork. Pin an exact version, commit the lock file, and be prepared to vendor or patch. Audit the release tag and changelog before upgrading; the listed release date is unusual enough to verify.
• Media adapters are being pruned. v1.2.6 removes the unused Gaufrette media adapters. If you wired media handling through those adapter services, your container will fail to compile or your media documents will fall back to a different adapter after upgrade. Grep your config and code for Gaufrette service IDs before bumping, and treat this as a small breaking change even though it is a patch release — it confirms the fork will drop dead integrations without a major version bump.
• Do not install it alongside the original symfony-cmf/* packages. Namespace and service collisions are likely. Check replace/conflict rules and remove the abandoned packages first.
• PHPCR is the biggest operational hurdle. Jackrabbit and doctrine/phpcr-dbal behave differently for node types, workspace setup, and queries. Document your chosen backend and initialization steps; a fresh environment that skips workspace setup will fail in confusing ways.
• Debug with the PHPCR commands, not var_dump. Use bin/console doctrine:phpcr:node:dump, workspace commands, and debug:container to inspect services. Most “content is missing” issues are wrong workspace, wrong base path, or missing node types.
• Watch performance on tree traversal. Menu rendering and child loading can become expensive on large trees. Cache rendered menus and routes, and avoid loading full child collections when you only need counts or titles.
• Upstream documentation will drift. Symfony CMF docs describe the original packages, and each fork release widens the gap — v1.2.6 is already removing components the upstream docs still describe. When behavior differs, read the fork’s tests and service definitions. Treat the tests as executable documentation.
• Admin UI dependencies are fragile. If the fork includes Sonata Admin integration, pin compatible Sonata versions and verify assets compile. Admin integration is often the first thing to break on a Symfony upgrade.
• Enforce publishing and permissions at every entry point. Routes, menus, blocks, and search all need to respect unpublished or unauthorized content. A route provider that ignores state is a common source of accidental exposure.
• Test against a disposable PHPCR workspace. Load fixtures, exercise routing and menu generation, and tear down the workspace. Do not point tests at a shared repository.
• Keep an exit plan. Because the package is a merged fork of abandoned components, isolate CMF-specific code behind your own services and interfaces. That makes it feasible to replace routing, menus, or the content repository later without rewriting the application.