Ckeditor Laravel Package

Getting Started

This is a single-purpose add-on: it gives the Cruddy admin panel a CKEditor-backed field type so a textarea becomes a WYSIWYG HTML editor. It is a very small package (2 stars, no dependents), so treat the source as the documentation.

1. Install into an existing Laravel app that already has Cruddy wired up:

   composer require cruddy/ckeditor
   

2. Publish what ships. The repo is small; check src/ for a service provider and resources/ for Blade views, JS, and config. If the provider isn't auto-discovered, register it in config/app.php, then:

   php artisan vendor:publish --provider="Cruddy\Ckeditor\CkeditorServiceProvider"
   

   (Confirm the exact namespace/provider name from composer.json and src/ — don't assume.)
3. Look first at the field class and its Blade view. That tells you the field type string to use in your resource definition and which CKEditor build/version is bundled. The bundled CKEditor version is the single most important thing to know before you build on it.
4. First use case: open one Cruddy resource that currently uses a plain textarea, swap the field to the CKEditor type, save a record, and confirm the HTML round-trips. Do this on a throwaway resource before touching production content models.

Implementation Patterns

Basic field swap in a Cruddy resource definition. Cruddy resources declare fields declaratively; the package registers a field type you reference there. The pattern is the same as any other Cruddy field:

// Pseudocode — verify the exact key/class against the package source
$this->fields = [
    'body' => [
        'label' => 'Body',
        'type'  => 'ckeditor', // or the field class the package exposes
    ],
];

Store HTML, render deliberately. CKEditor submits HTML, so the column must be text/longText. On the front end you must render it unescaped ({!! $model->body !!}) — which means the trust boundary moves to whoever can edit. If non-admins can edit, sanitize on save (HTMLPurifier or mews/purifier) rather than trusting the client.

Split field configs for different content. A short "summary" field and a long "article body" field rarely want the same toolbar. Configure per-field options (toolbar items, height, allowed content) in the field definition rather than globally, so you don't ship a full toolbar to a caption field.

Uploads. CKEditor's image/link dialogs need an endpoint. Either point the editor's upload config at an existing Laravel upload route you control (with auth + validation + storage disk), or disable uploads entirely and let users paste URLs. Do not let the package's default config, if any, point at a third-party CDN uploader.

Multiple editors per form. Each field instance needs its own unique editor instance. If you render several CKEditor fields on one Cruddy form, verify the package's init code keys off the field id/name; naive document.querySelector('.ckeditor')-style init will only wire the first one.

Livewire / Turbo / SPA-style navigation. If your admin uses Livewire or Turbo, editors must be explicitly destroyed and re-initialized on component teardown/mount. Plan for a small destroy()/init() JS hook; this is the most common integration failure with any CKEditor wrapper.

Gotchas and Tips

• Maintenance risk is the headline. 2 stars, 0 dependents means no community safety net: no Stack Overflow answers, no forks to crib fixes from, and possible drift from current Laravel/Cruddy/CKEditor releases. Pin the version in composer.json and budget time to read the source when something breaks.
• CKEditor 4 vs 5 matters enormously. They are different products with different APIs, licensing (CKEditor 5 is GPL/commercial), and init code. Confirm which one is bundled before writing any custom toolbar or plugin config; config written for one will silently do nothing on the other.
• Asset pipeline. If the package ships prebuilt JS/CSS, it likely bypasses Vite/Mix. That's fine until you need cache-busting or a custom build. Know whether you're loading from public/vendor/... or from node_modules, and check that php artisan vendor:publish actually copied the assets after deploy (a classic "works locally, blank editor in prod" cause).
• XSS is your responsibility, not the editor's. The toolbar restricts the UI, not the request. A user can POST arbitrary HTML to the endpoint. Sanitize server-side on save.
• Debugging checklist when the editor doesn't appear: browser console for a missing CKEDITOR/ClassicEditor global (asset not loaded), check the textarea still exists in the DOM with the expected id, check for a JS error from a previous field's init aborting the rest, and check that your published view override didn't drop the init script.
• Override the view, don't fork the package. Copy the package Blade view into your app's view namespace and adjust toolbar/height there. Keeps upgrades (however infrequent) possible.
• Extension points to check for first: published config file (toolbar presets), the Blade view (init options), and whether the field class is subclassable so you can add your own defaults without editing vendor code.
• Have a graceful fallback. If you disable JS or the CDN is unreachable, the user should still get a usable textarea, not a blank box. Verify the underlying <textarea> is populated with existing content before init.