Pagepart Bundle Laravel Package

Technical Evaluation

Verdict up front: despite being catalogued as a Laravel/PHP package, kunstmaan/pagepart-bundle is a Symfony bundle, not a framework-agnostic library. It has no Laravel service provider, no facade, no container bindings, and no PSR-only entry point. Its last tagged release is 2014-09-04 (Symfony 2.x / PHP 5.4–5.5 era), it carries 16 stars and 0 dependents, and the parent Kunstmaan Bundles CMS project has been effectively unmaintained for years. The 0.38 score is consistent with that profile. This is a concept to borrow, not a dependency to install.

Architecture fit

• Domain model: the bundle's contribution is a "page part" composition pattern — a page is an ordered collection of typed, self-contained blocks (text, image, button, media, etc.). Each page-part type is a Doctrine entity extending an abstract base, mapped via single-table inheritance, with an admin form and a Twig render template. Page-part availability is configurable per page type.
• Fit for a Laravel codebase: near zero at the code level. The abstraction is welded to Doctrine ORM inheritance, Symfony's DI container, form component, and Twig bundle conventions. Laravel's Eloquent + Blade + Livewire/Filament stack would require a rewrite of the mechanism, not an integration.
• Fit as a reference design: high. The per-page-type allowlist of blocks, separation of persisted data from presentation template, and the "webmaster composes the page" UX are directly transferable to a Filament/Nova block builder or a custom page_blocks polymorphic table. That is the realistic value here.
• Framework mismatch is the headline risk for anyone reading this catalog entry at face value.

Integration feasibility

Technical risk

• Abandonment risk: critical. 12-year-old last release, no dependents, no security response path. Any CVE in the transitive Symfony/Doctrine tree is unpatchable without an internal fork.
• Transitive dependency risk: high. Expect symfony/symfony 2.x fragments, doctrine/orm ~2.4, gedmo/doctrine-extensions, sonata-project/admin-bundle, and Kunstmaan sibling bundles — many with their own abandonment and known advisories.
• Runtime risk: high. PHP 8 incompatibilities are near-certain (dynamic properties, each(), removed mcrypt, string-offset semantics).
• Talent risk: moderate. Symfony 2 / Sonata familiarity has thinned considerably; the engineers who know this stack are expensive and the knowledge is not reusable elsewhere in our roadmap.
• Concept risk: low. The page-part pattern itself is sound and widely validated (Gutenberg, Storyblok, Sanity, Filament builders).

Key questions

1. Is the actual requirement "let non-technical editors compose pages from blocks," or specifically "adopt Kunstmaan"? If the former, this package is a design reference only.
2. Are we committed to Symfony anywhere in the estate? If not, this evaluation should exit here.
3. Is there an existing Kunstmaan installation in the business we must interoperate with or migrate off? That changes the work from greenfield to extraction.
4. Who owns the fork if we vendor it? Is a security-patch SLA realistic for a 2014 codebase?
5. What is the editor-experience bar — does it require per-page-type block allowlists, inline preview, revision history? (Kunstmaan gives allowlists and preview; revisions live in NodeBundle, not here.)
6. Do we need multi-language page parts? Kunstmaan handles this via NodeTranslation/PageTranslation in the sibling bundles — not in this package alone.

Integration Approach

Stack fit

• Target stack (assumed): Laravel 10/11, PHP 8.2+, MySQL/Postgres, Blade + Livewire or Filament, queue-backed media handling.
• Source package: Symfony 2.x bundle, Doctrine STI entities, Twig templates, Sonata-style admin forms.
• Overlap: essentially none at the code level. Overlap at the model level is high: Page hasMany PagePart; PagePart has type, sequence, data, template.
• Recommendation: treat as pattern port, not dependency. Two viable ports:
  1. Polymorphic blocks table — page_blocks(id, page_id, blockable_type, blockable_id, position) with one Eloquent model per block type. Closest to Kunstmaan's inheritance semantics, cleanest queries, best for typed validation.
  2. JSON column — pages.blocks JSON array with a block-type registry/schema. Faster to ship, weaker referential integrity and harder to query media relations.
  • Port #1 is the faithful analogue and what I'd recommend if editor workflows are core.

Migration path

There is no direct migration path from this package — no Laravel artifact, no data to migrate from unless we already run Kunstmaan. If we do run Kunstmaan:

