- What is tomatophp/tomato-ecommerce and what does it include?
- Tomato Ecommerce is a Composer package for Laravel from the TomatoPHP ecosystem that adds a complete online store to your application. It covers products, categories, carts, checkout, orders, coupons, shipping, tax, payment handling, multi-language settings and a clean admin interface built on Filament. It is designed to be installed into an existing Laravel monolith that already runs a TomatoPHP and Filament panel.
- How do I install tomato-ecommerce in a Laravel app?
- Install it with composer require tomatophp/tomato-ecommerce, then publish the package config and migrations, run php artisan migrate and seed any required data. The package follows TomatoPHP conventions, so it expects the Tomato module loader and a Filament panel to already be present. Try it in a disposable Laravel app first and walk the product to cart to checkout to order path before wiring it into a real project.
- Which Laravel, PHP and Filament versions does tomato-ecommerce support?
- The package is built for the TomatoPHP ecosystem, which typically targets Laravel 10 and 11, PHP 8.1 or newer, and Filament v3. Because TomatoPHP modules version together against a shared panel constraint, check the exact Laravel, PHP and Filament ranges declared in composer.json before installing. Pin the exact version you evaluate rather than relying on a caret range, since patch releases are frequent and their notes are terse.
- Does tomato-ecommerce work for headless or Inertia and React storefronts?
- It is a poor fit for headless or API-first setups such as an Inertia and React storefront or a separate front end, because its models and services are shaped around an admin panel. You can still use it as a back-office toolkit and write a service layer over its Eloquent models, but budget for that adapter explicitly. If you want to own your commerce domain model, a framework-agnostic package is a better choice.
- Are payments, tax, shipping and refunds fully implemented in tomato-ecommerce?
- The package advertises products, cart, checkout, orders, payments, coupons, shipping and tax, but capability depth varies in packages at this maturity level. Payment integration is usually the thinnest and most vendor-specific part, and refunds, inventory reservation and detailed tax rules are common gaps. Verify each flow end to end against your own requirements instead of assuming the feature list is fully implemented.
- Are the migrations publishable and reversible, and can I own the schema?
- TomatoPHP packages typically ship publishable migrations, so you can publish them and own the schema inside your application. Confirm in your test install whether the migrations are reversible and whether they are additive to an existing database or collide with existing commerce tables. Existing commerce tables are the most likely source of integration pain, so diff the generated schema against your current one before committing.
- Is tomato-ecommerce production ready, and how stable is the 1.0.x line?
- The 1.0.x line has had eight patch releases with terse notes, and the latest one only updates an icon, which tells you little about stability or direction. There is no visible CI badge, coverage report or detailed changelog in that release, so treat quality signals as unverified. Pin the exact version and expect to do your own testing before putting the package in a revenue path.
- Does tomato-ecommerce support multi-language stores, coupons and multiple currencies?
- Yes, the package includes multi-language settings along with cart and ordering functions, coupons, shipping, tax and payment handling. These are configured through the package config files and the Filament admin interface rather than a separate settings API. Check that the language and currency behaviour matches your storefront requirements, since admin-centric packages often assume a single storefront.
- How should I test the checkout and order flow before committing to tomato-ecommerce?
- Create a throwaway Laravel app, install the package, publish config and migrations, migrate and seed, then walk the golden path from product to cart to checkout to order to fulfillment. Place a test order with a coupon, a shipping option and a tax rule to confirm those settings actually apply. Then diff the generated schema against your production schema before considering a real integration.
- When should I choose an alternative to tomato-ecommerce, and what are the main risks?
- Consider alternatives if you need a headless commerce API, want full ownership of the domain model, or cannot accept small-team and single-maintainer risk in the revenue path. The main technical risks are ecosystem lockstep, where one patch can force a family-wide Filament bump, and migrations you must own yourself. If you stay, pin versions and confirm whether commercial support and documented payment and shipping extension points exist.