- How do I install tomatophp/tomato-category-module in a Laravel app?
- Install it with composer require tomatophp/tomato-category-module, then publish the package migrations and config, run php artisan migrate, and register the Filament resource in your admin panel. In a typical TomatoPHP app this is a short setup, but confirm the service provider auto-discovery and publish tags in the README for your version. Run migrations as a dedicated deployment step rather than bundling them into a general release.
- Does this package require Filament, or can I use it with plain Laravel?
- The module is built for the TomatoPHP admin ecosystem on Laravel and Filament, and much of its value is the pre-built CRUD/resource layer. You can still evaluate the Eloquent model and migrations in isolation, but if your admin layer is Nova, Backpack, or hand-rolled Blade, you are paying for UI you will not use. In that case a leaner taxonomy package or a small bespoke implementation is usually the better fit.
- Which Laravel and Filament versions are supported?
- The supplied assessment assumes Laravel 10 or 11, PHP 8.1+, Livewire, and Filament v3, but the exact composer.json constraints are not verified in the release artifact. Check the package composer.json for Laravel, Filament, and PHP major-version constraints before adopting it. The Filament major version must match your host application, so resolve that first in a spike.
- How does the category hierarchy work, and is reordering expensive?
- The package provides hierarchical, sortable categories, but the supplied materials do not confirm whether the tree is nested-set, adjacency-list, or closure-table. That choice determines whether reordering is a cheap UPDATE or an expensive subtree rewrite, especially at 10k+ nodes. Inspect the migration and model methods, then benchmark move-subtree and reorder operations against realistic data.
- Can I attach categories and tags to any Eloquent model?
- Yes, the intended design is a category/taxonomy module with a polymorphic categorizable pivot so other domain entities can be tagged without adding taxonomy columns to every model. The overview explicitly says it manages categories, tags, and types for any model. Confirm the morph map and pivot table names in the published migration before wiring it into existing entities.
- What migrations and database tables does it add?
- Expect publishable migrations and config that create category storage separate from the models being categorized. The exact table names and whether they are namespaced are not verified in the supplied artifact, so review the migration files before running them. Confirm the tables are additive and will not collide with an existing categories table or enum-based taxonomy.
- Is it safe to upgrade from v1.0.0 to v1.0.1 in production?
- v1.0.1 is a patch release off v1.0.0, but its release notes contain only an auto-generated changelog link with no commit summaries or migration notes. Treat the delta as unknown-but-presumed-non-breaking until you review the diff, and check whether it touches migrations or published config. Pin versions and test the upgrade in staging before production.
- What happens when I delete a category, and do pivot rows cascade?
- The supplied assessment does not confirm whether category deletion is soft or hard, or whether the polymorphic pivot cascades or leaves orphan rows. Review the migration foreign-key definitions and the model's deleting behavior before relying on it. At minimum, test deleting a parent category with children and attached models in a staging database.
- Is tomatophp/tomato-category-module actively maintained?
- TomatoPHP is a single-vendor, small-team OSS ecosystem with a fast release cadence, so maintenance concentration and bus factor are real considerations. The modules are cohesive by design, and adopting one creates gravitational pull toward the suite. Pin versions deliberately, vendor-lock where sensible, and keep an exit plan for a bespoke taxonomy implementation, which is bounded but real work.
- What are the alternatives to this TomatoPHP category module?
- If you are already committed to Filament and TomatoPHP, this module is a conventional fit because it supplies models, migrations, and admin CRUD for taxonomy. If you are not, evaluate the schema and model in isolation or choose a leaner taxonomy package rather than inheriting a UI layer and ecosystem coupling. The main alternatives are a small custom categories table with a polymorphic pivot or another Laravel taxonomy package that matches your admin stack.