Pagepart Bundle Laravel Package

Product Decisions This Supports

• Build vs. buy for structured page composition: The pagepart model (a page = ordered list of typed blocks, each block owning its own data and template) is a legitimate architecture choice when you need marketing/webmasters to assemble pages without engineering involvement. This package is evidence of that pattern, not a modern implementation of it — useful as a reference design when deciding whether block-based composition is right for your roadmap.
• Content-modeling decisions: The per-page definition of "which pageparts are allowed here" is a governance feature worth stealing conceptually — it constrains editor freedom at the page-type level rather than globally, which is the right trade-off for multi-template sites.
• Separation of data from presentation: Supports a roadmap decision to keep editorial content portable across re-skins. If a redesign is on the horizon, this pattern de-risks it.
• Not a delivery decision: At 16 stars, zero dependents, and a last release in September 2014, this should not appear on a build/buy comparison sheet as a viable candidate. It is a historical artifact of the Kunstmaan CMS framework (Symfony, not Laravel) and carries no support, security, or compatibility commitment.

When to Consider This Package

Consider it only as:

• A reading reference when your team is designing a block/pagepart content model and wants to see a working (if dated) prior art.
• A constraint if you are already operating a legacy Kunstmaan CMS installation on an old Symfony version and need to understand or extend existing behavior — in that case the decision is maintenance, not adoption.
• An input to an architectural spike, not a dependency.

Look elsewhere — decisively — when any of the following is true:

• Framework mismatch: This is a Symfony bundle. It does not drop into Laravel. Treat any framing of it as a "Laravel package" as a red flag in the evaluation itself.
• Any production requirement: No release in over a decade means no PHP 8.x support, no modern Symfony compatibility, no security patching, and no maintainer response path. Zero dependents means zero community pressure to fix anything.
• You need editor UX, media handling, or workflows: Modern alternatives (block editors in Craft, Statamic, WordPress Gutenberg, or headless CMS platforms like Sanity/Contentful/Storyblok, or Laravel-native options like Filament with block builders) deliver the same separation-of-data-and-presentation benefit with active maintenance.
• You need a hiring or onboarding story: Committing to an unmaintained bundle creates a single-point-of-failure skills dependency.

How to Pitch It (Stakeholders)

To executives: This package validates a product capability — letting non-technical staff assemble pages from reusable, governed blocks — but it is not something we should build on. It is a 2014-era Symfony component with no active maintenance, no dependents, and no security posture. Adopting it would trade a short-term shortcut for long-term maintenance and hiring risk. Recommendation: do not adopt; borrow the pattern.

To engineering: The design idea is sound and worth replicating — typed pageparts, per-page allowed-block lists, strict data/presentation separation. The implementation is not: last release September 2014, 16 stars, 0 dependents, and it targets Symfony, not our Laravel stack. If we want block-based composition, we build a thin version in-house or adopt a maintained third-party editor. Budget this as a design reference, not a dependency or a spike-with-intent-to-ship.

Bottom line: Opportunity is low and risk is high. Close the evaluation with a documented "no" and capture the two design principles (block composition, per-page block governance) in our own architecture notes.