Weave Code
Content Bundle Laravel Package
integrated/content-bundle
integrated/content-bundle is a Laravel package that bundles content management capabilities into a single integration, helping you organize, store, and serve structured content using familiar PHP and Laravel conventions.
Integrated Content Bundle
Frequently asked questions about Content Bundle
- How do I install integrated/content-bundle in a Laravel application?
- The package is hosted on Bitbucket rather than Packagist, so you add it as a Composer VCS repository in your root composer.json and then require integrated/content-bundle. Every developer machine and CI runner needs credentials for that private repository, typically an app password or SSH key, plus a rotation policy. Confirm the tagged release or branch you are pinning before the first install so builds stay reproducible.
- Does integrated/content-bundle support Laravel 10 and 11?
- The naming and internal conventions suggest Symfony-shaped idioms, so Laravel 10 or 11 compatibility cannot be assumed and must be verified against the package's composer.json require and autoload sections. Check the declared PHP and framework constraints and whether any Symfony components it pulls in conflict with the versions Laravel ships. If the constraints cap at older Symfony releases, treat adoption as a port rather than a simple dependency add.
- What is the difference between blocks, collections, and templates in this package?
- Blocks are the composable units of content that editors fill in, and they are the smallest reusable piece of the content model. Collections group and order those blocks, giving you sorting, filtering, and repeatable lists across pages and APIs. Templates define how a block or collection is rendered, with overridable defaults so developers control output while editors only manage data.
- Is integrated/content-bundle available on Packagist?
- No. Distribution is via the Bitbucket repository only, with no Packagist entry, which means there is no public consumption path and no market signal such as install counts or dependents. In practice that adds credential provisioning for CI and local machines to your setup cost. It also means you should pin an explicit commit or tag instead of tracking a moving branch.
- What license is integrated/content-bundle released under, and can I fork it?
- The license grant is not stated in the package overview, and that ambiguity has to be closed in writing before any engineering time is committed. You need explicit confirmation that internal use, forking, and modification are permitted, because a content package typically touches your schema and admin surface. Without that, legal review cannot clear redistribution or long-term fork maintenance.
- The name ends in -bundle. Is this a Symfony bundle or a Laravel package?
- The -bundle suffix, Bundle class, DependencyInjection extension, and Resources/config/services.yml layout are Symfony conventions, and Laravel has no runtime equivalent. The description frames it as a Laravel integration, so the first job is to confirm which it actually is by reading composer.json and the package root. If it is a genuine Symfony bundle, the honest scope is porting the domain model, not installing a dependency.
- How do I add a custom field type to the content model?
- The package advertises extensible field types, so custom data models are meant to be added by registering your own field type implementation against the content definition layer. Confirm the exact extension point in the source before designing around it, since framework-shaped bundles often bind field registration to container configuration. Keep custom field rendering in your templates so presentation stays separate from stored content.
- Does the bundle own its database schema, and how are migrations handled?
- A content package with blocks, collections, and ordering almost certainly persists its own tables, so assume it brings schema with it until proven otherwise. Ask directly whether migrations are published into your application or shipped inside the package, and what the upgrade story is for schema changes. Packages built on Doctrine mappings rather than Laravel migrations will need a bridging strategy before you commit to production data.
- Is integrated/content-bundle actively maintained, and what are the alternatives?
- There is no observable commit cadence, issue tracker, or release history in the public signals, so support cannot be forecast and the package should be treated as a lead to qualify. Establish a named owner on both the vendor and internal side, and confirm whether support is commercial or as-is. If the platform contract is not real, evaluate maintained Laravel content packages or a small in-house content model instead.
- How do I test content rendering and deploy this private package in production?
- Because the repository is private, your CI pipeline needs stored Composer credentials with rotation, and you should cache dependencies against a pinned commit for reproducible builds. Write rendering tests around templates and block output rather than around the package internals, so you can swap or fork the implementation later. Before production, run a spike on the target Laravel version and confirm the transitive dependency surface, since Doctrine or admin-generator pulls each add their own CVE and PHP-version treadmill.
Weaver
How can I help you explore Laravel packages today?