Merchlint – Store Audit for WooCommerce

Changelog

0.3.2

• On WooCommerce older than 9.2 the two identifier checks now say they did not run, instead of
  reporting numbers. That WooCommerce has no field for a product identifier at all. If the
  field had been written straight into the database – after moving back from a newer version, or
  by an import – the plugin used to treat the store as one that keeps identifiers while reading
  every one of them as empty: the duplicate check then reported nothing even when duplicates
  were there. Both checks now stay quiet and say why, naming the WooCommerce version that first had the field.

• The evidence column no longer shows a Polish word on an English screen. Where a check reads
  a field and finds it empty, the value now reads “(empty)”. It had been coming straight from the audit
  engine, which has no access to translations, so the Polish “(puste)” appeared for anyone reading the
  screen in English – in the one column whose whole job is to let you verify us.

• The duplicate-identifier check now says when it had nothing to compare. On a catalogue where
  not one product carries an identifier, it used to report “nothing found – this check is clean” – a clean
  bill of health for a field nobody fills, and two different sentences about the same field one under the
  other, because the missing-identifier check said so correctly. Both checks now give the same answer,
  with the same reason.

• A finding on a variation now links straight to the tab where you fix it. The link in
  the list opened the parent product at the top of the page; on a product with twenty
  variations that is a long way from the one you were sent to. The export file had carried
  the right link all along – only the screen did not.

0.3.1

• Both duplicate checks now see codes stored on variations, not only on products. Until now the
  comparison ran over products alone, so a code repeated between one product and another product’s
  variation was invisible — even though an export file treats every variation as a separate item.
  On a store with variable products the numbers can go up after this update.
• The identifier check also reports a product that shares its number with its own variation. The
  SKU check does not — and that difference is deliberate. WooCommerce shows the parent’s SKU on a
  variation that has none, so for SKU that pair is how the platform behaves, not a fault. For the
  identifier there is no such inheritance: WooCommerce requires it to be unique across products and
  variations, yet never notices when an import writes the pair straight to the database, so this is
  the only place it surfaces. It matters when an export file carries the parent alongside its
  variations — then two items go out with one number.
• One pair is still left out and the knowledge pages now say so: two variations of one product
  sharing a code while the product itself carries none. A finding belongs to a product, and there
  is nothing to attach it to there.
• The three checks whose behaviour changed carry a new version number, and that is deliberate.
  The “Changes since the previous audit” screen reads those numbers to tell you when a movement
  comes from us rather than from your store, and anything you hid under the old version is marked
  for a second look — your decision was an answer to a question that is now worded differently.
  Nothing is un-hidden behind your back; it is only flagged.
• Variations sitting in the trash no longer count — anywhere. A variable product whose living
  variations all carried an identifier could still be reported as missing one, because a trashed
  variation had none; the same ghost could make a code look duplicated. Nothing in the shop shows
  those variations, and WooCommerce’s own uniqueness check ignores the trash as well — now so do we.
  This one was in the previous release too, not only in the change above.
• Two additions to the identifier check’s knowledge page. What to do when the check is clean
  and the export file still shows no identifier — an export plugin may read the field through a
  cached list of fields, which a product save does not refresh. And why a number copied onto
  variations while a file is being built hides the gap rather than closing it: a shopping service
  expects each variation to carry its own, and this check reports what WooCommerce holds.

0.3.0

• Two new checks, both free and with no product cap: a product with no GTIN, UPC, EAN or ISBN,
  and two products sharing the same one. Shopping services use that identifier to match your
  offer to the same product sold elsewhere, so an empty or duplicated one is the usual reason an
  item quietly drops out of a feed. WooCommerce has had the field since 9.2, on the Inventory tab,
  and nothing in the admin ever points at it. The check reads WooCommerce’s own field; identifiers
  kept in a plugin’s field or in a product attribute are not read.
• The missing-identifier check stays quiet in shops that do not use identifiers at all. If not
  one product has the field filled, you get a single sentence saying so instead of a list of your
  entire catalogue — handmade goods, services and your own production carry no manufacturer’s
  barcode and need none.
• On a variable product the identifier belongs on each variation, so such a product gives one
  finding with the evidence “6 variations without a GTIN” — not six separate rows.
• Translations of one product are not reported as a duplicate, exactly as with SKU.
• After an update, “Changes since the previous audit” now names the checks that are new.
  Two checks arriving at once means findings arriving at once, and the screen showed the
  movement without saying where it came from — so it read as if something had broken in your
  store overnight. A check that is new and found nothing stays out of the way.
• A check that could not run no longer reads as a clean one — on every screen, not just some.
  The audit screen has always had a section saying what could not be checked and why. Two places
  did not: the dashboard tile counted such a check among the rules it had gone through, and
  “Changes since the previous audit” showed its findings dropping to zero exactly as it shows a
  real fix. On a store that keeps no product identifiers at all, that meant being congratulated
  for something nobody had measured. The tile now says how many checks could not run, and the
  comparison says plainly that a drop there is not a fix.
• An empty catalogue is no longer reported as a clean one. A store with no products got a row
  of zeros and a tile saying nothing needed fixing — which is what a fresh WooCommerce install
  looks like before the first product is added. The audit now says plainly that there was nothing
  to check.
• Ready since 0.2.2 and shipping here: the audit engine no longer assumes every store can answer
  every question. A rule now says what it needs, and a store that cannot provide it gets a plain
  note saying the rule was not applicable — instead of a silent zero that reads like a clean
  result. On WooCommerce every rule still applies, so every check you already had gives exactly
  the same result as it did under 0.2.1.
• The list of rules moved into the audit engine itself.

0.2.1

• New display name: Merchlint – Store Audit for WooCommerce. Same plugin, same address, same
  settings — the name now says what it does, for people who find plugins by searching for the job
  rather than for a brand.
• Every rule now links to its own page, which explains what the finding costs, exactly how the
  rule decides, how to fix it, and when it is not a problem worth fixing. The link opens in your
  browser and carries nothing but the language of your admin; the plugin itself still makes no
  outbound connections at all.
• The plugin’s name on your plugins list is now a link to its home page. Until now it led nowhere.
• No change to what the audit checks or reports. A scan of an unchanged store gives exactly the
  same result as it did under 0.2.0.

0.2.0

• First public release. Versions 0.1.0 and 0.1.1 below were pre-release: they were reviewed but
  never published, so this is the first version you can install from the directory. Everything the
  audit does is listed under 0.1.0.
• Two extension points so add-ons can build on the audit: an action when a scan finishes and
  a filter over the scan settings, plus the scan history behind both.
• Rules the current scan did not run are now marked “not in this audit” instead of “clean”.
• A scan now keeps its settings even if an add-on hands it a value that cannot be stored — before,
  one such value silently dropped every threshold the scan was running with, and the second half of
  the scan used the defaults.
• Comparing two audits no longer writes a PHP notice to the log when a setting holds a list rather
  than a number.
• No change to what the audit checks on its own.

0.1.1

• Translations now come from translate.wordpress.org instead of files bundled in the plugin.
• No change to what the audit checks or reports.

0.1.0

• First release. Fifteen checks, resumable scanning, CSV export, per-rule knowledge pages,
  permanent “hide”, English and Polish.