Moksa for WooCommerce
| 开发者 | moksa0923 |
|---|---|
| 更新时间 | 2026年10月9日 00:39 |
| PHP版本: | 8.2 及以上 |
| WordPress版本: | 7.1 |
| 版权: | GPLv3 |
| 版权网址: | 版权信息 |
详情介绍:
安装:
- PHP 8.2+
- WordPress 7.0+
- WooCommerce 9.9+
- Install and activate the plugin.
- Go to WooCommerce → Settings → Moksa for WooCommerce to enable the modules you need.
- Configure the credentials for each enabled provider on its dedicated tab.
屏幕截图:
常见问题:
Does it work with the Block-based Checkout?
Yes. Every payment method ships an AbstractPaymentMethodType + React component, and the convenience-store picker / invoice fields render inside the Checkout block.
Is it HPOS-compatible?
Yes. All order meta uses $order->update_meta_data() / $order->save(), never update_post_meta().
Can I mix providers?
Yes. Payment, shipping and invoice modules are fully independent — any combination works.
What is the Moksa AI assistant and what does it need?
It is an optional in-admin chat assistant for managing orders, e-invoices, shipping labels and module settings in natural language. It requires WordPress 7.0 (for the built-in AI Client) and an AI provider connected under Settings → Connectors; enable it under the plugin's Advanced settings. Every action that changes data first asks for your confirmation, and the assistant can never read or change your provider credentials, switch sandbox/live mode, or issue refunds.
Can external AI tools connect to my store over MCP?
Yes, optional and off by default. Turn it on under WooCommerce → Moksa AI → Settings → "Enable external MCP server". The plugin then serves a standards-compliant, stateless MCP (Model Context Protocol) endpoint at /wp-json/moksa-for-woocommerce/v1/mcp that any standard MCP client (for example mcp-remote or Claude) can connect to directly — no bridge required.
Authentication uses a WordPress Application Password for a user that has the "edit orders" capability; use a dedicated, limited account rather than an administrator. Connect your client to the endpoint with an Authorization: Basic <base64 of username:application-password> header. By default only read-only tools (look up orders, reports, settings overview) are exposed; order-changing tools stay hidden unless you also enable the "allow external AI to make changes" option, and destructive actions still require in-store confirmation. Every request is permission-checked on the server.
更新日志:
- An "Invoice number" column on the WooCommerce orders list, shown whenever an e-invoice provider is enabled. It reads whichever provider actually issued the invoice — ECPay, ezPay, Amego, PayNow, SmilePay, or PAYUNi's built-in invoice — and marks voided invoices. Like any column, it can be hidden from Screen Options. Fixed
- The "Invoice number" personalization tag in the block email editor only read ECPay invoices, so it came out empty for invoices issued by the other providers. It now reads all of them, and leaves voided invoices out.
- On the classic checkout, a half-width field could be pushed into the middle of the row and its partner dropped to the next line when the two fields above it differed in height by a few pixels (for example the country field being slightly taller than the state field). Each pair of half-width fields now starts on a new row.
- SmilePay payment notices could be forged. The only secret in SmilePay's check value is a 4-digit merchant code, leaving under a hundred values to try. Every new SmilePay order now carries its own signed key in the notification URL, failed checks stop automatic confirmation for that order after three attempts, and the check value is computed from the order total rather than the amount in the notice. Orders placed before this update keep the previous check.
- A late failure or payment-code notice could switch an already paid ECPay, NewebPay or SmilePay order back to failed or on hold, and overwrote the transaction number used for refunds. Such notices are now only recorded as an order note.
- An ECPay or NewebPay payment whose amount does not match the order total (for example an old payment tab completed after the cart changed) now puts the order on hold for review instead of marking it paid. Fixed
- ECPay shipping status follow-up checks and the order screen's status lookup never worked: ECPay's successful reply was treated as an error.
- PAYUNi store pickup on the block checkout: a first-time customer could not place an order, because the hidden address fields were still required.
- ECPay paper invoices were issued to the ECPay member carrier instead of being printed.
- ECPay tax-ID and paper invoices failed on store-pickup orders without a street address. The pickup store's address is now used.
- PAYUNi "hide billing address for store pickup" on the classic checkout: switching back to home delivery left the address fields marked optional.
- The AI assistant button appeared a second time inside the plugin-update screen. Changed
- Shipping status follow-up checks no longer save the order on every check (so no hourly order-updated webhooks), also compare the status description, rotate through every eligible order, and no longer run 8 hours late.
- The Taiwanese field layout is now switched on only from its own section. If the old "reorder fields" checkbox was off, the section starts off.
- The Taiwanese mobile number check is now its own setting and works without the Taiwan address tools.
- Half-width fields on the classic checkout could end up stranded at half width on their own — the phone field, for instance, whenever its neighbour had been hidden by store-pickup billing hiding, the country-hiding option, or a WooCommerce setting. Pairing was decided once on the server before any of that hiding happened. It is now re-checked in the browser from the fields actually on screen, every time the checkout refreshes, so a field whose partner disappears takes the full row.
- The email field could not usefully be set to 50% width: pairing reserved a slot for it on the shipping address form, which has no email field, so its neighbour there fell out of step. Pairing is now worked out per form from the fields it actually contains.
- NewebPay convenience-store pickup on the classic checkout never showed the store picker. The picker was drawn 200 ms after choosing the method, and WooCommerce's own refresh then replaced that part of the page and wiped it. It is now redrawn after every refresh, the same way the ECPay, PAYUNi and SmilePay pickers already were. Older entries are available in the plugin's repository.