- Is bumbummen99/shoppingcart compatible with Laravel 10 and Laravel 11?
- The last tagged release was in May 2022, so Laravel 10 and 11 support cannot be assumed. Run a short spike that installs the package under your target Laravel and PHP versions and exercises add, update, remove, conditions, and totals. Pin the package version explicitly and add a CI matrix over the framework and PHP versions you actually deploy. If the tag does not satisfy your constraints, budget for a fork rather than discovering the gap mid-project.
- How do I install bumbummen99/shoppingcart in a Laravel app?
- Install it with Composer and rely on package auto-discovery, then optionally publish the config if you want to define tax, discount, or shipping rules. You interact through the Cart facade using the familiar add, content, update, and remove API inherited from the Crinsane lineage. Most Laravel developers can have a working cart wired into a controller or Livewire component in an afternoon. No order or payment infrastructure is included, so checkout remains your responsibility.
- Does this package support multiple cart instances?
- Yes, one of its headline features is support for multiple named cart instances, so you can keep separate carts for different contexts such as a wishlist versus an active basket. Each instance holds its own collection of items and its own conditions, taxes, and totals. This is still a transient pre-checkout object, not a durable commerce record. Keep instance names behind your own service layer so the vendor API does not leak into controllers.
- Can I persist cart contents to the database instead of the session?
- The package supports both session and database storage, which helps with cart durability across requests and instances. Real durability, concurrency behavior, and horizontal scaling still depend on your configured session driver, so verify Redis or database sessions in production rather than assuming. If you need abandoned-cart recovery, cross-device carts, or B2B quotes, treat this as insufficient on its own. Those flows require queryable cart state that you own and model explicitly.
- How do taxes, discounts, and shipping work in bumbummen99/shoppingcart?
- Totals are calculated through conditions, a lightweight mechanism for adding tax, discount, and shipping adjustments on top of the item subtotal. The package performs the arithmetic, but your application supplies every price, rate, and rule. That means the cart is never the price authority and every total must be re-validated server-side at checkout. Complex promotion stacking, multi-jurisdiction tax, and multi-currency pricing go beyond what simple conditions are designed for.
- Is bumbummen99/shoppingcart a drop-in replacement for Crinsane/LaravelShoppingcart?
- It is the conventional upgrade route for teams already on Crinsane and historically preserves the original namespace and API surface. Do not assume drop-in behavior blindly; check the exact namespace and method signatures against the specific tag you install. Treat the move as an API-compatibility exercise rather than a data migration, since cart contents are ephemeral. A feature-flagged parallel run is a cheap way to confirm parity before cutover.
- How should I test this shopping cart package in CI?
- Run a smoke test that covers add, update, remove, conditions, and total calculations on every supported Laravel and PHP combination. Test against your production session driver rather than the array driver, because most latent defects only surface with Redis or database sessions. Pin the package version so a missing release cadence cannot silently change your test surface. Add a server-side re-pricing assertion at the checkout boundary as well.
- Can I use this cart package for a headless or API-first storefront?
- It is a poor fit for headless, API-first, or multi-tenant commerce because it is a session-backed, transient cart with no price authority or catalog model. If you must use it, wrap the facade behind an internal CartService contract and expose JSON endpoints from your own controllers. That keeps the vendor API out of your front-end contracts and makes the package replaceable later. For SPA and mobile clients that need durable, queryable carts, choose a different foundation.
- Is bumbummen99/shoppingcart actively maintained and safe for production?
- It is a single-maintainer fork with no tagged release since May 2022 and no visible security-patch process, so maintenance risk is real. The reported dependent count is zero, which understates actual usage but is not a substitute for upstream health. Treat it as a small, replaceable domain utility rather than a foundation for revenue-critical flows. Decide up front who owns the code and whether you have budget to vendor and patch it if upstream goes dormant.
- Does this package handle orders, payments, inventory, or multi-currency?
- No. It is a cart, not a commerce platform: there is no order lifecycle, inventory reservation, payment orchestration, or price authority. Multi-currency catalogs and multi-tenant or multi-region pricing are outside its scope. Pair it with your own order and checkout services, and always re-price server-side before capturing payment. If those capabilities are requirements from day one, evaluate a full commerce platform instead.