Moksa for WooCommerce
| 开发者 | moksa0923 |
|---|---|
| 更新时间 | 2026年9月11日 12:04 |
| 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.
更新日志:
- 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.
- TapPay credit card on the classic (shortcode) checkout could not complete an order. The handler that fetches the card token before submitting was attached to the page body, but WooCommerce fires that event directly on the form without bubbling, so it never ran and every order was submitted with an empty token. It is now attached to the form itself. Thanks to Leo at ECLORE for the report, which traced this to the exact line in WooCommerce and confirmed the fix on a live site.
- The TapPay card fields disappeared as soon as the checkout refreshed itself — switching shipping method, applying a coupon, or the refresh WooCommerce runs on load. The secure fields are now re-mounted whenever WooCommerce replaces that part of the page. Also reported by Leo.
- The TapPay card number, expiry and CVC boxes had no size of their own, so on many themes they were invisible and could not be clicked. They now ship with their own styling, and the expiry / CVC row no longer spills over the next payment method. Also reported by Leo.
- Stores using the Taiwanese city and district dropdowns could not complete a home-delivery order on the classic checkout: the district field was hidden, while the checkout still insisted it be filled in. The field was only meant to be hidden on the block checkout, where a separate district field takes its place.
- Shipping methods vanished from the classic checkout right after it loaded, showing "Enter your address to view shipping options" instead, and came back on a page refresh. When PAYUNi convenience-store pickup was the first shipping method and "hide billing address fields for store pickup" was on, the country was being blanked along with the rest of the address — but the country is what picks the shipping zone, so every method disappeared, including the pickup option that triggered it. The country now stays put; only the street-level fields are cleared.
- With "Hide the country field" on, the classic checkout's half-width fields fell out of step — a field would sit in the left column but be styled as the right one, showing up as an odd indent on the postcode. The hidden country field no longer counts toward pairing.
- Thirteen Taiwan-specific fields are now available as personalization tags in the block email editor, so you can write your own sentence around them instead of accepting a fixed paragraph and a table. Pickup store name, ID and address, tracking number, shipping provider, invoice number, bank code, ATM virtual account, convenience store payment code, the three barcode segments, and the payment deadline.
- The payment tags read from this plugin's shared payment layer rather than from any one provider, so a store that switches between ECPay, NewebPay, PayNow, PChomePay and SmilePay keeps the same tags working without touching its emails. Fixed
- SmilePay orders never showed the payment deadline to the customer, even though the date was recorded on the order. The other four payment providers all showed it. Older entries are available in the plugin's repository.