- How do I install ibrand/laravel-shopping-cart in a Laravel app?
- Install it with composer require ibrand/laravel-shopping-cart. The package follows standard Laravel conventions: a service provider, a Cart facade, and a publishable config file, so on Laravel 5.5 and newer the provider and alias are usually auto-discovered. If you are not on auto-discovery, register the provider and facade alias in config/app.php and publish the config with vendor:publish. Check that the illuminate/* constraints actually resolve against your Laravel version before you commit to it.
- Does ibrand/laravel-shopping-cart work with Laravel 10, 11 or 12 and PHP 8.2?
- Probably not out of the box. The last tagged release is from January 2018 and most plausibly targets Laravel 5.5 to 5.6 on PHP 7.x, so expect Composer constraint conflicts on Laravel 10 and above with PHP 8.2 or newer. Resolving that is a fork-and-bump job, not a config change. The code surface is small, so getting it green on a modern stack is realistically a one to three day spike.
- Does this Laravel cart package use session storage or database storage?
- It supports both session and database storage, selectable through configuration. Session storage is the simplest option for a single-node app, while database storage persists the cart across requests and servers and typically requires publishing and running the package migrations. Before going to production, confirm how the chosen driver behaves across multiple nodes and on login and logout.
- Can I have multiple separate cart instances, for example a basket and a wishlist?
- Yes. Multiple cart instances are an explicit feature, so you can keep a default basket alongside a saved-for-later or wishlist cart and address each by name through the cart manager. Test your instance naming and the interaction with your storage driver, since session and database backends can behave differently under the same name.
- How do I apply discounts or coupons with item conditions?
- The package models cart conditions on top of line items, which is where discount and coupon style adjustments belong. Whether you can register your own condition types cleanly depends on whether the resolution logic is exposed through public extension points. If it is not, you will end up patching vendor code, so inspect the condition class before you build on it.
- How do quantity updates and totals calculation work?
- You update the quantity on an existing line item and the package recalculates line totals and the cart total, which is the classic line-item domain of unit price times quantity. Always call that recalculation server-side at checkout rather than trusting any total posted by the browser. Write tests around rounding and multi-item carts, because that is where small cart libraries usually break.
- Is ibrand/laravel-shopping-cart safe to use in production for real money?
- The critical question is pricing integrity: prices and conditions must be recomputed server-side on every read and at checkout, never accepted from client input. If any price or condition state can be set from the request, treat it as a revenue-integrity defect and fix it in a fork before shipping. Also make rounding and currency handling explicit, since the package does not enforce them for you.
- Is ibrand/laravel-shopping-cart still maintained, or should I look for alternatives?
- It has had no release since early 2018, one maintaining organization, no dependent packages, and roughly 37 stars, so treat it as abandoned upstream. If you adopt it, vendor it into your own namespace, pin the version, add CI and tests, and own it internally. On Laravel 5.5 to 5.8 with PHP 7.x and simple needs it saves time; on a modern stack it is better used as reference material for a thin in-house cart service.
- What happens to the guest cart when a user logs in?
- Guest-to-user cart merge is not a documented feature of this package, so assume you have to implement it yourself. Decide whether the merge is additive, replace-on-conflict, or quantity-summed, and make it idempotent so a double login cannot duplicate line items. This is one of the areas where a small 2018-era cart package typically stops short of real e-commerce requirements.
- Does the package handle tax, multi-currency and rounding?
- No. Its scope is line items, quantities, unit price, line totals and conditions; tax engines, multi-currency pricing and B2B tiered pricing sit above it. Rounding rules are likewise your responsibility, and you should apply them consistently at the boundary of the cart and your price source of truth. Budget that mapping work separately from the integration itself, because it is usually larger than the install.