- Is baks-dev/products-category a Laravel package?
- No. Despite being described in some listings as a Laravel/PHP package, the install and operations instructions use php bin/console, baks:assets:install, and doctrine:migrations:diff and doctrine:migrations:migrate. There is no artisan command, no service provider publish step, no Eloquent models, and no Blade views. It is a Symfony bundle built for the BaksDev e-commerce platform with Doctrine ORM as its persistence layer.
- How do I install baks-dev/products-category?
- Run composer require baks-dev/products-category, then run php bin/console baks:assets:install to install the configuration and file assets. You must also create the cover upload directory and set permissions manually with sudo mkdir <path_to_project>/public/upload/product_category_cover followed by sudo chmod 773 on that directory. Confirm your application is on PHP 8.4 or higher before starting.
- Can I use this package in an existing Laravel application?
- Architecturally it is a poor fit. Laravel uses Eloquent and its own migration runner, so adopting this bundle means either running dual ORMs or doing a full Doctrine integration through something like laravel-doctrine/orm. That is a much larger commitment than adding a simple category table. For a Symfony or BaksDev codebase the bundle is conventional and plausible; for Laravel it is not.
- What PHP version does baks-dev/products-category require?
- The README badge specifies a minimum of PHP 8.4. That is a hard gate and should be verified before anything else, because it disqualifies many existing production estates. You also need to confirm the host application and all sibling baks-dev dependencies are on 8.4.
- How are database migrations handled?
- Migrations are not shipped with the package. The documented flow has the integrator run php bin/console doctrine:migrations:diff to generate migrations from the current Doctrine mapping metadata, then doctrine:migrations:migrate to apply them. This means you own the migration history forever, schema drift is likely, and vendor upgrades can silently change the generated diff. It is the single largest long-term operational cost of adopting the bundle.
- Where are product category cover images stored?
- Cover images go to a fixed public/upload/product_category_cover path that you create manually and chmod to 773. That permission is group- and world-writable and bypasses Laravel's storage abstraction and storage:link workflow. Offloading to S3 or a CDN requires overriding the bundle's storage layer, so plan for that if you need cloud storage.
- Does it support translations for category names?
- There is no evidence of i18n support for category names in the documentation. The README and package documentation are Russian-only. If you need multilingual category labels, treat that as custom work until you have read the source.
- Is baks-dev/products-category production ready and actively maintained?
- Treat maturity as high risk. The package has zero stars, zero dependents on Packagist, and a single maintainer, and release notes for recent versions are literally just the version string with no changelog or breaking-change signaling. One release is dated in the future, which suggests untrustworthy release provenance. There is no stated security disclosure process and the MIT license permits forking if you need to take ownership.
- How do I run the test suite for this package?
- The README documents running php bin/phpunit --group=products-category. Note that this relies on the host application's PHPUnit binary rather than a self-contained test setup. Verify coverage yourself before relying on it for upgrade safety.
- What are the alternatives to adopting this bundle?
- The domain scope is narrow: hierarchical product categories with cover images. A hand-rolled category table with a parent_id column plus an image column is on the order of days of work, not months. If you are on Laravel, that is almost certainly the better path; if you are already running BaksDev, this bundle is the conventional choice.