Merge pull request #15 from kristianwind/repo-rename

Rename the repository to woo-discount-manager, keep the installed slug

README.txt

@@ -1,10 +1,10 @@
 === WooCommerce Email Discount Manager ===
-Contributors: wedsmp
+Contributors: kristianwind
 Tags: woocommerce, discount, email, shipping, coupon
 Requires at least: 5.8
 Tested up to: 7.1
 Requires PHP: 7.4
-Stable tag: 1.4.0
+Stable tag: 1.4.6
 WC requires at least: 6.0
 WC tested up to: 11.1.0
 License: GPLv2 or later
@@ -96,6 +96,26 @@ The most specific match wins: exact email, then domain, then partial match.
 
 == Changelog ==
 
+= 1.4.6 =
+* Housekeeping: the plugin's source moved to a shorter address. Updates continue to arrive as before, and nothing needs doing.
+
+= 1.4.5 =
+* Fixed: the plugin could offer its own release as an update to a different plugin. Plugins that update from the same place share one check inside WordPress, and this one answered for all of them instead of only for itself. If another such plugin is installed, update it as well.
+* "Vis detaljer" next to the update notice now opens the plugin's own details, with the release notes as the changelog. It previously showed "Plugin not found", because WordPress was asking wordpress.org about a plugin that is not published there.
+
+= 1.4.4 =
+* A new version now shows up within about fifteen minutes instead of being hidden behind a six-hour cache. The plugin was holding on to its own answer for longer than WordPress waits before asking again, so a release could be published and the shop shown nothing.
+
+= 1.4.3 =
+* The plugin is now credited to Kristian Wind, with a link to where its source lives. It previously carried a placeholder name.
+
+= 1.4.2 =
+* The plugin now has an icon, so it no longer shows up as a generic grey plug under Dashboard → Updates.
+* "Check again" on the updates screen really does check again. It previously reused a cached answer for up to six hours, which made a brand new version look like it had not been published.
+
+= 1.4.1 =
+* The update check now builds the download address itself instead of using the one the repository reports. The repository was reporting a plain-HTTP address on a raw IP, which would have meant downloading plugin code over an unencrypted connection to an address that is free to change. Anyone on 1.4.0 gets this automatically with the next update.
+
 = 1.4.0 =
 * The plugin now updates itself. WordPress checks the plugin's own release feed and offers new versions in Plugins and Dashboard → Updates, so an update no longer means uploading a zip by hand. The per-plugin "Enable auto-updates" link works too.
 * Tested against WordPress 7.1 and WooCommerce 11.1, and against the next release of each, so an update to either is checked before it reaches a shop rather than after.

assets/icon.svg

@@ -0,0 +1,18 @@
+<svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 128 128" width="128" height="128" role="img" aria-label="WooCommerce Email Discount Manager">
+  <!-- Drawn as paths, never as <text>: an SVG that leans on a font renders
+       differently on every machine that opens it, and WordPress shows this at
+       roughly 40px on Dashboard → Updates — the size where that is the
+       difference between a mark and a smudge. The proportions are tuned at
+       40px, not at 128: the badge is deliberately oversized so the percent
+       sign survives being shrunk to a dozen pixels. -->
+  <rect width="128" height="128" rx="28" fill="#7f54b3"/>
+  <rect x="13" y="30" width="74" height="52" rx="7" fill="#ffffff"/>
+  <path d="M13 36 L50 62 L87 36" fill="none" stroke="#7f54b3" stroke-width="7"
+        stroke-linecap="round" stroke-linejoin="round"/>
+  <circle cx="90" cy="90" r="32" fill="#ffffff"/>
+  <g stroke="#7f54b3" stroke-width="6" fill="none" stroke-linecap="round">
+    <circle cx="80" cy="80" r="6"/>
+    <circle cx="100" cy="100" r="6"/>
+    <path d="M76 104 L104 76"/>
+  </g>
+</svg>

ci/dist-files.sh

@@ -18,7 +18,14 @@ while IFS= read -r line; do
   [ -n "$line" ] && patterns+=("${line%/}")
 done < .distignore
 
-git ls-files | while IFS= read -r file; do
+# -z, not plain `git ls-files`: git QUOTES any path containing a non-ASCII
+# byte, so "TESTMILJØ.md" comes out as the literal 14-character string
+# "TESTMILJ\303\230.md". That form matches no pattern in .distignore, so the
+# file is kept — an internal document walking straight into the release zip
+# with nothing said. (-z also covers paths with spaces.) Found in a sibling
+# plugin that has exactly such a filename; this repo has none today, which is
+# precisely why it would have sat here until someone added one.
+git ls-files -z | while IFS= read -r -d '' file; do
   keep=1
   for p in "${patterns[@]}"; do
     # A bare name excludes the file or directory wherever it appears, which is

ci/lib.sh

@@ -46,33 +46,51 @@ ci_plugin_header() {
     "$(ci_repo_root)/$PLUGIN_MAIN" | head -1 | sed -E 's/[[:space:]]+$//'
 }
 
+# Run a shell script against a checkout of this repository, inside a container.
+#
+# The repository goes in over a tarball and `docker cp`, never a bind mount: a
+# Gitea Actions job runs inside a container talking to the HOST's docker
+# daemon, so a host path here lands on an empty directory nobody created and
+# the check passes by checking nothing. The symptom reads like a typo in a path.
+#
+# Two details are load-bearing. The script is copied in as a FILE rather than
+# interpolated into `sh -c`, so it can contain $, quotes and newlines without
+# being mangled — which matters the moment it is more than one command. And
+# --entrypoint sh is not decoration: some images (composer:2, for one) have an
+# entrypoint that swallows its arguments.
+#
+# Taken from the subscriptions port, which needed it for composer.
+ci_in_container() { # image script-text
+  local image="$1" script="$2"
+  local dir cid code=0
+
+  dir=$(mktemp -d -t wpci-XXXXXX)
+  ( cd "$(ci_repo_root)" && git ls-files -z | tar --null -T - -cf "$dir/src.tar" )
+  printf '%s\n' "$script" > "$dir/run.sh"
+
+  cid=$(docker create --entrypoint sh -w /src "$image" \
+    -c 'mkdir -p /src && tar -xf /tmp/src.tar -C /src && exec sh /tmp/run.sh')
+  docker cp "$dir/src.tar" "$cid:/tmp/src.tar" >/dev/null
+  docker cp "$dir/run.sh"  "$cid:/tmp/run.sh"  >/dev/null
+  docker start -a "$cid" || code=$?
+  docker rm -f "$cid" >/dev/null
+  rm -rf "$dir"
+  return "$code"
+}
+
 # Run one of this repository's PHP scripts.
 #
 # Uses the local php when there is one — a laptop, GitHub's hosted runners —
 # and a container otherwise. The Gitea runner image has no php, and losing a
 # build to "php: command not found" after everything else passed is a silly way
 # to spend an afternoon. Measured: it happened on the very first Gitea run.
-#
-# The repository goes in over a tarball and `docker cp`, never a bind mount: a
-# Gitea Actions job runs inside a container talking to the HOST's docker
-# daemon, so a host path here lands on an empty directory nobody created.
 ci_php() {
   if command -v php >/dev/null 2>&1; then
     php "$@"
     return
   fi
 
-  local tarball cid code=0
-  tarball=$(mktemp -t wpci-php-XXXXXX.tar)
-  ( cd "$(ci_repo_root)" && git ls-files -z | tar --null -T - -cf "$tarball" )
-
-  cid=$(docker create "php:8.4-cli" sh -c \
-    "mkdir -p /src && tar -xf /tmp/src.tar -C /src && cd /src && exec php $(printf '%q ' "$@")")
-  docker cp "$tarball" "$cid:/tmp/src.tar" >/dev/null
-  docker start -a "$cid" || code=$?
-  docker rm -f "$cid" >/dev/null
-  rm -f "$tarball"
-  return "$code"
+  ci_in_container "php:8.4-cli" "exec php $(printf '%q ' "$@")"
 }
 
 ci_step() { printf '\n\033[1m→ %s\033[0m\n' "$*"; }

ci/plugin.conf

@@ -7,6 +7,13 @@
 # Directory name the plugin gets inside wp-content/plugins, and the name of the
 # built zip. WordPress identifies a plugin by "<slug>/<main file>", so changing
 # this after release orphans every installed copy.
+#
+# 🔴 THIS DELIBERATELY DOES NOT MATCH THE REPOSITORY NAME, and it must not be
+# "tidied up" to. The repo is woo-discount-manager; the installed directory has
+# been woocommerce-email-discount-manager since the first release and is on a
+# live shop. Renaming it would not move that installation — it would put a
+# SECOND copy beside it and leave the old one active. The repo name is free to
+# change (Gitea keeps a 301, measured), the installed slug never is.
 PLUGIN_SLUG=woocommerce-email-discount-manager
 
 # The file carrying the plugin header. Version: in here is the version.

