- How do I install tomatophp/tomato-products in a Laravel application?
- Install the package with Composer, publish its configuration and migrations, then run the migrations against your database. Register the Filament plugin in your panel provider and seed the permissions so the product resource appears for the right admin roles. The mechanical setup is small; the bigger decision is whether the package owns your catalog schema before you run that first migration.
- What features does Tomato Products add to a Filament admin panel?
- It gives you a product CRUD resource with catalog organization, category support, pricing fields, media handling, and translatable fields. It is built on Filament and Laravel conventions, so the screens sit alongside your other admin resources. The value is a working catalog back office in days rather than weeks.
- Is Tomato Products a complete e-commerce or checkout solution?
- No. It is a Filament admin module for product catalog management, not a commerce engine and not a headless catalog API. It does not cover pricing rules, tax, order orchestration, checkout, or inventory reservation. Treat it as buying an admin UI and inheriting a product schema, not as adopting a product platform.
- Which Laravel and Filament versions does tomato-products support?
- The package depends on Laravel and Filament, but a formal supported Laravel, PHP, Livewire, and Filament matrix is not published in the documentation. Check the composer.json constraints after installation and confirm the supported Filament major with the maintainer before you plan an admin-panel upgrade. Filament major transitions have historically broken plugin packages, so verify v4 compatibility ahead of time if that is on your roadmap.
- Do I need the full TomatoPHP ecosystem to use this package?
- For a high-fit install, your application should already be on Laravel, Filament, and the surrounding TomatoPHP core modules such as users, permissions, translations, and settings. Outside that stack the fit is low to moderate because the package's value lives in its Filament resources and its assumptions about adjacent Tomato modules. It is not a framework-agnostic domain model you can drop into any Laravel app.
- Can I customize the product schema or edit the published migrations?
- Migrations and configuration are publishable, but the migrations ship in vendor and are package-owned by default. Local edits to them create a permanent fork burden or migration-order conflicts when you upgrade. Decide up front whether the package owns the catalog tables or whether you will wrap and extend them, because migrating away later is a data project rather than a configuration change.
- Does Tomato Products support multi-tenancy or multiple stores?
- Multi-tenancy is not assumed by the package. Per-tenant or per-store catalogs require adding global scopes and migration work yourself, which pushes you toward forking or extending the package. If multi-tenant, multi-store, multi-currency, or product variants are near-term requirements, evaluate that before adopting a flat product table.
- Can I use Tomato Products as a headless catalog API for a storefront?
- Not directly. The package is designed around Filament admin resources, not API-first or headless delivery, so you would need to build an adapter or read layer over its tables. Your storefront, ERP, or PIM would be written against the package's schema. Confirm that schema is stable public API before committing downstream systems to it.
- Is Tomato Products actively maintained, and how do I upgrade safely?
- It is at 1.0.x with rapid patch releases and a single-maintainer, small-ecosystem profile, so weigh the support horizon rather than only today's functionality. Releases such as v1.0.18 have shipped as patch bumps with no changelog, making upgrades hard to triage without a source diff. Pin versions, read src/Models/Product.php and the migrations before upgrading, and test each bump in a throwaway branch. Ask the maintainer whether a changelog and semantic versioning policy will exist going forward.
- When should I choose Tomato Products instead of building custom Filament CRUD?
- Choose it when your app is already on Laravel, Filament, and TomatoPHP, and you need a product catalog admin surface quickly without justifying custom CRUD from scratch. Build your own or stop the spike if your application is API-first, needs complex pricing rules or inventory reservation, or has near-term variants, multi-currency, multi-store, or multi-tenant requirements. Retrofitting those onto a flat product table is the expensive path.