Merchlint reads your WooCommerce catalogue and tells you where it is losing you money. Every\nfinding comes with the value it was based on, so you can check it yourself instead of taking our\nword for it.<\/p>\n\n
It changes nothing. No product, no price, no stock level, no order. The audit reads and reports;\nevery fix is yours to make, in your own admin.<\/p>\n\n
Fifteen checks, in five groups:<\/p>\n\n
Fifteen checks, fifteen pages \u2014 linked from the audit screen, next to the rule they belong to.\nEach page says what the problem costs, which fields the rule reads and which thresholds it\ncompares them against, how to fix it, and when the finding is not<\/strong> a problem in your store.<\/p>\n\n That last part is why the pages exist. A rule you cannot argue with is a rule you end up ignoring\nwholesale, so every page names the cases where the right answer is \"hide this and move on\":\nseasonal goods, spare parts, products sold only by phone.<\/p>\n\n The free version works entirely on your server. No account, no sign-up, no phoning home: the\nplugin makes no outbound connections at all, and an automated check enforces that on every build.<\/p>\n\n The links to merchlint.com are ordinary links. They open in your browser when you click them, and\nthe plugin sends nothing along the way \u2014 not your store's address, not its version, not an\nidentifier of any kind. The only thing in the address is the language your admin is set to, so\nthat a Polish store gets the Polish page. Without a click, nothing leaves your store at all.<\/p>\n\n\n The audit reads your catalogue and writes only to its own tables. Removing the plugin removes them.<\/p>\n\n Short PHP time limit?<\/strong> Nothing to do \u2014 the audit reads your host's own limit and sizes each chunk\nto fit inside it, then books the next one itself. A shorter chunk means more of them, not less work:\nthe audit still finishes, and it still resumes from where it stopped.<\/p>\n\n If your host reports a limit it does not actually enforce, you can set the chunk yourself in\n wp-config.php:<\/p>\n\n No. It reads your catalogue and reports what it finds. Every change is made by you, in your own\nadmin. This is enforced in the code, not just promised: an automated check refuses to build the\nplugin if it calls any function that would modify products, categories, media or orders.<\/p><\/dd>\n The scan runs in the background, in short slices, and it only touches the admin side. Your\nstorefront is not involved. If the scan is interrupted \u2014 a server restart, a deployment \u2014 it picks\nup where it left off and gives the same result as an uninterrupted run.<\/p><\/dd>\n Yes. A scan of 50 000 products completes in about 90 seconds and the results are paginated, so\na rule with twelve thousand findings still opens instantly.<\/p><\/dd>\n Because a stalled queue fails quietly. WP-Cron and Action Scheduler are what WooCommerce and its\nextensions book later work on \u2014 order emails, the end of a scheduled sale, stock released from\nabandoned carts, subscription renewals \u2014 and neither your storefront nor your order list will tell\nyou they stopped. The store keeps selling. It just stops doing everything that was meant to happen\nlater.<\/p>\n\n The two queues are reported as separate findings, because they stop for different reasons and are\nfixed in different places. What the rule measures is the age of the oldest overdue action, not how\nmany are waiting: a store with no visitors always has a queue full of them and is perfectly\nhealthy, because the first visitor clears it. Anything overdue by more than a day is not quiet, it\nis broken \u2014 and that threshold is yours to move.<\/p><\/dd>\n Everything the fifteen checks touch, not only product fields: the catalogue and its categories, the\nmedia library and the files behind it, the size of your autoloaded options, and the versions of PHP,\nWordPress and WooCommerce you are running. A store can have faultless product data and still be\nlosing money to a stalled queue or to an unsupported PHP version, so the report covers both.<\/p><\/dd>\n Yes. Translations of one product are counted as one product: their SKU is shared deliberately, and\ntheir stock is one physical stock, so we never report the same goods twice or double the amount at\nstake. Polylang is tested with the plugin itself; WPML is recognised through its translation table,\nwhich we test against the same data it produces.<\/p><\/dd>\n Yes, with HPOS on and off. Both modes give identical results, amounts included.<\/p><\/dd>\n Then hide them. Every rule's page explains when the finding is NOT a problem \u2014 seasonal goods,\nspare parts, products sold only by phone \u2014 and hiding is one click. The decision survives future\nscans, and the hidden items stay visible as a count, so nothing disappears silently.<\/p><\/dd>\n\n<\/dl>\n\n\n\n
Your data stays yours<\/h4>\n\n
\n
define( 'MERCHLINT_BUDGET_SECONDS', 8 );\n<\/code><\/pre>\n\n\n\n
Does it change anything in my store?<\/h3><\/dt>\n
Will it slow my store down?<\/h3><\/dt>\n
Can I audit a store with tens of thousands of products?<\/h3><\/dt>\n
Why does it check WP-Cron and Action Scheduler?<\/h3><\/dt>\n
What does \"store health\" cover here?<\/h3><\/dt>\n
Does it work with multilingual stores?<\/h3><\/dt>\n
Does it work with HPOS (High-Performance Order Storage)?<\/h3><\/dt>\n
Some of the findings do not apply to my store.<\/h3><\/dt>\n
0.2.1<\/h4>\n\n
\n
0.2.0<\/h4>\n\n
\n
0.1.1<\/h4>\n\n
\n
0.1.0<\/h4>\n\n
\n