Page Blocks Laravel Package

Technical Evaluation

Architecture fit. dejodev/page-blocks is a Filament plugin that provides a "page blocks" content model — the classic page-builder pattern where a page record owns an ordered collection of typed blocks (hero, rich text, image + text, CTA) persisted as structured data and edited through a Filament form. Architecturally this is the right shape for a Laravel/Filament application that needs editorial composition without a full CMS: it sits between the "just use a Builder field" approach (fast, but unstructured and hard to render consistently) and a heavyweight headless CMS (PageTree, Statamic, Wagtail-style). If our application is already Filament-first, the plugin should register via package auto-discovery, expose a service provider and a block registry, and integrate as a relation or JSON column on our page model. That is a low-friction architectural fit — provided the internals follow Filament conventions and do not require us to subclass or monkey-patch core classes.

Integration feasibility. The surface area appears small, which cuts both ways: a small package is easy to read, vendor, and patch, but it also means fewer escape hatches and no ecosystem of extensions. Composer installation should be trivial (MIT license, no private registry). The real feasibility question is not install effort but whether the block schema is expressive enough for our content types and whether the rendering layer is separable from the admin layer — a block editor that only renders in Filament views is not usable for a public-facing site. We need to confirm a headless/Blade render path exists before committing.

Technical risk. High, driven almost entirely by adoption and maintenance signals rather than code quality:

• 0 stars, 0 dependents — no evidence of production use anywhere. No community to absorb bugs, no Stack Overflow corpus, no third-party blog posts.
• Single maintainer, unnamed bus factor. If the maintainer stops, we are the maintainers.
• Last release dated 2026-08-22 in the supplied metadata. That is either a future-dated artifact, a mirror quirk, or a scheduled tag. Either way, release metadata is not trustworthy as a maintenance signal until we inspect the actual commit history and tag cadence.
• Version coupling. Filament has shipped breaking majors on a roughly annual cadence (v3 → v4 introduced significant API and Livewire 3 changes). A zero-adoption plugin will not be tracked through those upgrades by anyone but us. This is the single largest long-term risk.
• Data durability risk. Editorial content stored as JSON in a column is only as safe as the block-schema migration story. If block types are renamed or reordered without a migration path, we corrupt live content.

Key questions (to resolve in a timeboxed spike, not by reading the README):

1. Which Filament major versions (and Livewire version) are supported in composer.json constraints, and is there a CI matrix proving it?
2. How are blocks persisted — JSON column, polymorphic table, or separate rows? What is the query story for listing/filtering by block content?
3. Is there a public rendering API (Blade components, a render() method, or view-per-block), or is rendering left to the consumer?
4. Are blocks extensible without forking, e.g. a registry/registerBlock() hook for custom block types?
5. What is the media story — reuse of spatie/laravel-medialibrary, Filament FileUpload, or bespoke disk handling?
6. Does it ship migrations, and are they publishable and additive?
7. What do the tests look like — Pest/PHPUnit coverage, or none?
8. What is the actual commit cadence and issue response history on GitHub?

Integration Approach

Stack fit. Reasonable for a Filament-centric monolith, weak for anything else. A quick fit matrix:

If our stack is Filament v4 or we are mid-upgrade, I would not integrate this package now; the compatibility surface is unproven and the upgrade burden lands entirely on us.

Migration path. Nothing to migrate from if we're greenfield — the question is the exit path. Design for removability from day one:

1. Require the package behind a thin internal adapter (a PageContent service and our own Blade partials) so the plugin is never called directly from application code.
2. Persist blocks in a column or table we own and control the migration for; do not rely on package-published migrations as the source of truth.
3. Treat the block JSON schema as our contract, versioned with a schema_version key so we can transform data if we swap implementations.

Compatibility. Pin the package version exactly ("dejodev/page-blocks": "x.y.z", not ^). Pair that with a Laravel/Filament upgrade checklist entry: any Filament major bump requires a spike against this package first. Budget for a fork if the maintainer is inactive at that point.

Sequencing. Four gates, roughly one sprint of elapsed time:

• Gate 1 — Source audit (0.5 day). Read the repo, not the README: composer.json, service provider, block registry, migrations, tests, commit history, open issues.
• Gate 2 — Sandbox spike (1–2 days). Install into a throwaway Filament app, build three representative blocks (rich text, image + text, CTA), render one page in Blade outside the admin panel. If step three fails, stop.
• Gate 3 — Vendor decision. If the spike passes, fork to an internal namespace or use a Composer VCS/path repository so we control patching. Do not depend on Packagist availability alone.
• Gate 4 — Production pilot (behind a flag). One low-traffic marketing page, one editor, two weeks of observation before widening.

Operational Impact

Maintenance. Assume we own it. With zero dependents and a single maintainer, the realistic posture is "vendored code we occasionally sync." That means assigning an owner, adding the package to our dependency-review routine, and running our own static analysis (PHPStan/Larastan) and test coverage over the integration points. The MIT license makes the fork legal and cheap; the cost is ongoing attention, not licensing.

Support. No SLA, no community, no commercial backing. Issue response is best-effort at best. Internal support model: the adopting team documents the block schema and render path in our own wiki, because the upstream docs are unlikely to be a durable reference. Budget for at least one engineer who has read the source.

Scaling. Content-block workloads are read-heavy and cache-friendly; the package's own footprint is unlikely to be the bottleneck. The risks are structural rather than load-related:

• Blocks as a single JSON blob per page are fine for hundreds of pages, awkward for cross-page queries ("find all pages with a CTA containing X"). If we need that, plan a derived index table.
• Rendering many small block partials per request adds view-render overhead — mitigate with full-page or fragment caching keyed on the page's updated_at.
• Media in blocks will drive storage and CDN needs; resolve the media story before launch, not after.

Failure modes. Ranked by likelihood × impact:

1. Silent breakage on a Filament/Livewire major upgrade — high likelihood, high impact. Mitigation: exact version pin, upgrade checklist gate, fork ready.
2. Block schema drift corrupting live content — medium/high. Mitigation: versioned schema, validation on save, backup-before-migrate, no destructive block-type renames.
3. Upstream abandonment — medium likelihood, medium impact given MIT + fork option. Mitigation: vendored copy.
4. Admin editor UX gaps surfacing late — medium. Mitigation: put a real editor in the pilot, not just engineers.
5. Media orphaning / disk inconsistencies — lower. Mitigation: explicit cleanup job if media is bespoke.

Ramp-up. Developer ramp-up is genuinely short — small API, Filament conventions, a day or two for a Filament-fluent engineer. The hidden cost is absence of documentation: onboarding happens by reading source, so the first integrator should write the internal doc as a deliverable. Editor ramp-up is the real UX dependency; plan a short training pass and a "known limitations" note for the content team.

Verdict. Viable as a bounded, internal, fork-ready component for a Filament-first application where we are willing to own the code. Not appropriate as a load-bearing dependency for a long-lived client product without that ownership commitment. Decide after Gate 2 — the spike is cheap and answers every question that matters.