- What is samuell/contenteditor-plugin and what does it do?
- It is a thin Laravel and OctoberCMS add-on that registers a service provider, routes, controllers, and a front-end JavaScript editor so you can edit page content in place. It writes flat content files such as markdown, HTML, Blade, or JSON back to disk, making the filesystem the source of truth. It suits small, single-tenant, file-backed sites rather than database-driven or multi-tenant applications. Expect to refactor Blade templates so editable regions are marked up before it is useful.
- How do I install samuell/contenteditor-plugin in a Laravel project?
- Composer require the package, publish its config and assets, mount the editor JavaScript on the pages you want editable, and wrap the package routes in your auth middleware. Most teams can have it running in staging in under a day. The real cost is marking up editable regions in Blade across every page, which scales linearly with page count. Verify the Composer constraints against your PHP and Laravel versions before committing.
- Is this package built for Laravel or for OctoberCMS?
- It is packaged as a plugin for OctoberCMS, which itself runs on Laravel, so the framework underneath is Laravel but the integration surface targets October's plugin conventions. If you are on a plain Laravel app you will need to adapt the service provider and route registration yourself. Do not assume it drops into a stock Laravel skeleton unchanged. Test the wiring in a scratch app before planning around it.
- Does samuell/contenteditor-plugin support Laravel 11 and Laravel 12?
- The last release dates to around 2023, which predates Laravel 11 and 12, so current-version compatibility is unproven. Check the composer.json constraints and run the test suite against your target LTS before adopting it. Treat compatibility as something you must test, not assume. Budget time for small patches if framework APIs or dependency constraints have shifted.
- Where does the package store edited content?
- It writes flat files such as markdown, HTML, Blade, or JSON directly to the local filesystem, which becomes the source of truth. There is no database persistence layer, no transactional store, and no evident pluggable storage driver. That makes it a fit for brochure sites, docs, and marketing pages, and a poor fit for anything DB-backed. Decide where write-back lands: either a persistent writable volume or a volume reconciled back to git.
- Can I use it with S3 storage or a multi-server deployment?
- Only local disk is supported as far as the package is concerned; there is no S3 or database driver. Read-only container filesystems, ephemeral PaaS storage, and multi-instance deployments will silently break or diverge because each instance writes to its own disk. If you must run multiple instances, mount the content directory on a shared volume and treat it as canonical. Serverless deployments are effectively out of scope.
- How do I protect the content editor routes from unauthorized users?
- Route protection appears to be middleware-dependent, so the host application must supply authentication and authorization. Wrap the package routes in your auth middleware and, ideally, a gate or policy restricted to a small trusted editor group. Test the unauthenticated path in staging before going live, because a misconfiguration exposes content mutation to anonymous users. Front-end file writing is an arbitrary-write primitive if paths are not canonicalized and whitelisted.
- Does the package sanitize HTML to prevent XSS attacks?
- Sanitization on write or read is not documented, so assume stored HTML is an XSS surface. Sanitize on output with a library such as HTML Purifier, or sanitize on write before persisting. Restrict the editor to trusted users and avoid rendering raw editor HTML in public views. Verify the current behavior against the source before relying on it.
- Does it offer revision history or concurrency control?
- There is no evident audit trail, versioning, or concurrency control, so expect last-write-wins lost updates when two editors touch the same file. Partial writes are also possible on failure. Add a versioning shim before real usage: a pre-write file copy, a git commit hook on the content directory, or a thin wrapper that snapshots the prior revision. That cheap step turns an unrecoverable failure mode into a recoverable one.
- Is the package actively maintained, and what are the alternatives?
- It has roughly 40 stars, zero dependents, a single maintainer, and a last release about two years old, so plan to fork it into your VCS, pin the version, and own patches. If that ownership burden is unacceptable, consider a headless CMS, Statamic, or a custom Laravel Nova or Filament admin for content editing. For a small brochure site with a trusted editor group, the file-based approach is still reasonable. For compliance, retention, or multi-tenant requirements, look elsewhere.