Linux 软件免费装
Banner图

Merchlint – Store Audit for WooCommerce

开发者 baltano
更新时间 2026年9月7日 17:47
PHP版本: 7.4 及以上
WordPress版本: 7.1
版权: GPL-2.0-or-later
版权网址: 版权信息

标签

woocommerce store health duplicate sku autoloaded options catalog audit

下载

0.2.0 0.2.1

详情介绍:

Merchlint reads your WooCommerce catalogue and tells you where it is losing you money. Every finding comes with the value it was based on, so you can check it yourself instead of taking our word for it. It changes nothing. No product, no price, no stock level, no order. The audit reads and reports; every fix is yours to make, in your own admin. What it looks for Fifteen checks, in five groups: What makes it different Every check has a page that explains it Fifteen checks, fifteen pages — linked from the audit screen, next to the rule they belong to. Each page says what the problem costs, which fields the rule reads and which thresholds it compares them against, how to fix it, and when the finding is not a problem in your store. That last part is why the pages exist. A rule you cannot argue with is a rule you end up ignoring wholesale, so every page names the cases where the right answer is "hide this and move on": seasonal goods, spare parts, products sold only by phone. Your data stays yours The free version works entirely on your server. No account, no sign-up, no phoning home: the plugin makes no outbound connections at all, and an automated check enforces that on every build. The links to merchlint.com are ordinary links. They open in your browser when you click them, and the plugin sends nothing along the way — not your store's address, not its version, not an identifier of any kind. The only thing in the address is the language your admin is set to, so that a Polish store gets the Polish page. Without a click, nothing leaves your store at all.

安装:

  1. Install and activate the plugin. WooCommerce must be active first — WordPress enforces this for you.
  2. Open Store audit in the admin menu.
  3. Press Scan now. A store with 50 000 products takes about a minute and a half on the hardware we measure on; a slower host takes longer. You can stop the scan at any point.
The audit reads your catalogue and writes only to its own tables. Removing the plugin removes them. Short PHP time limit? Nothing to do — the audit reads your host's own limit and sizes each chunk to fit inside it, then books the next one itself. A shorter chunk means more of them, not less work: the audit still finishes, and it still resumes from where it stopped. If your host reports a limit it does not actually enforce, you can set the chunk yourself in wp-config.php: define( 'MERCHLINT_BUDGET_SECONDS', 8 );

屏幕截图:

  • One rule up close: what it checks, what to do about it, a link to the full write-up, and the
  • Every rule with its count, split into what came from your own data and what came from your
  • The dashboard widget: the result of the last audit on the first screen you see after logging in.
  • What changed since the previous audit, and whether the difference came from your store or from

常见问题:

Does it change anything in my store?

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.

Will it slow my store down?

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.

Can I audit a store with tens of thousands of products?

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.

Why does it check WP-Cron and Action Scheduler?

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.

What does "store health" cover here?

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.

Does it work with multilingual stores?

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.

Does it work with HPOS (High-Performance Order Storage)?

Yes, with HPOS on and off. Both modes give identical results, amounts included.

Some of the findings do not apply to my store.

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.

更新日志:

0.2.1 0.2.0 0.1.1 0.1.0