Gradia POS – Modern Point of Sale for WooCommerce
| 开发者 | briangradyzer |
|---|---|
| 更新时间 | 2026年9月24日 05:14 |
| PHP版本: | 7.4 及以上 |
| WordPress版本: | 7.1 |
| 版权: | GPL-2.0-or-later |
| 版权网址: | 版权信息 |
详情介绍:
Gradia POS turns your WooCommerce store into a fully-featured Point of Sale terminal — accessible directly from a browser, no dedicated hardware needed.
Key Features:
- 🛒 Fast product search by name, SKU, or barcode scan
- 💳 Payment gateways pulled directly from WooCommerce (local or remote store)
- 🖨 Receipt printing for both local and external WooCommerce orders
- 🌐 Remote WooCommerce store bridge via REST API (Consumer Key / Secret)
- 📦 Add and edit products from within the POS terminal
- 📷 WP Media Library image picker in product forms (with URL fallback)
- 👥 Role-based access: Administrator, Shop Manager, Supervisor, Cashier
- 📶 Offline support with IndexedDB order queue and auto-sync
- ⭐ Built-in customer rewards and loyalty points
- ⏰ Shift tracking with clock-in/clock-out, shift log, and live monitor
- 🎁 Tips and gift cards at checkout
- ✉️ Optional digital receipt by email, alongside printing
- 🎨 Glassmorphic UI with customisable accent colour and dark mode
- 🔒 All API credentials encrypted at rest (AES-256-CBC)
安装:
- Upload the
gradia-posfolder to/wp-content/plugins/ - Activate the plugin through the Plugins menu in WordPress
- Navigate to WP Admin → Gradia POS to configure your store settings
- Assign users the Cashier role via WP Admin → Gradia POS → Cashier Users
- Cashiers are automatically redirected to the POS Terminal on login
屏幕截图:
常见问题:
How do I connect an external WooCommerce store?
Go to WP Admin → Gradia POS → Settings and enable Remote Mode. Enter the external store URL and a WooCommerce Consumer Key / Secret with read/write permissions.
What roles can access the POS?
Administrator, Shop Manager, and Cashier. Administrators control which Cashiers can add or edit products via WP Admin → Gradia POS → Cashier Users.
Can Cashiers edit products?
Yes — if explicitly enabled by the Administrator in POS Settings. Shop Managers and Administrators can always add and edit products.
Does it work offline?
Yes. Products are cached in IndexedDB. Cash orders placed offline are queued and synced automatically when the connection is restored.
Can I print receipts for external store orders?
Yes. A local receipt is generated for every order (local or remote) and includes the correct change calculation.
更新日志:
10.03.05
- Renamed the plugin to "Gradia POS – Modern Point of Sale for WooCommerce" (plugin header and readme both updated to match)
- The cash drawer no longer pops open automatically for card/electronic payments — it now only fires the drawer-kick command (QZ Tray and PrintNode both) when the payment method was actually cash. A new machine-readable paymentMethod field was added alongside the existing display-label field everywhere receipt data gets built (local orders, remote orders, split payments — which check whether any of the combined payment parts was cash) so this can be checked reliably rather than guessed from tendered/change values, which have edge cases (an exact-cash payment shows change=0, same as a card payment would).
- Found and fixed the actual root cause of remote-mode charges failing whenever a customer was selected: "Customer ID is invalid." A customer picked on the POS is always a local WordPress user (that's where reward-points meta lives), but in remote mode the order gets created on a completely separate WooCommerce install with its own separate customer table — the local ID meant nothing there, and WooCommerce's own REST API correctly rejected it.
- Fixed by resolving the local customer to a real remote customer by email at the point of order submission — looking them up on the remote store, creating one there if none exists yet, and caching the mapping so repeat customers only need this resolved once. Falls back to guest checkout on the remote order (rather than blocking the sale) if the local user has no email or the remote store can't be reached.
- Checkout hardening on top of 10.03.02's fix: the order-creation response now goes through the plugin's own resilient JSON parser (already used elsewhere in this file) as an extra defensive layer against any future stray PHP output corrupting the response, on top of the actual root-cause fix already shipped. Phase 2 finalisation stays fire-and-forget (deliberately not awaited — blocking every sale on it would mean an error there looks identical to a failed charge, when the charge already succeeded, risking a duplicate), but now shows a toast if it fails instead of staying silent, and is skipped entirely for remote orders, which never use it.
- Found the actual cause of remote-mode charges silently failing to produce a receipt (was diagnosed and fixed on the Pro side after live testing there, this plugin had the identical bug and is fixed the same way): two variables ($sub_pre, $subtotal_raw) in the remote order-creation code were only defined inside a conditional block or later in the function, but used unconditionally/earlier elsewhere. A sale with a rewards redemption but no separate POS discount hit the first one directly; the second was always latent regardless of discount, silently zeroing out every tax line (VAT/NHIL/GETFund) on the receipt. On a site with PHP warnings set to display, either one gets echoed into the AJAX response ahead of the JSON, breaking it client-side. Both now compute unconditionally before their first use.
- Fixed the previous fix: syncing a rewards-selected customer to the basket's customer field was also firing the same event used for selecting a customer before adding items, which independently triggers price-level re-pricing. With the payment modal already open and totals already fixed, that re-pricing happened silently mid-checkout, so the charge the server received no longer matched the modal's numbers, and Confirm & Charge just failed silently instead of producing a receipt. The sync no longer fires that event, only the two fields it actually needs to set.
- Versioning correction (again — this one's on me): 10.02.21 should have wrapped to 10.03.01
- Fixed a real bug: selecting a customer inside the Rewards redemption modal never updated the basket's own customer field, so the order was still created against Walk-in Guest even though the points redemption correctly happened against the right customer. Now syncs automatically, without overriding a customer the cashier deliberately selected separately.
- Removed the customer name/reward-points receipt feature added in 10.02.20 — that's a Pro-only feature and shouldn't have shipped here.
- Receipts now show the reward points a purchase will earn (when a customer is selected), alongside the points-remaining balance already shown. Clearly separate from the confirmed balance, since the cashier still confirms the actual award in a later step after the receipt prints — this is the same estimate that confirmation screen itself computes.
- Added the missing Text Domain header (gradia-pos) — WordPress can derive it from the slug without one, but every translation call in the codebase already uses this literal string, so declaring it removes any ambiguity
- Trimmed this changelog, which was well over WordPress.org's 5,000 character limit and being silently truncated
- Widened the option-migration fix to also catch options defined as class constants, not just literal strings; re-versioned the migration guard to run again for anyone who got the earlier, incomplete pass
- Extended role migration to also catch custom staff roles created before the prefix rename, not just Cashier/Supervisor
- Fixed data appearing to vanish after updating (empty products, blank categories) — added a one-time migration for options and role assignments left behind by the grdpos_ → gradia_pos_ prefix rename
- Fixed a fatal error on every front-end page load when neither local WooCommerce nor a remote store was fully configured yet
- Properly fixed the receipt print window's asset loading (enqueue + wp_print_styles/scripts instead of raw tags) and remaining email-escaping findings
- Removed dead 2FA and biometric sign-in code from the login page (inert markup and unreachable JS, no server-side path ever triggers either)
- Renamed every grdpos_ identifier to gradia_pos_ (functions, options, roles, AJAX actions, JS globals/events, CSS classes) to avoid a real collision with Portal Cloud 9 Pro
- Fixed a dead nonce field, a dead self-referential code block, and a real drawer-open AJAX action name mismatch found while verifying the rename
- Removed a leftover AJAX action registration pointing at an undefined callback, a latent fatal-error risk
- WordPress.org review remediation: receipt print window assets moved to external files, discount-label/email escaping fixed, several phpcs:ignore suppressions replaced with proper wp_kses() calls, esc_attr() added to CSS-generating functions, esc_url_raw() corrected to esc_url()
- Renamed the p9PosData JS global to grdposData
- Fixed the SKU/Barcode scan button showing the theme's pink accent instead of the intended style, and swapped its icon for an actual barcode icon