- Is hansschouten/phpagebuilder a Laravel package or a plain PHP library?
- It is a framework-agnostic PHP library, not a Laravel package. It ships no service provider, publishable config or migrations, Blade components, or Eloquent models, so Laravel must own the application shell, auth, persistence, and routing. Treat it as an authoring layer that emits a stored page definition your Laravel app renders.
- How do I install and integrate it into a Laravel application?
- Install it with Composer using composer require hansschouten/phpagebuilder, then build a thin first-party adapter in your app. That adapter typically includes a service provider, a config file, Page and PageRevision Eloquent models, a repository implementing the package's storage contract, and a renderer that maps stored blocks to Blade partials. Budget this as custom build effort, not configuration.
- Which Laravel and PHP versions does it support?
- Because it is framework-agnostic, the package does not declare Laravel constraints the way a Laravel package would. Targeting Laravel 10, 11, or 12 on PHP 8.1+ is a reasonable baseline for your adapter, but confirm the package's PHP requirement and recent release cadence on Packagist before committing. Laravel major-version upgrades become your responsibility if upstream stalls.
- Where does it store pages, and can I persist them with Eloquent?
- Storage is one of the key unknowns: verify whether it persists pages to a database, the filesystem, or through a caller-supplied callback. For Laravel, plan to implement a repository against Eloquent with pages and page_revisions tables. Do not assume a built-in storage abstraction until you confirm the contract in the source.
- Can I use it alongside Filament, Nova, or my existing Blade admin panel?
- It can work alongside Filament, Nova, or a custom Blade admin, but you risk two competing admin surfaces and CSS/JS bundle collisions with jQuery, Bootstrap, Tailwind, or Vite. Mount the builder under an authenticated admin route group such as /admin/pages/{page}/edit with policy-gated access. Verify asset isolation before adopting it into an existing admin stack.
- Is it safe to let users author HTML blocks, and how do I prevent XSS?
- A drag-and-drop HTML builder is an XSS and stored-injection surface by design, since anyone who can author blocks may persist script, iframe, or event-handler payloads. Add server-side sanitization with an HTMLPurifier-class allowlist, a strict Content Security Policy, tightly scoped author roles, and a review step before publish. Never render raw stored markup on the public site without a sanitization pass.
- How do I render builder pages in Laravel?
- Store the builder's page definition as JSON or HTML, then compile it through a PageRenderer that maps each block to a Blade partial. Keep authoring endpoints inside an authenticated admin route group and render published output as cached, sanitized HTML. Escape block data if you render through Blade rather than raw markup.
- Is the saved page format versioned, and what happens to content on upgrades?
- Saved page JSON is a long-lived artifact, and there is no visible documented block schema or migration path for stored content across releases. Define your own versioned block schema and write migrations for saved pages before you ship. Ask the maintainer whether the format is versioned, or plan to vendor and fork.
- How should I test a page builder integration before production?
- Spike it in a scratch Laravel app: install the package, wire a storage adapter, create a page, author blocks, render the output, and run it through your sanitizer. Add feature tests for auth-gated authoring routes, rendering, and publish state, plus security tests for script, iframe, and event-handler payloads. Test asset loading against your admin front-end stack early.
- Is it actively maintained, and what are the alternatives if it is abandoned?
- It is a single-author package with no visible corporate backing, an unknown repository URL, and a low composite score, so treat popularity as interest rather than production readiness. Plan for vendoring or a private fork from day one and own PHP/Laravel upgrades. If that risk is unacceptable, compare Laravel-native CMS or page-builder options that ship a service provider, migrations, and Eloquent models, or build a minimal block editor in Blade or Filament.