- How do I install okipa/laravel-brickables in a Laravel application?
- Install it with Composer using composer require okipa/laravel-brickables. The package ships a service provider that Laravel's package auto-discovery registers, so no manual provider entry is normally needed. After installing, publish any package configuration and migrations and run php artisan migrate. Confirm your app runs Laravel 9 or 10 on PHP 8.1 or 8.2 before installing version 3.2.0, since those are the supported constraints for this release.
- Which Laravel and PHP versions does laravel-brickables 3.2 support?
- Version 3.2.0 targets Laravel 9.x and 10.x on PHP 8.1 and 8.2. Laravel 8 support was dropped in this release, which is consistent with Laravel 8 reaching the end of its security support in January 2023. If your application is still on Laravel 8 or on PHP 8.0, you should stay on the 3.1.x line until your platform upgrade is complete. Check the composer.json diff between 3.1.x and 3.2.0 to see the exact constraints, including any illuminate/* or testbench bumps.
- How do I attach content bricks to an existing Eloquent model?
- Add the package's brickable trait to the model that should own the content, which gives it a polymorphic relationship to stored bricks. Because the relationship is polymorphic, the same brick types can be reused across pages, articles, or any other model without duplicating tables or logic. From there you can create, order, and retrieve bricks through the trait's helpers rather than writing custom queries. Keep the trait on the parent model only, and let each brick record store its own type and payload.
- How do I create a custom brick type in laravel-brickables?
- The package uses an extensible brick type system, so you define a new brick class that extends the package's brick abstraction and register it as an available type. Each brick type is responsible for its own content fields, validation rules, and rendering view, which keeps page composition modular. Register the type wherever the package expects its brick catalogue, typically through configuration. Once registered, editors can add that brick to any model that uses the brickable trait.
- How do I render brick content in a Blade template?
- Load the model with its bricks relation, loop over the ordered collection, and render each brick through its own view or render method so every brick type controls its markup. The package's helpers handle retrieval and ordering so your template does not need to query bricks directly. Keeping rendering inside each brick class means new brick types do not require changes to the parent page template. Eager load bricks to avoid N+1 queries on pages with many blocks.
- Is laravel-brickables 3.2 compatible with PHP 8.3?
- Version 3.2.0 is constrained to PHP 8.1 and 8.2, so a PHP 8.3 environment will fail Composer resolution. Using --ignore-platform-reqs to force the install is not recommended because it bypasses the constraint the maintainer set and invites runtime defects. If your CI images or container base images already run PHP 8.3, treat that as a blocker and check whether a newer release raises the ceiling. Teams that need 8.3 today should pin to a version that explicitly declares support rather than working around the constraint.
- Why does composer update fail with a version conflict after upgrading laravel-brickables to 3.2.0?
- The two most common causes are an application still on Laravel 8, or a PHP runtime on 8.3 while the package allows only 8.1 and 8.2. A mismatch between your app's own php constraint and the package's constraint can also produce confusing resolution errors even when the runtime itself is fine. Read the conflict output carefully, then compare your composer.json platform requirements against the package's declared constraints. Fix the underlying platform mismatch rather than forcing the install with ignore flags.
- Is upgrading from laravel-brickables 3.1.x to 3.2.0 a breaking change?
- The 3.2.0 release is a platform-compatibility change with no reported behavioral or data-model changes, but it does remove Laravel 8 support, so it is breaking for anyone still on Laravel 8. For applications already on Laravel 9 or 10 with PHP 8.1 or 8.2, it should behave like a routine minor bump. If you remain on Laravel 8, pin the package to ^3.1 explicitly so a routine composer update cannot drag the app across an unsupported boundary. Run your integration tests, not just unit tests, since service-provider registration is the usual failure point.
- How should I test brick content management in my Laravel application?
- Write feature tests that create a model, attach bricks of several types, and assert ordering and rendered output, using the package's model helpers to build fixtures. Use RefreshDatabase so the package migrations run cleanly in the test schema. Cover the service provider boot path as well, because a misregistered provider or missing config surfaces at boot rather than in isolated unit tests. If your app renders bricks in Blade, assert on the rendered HTML for each brick type.
- Is okipa/laravel-brickables still maintained, and how do I migrate off Laravel 8?
- The 3.2.0 release is a maintenance-style platform alignment rather than a feature release, and its notes do not include a changelog or upgrade guide, so confirm the maintainer's support policy for the 3.1.x branch if you still need Laravel 8. For migration, sequence the work as PHP 8.1 first, then Laravel 9, then Laravel 10, and finally package 3.2.0, rather than upgrading the package in isolation. Inventory every application depending on the package and tag it by Laravel and PHP version before rolling anything out. Upgrade in a non-production environment first and monitor for boot-time exceptions when the service provider registers.