Weave Code
Basic Blocks Laravel Package
bagistoplus/basic-blocks
A Laravel package for BagistoPlus that supplies reusable basic blocks, making it easier to compose content sections and assemble storefront layouts with less custom code. Simple to install and extend for common block-based page building needs.
Basic blocks for bagisto visual editor
Frequently asked questions about Basic Blocks
- How do I install bagistoplus/basic-blocks in a Laravel Bagisto project?
- Install it with Composer using composer require bagistoplus/basic-blocks. The package registers block types through a service provider and config, but the release note does not list publish tags or confirm whether the provider is auto-discovered. Check src/Providers for the service provider and run vendor:publish only after confirming the tag names.
- Does bagistoplus/basic-blocks support my Laravel and Bagisto versions, and is it actively maintained?
- The v1.6.0 release note does not declare php, laravel/framework, bagisto/*, or BagistoPlus constraints, so compatibility is unverified until you read composer.json. Maintenance signals are thin: zero dependents, negligible stars, and no changelog history to infer backwards-compatibility discipline. Treat alternatives as unproven until the block registry, store scoping, and view namespacing are confirmed.
- What blocks are included in bagistoplus/basic-blocks?
- The only documented release, v1.6.0, adds two blocks: category banner and category description. The package describes itself as a library of reusable basic blocks for the Bagisto visual editor. Additional blocks may exist in the codebase, but the release note does not enumerate them.
- How are block types registered or extended in this package?
- The package describes config-or-provider registration and an extensible API, but the release note does not document the block registry contract. Determine whether block types are registered through a config array, a singleton registry, or discrete classes by reading the service provider. That answer decides whether custom blocks are an extension point or a fork.
- What database columns do the basic-blocks migrations create?
- The release note does not list migration contents. Before adopting, inspect database/migrations for store_id, locale, position, and is_active, because those columns determine multi-store and multi-language behavior. If store_id is absent, a block authored for one channel may render on every channel.
- How does the category banner block resolve its category, and what happens when a category is deleted?
- The resolution method is the most decision-relevant part of the codebase, and the release note does not document it. Check whether the block binds by foreign key, polymorphic relation, or pivot, because that determines multi-category reuse and orphan behavior. Confirm the delete behavior before relying on the block in production.
- Does bagistoplus/basic-blocks support multi-store or channel-scoped content?
- Storefront scoping is unverified in the provided release note. Inspect the block table for store_id and check how the resolution method applies channel scope. Without store scope, a banner authored for one channel can silently render on all of them.
- Are views namespaced, and will theme overrides survive vendor:publish?
- The release note does not state whether the package uses loadViewsFrom with a basic-blocks:: namespace or publishes views into the theme path. If views are published into the theme path by default, theme overrides can be lost on the next vendor:publish. Confirm the view loading approach before customizing templates.
- Does the package have tests or CI, and what should I test before upgrading?
- No test or CI signal is documented, and the evaluation score is based on a single release note. Write a feature test that covers a category with a block, without a block, and with the block disabled, and run it before and after every upgrade. Regression coverage for the block render path is your responsibility.
- How quickly do block changes appear on the storefront, and is cache invalidation handled?
- Cache invalidation is unproven in the provided context. The core value of swapping a banner without a deploy depends on immediate save-to-render latency. Verify the save-to-render path in a staging storefront before promising merchandising teams that changes are instant.
Weaver
How can I help you explore Laravel packages today?