ci/publish-release.sh

@@ -65,6 +65,35 @@ tested_wc=$(ci_plugin_header 'WC tested up to')
 body=$(printf '%s\n\n---\n\nTested up to: %s\nWC tested up to: %s\n' \
   "$notes" "${tested_wp:-unknown}" "${tested_wc:-unknown}")
 
+# Read one top-level field out of a JSON response.
+#
+# Not sed. A greedy `.*"id":([0-9]+)` matches the LAST id in the payload, and a
+# Gitea release carries both an embedded "author" object and, once anything is
+# attached, an "assets" array — each with an id of its own. Measured on this
+# repo: the four published releases have ids 416/417/419/421, and the greedy
+# pattern returns 1/2/3/4, which are the asset ids.
+#
+# Those four releases were nonetheless published correctly, and only by luck:
+# the author id on this instance is **-1**, and the minus sign stops `[0-9]+`
+# from matching, so on a create response — which has no assets yet — the last
+# numeric id happened to be the release's. A real author id, or a re-run
+# against a release that already has its zip, and it picks the wrong number.
+#
+# Found by the session porting this into subscriptions, where it picked the
+# author id and the upload 404'd. python3 is already a required tool here.
+json_field() { # field  (JSON on stdin)
+  python3 -c '
+import json, sys
+try:
+    data = json.load( sys.stdin )
+except Exception:
+    sys.exit( 0 )
+value = data.get( sys.argv[1] )
+if value is not None:
+    print( value )
+' "$1"
+}
+
 api() { # method path [data]
   curl -fsS -X "$1" \
     -H "Authorization: token $GH_TOKEN" \
@@ -94,27 +123,66 @@ print(json.dumps({
   # A re-run of a release must not fail on "already exists".
   existing=$(curl -fsS -H "Authorization: token $GH_TOKEN" \
     "$GITHUB_API_URL/repos/$owner/$repo/releases/tags/$TAG" 2>/dev/null || true)
-  id=$(printf '%s' "$existing" | sed -n -E 's/.*"id":[[:space:]]*([0-9]+).*/\1/p' | head -1)
+  id=$(printf '%s' "$existing" | json_field id)
 
   if [ -z "$id" ]; then
     created=$(api POST "$GITHUB_API_URL/repos/$owner/$repo/releases" "$payload")
-    id=$(printf '%s' "$created" | sed -n -E 's/.*"id":[[:space:]]*([0-9]+).*/\1/p' | head -1)
+    id=$(printf '%s' "$created" | json_field id)
   fi
   [ -n "$id" ] || { echo "Could not create or find the release for $TAG." >&2; exit 1; }
   echo "  release id $id"
 
-  curl -fsS -X POST \
-    -H "Authorization: token $GH_TOKEN" \
-    -F "attachment=@$zip" \
-    "$GITHUB_API_URL/repos/$owner/$repo/releases/$id/assets?name=$PLUGIN_SLUG.zip" >/dev/null
-  echo "  attached $PLUGIN_SLUG.zip"
+  # Before uploading anything to it, confirm the id really is this tag's. The
+  # failure being guarded against is not a 404 — that is loud — but an id that
+  # exists and belongs to something else, which would attach this plugin's zip
+  # to an unrelated release with every check still green.
+  release=$(curl -fsS -H "Authorization: token $GH_TOKEN" \
+    "$GITHUB_API_URL/repos/$owner/$repo/releases/$id")
+  actual=$(printf '%s' "$release" | json_field tag_name)
+  if [ "$actual" != "$TAG" ]; then
+    echo "Release id $id is tagged '$actual', not '$TAG'. Refusing to upload the zip to it." >&2
+    exit 1
+  fi
+
+  # A re-run must not fail on the half that already succeeded: the upload
+  # rejects a duplicate asset name.
+  if printf '%s' "$release" | python3 -c '
+import json, sys
+data = json.load( sys.stdin )
+sys.exit( 0 if any( a.get( "name" ) == sys.argv[1] for a in data.get( "assets", [] ) ) else 1 )
+' "$PLUGIN_SLUG.zip"; then
+    echo "  $PLUGIN_SLUG.zip is already attached — leaving it alone"
+  else
+    curl -fsS -X POST \
+      -H "Authorization: token $GH_TOKEN" \
+      -F "attachment=@$zip" \
+      "$GITHUB_API_URL/repos/$owner/$repo/releases/$id/assets?name=$PLUGIN_SLUG.zip" >/dev/null
+    echo "  attached $PLUGIN_SLUG.zip"
+  fi
 
   release_api="$GITHUB_API_URL/repos/$owner/$repo/releases/latest"
 fi
 
 ci_step "the feed, read the way a shop reads it"
-# Deliberately no token on any request below. A "check" that sends credentials
-# the shops do not have is the false positive that hides exactly this bug.
+
+# Only the forge named in "Update URI" actually serves shops. This script runs
+# on both, and the other one is a mirror — requiring a mirror to be anonymously
+# readable would fail every release for a repository that is private on purpose.
+# (It did, on the first v1.4.0 run: GitHub is private and is not the feed.)
+update_uri=$(sed -n -E 's/^[[:space:]]*\*[[:space:]]*Update URI:[[:space:]]*(.*)/\1/p' "$PLUGIN_MAIN" | head -1 | tr -d '[:space:]')
+feed_host=$(printf '%s' "$update_uri" | sed -E 's|^[a-z]+://([^/]+).*|\1|')
+this_host=$(printf '%s' "${GITHUB_SERVER_URL:-}" | sed -E 's|^[a-z]+://([^/]+).*|\1|')
+
+if [ -z "$update_uri" ]; then
+  echo "The plugin header has no Update URI, so there is no feed to check."
+  exit 0
+fi
+
+if [ "$feed_host" != "$this_host" ]; then
+  echo "  $this_host is a mirror; shops read $feed_host. Nothing to verify here."
+  exit 0
+fi
+
 feed=$(curl -fsS --max-time 30 "$release_api" 2>/dev/null || true)
 
 if [ -z "$feed" ]; then
@@ -126,16 +194,35 @@ if [ -z "$feed" ]; then
   exit 1
 fi
 
-package=$(printf '%s' "$feed" | tr ',' '\n' | sed -n -E 's/.*"browser_download_url":[[:space:]]*"([^"]*\.zip)".*/\1/p' | head -1)
-if [ -z "$package" ]; then
+printf '%s' "$feed" | grep -q '"browser_download_url"' || {
   echo
   ci_fail "The release is readable, but it has no zip attached. WordPress would be offered an update it cannot download."
   exit 1
-fi
+}
 
-code=$(curl -s -o /dev/null -w '%{http_code}' -L --max-time 60 "$package")
+# Checked at the address the PLUGIN builds, not the one the API reports.
+#
+# A forge fills browser_download_url from its own configured root URL, which is
+# not necessarily the address the outside world reaches it on: gitea.nolimit.dk
+# returns http://57.129.89.117:25001/... there, a plain-HTTP raw IP that
+# bypasses the Cloudflare tunnel. Verifying that address would be verifying a
+# URL no shop ever uses — a green check on the wrong thing, which is worse than
+# no check.
+package="$update_uri/releases/download/$TAG/$PLUGIN_SLUG.zip"
+code=$(curl -s -o /tmp/wpci-feed.zip -w '%{http_code}' -L --max-time 120 "$package")
 echo "  $package -> HTTP $code"
-[ "$code" = 200 ] || { ci_fail "The package URL is not anonymously downloadable."; exit 1; }
+[ "$code" = 200 ] || { ci_fail "The package URL the plugin will use is not anonymously downloadable."; exit 1; }
+
+# And it has to be the plugin, not an error page with a 200 on it.
+python3 -c '
+import sys, zipfile
+names = zipfile.ZipFile("/tmp/wpci-feed.zip").namelist()
+main = sys.argv[1] + "/" + sys.argv[2]
+if main not in names:
+    sys.exit("The downloaded zip does not contain " + main)
+print("  it is the plugin: %d entries, %s present" % (len(names), main))
+' "$PLUGIN_SLUG" "$PLUGIN_MAIN"
+rm -f /tmp/wpci-feed.zip
 
 echo
 echo "Published $TAG. A shop running this plugin will be offered it within twelve hours,"

ci/static.sh

@@ -76,11 +76,13 @@ before=$fails
 if git ls-files -z '*.php' | xargs -0 grep -nP '<\?(?!php|=|xml)' ; then
   note_fail "Use <?php, not short open tags."
 fi
-while read -r f; do
+# -z: git quotes non-ASCII paths, and the quoted form is not a path that
+# exists, so this loop would silently skip the file it was meant to check.
+while IFS= read -r -d '' f; do
   [ -n "$f" ] || continue
   [ "$(tail -c 3 "$f" | tr -d '[:space:]')" = "?>" ] \
     && { ci_annotate error "$f" 1 "Remove the trailing ?> at the end of the file."; fails=$((fails + 1)); }
-done <<< "$(git ls-files '*.php')"
+done < <(git ls-files -z '*.php')
 [ "$fails" = "$before" ] && echo "  clean"
 
 ci_step "text domain"
@@ -141,6 +143,47 @@ for readme in readme.txt README.txt; do
     || note_fail "$readme has 'Stable tag: $stable' but the plugin header says $version."
 done
 
+ci_step "no secrets in tracked files"
+# Suggested by the AI-manager port, and it costs nothing: a pushed key cannot be
+# unpushed. It has to be rotated, and the window between the push and noticing
+# is the whole problem.
+#
+# Deliberately narrow. Broad entropy heuristics fire on minified assets, hashes
+# and base64 images, and a check that cries wolf gets commented out — which is
+# worse than not having it. These are prefixes that mean one thing only.
+before=$fails
+while IFS= read -r -d '' f; do
+  [ -f "$f" ] || continue
+  if LC_ALL=C grep -nE '(sk-ant-[A-Za-z0-9_-]{16,}|sk-[A-Za-z0-9]{32,}|ghp_[A-Za-z0-9]{30,}|gho_[A-Za-z0-9]{30,}|github_pat_[A-Za-z0-9_]{50,}|AKIA[0-9A-Z]{16}|-----BEGIN [A-Z ]*PRIVATE KEY-----)' "$f"; then
+    note_fail "$f looks like it contains a credential. It cannot be unpushed — rotate it."
+  fi
+done < <(git ls-files -z)
+[ "$fails" = "$before" ] && echo "  nothing that looks like a key or a private key"
+
+ci_step "no placeholders left in the plugin header"
+# The header is the plugin's business card: wp-admin shows the author and the
+# links to whoever installs it, so a placeholder there survives for as long as
+# nobody happens to look at that screen. This plugin shipped with
+# "https://example.com/" as its Plugin URI for several releases.
+#
+# It catches the generic markers only. A made-up vendor name — this one went
+# out as "WEDSMP" — looks exactly like a real one to any check, so an empty
+# field is warned about but a wrong-but-plausible value cannot be.
+before=$fails
+for field in 'Plugin Name' 'Description' 'Author' 'Author URI' 'Plugin URI'; do
+  value=$(ci_plugin_header "$field")
+  if [ -z "$value" ]; then
+    echo "::warning::The plugin header has no '$field:'."
+    continue
+  fi
+  case "$value" in
+    *example.com*|*example.org*|*yourname*|*YOUR_*|*TODO*|*FIXME*|*changeme*|*'<'*'>'*)
+      note_fail "$field is still a placeholder: $value"
+      ;;
+  esac
+done
+[ "$fails" = "$before" ] && echo "  name, description, author and links are all filled in"
+
 ci_step "the compatibility headers still tell the truth"
 # Advisory, never fatal. WordPress ships a new version whether or not anything
 # here is wrong, and a build that goes red on release day for a header nobody

ci/update-smoke.sh

@@ -0,0 +1,132 @@
+#!/usr/bin/env bash
+# Install the PREVIOUS version into a throwaway shop and let WordPress update
+# it from the published feed, on its own.
+#
+# This is the only check that proves the whole chain: header, filter, feed,
+# download address, zip layout and the folder WordPress unpacks into. Every
+# part of it can be individually correct and the update still not arrive —
+# a package URL on an address the shop cannot reach, a zip whose top-level
+# directory is not the plugin slug, a version WordPress does not consider
+# newer. Run it after a release.
+#
+#   FROM_VERSION=1.3.1 ci/update-smoke.sh
+set -euo pipefail
+
+cd "$(dirname "$0")/.."
+. ci/lib.sh
+ci_load_conf
+
+FROM_VERSION="${FROM_VERSION:-0.0.1}"
+expected=$(ci_plugin_version)
+
+id="wpup-$$"
+net="$id-net"
+cleanup() {
+  docker rm -f "$id-db" "$id-cli" >/dev/null 2>&1 || true
+  docker volume rm -f "$id-wp" >/dev/null 2>&1 || true
+  docker network rm "$net" >/dev/null 2>&1 || true
+}
+trap cleanup EXIT
+
+echo "Installing $PLUGIN_SLUG $FROM_VERSION, then asking WordPress to update it. Expecting $expected."
+
+docker network create "$net" >/dev/null
+docker volume create "$id-wp" >/dev/null
+docker run -d --name "$id-db" --network "$net" \
+  -e MARIADB_ROOT_PASSWORD=root -e MARIADB_DATABASE=wordpress \
+  -e MARIADB_USER=wordpress -e MARIADB_PASSWORD=wordpress mariadb:lts >/dev/null
+docker run --rm -v "$id-wp:/var/www/html" alpine chown 33:33 /var/www/html
+docker run -d --name "$id-cli" --network "$net" -v "$id-wp:/var/www/html" \
+  -e WORDPRESS_DB_HOST="$id-db" wordpress:cli sleep infinity >/dev/null
+docker exec -u root "$id-cli" sh -c 'echo memory_limit=512M > /usr/local/etc/php/conf.d/zz-memory.ini'
+wp() { docker exec "$id-cli" wp "$@"; }
+
+for i in $(seq 1 60); do
+  docker exec "$id-db" mariadb -uwordpress -pwordpress -e 'select 1' wordpress >/dev/null 2>&1 && break
+  [ "$i" = 60 ] && { echo "MariaDB never came up." >&2; exit 1; }
+  sleep 2
+done
+
+ci_step "a shop running the previous version"
+wp core download --quiet
+wp config create --dbname=wordpress --dbuser=wordpress --dbpass=wordpress --dbhost="$id-db" --quiet
+wp core install --url=http://plugin.test --title="update smoke" --admin_user=admin \
+  --admin_password=admin --admin_email=ci@example.com --skip-email --quiet
+[ "$NEEDS_WOOCOMMERCE" = yes ] && wp plugin install woocommerce --activate --quiet
+
+# The working tree, with the version wound back. WordPress compares the feed
+# against this header and nothing else, so this is what makes it an "older"
+# install as far as the update check is concerned.
+./ci/dist-files.sh | tr '\n' '\0' | tar --null -T - -cf - \
+  | docker exec -i "$id-cli" sh -c \
+      "mkdir -p /var/www/html/wp-content/plugins/$PLUGIN_SLUG \
+       && tar -xf - -C /var/www/html/wp-content/plugins/$PLUGIN_SLUG"
+docker exec "$id-cli" sed -i -E \
+  "s/^([[:space:]]*\*[[:space:]]*Version:[[:space:]]*).*/\1$FROM_VERSION/" \
+  "/var/www/html/wp-content/plugins/$PLUGIN_SLUG/$PLUGIN_MAIN"
+wp plugin activate "$PLUGIN_SLUG" --quiet
+installed=$(wp plugin get "$PLUGIN_SLUG" --field=version)
+echo "  installed $installed"
+[ "$installed" = "$FROM_VERSION" ] || { echo "Winding the version back did not take." >&2; exit 1; }
+
+ci_step "what WordPress thinks, unprompted"
+# Not the plugin's own code — WordPress's update check, the same one that runs
+# on a schedule in a live shop.
+wp plugin update --all --dry-run 2>&1 | sed 's/^/  /' || true
+available=$(wp plugin list --name="$PLUGIN_SLUG" --field=update)
+echo "  update status: $available"
+[ "$available" = available ] || {
+  echo "WordPress was not offered an update. The header, the filter or the feed is wrong." >&2
+  exit 1
+}
+
+ci_step "letting WordPress install it"
+wp plugin update "$PLUGIN_SLUG" 2>&1 | sed 's/^/  /'
+
+now=$(wp plugin get "$PLUGIN_SLUG" --field=version)
+status=$(wp plugin list --name="$PLUGIN_SLUG" --field=status)
+echo
+echo "  version after update: $now (was $FROM_VERSION)"
+echo "  status:               $status"
+
+[ "$now" = "$expected" ] || { echo "Expected $expected after the update." >&2; exit 1; }
+[ "$status" = active ] || { echo "The plugin is no longer active after updating itself." >&2; exit 1; }
+
+ci_step "one copy of the plugin, not two"
+# A zip whose top-level directory is not the slug installs a SECOND copy beside
+# the first instead of replacing it, and the old one stays active. This used to
+# count the directories into a variable and then never look at it — a check
+# that could not fail, sitting under a comment explaining exactly what it was
+# for.
+docker exec "$id-cli" ls /var/www/html/wp-content/plugins | sed 's/^/  /'
+copies=$(docker exec "$id-cli" sh -c \
+  "ls -d /var/www/html/wp-content/plugins/$PLUGIN_SLUG* 2>/dev/null | wc -l" | tr -d '[:space:]')
+echo "  directories starting with $PLUGIN_SLUG: $copies"
+[ "$copies" = 1 ] || {
+  echo "Expected exactly one, got $copies. The zip unpacked to a directory that is not the slug." >&2
+  exit 1
+}
+
+ci_step "the code that is now running reports the new version"
+# Files can be replaced while the running code still reports the old version —
+# an opcache that was not invalidated, or a constant defined somewhere else.
+# The constant name is read out of the plugin header rather than hard-coded:
+# this script is copied between plugins, and a name that does not exist over
+# there prints an empty value and carries on cheerfully.
+const=$(sed -n -E "s/^[[:space:]]*define\([[:space:]]*'([A-Z_]*VERSION)'.*/\1/p" "$PLUGIN_MAIN" | head -1)
+if [ -n "$const" ]; then
+  running=$(wp eval "echo defined( '$const' ) ? $const : '';" | tr -d '[:space:]')
+  echo "  $const = ${running:-<undefined>}"
+  [ "$running" = "$expected" ] || {
+    echo "The files say $expected but the running code says '${running:-undefined}'." >&2
+    exit 1
+  }
+else
+  echo "  $PLUGIN_MAIN defines no *_VERSION constant — nothing to cross-check."
+fi
+
+wp plugin list --name="$PLUGIN_SLUG" --field=update | grep -qx none \
+  && echo "  WordPress no longer offers an update — the header and the feed agree."
+
+echo
+echo "WordPress found, downloaded and installed $expected from the published feed on its own."

docs/REUSE.md

@@ -52,6 +52,34 @@ and instantiate the updater **before** any "is WooCommerce active" gate — a
 shop with WooCommerce switched off for an afternoon must not quietly stop
 receiving fixes.
 
+Three things in that file are load-bearing and none of them look it:
+
+- 🔴 **`offer_update()` answers even when the installed version is already
+  current.** It is tempting to return `false` there — there is no update, after
+  all — and that one line is what silently removes the **Enable auto-updates**
+  link from the Plugins screen. `WP_Plugins_List_Table` sets
+  `update-supported` only for plugins it finds in the update transient's
+  `response` **or** `no_update` list; a plugin that stays silent is in neither,
+  and wp-admin says "Auto-updates are not available for this plugin." The
+  plugin looks perfectly configured and can never auto-update.
+  `tests/smoke.php` asserts the rendered table, not the intention.
+- **Set `icons`.** Without it Dashboard → Updates shows a generic grey plug.
+  Point it at the shop's own copy (`PLUGIN_URL . 'assets/icon.svg'`), not the
+  release host: one fewer thing that must be reachable for wp-admin to render,
+  and it cannot go mixed-content on an HTTPS shop.
+- **`Update URI` also switches wordpress.org off** for this plugin, from
+  WordPress 5.8. Remove the header and a .org plugin that happens to share the
+  slug could be pushed onto a shop running yours.
+
+🔴 **Keep the feed cache short — WordPress is already the rate limiter.** It
+gates its own check by screen: one minute on Dashboard → Updates, one hour on
+the Plugins screen, 2–12 hours in the background. This filter only runs when
+that check runs, so any cache longer than that cadence simply hides new
+releases underneath it. Ours was six hours "because WordPress checks twice a
+day anyway", and the symptom was a release going out and the shop being shown
+nothing. It is fifteen minutes now, and `forget_on_force_check()` drops it
+entirely on the **Check again** link.
+
 **6. Make the Gitea repository public**, or point `Update URI` at a separate
 public releases-only repository. Every shop reads that feed without
 credentials; `ci/publish-release.sh` fails the release with this instruction if
@@ -72,9 +100,105 @@ it cannot.
   that run is green.
 - `release.yml` — tag, test, build, publish, then read the feed back with no
   credentials to prove a shop can download it.
+- `ci/update-smoke.sh` — install the previous version into a throwaway shop and
+  let WordPress update it by itself. The only check that proves the whole chain.
+- Assertions that the **Enable auto-updates** link is actually offered, built
+  from the real `WP_Plugins_List_Table`, and that the update offer carries an
+  icon that exists in the release.
 - `ci/workflows-in-sync.sh` — fails when the two workflow roots drift, which is
   the only way to notice that a workflow stopped running on Gitea.
 
+## Running these locally: `git add` first
+
+Every one of these scripts derives "what ships" from `git ls-files`, which
+reads the **index**. An uncommitted file is therefore invisible to
+`ci/dist-files.sh`, to the release zip, and to the copy that goes into the test
+site.
+
+That is deliberate — it is what catches a file that was written, referenced and
+never committed, which is a release that is missing a file while every local
+test passes because the file is sitting right there in the working tree. But it
+also means running any of this before `git add` tests a release without your
+newest file, and the failure is silent: the check does not complain, it just
+measures something else. It cost two rounds here, once on
+`includes/class-updater.php` and once on `assets/icon.svg`.
+
+If a script reports something you just fixed as still missing, `git status`
+before you debug the script.
+
+## Make a check fail once before you believe it
+
+Three checks in this directory turned out to be incapable of failing, and all
+three sat under a comment explaining exactly what they were for:
+
+- `tests/smoke.php` printed `FAIL` and exited 0 for four releases.
+- `ci/static.sh`'s PHP lint passed while linting an empty directory.
+- `ci/update-smoke.sh` counted the plugin directories into a variable and never
+  looked at it — under a comment about a zip installing a second copy.
+
+None of them were caught by reading the code, and a green build is exactly what
+a broken check looks like. So: break it on purpose once, watch it go red, then
+put it back. It costs one run.
+
+## The bug you cannot find by reading your own repo
+
+🔴 **`update_plugins_{$hostname}` is keyed on the hostname, not the
+repository.** Every plugin whose `Update URI` points at the same host shares one
+hook, and WordPress runs **every** callback on it for **every** one of those
+plugins:
+
+```php
+// wp-includes/update.php
+$update = apply_filters( "update_plugins_{$hostname}", false, $plugin_data, $plugin_file, $locales );
+```
+
+Answer unconditionally and you offer your release to your neighbour. Measured on
+a live shop: a subscriptions plugin was shown this one's 1.4.4 and told it was
+an update for itself. Load order decides who wins, so which plugin gets
+corrupted is arbitrary — and pointed at one with auto-updates enabled, it
+installs a stranger's zip over itself, unattended, on a shop taking money.
+
+```php
+add_filter( "update_plugins_{$host}", array( $this, 'offer_update' ), 10, 3 );
+
+public function offer_update( $update, $plugin_data, $plugin_file = '' ) {
+    if ( '' !== $plugin_file && plugin_basename( SELF_FILE ) !== $plugin_file ) {
+        return $update;
+    }
+```
+
+Both halves. Leave the accepted-argument count at 2 and the third argument never
+arrives, so the guard compares against an empty string and does nothing — the
+same shape of bug it exists to fix. `plugins_api` is safe if it guards on
+`$args->slug`.
+
+**No integration test can find this.** A site test installs one plugin from that
+host, so the collision cannot arise there. The assertion is the entire defence:
+
+```php
+wc_edm_ok( 'another plugin on the same host is not offered our release',
+    false === $updater->offer_update( false, $data, 'someone-else/someone-else.php' ) );
+```
+
+The same shape applies to anything else shared between sibling plugins. A
+`shared-*.php` file copied byte-identically into five plugins fatals with
+`Cannot redeclare` on the second activation unless everything in it is wrapped
+in `function_exists()` / `class_exists()` / `defined()` — and then the copy that
+loads first wins, which is alphabetical order, which is arbitrary. Freeze the
+contract rather than versioning the file.
+
+## The repository name and the installed slug are different things
+
+The repo may be renamed freely — Gitea keeps a 301 on both the API and the deep
+release-download paths (measured), and WordPress follows up to 5 redirects by
+default, so installed copies keep updating through the old `Update URI`.
+
+The **installed** slug can never change. It is `<slug>/<main file>` in
+`wp-content/plugins`, and a new one installs a second copy beside the first
+while the old one stays active. So `PLUGIN_SLUG` in `ci/plugin.conf` is allowed
+to disagree with the repository name forever, and if it does, say so in the file
+or somebody will helpfully align them.
+
 ## Two guards worth understanding before you move them
 
 **`.gitea/workflows/` hides `.github/workflows/` completely.** Gitea uses the
@@ -88,6 +212,30 @@ and a release with no zip attached both produce a page that looks perfect to
 anyone logged in, and an update that no shop is ever offered. A check that
 sends a token is the false positive that hides exactly that.
 
+**Do not parse a forge's JSON with `sed`.** A greedy `.*"id":([0-9]+)` matches
+the *last* id in the payload, and a release object carries an embedded
+`author` and, once anything is attached, an `assets` array — each with an id of
+its own. `ci/publish-release.sh` uses a four-line `json_field()` over `python3`
+instead. Measured here: the greedy pattern returns the asset ids 1/2/3/4 for
+releases whose real ids are 416/417/419/421.
+
+Four releases were published correctly anyway, and the reason is **who
+published them, not which instance**: a release created by the Actions job
+token has the ghost user as its author (`"id":-1`), and the minus sign stops
+`[0-9]+` from matching. A release created by a real user — a cross-repo PAT, or
+one published by hand — has `"id":1` and the greedy match lands on it. Do not
+read the `-1` as a safety margin; it lasts until the first release somebody
+publishes by hand. And on a re-run the lookup fetches a response that *has*
+assets, where the last id is an asset id: positive, on any instance, with any
+token.
+
+**A forge's own download URL is not the address your users can reach.**
+`browser_download_url` is built from the forge's configured root URL;
+`gitea.nolimit.dk` reports `http://57.129.89.117:25001/...` there. The updater
+rebuilds the address from the `Update URI` header and keeps only the path. This
+one hides particularly well: a CI job on the same network reaches that raw IP,
+so following the reported URL goes green and only a real client outside fails.
+
 ## Candidates already in the fleet
 
 `spool` and `subscriptions` are both WooCommerce plugins with some of this

docs/TESTING-AND-RELEASES.md

@@ -16,6 +16,8 @@ Three questions, answered by three things in this repository.
 ci/static.sh                  # syntax, hygiene, versions, headers — seconds
 ci/site-test.sh               # a real WordPress + WooCommerce — a few minutes
 ci/build-zip.sh               # what a shop actually installs
+FROM_VERSION=1.4.0 \
+  ci/update-smoke.sh          # let WordPress update itself from the live feed
 ```
 
 `ci/site-test.sh` takes three knobs:
@@ -110,6 +112,31 @@ Two things in there are guards against bugs that are invisible without them:
 
 ---
 
+## Proving an update actually arrives
+
+`ci/update-smoke.sh` installs the **previous** version into a throwaway shop
+and then gets out of the way: WordPress's own update check finds the new one,
+downloads it and installs it.
+
+```sh
+FROM_VERSION=1.4.0 ci/update-smoke.sh
+```
+
+Nothing else can stand in for it. Every piece of the chain can be individually
+correct and the update still not arrive:
+
+- a package URL on an address the shop cannot reach,
+- a zip whose top-level directory is not the plugin slug — which installs a
+  *second* copy beside the first and leaves the old one active,
+- a version WordPress does not consider newer than what is installed.
+
+It checks all three, plus that the plugin is still active afterwards and that
+WordPress stops offering the update once it is applied.
+
+Run it after a release.
+
+---
+
 ## How the automatic updates work
 
 The plugin header carries:
@@ -128,11 +155,67 @@ That means all of this works with no extra code:
 
 - the update notice on **Plugins** and **Dashboard → Updates**
 - the **update now** link
-- the per-plugin **Enable auto-updates** link — WordPress builds that from the
-  plugins it has an answer for, which is why the updater answers even when the
-  installed version is already current
+- the per-plugin **Enable auto-updates** link
 - `wp plugin update woocommerce-email-discount-manager` over WP-CLI
 
+### Turning on automatic updates
+
+Plugins screen → the **Automatic updates** column on the right → **Enable
+auto-updates**. WordPress then installs new versions by itself on its
+twice-daily check.
+
+That link is not free for a plugin outside wordpress.org.
+`WP_Plugins_List_Table` marks a plugin as `update-supported` only if it finds
+it in the update transient's `response` list (an update is waiting) or its
+`no_update` list (we were asked, there is none):
+
+```php
+// wp-admin/includes/class-wp-plugins-list-table.php
+$plugin_data = array_merge( (array) $plugin_info->response[ $plugin_file ],  array( 'update-supported' => true ), $plugin_data );
+$plugin_data = array_merge( (array) $plugin_info->no_update[ $plugin_file ], array( 'update-supported' => true ), $plugin_data );
+} elseif ( empty( $plugin_data['update-supported'] ) ) {
+    $plugin_data['update-supported'] = false;
+```
+
+A plugin in neither list gets "Auto-updates are not available for this plugin"
+and no toggle — while looking entirely healthy otherwise. That is why
+`offer_update()` answers even when the installed version is already current:
+the answer lands in `no_update`, and the link stays. `tests/smoke.php` builds
+the real list table and asserts the flag rather than trusting the reasoning.
+
+### "Check again" really checks again
+
+The feed is cached for fifteen minutes, and the cache is dropped entirely when
+wp-admin is loaded with `force-check`.
+
+It was six hours, on the reasoning that WordPress checks twice a day anyway.
+That reasoning was wrong. WordPress gates its own check **by screen**:
+
+| Screen | How often WordPress re-checks |
+| --- | --- |
+| Dashboard → Updates | every minute |
+| Plugins | every hour |
+| Background / cron | every 2–12 hours |
+
+This filter only runs when that check runs, so WordPress is already the rate
+limiter. A cache longer than its cadence does nothing but hide new releases
+underneath it — a release published, and a shop shown nothing.
+
+From the command line, `wp transient delete wc_edm_release_feed` does the same.
+
+### The icon
+
+`assets/icon.svg`, handed to WordPress in the offer's `icons` key. Without it
+Dashboard → Updates shows a generic grey plug. WordPress takes the first of
+`svg`, `2x`, `1x`, `default` that is set.
+
+It is served from the shop's own copy of the plugin, not from the release host:
+one fewer thing that has to be reachable for wp-admin to render correctly, and
+it cannot go mixed-content on an HTTPS shop. The mark is drawn as paths rather
+than `<text>`, because an SVG that leans on a font renders differently
+everywhere — and this one is shown at about 40px, which is the size where that
+matters.
+
 `Update URI` earns its place a second way: since WordPress 5.8, a plugin that
 declares one is **never asked about on wordpress.org**. Without it, a .org
 plugin that happened to share this slug could be pushed onto a shop running
@@ -149,6 +232,28 @@ If you would rather keep the source private, create a separate public repo that
 holds only releases and point `Update URI` at that instead — the updater
 derives everything else from the header, so that is a one-line change.
 
+### The download address is rebuilt, not taken
+
+The updater ignores the `browser_download_url` the API hands back and builds
+the address from the `Update URI` header instead.
+
+That field is filled from the forge's own configured root URL, which is not
+necessarily the address the outside world reaches it on. `gitea.nolimit.dk`
+returns `http://57.129.89.117:25001/...` there — plain HTTP, a raw IP, a
+non-standard port, and around the Cloudflare tunnel in front of it. A shop
+handed that would be downloading plugin code over an unencrypted connection to
+an address nothing guarantees will keep working.
+
+The paths Gitea reports are correct; only the host is wrong. So the host comes
+from the header — the one place that already had to be right for any of this
+to work — and the path is kept.
+
+This is worth knowing because of *how* it hides: a CI job on the same network
+reaches that raw IP perfectly well, so a verification step that follows the
+reported URL goes green. Only a real client outside fails. The release check
+therefore downloads the address **the plugin builds**, and opens the zip to
+confirm it is the plugin rather than an error page with a 200 on it.
+
 ### It reports nothing
 
 The update check sends a plain unauthenticated GET for a file every visitor to

includes/class-updater.php

@@ -34,10 +34,24 @@ class WC_EDM_Updater {
 	const TRANSIENT = 'wc_edm_release_feed';
 
 	/**
-	 * How long that cache lives. WordPress checks for updates twice a day; a
-	 * shorter window would only add requests, a longer one would delay a fix.
+	 * How long that cache lives.
+	 *
+	 * Six hours, originally, on the reasoning that WordPress checks twice a
+	 * day anyway. That reasoning was wrong, and the symptom was a shop that
+	 * had just been told a new version existed and was shown nothing.
+	 *
+	 * WordPress does not check twice a day when somebody is looking. It gates
+	 * its own check by screen — one minute on Dashboard → Updates, one hour on
+	 * the Plugins screen, twelve hours in the background (wp_update_plugins(),
+	 * switch on current_filter()). This filter only runs when that check runs,
+	 * so WordPress is already the rate limiter, and a cache longer than its
+	 * cadence does nothing but hide new releases underneath it.
+	 *
+	 * Fifteen minutes is left only to absorb a burst — several calls in one
+	 * request, or other code calling wp_update_plugins() with extra stats,
+	 * which bypasses the gate above.
 	 */
-	const TTL = 6 * HOUR_IN_SECONDS;
+	const TTL = 15 * MINUTE_IN_SECONDS;
 
 	/**
 	 * Hook into the update check for our own host only.
@@ -49,12 +63,18 @@ class WC_EDM_Updater {
 			return;
 		}
 
-		add_filter( "update_plugins_{$host}", array( $this, 'offer_update' ), 10, 2 );
+		add_filter( "update_plugins_{$host}", array( $this, 'offer_update' ), 10, 3 );
 
 		// Without this the old answer is served for up to six hours after an
 		// update, and the plugins screen keeps offering a version already
 		// installed.
 		add_action( 'upgrader_process_complete', array( $this, 'forget' ), 10, 0 );
+
+		// And "Check again" has to actually check again.
+		add_action( 'admin_init', array( $this, 'forget_on_force_check' ) );
+
+		// "View version details" next to the update notice.
+		add_filter( 'plugins_api', array( $this, 'plugin_details' ), 10, 3 );
 	}
 
 	/**
@@ -106,9 +126,26 @@ class WC_EDM_Updater {
 	 *
 	 * @param array|false $update      Update offered so far.
 	 * @param array       $plugin_data Headers of the installed plugin.
+	 * @param string      $plugin_file Which plugin WordPress is asking about.
 	 * @return array|false
 	 */
-	public function offer_update( $update, $plugin_data ) {
+	public function offer_update( $update, $plugin_data, $plugin_file = '' ) {
+		// The filter name is built from the HOSTNAME, not the repository:
+		// every plugin that updates from gitea.nolimit.dk shares the one hook
+		// `update_plugins_gitea.nolimit.dk`, and WordPress runs every callback
+		// on it for every one of those plugins. Without this check a plugin
+		// answers for its neighbour and offers it its own release — measured
+		// on a live shop, where a subscriptions plugin was offered this one's
+		// 1.4.4 and told it was an update for itself.
+		//
+		// The `10, 3` on the add_filter above is half of this fix. With the
+		// accepted-argument count left at 2 the third argument never arrives,
+		// $plugin_file stays empty, and the guard silently does nothing — the
+		// same shape of bug it exists to fix.
+		if ( '' !== $plugin_file && plugin_basename( WC_EDM_PLUGIN_FILE ) !== $plugin_file ) {
+			return $update;
+		}
+
 		$release = $this->latest_release();
 
 		if ( ! $release ) {
@@ -123,6 +160,70 @@ class WC_EDM_Updater {
 			'tested'       => $release['tested'],
 			'requires'     => isset( $plugin_data['RequiresWP'] ) ? $plugin_data['RequiresWP'] : '',
 			'requires_php' => isset( $plugin_data['RequiresPHP'] ) ? $plugin_data['RequiresPHP'] : '',
+			// Without this, Dashboard → Updates shows the generic grey plug
+			// next to the plugin. WordPress takes the first of svg, 2x, 1x,
+			// default that is set.
+			//
+			// Served from the shop's own copy of the plugin rather than from
+			// the release host: it is one fewer thing that has to be up and
+			// reachable for wp-admin to render correctly, it cannot go mixed
+			// content on an HTTPS shop, and the icon is in the zip anyway.
+			'icons'        => array(
+				'svg'     => WC_EDM_PLUGIN_URL . 'assets/icon.svg',
+				'default' => WC_EDM_PLUGIN_URL . 'assets/icon.svg',
+			),
+		);
+	}
+
+	/**
+	 * Answer the "View version details" modal.
+	 *
+	 * WordPress builds that link as
+	 * plugin-install.php?tab=plugin-information&plugin=<slug>, which calls
+	 * plugins_api() — and plugins_api() asks **wordpress.org**. This plugin is
+	 * not there, so without this filter the link opens a modal containing an
+	 * error, on the same screen that is otherwise telling the shop owner an
+	 * update is ready. Nothing warns you: the link looks like every other
+	 * plugin's.
+	 *
+	 * @param false|object|array $result Response so far.
+	 * @param string             $action Requested action.
+	 * @param object             $args   Request arguments.
+	 * @return false|object|array
+	 */
+	public function plugin_details( $result, $action, $args ) {
+		$slug = dirname( plugin_basename( WC_EDM_PLUGIN_FILE ) );
+
+		if ( 'plugin_information' !== $action || empty( $args->slug ) || $args->slug !== $slug ) {
+			return $result;
+		}
+
+		require_once ABSPATH . 'wp-admin/includes/plugin.php';
+		$plugin  = get_plugin_data( WC_EDM_PLUGIN_FILE, false, false );
+		$release = $this->latest_release();
+
+		$notes = $release && '' !== $release['notes'] ? $release['notes'] : '';
+
+		return (object) array(
+			'name'          => $plugin['Name'],
+			'slug'          => $slug,
+			'version'       => $release ? $release['version'] : $plugin['Version'],
+			'author'        => $plugin['Author'],
+			'author_profile'=> $plugin['AuthorURI'],
+			'homepage'      => $plugin['PluginURI'],
+			'requires'      => $plugin['RequiresWP'],
+			'requires_php'  => $plugin['RequiresPHP'],
+			'tested'        => $release ? $release['tested'] : '',
+			'download_link' => $release ? $release['package'] : '',
+			'icons'         => array( 'svg' => WC_EDM_PLUGIN_URL . 'assets/icon.svg' ),
+			'sections'      => array(
+				'description' => wpautop( esc_html( $plugin['Description'] ) ),
+				// Plain text from the release notes, not markdown: rendering it
+				// as HTML would mean trusting whatever is in a release body.
+				'changelog'   => '' !== $notes
+					? wpautop( esc_html( $notes ) )
+					: wpautop( esc_html__( 'Release notes are published with each release.', 'wc-email-discount' ) ),
+			),
 		);
 	}
 
@@ -133,6 +234,27 @@ class WC_EDM_Updater {
 		delete_transient( self::TRANSIENT );
 	}
 
+	/**
+	 * Honour the "Check again" link on Dashboard → Updates.
+	 *
+	 * The six-hour cache is right for the check WordPress runs twice a day on
+	 * its own, and wrong for a button whose entire promise is that it looks
+	 * right now. Without this, someone who has just published a release clicks
+	 * it, sees nothing, and concludes the update mechanism is broken.
+	 *
+	 * No nonce to verify: this reads a link WordPress itself renders, and the
+	 * only effect is discarding a cache — the worst a forged request achieves
+	 * is one extra HTTP GET.
+	 */
+	public function forget_on_force_check() {
+		// phpcs:ignore WordPress.Security.NonceVerification.Recommended
+		if ( empty( $_GET['force-check'] ) || ! current_user_can( 'update_plugins' ) ) {
+			return;
+		}
+
+		$this->forget();
+	}
+
 	/**
 	 * Read the newest release from the repository.
 	 *
@@ -176,49 +298,72 @@ class WC_EDM_Updater {
 			return null;
 		}
 
-		$body = json_decode( wp_remote_retrieve_body( $response ), true );
+		$release = $this->parse_release( json_decode( wp_remote_retrieve_body( $response ), true ) );
 
-		if ( ! is_array( $body ) || empty( $body['tag_name'] ) ) {
+		if ( ! $release ) {
 			set_transient( self::TRANSIENT, 'none', 15 * MINUTE_IN_SECONDS );
 			return null;
 		}
 
-		$package = '';
-		$tested  = '';
+		set_transient( self::TRANSIENT, $release, self::TTL );
+
+		return $release;
+	}
+
+	/**
+	 * Turn a release API response into what WordPress needs.
+	 *
+	 * The download address is rebuilt from the repository address in the
+	 * plugin header rather than taken from the response's
+	 * browser_download_url. That field is built from the forge's own
+	 * configured root URL, which is not necessarily the address the outside
+	 * world reaches it on — gitea.nolimit.dk returns
+	 * "http://57.129.89.117:25001/..." there, a plain-HTTP raw IP that
+	 * bypasses the Cloudflare tunnel in front of it. A shop handed that would
+	 * be downloading plugin code over an unencrypted connection to an address
+	 * that is free to change. Measured on the v1.4.0 release.
+	 *
+	 * @param mixed $body Decoded API response.
+	 * @return array|null { version, package, url, tested }, or null.
+	 */
+	private function parse_release( $body ) {
+		if ( ! is_array( $body ) || empty( $body['tag_name'] ) ) {
+			return null;
+		}
+
+		$tag  = $body['tag_name'];
+		$base = rtrim( self::update_uri(), '/' );
+		$zip  = '';
 
 		foreach ( isset( $body['assets'] ) ? $body['assets'] : array() as $asset ) {
-			if ( empty( $asset['name'] ) || empty( $asset['browser_download_url'] ) ) {
-				continue;
-			}
-			if ( substr( $asset['name'], -4 ) === '.zip' ) {
-				$package = $asset['browser_download_url'];
+			if ( ! empty( $asset['name'] ) && '.zip' === substr( $asset['name'], -4 ) ) {
+				$zip = $asset['name'];
 			}
 		}
 
+		if ( '' === $zip ) {
+			// A release with no zip attached is a half-finished release.
+			// Offering it would hand WordPress a download it cannot install.
+			return null;
+		}
+
 		// The release notes carry the compatibility line the release workflow
 		// writes, so wp-admin can show what this version was actually tested
 		// against instead of what the previous one claimed.
+		$tested = '';
 		if ( ! empty( $body['body'] ) && preg_match( '/^Tested up to:\s*(\S+)/mi', $body['body'], $m ) ) {
 			$tested = $m[1];
 		}
 
-		if ( '' === $package ) {
-			// A release with no zip attached is a half-finished release.
-			// Offering it would hand WordPress a download it cannot install.
-			set_transient( self::TRANSIENT, 'none', 15 * MINUTE_IN_SECONDS );
-			return null;
-		}
-
-		$release = array(
-			'version' => ltrim( $body['tag_name'], 'vV' ),
-			'package' => $package,
-			'url'     => ! empty( $body['html_url'] ) ? $body['html_url'] : $uri,
+		return array(
+			'version' => ltrim( $tag, 'vV' ),
+			'package' => $base . '/releases/download/' . rawurlencode( $tag ) . '/' . rawurlencode( $zip ),
+			'url'     => $base . '/releases/tag/' . rawurlencode( $tag ),
 			'tested'  => $tested,
+			// The release notes are the changelog. Kept so the "View version
+			// details" modal has something true to show.
+			'notes'   => isset( $body['body'] ) ? (string) $body['body'] : '',
 		);
-
-		set_transient( self::TRANSIENT, $release, self::TTL );
-
-		return $release;
 	}
 
 	/**

tests/smoke.php

@@ -14,7 +14,29 @@ if ( ! defined( 'ABSPATH' ) ) {
 	exit;
 }
 
-$wc_edm_failures = 0;
+/*
+ * The counter lives in $GLOBALS on purpose, and the four lines below prove it
+ * reaches the verdict before anything relies on it.
+ *
+ * `wp eval-file` runs this file through eval() INSIDE A METHOD, so the top
+ * level here is function scope, not global scope. A plain `$failures = 0` at
+ * the top and a `global $failures` in a helper below are therefore two
+ * different variables: the helpers increment the real global, the verdict at
+ * the bottom reads the local, and the local is always zero. Every assertion
+ * fails, every FAIL line prints, the file ends with "All assertions passed"
+ * and exits 0 — and CI goes green. That is not reasoning, it is what this file
+ * did until it was measured.
+ *
+ * This is the one file whose entire job is to be able to go red, so it checks
+ * that it can.
+ */
+$GLOBALS['wc_edm_failures'] = 0;
+( static function () { ++$GLOBALS['wc_edm_failures']; } )();
+if ( 1 !== $GLOBALS['wc_edm_failures'] ) {
+	echo "The failure counter does not reach the verdict: this file cannot go red.\n";
+	exit( 1 );
+}
+$GLOBALS['wc_edm_failures'] = 0;
 
 /**
  * Assert a condition and keep going, so one run reports every failure.
@@ -24,14 +46,12 @@ $wc_edm_failures = 0;
  * @param string $detail    Shown when it fails.
  */
 function wc_edm_ok( $what, $condition, $detail = '' ) {
-	global $wc_edm_failures;
-
 	if ( $condition ) {
 		printf( "  ok    %s\n", $what );
 		return;
 	}
 
-	++$wc_edm_failures;
+	++$GLOBALS['wc_edm_failures'];
 	printf( "  FAIL  %s%s\n", $what, '' !== $detail ? " — {$detail}" : '' );
 }
 
@@ -233,6 +253,44 @@ wc_edm_is(
 	$derive->invoke( new WC_EDM_Updater(), 'https://gitea.nolimit.dk/kw/demo' )
 );
 
+// The forge builds browser_download_url from its own configured root URL,
+// which is not necessarily the address the outside world reaches it on. This
+// is the real response gitea.nolimit.dk returned for v1.4.0: a plain-HTTP raw
+// IP that bypasses the Cloudflare tunnel in front of it. A shop handed that
+// would be fetching plugin code over an unencrypted connection to an address
+// that is free to change, so the download address is rebuilt from the
+// repository address in the plugin header instead.
+$parse = new ReflectionMethod( 'WC_EDM_Updater', 'parse_release' );
+$parse->setAccessible( true );
+$parsed = $parse->invoke(
+	new WC_EDM_Updater(),
+	array(
+		'tag_name' => 'v1.4.0',
+		'body'     => "notes\n\nTested up to: 7.1\nWC tested up to: 11.1.0\n",
+		'html_url' => 'http://57.129.89.117:25001/kw/woocommerce-email-discount-manager/releases/tag/v1.4.0',
+		'assets'   => array(
+			array(
+				'name'                 => 'woocommerce-email-discount-manager.zip',
+				'browser_download_url' => 'http://57.129.89.117:25001/kw/woocommerce-email-discount-manager/releases/download/v1.4.0/woocommerce-email-discount-manager.zip',
+			),
+		),
+	)
+);
+
+wc_edm_is( 'the version comes from the tag, without the v', '1.4.0', $parsed['version'] );
+wc_edm_is(
+	'the download address is rebuilt on the host in the plugin header',
+	$update_uri . '/releases/download/v1.4.0/woocommerce-email-discount-manager.zip',
+	$parsed['package']
+);
+wc_edm_ok(
+	'so it is never the raw address the forge happened to report',
+	false === strpos( $parsed['package'], '57.129.89.117' ) && 0 === strpos( $parsed['package'], 'https://' ),
+	'got ' . $parsed['package']
+);
+wc_edm_is( 'and the tested-up-to line is read out of the release notes', '7.1', $parsed['tested'] );
+wc_edm_ok( 'a release with no zip attached is not offered at all', null === $parse->invoke( new WC_EDM_Updater(), array( 'tag_name' => 'v9.9.9', 'assets' => array() ) ) );
+
 // Feed the updater a known release through its own cache instead of the
 // network: what matters here is the shape handed to WordPress, and a test
 // that needs the internet fails for reasons that have nothing to do with it.
@@ -247,13 +305,26 @@ set_transient(
 	60
 );
 
-$offered = wc_edm()->updater->offer_update( false, get_plugin_data( WC_EDM_PLUGIN_FILE, false, false ) );
+$offered = wc_edm()->updater->offer_update( false, get_plugin_data( WC_EDM_PLUGIN_FILE, false, false ), plugin_basename( WC_EDM_PLUGIN_FILE ) );
 wc_edm_is( 'a newer release is offered as an update', '99.0.0', is_array( $offered ) ? $offered['version'] : null );
 wc_edm_is(
 	'and it carries the folder name WordPress will unpack into',
 	'woocommerce-email-discount-manager',
 	is_array( $offered ) ? $offered['slug'] : null
 );
+// Dashboard → Updates falls back to a generic grey plug when this is missing,
+// and a 404 here is invisible until someone looks at that screen.
+wc_edm_ok(
+	'the offer carries an icon',
+	is_array( $offered ) && ! empty( $offered['icons']['svg'] ),
+	'without it wp-admin shows the generic plugin placeholder'
+);
+wc_edm_ok(
+	'and the icon is a file that is actually in the release',
+	file_exists( WC_EDM_PLUGIN_DIR . 'assets/icon.svg' ),
+	'the offer would point wp-admin at a 404'
+);
+
 wc_edm_ok(
 	'the offer names a downloadable package',
 	is_array( $offered ) && ! empty( $offered['package'] ),
@@ -273,16 +344,187 @@ set_transient(
 	),
 	60
 );
-$offered = wc_edm()->updater->offer_update( false, get_plugin_data( WC_EDM_PLUGIN_FILE, false, false ) );
+$offered = wc_edm()->updater->offer_update( false, get_plugin_data( WC_EDM_PLUGIN_FILE, false, false ), plugin_basename( WC_EDM_PLUGIN_FILE ) );
 wc_edm_is( 'the current version is answered too, not passed over', WC_EDM_VERSION, is_array( $offered ) ? $offered['version'] : null );
 
+// 🔴 The filter name is built from the HOSTNAME, not the repository. Every
+// plugin updating from gitea.nolimit.dk shares the hook
+// update_plugins_gitea.nolimit.dk, and WordPress runs every callback on it for
+// every one of those plugins. Answering unconditionally means offering the
+// neighbour your own release — which happened on a live shop: a subscriptions
+// plugin was shown this one's 1.4.4 and told it was an update for itself. Load
+// order decides who wins, so the direction it breaks in is arbitrary.
+//
+// The site test installs exactly one plugin from this host, so the collision
+// can never occur here. This assertion is the whole defence.
+wc_edm_ok(
+	'another plugin on the same host is not offered our release',
+	false === wc_edm()->updater->offer_update(
+		false,
+		get_plugin_data( WC_EDM_PLUGIN_FILE, false, false ),
+		'kw-subscriptions/kw-subscriptions.php'
+	),
+	'we answered for a plugin that is not ours'
+);
+
+// The "View version details" link next to the update notice. WordPress builds
+// it as plugin-install.php?tab=plugin-information&plugin=<slug>, which calls
+// plugins_api() — and plugins_api() asks wordpress.org, where this plugin does
+// not exist. Unanswered, that link opens a modal reading "Plugin not found."
+// on the same screen that is telling the shop owner an update is ready.
+// Measured on a live shop before this was written.
+set_transient(
+	WC_EDM_Updater::TRANSIENT,
+	array(
+		'version' => '99.0.0',
+		'package' => 'https://gitea.nolimit.dk/kw/demo/releases/download/v99.0.0/demo.zip',
+		'url'     => 'https://gitea.nolimit.dk/kw/demo',
+		'tested'  => '7.1',
+		'notes'   => "v99.0.0 — a headline\n\nA line of release notes.",
+	),
+	600
+);
+
+// plugins_api() lives in the admin includes, which a WP-CLI context does not
+// load. wp-admin has it; this does not.
+require_once ABSPATH . 'wp-admin/includes/plugin-install.php';
+
+$wc_edm_slug = dirname( plugin_basename( WC_EDM_PLUGIN_FILE ) );
+$details     = plugins_api( 'plugin_information', array( 'slug' => $wc_edm_slug ) );
+
+wc_edm_ok(
+	'the details modal is answered here, not by wordpress.org',
+	! is_wp_error( $details ),
+	is_wp_error( $details ) ? $details->get_error_message() : ''
+);
+wc_edm_is( 'and it is about this plugin', $wc_edm_slug, is_wp_error( $details ) ? null : $details->slug );
+wc_edm_is( 'it reports the version from the feed', '99.0.0', is_wp_error( $details ) ? null : $details->version );
+wc_edm_ok(
+	'the changelog is the release notes',
+	! is_wp_error( $details ) && false !== strpos( $details->sections['changelog'], 'A line of release notes' ),
+	'a modal with an empty changelog is barely better than an error'
+);
+wc_edm_ok(
+	'and the notes are escaped rather than rendered',
+	! is_wp_error( $details ) && false === strpos( $details->sections['changelog'], '<script' ),
+	'a release body is not a template language'
+);
+wc_edm_ok(
+	'another plugin\'s details request is left alone',
+	false === wc_edm()->updater->plugin_details( false, 'plugin_information', (object) array( 'slug' => 'akismet' ) ),
+	'answering for somebody else would replace their modal with ours'
+);
+
+delete_transient( WC_EDM_Updater::TRANSIENT );
+
+/*
+ * The "Enable auto-updates" link on the Plugins screen.
+ *
+ * It is not automatic for a plugin that does not come from wordpress.org.
+ * WP_Plugins_List_Table sets 'update-supported' => true only for plugins it
+ * finds in the update transient's `response` list (an update is waiting) or
+ * its `no_update` list (we asked, there is none). A plugin in neither gets
+ * "Auto-updates are not available for this plugin." and no toggle.
+ *
+ * That is the whole reason offer_update() answers even when the installed
+ * version is already current. Staying silent there is how a plugin ends up
+ * unable to auto-update while looking perfectly configured — so this asserts
+ * the outcome, not the intention.
+ *
+ * The feed stays stubbed through the transient above: this is about what
+ * WordPress does with our answer, and a test that needs the internet fails for
+ * reasons that have nothing to do with it.
+ */
+// The cache must not outlive WordPress's own check cadence. It gates by screen
+// — one minute on Dashboard → Updates, one hour on the Plugins screen — and
+// this filter only runs when that check runs, so anything longer here hides a
+// new release underneath a cache the shop owner cannot see. This was six hours
+// and produced exactly that: a release published, and a shop shown nothing.
+wc_edm_ok(
+	'the cache is shorter than the interval WordPress re-checks on',
+	WC_EDM_Updater::TTL <= 15 * MINUTE_IN_SECONDS,
+	'TTL is ' . WC_EDM_Updater::TTL . 's; WordPress re-checks every 60s on Dashboard → Updates'
+);
+
+// "Check again" must discard the cache, or the button lies: someone
+// who has just published a release clicks it, sees nothing, and concludes the
+// whole mechanism is broken.
+set_transient( WC_EDM_Updater::TRANSIENT, array( 'version' => '1.0.0', 'package' => 'x', 'url' => 'x', 'tested' => '' ), 600 );
+wp_set_current_user( 1 );
+$_GET['force-check'] = '1';
+wc_edm()->updater->forget_on_force_check();
+unset( $_GET['force-check'] );
+wc_edm_ok( 'Check again discards the cached feed', false === get_transient( WC_EDM_Updater::TRANSIENT ) );
+
+// And a visitor with no business updating plugins does not get to clear it.
+set_transient( WC_EDM_Updater::TRANSIENT, array( 'version' => '1.0.0', 'package' => 'x', 'url' => 'x', 'tested' => '' ), 600 );
+wp_set_current_user( 0 );
+$_GET['force-check'] = '1';
+wc_edm()->updater->forget_on_force_check();
+unset( $_GET['force-check'] );
+wc_edm_ok( 'but a caller who cannot update plugins does not clear it', is_array( get_transient( WC_EDM_Updater::TRANSIENT ) ) );
+delete_transient( WC_EDM_Updater::TRANSIENT );
+
+// Rendering the list table in a CLI context makes core itself emit a
+// strlen(null) deprecation from class-wp-plugins-list-table.php. It is
+// WordPress's, not ours, which is why the deprecation check filters on this
+// plugin's directory rather than failing on everything it sees.
+// Primed again deliberately. The force-check assertions above deleted it, and
+// without this offer_update() makes a real HTTP request — which passes only
+// because this plugin's feed repo happens to be public. That would make the
+// assertion measure the environment rather than the code under test.
+set_transient(
+	WC_EDM_Updater::TRANSIENT,
+	array(
+		'version' => WC_EDM_VERSION,
+		'package' => 'https://gitea.nolimit.dk/kw/demo/releases/download/v1/demo.zip',
+		'url'     => 'https://gitea.nolimit.dk/kw/demo',
+		'tested'  => '7.1',
+	),
+	600
+);
+
+delete_site_transient( 'update_plugins' );
+wp_update_plugins();
+$transient = get_site_transient( 'update_plugins' );
+$basename  = plugin_basename( WC_EDM_PLUGIN_FILE );
+
+wc_edm_ok(
+	'WordPress files the plugin under response or no_update',
+	isset( $transient->response[ $basename ] ) || isset( $transient->no_update[ $basename ] ),
+	'in neither, so wp-admin would say "Auto-updates are not available for this plugin"'
+);
+
+// And the list table itself, which is what the shop owner actually looks at.
+require_once ABSPATH . 'wp-admin/includes/class-wp-list-table.php';
+require_once ABSPATH . 'wp-admin/includes/class-wp-plugins-list-table.php';
+wp_set_current_user( 1 );
+set_current_screen( 'plugins' );
+
+$table = new WP_Plugins_List_Table( array( 'screen' => get_current_screen() ) );
+$table->prepare_items();
+
+$row = null;
+foreach ( $table->items as $file => $data ) {
+	if ( $file === $basename ) {
+		$row = $data;
+	}
+}
+
+wc_edm_ok( 'the plugin is on the Plugins screen at all', null !== $row );
+wc_edm_ok(
+	'and WordPress marks it as supporting updates',
+	$row && ! empty( $row['update-supported'] ),
+	'without this the auto-update column reads "Auto-updates are not available for this plugin."'
+);
+
 delete_transient( WC_EDM_Updater::TRANSIENT );
 
 /* --------------------------------------------------------------- verdict -- */
 
 echo "\n";
-if ( $wc_edm_failures > 0 ) {
-	printf( "%d assertion(s) failed on WordPress %s.\n", $wc_edm_failures, get_bloginfo( 'version' ) );
+if ( $GLOBALS['wc_edm_failures'] > 0 ) {
+	printf( "%d assertion(s) failed on WordPress %s.\n", $GLOBALS['wc_edm_failures'], get_bloginfo( 'version' ) );
 	exit( 1 );
 }
 printf(

woocommerce-email-discount-manager.php

@@ -1,11 +1,12 @@
 <?php
 /**
  * Plugin Name: WooCommerce Email Discount Manager
- * Plugin URI:  https://gitea.nolimit.dk/kw/woocommerce-email-discount-manager
- * Update URI:  https://gitea.nolimit.dk/kw/woocommerce-email-discount-manager
+ * Plugin URI:  https://gitea.nolimit.dk/kw/woo-discount-manager
+ * Update URI:  https://gitea.nolimit.dk/kw/woo-discount-manager
  * Description: Apply discounts and show/hide shipping methods based on the customer's email address (full address, domain or partial match).
- * Version:     1.4.0
- * Author:      WEDSMP
+ * Version:     1.4.6
+ * Author:      Kristian Wind
+ * Author URI:  https://gitea.nolimit.dk/kw
  * License:     GPL-2.0-or-later
  * Text Domain: wc-email-discount
  * Requires at least: 5.8
@@ -27,7 +28,7 @@ if ( ! defined( 'ABSPATH' ) ) {
 	exit;
 }
 
-define( 'WC_EDM_VERSION', '1.4.0' );
+define( 'WC_EDM_VERSION', '1.4.6' );
 define( 'WC_EDM_PLUGIN_FILE', __FILE__ );
 define( 'WC_EDM_PLUGIN_DIR', plugin_dir_path( __FILE__ ) );
 define( 'WC_EDM_PLUGIN_URL', plugin_dir_url( __FILE__ ) );