Zero Gravity Cms Bundle Laravel Package

Getting Started

First, a reality check: despite the "Bundle" naming, this is a Symfony bundle, not a Laravel package. There is no service provider, no facade, no config/zero-gravity.php. If you're in a Laravel codebase, you cannot composer require this and start using it; it targets Symfony's kernel, service container, and typically Doctrine. Treat it as an external CMS you either (a) consume over HTTP, or (b) run as a separate Symfony application alongside your Laravel app.

Minimal steps once you've confirmed you actually have a Symfony context (or a standalone deployment):

1. composer require zero-gravity/zero-gravity-cms-bundle
2. Register the bundle in config/bundles.php:

   ZeroGravity\CmsBundle\ZeroGravityCmsBundle::class => ['all' => true],
   

3. Create the config file the bundle expects — check the repo's README.md and src/DependencyInjection/Configuration.php (or equivalent) for the exact root key and required nodes. This is the authoritative source; bundle config keys are almost never guessable.
4. Import the bundle's routing (typically @ZeroGravityCmsBundle/Resources/config/routing.xml or a routes.yaml in the repo) so its controllers are reachable.
5. Run bin/console debug:container --tag=... and bin/console debug:router to see what the bundle actually registered — this is your fastest map of the surface area.

Where to look first: README.md → src/DependencyInjection/ (config schema) → src/Resources/config/ (services and routes) → src/Controller/. That path tells you what's configurable, what's wired, and what endpoints exist before you read a single domain class.

First real use case: the bundle is a content management system, so the first thing to prove out is the content → render loop: define a content tree (pages/nodes) in whatever storage the bundle uses, configure routing so a page slug resolves, and confirm a request returns rendered content. If that loop doesn't work end-to-end in your environment, nothing else matters — stop and reassess.

For a Laravel-only team, the pragmatic entry point is different: run the Symfony app as a separate service (Docker container, subdomain like cms.internal, or a headless JSON endpoint) and have Laravel consume it via Http::baseUrl(...)->get('/api/pages/{slug}'). That keeps your Laravel developer experience intact and avoids dragging Symfony's container, Doctrine, and asset pipeline into your app.

Implementation Patterns

Pattern 1 — Separate service, Laravel as consumer (recommended). Run the CMS as its own deployable. In Laravel, wrap it in a thin client:

// app/Services/CmsClient.php
class CmsClient
{
    public function __construct(private PendingRequest $http) {}

    public function page(string $slug): ?array
    {
        return Cache::remember("cms.page.$slug", 300, fn () =>
            $this->http->get("/pages/$slug")->throw()->json()
        );
    }
}

Bind it in a service provider with Http::baseUrl(config('services.cms.url'))->withToken(...). This is the only pattern that scales for a Laravel shop — it isolates the Symfony runtime, keeps tests simple (Http::fake()), and lets you swap the CMS later.

Pattern 2 — Symfony app owns rendering, Laravel owns app logic. If the CMS must render HTML for SEO, let Symfony render public content routes and let Laravel handle authenticated app routes. Use a reverse proxy (Nginx location blocks or Traefik rules) to split traffic by path prefix. Keep session/cookie domains aligned or you'll get confusing auth bugs.

Pattern 3 — Content-as-data sync. If the bundle exposes content as structured data (pages, blocks, menus), sync it into your Laravel database on a schedule or webhook. Then Laravel queries locally — fast, no runtime coupling. Use a queued job with upsert() keyed on the CMS's stable content ID. This is the right pattern if page reads dominate and content changes are infrequent.

Workflow tips for the Symfony side (if you're touching it):

• Use bin/console debug:config zero_gravity_cms (name it per the bundle's actual alias) to dump the resolved config, not just what you wrote — bundles merge defaults in surprising ways.
• Register content types/routes through the bundle's extension points rather than editing vendor files; look for tagged services (debug:container --tag=) and compiler passes in src/DependencyInjection/Compiler/.
• Keep environment config in .env + config/packages/*.yaml, and commit a .env.dist with every key the bundle reads.

Integration tips:

• Put a contract test around the CMS HTTP surface (status codes, JSON shape) so a CMS upgrade fails loudly in CI, not in production.
• Version your CMS API path (/api/v1/...) from day one; bundles like this rarely guarantee BC on internal routes.
• If you need auth between Laravel and the CMS, use a service token header, not shared session cookies.

Gotchas and Tips

The framework mismatch is the first gotcha. Every Laravel instinct — php artisan vendor:publish, facades, Eloquent, config() — does not apply. If someone on the team reads "CMS Bundle" and assumes Laravel, you'll burn a day. State the Symfony dependency in your onboarding docs explicitly.

Signals to weigh before committing. The repository shows no stars and no dependents, and the opportunity score is low. That's not a verdict on quality, but it is a maintenance-risk signal: expect thin documentation, sparse examples, and no community answers when you hit an edge case. Budget time to read source rather than search for tutorials, and consider whether the team can own a fork if upstream goes quiet.

Config keys are not guessable. Symfony bundle config schemas live in DependencyInjection/Configuration.php. Read it. A typo'd key either throws a clear InvalidConfigurationException (good) or is silently ignored because the bundle didn't declare it (bad — you'll debug the wrong layer).

Service wiring failures look like runtime errors. If a dependency isn't registered, you often get a ServiceNotFoundException deep in a controller, not at boot. Run bin/console lint:container and bin/console debug:autowiring early and often; they catch most of this before you click around in a browser.

Routing is easy to half-configure. Importing the bundle's routes but forgetting the prefix, or configuring a route while the content resolver has no content, yields 404s that look like routing bugs but are content bugs. Test with a fixture page before debugging the router.

Doctrine assumptions. CMS bundles frequently assume Doctrine ORM (entities, migrations, a connection). If you're bridging into Laravel's Eloquent world, you cannot share a data layer — pick one owner per table. Don't let both frameworks write to the same schema.

Caching hides config changes. Symfony's container and router caches survive config edits in prod-like envs. Always bin/console cache:clear after touching config/ or .env, or you'll chase ghosts. In dev, confirm APP_ENV=dev and APP_DEBUG=1.

Extension points, if you need to customize: look for tagged services, event subscribers (KernelEvents), and compiler passes first. If the bundle exposes a content-type or renderer interface, implement that rather than subclassing internal classes — internal classes carry no BC promise.

Upgrade discipline. With no dependents, semver is likely aspirational. Pin the exact version in composer.json, read the diff on every bump, and keep the contract tests from the integration section running in CI. That's your real safety net.