- How do I install overtrue/laravel-shopping-cart in a Laravel app?
- Install it with Composer using composer require overtrue/laravel-shopping-cart. On Laravel 5.5 and later the service provider and Cart facade alias are auto-discovered, so no manual registration is needed; older versions require adding both to config/app.php. Because the package is archived, expect its illuminate constraints to block installation on current Laravel releases until you widen them or vendor the source.
- Does overtrue/laravel-shopping-cart support Laravel 10 or Laravel 11?
- Not out of the box. The last release dates from October 2019, so its illuminate/support and PHP constraints predate Laravel 8 and beyond. To run it on Laravel 10 or 11 with PHP 8.2+ you will need to fork the package, widen the Composer constraints, and test the facade and session interactions yourself, since there are no upstream fixes.
- Does this package require database tables or migrations?
- No. Cart data is stored entirely in the Laravel session, so there are no migrations, tables, or config files to publish. That keeps setup trivial, but it also means carts are bound to session lifetime and cookie integrity, and there is no queryable record for abandoned-cart recovery, reporting, or support tooling.
- How do I add item attributes like size or color to a cart item?
- You pass an attributes array alongside the item ID, name, quantity, and price when adding a line item, and the package keeps those variants attached to that cart entry. This lets you treat the same product in different sizes or colors as distinct cart lines. Totals and counts then reflect the combined quantities across those attribute variants.
- How do I calculate the cart subtotal, total, and item count?
- The facade exposes helpers for subtotal, total, item count, and searching cart contents, so you can render a summary in Blade, Livewire, or Inertia without writing your own aggregation logic. Conditions such as tax, shipping, or discounts are applied when the total is evaluated, so call total after your conditions are registered. Keep in mind there is no price snapshotting, so store the price you charged on the order when you convert the cart.
- Can I run multiple separate cart instances in the same application?
- Yes. The package supports multiple named cart instances, which is useful when you need a wishlist-style cart alongside an active checkout cart, or separate carts per storefront. Each instance behaves independently for adding, updating, removing, clearing, and totaling items.
- How do I apply tax, shipping, or discount conditions to the cart?
- Conditions are the package's extension seam: you register a condition that inspects the cart and adjusts or reports the total for tax, shipping, or promotions. It is the cleanest part of the API and the main reason the package is still worth studying. Validate ordering and idempotency of conditions carefully, because the package does not guard against double-applied discounts.
- What happens to the cart when a user logs out or the session expires?
- The cart is destroyed along with the session. Logout, session rotation, cookie loss, or exceeding the roughly 4KB cookie limit will silently empty it, and there is no guest-to-authenticated cart merge logic. If cross-device carts, guest checkout continuity, or abandoned-cart email matter to your UX, plan to back the cart with your own database repository instead.
- Is overtrue/laravel-shopping-cart still maintained, and what are the alternatives?
- No. The repository is archived and unmaintained, so there are no security patches, PHP or Laravel upgrade support, or bug fixes. Common alternatives are a maintained package such as darryldecode/cart, a fork you own and vendor privately, or a thin first-party cart service with database-backed carts, cart_items, and conditions—the last option has the best total cost of ownership if you need persistence or analytics.
- Can I use this package in an API-first or SPA application without relying on sessions?
- It is a poor fit there. Persistence and identity are delegated entirely to the HTTP session, so a token-based API, a separate SPA frontend, or a microservice cannot use it without wrapping it behind your own persistence and service interface. It works best in a server-rendered Laravel monolith where the session is already the state boundary, paired with a checkout service that converts the cart into an order.