| 开发者 | baltano |
|---|---|
| 更新时间 | 2026年10月21日 16:40 |
| PHP版本: | 7.4 及以上 |
| WordPress版本: | 7.1 |
| 版权: | GPL-2.0-or-later |
| 版权网址: | 版权信息 |
wp-config.php:
define( 'MERCHLINT_BUDGET_SECONDS', 8 );No. It reads your catalogue and reports what it finds. Every change is made by you, in your own admin. This is enforced in the code, not just promised: an automated check refuses to build the plugin if it calls any function that would modify products, categories, media or orders.
The scan runs in the background, in short slices, and it only touches the admin side. Your storefront is not involved. If the scan is interrupted — a server restart, a deployment — it picks up where it left off and gives the same result as an uninterrupted run.
Yes. A scan of 50 000 products completes in about 90 seconds and the results are paginated, so a rule with twelve thousand findings still opens instantly.
Because a stalled queue fails quietly. WP-Cron and Action Scheduler are what WooCommerce and its extensions book later work on — order emails, the end of a scheduled sale, stock released from abandoned carts, subscription renewals — and neither your storefront nor your order list will tell you they stopped. The store keeps selling. It just stops doing everything that was meant to happen later. The two queues are reported as separate findings, because they stop for different reasons and are fixed in different places. What the rule measures is the age of the oldest overdue action, not how many are waiting: a store with no visitors always has a queue full of them and is perfectly healthy, because the first visitor clears it. Anything overdue by more than a day is not quiet, it is broken — and that threshold is yours to move.
Everything the twenty checks touch, not only product fields: the catalogue and its categories, the media library and the files behind it, the size of your autoloaded options, and the versions of PHP, WordPress and WooCommerce you are running. A store can have faultless product data and still be losing money to a stalled queue or to an unsupported PHP version, so the report covers both.
Yes. Translations of one product are counted as one product: their SKU is shared deliberately, and their stock is one physical stock, so we never report the same goods twice or double the amount at stake. Polylang is tested with the plugin itself; WPML is recognised through its translation table, which we test against the same data it produces.
Yes, with HPOS on and off. Both modes give identical results, amounts included.
Then hide them. Every rule's page explains when the finding is NOT a problem — seasonal goods, spare parts, products sold only by phone — and hiding takes two clicks, with an optional reason. The decision survives future scans, and the hidden items stay visible as a count and in a list you can restore them from, so nothing disappears silently.
Only if you connect one yourself. On WordPress 6.9 or later Merchlint registers two read-only
abilities through the WordPress Abilities API: the audit summary and the list of findings. An AI
assistant you connect to your store, for example through an MCP plugin, can call them as a
logged-in user with the manage_woocommerce permission, and gets the same results as the Store
audit screen. Merchlint itself sends nothing anywhere and changes nothing in your store.
hwp_product_gtin or hwp_var_gtin. A GTIN
plugin that is no longer in the WordPress.org directory stored numbers in these two fields, one
for products and one for variations, and a store that used it keeps them there after removing
it. When products hold their number only in one of those fields, the audit says how many and
names the field, as it already does for other plugins' fields. Nothing is counted differently.