Livewire Editorjs Laravel Package

Technical Evaluation

• What the package actually is: thin glue between Laravel Livewire and Editor.js — a service provider, one Livewire component, a Blade view, and publishable JS/CSS assets. Content is persisted as Editor.js block JSON rather than HTML. There is still no admin UI, no renderer, and no content API — but as of v1.5.0 it does now offer a configurable storage folder for uploaded images, so the package has begun to absorb part of the media pipeline rather than leaving it entirely to the integrator.
• Architecture fit: good fit for a Laravel monolith on Livewire + Blade that needs structured, block-based authoring (paragraph, header, list, image, embed) stored as JSON. Better fit than previously assessed for Laravel 9/10 estates, since v1.5.0 explicitly adds Laravel 10 support. Still a poor fit if the product needs WYSIWYG HTML, server-rendered SEO content out of the box, or a vendor-supported component with a formal deprecation policy.
• Integration feasibility: high for a proof of concept, and now slightly higher for production-adjacent work. composer require, publish assets and config, drop the component into a form, bind to a JSON/text column, point the new image-folder setting at the right disk. The real cost still sits downstream: sanitization, schema validation, renderer ownership, and upgrade patches — though the image path story is now a config concern rather than a from-scratch build.
• Technical risk: moderate (down from high). The April 2023 "archived, 0 dependents, no upgrade path" picture is no longer accurate: v1.5.0 was published, Laravel 10 is supported, Editor.js was bumped 2.22.3 → 2.26.5, and a new external contributor landed the image-folder feature. That is evidence of a live maintainer and a real (if small) user base. Residual risks:
  • Bus factor remains ~1.5. One maintainer plus one drive-by contributor is not a support contract. Release cadence over the prior two years was zero, so a future dormancy is plausible.
  • Livewire 3 is still unverified. Laravel 10 support does not imply Livewire 3 support; the component's property-binding and lifecycle hooks are the likeliest breakage point. Treat this as the gating unknown.
  • Editor.js 2.22 → 2.26 is a multi-minor jump. Block tool APIs and serialized output can shift across that range; any pinned third-party tools in our install must be bumped in lockstep or the editor will misbehave at author time and emit unknown blocks.
  • New write path. The image-folder feature means the package now writes files to disk. Upload validation, size/dimension limits, filename hygiene, and orphan cleanup are still ours, but the failure surface has moved into our code path rather than sitting outside it.
  • Stored JSON rendered to HTML without a sanitizer remains a live XSS vector. Upstream has not taken this on.
• Key questions:
  • What is our Livewire version today and our upgrade window? Has anyone verified v1.5.0 against Livewire 3, or only against the Livewire 2 constraints it declares? This is the single question that determines fork-vs-depend.
  • Where does the new image-folder config point in each environment — local disk, S3, a CDN-backed bucket? Is it set per-environment, or will staging and production silently diverge?
  • Which block types are genuinely in scope versus nice-to-have? Custom blocks are where the JS effort lives, and Editor.js 2.26 tool compatibility must be confirmed for each.
  • Are our Editor.js tools pinned in package.json and bundled, or CDN-loaded? Post-bump, unpinned tools are the most likely source of silent breakage.
  • Who consumes the stored JSON (Blade partial, API, mobile), and who owns sanitization at render time?
  • Do we need content portability — export to HTML/Markdown, and a schema version field on the document?
  • Given upstream is now responsive, do we contribute patches upstream (Livewire 3 support, sanitizer hooks) instead of forking? Forking a live project forfeits free future work; depending on it forfeits control.
  • Is Editor.js a product requirement or a UI preference? Alternatives (Tiptap, Filament RichEditor, a maintained block editor) may still cost less over 24 months.

Integration Approach

