- How do I install coderstm/laravel-page-builder in a Laravel app?
- Install it with Composer using composer require coderstm/laravel-page-builder. The package follows standard Laravel conventions with an auto-discovered service provider, and you should expect to publish configuration, migrations, and views with vendor:publish. After publishing, run the migrations and confirm the editor assets and route registration match your app before wiring pages into your existing routes.
- Which Laravel and PHP versions does this page builder support?
- The overview does not state a Laravel or PHP support policy, so read the constraints in composer.json before planning anything. With zero stars and zero dependents there is no ecosystem evidence that it runs on a current Laravel release. Treat it as unproven on your stack until you have spiked it in a throwaway app.
- How is page content stored, and is the JSON schema versioned?
- Page content is stored as structured JSON describing layouts, sections, and reusable blocks, which keeps layouts portable and version-friendly in Git. Cast the JSON column to an array or a custom cast in your Eloquent model so Blade can iterate the blocks. Check the source for a schema_version field and validation rules, because unversioned JSON becomes a content migration problem on every upstream change.
- Do I need Node or a front-end build step for the page builder editor?
- It is not documented whether the editor ships precompiled CSS and JavaScript or requires a Node build step. Check the package's public assets and build scripts before adding it to your pipeline, especially if your deploy only runs composer install. If a Node build is required, budget for it in CI or vendor the compiled assets in your fork.
- Can I use it for multi-tenant branding or white-label themes?
- The package composes layouts from sections and blocks and layers a theme on top, which is the strongest reason to evaluate it for per-tenant branding or white-label template libraries. Confirm how themes are authored and loaded, and specifically whether an admin upload can introduce PHP or Blade that executes on your server. If themes can execute code, restrict theme installation to deploys rather than the admin panel.
- Is block HTML sanitized to prevent stored XSS?
- The overview does not mention server-side sanitization, so assume block HTML is rendered as stored until you verify otherwise. Any block that accepts raw HTML is a stored-XSS vector, particularly if lower-trust editors or tenants can author content. Sanitize on save and on render with an allowlist library, and keep a strict CSP as a second layer.
- How do I render a built page in Blade, and what happens with malformed JSON?
- Rendering is done through Blade partials, so published pages are server-rendered markup rather than a JSON API response. Add validation and a fallback partial so malformed or hand-edited JSON, or a block view deleted in a deploy, degrades instead of throwing a 500 on a published page. Wrap the renderer in a test that feeds it broken payloads.
- Does it support drafts, revisions, previews, scheduled publishing, or locales?
- Those features are not described in the overview, so plan as if they are absent. Verify in the source whether pages have status columns and revision tables or just a published JSON blob. If you need an editorial workflow or per-locale content, budget to build it on top of the layout model rather than expecting it from the package.
- Does this work with Inertia, Vue, React, or a headless front end?
- This is a Blade-first page builder, so it fits a Laravel monolith that already owns public routes and views. On an Inertia or Next.js front end you would either render published pages through Blade outside the SPA shell or write your own serialization endpoint and renderer, which discards most of the package's value. If a structured content API is your real requirement, evaluate a headless CMS instead.
- Is it safe and maintained enough for production use?
- With a single maintainer, no changelog cadence, and no visible CI or test suite, plan to own the code. Vendor the package into packages/ or a pinned private fork instead of relying on Packagist, and spike it behind a feature flag on one low-traffic page first. Confirm the license allows forking and internal redistribution before you commit.