Weave Code
Pagepart Bundle Laravel Package
kunstmaan/pagepart-bundle
Kunstmaan PagePartBundle is a Symfony bundle for building pages from reusable page parts. It offers configurable content blocks, admin management, and flexible templating for modular CMS pages.
KunstmaanPagePartBundle supplies the reusable page parts system behind the Kunstmaan CMS, a Symfony bundle for building structured, editor-friendly content. Page parts are small, self-contained blocks—text, images, buttons, sliders—that editors assemble into pages through the admin interface, keeping content decoupled from layout templates.
- Doctrine-backed page part entities with admin CRUD
- Configurable part types, contexts, and ordering
- Twig rendering with separate frontend and backend views
- Extensible base classes for building custom page parts
- Integrates with the broader Kunstmaan CMS node and admin stack
Frequently asked questions about Pagepart Bundle
- Is kunstmaan/pagepart-bundle a Laravel package?
- No. kunstmaan/pagepart-bundle is a Symfony bundle split from the Kunstmaan Bundles CMS; it ships no Laravel service provider, facade, container bindings, or PSR-only entry point. Treat it as a design reference for block-based page composition, not a Composer dependency for a Laravel application.
- Can I install kunstmaan/pagepart-bundle in a Laravel app with Composer?
- Composer may resolve it, but the result is not an integration. The bundle is welded to Doctrine ORM single-table inheritance, Symfony's DI container and Form component, and Twig conventions, and it would pull in Symfony HttpKernel, Doctrine, and likely Sonata Admin or kunstmaan/admin-bundle. Making it work in Laravel means rewriting the mechanism, not wiring a provider.
- Which Laravel versions does kunstmaan/pagepart-bundle support?
- None. The last tagged release is 2014-09-04, from the Symfony 2.x and PHP 5.4–5.5 era, years before Laravel's modern release cadence. There is no supported Laravel version, and no compatibility path for Laravel 8, 9, 10, or 11.
- What does KunstmaanPagePartBundle do and what is the page-part pattern?
- It provides a page-part composition pattern: a page is an ordered collection of typed, self-contained blocks such as text, image, button, or media. Each page-part type is a Doctrine entity extending an abstract base with single-table inheritance, plus an admin form and a Twig render template, and the available parts are configurable per page type. Editors compose pages from these blocks instead of editing one monolithic body field.
- How do I install and configure KunstmaanPagePartBundle in Symfony?
- In a legacy Symfony 2.3 or 2.5 application you would require kunstmaan/pagepart-bundle alongside its sibling Kunstmaan bundles, register it in AppKernel, and configure page types and their allowed page parts. That path needs a PHP 5.6 or 7.0 runtime that has been end-of-life since 2018–2019, so it is not acceptable for a supported production system. For new work, borrow the configuration model rather than installing the code.
- Is KunstmaanPagePartBundle still maintained?
- Effectively no. The last release was in September 2014, the repository has roughly 16 stars and zero dependents, and the parent Kunstmaan Bundles CMS project has been unmaintained for years. There is no security response path, so any advisory in the transitive Symfony or Doctrine tree would require an internal fork to patch.
- Can I use KunstmaanPagePartBundle on PHP 8 or Symfony 6 and 7?
- Not without a fork. The 2014 code predates PHP 7 type declarations and Doctrine 2.6+, and PHP 8 incompatibilities are near-certain given dynamic properties, removed each(), and changed string-offset semantics. Symfony 5, 6, and 7 removed or deprecated much of what the bundle relies on, so expect substantial rework before it boots.
- What are the production risks of depending on kunstmaan/pagepart-bundle?
- Abandonment is the critical risk: a 12-year-old codebase with no maintainers and no patch channel. Transitive dependency risk is high, since you inherit Symfony 2.x fragments, doctrine/orm ~2.4, gedmo/doctrine-extensions, and Sonata Admin, many with their own advisories. Talent risk is moderate too, because Symfony 2 and Sonata experience is thinning and does not transfer to a modern Laravel roadmap.
- What are the alternatives to KunstmaanPagePartBundle for Laravel?
- Use a Laravel-native block builder such as Filament's builder field, Laravel Nova, or a custom Livewire editor backed by a polymorphic page_blocks table. The page-part idea itself is well validated by Gutenberg, Storyblok, and Sanity, so you are copying a proven concept rather than a 2014 implementation.
- How do I reimplement and test the page-part pattern in Laravel?
- Model blocks as a polymorphic table keyed by page_id and block type, add a per-page-type allowlist so editors only see permitted blocks, and render each block through its own Blade view. Test the allowlist rules, ordering and reordering, rendering of every block type, and authorization on the editor endpoints. Keep persisted block data separate from its presentation template, which is the one design decision from Kunstmaan worth preserving.
Weaver
How can I help you explore Laravel packages today?