• Stack fit: Laravel 9/10-era conventions, Livewire 2 (Livewire 3 unconfirmed), Blade, optionally Tailwind. Client-side Editor.js needs asset publishing and a JS init hook. No migrations required beyond adding a JSON/text column and, if using the new feature, a configured image directory. In a Filament admin it remains a custom form field, not a first-class component.
• Migration path:
  1. Time-boxed spike on a branch against our actual Laravel and Livewire versions: install, publish assets and config, set the image folder per environment, wire to a real model, round-trip a document through save/reload including an image upload, test on staging with the production asset pipeline.
  2. Decision gate — now a three-way rather than a two-way: (a) depend on the released package with a pinned version, (b) depend plus upstream PRs for Livewire 3 / sanitization, or (c) fork to acme/editorjs-laravel. Prefer (a)/(b) while upstream is active; keep (c) as the fallback if Livewire 3 support stalls. Whichever we pick, pin the Editor.js version and commit built assets rather than relying on CDN.
  3. Harden: whitelist block schema in validation, add a renderer with a sanitizer (HTMLPurifier or block-to-HTML mapping), constrain the new upload path with MIME/size/dimension limits and a cleanup job, and confirm the folder config resolves through Laravel's storage abstraction rather than a hardcoded path.
  4. Re-verify all block tools against Editor.js 2.26.5 and update our bundle; log unknown block types on save so schema drift surfaces early.
  5. Document and hand off with a runbook, a pinned-version manifest, and a "known limitations" page.
• Compatibility: verify composer constraints against current PHP/Laravel and against Livewire 3 explicitly before committing — Laravel 10 support was added, Livewire 3 was not. Pin the full Editor.js tool set to versions compatible with 2.26.5. Treat any CDN-loaded plugin as an uncontrolled dependency. Confirm the Livewire property-binding style (wire:model defer/live semantics) matches the version in use. Confirm the image-folder config behaves identically on local disk and S3.
• Sequencing: spike (≤1 sprint) → dependency-vs-upstream-vs-fork decision (add ~1 sprint of hardening if we fork or upstream) → pilot on one low-risk content type → broaden. Store both the raw block JSON and a derived, sanitized HTML column so a future editor swap — or a forced migration off this package — is a re-render, not a re-authoring project. This storage/renderer decoupling remains the single most valuable architectural decision a TPM can force here.

Operational Impact

• Maintenance: still ours, but with a better outlook. Budget ~1–2 dev-days per quarter to track upstream releases and bump Editor.js tooling, plus a named owner. Upstream is alive again, so dependency bumps may be a version change rather than a patch we write — but the two-year dormancy means we should not assume cadence. Monitor JS dependency advisories directly; no formal security response process exists. Every Livewire major upgrade is still our work unless we contribute it upstream.
• Support: community-only, single primary maintainer. Issues and PRs are live (v1.5.0 included an external contribution), which is a meaningful improvement over an archived repo — but there is no SLA, no LTS, and no deprecation policy. Requires an internal runbook, known-limitations doc, and at least one developer fluent in the Editor.js block API to add or fix blocks.
• Scaling: editor work is client-side, so server load is modest — JSON documents in the KB range, fine for MySQL 5.7+/Postgres JSON columns. Cost concentrates in media: the new folder-config feature makes S3 + CDN straightforward, but enforce size and dimension caps, add orphan cleanup for abandoned documents and deleted blocks, and consider a per-document block limit and pagination for very large documents, which degrade editor responsiveness.
• Failure modes:
  • Image folder unset or set differently per environment → uploads land on ephemeral local disk in production or 404 after deploy.
  • Disk permissions or S3 credentials misconfigured on the new write path → editor reports upload failure with no actionable error.
  • Stale or unpublished JS assets after deploy → editor silently fails to mount.
  • Editor.js tools pinned to pre-2.26 versions after the bump → author-time tool crash or unknown blocks on save.
  • Livewire hydration/property-binding errors after a framework upgrade (Livewire 3 remains the unproven case).
  • Malformed or hostile JSON rendered unescaped → stored XSS.
  • Orphaned uploads when a document is abandoned or a block is deleted.
  • Block schema drift producing blank or unknown blocks in the renderer.
  • Composer resolution failure blocking an unrelated framework upgrade — less likely than before given Laravel 10 support, but still possible at the Livewire constraint.
  • Maintainer dormancy resuming, leaving us effectively back at the archived-repo scenario with a newer baseline.
• Ramp-up: hours for a developer already comfortable with Livewire and Blade; moderate for custom block tooling in JS; designers should expect Editor.js's minimal, opinionated default styling and budget for it. Position this to stakeholders as an accelerated starter kit with a live but thin upstream — not a supported platform. The opportunity score improves on v1.5.0 because depending on upstream is now defensible for the pilot phase; the recommendation to build a well-maintained internal replacement once the content model proves out still stands.