Contenteditor Plugin Laravel Package

Getting Started

Before you install anything, read the source. With 40 stars, zero dependents, and a last release from September 2023, you are effectively adopting a small, single-maintainer package. Budget 20 minutes to open vendor/samuell1/contenteditor-plugin/src after install and confirm the actual class names, config keys, and event names — the README is thin and API details below are illustrative.

1. Install

   composer require samuell1/contenteditor-plugin
   

   Then list what's publishable so you know what you're getting:

   php artisan vendor:publish --provider="Samuell1\ContentEditor\ContentEditorServiceProvider"
   

   Pick the contenteditor-config / contenteditor-assets tags explicitly rather than running a blanket publish — blanket publishes can drag in unrelated tags.

2. If it's a Filament plugin (likely given the naming), register it on the panel rather than globally:

   public function panel(Panel $panel): Panel
   {
       return $panel->plugins([
           \Samuell1\ContentEditor\ContentEditorPlugin::make(),
       ]);
   }
   

   If instead it registers a service provider + routes, confirm the routes appear with php artisan route:list | grep content.

3. First use case — prove the round trip on one page. Take a single marketing page (not app UI). Mark one region as editable using whatever convention the package uses (a Blade directive, a data-content-editable attribute, or a component wrapper — check the views the package ships). Then:

   • Load the page with APP_DEBUG=true and confirm the editor JS is actually injected (view source, not just the network tab).
   • Click, edit, save.
   • Verify the write landed where you expect: tail storage/logs/laravel.log and inspect the file or DB row directly.
   • Reload in a fresh private window to confirm it's persisted, not just patched in the DOM.

4. Look first at: the service provider (what it binds/registers), the config file (storage path, allowed extensions, middleware), and the save controller/action (that's your security surface).

Implementation Patterns

Scope it to content, not app UI. The package is designed for front-end pages — landing pages, marketing copy, legal pages, docs. Do not point it at arbitrary Blade views or it becomes an unauthenticated file_put_contents primitive.

Storage strategy — pick one and stick to it:

• File-based (what the description implies): editable regions live as HTML/markdown files under something like resources/content/pages/*.html or storage/app/content/. Simple, diffable, git-friendly. Downside: no per-user audit trail or drafts unless you build it.
• DB-backed: if the package exposes a storage contract/driver, implement it against an Eloquent model so you get updated_by, timestamps, and revisions for free. This is the path to take anything past a prototype.

Gate it hard. Wrap the editor routes in your own middleware, not just the package's:

// routes/web.php or the panel's auth stack
Route::middleware(['auth', 'can:edit-content'])->group(function () {
    // package routes, or a thin wrapper controller
});

Define a edit-content gate tied to a role/permission. Never rely on the editor being "hidden" in the UI — the save endpoint is the thing that matters.

Draft → preview → publish cycle. The cleanest pattern with a file-backed editor:

• Save writes to a draft/ copy.
• A preview route renders the draft for the editor only.
• Publish promotes draft → live (copy + cache bust).
• If the package has no native draft support, this is a ~50-line wrapper around its save call, and it's worth it.

Cache invalidation is on you. If you render stored HTML inside a cached fragment or compiled Blade, saving content does nothing visible until the cache clears. Hook the package's post-save event (check src/Events) or wrap the save in your own service that also calls Cache::forget("page:{$slug}"). Without this you'll spend an afternoon debugging "my changes don't save."

Sanitize on save, escape on render. Stored HTML is user input:

use Symfony\Component\HtmlSanitizer\HtmlSanitizer;

$clean = $sanitizer->sanitize($request->input('content'));

Then render with {!! $clean !!} — raw output is only safe because sanitization happened upstream. Do not skip either half.

Integrate via a thin adapter. Rather than scattering package calls across Blade files, put the read/write behind your own class (ContentRepository), so swapping the package out later is a one-file change. Given the maintenance profile, that adapter is your insurance policy.

Gotchas and Tips

• Maintenance risk is the headline. Zero dependents and an 18-month-old last release means: no community answers, no upstream fixes, Laravel-major upgrades are your problem. Pin it exactly ("samuell1/contenteditor-plugin": "1.0.3" or whatever the tag is — not ^1.0) and vendor-fork it if you ship to production. A private fork with your own namespace is cheap.
• Verify framework compatibility immediately. Check composer.json for illuminate/* constraints against your Laravel version. A package this quiet was almost certainly not tested on Laravel 11/12.
• Asset publishing overwrites. vendor:publish --force after every composer update will clobber any custom CSS/JS you edited in public/vendor/.... Keep customizations in your own asset pipeline instead.
• File paths and permissions. Ensure the content root is outside public/ (so nothing is directly executable) and owned by the web user. Watch for traversal if any slug/path segment comes from the request — validate against an allowlist of registered pages.
• CSRF on the save endpoint. It's an AJAX POST; if you get 419s, it's a missing token in the fetch headers, not a package bug. Verify how the package's JS obtains the token.
• Config vs. view cache. After touching the config, run php artisan config:clear. If content is compiled into a Blade view, view:clear too — stale config is the #1 cause of "it's ignoring my settings."
• Debugging the save path. Log the raw payload in the save action (Log::debug('content save', $request->all())) before it hits disk. Most failures are a field-name mismatch between the JS widget and the controller, which is silent.
• Testing. Use Storage::fake('content') to assert file writes, and Http::fake() isn't useful here — hit the real save route with actingAs($admin) and assert the 200 plus the persisted artifact.
• Extension points to look for in src/: a config-driven storagedriver/disk, an afterSave event, and published views you can override via resources/views/vendor/contenteditor. Those three give you 90% of customization without touching vendor code.
• Escape hatch. If the package's save logic fights you, the editor front-end is usually the hard part and the storage is trivial. You can keep the JS widget and replace the backend with a 30-line controller of your own — often a better bet than debugging an unmaintained save pipeline.