- How do I install laravel-editorjs in a Laravel app?
- Install it with Composer using composer require alaminfirdows/laravel-editorjs. Then publish the package assets and configuration with the artisan vendor:publish command so the Editor.js JavaScript, config file, and upload stubs land in your application. The whole setup is Composer plus artisan publish, with a config file controlling tool registration and upload handling. No service provider wiring is required beyond Laravel's package auto-discovery.
- Which Laravel and PHP versions does laravel-editorjs support?
- Version 2.4.0 adds PHP 8.4 support and claims compatibility with Laravel 12 and 13, on top of earlier 2.x support. Note that Laravel 13 forward-compatibility work was merged while that framework version was not yet generally available, so validate the matrix against your actual target versions in CI rather than trusting the changelog alone. If you are on an older Laravel release, check the tagged release notes before upgrading.
- How do I render Editor.js content in a Blade view?
- As of v2.4.0 the package ships a Blade directive, @editorJsRender(), which takes stored Editor.js block JSON and outputs rendered HTML. That directive moves the package into the presentation layer, so review its escaping behavior before using it with untrusted author input. For custom or third-party tools, the directive cannot know your renderer, so you must supply rendering logic yourself.
- Where should I store the Editor.js JSON output in my database?
- Editor.js emits a JSON object containing a blocks array, so a JSON or longText column on your model is the usual choice, often cast to an array or custom cast in Eloquent. The package gives you parsing and rendering but does not dictate the storage schema, so that decision is yours. Consider whether the same block JSON must survive a later migration to an API-driven or headless frontend before you lock in a column type.
- How does laravel-editorjs handle image and file uploads?
- The package stubs and registers an upload endpoint through its configuration, but it does not own your media storage. You implement the actual upload controller, validation rules, disk configuration, and cleanup, then point the Editor.js image or file tool at that route. Treat uploads as a scoping item you must budget for, because Editor.js tools expect a working endpoint that returns the expected JSON shape.
- Is it safe to render user-submitted Editor.js content with this package?
- The package validates the structure of block JSON, but the security posture of stored and rendered output depends on your configuration and on which tools you enable. This is a shared-responsibility boundary: sanitize author input, escape on output, and restrict which tools untrusted users can access. Pay particular attention to custom and third-party tools, since their renderers bypass any built-in rendering and escaping.
- How do I register custom Editor.js tools with this package?
- Tool registration is governed by the published config file, where you declare the bundled and custom tools you want available in the editor. For any custom tool you add, you also own its server-side renderer and sanitizer, since the package can only render blocks it knows about. Decide early who on your team maintains those renderers if the tool set grows.
- Is upgrading from v2.3.0 to v2.4.0 a breaking change?
- The v2.4.0 additions, including the warning tool, the Blade directive, PHP 8.4 support, and the Laravel 12 and 13 compatibility work, are described as additive and non-breaking relative to v2.3.0. In practice the upgrade is an in-place composer update, optionally republishing config and assets if new options were introduced. Review the published config diff and test your rendering path after upgrading, since the new directive is an additional surface rather than a replacement.
- How do I test an application that uses laravel-editorjs?
- Unit test coverage is improving but was previously thin, so do not rely on the package's suite as a proxy for your own. Write feature tests that save Editor.js JSON through your model, assert the parsed structure, and assert the output of @editorJsRender() for representative blocks. Include a test for untrusted input containing script tags or raw HTML so escaping regressions surface immediately.
- Is laravel-editorjs actively maintained, and what are my alternatives if it isn't?
- Maintenance is effectively single-maintainer, with most merged pull requests from the original author, though v2.4.0 does show a second contributor and an external compatibility PR. That is a moderate bus-factor risk worth recording in your dependency review. If it goes unmaintained, your fallback options are forking the package or dropping it and using Editor.js directly on the frontend with your own block JSON parsing and rendering layer.