The plugin header said "WC tested up to: 11.1.2" and README.txt said 11.1.0 —
since 1.6.2, which is the release whose whole content was bumping that value,
and whose commit message says both were bumped. Only one was.
The check that exists for this printed green the entire time, and both of its
readings were correct:
WordPress: README.txt says 7.1.2, current release is 7.1.2
WooCommerce: plugin header says 11.1.2, current release is 11.1.2
It reads each value from the file that value belongs in, for a good reason
written in the comment above it: WordPress reads "Tested up to" only from
readme.txt, WooCommerce reads "WC tested up to" only from the plugin header.
So each check asks "is this value current" of the authoritative copy — and a
SECOND copy of the same value in the other file is compared with nothing. A
correct answer to a different question, which is the shape most false greens
here have.
Two checks, two questions, kept apart:
- "Is this value current" stays advisory, per the comment already there: a
build that goes red on release day for a header nobody has had a chance to
update is a build that gets ignored.
- "Do our own two copies say the same thing" is a fact about this tree with no
release-day excuse, so it is fatal.
Three pairs are actually duplicated here — WC tested up to, Requires at least,
Requires PHP — so the step has live rows rather than one. Proven red one field
at a time with a landing check each, and the count is on the green line,
because a readme carrying none of these fields has nothing to disagree and
would print the same silence as one where every pair matches.
50 selftest assertions. static=0 selftest=0 site=0; site still 69 on WordPress
7.1.2 with WooCommerce 11.1.2.
README.txt ships, so this is a version bump: 1.6.3. The changelog keeps 1.6.2's
entry — my first pass sed'd 1.6.2 to 1.6.3 across the file and rewrote that
heading, which would have made the changelog describe a release that never
happened.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Kristian asked the family to check WordPress 7.1.2. Run pinned rather than
against "latest", because latest drifts and then nobody knows which version a
green belonged to:
PHP 7.4 69 assertions, 0 failures "none from this plugin"
PHP 8.3 69 assertions, 0 failures "none from this plugin"
PHP 8.4 69 assertions, 0 failures "none from this plugin"
The container reported WordPress 7.1.2 and WooCommerce 11.1.2 on all three,
read out of the run rather than from the variable it was given. So there is no
problem with 7.1.2 here.
The findings were in the reporting, not the code.
The headers were stale: "Tested up to: 7.1" and "WC tested up to: 11.1.0"
against current 7.1.2 and 11.1.2. The WooCommerce one is the visible half — a
shop on 11.1.2 sees an untested warning on the WooCommerce status page, and on
this plugin that banner sits in front of somebody deciding whether to update a
discount engine.
And the suite said "All assertions passed" without a number, which is the exact
failure every other check here was fixed for. It now prints the count.
🔴 Then the floor for that count found a bigger hole than it was written for.
Putting it at the end of the smoke file does nothing: wp eval-file runs the
file in function scope, so a `return` partway through skips everything after
it, including the floor. Measured — truncating tests/smoke.php before the
shipping section ran two thirds of the assertions and ci/site-test.sh reported
GREEN.
A file cannot assert about its own early exit. ci/site-test.sh now captures the
output and checks the total against MIN_SITE_ASSERTIONS from outside, where an
early return cannot reach, and fails when the summary line is missing
altogether. The in-file floor stays for a short run that does reach the end.
Proven with the same fixture that exposed it: the truncated suite now exits 1
saying it printed no assertion total.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
The status pill on the shared dashboard is white 11px text over a light
overlay. SEO measured it two ways, arithmetic and a canvas read-back in
headless Chromium: this plugin's #1a7a52 gave 3.50:1 against a 4.5 minimum,
and six of eight family colours failed along with the no-colour fallback.
Not fixable by choosing a different card colour. The header is a direct pair
and passes at 5.32:1; the pill is a COMPOSITE, and 22% white is a floor — a
card has to reach about 7.7:1 before the pill clears 4.5, which is above the
whole family band. So it is the shared file or seven plugins giving up the
colour the cards exist to carry. 1.2.3 makes the overlay rgba(0,0,0,.18) and
this plugin's pill goes to 7.15:1.
Verified before copying: the hash, and php -w over both files to confirm the
executable code really changed — the diff is the version constant and that one
CSS value, nothing else.
The new assertion renders the dashboard and reads the pill out of what came
back, and it is built around the trap SEO warned about: their first harness
printed "no problem" over a code path it never entered, because it stubbed
wpmgr_cards instead of wpmgr_dashboard_cards and the renderer took its early
return. So the card's own title is asserted first — if the renderer bailed,
nothing after it means anything — and the OLD rgba is asserted ABSENT, because
a check that cannot tell the two versions apart cannot testify about either.
Both proven: against 471b0a2a it fails naming "the old 22% white", and with the
card filter removed it fails at 81 bytes rendered. That 81 is the same number
SEO reported from their own broken harness, which is independent confirmation
it is the same code path.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Kristian checked out with an address in no group and was offered both free
delivery methods set up for the Netic group. Measured on the shop before
touching anything: one group, four rules, two of them "show" on the free
delivery methods he saw.
It was not a regression. A test asserted the behaviour as intended — "an
unmatched customer sees every method" — so a "show" rule was a whitelist FOR
THE GROUP and nothing more. The plugin did half of what its own description
promises: it filtered what the group sees and never reserved anything from
anyone else. On a shop that takes money the effect is that free delivery
arranged for one company is available to every customer.
A method named in any group's show rules is now reserved for the groups that
name it.
Answering "does it work for other discounts too", which found the hole the
first fix left: it did not. A group with NO rules of its own returned every
rate untouched, and so did a group carrying only "hide" rules, because neither
engages the whitelist — so their members saw another group's reserved methods.
Both now have other groups' reserved methods removed.
The "never leave the customer without shipping" guard is kept and asserted: a
shop that reserved everything it offers must still let an ordinary customer
check out, because that failure is worse than the leak.
Four assertions, each proven red. Two of them caught my own mistakes rather
than the product's: the hide-only fixture originally left nothing for the
customer, so the guard fired and returned every rate — which reads exactly like
the leak it was written to detect. A third rate makes the behaviour observable.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Kristian read the readme and found it still telling people to configure the
plugin under WooCommerce, for a page that moved to the Nolimit menu three
releases ago. Sweeping for it found seven stale places, and three of them are
notices THE PLUGIN SHOWS THE USER — the missing-WooCommerce notice, the
activation error and the incomplete-install warning all still called it
WooCommerce Email Discount Manager.
That is the mimir.guide failure exactly: the code moved, the text stood still,
and nothing failed. It was found by somebody reading, which is the only way it
could be found, and that is the argument for the check rather than for being
more careful next time.
ci/static.sh now asserts two things. The name in readme.txt's title matches the
Plugin Name header, because the header is what WordPress shows and everything
else has to agree with it. And no shipped PHP file contains OLD_PLUGIN_NAME,
which is now a value in ci/plugin.conf rather than a habit.
The changelog is deliberately exempt: an entry describes what was true for that
release, and rewriting it would be a different lie. Only text describing the
CURRENT state is checked.
Both halves proven red — a readme title that disagrees, and the old name put
back into one notice.
Not changed: the page stays under Nolimit rather than gaining a second entry
under WooCommerce. One menu is the family's shape, and a duplicate entry is
clutter rather than a fix for a readme that was simply wrong.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
678f1f03 is withdrawn. It hard-coded the icon box at 36x34, and WordPress
declares that parent three times with different sizes — 36x34 open, 35x30
folded, 34x30 under 960px — so a fixed number is correct in one state and 4px
too tall in the two a laptop is usually in. cache-manager measured where the
ink lands rather than where the box is and found it worse than that: the glyph
moved from 2.5px above centre to 2.5px below in the folded states, the same
error mirrored, in a state that had been nearly right. 1.2.2 removes the number
entirely with width/height at 100%.
1.5.2 is already published with 678f1f03, so this tree shipped the withdrawn
version. Checked before anything else, because a later candidate fatalled on
every admin page with "Unknown format specifier": that file was never taken
here, and the published 1.5.2 emits its stylesheet cleanly — verified by
running sprintf over its format string rather than reading it. So the shop is
cosmetically off in folded menus, not broken.
New assertion, and it is the one this round is really about: the style
function is INVOKED and its output captured, rather than the source being
read. The fatal that prompted it survived three sessions reading the file,
a clean php -l, a clean PHPCS, and two browsers agreeing about the CSS —
because every one of those was fed the stylesheet by hand rather than through
the printf that produces it. A literal per-cent must be doubled in a format
string, and nothing that looks at the file can see that.
Proven red with that exact fault rather than an arbitrary one: undoubling the
per-cent gives "ValueError: Unknown format specifier ';'".
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Kristian reported the infinity sign sitting above centre in the admin menu on
the live shop. Security traced it to WordPress's own stylesheet rather than
adjusting it by eye: #adminmenu div.wp-menu-image is 36x34 and its :before
carries padding 7px 0, which is exactly 7 + 20 + 7 for a 20px dashicon at
line-height 1. The 1.2.0 rule set line-height 1.4 and inherited that padding,
so the pseudo-element was 42px tall inside a 34px parent.
1.2.1 reproduces the box, drops the padding and centres with flex — geometry
rather than a nudge, because U+221E sits on the maths axis instead of filling
its em box.
It is the same half-done abstraction as the escaping fix: the filter made the
character configurable and left the geometry tuned for one specific character.
Nothing could fail, because the only value anyone ever passed was the one it
was tuned for.
Verified before copying, including the part that makes the check meaningful:
Security predicted php -w WOULD differ this round, since the executable code
changed — so equal stripped hashes would have meant the wrong file. They
differ, and the diff is the version constant plus the CSS geometry, with
wpmgr_css_escape untouched.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Three things, all the same shape: a check that recognises a spelling has one
blind spot per spelling, and one that reads the thing itself has none of that
kind. Security hit it when an assertion matching the literal '∞' went red over
a file drawing exactly that character through a CSS escape.
Swept this repo's assertions for the same and found two.
"the plugin itself loads the shared menu file" searched THIS FILE'S SOURCE TEXT
for "'includes/shared-menu.php',". A comment mentioning that path would have
satisfied it — the same hollow shape as grepping a file for the words of the
guard it is supposed to have, which this kit already had once today. The admin
list is now a method, admin_includes(), and the test reads the array the plugin
actually loads from. Proven red by removing the entry: the failure prints the
list it did find.
The package-URL check asserted the absence of one particular IP address.
Gitea's ROOT_URL has been a raw address before and may be again, so naming
today's is blind to tomorrow's. It now asserts the host and the scheme.
Proven red with the realistic fault rather than a contrived one — the raw
address in the Update URI header:
FAIL so it is never the raw address … expected 'gitea.nolimit.dk', got '57.129.89.117'
FAIL and it is fetched over https … expected 'https', got 'http'
And ci/build-zip.sh left the archive behind when it failed. Every exit in the
checks section happens after the archive is written, so a failed build kept a
half-built artefact that looks exactly like a good one — and both the release
step and anyone publishing by hand take build/<slug>.zip by name. Found by
stubbing ci/dist-files.sh empty: exit 1, correct message, zip still on disk.
A trap removes it now, proven both ways.
Checked while here, from Security's report that the kit's shipped-file floor
was unguarded: this copy is guarded, and red for the right reason. Stubbing the
file list empty gives exit 1, one FAIL naming the empty list, and zero
occurrences of the "every one guarded" line — which is the assertion that
matters, since being red for an unrelated reason would look identical from the
exit code.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
The published 1.5.0 carries includes/shared-menu.php at f4862d5c — contract
1.0.0, the oldest of the six, in an artefact a shop downloads. It was built
before the family froze 1.1.0 and again 1.2.0, so the zip is older than the
repo in the one way that reaches a customer.
This release carries 9012fe98, so the menu shows the infinity glyph and the
glyph is emitted as CSS numeric escapes rather than through esc_attr().
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Kristian's menu screenshot showed four plugins under Nolimit and not this one,
after a build that moved the page there had already merged. Two separate
problems behind that.
The version never moved. The rename and the menu change went out still calling
themselves 1.4.6 — the same number as the copy already installed. So two
different builds carried one version, which is the one thing a version number
exists to prevent, and nothing offered the new one as an update. Now 1.5.0.
And the tests could not have caught it if the code HAD been wrong. The only
menu assertion was that this plugin claims the label through
wpmgr_menu_title — which passes while the plugin is absent from the menu
entirely. The label and the membership are different facts, and the screenshot
showed exactly that pair: the menu said Nolimit, this plugin was not in it.
Three assertions now. The parent exists after wpmgr_ensure_menu(), this
plugin's page is among the children of WPMGR_MENU_SLUG, and — separately — the
main file lists includes/shared-menu.php in its is_admin() branch.
That third one is there because the first two are a reduced repro and say so:
the admin menu is only built in an admin request, and these run under WP-CLI
where is_admin() is false and class-admin.php is never included, so the test
has to require the files by hand. A by-hand require would pass even if the
plugin never loaded them in a real request. That is the half a reduced repro
always omits, so it is asserted on its own rather than assumed.
Checked while here, from the security session's report: no human_time_diff
anywhere in this plugin, so the half-translated "4 timer ago" seam does not
exist here. Nothing to fix.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
The family shape is source private, releases in a separate public repo so a
shop can fetch an update without credentials and without the source being
readable. This plugin was the only one still serving its own update feed out of
the repository that holds ci/, docs/ and tests/.
kw/nolimit-discounts-dist created (public, zips only). RELEASE_REPO in
ci/plugin.conf now names it, and ci/publish-release.sh honours it over
GITHUB_REPOSITORY — falling back to the running repo, which is what a plugin
without a split still wants.
🔴 The "Update URI:" header moves in the SAME commit as the publishing target,
and ci/static.sh now fails when the two disagree. The header is what every
installed copy polls; if it names a repository nothing is published to any
more, the shop stops being offered updates and nothing announces it, because
latest_release() simply returns false. That is the same failure as a privacy
page standing still while the code moves, and the check is what makes it
impossible to forget.
Proven red before being believed: pointing RELEASE_REPO at another repository
fails with both sides named. RELEASE_REPO is required by ci_load_conf, because
an unset value would turn the comparison into a no-op and restore exactly the
bug it prevents.
Not done here, and it is the blocker for actually cutting a release: publishing
to another repository needs a token with write access to it. The job token only
covers the repo it runs in, so this needs a cross-repo PAT in the repository
secrets, and that is Kristian's to add.
Also not done, deliberately: the source repo stays public for now. Making it
private before the dist repo has releases would break the feed for the copy
installed on the live shop, whose header still points at the old address.
1.4.6 and earlier keep working through Gitea's rename redirect - measured, the
old name still answers 200 - and that redirect is the only thing holding them
up, so it must not be removed until a build carrying the new header has
propagated.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Kristian could not find this plugin in the Nolimit menu, and it still called
itself WooCommerce Email Discount Manager. Both are the display side of the
family rename; neither touches the installed folder.
Plugin Name is now "Nolimit Discounts". The folder, the text domain, the option
prefix and the three tables are deliberately unchanged: WordPress identifies a
plugin as <folder>/<file>, so renaming the folder would not move the
installation on the live shop — it would put a second copy beside it and leave
the old one active. That is a migration with a shim, and it is Kristian's call
rather than a side effect of a label change.
includes/shared-menu.php added, byte-identical to the family copy
(f4862d5c…c63185), and the page moved from the WooCommerce submenu to the
shared parent. The page slug is unchanged, so admin.php?page=… still resolves
and an existing bookmark keeps working — moving a page between parents does not
move its URL.
The label is claimed through the wpmgr_menu_title filter from this plugin's own
bootstrap, NOT by editing the shared file. Which copy of that file a site loads
is decided by activation order, and PHP cannot un-declare a function, so the
first copy wins for the whole request: editing it would make a site with three
of five plugins updated show "Manager" or "Nolimit" depending on who booted
first, and change its mind when a plugin is deactivated. The filter is
idempotent and a plugin still on an older build changes nothing.
The filter is registered before the WooCommerce gate, for the same reason the
updater is: the shared menu's label must not depend on whether this particular
plugin got past a check.
Two assertions, both proven red first. The label is asserted through the filter
rather than by reading the menu, because the menu is only built in an admin
request and the smoke tests run under WP-CLI. And the shared file's sha256 is
asserted, so editing it goes red here rather than going strange on a shop —
appending one comment line produced:
FAIL and the shared menu file is the family copy, unedited
— expected 'f4862d5c…', got '45df6b55…'
Also caught in passing by the kit, working exactly as intended: the new
shared-menu.php was untracked, and "every file the plugin loads is a file the
release contains" failed rather than shipping a zip without it.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Kristian named the five plugins as a family, and three repos disagreed with what
he calls them. His decision: rename the repo, never the installed slug.
MEASURED BEFORE DOING IT, because four published releases carry the old URL in
their Update URI header. A throwaway repo was created, renamed and deleted:
old API path 301 -> new
old web path 301 -> new
old /releases/download/... path 301 -> new
and WordPress follows up to 5 redirects by default (class-wp-http.php:191), on
GET. Confirmed afterwards against the real thing: the old feed URL resolves to
v1.4.5 and the old download path still serves 48185 bytes.
So a shop on 1.4.2 keeps updating through the redirect, and 1.4.6 moves it onto
the new address directly.
PLUGIN_SLUG and PLUGIN_MAIN are deliberately untouched and now disagree with the
repository name. That is permanent: the installed directory has been
woocommerce-email-discount-manager since the first release and is on a live
shop, and changing it would not move that installation — it would put a SECOND
copy beside it and leave the old one active. ci/plugin.conf says so in the file,
because otherwise somebody will helpfully align them.
Also in, both for the family rather than for this plugin alone:
- docs/REUSE.md gains the hostname-keyed hook as a first-class section. It is
the only bug we have found that is CAUSED by there being more than one plugin,
so it is invisible to anyone reading a single repo — along with the same shape
in a shared-*.php file copied into five plugins, which fatals with "Cannot
redeclare" on the second activation without function_exists() guards.
- ci/static.sh fails on anything shaped like a credential in a tracked file.
Suggested by the AI-manager port: a pushed key cannot be unpushed, only
rotated. Deliberately narrow — sk-ant-, sk-, ghp_, gho_, github_pat_, AKIA,
PRIVATE KEY blocks — because a broad entropy heuristic fires on minified
assets and a check that cries wolf gets commented out.
Verified failing before being believed: a file containing sk-ant-api03-... makes
the step report the filename and the suite exit 1.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Gets the cross-plugin fix onto a shop. Until this is installed, a plugin
updating from the same host can be offered this one's release as its own, and
the direction that breaks in is decided by load order.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
The fifteen-minute cache is the only change here a shop can feel, and it is the
one Kristian hit: a release published and nothing shown.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
The header went out as "Author: WEDSMP" with a Plugin URI of example.com. That
is what wp-admin shows to whoever installs it, which is why it is worth a
release of its own rather than waiting for the next change.
Author is now Kristian Wind, with an Author URI pointing at where the source
lives, and the readme credits kristianwind rather than wedsmp.
ci/static.sh now fails on a placeholder in the header. It catches the generic
markers — example.com, TODO, yourname, an unfilled <...> — and it would have
caught the Plugin URI. It would NOT have caught "WEDSMP": a made-up vendor name
is indistinguishable from a real one to any check, so an empty field is warned
about and a wrong-but-plausible one cannot be.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
The v1.4.0 zip that is already published contains the updater that trusts the
repository's own browser_download_url — the one that reports a plain-HTTP raw
IP. Anyone who installs 1.4.0 keeps that until an update arrives over exactly
the address it gets wrong. It works today, because that address happens to be
reachable, which is the reason to close it now rather than leave it working by
luck.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Three things this repository could not do: prove the plugin still works on a
WordPress or WooCommerce released after it, get a fix onto a shop without
someone uploading a zip, and do either of those for the next plugin without
starting over.
ci/ is the test harness. ci/site-test.sh builds a throwaway WordPress +
WooCommerce in containers at any versions you name — including `nightly` and
`beta` — installs exactly the files the release zip will contain, and runs
tests/smoke.php inside it with wp eval-file. Real cart, real coupons, real
WC_Shipping_Rate objects: a mocked cart keeps passing after WooCommerce has
changed underneath it, which is the one failure worth catching here. WP_DEBUG
is on and any notice logged from this plugin's directory fails the build,
because that is the shape an upgrade actually breaks in — nothing fails, a
notice appears, and two releases later it is a fatal.
compat.yml runs that weekly against today's releases, the next WordPress and
the next WooCommerce, the oldest PHP the header promises and the newest PHP.
When it is green it opens a PR bumping "Tested up to" and "WC tested up to" —
only when green, because WooCommerce shows that second value to the shop owner
as an untested-plugin banner, and that banner is what they read before deciding
whether to press update.
includes/class-updater.php is the distribution half. It hooks
update_plugins_{hostname} for the host in the new "Update URI" header and reads
the Gitea release API, so WordPress handles the notice, the download, the
"Enable auto-updates" link and wp plugin update with no further code. Update
URI earns its place twice: since 5.8 a plugin that declares one is never asked
about on wordpress.org, so a .org plugin sharing this slug cannot be pushed
onto a shop running this one. The check sends nothing about the site and
overrides WordPress's default user agent, which carries the site's own URL.
release.yml tags, tests, builds, publishes — then reads the feed back with no
credentials. A private repository and a release with no zip attached both leave
a page that looks perfect to anyone logged in and an update no shop is ever
offered.
Measured before committing, all green: WP 7.1 + WC 11.1 on PHP 8.3 and 7.4,
WP 7.2-alpha on 8.3, and the beta cell falling back to stable on 8.4. No
deprecations from this plugin on any of them.
Three guards are there because the bug they catch is invisible without them:
the annotated tag is re-fetched before its message is read (checkout turns it
into a lightweight tag pointing at the merge commit), the two workflow roots
are kept in sync (.gitea/workflows hides .github/workflows entirely), and every
file the code loads must be in the release zip — which caught class-updater.php
being referenced and uncommitted while every local test passed.
docs/REUSE.md is the port to the next plugin: copy ci/, rewrite five lines.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
