Cart

The Cart component is the transaction half of the hub's online store. It holds the shopper's basket, the checkout, and the order record; the catalogue of products and SKUs lives in the Storefront component. In the administrator interface Cart is a set of reports: what has been ordered, and what has been downloaded.

Like Storefront, Cart is disabled on a new hub, and most hubs leave it that way. The two go together: the storefront's product pages call into Cart to add an item, and Cart's screens read the catalogue back out of Storefront, so enabling one without the other gives you a store nobody can buy from or a set of reports with nothing to report on. Enable both or neither, under Extensions → Extension Manager → Manage. See Storefront for how the hub's four money-handling components fit together.

Two things bring a manager here once the store is running. A buyer says they have run out of downloads and wants another; or someone asks what was sold last quarter. Both are below.

Go to Components → Shopping Cart. Two submenu links sit at the top:

• Software Downloads
• Orders

Every screen needs core.manage on com_cart.

Software Downloads

Cart records a row every time someone downloads a purchased software SKU. Two reports read those rows.

All downloads

The default screen. Its columns are Product, Downloaded by, User Info, EULA, Downloaded, IP, and Status. Product, Downloaded by, Downloaded and Status are sortable.

Above the table are a Search box, an All SKUs drop-down, and From and To date fields with an Update button. The date window defaults to the last month. Clicking a user's name, a product, or a SKU in the table adds that as a filter; a Clear button in the table header removes it.

Download CSV in the toolbar exports the current date range and sort as cart-downloads-<date>(<from>-<to>).csv, with the columns Downloaded, Product, SKU, User, Username, User ID, User Details, EULA, IP, and Status. The export is written in chunks of 5000 rows, so a large report streams rather than exhausting memory.

Downloads by SKU

A roll-up: one row per SKU, with Product, SKU, and Downloaded — the number of download records in the date window. It has its own search and date filters and its own Download CSV button.

Marking a download inactive

This is the one repair Cart offers, and it is the reason most managers open the component. A member bought a code, downloaded it, lost the machine, and has hit the per-user download limit. Marking their old download record Inactive takes it out of the count and gives them the download back.

Click the icon in a row's Status column to flip that record between Active and Inactive.

Working through the example: filter the list by clicking the member's name in the table, widen the From date if the download is older than a month — the window defaults to the last month, so an old record simply is not there — find the row, and click its Status. The change takes effect on their next attempt; nothing is emailed and no order is altered. It is reversible: click the status again to make it active once more.

This matters when a SKU carries download limits. Cart counts only active download records against a limit, so marking an old record inactive gives the user another download. There are three limits, all set on the SKU or product in Storefront under Software:

Setting	Where	Effect
Downloads Limit per Single User	SKU	How many active downloads one account may have of this SKU
Total Downloads Limit	SKU	How many active downloads exist of this SKU across all users
Total Downloads Limit	Product	The same, counted across every SKU of the product

A limit of 0 or empty means no limit.

Orders

All orders

One row per completed transaction: Order ID, Order total, Items ordered, Order placed, Purchased by, and Payment method. Order ID, Order placed, Purchased by and Payment method are sortable.

The filters are a Search box, an Order notes drop-down (All notes or Only nonempty notes), and the From/To date window. Download CSV in the toolbar exports the list.

Click an order ID to open it.

Viewing an order

The order view shows Order Details, Shipping info, Payment info, Items Ordered, Notes/Comments, and a Changelog listing every administrative edit with who made it and when.

Edit on the order view opens a form that can change:

• the payment details string,
• the price and quantity of each item ordered,
• the checkout notes on each item, and
• the order's own notes.

Saving records the difference in the order's changelog. Nothing else about a completed order can be changed from here — there is no order status field and no way to add or remove items.

Items ordered

A line-item report across all orders: SKU ID, Product, QTY, Price, Order ID, Order placed, and Purchased by. It has the same search and date filters, and its own Download CSV button.

Options

Press Options in the toolbar of any Cart screen. The full list is in the generated parameter reference; the ones that matter day to day are:

• Send notifications to — a comma-separated list of addresses that get an ORDER NOTIFICATION mail on every new order. Leave it empty and no notification is sent.
• Send order info from — the address the shopper's order confirmation appears to come from. Must be a valid address or the site's mailfrom is used instead.
• Store administrator ID — the numeric user ID that receives payment processing error mail.
• Transaction TTL — minutes a pending transaction holds its inventory before the items are released back to stock. Default 120.
• The Payment fieldset holds the payment provider name, environment, site ID, and validation key. Two providers ship with the component: DUMMY AUTO PAYMENT and UPAY.

A note on permissions

Reaching any Cart screen needs core.manage on com_cart. Beyond that, the component's permission handling is thin:

• The toolbar buttons are hidden by checks against the asset names com_cart.download, com_cart.orders, and com_cart.order. Only download is declared in config/access.xml, and none of the three has a permissions form of its own, so in practice all three inherit the component-level rules on the Options → Permissions tab.
• The controllers themselves do not repeat those checks. A user who can reach the component can activate a download or save an order edit by posting directly, whatever the toolbar shows.

Grant core.manage on com_cart only to people you would also let edit orders.