1. Spike (3–5 days): inventory current page-part types, their fields, and templates; identify which are actually used.
2. Schema mapping: Kunstmaan STI child tables → Laravel block models; PagePartRef ordering → position column.
3. Content extraction: read-only Doctrine/PHP 5.6 container or a direct SQL export, emit JSON per page, import via artisan command.
4. Parallel run: dual-render a sample of pages behind a feature flag; diff output.
5. Cutover per page type, not per site — page parts are naturally independent units.

If we do not run Kunstmaan, skip 1–4 and go straight to the port.

Compatibility

• PHP: package targets PHP ≥5.4; will not run on 8.x without patching.
• Symfony: 2.3–2.5 range; incompatible with 4+.
• Doctrine: 2.x STI — Eloquent has no equivalent; requires the port.
• Twig templates: translatable to Blade in hours, but they are coupled to Kunstmaan's PagePartAdmin context variables.
• License: MIT — no legal blocker to copying and adapting the design and templates. This matters: a clean-room port derived from the MIT source is legally fine, and is the pragmatic path.

Sequencing

1. Week 0 — decision gate. Confirm requirement is block-composition, not Kunstmaan adoption. Kill the dependency option here. (0.5 day)
2. Week 1 — spike. Port the two or three highest-value block types end-to-end in a Laravel branch; validate editor UX with two webmasters. (3–5 days)
3. Week 2–3 — core model. Block registry, per-page-type allowlist config, ordering, soft deletes, media relations.
4. Week 3–5 — admin editor. Filament/Livewire block builder with add/remove/reorder, preview, validation.
5. Week 5–6 — rendering. Blade partial per block type, cached fragment rendering.
6. Week 6–8 — hardening. Permissions, audit trail, revision history (this is the piece Kunstmaan puts in NodeBundle — budget for it explicitly), accessibility pass on editor UI.
7. Week 8 — pilot. One page type, one editor, measured rollback.

Operational Impact

Maintenance

• If adopted as a dependency: high and unbounded. A 2014 Symfony bundle in 2025 means owning an internal fork, a pinned EOL PHP runtime, and a transitive tree we cannot patch. Every security scan becomes a manual triage exercise.
• If ported: low-to-moderate, and normal. ~1,500–2,500 lines of first-party Laravel code, standard test coverage, no exotic dependencies. Estimated steady-state cost: 0.1–0.2 FTE for block-type additions and editor polish.
• Ongoing cost driver: every new block type is a small vertical slice (model + form + template + test). Kunstmaan's own pitch — "pageparts are easy to create for your specific project" — is the cost model; assume 0.5–1.5 days per block type.

Support

• Upstream support: none. No maintainer activity, no issue triage, no release cadence. The kunstmaan org has moved on; the CMS is not a supported product line.
• Internal support burden with dependency adoption: we become the maintainers by default, with no upstream to escalate to and no community of 0 dependents to lean on.
• Internal support burden with port: same as any in-house admin feature — standard on-call, standard code review, standard documentation expectations.
• Vendor/community escape hatch: none. Contrast with Filament or Nova, where upgrade guides and an active plugin ecosystem exist.

Scaling

• Data model scaling: the Kunstmaan pattern is fine at scale — STI page parts are cheap reads, and ordering is an indexed integer. A ported version inherits this. Watch for N+1 on block rendering; eager-load blocks and media per page.
• Editor scaling: ordering/reordering with a position column needs care past ~50 blocks per page (renumbering churn). Use sparse or fractional positions if pages get long.
• Render scaling: block-per-partial rendering multiplies template lookups; cache rendered page fragments keyed by page version. This is not a Kunstmaan-specific concern, but it is where naive ports fall over.
• Team scaling: better with a port. New Laravel engineers can be productive on the port in days; Symony 2/Sonata onboarding is a multi-week tax for a stack we don't otherwise use.

Failure modes

Ramp-up

• Dependency path: 4–8 weeks before first value, dominated by resurrecting an EOL Symfony stack, with no reusable knowledge at the end. Recommend against.
• Port path: 1 week to a demo, 6–8 weeks to a production-ready editor with revisions and permissions. Knowledge is fully reusable across the Laravel estate.
• Reference-review path (cheapest): 2 engineer-days to read the MIT-licensed source — specifically AbstractPagePart, the page-part configuration and the admin form flow — and write a half-page design note translating it to our stack. This captures ~80% of the bundle's value at ~2% of the integration cost.
• Stakeholder framing: the package scores 0.38 for a reason. Present it as a pattern source with MIT-licensed reference code, not a component we can ship. The business requirement it addresses — webmaster-composable pages — is real and worth funding; this repository is the wrong vehicle for it.