Cms Bundle Laravel Package

Getting Started

Before anything else, note the fundamental mismatch: johnkrovitch/cms-bundle is a Symfony bundle, not a Laravel package. There is no service provider auto-discovery, no php artisan vendor:publish, and no Blade integration. If you are working in a Laravel codebase, you cannot composer require this and expect it to boot — Laravel does not load Symfony bundles. The realistic "getting started" path is either (a) you are actually maintaining a Symfony application, or (b) you are evaluating this as reference code for CMS concepts to port, not as a dependency.

Assuming a Symfony context:

1. composer require johnkrovitch/cms-bundle and confirm a compatible Symfony version (the last release is 2020, so expect Symfony 4.x/5.x era constraints).
2. Register the bundle manually in config/bundles.php — bundles of this vintage rarely ship Flex recipes, so automatic registration is unlikely.
3. Look first at the bundle's root class (*Bundle.php) and DependencyInjection/ for the extension and any config tree, then Resources/config/ for route, service, and template definitions. The README is the primary (and likely only) documentation.
4. Check whether the bundle ships Doctrine entities/mappings and whether it expects a specific admin layer (EasyAdmin, SonataAdmin) before wiring anything up.

First use case to validate: a single CMS-managed page or content block rendered through a Twig template. Attempt that end-to-end before committing to it — given the package's age and adoption, that smoke test is the real go/no-go.

Implementation Patterns

Since the bundle exposes Symfony services, the day-to-day patterns are standard Symfony ones translated from what you'd do in Laravel:

• Service wiring: dependency injection via the container, not facades. Where you'd reach for app() or a facade in Laravel, here you inject the CMS service through the constructor or fetch it in a controller.
• Configuration: publish/author your bundle config under config/packages/ and inspect the extension's Configuration class to know the exact keys. Do not guess keys from the README — read the tree.
• Rendering: Twig, not Blade. If you are pulling content into a Laravel view, you would need to build an HTTP or data-layer adapter rather than reusing Twig templates directly.
• Extending behavior: prefer Symfony's standard extension points — bundle config, event subscribers/listeners, and service decoration — over editing vendor code.
• Template overrides: for Symfony, override bundle templates by convention (templates/bundles/<BundleName>/...) rather than copying files into vendor.
• Integration tip for mixed teams: if a Laravel app genuinely needs this CMS's data, isolate it behind a thin repository/adapter class so the rest of the Laravel code never depends on Symfony container semantics. Do not attempt to bridge the two containers.

For workflows: model your content types against whatever entities the bundle ships, seed them, then render through the provided controllers/routes. Treat the bundle as the persistence + admin layer and keep your presentation layer thin so you can replace the bundle later.

Gotchas and Tips

• Abandonment risk is the headline. One star, zero dependents, last release October 2020, and an opportunity score near the bottom of the range. There is effectively no community, no issue triage, and no upgrade path. Budget for the possibility of forking and maintaining it yourself.
• Version compatibility will bite. A 2020 bundle predates Symfony 6 and modern PHP 8.x conventions. Expect deprecated APIs, missing type declarations, and possible composer conflicts with current Symfony components. Pin your framework version or expect to patch the bundle.
• Undocumented behavior. Assume the README is incomplete. The authoritative source is the code: DependencyInjection/Configuration.php for valid config keys, Resources/config/ for services and routes, and the entity mappings for the data model.
• Debugging in Symfony: use bin/console debug:container <service>, debug:router, and the profiler to confirm the bundle actually registered its services and routes. If pages 404 or services are missing, the bundle registration or route import is usually the culprit.
• Do not force it into Laravel. No amount of composer gymnastics makes a Symfony bundle run under Laravel's container. If the goal is a Laravel CMS, evaluate Laravel-native options (e.g., a headless CMS via API, or a maintained Laravel CMS package) instead.
• Extension points to lean on: service decoration and event listeners let you customize behavior without forking. If you must fork, keep your changes in a separate package so a future maintained replacement is a drop-in swap.
• Bottom line: treat this as reference material or a fork candidate, not a production dependency. For anything user-facing and long-lived, the maintenance cost almost certainly exceeds the value it provides.