Weave Code
Block Bundle Laravel Package
integrated/block-bundle
Symfony bundle for creating, organizing, and rendering reusable content blocks. It provides Doctrine-backed block storage and flexible block types for building modular, CMS-style pages without hardcoding every section.
Integrated Block Bundle
Frequently asked questions about Block Bundle
- Is integrated/block-bundle a Laravel package or a Symfony bundle?
- By naming convention, directory structure, and packaging it is a Symfony bundle: it ships a bundle class, DependencyInjection configuration, service definitions, a Twig extension, and Doctrine entities. It is not a Laravel package and exposes no service provider, facade, or publishable Laravel config. Treat any Laravel framing as unverified until someone reads composer.json and the bundle class directly.
- Can I use integrated/block-bundle in a Laravel application?
- Not without a custom integration layer, and that is the gating question for the whole evaluation. The bundle assumes a Symfony kernel, its DI container, Twig, and Doctrine wiring, so bridging it into Laravel's container would be a bespoke project rather than an install. Unless the core can be consumed as a framework-agnostic Composer library without kernel coupling, the cost likely exceeds building a block model in-house. Answer framework fit before spending time on anything else.
- Does it support Laravel 11 and PHP 8.3?
- No Laravel support is declared anywhere, and there are no Packagist releases, tags, or documentation to check against. PHP and Symfony version bounds are unknown until composer.json is inspected in the repository. Do not assume Laravel 11 or PHP 8.3 compatibility from the overview text.
- How do I install it with Composer when it isn't on Packagist?
- Add the Bitbucket URL as a Composer vcs repository, pin an explicit commit hash, and supply credentials through COMPOSER_AUTH so local builds and CI can authenticate. Installation then depends on Bitbucket access continuing for the life of the product, including SSO and app-password policy changes. Do this first in a throwaway sandbox so you can see exactly what installs before touching a real codebase.
- What are the PHP, Symfony, and Doctrine version requirements?
- Unverified. There is no published composer.json metadata visible through Packagist, so the declared require constraints for php, symfony/*, and doctrine/* must be read straight from the repository. Check autoload, extra, and stability settings at the same time, since they affect whether the package resolves cleanly inside an existing project. Treat every compatibility claim as unknown until that file has been reviewed.
- How do block types, configuration, and Twig rendering work?
- The core loop is a block key lookup through a repository, followed by rendering through an overridable Twig template, with block types and services registered in YAML configuration. Block types are pluggable and carry their own fields and rendering logic, resolved through a simple service and registry API. Views are template-driven and can be overridden per project, which is where most customization will land. The framework-agnostic core claim should be verified in code rather than assumed.
- Does it ship Doctrine entities, migrations, routes, or an admin UI?
- The bundle definitely includes Doctrine entities and service configuration, but whether migrations, routes, middleware, or an admin UI ship in the box is unconfirmed and must be checked in the repository. Each of those expands the integration surface and the eventual upgrade cost, so review migrations for reversibility before adopting. The bigger long-term risk is content model lock-in: block schemas persisted in the database are cheap to adopt and expensive to migrate away from once editors have populated them.
- Is it production-ready and actively maintained?
- There is no external validation: no releases, no tags, no documentation, no dependents, and no visible issue activity, plus no named maintainer or commitment to future security patches. Technical risk is high, so treat it as an internal-fork candidate rather than a normal dependency. Spike it in an isolated sandbox at a pinned commit, read the bundle class, Configuration.php, service definitions, entities, and Twig extension signatures, and confirm a point of contact for escalation before committing.
- What license is it under, and can we fork and modify it?
- The license is unconfirmed and must be cleared before any code enters your repository. Do not assume fork-and-modify rights from the fact that the source is reachable; confirm the license text and internal ownership first. If the license permits it, an internal fork removes Bitbucket availability as a build dependency, at the cost of owning maintenance and security patching permanently.
- What alternatives should a Laravel team consider?
- For a Laravel-native application the realistic alternative is a small in-house block model: a blocks table, a block type registry, and Blade partials per type, which is typically days rather than weeks of work. Laravel-native CMS or page-builder packages are the other option if you want an admin surface and editor tooling out of the box. Consider this Symfony bundle only if your stack is Symfony, or the core proves genuinely framework-agnostic, and you have a near-term requirement for editor-composed, reusable content.
Weaver
How can I help you explore Laravel packages today?