| 开发者 | baltano |
|---|---|
| 更新时间 | 2026年9月7日 17:47 |
| 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 fifteen 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 is one click. The decision survives future scans, and the hidden items stay visible as a count, so nothing disappears silently.