A store in Arabic, run from one panel. 

A hero banner with the current promotion, a category carousel, featured products and new arrivals. Navigation covers home, shop, about and contact, with sign-in for customers and a floating shop button.

The hero is an "ad" managed in the dashboard (tag, title, description, image and an optional product link), and the about, vision, mission, terms and privacy pages come from the dashboard's content section.

Promotions change often. Letting the team swap the hero and edit pages themselves means the store never waits on a developer to stay current.

A searchable shop with category shortcuts, sorting (newest, oldest, price up, price down) and a product-type filter. Each card shows the category, product code, price with the original price struck through, the discount percentage, a featured badge and how many are in stock, with add to cart on the card itself.

Discounts are computed from the compare-at price set in the dashboard, and stock comes straight from the product record, so the card never shows a price or quantity the backend doesn't have.

Shoppers decide from the grid. Showing the saving and the stock level up front turns browsing into adding to cart.

The product's category and code, name, price, a stock badge, variant options (sizes here), a quantity stepper, add to cart and the description, next to a large product image.

Variants are defined per product in the dashboard as named selections with options, so the same page handles sizes, colours or any other choice without new code.

Clothing lives and dies on sizes. A clear selected state and a visible stock count cut the back-and-forth that kills small-shop conversions.

Total users, total orders, net revenue and pending orders; gross revenue from delivered orders, the refunded amount and net revenue; and trends for orders, revenue, refund deductions and refund requests over a chosen period (this week, this month, last month, last three months).

Gross revenue is summed from delivered orders only, and completed refunds are subtracted to give net revenue, all computed on the server from order and refund states.

A store that reports gross sales overstates its income every time it refunds. Showing net revenue first keeps the owner's numbers honest.

Totals for all, pending, confirmed, shipped, delivered and cancelled orders, plus refund counts by stage. Filters cover customer email, sort order, status, period and refund state. Each order card shows the customer, item count, date, status, refund badge and total.

Order status and refund status are separate fields, so a delivered order can carry an open refund request without losing its delivery history.

Treating a refund as a status would erase the fact that the order was delivered. Keeping them apart makes both the timeline and the accounting correct.

An all-time refund overview with counts at each stage and the total deducted from revenue, plus a queue of the latest orders needing attention: pending orders and active refund requests, each linking straight to the order.

A refund advances one stage at a time, and only a completed refund is deducted from revenue. The attention queue is a server query over pending orders and open refunds.

Refunding before the product comes back is how small shops lose money. A staged workflow makes "product received" a required step, not a hope.

Name, SKU, description, price, compare-at price, stock and category, a featured flag, up to five images, free-form attributes (key and value) and variant selections with options. Below it, the product list with category, stock and price, filterable by category.

Images are uploaded through the dashboard, and attributes and selections are stored as structured data on the product, which the storefront renders as specs and variant pickers.

Small stores sell very different things, from biscuits to jackets. Generic attributes and selections let one product model fit them all.