Inline Editing Bundle Laravel Package

Getting Started

xcore/inline-editing-bundle is a Symfony bundle built for XCore CMS — not a Laravel package. Despite the naming and your familiarity with package/, there is no ServiceProvider, no facade, no config/inline-editing.php. A Laravel developer's first decision is whether to (a) study it as reference architecture and port the pattern, or (b) actually run it inside a Symfony/XCore application.

First 15 minutes:

1. Confirm the composer.json "type" field — it will be symfony-bundle. This immediately tells you composer require into a Laravel app installs the files but wires up nothing.
2. Open src/ and find the class that extends Bundle (typically InlineEditingBundle.php). That file lists the service and template wiring.
3. Look at src/Controller/ first — the save endpoint(s) hold the entire feature. This is the piece you are re-implementing.
4. Then src/Twig/ for the front-end helper (the analogue of a Blade component / directive).
5. Then src/EventSubscriber/ or src/EventListener/ for cache-invalidation and re-render hooks.
6. Resources/config/ (routes, services) — this is the wiring you need to translate into routes/web.php and a service provider.

First use case to target: a single editable field (a blog post title, or body) that an authenticated editor can click into, edit in place, and persist with an AJAX round-trip returning fresh HTML. That is the shortest path to understanding the package's entire value proposition.

If you're building the Laravel equivalent, plan on: a PATCH /inline/{model}/{id}/{field} route, a Gate/Policy for field-level authorization, a Blade component <x-inline-editor :model="$post" field="title" />, and Alpine.js (or Turbo/Hotwire) for the click-to-edit toggle. You are not importing the bundle — you are reading it to copy the shape.

Implementation Patterns

The editable-region helper. The bundle exposes a Twig function that wraps a template region in the metadata required for click-to-edit: content type, identifier, field name, and current value. The Blade equivalent is a component that renders the same data-* attributes and lets your JS controller POST on blur:

<x-inline-editor :model="$post" field="title" :value="$post->title" />

Keep the server-rendered value inside the element so it degrades without JS.

Save endpoint shape. The bundle's controller pattern is: resolve the entity by identifier → check permission → validate the incoming value → persist → return updated payload (or a redirect for non-AJAX). Mirror it exactly in Laravel:

Route::patch('/inline/{model}/{id}/{field}', [InlineEditController::class, 'update'])
    ->middleware(['auth', 'verified']);

Inside update, resolve through a server-side field whitelist, authorize via $this->authorize('editField', [$model, $field]), sanitize if rich text, and return JSON with rendered HTML or a 204.

Content-type registry (polymorphism). The bundle is designed around multiple content types. In Laravel this is a Relation::morphMap() plus your own registry mapping a client token to a model class. Never trust the client-supplied model string — resolve it through the registry:

$class = ContentTypes::resolve($request->string('type'));
abort_unless($class && class_exists($class), 422);
abort_unless(in_array($field, $class::editableFields(), true), 422);

Event-driven invalidation. The bundle fires events on save so caches can be cleared and derived data re-rendered. Laravel maps this cleanly to an observer plus an event/job:

Post::updated(fn ($post) => ContentUpdated::dispatch($post));
// listeners: CacheBuster, SearchIndexer, SitemapBuilder

Edit-mode toggle. The bundle is typically gated behind an "edit mode" session flag so anonymous traffic gets cached, unadorned HTML. Replicate with middleware that sets session(['edit_mode' => true]) for authorized users, then wrap the edit wrappers in @if (editMode()) so production HTML is not bloated by the wrapper markup.

Progressive enhancement. Keep the inline edit region an actual <form> (even a hidden one) so no-JS submission works, and layer JS on top for the inline UX. This is the pattern the bundle's Twig partials follow and it is the right pattern to carry into Laravel.

Gotchas and Tips

• This is not installable in Laravel. type: symfony-bundle means the bundle only auto-registers through config/bundles.php in Symfony. composer require will succeed, but no routes, no Twig helpers, no listeners will exist in a Laravel app. Don't spend an afternoon wondering why the endpoint 404s.
• Twig vs Blade is the largest porting cost. Copy the markup, not the templating. Twig's attribute() and filter chaining do not map 1:1; rewrite the helpers as Blade components or a custom directive rather than trying to shim Twig into Laravel.
• Doctrine vs Eloquent. The controller will likely use an EntityManager and Doctrine repository. In Laravel this becomes Model::find() with findOrFail and a $fillable/$guarded awareness. Whitelist the editable field set explicitly — the Doctrine version relies on entity metadata, which does not exist in Eloquent.
• CSRF token name. Symfony and Laravel both use _token, but they're validated by different middleware. If you lift JS from the bundle, regenerate headers with csrf_token() or @csrf — don't hardcode.
• Rich text is the real XSS risk. Inline editing + HTML means every save is a potential injection point. The bundle ships server-side sanitization (usually via HTMLPurifier or a Symfony sanitizer). In Laravel use mews/purifier or HTMLPurifier directly; strip_tags is not enough and htmlspecialchars will destroy formatting. Sanitize on save, render-safe on display.
• Concurrency is unhandled in the simple path. Two admins editing the same field will silently clobber. Add an updated_at (or version) check on save and return 409 Conflict when it moved. This is an improvement to make over copying the bundle's simpler controller.
• Field whitelisting is non-negotiable. Without a per-model editableFields() list, a malicious client can patch is_admin, price, or published_at. The bundle relies on content-type configuration for this; in Laravel there is no equivalent, so you must build it.
• Caching fights edit mode. Full-page response caching and inline editing coexist badly. Either vary the cache key on the edit-mode cookie, or serve edit mode from a separate route (/edit/{slug}) that bypasses the cache entirely.
• Asset pipeline mismatch. The bundle ships Webpack Encore config; Laravel has moved to Vite. If you port the JS, rewrite the entry config — don't copy webpack.config.js and expect it to work.
• Extension points if you fork (and you probably should): for a Symfony project, override services in config/services.yaml, override templates in Resources/views/, and decorate the save handler rather than editing the controller directly. In Laravel terms, translate that into a config-driven controller + an interface you can swap.
• Community support is effectively zero. 9 stars, 0 dependents means no one is patching this for you. Treat it as a well-structured reference implementation to read once and re-implement — not a dependency to lean on in production.
• Debugging in a Symfony sandbox: use the Profiler's Request panel to inspect the save payload and Response panel to see exactly what the controller returns. The bundle's error paths surface there rather than in storage/logs.