Content Bundle Laravel Package

Getting Started

This is a Symfony 2 bundle, not a Laravel package — do not attempt composer require. Treat koala/content-bundle as a read-only reference for the inline-edit-over-entity pattern, then port the pattern into Laravel. There is no service provider, facade, Blade views, or Eloquent model here, and the Symfony/PHP constraints will not resolve against any supported Laravel version.

• First, confirm the host stack: open composer.json and read the Symfony, Doctrine, Twig, and PHP constraints. Symfony ^2.3 is incompatible with Laravel's symfony/* ^6/^7 requirements — Composer will fail before any code runs.
• Then read the code in this order:
  • composer.json — dependency floor and confirmed Symfony 2 target
  • KoalaContentBundle.php — bundle registration class (no equivalent in Laravel)
  • DependencyInjection/ — configurable entity classes and service wiring; this is where "what's pluggable" is defined
  • Resources/config/routing.yml — the exposed save/load routes you'll be re-modeling
  • Entity/ — the content/page persistence model; map these fields to Eloquent migrations
  • Controller/ — the editor↔persistence contract (save/load endpoints)
  • Resources/views/ — Twig partials that emit editable region markup
  • Resources/public/ — the Mercury Editor JS/CSS payload (do not port this)
• Minimal Symfony 2 steps (for context only, not Laravel): register in app/AppKernel.php, import routing, configure Doctrine mapping, run a schema migration, publish assets, and firewall the editor routes.
• First Laravel use case: create a Page model, a ContentBlock model, a Blade partial per editable region, a JSON save endpoint with auth + CSRF + sanitization, and a maintained editor (TipTap, Trix, Editor.js, or ProseMirror). That is the entire first slice; the bundle tells you what the endpoints and region model looked like circa Symfony 2, nothing more.

Implementation Patterns

The reusable IP is the data model + interaction contract, not the code. Extract these patterns:

• Content types → Eloquent models. Map the bundle's Doctrine entities to Page and ContentBlock models with explicit title, slug, body (HTML), status, published_at, and timestamps. If the original schema conflates page and block, split them — block reuse is the feature that justified a CMS layer in the first place.
• Editable regions keyed per page. In Blade, emit regions with stable keys and data attributes (data-region="hero.body"). The editor writes to a keyed region, not the whole document; this keeps saves small and conflict-prone edits isolated.
• Save-on-blur / per-region endpoint. The bundle's controller contract is a thin "region key → content → 204". Rebuild as a throttled POST /pages/{page}/regions/{region} route with a FormRequest, a policy check, and JSON response. This is where the original's value lies — the shape of that contract, not the Symfony controller.
• Rendering separation. Store HTML (sanitized) and render in Blade with {!! !!} — or, better, store structured field JSON and render via Blade components. Do not render raw stored HTML without server-side purification.
• Revisioning. The original almost certainly has no revision table. Add ContentRevision (page_id, region, body, editor_id, created_at) on save. This gives you an audit trail and a migration story if content moves later.
• Editor asset pipeline. Do not reuse Resources/public/ (Mercury). Wire TipTap/ProseMirror as a Vite entrypoint, initialize it per editable region in a small JS module, and feature-flag inline editing so it can be disabled per environment.
• Integration tip: wrap the save logic in a ContentRegionService and call it from both the controller and any queue/CLI import path. Keep the editor JS dumb — all validation and sanitization on the server.

Gotchas and Tips

• Composer will fail. Do not try to install. The Symfony ^2.3 pins are unresolvable against Laravel 9+ (^6.0), Laravel 10 (^6.3), and Laravel 11 (^7.0). This is the first and most likely failure mode.
• No Laravel equivalents exist here. No service provider, no facades, no Eloquent, no Blade views, no config publishing. Any "integration" is a port, not an install.
• Mercury Editor is dead. It depends on jQuery, contenteditable, Rangy, and execCommand — deprecated APIs that fail silently or corrupt content on modern browsers. If you port it, you will lose data on save with no error visible to the user.
• Stored XSS is the highest-severity risk. Do not render editor HTML without server-side purification (mews/purifier). The original bundle likely lacks this; do not inherit the gap.
• Protect the save routes. The Symfony 2 bundle's controllers predate modern authorization expectations. In Laravel, put every save endpoint behind a Gate/policy and CSRF; validate that the editor owns the page before writing a region.
• Debugging hint: if inline saves appear to succeed but nothing changes, check the browser network tab first (silent client failure from the deprecated editor) and then the sanitizer (content stripped on the server before persistence). Log both sides of the save route.
• Extension points you can keep conceptually: region keys, per-region save contract, and block reuse. Everything else — DI wiring, Twig partials, Doctrine mapping, asset publishing — is framework-specific and should be reimplemented, not carried over.
• If a legacy Symfony 2 estate genuinely exists, do not share code with Laravel. Isolate it behind an HTTP boundary, treat it as a black box, and plan its replacement separately.
• Calibrate on the scoring dashboard: opportunity: 0.71 here reflects supply scarcity, not market pull. Do not triage this as a hidden gem; the archived status, 10 stars, and 0 dependents are the real signals.