Simple Cms Bundle Laravel Package

Getting Started

First, the mismatch: wizin/simple-cms-bundle is a Symfony bundle, not a Laravel package. It will not composer require cleanly into a Laravel app — its transitive dependencies (Symfony framework/HttpKernel, Doctrine, Twig) collide with Laravel's container, routing, and Eloquent assumptions. The first step is deciding whether you are actually integrating this into Laravel (usually a bad idea) or evaluating it inside a small Symfony app that Laravel talks to over HTTP or a shared database.

Where to look first (in this order):

1. composer.json — check require for symfony/framework-bundle, doctrine/orm, twig/twig and their version pins. If it targets Symfony 3.x/4.x or PHP <8.1, it is effectively dead on arrival for a modern stack. Run composer why-not wizin/simple-cms-bundle in your project to see conflicts.
2. README.md — for a 0-star, 0-dependent package, the README is often the only documentation. If setup instructions are missing, treat installation as reverse-engineering work.
3. src/WizinSimpleCmsBundle.php — the bundle class tells you what it registers.
4. src/Resources/config/ — routing, services, and the configuration tree (Configuration.php / DependencyInjection/) define every knob you get.
5. src/Entity/ — the Doctrine models are the real data contract you will need to read from Laravel.

Minimal use in a Symfony sandbox:

composer require wizin/simple-cms-bundle
# config/bundles.php
Wizin\SimpleCmsBundle\WizinSimpleCmsBundle::class => ['all' => true],

Then import the bundle's routes (check Resources/config/routing.xml or .yaml), run bin/console doctrine:migrations:migrate if it ships migrations, and inspect bin/console debug:router for the admin/content endpoints.

First use case: run it read-only — render CMS-managed pages — before letting anyone write through its admin. That gives you a reversible experiment.

Implementation Patterns

Pattern 1 — HTTP boundary (recommended). Run the bundle in a minimal Symfony app as an internal service. Laravel calls it via a CmsClient class using Http::baseUrl(...), caches responses with Cache::remember, and never shares a database. This keeps Doctrine out of your Laravel composer graph entirely.

Pattern 2 — Shared database, read-only from Laravel. If you must, point Laravel at the same MySQL/Postgres and read the bundle's tables through DB::table('...') or a thin Eloquent model with $table and no migrations. Never let Laravel's migrate touch those tables — Doctrine owns the schema. Add a migration test that asserts the table list is unchanged.

Pattern 3 — Fork and own it. With zero dependents and MIT licensing, the realistic long-term move is copying the relevant entities/controllers into your own codebase. You get the feature without an unmaintained dependency, and you can swap Doctrine for Eloquent if you port it into Laravel.

Concept mapping while reading the source:

Integration tip: wrap whatever you choose in a single interface (PageRepository::findBySlug()), so a later swap to Statamic/Filament/a custom model touches one file.

Gotchas and Tips

• Bus factor of one (and zero). No stars, no dependents, no issue history means no security advisories and no upstream fixes. Pin the exact commit hash, vendor the code into packages/ or a private fork, and add it to your dependency-review list.
• Old Symfony constraints are the most common failure. Version pins in composer.json are the single biggest blocker. If they are strict (^2.8/^3.0), do not attempt to force modern PHP — fork and bump, or walk away.
• Doctrine vs Eloquent is a real hazard. Two ORMs on one schema produce duplicate migration ownership, timestamp-format drift, and null-handling differences. If patterns 2 applies, document which side owns writes.
• Assets and admin auth don't transfer. The bundle's admin uses Symfony's firewall and its own Twig layout. Laravel's auth middleware will not protect those routes. Put the Symfony app behind a reverse proxy with basic auth or SSO before exposing anything.
• Route collisions. A catch-all CMS route from the bundle will shadow Laravel routes if proxied carelessly. Scope it with a prefix (/cms) at the proxy or router level.
• Debugging toolkit: bin/console debug:router, debug:container --tag=..., debug:config wizin_simple_cms, lint:yaml config/, and the Symfony profiler. If the bundle fails silently, check that its config key is actually loaded — a typo in config/packages/*.yaml usually just yields "bundle not configured" errors deep in a service.
• Extension points, in order of safety: Twig template overrides in templates/bundles/WizinSimpleCmsBundle/, event subscribers, then bundle config, then a DI compiler pass, and only last a hard fork of the service definitions.
• Sanity check before committing: if the README does not tell you how to boot it, and the tests directory is absent or broken, the cost of adoption is likely higher than writing a simple Page model, a Blade admin, and a slug route in Laravel — roughly a day of work with no external risk.