Laravel Grapesjs Laravel Package

Getting Started

1. composer require dotlogics/laravel-grapesjs and let Laravel auto-discover the service provider.
2. Publish the package's config, views, and front-end assets, then run php artisan migrate if you plan to use the DB-backed storage manager. Publish tags vary by version, so list them with php artisan vendor:publish rather than guessing.
3. Read config/grapesjs.php first. It is the control panel for this package: editor id, plugin list, storage manager driver, and any route/middleware wiring. Nearly every behavioural question you'll have day to day is answered or overridden here.
4. First use case: an admin-facing template editor. Expose a route that injects the package's Editor service and returns its rendered view, e.g. a controller method returning view('admin.editor', ['editor' => $editor->view()]) behind your auth/can middleware. Save the editor output, then render the stored HTML in your own application or mailer.

Start with the smallest possible loop — one route, one editor, one row in a table — before touching plugins or storage customisation. The editor is the easy part; persistence and re-hydration are where the real design work happens.

Implementation Patterns

Persist three artifacts, not one. Store the GrapesJS project JSON alongside the generated HTML and CSS. JSON is what lets a user reopen and continue editing; HTML/CSS is what you ship to end users. A single json column plus html and css columns (or a renders() accessor) on your own Template/EmailTemplate model is the common shape.

Wrap the package in your own domain model. Don't let controllers talk to raw arrays from the storage manager. Put the save/load logic behind a repository or model method, so you can swap the package's storage manager for a custom implementation later without ripping up controllers.

Custom storage manager for anything non-trivial. If you need tenant scoping, S3, versioning, or audit history, register a custom storage manager class in the config and let it delegate to your own repository. This is the package's main extension point and keeps the editor decoupled from your persistence rules.

Multiple editors per page. When editing more than one template at a time (e.g. a list of email variants), give each instance a distinct editor id via config/options. Shared ids cause the second instance to attach to the first's DOM node.

Plugin and block registration. Add GrapesJS plugins and custom block sets through the config's plugin array, shipping your plugin JS as a published asset. Keep custom blocks in version control and load them via your own asset bundle rather than editing vendor files.

Preview and export pipeline. For email templates, treat the editor output as a draft: run it through an inliner and any required sanitisation before sending. For web pages, pass the stored HTML through your existing sanitiser or a trusted-only admin gate.

Upgrades. Pin the minor version, upgrade deliberately, and re-publish assets with --force after bumping so the front-end JS matches the PHP side.

Gotchas and Tips

• 3.4.1 fixed a real editing bug: the code editor could reset (lose) styles. If you are on 3.4.0 and users edit HTML/CSS in code view, upgrade and verify that style changes survive a round-trip; this is a data-loss-shaped bug, not just cosmetic.
• JSON is the source of truth. Storing only the rendered HTML means users can never meaningfully re-edit a template. This is the most common design mistake with this package.
• Stored HTML is executable content. Restrict the editor to trusted roles or sanitise on render. Do not assume GrapesJS's output is safe just because it came from your own route.
• After config or asset changes, clear caches. php artisan config:clear and view:clear catch a large share of "my settings aren't applying" reports.
• File-system storage needs permissions and a symlink. Check storage/app/public and php artisan storage:link before blaming the storage manager for failed saves.
• CSRF and middleware on save routes. The editor's save requests go through your web middleware stack; missing CSRF tokens or auth middleware show up as silent save failures in the browser console rather than server errors.
• Debug in the browser first. Editor-not-loading, block-missing, and save-failing issues are almost always JS console or network-tab problems, not Laravel exceptions. Check the asset manifest and the save request payload before adding logging to PHP.
• Check the changelog between minors. The 3.4.x line ships front-end asset changes; re-published JS from a newer patch can conflict with a stale compiled asset in public/vendor. When behaviour changes inexplicably after an upgrade, hard-refresh and confirm the published asset version.