AuctionForge

[3.7.1.22] — 2026-07-25

Fixed — Lot::countLots() loaded the entire lot catalogue to produce one integer

inc/model/Lot.php built its query with 'numberposts' => -1 and then returned

count(get_posts($args)). That materialises every matching lot as a full WP_Post

object — priming the post-meta and term caches for all of them — purely to arrive at

a row count.

The caller makes it worse: ajax/LotListAjax.php returns only 5 lots per request

and calls countLots() alongside them just to render a total. So a "give me 5 lots"

AJAX request could load the whole catalogue.

It has been dormant rather than harmless. The query also filters on the featured

meta flag (Lot::VIEW_HOMEPAGE_BS), which currently matches only 0–11 lots on every

site measured, so the cost never materialised. It would have appeared the moment

anyone bulk-flagged lots as featured on a site holding thousands of them. Measured on

two live sites with the flag filter removed to expose the worst case:

| lots | before | after |

|---|---|---|

| 18,718 | 113.5 MB, 0.78 s | 0.0 MB, 0.01 s |

| 12,850 | 76.5 MB, 0.60 s | 0.0 MB, 0.01 s |

Now uses WP_Query with posts_per_page => 1, fields => 'ids' and

update_post_meta_cache/update_post_term_cache disabled, returning found_posts.

get_posts() cannot be used for this: it forces no_found_rows => true, which

discards the very total required. This is the pattern templates/page_auction.php

already used ($countLots = $wp_query->found_posts;), so the two call sites now agree.

The filter arguments are byte-identical — the BP_QUERY/bp_field meta filter,

suppress_filters => false and the Polylang branch are untouched — so the returned

number cannot change. Verified on three live sites: old and new implementations and

the live method all returned the same count (11, 7 and 0 respectively).

[3.7.1.21] — 2026-07-25

Fixed — Webhook item updates never purged the page cache

inc/sync/ItemUpdateWorker.php stage 5 ("Clearing cache") called only HummingbirdSupport::clearCacheByUrl() and Auction::doClearCacheForAuctionPages(). Both are Hummingbird-only, so on any site without that plugin — which is all of them on the current hosting stack — the entire stage was a no-op: Cloudflare, nginx FastCGI and LiteSpeed were never told about the change. Item updates arriving by BidSpirit webhook therefore left stale cached pages behind.

It also passed the wrong id. Lot::getId() returns the BidSpirit lot id (it is loaded straight off the API payload), not the WP post id, so get_permalink() was resolving a nonexistent post and the log line reported a bogus post #17471 for what was actually post 13620. Stage 5 now resolves the real post id through bp_meta_data (the authoritative lot↔post join, matched on lot + auction + language and widening if needed) and routes the purge through CachePurge::purgeLot(), so every configured cache layer is invalidated. The log line reports the resolved post, or says plainly that it could not be resolved.

Fixed — A cache dir that cannot be reached now reports itself instead of failing silently

inc/controllers/NginxCacheSupport.php skipped the file-deletion purge whenever the configured cache directory was unreachable, and said nothing. Because isConfigured() only tests that af_nginx_cache_dir is non-empty — never that it is reachable — CachePurge would call in, the purge would delete nothing, and the caller could not tell success from failure.

This is not hypothetical: aaPanel writes open_basedir=/www/wwwroot/<site>/:/tmp/ into each site's .user.ini, while the shared FastCGI cache lives at /www/server/fastcgi_cache — outside it. Every purge silently no-op'd and pages stayed stale until fastcgi_cache_valid expired (24h by default). It went unnoticed for days because .user.ini is PHP_INI_PERDIR and is read only by the FPM/CGI SAPI — WP-CLI ignores it, so wp eval purge tests passed while the real web and webhook paths failed.

Now every rejection path (outside open_basedir, missing, or not writable) logs one clearly-worded line per request via the new noteCacheDirFault(), records the fault in the af_nginx_purge_error option, and raises a notice-warning in wp-admin telling the site owner exactly which directory is unreachable and why. The flag clears itself the moment a purge succeeds. A new public NginxCacheSupport::purgeHealth() returns the same state for support tooling without attempting a purge. purgeByFile() also checks reachability up front, so a blocked path no longer sprays raw open_basedir restriction in effect warnings into the error log.

No schema, option-format or config-version change; existing af_nginx_* settings are untouched.

[3.7.1.20] — 2026-07-24

Fixed — auto_commit_disabled left autocommit off, so sync jobs never committed 'completed'

On sites with the Auto commit mysql disabled option ON, inc/import/InsertLotsBS.php::init() issued SET autocommit = 0 before importing lots but never restored autocommit = 1 after its final COMMIT. The database connection was left mid-transaction, so the sync worker's subsequent SyncQueue::complete() status UPDATE was never committed — it rolled back when the request ended. The lot data persisted (it is committed in per-batch chunks inside the import), but every catalog_sync / item_update job stayed processing until the stuck-job watchdog marked it failed, so the Sync Status dashboard showed unbroken failures even though the catalog was mostly current.

Observed in the wild on a site where catalog_sync was 0-for-326 and no job of any type had completed in ~4 weeks; the lots were present (560/560) but no job ever reached completed. init() now runs SET autocommit = 1 immediately after its final COMMIT, so the caller's writes — the job-status update in particular — commit normally. (Setting autocommit = 1 also implicitly commits any still-open transaction, so this is doubly safe.) Sites with the option off (the default) never entered this path and are unaffected. No schema or config-version change.

[3.7.1.19] — 2026-07-24

Fixed — Category-filtered listings emitted invalid SQL and returned zero lots

inc/controllers/BidspiritQuery.php::bp_query_where() builds the bpMeta WHERE clause for AuctionForge listing queries. Many callers pass bp_index purely as a truthy JOIN marker — array(1) (see inc/shortcodes/LotsByCategory.php, inc/model/Lot.php, inc/helpers/BS_API.php) — meaning "join the bp_meta_data table so I can filter by bp_field/term_id", with no itemIndex constraint. The reader tried to interpret that positional array(1) as an associative ["compare"]/["value"] clause, always resolving compare to "" and value to 0, and emitted:

```

CAST(bpMeta.itemIndex AS UNSIGNED) 0

```

— a comparison with no operator, which MariaDB rejects as a syntax error. Because this ran inside posts_where on the main listing query, the *entire* query failed: category-filtered catalog pages and the bp_lots_by_category widget returned no lots, and every render logged WordPress database error You have an error in your SQL syntax … near '0 ) AND ( bpMeta.\categoryId\ = … )' (66,000+ entries on the dev site since 2026-03-26).

The itemIndex branch now only emits a CAST(...) {compare} {value} clause when a comparison operator is actually present; when bp_index is just a JOIN marker it emits a 1=1 no-op so the wrapping AND ( … ) stays valid, leaving the real filtering to term_id/bp_field. The between range branch (used by day-range queries with explicit >=/<=) and the bp_id branch are unchanged. Verified on dev: the previously-failing bp_index=array(1) + categoryId query now produces valid SQL (AND ( 1=1 ) AND ( bpMeta.\categoryId\ = 717 )) and returns matching lots with no DB error. No schema or config-version change.

*(Latent parallel: the bp_id branch dereferences ["compare"] without an emptiness guard too; not currently triggered in the wild, noted for a future hardening pass.)*

[3.7.1.17] — 2026-07-24

Fixed — Catalog sync auction-published push fataled with "Cannot use stdClass as array"

inc/controllers/AuctionsAPI.php::auctionPublishedPush() read the localized auction name with $obj->auctionsInfoByLang[$langCode] — an array subscript on a value that arrives from the BidSpirit webhook as a stdClass (the payload is decoded as objects, exactly as the surrounding sync code already treats itemsByLanguage). Under PHP 8 this threw an uncaught Error: Cannot use object of type stdClass as array, returning HTTP 500 to POST /wp-json/bidspirit/v1/sync so the auction-published push — and the sync request carrying it — failed. It is now read with a null-safe object access (isset($obj->auctionsInfoByLang->{$langCode})), falling back to the auction number when the localized info is absent, and degrades quietly whether the field is an object, an array, or missing. No schema or config-version change.

Fixed — nginx FastCGI cache purge logged open_basedir Warnings and silently failed under restricted sites

inc/controllers/NginxCacheSupport.php::safeCacheDir() called is_dir() / is_writable() directly on the configured cache directory. On aaPanel-hosted sites whose open_basedir is restricted to their own docroot + /tmp — while af_nginx_cache_dir points at the shared /www/server/fastcgi_cache — every auction/lot purge emitted PHP Warning: … open_basedir restriction in effect and the direct-file-deletion purge silently did nothing. safeCacheDir() now checks the target against the active open_basedir first (new dirWithinOpenBasedir() helper) and returns quietly when it is unreachable, suppressing any residual stat warning. Sites with no restriction (or whose cache dir is inside open_basedir) are unchanged. Sites that cannot reach the cache dir directly should use the ngx_cache_purge URL method (AF_NGINX_PURGE_URL) or add the cache path to open_basedir. No schema or config-version change.

---

[3.7.1.16] — 2026-07-24

Fixed — Auction pages white-screened (HTTP 500) when an auction had no auction_days

templates/page_auction.php read the auction_days term meta into $auctionDays and immediately called count($auctionDays) (and iterated it with foreach). For any auction whose auction_days meta was unset, getTermOption() returns null, so count(null) threw an uncaught TypeError: count(): Argument #1 ($value) must be of type Countable|array, null given under PHP 8 — returning a 500 white-screen to visitors and search-engine crawlers hitting that auction page. $auctionDays is now normalised to an array (if (!is_array($auctionDays)) { $auctionDays = []; }) immediately after it is read, so the count(), the foreach, and the day-index lookups below are all safe when no schedule is present. Auctions with valid single- or multi-day schedules are unchanged. No schema or config-version change.

---

AuctionForge Changelog

All notable changes to the AuctionForge plugin are documented in this file.

---

[3.7.1.12] — 2026-07-20

Fixed — Open-invoices banner ignored the "Enable My Invoices tab" setting

The site-wide "⚠ This account has open invoices / Pay Now" banner rendered for logged-in users with unpaid BidSpirit bills even on sites where the My Invoices profile tab is disabled — and its "Pay Now" button linked to #bp-bills, a tab that does not exist on those sites, so it led nowhere. checkUnpaidBillsBanner() had no gate on the setting.

BidspiritViews::bp_footer() now emits window.afBillingTabEnabled, computed from the same enable_billing_tab expression that gates the tab markup in profile-templates.php (so banner and tab can never disagree), and checkUnpaidBillsBanner() returns immediately when it is false — no banner, and no bills/getUnpaidBills / unpaid-status AJAX traffic on such sites. Sites with the tab enabled are unchanged. No schema or config-version change.

Fixed — US auction houses resolved to the UK "Catalogue" dialect in Auto mode (regression)

Restores the address-signature detection that was lost in an earlier merge (originally fixed 2026-06-26, silently reverted by a later version sync). US house addresses typically name no country and end in "City, ST 12345", so Dialect::captureRegionFromAuctions() took the "ST 12345" tail as an unknown country name and resolved UK. countryToDialect() now takes the full address and recognises a US state code + 5-digit ZIP tail (const US_STATE_CODES, uppercase-only match), plus a bare trailing ZIP with a $ currency as a secondary signal. Conservative by design: named countries still resolve UK — Canadian ("ON M5V 3L9") and Australian ("WA 6000", 4-digit postcode) tails cannot match the 5-digit requirement.

Fixed — LiteSpeed cache purges during sync stacked "Purge url" admin notices

CachePurge purged per-lot URLs via the public litespeed_purge_url action, which calls Purge::purge_url() with $quite=false and enqueues a dismissible admin notice per URL — a full-auction sync stacked hundreds of "Purge url …" notices on the next wp-admin page and looked like a fault to clients. Purges now call \LiteSpeed\Purge::cls()->purge_url($u, false, true) directly (identical purge, no notice), falling back to the action when the class is unavailable. Manual purges elsewhere keep their confirmations.

Fixed — Sync log wrote one row per skipped auction

LotList::updateData() logged " Skipping auction N (excluded or not matched)" for every excluded auction on every worker run — the dominant source of af_sync_log table growth on multi-house sites (observed in the GBs fleet-wide). It now counts the skips and writes a single "Skipped N/M auctions (excluded or not matched)" summary line per run. The per-auction detail remains available via Debug::logData().

Housekeeping

Removed stray .bak working files (auctionforge.php.bak-*, readme.txt.bak-verbump, app.js.prephonebypass-*.bak, CachePurge/BidspiritViews backups) that had been shipping inside the plugin tree since 3.7.1.4.

[3.7.1.11] — 2026-07-20

Added — "Auction is live" popup on single-lot pages

When BidSpirit reports an auction as live, single-lot pages now show the "Auction is live — Enter live auction" popup (linking to the BidSpirit bidding console), exactly as auction catalogue pages already did. Previously a one-lot auction had no live indication anywhere on the site, because its catalogue URL redirects straight to the lot page and only the catalogue code path surfaced the live state. (Entry backfilled — 3.7.1.11 shipped with this note in readme.txt only. 3.7.1.10 was an internal bump with no separate changes.)

[3.7.1.9] — 2026-07-14

Fixed — Catalog pagination stayed broken for returning visitors (stale session)

Follow-up to 3.7.1.8. That fix stopped *new* sessions from getting a bad per-page baseline, but a returning visitor whose session already held the old baseline (the session cookie lives 24h) kept getting page 2+ reset to page 1 at any non-default items-per-page — only a full "clear site data" (which drops the session cookie) fixed it for them.

The server no longer resets pagination from session state at all. Per-page changes already return to page 1 on the client (the items-per-page dropdown navigates to the page-1 URL), so the session-based reset in BidspiritLots::search_filter() and bidspirit_lot_per_page() was both redundant and the source of the stale-baseline problem — it has been removed. Pagination is now correct for every visitor (new or returning, any session state) on the next page load, with no cache/cookie clearing required. No schema or config-version change.

[3.7.1.8] — 2026-07-14

Fixed — Catalog pagination broke at any non-default "Items per page"

On auction catalog pages, setting Items per page to any value other than the site's WordPress default (posts_per_page) made page 2 and beyond redirect straight back to page 1 — so it appeared to "show the same lots" — while the value matching the default worked. BidspiritLots::bp_session_starter() seeded the per-page change-detection baseline from get_option('posts_per_page'); because auction pages are served from full-page cache / behind a CDN that drops the PHP session cookie, that baseline reset to the default on every request, so any non-default size looked "just changed" on every page load and was force-redirected to page 1 by maybe_redirect_to_first_page().

The baseline is now seeded to null ("unknown previous value"), matching the existing category/search baselines, so a page reset only fires when a genuinely-known prior per-page value differs (isset && !== null && !=). The items-per-page dropdown additionally returns to page 1 client-side, so "change size → page 1" no longer depends on the session. No schema or config-version change.

[3.7.1.7] — 2026-07-13

Added — Per-house toggle to bypass phone verification (UK houses auto-bypass)

BidSpirit's users/phone/sendPhoneVerificationCode returns a generic UNKNOWN_ERROR for UK houses (e.g. rosanreeves, edwards) even for valid +44 mobiles, because SMS/phone-verification is not provisioned on those BidSpirit accounts. As the requirement is enforced only plugin-side, this left UK bidders unable to bid.

A new per-house setting require_phone_verification (in the bidspirit_settings option) makes the client-side bid gate conditional:

• auto (default) — enforce EXCEPT on UK houses (Dialect::isUk()), which are bypassed while their BidSpirit accounts lack SMS provisioning.
• off — never enforce (per-house override, e.g. wp option patch update bidspirit_settings require_phone_verification off).
• on — always enforce.

BidspiritViews::bp_footer() emits window.afRequirePhoneVerification; both bid gates (submitBid, submitBidCatalog) and the profile “Verify phone” CTA honour it. Fails closed (enforces) when the flag is absent. No schema or config-version change.

---

[3.7.1.2] — 2026-06-30

Fixed — Background sync worker spawn timing out ("Worker spawn HTTPS failed: cURL error 28")

On busy or memory-pressured hosts the background sync worker frequently failed to start, logging Worker spawn HTTPS failed: cURL error 28: Operation timed out after 5002 milliseconds with 0 bytes received (observed ~29×/day on one site). SyncQueue::spawnWorker() triggers the worker with a blocking loopback HTTP request to the site's own REST endpoint; the timeout was hard-coded to 5 seconds, so whenever the site's own backend took longer than 5s to respond (DB/FPM contention) the spawn aborted *as a hard error* and raised a sync alert — even though the site was up and serving.

Three changes make the spawn resilient:

• Configurable, longer timeout. The 5s hard-coded timeout is now 15s by default, overridable via the AUCTIONFORGE_WORKER_SPAWN_TIMEOUT constant or the auctionforge_worker_spawn_timeout filter.
• Scheme-matched loopback. Strategy 1 now issues the 127.0.0.1 loopback using the site's own scheme (https when the site is https) instead of always http. Previously an http→https redirect (301) made the loopback look like a failure and forced the slower public-URL fallback; the POST now reaches the worker endpoint directly.
• Non-blocking best-effort fallback. If both blocking attempts can't confirm a start within the timeout, the worker is now triggered with a final non-blocking (fire-and-forget) request, logged at warning instead of error. A merely-slow backend still starts its worker, the hourly SafetySync cron re-spawns if it genuinely didn't, and the condition no longer raises a hard sync alert.

No schema, DB, or config-version change. Behaviour is unchanged on healthy hosts (the loopback still returns 2xx immediately); the new paths engage only when the backend is slow. The underlying slow backend was a server-side issue (MariaDB query-cache lock contention + memory pressure) fixed at the infrastructure level; this release hardens the plugin so a transiently slow backend can no longer turn into a failed sync.

---

[3.7.1.1] — 2026-06-29

Added — Active uptime monitoring via Kuma keyword health marker

The keepalive mu-plugin now emits an invisible <!-- af-health:ok --> marker into every rendered front-end page (hooked on wp_head and wp_footer, emitted once per request, pure echo — no DB/IO, lands inside cached HTML). Uptime Kuma monitors each site by pulling the homepage and asserting the marker is present, which measures real user-facing availability (DNS + TLS + nginx + PHP + WordPress + DB + render) instead of the old push-heartbeat model that only measured whether WP-Cron was firing — and routinely false-flagged perfectly healthy sites as down (the worst offenders flapped 50–60×/day while serving HTTP 200 the entire time).

Because the marker lives in the mu-plugin (which WordPress can't deactivate and AuctionForge re-asserts on every load), it reflects "WordPress is rendering pages" independently of AuctionForge's own activation state, and it survives failed or in-progress plugin updates. The bundled keepalive template is bumped to 1.3.0, so the installer rewrites wp-content/mu-plugins/auctionforge-keepalive.php on update. The legacy push heartbeat is retained in this release for a safe transition to active monitoring.

---

[3.7.0.43] — 2026-06-22

Fixed — Submission "Need help?" contact was hardcoded (one tenant's details on every site)

The vehicle-submission help panel (templates/js-chunks/submissions.php) rendered a single hardcoded email and phone, so every AuctionForge site displayed the same contact regardless of which auction house it was — e.g. one tenant's info@absoluteclearance.co.uk / 01536 674804 showed on unrelated sites.

The panel now resolves the contact dynamically, in priority order:

• apply_filters('auctionforge_help_email', '') / apply_filters('auctionforge_help_phone', '') — explicit per-site override (any source, e.g. a theme/global/Elementor setting);
• otherwise the SEO & AEO Optimizer LocalBusiness details stored in the seo_aeo_options option (local_email / local_phone);
• if neither yields a value the corresponding row is omitted, and the whole "Need help?" block is hidden when no contact is available — so no placeholder or wrong-tenant detail is ever shown.

Internal

• Modified: templates/js-chunks/submissions.php — replaced the two hardcoded <p> contact values with filtered, esc_html-escaped values resolved from seo_aeo_options, each row guarded by an if.
• Modified: auctionforge.php — plugin header → 3.7.0.43.
• No database schema change (AUCTIONFORGE_DB_VERSION unchanged at 25).

---

[3.7.0.42] — 2026-06-22

Fixed — Submission templates emitted extra <h1>s and placeholder content site-wide

The vehicle-submission view (templates/js-chunks/submissions.php) is rendered on wp_footer on every page, so its <script type="text/template"> chunks shipped into the source of all pages. Two of those chunks used <h1> headings ("Submit your vehicle for auction" and "Detail received successfully"), meaning every page's HTML source contained three <h1> elements. While these live inside inert <script> templates (so a DOM-rendering crawler like Googlebot still resolves a single true H1), raw-source SEO tooling and some AI crawlers flag the duplicates, and the templates also shipped vendor placeholder text.

• Both template headings demoted from <h1> to <h2> — a single H1 per page in source.
• Replaced Lorem-ipsum placeholder copy in the intro and progress panels with real submission guidance.
• Replaced the dummy "Need help?" contact details (support@domain.com / +3265464325) with the live business contact (info@absoluteclearance.co.uk / 01536 674804).

No functional/JS changes — template IDs and structure are unchanged.

---

[3.7.0.41] — 2026-06-19

Fixed — Duplicate auction terms (auction shown twice, catalogue split)

A newly published auction could be created twice in WordPress as two identical auction_number terms, so the auction rendered twice on the listing and its catalogue was split across the two copies (e.g. 145 lots stored as 144 + 1). The lot posts themselves stayed unique — this was a duplicate *auction*, not duplicate *lots*.

Root cause: auction terms are only created in Auction::save() via wp_insert_category, which inserts whenever the caller's lookup returned no term. That lookup (findAuctionByIdWithLang() → get_terms() meta_query) can return nothing for a brand-new auction when two syncs run concurrently — for example a full_sync_* bulk run (via BulkSyncWorker / AuctionList) overlapping a catalogue webhook. Both see "no term" and both insert one. The only fallback, findAuctionByNumber(), looks up by the auction *number* slug and never matched the real term slug, so it could not catch the miss. This path is not covered by the existing CatalogSyncWorker per-auction lock, which serialises catalogue syncs to prevent duplicate *lot posts* but does not guard *term* creation.

Auction::save() now, before inserting a term:

• acquires a per-auction MySQL advisory lock (GET_LOCK('<prefix>af_term_<auctionId>', 10)) so concurrent creators serialise — the loser then finds the just-created term and updates it instead of inserting a second one; and
• performs an authoritative, cache-bypassing lookup by auction_id (direct termmeta ⋈ term_taxonomy query) and switches to update-in-place when a term already exists.

Polylang-aware: under full multilingual support it only reuses a term in the requested language, so legitimate per-language terms are still created.

Internal

• Modified: inc/model/Auction.php — save() gains a pre-insert dedup guard; new private helpers findTermIdByAuctionId(), acquireTermLock(), releaseTermLock(). InstanceDB wraps the global $wpdb, so the advisory lock and the wp_insert_category insert share a single DB session (the same property that makes the existing CatalogSyncWorker lock effective).
• No database schema change (AUCTIONFORGE_DB_VERSION unchanged at 25).

---

[3.7.0.40] — 2026-06-14

Fixed — Lot "begin to close" countdown now shows minutes (and seconds in the final minute)

The lot-page countdown (#auctionStartTimer, the *"Auction will begin to close in …"* line) only ever rendered whole days and whole hours, and computed once on page load. With less than an hour to go it therefore read "0 days and 0 hours" — e.g. a lot closing at 20:00 looked like a dead/expired timer from 19:00 onwards, even though ~46 minutes remained. The time maths was correct; the widget simply had no sub-hour granularity and never ticked.

It now updates every second and shows the largest meaningful units, dropping leading zero units:

• 44 minutes • 3 hours and 20 minutes • 1 day, 2 hours and 5 minutes
• In the final minute it counts the seconds down (40 seconds → 1 second) so it never sits on a flat "0".
• Once the close time passes (result < 0) the timer hides itself, as before.

getCountdownText() now wraps the suffix in a .bp-start-countdown span so the script can rewrite the whole phrase; if that wrapper is ever absent (e.g. a stale page-cached markup), getLeftDate() falls back to the original days+hours behaviour rather than erroring — important because app.js also carries the live bidding logic.

Internal

• Modified: inc/controllers/Settings.php — getCountdownText() suffix wrapped in .bp-start-countdown.
• Modified: assets/js/app.js — getLeftDate() rewritten: 1s ticking via setInterval, days/hours/minutes/seconds, zero-unit omission, pluralisation, and a wrapper-missing fallback. This is the file actually served (front-end $jsFile is hardcoded to .js).
• Modified: src/js/app.js — same getLeftDate() change, to keep the gulp source in sync. app.min.js is intentionally not regenerated (unused — the unminified app.js is enqueued).
• Modified: auctionforge.php — plugin header → 3.7.0.40. (3.7.0.39 was present in the header with no changelog entry; this release supersedes it.)

---

[3.7.0.38] — 2026-06-02

Added — Spelling Dialect "Auto" mode (match the auction house region)

The Spelling Dialect setting (Settings → Appearance) gains a third option, "Auto — match the auction house region", which becomes the new default for sites that haven't chosen one:

• During the existing auction sync (getAllAuctions), Dialect::captureRegionFromAuctions() reads the auction house's country from the auction address (trailing segment; currency as a fallback) and stores the resolved dialect in the spelling_dialect_auto option. No API calls happen on page loads — it's a fixed, site-wide value refreshed each sync, so it's fully page-cache-safe.
• Mapping: US → Catalog; every other country → Catalogue (American "Catalog" is US-only; UK/IE/AU/NZ/CA/etc. use "Catalogue").
• The admin field shows what was detected, e.g. *"Detected region: United Kingdom → Catalogue."* United States and United Kingdom remain manual hard-overrides.

Default change: new/unconfigured sites now default to Auto (was UK). Until a site's first sync resolves the region, Auto falls back to UK, so behaviour is unchanged until detection kicks in — then it self-corrects (a US house starts showing "Catalog" automatically).

Internal

• Modified: inc/helpers/Dialect.php — auto mode, FALLBACK_DIALECT, countryToDialect(), captureRegionFromAuctions(); DEFAULT_DIALECT → auto.
• Modified: inc/import/AuctionList.php — capture the house region during the auctions sync.
• Modified: inc/controllers/Settings.php — Auto dropdown option + detected-region note.
• Modified: auctionforge.php — plugin header → 3.7.0.38.

---

[3.7.0.37] — 2026-06-02

Fixed — Per-lot "full price VAT" now drives the VAT statement

The standalone VAT line on lot pages (vat-and-commission → .vat-field) was keyed off the auction-house VAT rule, so it always read *"VAT: X% on item price and commission"* regardless of a lot's full-price-VAT toggle — and toggling a lot off didn't change it. It now branches on the live per-lot flag (itemInfo.item.fullPriceVat), matching the price-breakdown calc in getFullPriceInfo():

• Full-price VAT on → *"VAT: X% on item price and commission"* (VAT applied to hammer + commission)
• off (default) → *"VAT: X% on commission only"*

This only changes the wording to match the amount getFullPriceInfo() already computes per the toggle; the VAT figure itself was already correct. The separate renderVatField() "no VAT on commission" path is unchanged.

Internal

• Modified: templates/js-chunks/vat-and-commission.php — VAT statement branches on the per-lot fullPriceVat instead of houseCommissionVatRule.
• Modified: auctionforge.php — plugin header → 3.7.0.37.

---

[3.7.0.36] — 2026-06-02

A Site Statistics release: day-of-week analysis, an opt-in weekly email report, lot-focused "top pages", and several dashboard refinements.

Added — Day-of-week tabs on the hourly charts

The Hourly Distribution (Site Statistics → Overview) and Peak Viewing Times (Lot Analytics) charts now have a day tab strip — All days · Mon · Tue … Sun — each showing that weekday's total. Selecting a day redraws the 24-hour chart consolidated across every matching date in the range, so you can see *which days and times* visitors are active. The lot-analytics data already carried day_of_week; it was previously flattened to 24 hours and is now surfaced.

Added — Scheduled weekly email report (opt-in, off by default)

A new report under Site Statistics → Settings emails a polished weekly summary: headline KPI cards (Visitors / Pageviews / Sessions with this-week-vs-last-week change), a visitor journey funnel (Visitors → Viewed a lot → Left a bid), busiest hour for each weekday, and the week's most-viewed lots. Driven by a daily cron that sends once on a configurable weekday. Supports one or several recipients (comma/semicolon/space/newline separated, validated and de-duped) and a "Send test now" button that sends to whatever is currently in the Recipient(s) box. Built table-based with inline CSS for Gmail/Outlook/Apple Mail compatibility.

Added — New vs Returning visitors, auction markers, engagement funnel

• New vs Returning visitor KPI cards on the Overview (new = authoritative af_stats_visitors.first_seen within the period, joined so it can never exceed total visitors).
• Auction-date markers drawn on the *Traffic Over Time* chart (dashed lines + a captioned list) so traffic can be read against sale dates.
• Engagement funnel panel: Visitors → Viewed a lot → Viewed 5+ lots → Bidders (bidders from synced af_bid_events).

Changed — "Top pages" is now lot-focused ("Top Lots" / "Most viewed lots")

Both the dashboard Overview panel and the email now list the most-viewed individual lot pages only (/lot-…), excluding home, catalogue listing/pagination and profile pages as low-signal. Email page titles are shown in full (no mid-word truncation) with the site-name suffix stripped; the dedicated Pages tab remains the unfiltered drill-down.

Changed — Lot Analytics "Peak Viewing Times" honours the global date range

Previously hard-coded to the last 30 days; it now respects the dashboard's range picker. The Lot Analytics tab also auto-loads on first click (previously required a manual refresh).

Changed — Chart.js bundled locally

The Statistics and plugin dashboards loaded Chart.js from a CDN at two different versions (@4 and @4.4.1). Chart.js 4.4.1 is now bundled at admin/assets/js/chart.umd.min.js and loaded from the plugin (version-busted), so charts work offline / behind strict CSP and the version is pinned.

Internal

• Added: inc/stats/class-stats-report.php — AF_Stats_Report (weekly cron, recipient parsing, HTML builder, "send test" AJAX). admin/assets/js/chart.umd.min.js — bundled Chart.js 4.4.1.
• Modified: inc/stats/class-stats-ajax.php — hourly-by-DOW query; new_visitors, auction_events, funnel in the dashboard payload; lot-only top pages; global date range passed to peak times; weekly-email settings saved.
• Modified: inc/model/LotAnalytics.php — getPeakViewingTimes() accepts an explicit $from/$to range.
• Modified: inc/stats/class-stats-init.php — require + register AF_Stats_Report.
• Modified: admin/view/stats/dashboard.php — day-of-week tabs, KPI cards, auction-marker plugin, funnel, Top Lots, weekly-email settings UI + test button, local Chart.js.
• Modified: admin/view/dashboard.php — local Chart.js.
• Modified: auctionforge.php — plugin header → 3.7.0.36.

---

[3.7.0.35] — 2026-06-02

Added — Regional spelling dialect ("Catalog" US / "Catalogue" UK)

A new Spelling Dialect dropdown at the top of Settings → Appearance lets each site choose how the word "catalog" is presented on the public front end:

• United States — Catalog — US spelling (the plugin's original authored wording).
• United Kingdom — Catalogue — UK spelling.

When UK is selected, every front-end occurrence is rewritten — *"Catalogue will be available soon"*, *"View catalogue"*, *"Catalogue Coming Soon"*, *"Download catalogue"*, *"Back to the catalogue"*, the lot-page Catalogue tab, and the "catalogue published" app notification.

How it works. Every user-facing catalog string already passes through the auctionforge text domain (__()), so the swap is implemented as a single gettext / gettext_with_context filter rather than by editing template files. Dialect::toUk() rewrites whole words only, preserving case and pluralisation (Catalog→Catalogue, View catalog→View catalogue, CATALOG→CATALOGUE, Catalogs→Catalogues), and is idempotent. The filter is front-end only (is_admin()-guarded, with a wp_doing_ajax() exception so front-end AJAX is still covered) and is scoped to the auctionforge domain, so it never touches WordPress core, the theme, or other plugins. Code identifiers, option keys (catalog_layout, bids_in_catalog), CSS classes (af-catalog-sidebar, catalog-section, bp-back-to-catalog-button) and JS variables are all left intact. On US sites the filter is not registered at all, so there is zero added overhead.

Internal

• Added: inc/helpers/Dialect.php — Dialect helper: get()/isUk() (reads the spelling_dialect option, default UK), word() for non-translated strings, the case/plural-preserving toUk() transform, the gettext filter callbacks, and register() (no-op on US sites).
• Modified: inc/coreIncludes.php — require Dialect.php and call Dialect::register() at plugin load.
• Modified: inc/controllers/Settings.php — use the Dialect helper; add the "Regional Spelling" sub-heading and Spelling Dialect field at the top of the Appearance section, plus the fill_bidspirit_options_spelling_dialect() renderer. The value persists through the existing bidspirit_settings option and sanitize callback.
• Modified: auctionforge.php — plugin header → 3.7.0.35.

Note for existing sites. The default dialect is UK ("Catalogue"). Any site that upgrades without an explicit spelling_dialect value will therefore display "Catalogue" on the front end. Sites that should keep US spelling must set Settings → Appearance → Spelling Dialect to United States — Catalog (stored as spelling_dialect = us). Admin labels are unaffected in either dialect.

---

[3.7.0.34] — 2026-05-30

Fixed — Duplicate lot posts created by concurrent catalog syncs for the same auction

When two catalog-sync jobs for the same auction ran at the same time, every lot was imported twice and the front-end showed each lot as a pair (the second post taking a -2 slug). Observed on a live sale: 157 lots became 313 published lot posts.

Root cause. Two BidSpirit webhooks arriving in the same second (e.g. CATALOG_PUBLISHED + AUCTION_CATALOG_UPDATED) each enqueue a catalog_sync. SyncQueue::enqueue() deduplicates with a non-atomic *SELECT-then-INSERT* (no DB unique constraint), so two simultaneous calls both pass the "already pending?" check and both jobs land in the queue. Job *claiming* is atomic per-job, but nothing serialised two different jobs for the same auction, so two workers ran concurrently. The matcher Lot::findByBSMeta() only sees committed publish/draft posts, so during the overlapping insert windows each worker saw "no existing post" for every lot and inserted a fresh full set. Worse, findByBSMeta does GROUP BY lotId, so the resulting duplicate pair is collapsed to a single row in every later sync — the importer never detects or repairs it, and the count($datum) > 1 "Double" guard in InsertLotsBS::init() is effectively dead code.

Fix. CatalogSyncWorker::process() and processDayEnded() now take a per-auction MySQL advisory lock (GET_LOCK('<prefix>af_sync_<auctionId>', 0)) around the API-fetch + post-insertion work. If another worker already holds the lock for that auction, the duplicate job logs concurrent-lock busy and returns cleanly — marked completed, since the in-flight sync already covers the work — instead of racing. The lock is held on the worker's own DB connection and auto-releases if the process dies, so it can never deadlock the queue. This serialises all catalog and day-ended processing per auction no matter how many duplicate jobs reach the queue.

Internal

• Modified: inc/sync/CatalogSyncWorker.php — new acquireAuctionLock() / releaseAuctionLock() helpers; process() and processDayEnded() acquire the lock up front (skip-on-busy) and release it in a finally.
• Modified: auctionforge.php — plugin header → 3.7.0.34.

Note for existing sites. This prevents *new* duplicates; it does not remove ones already created. To find them, look for published lot posts where two share one BidSpirit lot id (bp_meta_data.id). Keep the most-recently-synced post per lot id and set the rest to post_status = 'trash' — the lot post type has trash disabled, so do it via SQL, and do not use draft (which findByBSMeta still matches). Then recount the auction_number term and clear caches.

---

[3.7.0.33] — 2026-05-30

Fixed — auctionforge_sync_lots cron never scheduled (Lots push to wpdeploy silently stopped)

AF_Lots_Sync uses the custom bp_ten_minutely schedule. The sync crons were registered from AF_Stats_Init::init(), which runs at plugin-load time — *before* auctionforge.php adds bp_ten_minutely to the cron_schedules filter further down the same file. So wp_schedule_event(time(), 'bp_ten_minutely', 'auctionforge_sync_lots') ran against an unknown schedule, failed silently, and left the hook permanently unscheduled. The other four sync hooks use core's hourly and were unaffected — which is why only the Lots push to wpdeploy went stale (observed: 3 days with no push while every other stream ran on time). Fixed by deferring the sync register() calls to the init hook, by which point every custom schedule is registered. The hook self-arms on the next request after upgrade.

Fixed — Safety Sync admin run reported a false "Request failed (HTTP 200)"

auctionforge_ajax_run_cron_task returns its result as JSON, but a stray PHP notice/deprecation emitted by a task (e.g. the Safety Sync BidSpirit delta-check on PHP 8.1) printed into the response body ahead of the JSON, so the browser couldn't parse it and the modal showed a misleading "Request failed (HTTP 200)" even though the task succeeded. The handler now buffers task output, discards it before emitting JSON, and logs any suppressed output via SyncLogger (context admin) so the offending notice can still be found and fixed at the root.

Added — "Clear duplicate cron events" button on Sync Status

The one-shot AF_Cron_Cleanup migration only runs once per site, so per-hostname duplicate events created by an older build *after* the migration had already marked itself done were never swept. New AF_Cron_Cleanup::force_sweep() runs the same sweep on demand, exposed via a Clear Cron Dupes button in the Sync Queue toolbar (AJAX auctionforge_clear_cron_dupes). It removes legacy-args duplicates of the four per-hostname hooks plus the two orphan hooks, keeping one clean event each.

Internal

• Modified: inc/stats/class-stats-init.php — sync register() calls wrapped in add_action('init', …, 20).
• Modified: inc/maintenance/class-cron-cleanup.php — new public force_sweep() reusing the existing sweep helpers.
• Modified: auctionforge.php — auctionforge_ajax_run_cron_task() output-buffered against stray output; new auctionforge_ajax_clear_cron_dupes() handler + registration; plugin header → 3.7.0.33.
• Modified: admin/view/sync-status.php — added the "Clear Cron Dupes" button and handler.

Note: with all scheduling now arg-free (3.7.0.28+), the duplicates do not regenerate once swept; a canonical-hostname redirect (www ↔ apex) at the web-server level remains good hygiene but is no longer required to keep the cron table clean.

---

[3.7.0.32] — 2026-05-30

Fixed — V3 sync worker never spawned on some hosts (silent import stall)

On some sites (confirmed on a LiteSpeed/cPanel install) the V3 queue worker never actually started, so catalog lots were staged into import_history but never converted to WordPress posts — postId IS NULL, syncFinished = 0, syncTimes = 0, and no errors logged. Clearing the queue and reprocessing re-stalled immediately.

Root cause. SyncQueue::spawnWorker() starts the worker by POSTing the REST route /wp-json/auctionforge/v1/sync-worker. It tried an HTTP loopback to http://127.0.0.1/ with the site's Host: header first, and the success test was if (!is_wp_error($result)) — it never inspected the HTTP status code. On hosts where 127.0.0.1 + Host header resolves to the wrong vhost (or the route is blocked), that request returns 404/403, which is not a WP_Error. The old code therefore treated the 404 as a successful spawn, logged Spawned … (HTTP 404), returned true, and never reached the HTTPS fallback. The worker never ran; nothing drained the queue or the staging table. Sites whose 127.0.0.1 loopback resolves correctly returned 200 and were unaffected — which is why this was host-specific.

Fix. spawnWorker() now reads the response code and only treats 2xx as a successful spawn. On any non-2xx (or a WP_Error) from the loopback it logs a warning and falls through to the rest_url() HTTPS path, which is likewise status-checked. A new constant short-circuits the doomed attempt on known-bad hosts:

```php

define('AUCTIONFORGE_WORKER_SKIP_LOOPBACK', true); // wp-config.php — skip 127.0.0.1, go straight to HTTPS

```

Added — Automatic staging recovery on the safety cron

The hourly auctionforge_sync_safety cron previously only spawned a worker when the queue had pending jobs. Lots that were staged into import_history but left unconverted (e.g. after a worker died, or while the spawn bug above was in effect) had no queue job attached, so nothing ever picked them up. The safety cron now also checks SyncQueue::stagingBacklogCount() and, when it is non-zero, kicks the staging processor (non-blocking) to convert the backlog into posts — making the pipeline self-healing without manual intervention.

Added — "Process Staging" button on Sync Status

A new Process Staging button in the Sync Queue toolbar (Lots → Sync Status) runs InsertLotsBS over the staging table on demand — for when lots are staged but not appearing on the site. It fires non-blocking and switches the Live Console into fast-poll so the operator can watch posts being created in batches of 50.

Internal

• Modified: inc/sync/SyncQueue.php — spawnWorker() rewritten with HTTP-status-aware fallback + AUCTIONFORGE_WORKER_SKIP_LOOPBACK support; triggerStagingProcessor() gained a $blocking parameter (non-blocking fire-and-forget mode for cron/admin); new stagingBacklogCount() helper (counts import_history rows with syncFinished = 0).
• Modified: auctionforge.php — auctionforge_sync_safety_action() now drains orphaned staging via the non-blocking processor when a backlog exists; new process_staging case in the auctionforge_sync_enqueue AJAX handler; plugin header bumped to 3.7.0.32.
• Modified: admin/view/sync-status.php — added the "Process Staging" button and its click handler.

---

[3.7.0.28] — 2026-05-21

Fixed — WP-Cron duplicate-event accumulation

A scan across 18 WordPress installs found that 16 sites had duplicate cron events for the AuctionForge sync hooks — some with up to 20 copies of bp_auto_close and 6 copies of auctionforge_sync_safety. Root-cause analysis identified three distinct bugs in the plugin's scheduling code, all fixed in this release.

Bug 1 — $_SERVER['SERVER_NAME'] baked into scheduling args. auctionforge.php:2511-2554 scheduled bidspirit_import, data_import, bidspirit_archive_import, and auctionforge_sync_safety with $attr = array($_SERVER['SERVER_NAME']). WP-Cron's wp_next_scheduled() guard matches on hook plus args signature, so every distinct hostname the site was reached under (canonical, www., IP-direct, internal cron caller hitting 127.0.0.1, an old domain from before a rename) bypassed the guard and scheduled its own copy. The handlers unset($host) — the argument was always vestigial. Removed $attr entirely; events now schedule with empty args. Also dropped the !empty($_SERVER['SERVER_NAME']) outer guards so wp-cli / OS-cron bootstraps can prime the schedule on a fresh install.

Bug 2 — bp_auto_close per-term scheduling with no cleanup. inc/controllers/BidspiritLots.php scheduled one 10-minutely event per running auction term, keyed on ['term_id' => …, 'slug' => …] — correct in principle, but nothing ever unscheduled the event when the auction ended or its term was deleted. Long-running sites accumulated dozens of dangling per-term events polling the BidSpirit API for auctions that no longer existed. Added two cleanup paths:

• bidspirit_auto_close_action() now self-cleans: if the term has been deleted, or if the remote auction state returned by BidSpirit is not RUNNING or ENDING, the handler writes the remote state to auction_state term meta and calls wp_clear_scheduled_hook('bp_auto_close', $args) for that term. The meta write is necessary because check_is_live() runs on every wp_loaded and re-arms bp_auto_close for any term still marked STATE_RUNNING in local meta — without writing the remote state through, the unschedule would be undone on the next request. The meta write is consistent with what SafetySync::run() and inc/import/AuctionList.php:229 already do on non-RUNNING upstream states.
• New pre_delete_term hook on the auction_number taxonomy unschedules the matching event when an auction term is deleted, so a deleted auction can't leave a poll behind.

Bug 3 — Orphan hooks from removed plugin code. bidspirit_meta_migrate_sync and bidspirit_migrate_sync were scheduled by a previous plugin version whose code has since been removed. They sat in wp_options.cron firing into the void on every site (the MIGRATE_SYNC constant in Settings.php:36 is the lone survivor — commented out). No upgrade path ever called wp_clear_scheduled_hook() for them.

Added — One-shot migration: AF_Cron_Cleanup

New class at inc/maintenance/class-cron-cleanup.php, registered from class-stats-init.php, runs once on the first request after upgrading and:

1. Walks _get_cron_array() and unschedules every event for the four hooks rewritten in Bug 1 whose args are non-empty — clearing per-hostname stragglers. The new scheduling code at the top of auctionforge.php has already armed a clean no-args event by the time the migration runs (the scheduling code runs at plugin-load time; the migration runs on init priority 20). Preserving empty-args events means the schedule remains continuously populated — no gap between sweep and the next page load.

2. Unschedules every event (any args) for the two orphan hooks from Bug 3 — those have no callbacks anywhere in the codebase, so empty-args entries are also dead weight.

3. Marks itself done via the auctionforge_cron_cleanup_v1 option and never runs again.

Note that wp_clear_scheduled_hook($hook) alone only matches events with empty args — events scheduled with non-empty args (which is exactly our duplicate population) are left behind. The migration walks the cron array directly and calls wp_unschedule_event($timestamp, $hook, $event['args']) for each match.

Logs a summary line via SyncLogger so the per-site outcome is auditable: e.g. cron-cleanup: Cleared duplicate/orphan cron events: {"bp_auto_close":20,"auctionforge_sync_safety":3,"bidspirit_meta_migrate_sync":2}.

Failure modes after this release

| State | Outcome |

|---|---|

| Fresh install (no duplicates) | Migration runs, finds nothing, sets the option, exits in microseconds. |

| Upgrade on a site with N duplicates | Migration clears them on first load post-upgrade; scheduling code re-arms each hook once with empty args. |

| Site reached under multiple hostnames going forward | No new duplicates — args no longer carry the hostname, so the wp_next_scheduled() guard catches re-registration regardless of which hostname triggers it. |

| Auction term deleted via wp-admin | pre_delete_term clears the matching bp_auto_close event in the same request. |

| Auction ends remotely (state != RUNNING/ENDING) | Next handler run sees the state change and self-cleans the event. |

| Auction term deleted while a bp_auto_close cron is mid-flight | Handler's get_term() returns null, falls through unschedule_auto_close() cleanup branch, returns without an API call. |

Internal

• Created: inc/maintenance/class-cron-cleanup.php (~80 LOC).
• Modified: auctionforge.php lines 2511-2573 — removed SERVER_NAME args and outer guards from bidspirit_import / data_import / bidspirit_archive_import / auctionforge_sync_safety scheduling blocks; handler signatures changed from ($host) to (); add_action(..., 10, 1) simplified to add_action(...).
• Modified: inc/controllers/BidspiritLots.php — added pre_delete_term action registration; rewrote bidspirit_auto_close_action() with term-existence check and state-based self-clean; added unschedule_auto_close() and cleanup_auto_close_on_term_delete() helpers; dropped the SERVER_NAME guard from the per-term scheduling loop.
• Modified: inc/stats/class-stats-init.php — requires and registers AF_Cron_Cleanup alongside AF_Data_Purge.

---

[3.7.0.21] — 2026-05-05

Added — Connection Diagnostics on the Updates admin page

A new Connection Diagnostics card on Lots → Updates that detects and one-click-heals identity mismatches between this site and the deployment server.

The problem it solves. When a WordPress install is cloned (template → customer site, dev → prod, backup → restore), the cloned wp_options carry the original site's auctionforge_update_api_key over to the new home_url(). The new install then makes API calls to wpdeploy *authenticated as the original site*. wpdeploy looks up by api_key, not by URL, so every /sync-user-tracking, /check-updates, /report-health, and most importantly the Kuma push URL, gets recorded against the WRONG wpdeploy.sites row. The cloned site's monitor stays silent; the original's monitor shows traffic that isn't from it.

What the diagnostic does:

• Run Identity Check — calls the new wpdeploy GET /api.php/whoami endpoint and compares the returned caller_site_url against home_url(). Renders a verdict ("matches" / "MISMATCH") plus the full server-side view (site_id, site_name, last_check, plugin version on file, remote IP). The "Re-register & Reset Kuma" button only appears if there's a mismatch.
• Re-register & Reset Kuma — calls /request-access (which is idempotent on site_url — wpdeploy returns the canonical api_key for *this* home_url(), regardless of whatever wrong key we were holding), wipes auctionforge_kuma_push_url and any leftover heartbeat cron events, then immediately fires /check-updates so the api_request interceptor catches the freshly-correct kuma_push_url for *this* site. The keepalive mu-plugin's heartbeat picks it up on the next 60s tick.

Internal

• AuctionForge_Auto_Updater::whoami() (new) — thin wrapper over api_request('whoami', [], 'GET'). Returns the parsed wpdeploy /whoami payload.
• AuctionForge_Auto_Updater::reset_connection() (new) — three-step heal: re-register → wipe Kuma cached state → re-fetch via /check-updates. Returns shape suitable for wp_send_json_success.
• Two new AJAX actions: auctionforge_diagnose_connection, auctionforge_fix_connection. Both behind manage_options capability + nonce check.
• auctionforge_normalize_host() helper for case/scheme/www-tolerant URL comparison.

Server-side companion

Requires the wpdeploy /api.php/whoami endpoint added in the same release window. The endpoint is gated behind whatever api_key the caller already presented (a master key returns type=master with no site row; a per-site key returns the site row that key resolves to). Reveals nothing the caller doesn't already implicitly authenticate against.

---

[3.7.0.20] — 2026-05-04

Changed

• Kuma heartbeat path is now wpdeploy-independent. The actual heartbeat firing — wp-cron schedule, page-load piggy-back, outbound HTTP — moved out of AF and into the AuctionForge Keepalive mu-plugin (wp-content/mu-plugins/auctionforge-keepalive.php, bumped to v1.2.1). Once a site has been provisioned once and auctionforge_kuma_push_url is cached locally, the heartbeat keeps reporting forever even if AF is deactivated, mid-upgrade, deleted from disk, or wpdeploy is offline. The mu-plugin can't be deactivated by WordPress, can't be broken by an AF release, and depends on AF for nothing.
• AF only writes the kuma_push_url option now. It no longer schedules the cron, no longer fires the heartbeat, and no longer holds any heartbeat-related state. The api_request() interceptor still catches kuma_push_url from /check-updates and /report-health responses and persists it; the mu-plugin reads it from there.
• Migration block. init_hooks() clears any leftover auctionforge_kuma_heartbeat wp-cron event from AF ≤ 3.7.0.19 on first plugin load after upgrade. The mu-plugin runs the same clear on its own plugins_loaded hook — belt and braces. The new event the mu-plugin schedules is kuma_heartbeat_tick on a new kuma_60s schedule.
• AuctionForge_Auto_Updater::kuma_heartbeat() no-opped. Kept as a safety landing pad so any stale auctionforge_kuma_heartbeat wp-cron event that fires one last time before migration kicks in doesn't trip a "no callback registered" warning. Real heartbeat work happens in the mu-plugin.

Added — operator override

• AUCTIONFORGE_KUMA_PUSH_URL constant. Define it in wp-config.php to point a site directly at Kuma without ever involving wpdeploy:

```php

define('AUCTIONFORGE_KUMA_PUSH_URL', 'https://kuma.example.com/api/push/<token>?status=up&msg=&ping=');

```

The constant takes precedence over the auctionforge_kuma_push_url option. With it set, the site can be operated fully outside wpdeploy — useful for one-off installs, customer-managed sites, or disaster-recovery scenarios where wpdeploy is unreachable for an extended period.

Internal — Keepalive mu-plugin v1.2.1

The bundled keepalive template at inc/keepalive/auctionforge-keepalive.template.php now also handles Kuma heartbeats. Three layered triggers ensure cadence stays tight regardless of site traffic:

1. Dedicated wp-cron event kuma_heartbeat_tick on a new 60-second kuma_60s schedule

2. Page-load piggy-back on init: any request older than 50s since the last beat fires another, transient-guarded so concurrent hits coalesce. Free on busy sites; rescues low-traffic sites the moment any visitor arrives.

3. Self-heal inside the cron callback: if the event somehow gets cleared, re-arm it before sending the beat.

HTTP is timeout=2, blocking=false — fire-and-forget, never slows page loads. External IP introspection (ipify → ifconfig.me → icanhazip fallback chain, 24h transient cache) is duplicated in the mu-plugin so it doesn't depend on AF being loaded for the IP lookup.

The keepalive installer (class-keepalive-installer.php) detects the KEEPALIVE_VERSION: 1.2.1 header bump and idempotently overwrites every site's mu-plugin on the next AF load. No manual reactivation needed.

Failure modes after this release

| State | Heartbeat? |

|---|---|

| AF active and healthy | ✅ via mu-plugin |

| AF deactivated by an operator | ✅ mu-plugin runs anyway |

| AF deleted from disk | ✅ as long as auctionforge_kuma_push_url option exists OR constant is set |

| AF mid-upgrade / partial install | ✅ mu-plugin doesn't depend on AF code paths |

| wpdeploy down (existing site) | ✅ option is cached locally, no wpdeploy round-trip |

| wpdeploy down (brand-new site, never provisioned) | ❌ first-time URL provisioning still needs wpdeploy. One-shot, accepted trade-off. |

| Site has zero traffic AND wp-cron isn't firing | ❌ truly nothing to trigger a beat. Mitigation is OS-level cron / DISABLE_WP_CRON, out of scope here. |

---

[3.7.0.19] — 2026-05-04

Changed

• Reverted Kuma heartbeat cadence: 3 min → 1 min. auctionforge_kuma_heartbeat is back on the bp_minutely schedule. With Kuma's 310s silence window, 60s cadence tolerates 4 missed wp-cron ticks before flipping a monitor red — the original "give-it-leeway" semantics. The 3-min cadence introduced in 3.7.0.18 was strictly less chatty but tighter (a single missed tick would trip Kuma), and the trade-off wasn't worth it operationally.
• Migration block updated. init_hooks() now detects any existing event scheduled on a non-bp_minutely cadence (e.g. the bp_3_minutely set by 3.7.0.18) and re-schedules onto bp_minutely. Sites that took 3.7.0.18 roll back automatically on first plugin load after upgrade.
• First-fire jitter narrowed back to 0–60s to match the new cadence.

Notes

• The bp_3_minutely cron schedule registration in auctionforge.php is kept (harmless; available for future use). Only the heartbeat scheduling sites have been reverted.
• Apparent latency in Kuma flipping a monitor red after a real outage is governed by Kuma's per-monitor interval (silence-detection window, currently 310s on the wpdeploy/Kuma side), not by this cron's cadence. To detect outages faster, lower the Kuma interval; to add more tolerance to wp-cron drift, raise it.

---

[3.7.0.18] — 2026-05-04

Changed

• Kuma heartbeat cron cadence: 1 min → 3 min. auctionforge_kuma_heartbeat now runs on a new bp_3_minutely schedule (180s) instead of bp_minutely (60s). This pairs with Kuma's 310s silence-detection window — a single late wp-cron tick (3 min + drift) still lands inside the threshold, but normal traffic to Kuma drops by ~3×.
• Random first-fire offset widened from 60s → 180s. With ~50 sites on a single Kuma instance, spreading first-fires across the full 3-min window prevents synchronised bursts every 3 minutes.
• Auto-migration of existing scheduled events. On plugin upgrade init_hooks() calls wp_get_scheduled_event('auctionforge_kuma_heartbeat') and, if the existing event is on bp_minutely, clears it and reschedules onto bp_3_minutely. Idempotent — a no-op once migrated.

Internal

• New cron schedule registered: bp_3_minutely (BP_MINUTELY * 3 = 180s). Defined alongside the existing bp_minutely / bp_ten_minutely / bp_hourly / bp_24_hourly schedules in auctionforge.php.

---

[3.7.0.17] — 2026-05-04

Fix: "Install Now" always returned up_to_date

The /sync/version REST endpoint (called by wpdeploy's Install Now button) was always responding success: false, reason: up_to_date regardless of the actual installed version, defeating the button's whole purpose.

Root cause

rest_force_plugin_update() did:

```

delete_site_transient('update_plugins');

$this->check_pending_updates();

$updates = get_site_transient('update_plugins');

```

check_pending_updates() calls the /pending-updates endpoint on wpdeploy (which returns the deploy queue), but it does not touch the WP update_plugins transient. The transient just got deleted on the line above and never gets re-populated, so the isset($updates->response[…]) check always failed → always returned up_to_date.

Fix

• Use wp_update_plugins() instead — that's what fires the pre_set_site_transient_update_plugins filter chain that AF's own check_for_updates() callback hooks into to seed the transient. Same pattern is already used correctly in install_update() at line 280.
• Belt-and-braces: when the request body carries an explicit target version and that version is strictly greater than the on-disk plugin version (per version_compare), bypass the transient check and force the install. This handles edge cases where the transient seeding fails (network blip during the wp-cron cycle, hosting-side cache, etc.) so the explicit Install Now command still does what it says.

---

[3.7.0.16] — 2026-05-04

Server external IP reported to wpdeploy + included in Kuma heartbeats

Each AF install now reports its server's outbound external IP. Two channels:

1. Kuma heartbeat msg — the per-minute push payload now reads <wp_version>|<plugin_version>|<external_ip> (e.g. 6.9.4|3.7.0.16|152.53.187.82) so you can spot at a glance which physical box each site lives on. When a host goes dark, multiple monitors flip red simultaneously with the same IP — instant root-cause hint.

2. /report-health payload — a new external_ip field that wpdeploy stores on sites.external_ip. Visible in the Sites admin view as a tappable IP chip; clicking it filters the table to all sites sharing that IP.

How the IP is detected

AuctionForge_Auto_Updater::get_external_ip() calls one of three public echo services in turn — api.ipify.org, ifconfig.me/ip, icanhazip.com — with a 4-second timeout each. The first one that returns a valid IP wins. Result is cached in a transient for 24 hours so we don't hit external services on every report cycle.

Wpdeploy fallback for older plugins

/report-health now also captures REMOTE_ADDR (or HTTP_CF_CONNECTING_IP when behind Cloudflare) when the payload doesn't include external_ip. So sites still on 3.7.0.15 or older start populating their IP today via the same route, no plugin update needed for that data path.

---

[3.7.0.15] — 2026-05-04

Kuma monitors land in an "Unallocated" group by default

New AuctionForge installs are auto-enrolled into Kuma under a new top-level group called Unallocated so the operator can review them and drag-drop into the right home (Bidspirit Auction Sites, Stephen's Auctions, Misc Websites, etc.) before classification. Without this every new monitor would appear at the dashboard top level alongside whatever group hierarchy already exists.

What changed (wpdeploy-side, no plugin behaviour change)

• KumaProvisioner now ensures an "Unallocated" group exists in Kuma (find-or-create via the same Socket.IO add path used for monitors, with type='group') before provisioning each new push monitor, and passes parent=<group_id> in the add payload so the new monitor lands inside it.
• The Node helper accepts arbitrary type and parent fields on the input payload (previously hardcoded to type='push').
• The group itself gets the same user_id=1 reassignment so it shows up on the human admin's dashboard.

Existing Clumber monitor (id=71) was migrated into the new group as part of this release.

This is a wpdeploy infrastructure change — the AF plugin code is unchanged from 3.7.0.14. Version bumped only to mark a clean snapshot point.

---

[3.7.0.14] — 2026-05-04

Uptime Kuma push heartbeat with automatic enrolment

Each AF install now appears as its own monitor on the central Uptime Kuma at https://kuma.smoothbyteit.dev, beating every minute and flipping red within ~90 seconds when a site goes dark. Auto-enrolled — no manual Kuma UI clicks per site.

How it works

1. First contact: when the plugin calls /request-access or /report-health, wpdeploy's new KumaProvisioner opens a Socket.IO connection to Kuma as a dedicated auctionforge-bot user, calls the official add event, and gets back a fresh push token. The resulting URL is shipped to the plugin in the JSON response as kuma_push_url.

2. Plugin-side: a generic interceptor on api_request() persists kuma_push_url to the option auctionforge_kuma_push_url whenever it appears in any wpdeploy response, and immediately schedules the new auctionforge_kuma_heartbeat cron on the existing bp_minutely interval.

3. Heartbeat: the cron handler sends a single wp_remote_get to the push URL each minute with msg=<wp_version>|<plugin_version> so Kuma's dashboard shows the running stack at a glance. Kuma's silence-detection window is 90s, so a single missed wp-cron tick won't false-DOWN.

4. Idempotency: the Kuma monitor's description field stores wpdeploy_site_id:<id>. Re-registering the same site short-circuits at the wpdeploy layer (existing kuma_monitor_id on sites), or — if that's missing — Kuma's existing row is reattached via the description anchor. Re-installing the plugin never duplicates monitors.

Why Socket.IO and not direct DB insert

Kuma's monitor scheduler does not poll its own DB for new rows — startMonitors() only loads monitors at boot, and new ones are armed via the authenticated Socket.IO add event handler (which calls startMonitor() and arms the per-monitor safeBeat setTimeout). A direct INSERT would create a "phantom" monitor that accepts pushes but never flips DOWN on silence, defeating the whole feature.

Notifications + monitor ownership

Provisioner reads existing Kuma notification rows whose channel is Telegram (or marked default-for-new-monitors) and attaches them to every new monitor via the add event's notificationIDList. After the Socket.IO add succeeds, the provisioner direct-writes user_id=1 to the new monitor row in Kuma's SQLite — Kuma's add handler hardcodes user_id=socket.userID (the bot at user 2), which causes the frontend's real-time monitor-list updates to skip the admin's session. The follow-up UPDATE stamps ownership to the human admin so monitors render with their full name on the admin dashboard immediately.

Failure modes

Every call boundary degrades safely. If Kuma is unreachable when a site registers, registration completes without kuma_push_url; the next twicedaily /report-health retries. Heartbeat HTTP failures are silent (which is the desired outcome — Kuma's silence-detection is the signal). Kuma reset / monitor row deleted: provisioner's pre-flight check NULLs the wpdeploy anchors and falls through to fresh provisioning on the next call.

Operator setup

Already done: the auctionforge-bot Kuma user has been created and credentials populated in wpdeploy's config.php. To rotate or migrate Kuma later, edit KUMA_URL / KUMA_BOT_USER / KUMA_BOT_PASS in config.php — no plugin redeploy needed.

---

[3.7.0.13] — 2026-05-04

Wide shortcode: hide Register button for logged-in users

• When a user is logged in to BidSpirit (body.bp-login), the Register button is now automatically hidden on wide-format auction cards (bp_upcoming_wide and bp_auction_list layout="wide").
• The View Catalog / Catalog Coming Soon button expands to full width when the Register button is hidden.
• Uses a lightweight MutationObserver to react to BidSpirit's async session init.
• Applied to both UpcomingAuctionWide.php and AuctionList.php shortcode CSS blocks.

---

[3.7.0.12] — 2026-05-03

Stop-word denylist for BidSpirit category-tag concatenations

BidSpirit's wp_bp_meta_data.tags field arrives as PascalCase category names lowercased without separators (uscollectibles, firearmsaccessoriesammunition, usdecorativearts, printsandmultiples). They look like keywords but they're really categories, and on sites where the tags field is populated they completely swamp the top-5 chips for power users (e.g. one buyer's profile was led by uscollectibles 453 views despite that being a label rather than a real interest signal).

29 known patterns added to stop-words.php so the tokenizer drops them at extraction time. New ones surfacing from sites we haven't seen yet should be added here as they appear; the wpdeploy ?tab=keywords corpus page makes them easy to spot (sort by most users with low lots count and look for non-word concatenations).

---

[3.7.0.11] — 2026-05-03

Keyword extractor — capture model years + hyphenated calibers, drop more auction noise

The People view's top-5 keyword chips were filling up with generic descriptors (household, model, original, assortment) instead of the brand/maker terms (mauser, whitworth, colt) that actually distinguish one buyer from another. Live-data review on the new ?tab=keywords Keyword Corpus page on wpdeploy confirmed the cause: real signal was being lost at the tokenizer stage.

Tokenizer changes (inc/stats/class-keyword-extractor.php)

Three pre-passes now run before the standard split-on-non-alpha:

1. Hyphenated / x-separated calibers — .45-70, .30-06, 7.62x54r, 8x57. Without this they're split into pure-digit fragments and dropped, losing the actual model identifier.

2. Caliber-with-suffix — 9mm, .22lr, .45acp, .380acp. Previously only survived by accident because of the trailing letters; now extracted explicitly.

3. 4-digit model years 1700–2099 — 1873, 1903, 1911, 1971. Pure-digit tokens were unconditionally dropped; now retained when year-shaped.

Standard pass relaxed to allow 4-digit pure-digit tokens between 1700 and 2099.

Stop-word additions (inc/stats/stop-words.php)

Conservative — only universally empty auction descriptors:

original, marked, accessories, decorative, household, goods, made, condition, assortment

Deliberately NOT added: antique, vintage, rare, fine — those carry buyer-segmentation signal (antiquarian buyers vs. modern-collectibles buyers). Borderline cases (metal, wooden, american, model) are left to the wpdeploy-side IDF re-rank.

Companion change on wpdeploy (no plugin update needed)

refresh_people_rollup.php now multiplies each keyword's score by an IDF factor pulled from keyword_idf (refreshed hourly by refresh_lot_keyword_index.php). Generic keywords that appear in many lots get demoted automatically; brand/maker words that only appear on a handful get lifted into the top-5 chips.

After deploying this version, reset the auctionforge_lots_sync_watermark option on each site and clear the wp_af_stats_lot_keywords table to force re-extraction of every lot through the new tokenizer.

---

[3.7.0.10] — 2026-05-03

Lots sync — ship resolved CDN image URL, not bare BidSpirit filename

class-lots-sync.php was sending imagesListStr's first comma-token verbatim as image_url — that's the raw BidSpirit storage value (e.g. 001.jpg). Wpdeploy received a bare filename, the browser resolved it against the wpdeploy host, and every lot thumbnail 404'd.

The lots-sync now instantiates LotImage and pulls the resolved CDN URL (LABEL_MEDIUM thumbnail), with fallback to LABEL_ORIGINAL and a final defensive check that drops anything that doesn't start with http(s)://. Resolution is wrapped in try/catch — a missing class or BidSpirit settings issue leaves image_url empty rather than blowing up the sync batch.

After deploying this version on a site, reset its auctionforge_lots_sync_watermark option (delete the row) to re-push existing lots through the new resolver. The wpdeploy view skips <img> rendering when image_url isn't a real URL, so dirty rows degrade silently while the watermark catches up.

---

[3.7.0.9] — 2026-05-03

Keepalive sweep — auto-clears WP upgrader debris that produces silent "Could not create directory" failures

WordPress 6.x's atomic-rollback flow leaves wp-content/upgrade-temp-backup/ lying around when its post-install cleanup misfires (the user-facing symptom is "Update failed: Could not create directory" after an update that has actually already succeeded). Stale wp-content/upgrade/<plugin>-tmp/ and .maintenance lockfiles from crashed upgrades cause the *next* upgrade attempt to fail the same way. None of WP's own scheduled cleanup catches these reliably.

The keepalive mu-plugin (KEEPALIVE_VERSION 1.1.0) now sweeps all three classes of debris on every page load, transient-guarded to once per hour. Safety thresholds prevent it touching anything actually in flight: .maintenance files less than 5 min old, wp-content/upgrade/* entries less than 60 min old, and upgrade-temp-backup/ less than 30 min old are left alone. Wrapped in try/catch with no throws, so the sweep can never block a request.

The keepalive installer detects the version bump and rewrites wp-content/mu-plugins/auctionforge-keepalive.php automatically on the next AF load, no manual reactivation needed.

---

[3.7.0.8] — 2026-05-03

Shop auction UI refinements & share button settings

Shop (Buy-It-Now) catalog improvements

• Shop sorting dropdown: Added a dedicated sorting dropdown for shop catalogs with options: Recently Added, Price: High, and Price: Low. Sorts by buyoutPrice metadata. Regular auction catalogs retain the original sorting options.
• Removed "Buyout price:" label: On shop lot pages, the redundant "Buyout price:" text before the price is now hidden. Only the price and "Buy Now" button are displayed. Regular auction buyout lots still show the label.
• Removed increments table & terms links: On shop lot pages, the "Increments table" and "Terms and conditions" links are hidden since they don't apply to buy-it-now items. The "Make an inquiry" link remains.

Buyout confirmation modal overhaul

• Sales tax logic: The buyout confirmation modal now follows the same sales tax detection as the regular bid modal. When the auction house has a US state configured, displays "Sales Tax" instead of "VAT", with the correct percentage for same-state buyers and 0% for out-of-state.
• Hide 0% buyer's premium: The Buyer's Premium line is hidden when the commission is 0%.
• Shop-specific text: For shop buyouts, all disclaimer text is replaced with: *"You will receive an email with your invoice, including shipping, and a secure payment link."*
• Shop-specific buttons: "I don't Agree" → "Cancel", "I Agree" → "Buy". The "Terms of sale" button is removed for shop buyouts. Non-shop buyouts retain the original layout.

Purchase confirmed screen

• Title changed from "Confirm purchase:" to "Purchase Confirmed".
• Thank you message updated to: *"Thank you for your order. We will confirm your order within 1-2 business days and email you an invoice, including shipping, and a secure payment link."*

Share button settings (Appearance tab)

• Added a Share Buttons section to the BidSpirit Appearance settings tab with individual checkboxes for each sharing platform: Copy Link, WhatsApp, Facebook, Telegram, X (Twitter), VK, Pinterest, and Email.
• All platforms default to enabled (shown). Unchecking a platform hides that share button on all lot pages (both shop and regular auctions).

---

[3.7.0.7] — 2026-05-02

Identity stitch on bidder login — keyword interest tallying now actually fires

Why

The keyword extractor was filling wp_af_stats_lot_keywords correctly (197 lots, 734 distinct keywords on Clumber), but wp_af_user_interests and wp_af_user_recent_activity were both empty — zero rows of any dimension. Same on every site running the new sync streams.

Root cause: identity stitching (visitor_hash → email) only fired in the tracker AJAX when is_user_logged_in() returned true. On these auction sites the actual bidders authenticate via BidSpirit, never as wp_users — so the WP login check was always false, the stitch table stayed empty, and maybe_record_lot_view($url, $email, …) got called with an empty email and bailed out before tallying. Lot views by real bidders never landed in the user-side interest profile.

What changed (no auth-path intervention)

The fix piggybacks on the *existing* fire-and-forget tracking AJAX that already runs after a successful BidSpirit login (afLogIP("login", bidspiritUser)). It does not touch the BidSpirit auth path itself.

• inc/ip-logger.php auctionforge_ajax_log_ip() — after the existing auctionforge_user_tracking insert, if the request carries a visitor_hash and the email is valid, calls AF_Stats_Visitor_Email_Map::record($vh, $email, $ip). Wrapped in try/catch so any failure here can never break the existing tracking response.
• assets/js/app.js + src/js/app.js afLogIP() — reads localStorage['af_vid'] (defensively, ITP/private-mode safe) and includes it as visitor_hash in the POST body.
• inc/stats/class-stats-init.php maybe_record_lot_view() — when $email is empty (the common case for BidSpirit-only bidders) but a visitor_hash is present, falls back to AF_Stats_Visitor_Email_Map::lookup($visitor_hash). If a stitch exists, the view tallies; if not, it stays anonymous.

Net effect: a bidder logs in (BidSpirit), the post-login tracker AJAX fires as it always has, and now also writes one extra row into af_stats_visitor_emails. From that point onward, every page they view on the same browser/device tallies into af_user_interests keyed on their email. The BidSpirit transaction itself is untouched.

---

[3.7.0.6] — 2026-05-02

Critical fix — X-API-Key header collision with sibling SmoothByte plugins

What was wrong

On any site running both AuctionForge and another SmoothByte-stack plugin that also points its updater at wpdeploy.smoothbyteit.dev (e.g. seo-aeo-optimizer), the second plugin's http_request_args filter overwrote AuctionForge's X-API-Key header on every outbound API call. Wpdeploy then 401'd because the key it received belonged to a different plugin instance — usually a seo_aeo_update_api_key that wpdeploy had no record of.

The symptom was a quiet, total auth failure: report-health, check-updates, every sync-* route, all 401. The watchdog flagged streams as "gone" and updates stopped flowing. Affected sites: any install where the AuctionForge key and the sibling plugin's key happen to differ. Sites where both plugins shared a key were silently safe (the overwrite was a no-op).

Fix

AuctionForge_Auto_Updater::add_download_auth() now refuses to clobber an existing X-API-Key and, for download URLs, only stamps when the URL slug matches our own. That keeps targeted calls from api_request() intact regardless of filter ordering, and prevents either plugin from writing its key onto the other's download URL.

The same fix has been applied to seo-aeo-optimizer so both ends of the collision are defensive.

---

[3.7.0.5] — 2026-05-02

Sync Status admin panel — diagnostic + manual triggers in wp-admin

Why

Diagnosing sync issues used to require shell access on the site or piecing together state from wpdeploy's app.log. This release surfaces the same diagnostics inside wp-admin so a site admin (or anyone with manage_options) can see exactly what's happening and trigger fixes in one click.

Lives inside the existing Sync Status menu (Lots → Sync Status) — appended below the existing content as a "Sync Diagnostics & Manual Controls" section, no duplicate menu entry.

What's on the panel

Connection summary — plugin version, af_stats_db_version, wpdeploy server URL, last 8 chars of API key, keepalive install state + auto-reactivation count.

Sync streams table — for each of the 10 cron hooks (user-tracking, user-profile, user-interests, user-activity, lots, bids+wins, vulnerabilities, report-health, check-updates, fraud-enforcement):

• Configured schedule
• Last fired timestamp + status colour-coded (green=success, blue=idle/empty, red=error)
• Record count from last run
• Next scheduled run
• Current watermark (where applicable)
• "Fire now" button — clears doing_cron, calls do_action($hook) synchronously, shows the result

One-shot utilities

• Test wpdeploy connection — calls /api.php/info with the site's API key
• Clear stuck cron lock — deletes the doing_cron transient (the classic fix when scheduled events stop firing)
• Reinstall keepalive — overwrites mu-plugins/auctionforge-keepalive.php from the bundled template
• Backfill bids from legacy tracking — replays last_event_type='bid' rows from wp_auctionforge_user_tracking into wp_af_bid_events so the bids-wins stream picks them up. Useful for sites that have years of bid history in the legacy table but nothing in the new queue
• Run all due events now — clears doing_cron and fires every auctionforge_* cron event whose timestamp is past due, in one go

Live response output panel shows the JSON returned from each action so you can see what just happened without leaving the page.

Files Changed

• Created: inc/admin/class-sync-status-page.php
• Modified: inc/stats/class-stats-init.php (load + init the panel)
• Modified: admin/view/sync-status.php (append AF_Sync_Status_Page::render_panel() call at the bottom)
• Modified: auctionforge.php (Version 3.7.0.4 → 3.7.0.5)

Verification

Navigate to Lots → Sync Status in wp-admin on any 3.7.0.5 site. Scroll past the existing content to the new "Sync Diagnostics & Manual Controls" section. Click "Test wpdeploy connection" — you should see {"success": true, "auth_type": "site"}. Click "Fire now" on any stream — the row's last-fired timestamp should refresh after 1–2 seconds.

---

[3.7.0.4] — 2026-05-02

Self-healing: failed plugin updates can no longer take a site offline

Why

WordPress's plugin updater isn't transactional — when an update fails partway (corrupt unzip, fatal during the new version's plugins_loaded, disk pressure, theme conflict, etc.) WP often deactivates the plugin and leaves the site without it. Once AuctionForge is dropped from active_plugins, no AF code runs again — including its sync handlers — until someone notices and reactivates manually. On the AuctionForge site fleet, this had quietly happened to ~5 sites we found; almost certainly more on production sites we don't have filesystem access to.

This release ships an autonomous watchdog that lives outside the AuctionForge plugin entirely so it survives even when AF gets knocked out.

What changed

1. Self-installing keepalive (mu-plugin)

• inc/keepalive/auctionforge-keepalive.template.php — a 50-line WordPress must-use plugin. Lives in wp-content/mu-plugins/, which WordPress can't deactivate. On every plugins_loaded (priority 1, before any regular plugin), it checks: is auctionforge/auctionforge.php on disk but missing from active_plugins? If yes AND the file has a valid Plugin Name: header (smoke check — don't reactivate a corrupt zip), it re-adds AF and includes the file in the same request.
• inc/keepalive/class-keepalive-installer.php — runs on every successful AF load. Copies the template into wp-content/mu-plugins/auctionforge-keepalive.php if missing or version-bumped. Idempotent: compares KEEPALIVE_VERSION headers, only writes on change. Refuses to overwrite a foreign mu-plugin (defensive against name collisions). Failure is non-fatal — install errors are recorded in wp_options for wpdeploy visibility but never throw.

Net effect. Any site that successfully loads AF 3.7.0.4 or later will have the keepalive permanently installed in mu-plugins. From that point forward, even if a future update hard-fails, the keepalive recovers AF on the next pageview without any manual intervention or filesystem access. Crucially: this works on sites we don't own — the keepalive ships inside the AF zip, gets installed during the first successful update, and lives in mu-plugins thereafter.

2. Forensic markers

The keepalive writes three options on each recovery:

• auctionforge_auto_reactivated_at — most recent recovery timestamp
• auctionforge_auto_reactivated_count — total recoveries
• auctionforge_auto_reactivated_failed_at — set when the keepalive saw AF on disk but with no Plugin Name header (genuinely corrupt — needs operator attention)

These get picked up by the AF sync streams and surfaced on the wpdeploy dashboard so you can see which sites have been quietly recovering themselves and whether a particular release is failing more than it should.

3. Companion: post-update-silence alerts on wpdeploy (server side)

Wpdeploy's report-health route now compares incoming plugin_version against the row and writes last_version_changed_at + previous_plugin_version on change. The SyncWatchdog cron then alerts if a site has reported a version change but not sent any heartbeat for 2+ hours since — likely a failed install. Emits sync_incidents rows with kind=post_update_failure so the existing Telegram fan-out picks them up. Each version-change event alerts at most once.

Files Changed

• Created: inc/keepalive/auctionforge-keepalive.template.php, inc/keepalive/class-keepalive-installer.php
• Modified: inc/stats/class-stats-init.php (call AF_Keepalive_Installer::maybe_install() on every plugin load)
• Modified: auctionforge.php (Version 3.7.0.3 → 3.7.0.4)

Companion server-side changes (already deployed on wpdeploy.smoothbyteit.dev — not in this zip):

• sites table: last_version_changed_at TIMESTAMP NULL, previous_plugin_version VARCHAR(20) NULL
• api.php /report-health route detects version changes
• SyncWatchdog::maybe_alert_post_update_failure() emits the new alert kind

Verification

1. Drop a 3.7.0.4 install on any site. Confirm wp-content/mu-plugins/auctionforge-keepalive.php exists post-load.

2. Manually deactivate AF from the database (DELETE FROM wp_options ...active_plugins...). Hit the homepage. AF reappears in active_plugins; auctionforge_auto_reactivated_count increments.

3. Delete mu-plugins/auctionforge-keepalive.php. Trigger AF load (any pageview). The file reappears.

4. Bump KEEPALIVE_VERSION in the source template, ship a new release, observe the installed mu-plugin update on next AF load.

Operator notes

• Sites currently in the broken state (AF deactivated, no keepalive yet) are NOT auto-rescued by this release — they need a one-time manual reactivation in wp-admin OR a fresh AF install via wp-admin's Upload Plugin. After that, the keepalive is in place and future failures self-heal.
• The post-update-failure alert won't fire for upgrades that happened before this release (no last_version_changed_at was recorded). It activates from the first version change wpdeploy sees from each site after this update lands.

---

[3.7.0.3] — 2026-05-02

Fix: profile re-sync on login / profile-edit / register (no more empty names)

Why

The hourly profile sync uses a user_registered watermark — once a user has been pushed once, the watermark advances past them and they're never re-pulled. That meant:

1. Existing users whose first_name/last_name became populated AFTER their first sync stayed empty on wpdeploy forever.

2. BidSpirit-driven sites that don't write WP's standard first_name/last_name fields shipped empty rows even though the canonical name was visible in display_name.

The People view was showing — for the name on rows that absolutely had a name available — just not where the sync handler was looking.

Fixes (inc/sync/class-profile-sync.php + inc/stats/class-stats-init.php)

• AF_Profile_Sync::push_for_user_id($user_id, $blocking=false) — new public method that builds a single user's profile row, normalises it, and POSTs to wpdeploy bypassing the watermark. Non-blocking by default (wp_remote_post with blocking=false, timeout=2s) so login latency is unaffected.
• build_user_row($user_id) extracted as a reusable helper. Both the hourly batch and the on-demand push call it. Centralises role-filtering + display_name fallback + usermeta probing.
• display_name fallback. When wp_usermeta.first_name / last_name are both empty (typical on BidSpirit-only sites), build_user_row() parses display_name ("John Smith" → first=John, last=Smith) so we don't ship a row with a blank name when the data is sitting on the user record itself.
• Three new action hooks registered in class-stats-init.php::init():
• wp_login → push_for_user_id($user->ID) — every login refreshes the row
• profile_update → same — profile edits in wp-admin refresh
• user_register → same — new registrations get pushed instantly (instead of waiting up to 60 min for the next cron tick)

Files Changed

• Modified: inc/sync/class-profile-sync.php (refactor + new method + display_name fallback)
• Modified: inc/stats/class-stats-init.php (three new action hooks)
• Modified: auctionforge.php (Version 3.7.0.2 → 3.7.0.3)

Verification

1. On a 3.7.0.3 site, find a user whose wpdeploy.user_profiles.first_name is empty:

SELECT site_id, email, first_name FROM user_profiles WHERE email='something@example.com'

2. Log in as that user (or have them log in).

3. Within ~2 seconds, re-query — first_name should now be populated, either from the standard meta key OR parsed from display_name.

4. The non-blocking POST means the user's login experience is unchanged — no spinner, no extra latency.

Operator note

Existing wpdeploy rows with empty first_name/last_name will refresh automatically as users log in or edit their profile. To force a one-shot re-walk of every user on a site (regardless of watermark), reset the watermark there:

DELETE FROM wp_options WHERE option_name='auctionforge_profile_sync_watermark';

Next hourly cron will re-pull every non-admin user with the new fallback applied.

---

[3.7.0.2] — 2026-05-02

Fix: sync-lots datetime mismatch + idle syncs now heartbeat

Why

Two issues surfaced in the wpdeploy Sync Health dashboard:

1. Every site's sync-lots was stuck on api_error. The plugin sends last_modified straight from wp_bp_meta_data.lastUpdate, which is a Unix epoch string ("1756919754"). wpdeploy's lots.last_modified column is a DATETIME, so MariaDB rejects the insert with SQLSTATE[22007]: Incorrect datetime value. The handler records api_error and the watermark never advances, so every cron tick re-fails on the same batch.

2. Sites with nothing to sync looked dead. When a sync handler had an empty batch (e.g. no non-admin users yet) it was returning early without POSTing anything. wpdeploy's update_sync_health() only fires on a successful POST, so sites.sync_health_json stayed NULL and the dashboard showed grey dots — indistinguishable from a broken cron. WP-Cron was actually firing fine; the watchdog just couldn't tell.

Fixes

• inc/sync/class-lots-sync.php — new epoch_to_datetime() helper converts the BidSpirit epoch field to UTC Y-m-d H:i:s before shipping. Idempotent: already-formatted datetimes pass through untouched, invalid values become NULL.
• inc/sync/class-sync-base.php::run() — always POST, even when the batch is empty. Empty payload is {records: []} and wpdeploy's existing handlers handle it gracefully (loop is skipped, update_sync_health() still fires with synced=0). This makes the dashboard reflect cron liveness, not just data flow.

Files Changed

• Modified: inc/sync/class-lots-sync.php
• Modified: inc/sync/class-sync-base.php
• Modified: auctionforge.php (Version 3.7.0.1 → 3.7.0.2)

Verification

1. On Clumber: do_action('auctionforge_sync_lots') — confirm the previous auctionforge_last_sync-lots_status = api_error flips to success(N) and that wpdeploy.lots now contains rows.

2. On a site with no non-admin users: do_action('auctionforge_sync_user_profile') — confirm auctionforge_last_sync-user-profile_status = idle(0) AND that wpdeploy's Sync Health page now shows a green dot for that cell.

---

[3.7.0.1] — 2026-05-02

Fix: marketing data leaks WordPress admins into the people list

Why

After the 3.7.0.0 rollout the central people view on wpdeploy was showing site administrators alongside real auction-house users — the sync-user-profile handler read straight from wp_users with no role filter, so any account with administrator/editor/author/contributor/shop_manager capabilities was getting shipped as if it were a buyer. Marketing audiences must contain buyers, not staff.

Fixes (inc/sync/class-profile-sync.php)

• The read_batch() SQL now LEFT JOINs {$wpdb->usermeta} on the prefix-aware capabilities key ({$wpdb->prefix}capabilities) and filters out any user whose serialized capabilities meta_value contains administrator, editor, author, contributor, shop_manager, or super_admin. Users with IS NULL (no roles registered) are still allowed through — those are typically subscribers/buyers on this fleet.
• Watermark on auctionforge_profile_sync_watermark is unchanged; the next run after upgrade picks up the same batch with the new filter applied. Operationally the wpdeploy team also wiped the existing admin rows from user_profiles, user_interests, user_recent_activity, bids_wins, and people to clear the leak server-side — total of 35 rows scrubbed.

Files Changed

• Modified: inc/sync/class-profile-sync.php
• Modified: auctionforge.php (Version 3.7.0.0 → 3.7.0.1)

Verification on Clumber dev

1. Find a logged-in admin: SELECT u.user_email FROM wp_users u JOIN wp_usermeta um ON um.user_id=u.ID AND um.meta_key='wp_capabilities' WHERE um.meta_value LIKE '%administrator%';

2. Reset the watermark: DELETE FROM wp_options WHERE option_name='auctionforge_profile_sync_watermark';

3. Trigger sync: do_action('auctionforge_sync_user_profile');

4. On wpdeploy: confirm those admin emails do NOT appear in user_profiles (SELECT * FROM user_profiles WHERE email='admin@…'; returns zero rows).

Privacy / scope

• No API contract changes. The wpdeploy /api.php/sync-user-profile route accepts the same payload shape; this is purely a source-side filter narrowing what gets sent.

---

[3.7.0.0] — 2026-05-02

Cross-site user data lake — full Phase 2 + Phase 3 build

Why

AuctionForge sites were exposing per-lot engagement (views, favourites, bids, wins) keyed only on the anonymous af_vid localStorage hash, with no central aggregation. Marketing — even the "collect data now, send later" phase — needs a per-person view across the whole AF network: name + phone + postcode + country + IP + device fingerprint + the keywords they engage with + the bids they place + the lots they win, all rolled up across every site they've used. This release wires every piece needed for that, and keeps it sustainable: per-site aggregates rather than raw event firehose, watermarked syncs with retry, 14/30-day site-side retention, watchdog + Telegram alerts for dead streams.

See /root/.claude/plans/i-want-to-add-synthetic-goose.md for the full architecture.

New tables (idempotent dbDelta on the existing plugins_loaded migration path)

• wp_af_stats_lot_keywords — per-lot keyword cache. Title + tags + author tokenized (lowercase → drop stop-words → drop ≤2-char → drop pure-digit), one row per (post_id, keyword). Populated on save_post_lot.
• wp_af_user_interests — running tally per (user_email, dimension, dimension_value) where dimension ∈ keyword | category | author | price_band. UPSERT-keyed so increments are atomic. Bounded by users × distinct interests (typically a few dozen rows per user).
• wp_af_user_recent_activity — capped per-user activity log (last 50 events per email). Seeds the drill-down timeline on the wpdeploy person view.
• wp_af_bid_events — bid + win events (auto-created by the bids sync handler). Drained and shipped to wpdeploy hourly.
• synced_at columns added to wp_af_stats_pageviews, wp_af_stats_sessions, wp_af_stats_searches, wp_af_stats_outbound. Powers the durable sync-and-purge lifecycle.
• af_stats_db_version bumped 2 → 3. The existing AF_Stats_Init::maybe_create_tables() picks up the new tables on the next admin page load after auto-update.

New helper classes

• AF_Keyword_Extractor (inc/stats/class-keyword-extractor.php) — pure tokenizer + cache writer + read-through helper. Hooks save_post_lot to refresh on lot changes. Stop-words tunable via apply_filters('af_keyword_stop_words', ...).
• AF_User_Interests (inc/stats/class-user-interests.php) — record_view / record_favorite / record_bid / record_win. All idempotent UPSERTs. Calls AF_Stats_Tracker::should_skip() first so admins/bots never pollute interest profiles.
• AF_Sync_Base (inc/sync/class-sync-base.php) — abstract durability backbone. Reads synced_at IS NULL batches, POSTs, marks rows synced only on a confirmed 200, retries on next cron run if the POST fails. Idempotent UNIQUE keys on the wpdeploy side mean retries never duplicate.
• AF_Profile_Sync / AF_Interests_Sync / AF_Activity_Sync / AF_Lots_Sync / AF_Bids_Sync — five concrete sync streams.
• AF_Data_Purge (inc/maintenance/class-data-purge.php) — daily cron: 14-day floor on synced rows, 30-day hard cap with CRITICAL alert if any unsynced row hits the cap (which would mean wpdeploy has been unreachable for a month).

New cron schedules (auto-registered on plugins_loaded if auctionforge_update_server_url + _api_key are configured)

| Hook | Schedule | Endpoint |

|---|---|---|

| auctionforge_sync_user_profile | hourly | POST /api.php/sync-user-profile |

| auctionforge_sync_user_interests | hourly | POST /api.php/sync-user-interests |

| auctionforge_sync_user_activity | hourly | POST /api.php/sync-user-activity |

| auctionforge_sync_lots | every 10 min | POST /api.php/sync-lots |

| auctionforge_sync_bids_wins | hourly | POST /api.php/sync-bids-wins |

| auctionforge_purge_synced_data | daily | (purge cron — local) |

All sync handlers are watermarked or synced_at-gated; cron mid-run failure is harmless because the next run picks up the same rows.

Hooks fired

• af_stats_pageview_recorded($url, $email, $visitor_hash) — fires inside AF_Stats_Ajax::handle_track() after a logged-in pageview is recorded. Default listener resolves URL → lot post → AF_User_Interests::record_view().
• af_stats_lot_favorited($email, $post_id) — fires from the existing lot_analytics_record_favorite AJAX handler when a watchlist add happens. Default listener calls record_favorite().

Server-side companion (wpdeploy)

This release is paired with wpdeploy changes (handled out-of-band; not in the plugin zip):

• 5 new API routes matching the sync streams above. All return synced + watermark metadata so the plugin can advance / mark rows synced.
• update_sync_health() helper in wpdeploy — every successful sync POST writes (stream, last_seen_at, last_synced_count, state) into sites.sync_health_json.
• SyncWatchdog — 5-minute cron on wpdeploy that scans every (site × stream) cell and runs an ok → overdue → gone → recovering → ok state machine. Emits alerts via the existing sync_incidents Telegram fan-out.
• People section in the wpdeploy admin — ?tab=people (cross-site rollup with top keywords / lifetime spend), ?tab=person&email=... (drill-down with timeline + bids), ?tab=people-export (Google Customer Match + Meta Custom Audience CSV with sha256 hashing per spec).
• ?tab=sync-health — site × stream traffic-light grid showing every sync's state.

Files Changed

• Created: inc/stats/class-keyword-extractor.php, inc/stats/class-user-interests.php, inc/stats/stop-words.php
• Created: inc/sync/class-sync-base.php, inc/sync/class-profile-sync.php, inc/sync/class-interests-sync.php, inc/sync/class-activity-sync.php, inc/sync/class-lots-sync.php, inc/sync/class-bids-sync.php
• Created: inc/maintenance/class-data-purge.php
• Modified: inc/stats/class-stats-database.php (DB_VERSION = 3, new dbDelta calls, synced_at column adds)
• Modified: inc/stats/class-stats-init.php (require new classes, register sync crons, wire af_stats_pageview_recorded and af_stats_lot_favorited listeners)
• Modified: inc/stats/class-stats-ajax.php (fire af_stats_pageview_recorded after pageview record; fire af_stats_lot_favorited on watchlist add)
• Modified: auctionforge.php (Version: 3.6.4.0 → 3.7.0.0)

Verification on Clumber dev

1. After auto-update + first wp-admin page load: wp_af_stats_lot_keywords, wp_af_user_interests, wp_af_user_recent_activity all exist; af_stats_db_version = 3.

2. Save a test lot titled "Pair of Victorian silver candlesticks by Mappin & Webb" → wp_af_stats_lot_keywords has rows for victorian, silver, candlesticks, mappin, webb (and not pair, of, by).

3. Log in as throwaway test user, view 3 of those lots → wp_af_user_interests shows (test@…, keyword, 'victorian', view_count=3).

4. Wait one hourly cron, confirm wpdeploy.user_interests mirror via the wpdeploy admin → ?tab=people → search for the test email.

5. Confirm wpdeploy.sites.sync_health_json has user-interests.state = 'ok' for the Clumber site.

6. Pause the cron, wait 2h, watch the watchdog flip the cell to overdue and emit a Telegram alert.

Privacy / scope

• Admins and bots are filtered out at write time via AF_Stats_Tracker::should_skip().
• Email is normalized lowercase + trim before storage; phone normalized to E.164 (UK-aware) on the sync side.
• No outbound activation yet — wpdeploy stores everything but doesn't send anything to anyone. Marketing send mechanics (consent flag, suppression list, sender) explicitly deferred.

---

[3.6.4.0] — 2026-05-02

Identity stitching: visitor_hash → user_email

Why

The af_stats_* tables (pageviews, sessions, searches, outbound) and the lot-engagement tables (af_lot_analytics, af_lot_shares) currently store activity keyed only on the anonymous af_vid localStorage hash — there is no link from any browsing event to the user's email even when they're logged in. Without that link, the central wpdeploy server can never aggregate behavioural data on a per-person basis, which is the prerequisite for the cross-site user-data lake being built on wpdeploy (see /root/.claude/plans/i-want-to-add-synthetic-goose.md Phase 1).

This release adds the bridge: every authenticated tracker hit records a (visitor_hash, user_email) pair into a new table. From here on, anonymous browsing can be resolved to an email via JOIN for any session the user was logged in.

Changes

• New table wp_af_stats_visitor_emails — (visitor_hash, user_email, ip_address, first_seen, last_seen) with UNIQUE(visitor_hash, user_email) + index on user_email. Created via dbDelta inside the existing AF_Stats_Database::create_tables() so it ships through the standard plugins_loaded migration path — no manual reactivation needed after auto-update.
• af_stats_db_version bumped 1 → 2. AF_Stats_Init::maybe_create_tables() now compares against the new AF_Stats_Database::DB_VERSION constant rather than a hard-coded < 1, so future schema bumps (Phase 2 onwards) just require constant edits + new dbDelta calls.
• Identity record on every authenticated tracker hit. AF_Stats_Ajax::handle_track() now calls AF_Stats_Visitor_Email_Map::record($visitor_hash, $email, $ip) whenever is_user_logged_in() is true. Trust boundary: the email is read server-side from wp_get_current_user() — clients cannot assert who they are.
• Defensive table-exists guard. The new helper short-circuits silently if the migration hasn't run yet on a given site (race window on the very first request after auto-update); the next request finds the table and proceeds. No fatals, no missing rows.
• Email normalised at write time — lowercase + trim + is_email() validation before storage. Marketing audience match-rates downstream depend on consistent casing.

Files Changed

• Created: inc/stats/class-visitor-email-map.php
• Modified: inc/stats/class-stats-database.php (DB_VERSION constant; new table; drop_tables list)
• Modified: inc/stats/class-stats-init.php (require new helper; migration check uses constant)
• Modified: inc/stats/class-stats-ajax.php (record pair in handle_track)
• Modified: auctionforge.php (Version header bump)

Verification on Clumber dev

1. After auto-update, load any wp-admin/* page once → wp_af_stats_visitor_emails exists, af_stats_db_version = 2.

2. Log in as a test user, browse 5 lots → exactly one row in wp_af_stats_visitor_emails for that (visitor_hash, email) pair, with last_seen updating on each hit.

3. SELECT email FROM wp_af_stats_visitor_emails WHERE visitor_hash IN (SELECT visitor_hash FROM wp_af_stats_pageviews WHERE created_at > NOW() - INTERVAL 1 HOUR) returns the test email — proving the JOIN works.

Privacy / scope

• This change writes a (visitor_hash, email) pair to a single new table on the AF site. Nothing is sent to wpdeploy yet — the sync stream lands in Phase 2.
• Anonymous (logged-out) browsing is unaffected: no row is created until the user authenticates.
• Bots are still skipped via AF_Stats_Tracker::is_bot() before any tracking writes.

---

[3.6.3.1] — 2026-05-01

Fix: New lots never processed + Live console improvements

Why

When BidSpirit adds new lots to an auction (e.g. items 683-692), the sync pipeline correctly staged all 709 lots into import_history but the InsertLotsBS processing loop exited after the first batch of 500 unchanged lots, never reaching the genuinely new lots at the tail of the queue. This caused new lots to remain permanently stuck in staging — synced but never created as WordPress posts.

Separately, the admin Live Console was replaying the entire log history from the beginning on every page load, and showed long silent gaps during API calls with no indication of what the worker was doing.

Fixes

• InsertLotsBS loop break condition — The stage 5 insert loop in CatalogSyncWorker::process() and processDayEnded() previously broke when updated lots === 0, even if the batch had cleared hundreds of unchanged ("unupdated") lots from the queue. New lots with higher IDs were never reached. Now breaks only when both updated lots and unupdated lots are 0, meaning the staging queue is truly empty.
• Live Console starts from current position — consoleSinceId was hardcoded to 0, causing the console to page through the entire af_sync_log table (50 rows at a time) before reaching real-time entries. Now initializes to SyncLogger::getLatestId() so only entries created after page load appear.
• queueIsActive declaration order — Variable was declared after functions that referenced it, causing the console to always start at the slow 3s polling rate even when a worker was active. Moved declaration before first use.
• Progress logging during API calls — LotList::auctionProcessing() made 2-3 BidSpirit API calls with zero SyncLogger entries, creating long silent gaps in the console. Added log entries for API fetch start, response received (with duration), data staged, and API errors.
• Per-auction progress in bulk runs — LotList::run() now logs Processing auction X/Y: {id} for each auction in the bulk loop, and logs skipped auctions.
• processDayEnded insert loop logging — Added batch progress logging and timeout guard matching the process() method pattern. Previously this loop was completely silent.

Files Changed

• Modified: inc/sync/CatalogSyncWorker.php, inc/import/LotList.php, admin/view/sync-status.php

---

[3.6.3.0] — 2026-05-01

Public Auctions API — Token Authentication

Why

The /wp-json/auctionforge/v1/public/auctions endpoint added in v3.6.2.9 was publicly accessible. Since auction data should only be served to authorized aggregator sites, the endpoint now requires a valid auth token.

Changes

• Token verification — The PublicAuctions REST endpoint now validates an X-AF-Token header (or ?token= query parameter) against the site's existing Webhook auth token from AuctionForge settings.
• Returns 401 Unauthorized for missing/invalid tokens and 403 Forbidden if no auth token is configured on the site.
• Uses hash_equals() for timing-safe comparison.

Files Changed

• Modified: auctionforge.php, inc/api/PublicAuctions.php

---

[3.6.2.9] — 2026-05-01

Public Auctions REST API Endpoint

Features

• New REST endpoint GET /wp-json/auctionforge/v1/public/auctions — Exposes auction list data (title, date, image, state, catalog link) for consumption by the AuctionForge Hub plugin on parent/main sites.
• Parameters: type (upcoming or past, default: upcoming), limit (max results, default: 50).
• Handles multi-day auctions with correct part numbers and catalog links.
• Returns auction metadata including auction_id, source_site, and day_index for deduplication.

Files Changed

• Modified: auctionforge.php, inc/coreIncludes.php
• Created: inc/api/PublicAuctions.php

---

[3.6.2.8] — 2026-04-30

Suppress alerts for transient retry conditions

Why

The "BidSpirit API returned 0 lots — catalog may not be ready yet" message is logged when the BidSpirit webhook fires before the auction catalog is fully published. The safety cron retries the job automatically and it usually succeeds on the next attempt — there's no operator action required, so a Telegram alert is just noise.

Fix

• New private helper SyncLogger::isSuppressedFromAlerts($message, $context) matches the message against a substring allowlist of known-transient errors. When matched, the row is still inserted into af_sync_log (so the in-app sync console still shows the retry chain) but the auctionforge_sync_error_logged fan-out action does NOT fire — wpdeploy and Telegram stay quiet.
• Default suppression substrings: "BidSpirit API returned 0 lots", "catalog may not be ready yet".
• Extendable via the new auctionforge_sync_alert_suppress_patterns filter — themes/MU plugins can add their own substrings.

Files Changed

• Modified: auctionforge.php, inc/sync/SyncLogger.php

---

[3.6.2.7] — 2026-04-30

Typo fix

• Settings → Connections tab: the placeholder/help text under the Server field showed https://my-accaunt.bidspirit.com/ (extra "a"). Now reads https://my-account.bidspirit.com/.

Files Changed

• Modified: auctionforge.php, inc/controllers/Settings.php

---

[3.6.2.6] — 2026-04-30

Fix stale plugin_version in reports

Why

Sites were reporting their old version to wpdeploy long after they'd been upgraded — e.g. Lonsdale Auctioneers ran v3.6.1.1 but kept telling wpdeploy it was on v2.9.6. Root cause: the constant AUCTIONFORGE_VERSION is read from the plugin file's Version: header *once at plugin load*, then frozen into $this->current_version on the auto-updater instance. After a plugin upgrade replaces the file on disk, existing PHP-FPM workers keep using the cached constant value until they're recycled, so every report from those workers carries the old version.

Fix

• New helper AuctionForge_Auto_Updater::get_live_version() reads the version directly from the plugin file's header on each call (via get_file_data() — uncached).
• report_health, push_sync_error_immediate, and retry_sync_errors now send get_live_version() instead of the cached constant.
• The pre-existing iteration through active plugins inside report_health already used get_plugin_data() per plugin, so secondary plugin entries were already accurate; only the top-level plugin_version field was stale.

Files Changed

• Modified: auctionforge.php, inc/class-auto-updater.php

---

[3.6.2.5] — 2026-04-30

Real diagnostics for plugin self-updates

Why

The wpdeploy update_queue table had a 46% historical failure rate, but every single failure row stored the literal string "Installation failed" — collapsing every failure mode into one opaque error with no diagnostic value. Root cause: the install_update() method in both clients (AF auto-updater and wpd-client) treated Plugin_Upgrader::upgrade() as a boolean, throwing away WP_Error objects and skin-emitted error messages.

Fixes (inc/class-auto-updater.php install_update())

• Refreshes the update_plugins transient before invoking the upgrader. The upgrader reads from this transient to know what version to download; if WP hasn't checked recently, the upgrader silently returns false (looking like a failure even though there's a real update queued at wpdeploy).
• Distinguishes WP_Error, false/null, and success. WP_Error was previously treated as truthy → reported as "completed" even on failure. Now extracts the error code and message.
• Reads Automatic_Upgrader_Skin::get_errors() to surface the real upgrader-emitted error messages.
• Reads $upgrader->result which holds the final WP_Error for some failure paths.
• Captures PHP errors/warnings emitted during the upgrade (file-move issues, etc.) via a temporary set_error_handler.
• Detects "no update in transient" as a distinct failure cause and labels it explicitly so we know it's a transient-cache problem, not an actual install failure.
• Truncates the combined diagnostic to 1000 chars before sending.

The same fix is applied to wpd-client.php (the WPD client plugin shipped from client-plugin/wpd-client.php on the wpdeploy server).

Files Changed

• Modified: auctionforge.php, inc/class-auto-updater.php

---

[3.6.2.4] — 2026-04-30

Bulk-sync worker dispatch fix

Fixes

• The HTTP-loopback worker (auctionforge_rest_sync_worker in auctionforge.php) had its own switch statement for job-type dispatch, distinct from the one in crontasks/syncWorker.php. The new full_sync_upcoming and full_sync_past job types were only added to the CLI worker, so the loopback path produced "Unknown job type" errors. Both switches now route those types to BulkSyncWorker::process.
• inc/coreIncludes.php now require_onces BulkSyncWorker.php so the class is available wherever sync code runs.

Files Changed

• Modified: auctionforge.php, inc/coreIncludes.php

---

[3.6.2.3] — 2026-04-30

Fixes for end-to-end Telegram round-trip

Fixes

• verify_api_key reads the option fresh on every call (hash_equals against get_option('auctionforge_update_api_key')) instead of relying on the cached $this->api_key from constructor time. Different FPM workers can hold different cached values when the option drifts (e.g. via auto-heal collisions), which previously produced intermittent 401s on REST endpoints.
• New REST endpoint POST /wp-json/auctionforge/v1/sync/version — wraps the existing trigger-install flow with a JSON response (always HTTP 200 with success flag). The original endpoint returned WP_Error('no_update', …, status: 404) when the plugin was already on the latest version, which nginx's error_page 404 directive then clobbered with a static HTML 404 page on hosts using aaPanel/BTWAF. Keeping the URL under /sync/* matches the pattern that's already proven to pass through host WAFs.

Files Changed

• Modified: auctionforge.php, inc/class-auto-updater.php

---

[3.6.2.2] — 2026-04-29

Catalog-sync kind disambiguation

Fix

• catalog_sync jobs target a single auction that may be either active or archived. Until now their alerts were always classified as kind=upcoming. The classifier now resolves the auction's auction_state term meta and routes:
• ARCHIVED / ENDED / POST_AUCTION → kind=past → Kill + Full Past buttons
• anything else (or unresolvable) → kind=upcoming → Kill + Full Upcoming buttons

Files Changed

• Modified: auctionforge.php, inc/class-auto-updater.php

---

[3.6.2.1] — 2026-04-29

Telegram Sync Monitoring follow-ups

Features

• Context-aware alert buttons. Each Telegram alert now shows the action set most relevant to the failing sync: upcoming-sync errors get Kill + Full Upcoming, past-sync errors get Kill + Full Past, everything else gets Kill only. Button choice is driven by a new kind field classified at log-write time from the queue's job_type.
• Plugin version in alerts + Update button. Each push now includes the live plugin_version. wpdeploy compares it to the latest is_stable=1 row in its versions table and only renders an Update plugin button when the site is behind. Tapping Update calls the existing POST /wp-json/auctionforge/v1/trigger-install endpoint to force the upgrade.

Architecture

• New private helper AuctionForge_Auto_Updater::classify_error_kind($jobId) looks up the job's job_type and maps it to 'upcoming' / 'past' / 'other'. Used by both the immediate push and the 1-min retry cron.
• Outbound payloads now include plugin_version at the top level; wpdeploy refreshes sites.plugin_version on every /sync-errors POST.

Files Changed

• Modified: auctionforge.php, inc/class-auto-updater.php

---

[3.6.2.0] — 2026-04-29

Telegram Sync Monitoring & Remote Control

Features

• Instant Telegram alerts on sync errors. Any level='error' row written to af_sync_log is pushed (fire-and-forget, non-blocking) to wpdeploy, which fans it out to a configured Telegram group with inline-keyboard action buttons (Kill / Full Upcoming / Full Past / Acknowledge).
• Remote command surface. Any group admin can tap a button to:
• Kill sync — flips DB flags via SyncQueue::cancelAll(), then SIGTERMs every active worker; a 5-second watchdog escalates to SIGKILL for any survivor.
• Full sync upcoming — full re-import of every active auction and its lots (queued, observable, killable). Replaces the re-sync?do=importBidSpiritUpcoming flow with a queued equivalent.
• Full sync past — same, for archived auctions.
• Safety-net retry cron (auctionforge_retry_sync_errors, every minute) re-pushes recent error rows. wpdeploy dedupes via UNIQUE(site_id, af_log_id) so duplicates are silent.

Architecture

• SyncLogger::log() now fires do_action('auctionforge_sync_error_logged', …) on level='error' so any handler can react. The auto-updater listener does a 2 s non-blocking POST to /api.php/sync-errors.
• New REST endpoint POST /wp-json/auctionforge/v1/sync/cancel-all (X-API-Key auth) — runs SyncQueue::cancelAll() + SIGTERM + watchdog. Logs every action through SyncLogger.
• POST /sync/start extended with a mode parameter (upcoming default, past for archived). Bulk re-sync is now a queued job, not a synchronous block.
• New job types full_sync_upcoming and full_sync_past on SyncQueue, dispatched to a new BulkSyncWorker that wraps the existing AuctionList::init() + LotList::init($upcoming) pipeline.
• syncWorker.php installs a SIGTERM handler that flips the in-flight job to failed with a "Killed by admin (SIGTERM, cleanup OK)" marker and closes the DB cleanly before exiting. Watchdog escalates to SIGKILL after 5 s grace.
• LotList::auctionProcessing() now heartbeats the active bulk-sync job between auctions, preventing the safety cron from auto-failing long bulk runs as stale (the 600 s threshold is unchanged).

Files Changed

• Modified: auctionforge.php, inc/sync/SyncLogger.php, inc/sync/SyncQueue.php, inc/class-auto-updater.php, crontasks/syncWorker.php, inc/import/LotList.php
• Created: inc/sync/BulkSyncWorker.php

---

[3.6.1.6] — 2026-04-29

High-Value Lot Modes for [bp_lot_list]

Features

• high_value_past mode — Displays past auction lots ordered by their catalog estimate (estimatedPriceInt), highest first. Useful for "Top Lots" or "Highlights" sections.
• high_value_sold mode — Displays past sold lots ordered by their actual sold price (soldBid), highest first. Only includes genuinely sold lots (soldBid > 0) and reuses the same false-positive guard as random_past to skip lots where soldBid was carried over from startPrice without real bidding activity.
• Admin documentation updated — The Shortcodes reference page in WP Admin now lists both new modes in the mode attribute description and includes example shortcode usage.

Architecture

• New constants MODE_HIGH_VALUE_PAST and MODE_HIGH_VALUE_SOLD on LotsWidget.
• New method LotsWidget::getLotListHighValue($mode, $limit) builds the query, applies the past-auction tax filter, sets bp_orderby to the relevant meta field with DESC order, and (for the sold variant) filters out unsold-but-stale lots in PHP.
• New filter hook bp_lot_list_high_value_args_filter for downstream customization of the WP_Query args.

Files Changed

• Modified: inc/widgets/LotsWidget.php, inc/controllers/ShortcodesPage.php

---

[3.6.0.18] — 2026-04-25

Brevo SMS Notifications Integration

Features

• Transactional SMS via Brevo API — The plugin now sends text message alerts through the Brevo transactional SMS service, running alongside existing Firebase push notifications.
• Four Notification Types:
• New Auction Published — Broadcast SMS to all opted-in subscribers when an auction is published.
• Auction Starting Soon — Targeted SMS to users registered for an auction when it is about to start.
• Favorited Item Live Soon — Targeted SMS to users who favorited a lot when it is approaching in the auction.
• Outbid Notice — SMS sent when a user's leading bid is surpassed, with a 5-minute per-item cooldown to prevent spam.
• SMS Subscriber Database — New af_sms_subscribers table stores user phone numbers, country codes, and per-notification-type opt-in preferences (GDPR-ready explicit consent).
• Admin Settings Tab — New "SMS Notifications" tab in Settings with:
• Brevo API Key input
• SMS Sender Name (11 char max)
• Master enable/disable toggle
• Per-notification-type on/off switches
• Test SMS widget with phone input and send button
• Live subscriber count display
• Profile SMS Preferences — Users can opt into SMS notifications directly from their profile page with phone number entry and granular notification type selection.

Architecture

• BrevoSMS Service (inc/services/BrevoSMS.php) — cURL-based API wrapper with broadcast, targeted, and single-send methods, message builders with 160-char limit awareness, rate limiting, and comprehensive error logging.
• SMSSubscriber Model (inc/model/SMSSubscriber.php) — CRUD operations, email-to-phone resolution, opt-in filtering, and upsert logic.
• Webhook Integration — SMS dispatch hooks added to AuctionsAPI.php methods: leading_bid_surpassed(), item_live_soon(), auction_starts_soon(), and auctionPublishedPush().

AJAX Handlers

• auctionforge_sms_save — Save SMS preferences from profile page
• auctionforge_sms_load — Load SMS preferences for profile page
• auctionforge_sms_test — Admin-only test SMS endpoint

Database

• New table: af_sms_subscribers — Phone numbers, country codes, per-notification opt-ins, timestamps

Files Changed

• Modified: auctionforge.php, inc/coreIncludes.php, inc/controllers/AuctionsAPI.php, inc/controllers/Settings.php, admin/view/settings.php, templates/parts/profile-templates.php
• Created: inc/services/BrevoSMS.php, inc/model/SMSSubscriber.php

---

[3.6.0.7] — 2026-04-14

Hotfix

Fixes

• Namespace resolution — Fixed fatal error in wp_footer commission label hook caused by unqualified SettingsHelper and Settings class references. Now uses fully qualified namespaces.

Files Changed

• Modified: auctionforge.php

---

[3.6.0.6] — 2026-04-14

Commission Label Override Fix

Fixes

• Theme template override compatibility — Moved the commission label JS override from the single-lot.php template into auctionforge.php via wp_footer hook (priority 99). Sites with theme-level template overrides (e.g. themes/*/auctionforge/single-lot.php) were not picking up the inline script. The wp_footer approach works universally on all single lot pages.

Files Changed

• Modified: auctionforge.php, templates/single-lot.php

---

[3.6.0.5] — 2026-04-14

Commission Label Override

Features

• Commission Label Setting — New dropdown in Settings → Appearance allowing admins to choose between "Buyer's Premium" (default) and "Auction House Commission" as the label displayed on lot pages. This overrides the Bidspirit JS client's default label using a MutationObserver that catches asynchronously injected text.

Files Changed

• Modified: inc/controllers/Settings.php, templates/single-lot.php

---

[3.6.0.4] — 2026-04-12

Auction Approval Modal Redesign

Changes

• Removed BidSpirit Terms of Use — The generic BidSpirit "Terms of Use" section that appeared at the top of the non-credit-card approval modal has been removed. The modal now shows only the auction house's own legal agreements managed within the plugin.
• Renamed Modal Title — Changed "Terms of conditions" to "Terms & Conditions".
• Larger Scroll Area — The Terms & Conditions scroll box is now 350px tall (up from 200px) for easier reading.
• Proportional Section Heights — Refund & Return Policy and Chargeback Waiver sections use a shorter 260px scroll box to visually distinguish them from the primary Terms & Conditions.

Files Changed

• Modified: templates/js-chunks/approval-info.php, assets/js/app.js

---

[3.6.0.2] — 2026-04-10

Webhook Token Generator

Features

• Token Generator Widget — Added a 16-character random token generator directly below the "Webhook auth token" field on the Settings page. Includes a "Generate Token" button and a clipboard copy icon with visual feedback.

Files Changed

• Modified: inc/controllers/Settings.php

---

[3.6.0.1] — 2026-04-10

Patch

Changes

• Version bump.

---

[3.6.0.0] — 2026-04-10

Legal Agreements for Auction Approval

Features

• Terms & Conditions — A mandatory, scrollable Terms & Conditions document is now displayed during the auction approval process. Bidders must scroll to the bottom and check an agreement box before their approval request is submitted. Always enabled.
• Refund & Return Policy — An optional, scrollable Refund & Return Policy can be enabled in Settings. When enabled, bidders must read and accept it during auction approval.
• Chargeback Waiver — An optional, scrollable Chargeback Waiver can be enabled in Settings. When enabled, bidders must read and accept it during auction approval.
• Admin Management — New "Legal Agreements" page under the Bidspirit admin menu with tabbed TinyMCE editors for each agreement type. Includes automatic version numbering (incremented on content change) and full version history.
• Consent Logging — Every agreement acceptance is logged to a dedicated database table (af_user_agreement_log) with the agreement type, version, user email, IP address, user agent, auction ID, and timestamp.
• User Tracking Integration — Agreement events (terms_agreement, refund_agreement, chargeback_waiver) are also recorded in the existing IP tracking system alongside registration, login, and bid events.
• Placeholder Content — Default sample content is seeded on plugin activation for all three agreement types.

Settings Added

• Enable Refund & Return Policy — Toggle to require bidders to accept the refund policy during auction approval.
• Enable Chargeback Waiver — Toggle to require bidders to accept the chargeback waiver during auction approval.

Database

• New table: af_legal_agreements — Current active agreement content per type
• New table: af_legal_agreement_versions — Version history archive
• New table: af_user_agreement_log — User consent records

Files Changed

• Modified: auctionforge.php, inc/controllers/Settings.php, inc/controllers/BidspiritViews.php, inc/ip-logger.php, templates/js-chunks/approval-info.php, assets/js/app.js
• Created: inc/legal/class-legal-agreements.php, admin/view/legal-agreements.php

---

[3.5.0.6] — 2026-04-08

Bid Event Tracking

Features

• Bid Tracking — All successful bids (regular, catalog, pre-sale buyout, post-sale purchase) now fire afLogIP("bid", bidspiritUser) to capture the bidder's full identity in the user tracking table.
• Whitelist Update — Added bid to the allowed event_type values in both the local plugin and the central WPDeploy API.

---

[3.5.0.5] — 2026-04-08

Self-Healing Database Schema

Features

• Auto-Migration — The plugin now auto-detects and adds any missing tracking table columns on version upgrade, ensuring sites with older schemas seamlessly migrate without manual SQL.

---

[3.5.0.4] — 2026-04-08

API Key Auto-Healing

Features

• Seamless Self-Registration — The WordPress plugin now autonomously regenerates and saves a fresh API Key whenever WPDeploy rejects a payload with an api_key_collision error. This guarantees zero-downtime security handovers when developers clone instances to proxy/staging servers.

---

[3.5.0.3] — 2026-04-08

API Key Collision Defense

Features

• Network-Level Quarantine — Central API dynamically extracts and strictly validates the incoming payload domain against the registered API Key domain, forcefully blocking mismatched traffic (HTTP 403).
• Local Critical Alert Banner — Added a persistent crimson warning banner in the WordPress admin panel that intercepts api_key_collision errors, directly instructing developers to update cloned keys.

---

[3.5.0.2] — 2026-04-08

Modal Trigger Hotfix

Fixes

• Restructured internal UI rendering priority to gracefully deploy the inline Modal triggers inside custom IP log view without colliding with cached z-index stacks.

---

[3.5.0.1] — 2026-04-08

Hotfix

Fixes

• Timed Auction Badge Visibility — Fixed a strict type-matching bug in the main auction_list.php core file that incorrectly hid the "Timed Auction" badge overlay from valid timed/online auctions on the main upcoming/archive views. The badge now displays properly across all manual and Bidspirit-synced objects when toggled on.

Files Changed

• Modified: templates/main/auction_list.php

---

[3.2.9.1] — 2026-03-30

Timed Auction Display Enhancements

Features

• Timed Auction Countdown Text Toggle — Added a WP-Admin setting "Change text to 'Auction will close in'" that conditionally changes the countdown label for timed/online auctions on single lot pages.
• Shortcode Text Toggle Support — Extended the new countdown text logic to the bp_upcoming_wide shortcodes so "Live bidding starts in:" successfully transitions to "Auction will close in:" for timed auctions.

Files Changed

• Modified: inc/controllers/Settings.php, templates/single-lot.php, templates/shortcodes/upcoming-auction-wide.php, templates/shortcodes/upcoming-auction-wide-manual.php

---

[3.2.9.0] — 2026-03-29

Billing & Invoices Polish

Fixes

• Profile Invoice ID Tracking — Prevented internal auction codes (e.g. 002 or ai4) from breaking into the clean hyphenated titles inside the profile-templates.php view.
• Dynamic Payment Statuses — Replaced Bidspirit's default/cached NOT PAID HTML payloads by wiring the dompdf generator to directly respect the current $b.status string from the API (resolving instances where a paid invoice still printed "NOT PAID" atop the document).
• Payment Instructions Conditional — Automatically hide the "Payment Instructions" block from the PDF footer when an invoice is fully paid.
• Improved Nomenclature — Changed "Invoice No:" to "Bidder No:" on document output to prevent confusion with static invoice ledger IDs.

---

[3.2.6.0] — 2026-03-28

Multi-Day Auction Lot Filtering Fix

Fixes

• Day 2+ showing lots from Day 1 in multi-day auctions — The itemIndex column in bp_meta_data is varchar(55), but the day-range filter in BidspiritQuery::bp_query_where() was comparing it as a string. With string comparison, lot numbers like '11', '101'–'145' incorrectly fell between '1001' and '1450', causing Day 1 lots to leak into Day 2 results. Fixed by using CAST(bpMeta.itemIndex AS UNSIGNED) for numeric comparison and intval() on the PHP-side boundary values. Letter lots (e.g. 14A, 1025A) are handled correctly — CAST strips the suffix, keeping them grouped with their base lot number.

Files Changed

• Modified: inc/controllers/BidspiritQuery.php

---

[3.2.5.9] — 2026-03-27

Catalog Page Fix

Fixes

• Duplicate preview hours on catalog pages — The displayHours field was rendered twice: once via the bp_after_description_auction hook in BidspiritViews.php and once inline in the auction template. Removed the hook-based rendering to eliminate the duplication.

Files Changed

• Modified: inc/controllers/BidspiritViews.php, templates/main/auction.php

---

[3.2.5] — 2026-03-19

Sync Reliability & Stuck Lot Prevention

Fixes

• CATALOG_PUBLISHED webhook now triggers catalog sync — Previously only sent push notifications without syncing lots. When the earlier AUCTION_CATALOG_UPDATED fired before the catalog was ready on BidSpirit, lots were never imported. CATALOG_PUBLISHED now calls auctionCatalogUpdated() to trigger a full catalog sync when the catalog is actually available.
• 0-lot API results now fail instead of silently succeeding — When BidSpirit API returns 0 lots (catalog not yet ready), the sync job now fails with an explicit error message, allowing the next webhook to create a fresh retry job.
• Expanded CDN allowlist in pre_http_request filter — The HTTP filter during bulk post insertion now allows all *.bidspirit.com subdomains and BidSpirit image CDNs (fastly.net, cloudfront.net). Previously only bidspirit.com and www.bidspirit.com were allowed, blocking image downloads during sync and causing worker hangs.
• InsertLotsBS timeout guard — Stage 5 (InsertLotsBS processing loop) now has a 180-second timeout and logs progress every 2 batches. Prevents indefinite hangs that previously required manual force-kill.
• fixResult() no longer marks lots as done when postId=0 — When lotProcessing() fails to create a WP post, the staging row now keeps syncFinished=0 so the lot is retried on the next sync pass, instead of being permanently marked as complete with no actual post.
• lotProcessing() logs error on missing auction term — Previously returned 0 silently when Auction::findAuctionById() failed. Now logs an explicit error that feeds into fixResult() to keep the lot retryable.
• Hourly orphan detection in safety cron — New step in syncSafety.php detects lot posts that exist in bp_meta_data but are missing their auction taxonomy assignment (caused by workers killed mid-batch) and auto-repairs them with wp_set_object_terms().

Files Changed

• Modified: inc/controllers/AuctionsAPI.php, inc/sync/CatalogSyncWorker.php, inc/abs/InsertLotsAbstract.php, inc/import/InsertLotsBS.php, crontasks/syncSafety.php

---

[3.2.4] — 2026-03-18

Sync Worker Hang Fix

Fixes

• Sync workers hanging at InsertLotsBS stage — Third-party plugins (Smush Pro, SmartCrawl SEO, WPMU DEV Updates) hook into wp_insert_post() and make blocking outbound HTTPS calls for every lot processed. With 489+ lots per auction, this caused workers to hang indefinitely on socket reads to WPMU DEV servers (32.193.94.25, 32.193.93.106). Added WP_IMPORTING constant at the REST worker entry point and a pre_http_request filter in CatalogSyncWorker that blocks all non-essential external HTTP during the batch post-insertion phase. Loopback (127.0.0.1, localhost) and BidSpirit API calls remain allowed.
• Stuck staging rows after force-kill — When workers were force-killed mid-sync, staging rows in import_history were left with syncstart=1 and never unblocked. Subsequent sync runs could not see these rows (filtered out by Lot::getRawLots()), causing the InsertLotsBS loop to exit immediately with 0 posts processed. Combined with job deduplication (SyncQueue::enqueue() skips if a processing job exists), this created a deadlock where no new sync could proceed.

Files Changed

• Modified: auctionforge.php, inc/sync/CatalogSyncWorker.php

---

[3.2.2] — 2026-03-17

Full Sync Auction Discovery Fix

Fixes

• Full Sync finds no auctions on fresh sites — The v3 full_sync action only queried the WordPress database for existing auction terms, but on a freshly deployed site the database has zero auctions. Added AuctionList::init() discovery step before querying the DB, so Full Sync now fetches all auctions from the BidSpirit API and creates taxonomy terms first, then enqueues catalog sync jobs for each.

Files Changed

• Modified: auctionforge.php

---

[3.2.0] — 2026-03-14

Webhook Pipeline Fixes, Archive Sync & Admin UI Overhaul

New Features

• Archive Sync — New "Archive Sync" button on Sync Status admin page. Enqueues catalog sync jobs for all ARCHIVED/ENDED auctions. Past auctions now appear in the auction dropdown with an optgroup separator and state label.
• Sync Tasks v3 — Replaced old v2 task cards (importData, importBidSpirit, lotBidSpiritOld) with v3 queue-based tasks. "Sync Active Auctions" and "Sync Archived Auctions" now enqueue jobs via the queue system. Maintenance tasks (Clean Draft/Trash Lots, Clean Orphaned Meta) remain as direct-execution tasks.
• How It Works guide rewritten — Complete rewrite of the admin guide for v3 architecture. Documents webhook-first flow, all 5 job types, queue system mechanics, cron setup (external + WP-Cron), configuration constants, and troubleshooting.

Fixes

• Dual-write removed — Removed legacy handlers from auctionCatalogUpdated(), auctionDayEnded(), and itemsUpdated() webhook methods. The old handlers were racing with the v3 worker, creating orphaned staging rows in import_history that were never processed. All three methods now exclusively use the v3 enqueue → spawn path.
• ITEMS_UPDATED webhook — Fixed itemsUpdated() failing to enqueue jobs. The ITEMS_UPDATED payload has auctionId nested in itemsByLanguage.{lang}[0].item.auctionId, not at the top level. Added extraction logic to resolve it.
• ItemUpdateWorker incomplete — ItemUpdateWorker::process() was only calling Lot::bulkSave() (staging table) without running InsertLotsBS to process staged data into WP posts and bp_meta_data. Added the InsertLotsBS processing step with autocommit restore. Item updates now flow: stage → InsertLotsBS → WP post + meta → cache clear.
• Worker spawn reliability — Changed SyncQueue::spawnWorker() from non-blocking HTTPS to blocking HTTP loopback (http://127.0.0.1 with explicit Host header, 2s timeout). Fixes nginx 403/404 errors when HTTPS loopback hits the default vhost instead of the site's vhost.
• API token constant — Plugin expects AUCTIONFORGE_API_TOKEN in wp-config.php (renamed from UCO_API_TOKEN during the plugin rename). Documented in readme.

Database

• DB version: 22 → 23

Files Changed

• Modified: inc/controllers/AuctionsAPI.php, inc/sync/ItemUpdateWorker.php, inc/sync/SyncQueue.php, auctionforge.php, admin/view/sync-status.php, readme.txt

---

[3.0.0] — 2025-03-14

New Feature: Webhook-First Sync Architecture (Sync v3)

Overview: Complete redesign of the BidSpirit data synchronisation pipeline. Replaces the old two-phase polling system (importBidSpirit every hour + importData every minute) with a webhook-driven job queue that processes data in near real-time.

Architecture

• Webhook-driven sync — BidSpirit webhooks now enqueue jobs into a dedicated queue table (af_sync_queue) instead of relying solely on polling cron tasks. Data flows: webhook → queue → background worker → WordPress posts.
• Dual-write mode — During transition, webhooks enqueue jobs AND still run the legacy handlers. Once verified, legacy handlers can be removed cleanly.
• Job deduplication — Prevents duplicate work by checking for existing pending/processing jobs with the same auction_id + job_type.

New Components

• Job Queue System (inc/sync/SyncQueue.php) — Priority-based FIFO queue with atomic job claiming, status tracking (pending/processing/completed/failed/skipped), worker PID tracking, and automatic stuck job recovery.
• Sync Logger (inc/sync/SyncLogger.php) — Real-time log table for admin console polling with level filtering (info/success/warning/error) and incremental cursor-based retrieval.
• Catalog Sync Worker (inc/sync/CatalogSyncWorker.php) — Processes catalog_sync, full_sync, and day_ended jobs by reusing existing LotList::singleRun() logic.
• Item Update Worker (inc/sync/ItemUpdateWorker.php) — Processes individual item_update jobs with the same logic as the webhook itemsUpdated handler.
• Background Worker (crontasks/syncWorker.php) — Async CLI process spawned by webhooks via exec() or by the safety cron. Claims and processes queued jobs with a configurable timeout (default 240s).
• Safety Net (crontasks/syncSafety.php) — Hourly cron that resets stuck jobs (>10min), spawns workers for pending jobs, runs a 24-hour health check (auto-enqueues full sync if no webhooks received), and purges old data.

Admin UI

• Queue Status Dashboard — New card on Sync Status page showing pending/processing/completed/failed/skipped counts, recent jobs table with real-time refresh, worker status badge, and action buttons:
• Full Sync — Enqueues catalog sync for all active auctions
• Sync Selected — Enqueue a single auction from dropdown
• Spawn Worker — Manually trigger a background worker process
• Live Console — Dark-themed terminal console on the Sync Status page. Polls af_sync_log every 1.5s showing timestamped, color-coded log entries from webhooks, workers, queue operations, and the safety cron. Supports pause, clear, and auto-scroll.

Cron Changes

• Removed importData (ran every minute — ~1,440 PHP executions/day)
• Removed importBidSpirit (ran hourly — ~24 PHP executions/day)
• Added syncSafety (runs hourly at :10 — 24 PHP executions/day)
• Net effect: ~62 PHP executions/hour → 1 PHP execution/hour
• WP-Cron safety hook (auctionforge_sync_safety) — Always-active hourly event, independent of external cron
• setup.sh v3 — Updated task definitions, new migrate command for interactive v2→v3 transition

Database

• New table: af_sync_queue — Job queue with status, priority, source, attempts, worker PID, timing columns
• New table: af_sync_log — Real-time log entries with context, level, auction_id, job_id
• DB version: 20 → 22

Constants Added

| Constant | Default | Description |

|---|---|---|

| AUCTIONFORGE_SYNC_WORKER_TIMEOUT | 240 | Worker process timeout in seconds |

| AUCTIONFORGE_SYNC_STALE_JOB | 600 | Seconds before a processing job is considered stuck |

| AUCTIONFORGE_SYNC_HEALTH_CHECK | 86400 | Seconds without webhook before triggering full sync |

| AUCTIONFORGE_SYNC_LOG_RETENTION | 7 | Days to keep log entries |

| AUCTIONFORGE_SYNC_QUEUE_RETENTION | 30 | Days to keep completed queue jobs |

| AUCTIONFORGE_CURL_TIMEOUT | 30 | BidSpirit API cURL timeout in seconds |

| AUCTIONFORGE_PHP_BINARY | /www/server/php/83/bin/php | PHP CLI binary path for spawning workers |

AJAX Handlers Added

• auctionforge_sync_log_poll — Incremental log polling for live console
• auctionforge_sync_queue_status — Queue counts + recent jobs for dashboard
• auctionforge_sync_enqueue — Admin-triggered sync actions (full_sync, sync_auction, spawn_worker)

Fixes

• cURL timeout — BidSpiritRequest now enforces a 30-second timeout (was unlimited/0), preventing hung connections from blocking the sync pipeline.

Files Changed

• Modified: auctionforge.php, inc/coreIncludes.php, inc/controllers/AuctionsAPI.php, inc/BidSpiritRequest.php, admin/view/sync-status.php, crontasks/setup.sh
• Created: inc/sync/SyncQueue.php, inc/sync/SyncLogger.php, inc/sync/CatalogSyncWorker.php, inc/sync/ItemUpdateWorker.php, crontasks/syncWorker.php, crontasks/syncSafety.php

---

[2.7.3.0]

Fixes

• Various stability improvements and bug fixes.

[2.7.1.2]

Fixes

• Added missing vatAndCommission() function in loadBid() — the sales tax display on single lot pages was never being rendered because the code to call loadTemplate for vat-and-commission-template was missing from app.js.

[2.7.1.1]

Fixes

• 2 decimal places now only appear in the bid modal (Your max bid, Total Price) via showDecimals flag. Start price, increments list, and other prices show whole numbers as before.

[2.7.1.0]

Fixes

• Fixed Buyer's Premium value not showing on single lot pages.

[2.7.0.9]

Fixes

• Fixed fatal error during plugin install/upgrade: class-stats-database.php require failure.

[2.7.0.0]

New Features: Advanced Lot Analytics

• Conversion Tracking, Peak Viewing Times, Pre-Sale vs Live Comparison, Category Performance, Share Analytics, Search → View Funnel, Click-Through Tracking, CSV Export, Hot Lot Badge.
• New DB table: af_lot_shares. New columns on af_lot_analytics. DB version bumped to 20.

[2.6.0.0]

New Feature: Lot Analytics

• Comprehensive lot view and favorite tracking system with admin dashboard.

[2.5.0.0]

New Features

• Site Statistics System — Full website analytics built into the plugin admin.
• Recently Viewed Items — Profile page tab showing last 20 viewed lots per user.

AuctionForge Changelog

All notable changes to the AuctionForge plugin are documented in this file.

---

[3.7.1.12] — 2026-07-20

Fixed — Open-invoices banner ignored the "Enable My Invoices tab" setting

The site-wide "⚠ This account has open invoices / Pay Now" banner rendered for logged-in users with unpaid BidSpirit bills even on sites where the My Invoices profile tab is disabled — and its "Pay Now" button linked to #bp-bills, a tab that does not exist on those sites, so it led nowhere. checkUnpaidBillsBanner() had no gate on the setting.

BidspiritViews::bp_footer() now emits window.afBillingTabEnabled, computed from the same enable_billing_tab expression that gates the tab markup in profile-templates.php (so banner and tab can never disagree), and checkUnpaidBillsBanner() returns immediately when it is false — no banner, and no bills/getUnpaidBills / unpaid-status AJAX traffic on such sites. Sites with the tab enabled are unchanged. No schema or config-version change.

Fixed — US auction houses resolved to the UK "Catalogue" dialect in Auto mode (regression)

Restores the address-signature detection that was lost in an earlier merge (originally fixed 2026-06-26, silently reverted by a later version sync). US house addresses typically name no country and end in "City, ST 12345", so Dialect::captureRegionFromAuctions() took the "ST 12345" tail as an unknown country name and resolved UK. countryToDialect() now takes the full address and recognises a US state code + 5-digit ZIP tail (const US_STATE_CODES, uppercase-only match), plus a bare trailing ZIP with a $ currency as a secondary signal. Conservative by design: named countries still resolve UK — Canadian ("ON M5V 3L9") and Australian ("WA 6000", 4-digit postcode) tails cannot match the 5-digit requirement.

Fixed — LiteSpeed cache purges during sync stacked "Purge url" admin notices

CachePurge purged per-lot URLs via the public litespeed_purge_url action, which calls Purge::purge_url() with $quite=false and enqueues a dismissible admin notice per URL — a full-auction sync stacked hundreds of "Purge url …" notices on the next wp-admin page and looked like a fault to clients. Purges now call \LiteSpeed\Purge::cls()->purge_url($u, false, true) directly (identical purge, no notice), falling back to the action when the class is unavailable. Manual purges elsewhere keep their confirmations.

Fixed — Sync log wrote one row per skipped auction

LotList::updateData() logged " Skipping auction N (excluded or not matched)" for every excluded auction on every worker run — the dominant source of af_sync_log table growth on multi-house sites (observed in the GBs fleet-wide). It now counts the skips and writes a single "Skipped N/M auctions (excluded or not matched)" summary line per run. The per-auction detail remains available via Debug::logData().

Housekeeping

Removed stray .bak working files (auctionforge.php.bak-*, readme.txt.bak-verbump, app.js.prephonebypass-*.bak, CachePurge/BidspiritViews backups) that had been shipping inside the plugin tree since 3.7.1.4.

[3.7.1.11] — 2026-07-20

Added — "Auction is live" popup on single-lot pages

When BidSpirit reports an auction as live, single-lot pages now show the "Auction is live — Enter live auction" popup (linking to the BidSpirit bidding console), exactly as auction catalogue pages already did. Previously a one-lot auction had no live indication anywhere on the site, because its catalogue URL redirects straight to the lot page and only the catalogue code path surfaced the live state. (Entry backfilled — 3.7.1.11 shipped with this note in readme.txt only. 3.7.1.10 was an internal bump with no separate changes.)

[3.7.1.9] — 2026-07-14

Fixed — Catalog pagination stayed broken for returning visitors (stale session)

Follow-up to 3.7.1.8. That fix stopped *new* sessions from getting a bad per-page baseline, but a returning visitor whose session already held the old baseline (the session cookie lives 24h) kept getting page 2+ reset to page 1 at any non-default items-per-page — only a full "clear site data" (which drops the session cookie) fixed it for them.

The server no longer resets pagination from session state at all. Per-page changes already return to page 1 on the client (the items-per-page dropdown navigates to the page-1 URL), so the session-based reset in BidspiritLots::search_filter() and bidspirit_lot_per_page() was both redundant and the source of the stale-baseline problem — it has been removed. Pagination is now correct for every visitor (new or returning, any session state) on the next page load, with no cache/cookie clearing required. No schema or config-version change.

[3.7.1.8] — 2026-07-14

Fixed — Catalog pagination broke at any non-default "Items per page"

On auction catalog pages, setting Items per page to any value other than the site's WordPress default (posts_per_page) made page 2 and beyond redirect straight back to page 1 — so it appeared to "show the same lots" — while the value matching the default worked. BidspiritLots::bp_session_starter() seeded the per-page change-detection baseline from get_option('posts_per_page'); because auction pages are served from full-page cache / behind a CDN that drops the PHP session cookie, that baseline reset to the default on every request, so any non-default size looked "just changed" on every page load and was force-redirected to page 1 by maybe_redirect_to_first_page().

The baseline is now seeded to null ("unknown previous value"), matching the existing category/search baselines, so a page reset only fires when a genuinely-known prior per-page value differs (isset && !== null && !=). The items-per-page dropdown additionally returns to page 1 client-side, so "change size → page 1" no longer depends on the session. No schema or config-version change.

[3.7.1.7] — 2026-07-13

Added — Per-house toggle to bypass phone verification (UK houses auto-bypass)

BidSpirit's users/phone/sendPhoneVerificationCode returns a generic UNKNOWN_ERROR for UK houses (e.g. rosanreeves, edwards) even for valid +44 mobiles, because SMS/phone-verification is not provisioned on those BidSpirit accounts. As the requirement is enforced only plugin-side, this left UK bidders unable to bid.

A new per-house setting require_phone_verification (in the bidspirit_settings option) makes the client-side bid gate conditional:

• auto (default) — enforce EXCEPT on UK houses (Dialect::isUk()), which are bypassed while their BidSpirit accounts lack SMS provisioning.
• off — never enforce (per-house override, e.g. wp option patch update bidspirit_settings require_phone_verification off).
• on — always enforce.

BidspiritViews::bp_footer() emits window.afRequirePhoneVerification; both bid gates (submitBid, submitBidCatalog) and the profile “Verify phone” CTA honour it. Fails closed (enforces) when the flag is absent. No schema or config-version change.

---

[3.7.1.2] — 2026-06-30

Fixed — Background sync worker spawn timing out ("Worker spawn HTTPS failed: cURL error 28")

On busy or memory-pressured hosts the background sync worker frequently failed to start, logging Worker spawn HTTPS failed: cURL error 28: Operation timed out after 5002 milliseconds with 0 bytes received (observed ~29×/day on one site). SyncQueue::spawnWorker() triggers the worker with a blocking loopback HTTP request to the site's own REST endpoint; the timeout was hard-coded to 5 seconds, so whenever the site's own backend took longer than 5s to respond (DB/FPM contention) the spawn aborted *as a hard error* and raised a sync alert — even though the site was up and serving.

Three changes make the spawn resilient:

• Configurable, longer timeout. The 5s hard-coded timeout is now 15s by default, overridable via the AUCTIONFORGE_WORKER_SPAWN_TIMEOUT constant or the auctionforge_worker_spawn_timeout filter.
• Scheme-matched loopback. Strategy 1 now issues the 127.0.0.1 loopback using the site's own scheme (https when the site is https) instead of always http. Previously an http→https redirect (301) made the loopback look like a failure and forced the slower public-URL fallback; the POST now reaches the worker endpoint directly.
• Non-blocking best-effort fallback. If both blocking attempts can't confirm a start within the timeout, the worker is now triggered with a final non-blocking (fire-and-forget) request, logged at warning instead of error. A merely-slow backend still starts its worker, the hourly SafetySync cron re-spawns if it genuinely didn't, and the condition no longer raises a hard sync alert.

No schema, DB, or config-version change. Behaviour is unchanged on healthy hosts (the loopback still returns 2xx immediately); the new paths engage only when the backend is slow. The underlying slow backend was a server-side issue (MariaDB query-cache lock contention + memory pressure) fixed at the infrastructure level; this release hardens the plugin so a transiently slow backend can no longer turn into a failed sync.

---

[3.7.1.1] — 2026-06-29

Added — Active uptime monitoring via Kuma keyword health marker

The keepalive mu-plugin now emits an invisible <!-- af-health:ok --> marker into every rendered front-end page (hooked on wp_head and wp_footer, emitted once per request, pure echo — no DB/IO, lands inside cached HTML). Uptime Kuma monitors each site by pulling the homepage and asserting the marker is present, which measures real user-facing availability (DNS + TLS + nginx + PHP + WordPress + DB + render) instead of the old push-heartbeat model that only measured whether WP-Cron was firing — and routinely false-flagged perfectly healthy sites as down (the worst offenders flapped 50–60×/day while serving HTTP 200 the entire time).

Because the marker lives in the mu-plugin (which WordPress can't deactivate and AuctionForge re-asserts on every load), it reflects "WordPress is rendering pages" independently of AuctionForge's own activation state, and it survives failed or in-progress plugin updates. The bundled keepalive template is bumped to 1.3.0, so the installer rewrites wp-content/mu-plugins/auctionforge-keepalive.php on update. The legacy push heartbeat is retained in this release for a safe transition to active monitoring.

---

[3.7.0.43] — 2026-06-22

Fixed — Submission "Need help?" contact was hardcoded (one tenant's details on every site)

The vehicle-submission help panel (templates/js-chunks/submissions.php) rendered a single hardcoded email and phone, so every AuctionForge site displayed the same contact regardless of which auction house it was — e.g. one tenant's info@absoluteclearance.co.uk / 01536 674804 showed on unrelated sites.

The panel now resolves the contact dynamically, in priority order:

• apply_filters('auctionforge_help_email', '') / apply_filters('auctionforge_help_phone', '') — explicit per-site override (any source, e.g. a theme/global/Elementor setting);
• otherwise the SEO & AEO Optimizer LocalBusiness details stored in the seo_aeo_options option (local_email / local_phone);
• if neither yields a value the corresponding row is omitted, and the whole "Need help?" block is hidden when no contact is available — so no placeholder or wrong-tenant detail is ever shown.

Internal

• Modified: templates/js-chunks/submissions.php — replaced the two hardcoded <p> contact values with filtered, esc_html-escaped values resolved from seo_aeo_options, each row guarded by an if.
• Modified: auctionforge.php — plugin header → 3.7.0.43.
• No database schema change (AUCTIONFORGE_DB_VERSION unchanged at 25).

---

[3.7.0.42] — 2026-06-22

Fixed — Submission templates emitted extra <h1>s and placeholder content site-wide

The vehicle-submission view (templates/js-chunks/submissions.php) is rendered on wp_footer on every page, so its <script type="text/template"> chunks shipped into the source of all pages. Two of those chunks used <h1> headings ("Submit your vehicle for auction" and "Detail received successfully"), meaning every page's HTML source contained three <h1> elements. While these live inside inert <script> templates (so a DOM-rendering crawler like Googlebot still resolves a single true H1), raw-source SEO tooling and some AI crawlers flag the duplicates, and the templates also shipped vendor placeholder text.

• Both template headings demoted from <h1> to <h2> — a single H1 per page in source.
• Replaced Lorem-ipsum placeholder copy in the intro and progress panels with real submission guidance.
• Replaced the dummy "Need help?" contact details (support@domain.com / +3265464325) with the live business contact (info@absoluteclearance.co.uk / 01536 674804).

No functional/JS changes — template IDs and structure are unchanged.

---

[3.7.0.41] — 2026-06-19

Fixed — Duplicate auction terms (auction shown twice, catalogue split)

A newly published auction could be created twice in WordPress as two identical auction_number terms, so the auction rendered twice on the listing and its catalogue was split across the two copies (e.g. 145 lots stored as 144 + 1). The lot posts themselves stayed unique — this was a duplicate *auction*, not duplicate *lots*.

Root cause: auction terms are only created in Auction::save() via wp_insert_category, which inserts whenever the caller's lookup returned no term. That lookup (findAuctionByIdWithLang() → get_terms() meta_query) can return nothing for a brand-new auction when two syncs run concurrently — for example a full_sync_* bulk run (via BulkSyncWorker / AuctionList) overlapping a catalogue webhook. Both see "no term" and both insert one. The only fallback, findAuctionByNumber(), looks up by the auction *number* slug and never matched the real term slug, so it could not catch the miss. This path is not covered by the existing CatalogSyncWorker per-auction lock, which serialises catalogue syncs to prevent duplicate *lot posts* but does not guard *term* creation.

Auction::save() now, before inserting a term:

• acquires a per-auction MySQL advisory lock (GET_LOCK('<prefix>af_term_<auctionId>', 10)) so concurrent creators serialise — the loser then finds the just-created term and updates it instead of inserting a second one; and
• performs an authoritative, cache-bypassing lookup by auction_id (direct termmeta ⋈ term_taxonomy query) and switches to update-in-place when a term already exists.

Polylang-aware: under full multilingual support it only reuses a term in the requested language, so legitimate per-language terms are still created.

Internal

• Modified: inc/model/Auction.php — save() gains a pre-insert dedup guard; new private helpers findTermIdByAuctionId(), acquireTermLock(), releaseTermLock(). InstanceDB wraps the global $wpdb, so the advisory lock and the wp_insert_category insert share a single DB session (the same property that makes the existing CatalogSyncWorker lock effective).
• No database schema change (AUCTIONFORGE_DB_VERSION unchanged at 25).

---

[3.7.0.40] — 2026-06-14

Fixed — Lot "begin to close" countdown now shows minutes (and seconds in the final minute)

The lot-page countdown (#auctionStartTimer, the *"Auction will begin to close in …"* line) only ever rendered whole days and whole hours, and computed once on page load. With less than an hour to go it therefore read "0 days and 0 hours" — e.g. a lot closing at 20:00 looked like a dead/expired timer from 19:00 onwards, even though ~46 minutes remained. The time maths was correct; the widget simply had no sub-hour granularity and never ticked.

It now updates every second and shows the largest meaningful units, dropping leading zero units:

• 44 minutes • 3 hours and 20 minutes • 1 day, 2 hours and 5 minutes
• In the final minute it counts the seconds down (40 seconds → 1 second) so it never sits on a flat "0".
• Once the close time passes (result < 0) the timer hides itself, as before.

getCountdownText() now wraps the suffix in a .bp-start-countdown span so the script can rewrite the whole phrase; if that wrapper is ever absent (e.g. a stale page-cached markup), getLeftDate() falls back to the original days+hours behaviour rather than erroring — important because app.js also carries the live bidding logic.

Internal

• Modified: inc/controllers/Settings.php — getCountdownText() suffix wrapped in .bp-start-countdown.
• Modified: assets/js/app.js — getLeftDate() rewritten: 1s ticking via setInterval, days/hours/minutes/seconds, zero-unit omission, pluralisation, and a wrapper-missing fallback. This is the file actually served (front-end $jsFile is hardcoded to .js).
• Modified: src/js/app.js — same getLeftDate() change, to keep the gulp source in sync. app.min.js is intentionally not regenerated (unused — the unminified app.js is enqueued).
• Modified: auctionforge.php — plugin header → 3.7.0.40. (3.7.0.39 was present in the header with no changelog entry; this release supersedes it.)

---

[3.7.0.38] — 2026-06-02

Added — Spelling Dialect "Auto" mode (match the auction house region)

The Spelling Dialect setting (Settings → Appearance) gains a third option, "Auto — match the auction house region", which becomes the new default for sites that haven't chosen one:

• During the existing auction sync (getAllAuctions), Dialect::captureRegionFromAuctions() reads the auction house's country from the auction address (trailing segment; currency as a fallback) and stores the resolved dialect in the spelling_dialect_auto option. No API calls happen on page loads — it's a fixed, site-wide value refreshed each sync, so it's fully page-cache-safe.
• Mapping: US → Catalog; every other country → Catalogue (American "Catalog" is US-only; UK/IE/AU/NZ/CA/etc. use "Catalogue").
• The admin field shows what was detected, e.g. *"Detected region: United Kingdom → Catalogue."* United States and United Kingdom remain manual hard-overrides.

Default change: new/unconfigured sites now default to Auto (was UK). Until a site's first sync resolves the region, Auto falls back to UK, so behaviour is unchanged until detection kicks in — then it self-corrects (a US house starts showing "Catalog" automatically).

Internal

• Modified: inc/helpers/Dialect.php — auto mode, FALLBACK_DIALECT, countryToDialect(), captureRegionFromAuctions(); DEFAULT_DIALECT → auto.
• Modified: inc/import/AuctionList.php — capture the house region during the auctions sync.
• Modified: inc/controllers/Settings.php — Auto dropdown option + detected-region note.
• Modified: auctionforge.php — plugin header → 3.7.0.38.

---

[3.7.0.37] — 2026-06-02

Fixed — Per-lot "full price VAT" now drives the VAT statement

The standalone VAT line on lot pages (vat-and-commission → .vat-field) was keyed off the auction-house VAT rule, so it always read *"VAT: X% on item price and commission"* regardless of a lot's full-price-VAT toggle — and toggling a lot off didn't change it. It now branches on the live per-lot flag (itemInfo.item.fullPriceVat), matching the price-breakdown calc in getFullPriceInfo():

• Full-price VAT on → *"VAT: X% on item price and commission"* (VAT applied to hammer + commission)
• off (default) → *"VAT: X% on commission only"*

This only changes the wording to match the amount getFullPriceInfo() already computes per the toggle; the VAT figure itself was already correct. The separate renderVatField() "no VAT on commission" path is unchanged.

Internal

• Modified: templates/js-chunks/vat-and-commission.php — VAT statement branches on the per-lot fullPriceVat instead of houseCommissionVatRule.
• Modified: auctionforge.php — plugin header → 3.7.0.37.

---

[3.7.0.36] — 2026-06-02

A Site Statistics release: day-of-week analysis, an opt-in weekly email report, lot-focused "top pages", and several dashboard refinements.

Added — Day-of-week tabs on the hourly charts

The Hourly Distribution (Site Statistics → Overview) and Peak Viewing Times (Lot Analytics) charts now have a day tab strip — All days · Mon · Tue … Sun — each showing that weekday's total. Selecting a day redraws the 24-hour chart consolidated across every matching date in the range, so you can see *which days and times* visitors are active. The lot-analytics data already carried day_of_week; it was previously flattened to 24 hours and is now surfaced.

Added — Scheduled weekly email report (opt-in, off by default)

A new report under Site Statistics → Settings emails a polished weekly summary: headline KPI cards (Visitors / Pageviews / Sessions with this-week-vs-last-week change), a visitor journey funnel (Visitors → Viewed a lot → Left a bid), busiest hour for each weekday, and the week's most-viewed lots. Driven by a daily cron that sends once on a configurable weekday. Supports one or several recipients (comma/semicolon/space/newline separated, validated and de-duped) and a "Send test now" button that sends to whatever is currently in the Recipient(s) box. Built table-based with inline CSS for Gmail/Outlook/Apple Mail compatibility.

Added — New vs Returning visitors, auction markers, engagement funnel

• New vs Returning visitor KPI cards on the Overview (new = authoritative af_stats_visitors.first_seen within the period, joined so it can never exceed total visitors).
• Auction-date markers drawn on the *Traffic Over Time* chart (dashed lines + a captioned list) so traffic can be read against sale dates.
• Engagement funnel panel: Visitors → Viewed a lot → Viewed 5+ lots → Bidders (bidders from synced af_bid_events).

Changed — "Top pages" is now lot-focused ("Top Lots" / "Most viewed lots")

Both the dashboard Overview panel and the email now list the most-viewed individual lot pages only (/lot-…), excluding home, catalogue listing/pagination and profile pages as low-signal. Email page titles are shown in full (no mid-word truncation) with the site-name suffix stripped; the dedicated Pages tab remains the unfiltered drill-down.

Changed — Lot Analytics "Peak Viewing Times" honours the global date range

Previously hard-coded to the last 30 days; it now respects the dashboard's range picker. The Lot Analytics tab also auto-loads on first click (previously required a manual refresh).

Changed — Chart.js bundled locally

The Statistics and plugin dashboards loaded Chart.js from a CDN at two different versions (@4 and @4.4.1). Chart.js 4.4.1 is now bundled at admin/assets/js/chart.umd.min.js and loaded from the plugin (version-busted), so charts work offline / behind strict CSP and the version is pinned.

Internal

• Added: inc/stats/class-stats-report.php — AF_Stats_Report (weekly cron, recipient parsing, HTML builder, "send test" AJAX). admin/assets/js/chart.umd.min.js — bundled Chart.js 4.4.1.
• Modified: inc/stats/class-stats-ajax.php — hourly-by-DOW query; new_visitors, auction_events, funnel in the dashboard payload; lot-only top pages; global date range passed to peak times; weekly-email settings saved.
• Modified: inc/model/LotAnalytics.php — getPeakViewingTimes() accepts an explicit $from/$to range.
• Modified: inc/stats/class-stats-init.php — require + register AF_Stats_Report.
• Modified: admin/view/stats/dashboard.php — day-of-week tabs, KPI cards, auction-marker plugin, funnel, Top Lots, weekly-email settings UI + test button, local Chart.js.
• Modified: admin/view/dashboard.php — local Chart.js.
• Modified: auctionforge.php — plugin header → 3.7.0.36.

---

[3.7.0.35] — 2026-06-02

Added — Regional spelling dialect ("Catalog" US / "Catalogue" UK)

A new Spelling Dialect dropdown at the top of Settings → Appearance lets each site choose how the word "catalog" is presented on the public front end:

• United States — Catalog — US spelling (the plugin's original authored wording).
• United Kingdom — Catalogue — UK spelling.

When UK is selected, every front-end occurrence is rewritten — *"Catalogue will be available soon"*, *"View catalogue"*, *"Catalogue Coming Soon"*, *"Download catalogue"*, *"Back to the catalogue"*, the lot-page Catalogue tab, and the "catalogue published" app notification.

How it works. Every user-facing catalog string already passes through the auctionforge text domain (__()), so the swap is implemented as a single gettext / gettext_with_context filter rather than by editing template files. Dialect::toUk() rewrites whole words only, preserving case and pluralisation (Catalog→Catalogue, View catalog→View catalogue, CATALOG→CATALOGUE, Catalogs→Catalogues), and is idempotent. The filter is front-end only (is_admin()-guarded, with a wp_doing_ajax() exception so front-end AJAX is still covered) and is scoped to the auctionforge domain, so it never touches WordPress core, the theme, or other plugins. Code identifiers, option keys (catalog_layout, bids_in_catalog), CSS classes (af-catalog-sidebar, catalog-section, bp-back-to-catalog-button) and JS variables are all left intact. On US sites the filter is not registered at all, so there is zero added overhead.

Internal

• Added: inc/helpers/Dialect.php — Dialect helper: get()/isUk() (reads the spelling_dialect option, default UK), word() for non-translated strings, the case/plural-preserving toUk() transform, the gettext filter callbacks, and register() (no-op on US sites).
• Modified: inc/coreIncludes.php — require Dialect.php and call Dialect::register() at plugin load.
• Modified: inc/controllers/Settings.php — use the Dialect helper; add the "Regional Spelling" sub-heading and Spelling Dialect field at the top of the Appearance section, plus the fill_bidspirit_options_spelling_dialect() renderer. The value persists through the existing bidspirit_settings option and sanitize callback.
• Modified: auctionforge.php — plugin header → 3.7.0.35.

Note for existing sites. The default dialect is UK ("Catalogue"). Any site that upgrades without an explicit spelling_dialect value will therefore display "Catalogue" on the front end. Sites that should keep US spelling must set Settings → Appearance → Spelling Dialect to United States — Catalog (stored as spelling_dialect = us). Admin labels are unaffected in either dialect.

---

[3.7.0.34] — 2026-05-30

Fixed — Duplicate lot posts created by concurrent catalog syncs for the same auction

When two catalog-sync jobs for the same auction ran at the same time, every lot was imported twice and the front-end showed each lot as a pair (the second post taking a -2 slug). Observed on a live sale: 157 lots became 313 published lot posts.

Root cause. Two BidSpirit webhooks arriving in the same second (e.g. CATALOG_PUBLISHED + AUCTION_CATALOG_UPDATED) each enqueue a catalog_sync. SyncQueue::enqueue() deduplicates with a non-atomic *SELECT-then-INSERT* (no DB unique constraint), so two simultaneous calls both pass the "already pending?" check and both jobs land in the queue. Job *claiming* is atomic per-job, but nothing serialised two different jobs for the same auction, so two workers ran concurrently. The matcher Lot::findByBSMeta() only sees committed publish/draft posts, so during the overlapping insert windows each worker saw "no existing post" for every lot and inserted a fresh full set. Worse, findByBSMeta does GROUP BY lotId, so the resulting duplicate pair is collapsed to a single row in every later sync — the importer never detects or repairs it, and the count($datum) > 1 "Double" guard in InsertLotsBS::init() is effectively dead code.

Fix. CatalogSyncWorker::process() and processDayEnded() now take a per-auction MySQL advisory lock (GET_LOCK('<prefix>af_sync_<auctionId>', 0)) around the API-fetch + post-insertion work. If another worker already holds the lock for that auction, the duplicate job logs concurrent-lock busy and returns cleanly — marked completed, since the in-flight sync already covers the work — instead of racing. The lock is held on the worker's own DB connection and auto-releases if the process dies, so it can never deadlock the queue. This serialises all catalog and day-ended processing per auction no matter how many duplicate jobs reach the queue.

Internal

• Modified: inc/sync/CatalogSyncWorker.php — new acquireAuctionLock() / releaseAuctionLock() helpers; process() and processDayEnded() acquire the lock up front (skip-on-busy) and release it in a finally.
• Modified: auctionforge.php — plugin header → 3.7.0.34.

Note for existing sites. This prevents *new* duplicates; it does not remove ones already created. To find them, look for published lot posts where two share one BidSpirit lot id (bp_meta_data.id). Keep the most-recently-synced post per lot id and set the rest to post_status = 'trash' — the lot post type has trash disabled, so do it via SQL, and do not use draft (which findByBSMeta still matches). Then recount the auction_number term and clear caches.

---

[3.7.0.33] — 2026-05-30

Fixed — auctionforge_sync_lots cron never scheduled (Lots push to wpdeploy silently stopped)

AF_Lots_Sync uses the custom bp_ten_minutely schedule. The sync crons were registered from AF_Stats_Init::init(), which runs at plugin-load time — *before* auctionforge.php adds bp_ten_minutely to the cron_schedules filter further down the same file. So wp_schedule_event(time(), 'bp_ten_minutely', 'auctionforge_sync_lots') ran against an unknown schedule, failed silently, and left the hook permanently unscheduled. The other four sync hooks use core's hourly and were unaffected — which is why only the Lots push to wpdeploy went stale (observed: 3 days with no push while every other stream ran on time). Fixed by deferring the sync register() calls to the init hook, by which point every custom schedule is registered. The hook self-arms on the next request after upgrade.

Fixed — Safety Sync admin run reported a false "Request failed (HTTP 200)"

auctionforge_ajax_run_cron_task returns its result as JSON, but a stray PHP notice/deprecation emitted by a task (e.g. the Safety Sync BidSpirit delta-check on PHP 8.1) printed into the response body ahead of the JSON, so the browser couldn't parse it and the modal showed a misleading "Request failed (HTTP 200)" even though the task succeeded. The handler now buffers task output, discards it before emitting JSON, and logs any suppressed output via SyncLogger (context admin) so the offending notice can still be found and fixed at the root.

Added — "Clear duplicate cron events" button on Sync Status

The one-shot AF_Cron_Cleanup migration only runs once per site, so per-hostname duplicate events created by an older build *after* the migration had already marked itself done were never swept. New AF_Cron_Cleanup::force_sweep() runs the same sweep on demand, exposed via a Clear Cron Dupes button in the Sync Queue toolbar (AJAX auctionforge_clear_cron_dupes). It removes legacy-args duplicates of the four per-hostname hooks plus the two orphan hooks, keeping one clean event each.

Internal

• Modified: inc/stats/class-stats-init.php — sync register() calls wrapped in add_action('init', …, 20).
• Modified: inc/maintenance/class-cron-cleanup.php — new public force_sweep() reusing the existing sweep helpers.
• Modified: auctionforge.php — auctionforge_ajax_run_cron_task() output-buffered against stray output; new auctionforge_ajax_clear_cron_dupes() handler + registration; plugin header → 3.7.0.33.
• Modified: admin/view/sync-status.php — added the "Clear Cron Dupes" button and handler.

Note: with all scheduling now arg-free (3.7.0.28+), the duplicates do not regenerate once swept; a canonical-hostname redirect (www ↔ apex) at the web-server level remains good hygiene but is no longer required to keep the cron table clean.

---

[3.7.0.32] — 2026-05-30

Fixed — V3 sync worker never spawned on some hosts (silent import stall)

On some sites (confirmed on a LiteSpeed/cPanel install) the V3 queue worker never actually started, so catalog lots were staged into import_history but never converted to WordPress posts — postId IS NULL, syncFinished = 0, syncTimes = 0, and no errors logged. Clearing the queue and reprocessing re-stalled immediately.

Root cause. SyncQueue::spawnWorker() starts the worker by POSTing the REST route /wp-json/auctionforge/v1/sync-worker. It tried an HTTP loopback to http://127.0.0.1/ with the site's Host: header first, and the success test was if (!is_wp_error($result)) — it never inspected the HTTP status code. On hosts where 127.0.0.1 + Host header resolves to the wrong vhost (or the route is blocked), that request returns 404/403, which is not a WP_Error. The old code therefore treated the 404 as a successful spawn, logged Spawned … (HTTP 404), returned true, and never reached the HTTPS fallback. The worker never ran; nothing drained the queue or the staging table. Sites whose 127.0.0.1 loopback resolves correctly returned 200 and were unaffected — which is why this was host-specific.

Fix. spawnWorker() now reads the response code and only treats 2xx as a successful spawn. On any non-2xx (or a WP_Error) from the loopback it logs a warning and falls through to the rest_url() HTTPS path, which is likewise status-checked. A new constant short-circuits the doomed attempt on known-bad hosts:

```php

define('AUCTIONFORGE_WORKER_SKIP_LOOPBACK', true); // wp-config.php — skip 127.0.0.1, go straight to HTTPS

```

Added — Automatic staging recovery on the safety cron

The hourly auctionforge_sync_safety cron previously only spawned a worker when the queue had pending jobs. Lots that were staged into import_history but left unconverted (e.g. after a worker died, or while the spawn bug above was in effect) had no queue job attached, so nothing ever picked them up. The safety cron now also checks SyncQueue::stagingBacklogCount() and, when it is non-zero, kicks the staging processor (non-blocking) to convert the backlog into posts — making the pipeline self-healing without manual intervention.

Added — "Process Staging" button on Sync Status

A new Process Staging button in the Sync Queue toolbar (Lots → Sync Status) runs InsertLotsBS over the staging table on demand — for when lots are staged but not appearing on the site. It fires non-blocking and switches the Live Console into fast-poll so the operator can watch posts being created in batches of 50.

Internal

• Modified: inc/sync/SyncQueue.php — spawnWorker() rewritten with HTTP-status-aware fallback + AUCTIONFORGE_WORKER_SKIP_LOOPBACK support; triggerStagingProcessor() gained a $blocking parameter (non-blocking fire-and-forget mode for cron/admin); new stagingBacklogCount() helper (counts import_history rows with syncFinished = 0).
• Modified: auctionforge.php — auctionforge_sync_safety_action() now drains orphaned staging via the non-blocking processor when a backlog exists; new process_staging case in the auctionforge_sync_enqueue AJAX handler; plugin header bumped to 3.7.0.32.
• Modified: admin/view/sync-status.php — added the "Process Staging" button and its click handler.

---

[3.7.0.28] — 2026-05-21

Fixed — WP-Cron duplicate-event accumulation

A scan across 18 WordPress installs found that 16 sites had duplicate cron events for the AuctionForge sync hooks — some with up to 20 copies of bp_auto_close and 6 copies of auctionforge_sync_safety. Root-cause analysis identified three distinct bugs in the plugin's scheduling code, all fixed in this release.

Bug 1 — $_SERVER['SERVER_NAME'] baked into scheduling args. auctionforge.php:2511-2554 scheduled bidspirit_import, data_import, bidspirit_archive_import, and auctionforge_sync_safety with $attr = array($_SERVER['SERVER_NAME']). WP-Cron's wp_next_scheduled() guard matches on hook plus args signature, so every distinct hostname the site was reached under (canonical, www., IP-direct, internal cron caller hitting 127.0.0.1, an old domain from before a rename) bypassed the guard and scheduled its own copy. The handlers unset($host) — the argument was always vestigial. Removed $attr entirely; events now schedule with empty args. Also dropped the !empty($_SERVER['SERVER_NAME']) outer guards so wp-cli / OS-cron bootstraps can prime the schedule on a fresh install.

Bug 2 — bp_auto_close per-term scheduling with no cleanup. inc/controllers/BidspiritLots.php scheduled one 10-minutely event per running auction term, keyed on ['term_id' => …, 'slug' => …] — correct in principle, but nothing ever unscheduled the event when the auction ended or its term was deleted. Long-running sites accumulated dozens of dangling per-term events polling the BidSpirit API for auctions that no longer existed. Added two cleanup paths:

• bidspirit_auto_close_action() now self-cleans: if the term has been deleted, or if the remote auction state returned by BidSpirit is not RUNNING or ENDING, the handler writes the remote state to auction_state term meta and calls wp_clear_scheduled_hook('bp_auto_close', $args) for that term. The meta write is necessary because check_is_live() runs on every wp_loaded and re-arms bp_auto_close for any term still marked STATE_RUNNING in local meta — without writing the remote state through, the unschedule would be undone on the next request. The meta write is consistent with what SafetySync::run() and inc/import/AuctionList.php:229 already do on non-RUNNING upstream states.
• New pre_delete_term hook on the auction_number taxonomy unschedules the matching event when an auction term is deleted, so a deleted auction can't leave a poll behind.

Bug 3 — Orphan hooks from removed plugin code. bidspirit_meta_migrate_sync and bidspirit_migrate_sync were scheduled by a previous plugin version whose code has since been removed. They sat in wp_options.cron firing into the void on every site (the MIGRATE_SYNC constant in Settings.php:36 is the lone survivor — commented out). No upgrade path ever called wp_clear_scheduled_hook() for them.

Added — One-shot migration: AF_Cron_Cleanup

New class at inc/maintenance/class-cron-cleanup.php, registered from class-stats-init.php, runs once on the first request after upgrading and:

1. Walks _get_cron_array() and unschedules every event for the four hooks rewritten in Bug 1 whose args are non-empty — clearing per-hostname stragglers. The new scheduling code at the top of auctionforge.php has already armed a clean no-args event by the time the migration runs (the scheduling code runs at plugin-load time; the migration runs on init priority 20). Preserving empty-args events means the schedule remains continuously populated — no gap between sweep and the next page load.

2. Unschedules every event (any args) for the two orphan hooks from Bug 3 — those have no callbacks anywhere in the codebase, so empty-args entries are also dead weight.

3. Marks itself done via the auctionforge_cron_cleanup_v1 option and never runs again.

Note that wp_clear_scheduled_hook($hook) alone only matches events with empty args — events scheduled with non-empty args (which is exactly our duplicate population) are left behind. The migration walks the cron array directly and calls wp_unschedule_event($timestamp, $hook, $event['args']) for each match.

Logs a summary line via SyncLogger so the per-site outcome is auditable: e.g. cron-cleanup: Cleared duplicate/orphan cron events: {"bp_auto_close":20,"auctionforge_sync_safety":3,"bidspirit_meta_migrate_sync":2}.

Failure modes after this release

| State | Outcome |

|---|---|

| Fresh install (no duplicates) | Migration runs, finds nothing, sets the option, exits in microseconds. |

| Upgrade on a site with N duplicates | Migration clears them on first load post-upgrade; scheduling code re-arms each hook once with empty args. |

| Site reached under multiple hostnames going forward | No new duplicates — args no longer carry the hostname, so the wp_next_scheduled() guard catches re-registration regardless of which hostname triggers it. |

| Auction term deleted via wp-admin | pre_delete_term clears the matching bp_auto_close event in the same request. |

| Auction ends remotely (state != RUNNING/ENDING) | Next handler run sees the state change and self-cleans the event. |

| Auction term deleted while a bp_auto_close cron is mid-flight | Handler's get_term() returns null, falls through unschedule_auto_close() cleanup branch, returns without an API call. |

Internal

• Created: inc/maintenance/class-cron-cleanup.php (~80 LOC).
• Modified: auctionforge.php lines 2511-2573 — removed SERVER_NAME args and outer guards from bidspirit_import / data_import / bidspirit_archive_import / auctionforge_sync_safety scheduling blocks; handler signatures changed from ($host) to (); add_action(..., 10, 1) simplified to add_action(...).
• Modified: inc/controllers/BidspiritLots.php — added pre_delete_term action registration; rewrote bidspirit_auto_close_action() with term-existence check and state-based self-clean; added unschedule_auto_close() and cleanup_auto_close_on_term_delete() helpers; dropped the SERVER_NAME guard from the per-term scheduling loop.
• Modified: inc/stats/class-stats-init.php — requires and registers AF_Cron_Cleanup alongside AF_Data_Purge.

---

[3.7.0.21] — 2026-05-05

Added — Connection Diagnostics on the Updates admin page

A new Connection Diagnostics card on Lots → Updates that detects and one-click-heals identity mismatches between this site and the deployment server.

The problem it solves. When a WordPress install is cloned (template → customer site, dev → prod, backup → restore), the cloned wp_options carry the original site's auctionforge_update_api_key over to the new home_url(). The new install then makes API calls to wpdeploy *authenticated as the original site*. wpdeploy looks up by api_key, not by URL, so every /sync-user-tracking, /check-updates, /report-health, and most importantly the Kuma push URL, gets recorded against the WRONG wpdeploy.sites row. The cloned site's monitor stays silent; the original's monitor shows traffic that isn't from it.

What the diagnostic does:

• Run Identity Check — calls the new wpdeploy GET /api.php/whoami endpoint and compares the returned caller_site_url against home_url(). Renders a verdict ("matches" / "MISMATCH") plus the full server-side view (site_id, site_name, last_check, plugin version on file, remote IP). The "Re-register & Reset Kuma" button only appears if there's a mismatch.
• Re-register & Reset Kuma — calls /request-access (which is idempotent on site_url — wpdeploy returns the canonical api_key for *this* home_url(), regardless of whatever wrong key we were holding), wipes auctionforge_kuma_push_url and any leftover heartbeat cron events, then immediately fires /check-updates so the api_request interceptor catches the freshly-correct kuma_push_url for *this* site. The keepalive mu-plugin's heartbeat picks it up on the next 60s tick.

Internal

• AuctionForge_Auto_Updater::whoami() (new) — thin wrapper over api_request('whoami', [], 'GET'). Returns the parsed wpdeploy /whoami payload.
• AuctionForge_Auto_Updater::reset_connection() (new) — three-step heal: re-register → wipe Kuma cached state → re-fetch via /check-updates. Returns shape suitable for wp_send_json_success.
• Two new AJAX actions: auctionforge_diagnose_connection, auctionforge_fix_connection. Both behind manage_options capability + nonce check.
• auctionforge_normalize_host() helper for case/scheme/www-tolerant URL comparison.

Server-side companion

Requires the wpdeploy /api.php/whoami endpoint added in the same release window. The endpoint is gated behind whatever api_key the caller already presented (a master key returns type=master with no site row; a per-site key returns the site row that key resolves to). Reveals nothing the caller doesn't already implicitly authenticate against.

---

[3.7.0.20] — 2026-05-04

Changed

• Kuma heartbeat path is now wpdeploy-independent. The actual heartbeat firing — wp-cron schedule, page-load piggy-back, outbound HTTP — moved out of AF and into the AuctionForge Keepalive mu-plugin (wp-content/mu-plugins/auctionforge-keepalive.php, bumped to v1.2.1). Once a site has been provisioned once and auctionforge_kuma_push_url is cached locally, the heartbeat keeps reporting forever even if AF is deactivated, mid-upgrade, deleted from disk, or wpdeploy is offline. The mu-plugin can't be deactivated by WordPress, can't be broken by an AF release, and depends on AF for nothing.
• AF only writes the kuma_push_url option now. It no longer schedules the cron, no longer fires the heartbeat, and no longer holds any heartbeat-related state. The api_request() interceptor still catches kuma_push_url from /check-updates and /report-health responses and persists it; the mu-plugin reads it from there.
• Migration block. init_hooks() clears any leftover auctionforge_kuma_heartbeat wp-cron event from AF ≤ 3.7.0.19 on first plugin load after upgrade. The mu-plugin runs the same clear on its own plugins_loaded hook — belt and braces. The new event the mu-plugin schedules is kuma_heartbeat_tick on a new kuma_60s schedule.
• AuctionForge_Auto_Updater::kuma_heartbeat() no-opped. Kept as a safety landing pad so any stale auctionforge_kuma_heartbeat wp-cron event that fires one last time before migration kicks in doesn't trip a "no callback registered" warning. Real heartbeat work happens in the mu-plugin.

Added — operator override

• AUCTIONFORGE_KUMA_PUSH_URL constant. Define it in wp-config.php to point a site directly at Kuma without ever involving wpdeploy:

```php

define('AUCTIONFORGE_KUMA_PUSH_URL', 'https://kuma.example.com/api/push/<token>?status=up&msg=&ping=');

```

The constant takes precedence over the auctionforge_kuma_push_url option. With it set, the site can be operated fully outside wpdeploy — useful for one-off installs, customer-managed sites, or disaster-recovery scenarios where wpdeploy is unreachable for an extended period.

Internal — Keepalive mu-plugin v1.2.1

The bundled keepalive template at inc/keepalive/auctionforge-keepalive.template.php now also handles Kuma heartbeats. Three layered triggers ensure cadence stays tight regardless of site traffic:

1. Dedicated wp-cron event kuma_heartbeat_tick on a new 60-second kuma_60s schedule

2. Page-load piggy-back on init: any request older than 50s since the last beat fires another, transient-guarded so concurrent hits coalesce. Free on busy sites; rescues low-traffic sites the moment any visitor arrives.

3. Self-heal inside the cron callback: if the event somehow gets cleared, re-arm it before sending the beat.

HTTP is timeout=2, blocking=false — fire-and-forget, never slows page loads. External IP introspection (ipify → ifconfig.me → icanhazip fallback chain, 24h transient cache) is duplicated in the mu-plugin so it doesn't depend on AF being loaded for the IP lookup.

The keepalive installer (class-keepalive-installer.php) detects the KEEPALIVE_VERSION: 1.2.1 header bump and idempotently overwrites every site's mu-plugin on the next AF load. No manual reactivation needed.

Failure modes after this release

| State | Heartbeat? |

|---|---|

| AF active and healthy | ✅ via mu-plugin |

| AF deactivated by an operator | ✅ mu-plugin runs anyway |

| AF deleted from disk | ✅ as long as auctionforge_kuma_push_url option exists OR constant is set |

| AF mid-upgrade / partial install | ✅ mu-plugin doesn't depend on AF code paths |

| wpdeploy down (existing site) | ✅ option is cached locally, no wpdeploy round-trip |

| wpdeploy down (brand-new site, never provisioned) | ❌ first-time URL provisioning still needs wpdeploy. One-shot, accepted trade-off. |

| Site has zero traffic AND wp-cron isn't firing | ❌ truly nothing to trigger a beat. Mitigation is OS-level cron / DISABLE_WP_CRON, out of scope here. |

---

[3.7.0.19] — 2026-05-04

Changed

• Reverted Kuma heartbeat cadence: 3 min → 1 min. auctionforge_kuma_heartbeat is back on the bp_minutely schedule. With Kuma's 310s silence window, 60s cadence tolerates 4 missed wp-cron ticks before flipping a monitor red — the original "give-it-leeway" semantics. The 3-min cadence introduced in 3.7.0.18 was strictly less chatty but tighter (a single missed tick would trip Kuma), and the trade-off wasn't worth it operationally.
• Migration block updated. init_hooks() now detects any existing event scheduled on a non-bp_minutely cadence (e.g. the bp_3_minutely set by 3.7.0.18) and re-schedules onto bp_minutely. Sites that took 3.7.0.18 roll back automatically on first plugin load after upgrade.
• First-fire jitter narrowed back to 0–60s to match the new cadence.

Notes

• The bp_3_minutely cron schedule registration in auctionforge.php is kept (harmless; available for future use). Only the heartbeat scheduling sites have been reverted.
• Apparent latency in Kuma flipping a monitor red after a real outage is governed by Kuma's per-monitor interval (silence-detection window, currently 310s on the wpdeploy/Kuma side), not by this cron's cadence. To detect outages faster, lower the Kuma interval; to add more tolerance to wp-cron drift, raise it.

---

[3.7.0.18] — 2026-05-04

Changed

• Kuma heartbeat cron cadence: 1 min → 3 min. auctionforge_kuma_heartbeat now runs on a new bp_3_minutely schedule (180s) instead of bp_minutely (60s). This pairs with Kuma's 310s silence-detection window — a single late wp-cron tick (3 min + drift) still lands inside the threshold, but normal traffic to Kuma drops by ~3×.
• Random first-fire offset widened from 60s → 180s. With ~50 sites on a single Kuma instance, spreading first-fires across the full 3-min window prevents synchronised bursts every 3 minutes.
• Auto-migration of existing scheduled events. On plugin upgrade init_hooks() calls wp_get_scheduled_event('auctionforge_kuma_heartbeat') and, if the existing event is on bp_minutely, clears it and reschedules onto bp_3_minutely. Idempotent — a no-op once migrated.

Internal

• New cron schedule registered: bp_3_minutely (BP_MINUTELY * 3 = 180s). Defined alongside the existing bp_minutely / bp_ten_minutely / bp_hourly / bp_24_hourly schedules in auctionforge.php.

---

[3.7.0.17] — 2026-05-04

Fix: "Install Now" always returned up_to_date

The /sync/version REST endpoint (called by wpdeploy's Install Now button) was always responding success: false, reason: up_to_date regardless of the actual installed version, defeating the button's whole purpose.

Root cause

rest_force_plugin_update() did:

```

delete_site_transient('update_plugins');

$this->check_pending_updates();

$updates = get_site_transient('update_plugins');

```

check_pending_updates() calls the /pending-updates endpoint on wpdeploy (which returns the deploy queue), but it does not touch the WP update_plugins transient. The transient just got deleted on the line above and never gets re-populated, so the isset($updates->response[…]) check always failed → always returned up_to_date.

Fix

• Use wp_update_plugins() instead — that's what fires the pre_set_site_transient_update_plugins filter chain that AF's own check_for_updates() callback hooks into to seed the transient. Same pattern is already used correctly in install_update() at line 280.
• Belt-and-braces: when the request body carries an explicit target version and that version is strictly greater than the on-disk plugin version (per version_compare), bypass the transient check and force the install. This handles edge cases where the transient seeding fails (network blip during the wp-cron cycle, hosting-side cache, etc.) so the explicit Install Now command still does what it says.

---

[3.7.0.16] — 2026-05-04

Server external IP reported to wpdeploy + included in Kuma heartbeats

Each AF install now reports its server's outbound external IP. Two channels:

1. Kuma heartbeat msg — the per-minute push payload now reads <wp_version>|<plugin_version>|<external_ip> (e.g. 6.9.4|3.7.0.16|152.53.187.82) so you can spot at a glance which physical box each site lives on. When a host goes dark, multiple monitors flip red simultaneously with the same IP — instant root-cause hint.

2. /report-health payload — a new external_ip field that wpdeploy stores on sites.external_ip. Visible in the Sites admin view as a tappable IP chip; clicking it filters the table to all sites sharing that IP.

How the IP is detected

AuctionForge_Auto_Updater::get_external_ip() calls one of three public echo services in turn — api.ipify.org, ifconfig.me/ip, icanhazip.com — with a 4-second timeout each. The first one that returns a valid IP wins. Result is cached in a transient for 24 hours so we don't hit external services on every report cycle.

Wpdeploy fallback for older plugins

/report-health now also captures REMOTE_ADDR (or HTTP_CF_CONNECTING_IP when behind Cloudflare) when the payload doesn't include external_ip. So sites still on 3.7.0.15 or older start populating their IP today via the same route, no plugin update needed for that data path.

---

[3.7.0.15] — 2026-05-04

Kuma monitors land in an "Unallocated" group by default

New AuctionForge installs are auto-enrolled into Kuma under a new top-level group called Unallocated so the operator can review them and drag-drop into the right home (Bidspirit Auction Sites, Stephen's Auctions, Misc Websites, etc.) before classification. Without this every new monitor would appear at the dashboard top level alongside whatever group hierarchy already exists.

What changed (wpdeploy-side, no plugin behaviour change)

• KumaProvisioner now ensures an "Unallocated" group exists in Kuma (find-or-create via the same Socket.IO add path used for monitors, with type='group') before provisioning each new push monitor, and passes parent=<group_id> in the add payload so the new monitor lands inside it.
• The Node helper accepts arbitrary type and parent fields on the input payload (previously hardcoded to type='push').
• The group itself gets the same user_id=1 reassignment so it shows up on the human admin's dashboard.

Existing Clumber monitor (id=71) was migrated into the new group as part of this release.

This is a wpdeploy infrastructure change — the AF plugin code is unchanged from 3.7.0.14. Version bumped only to mark a clean snapshot point.

---

[3.7.0.14] — 2026-05-04

Uptime Kuma push heartbeat with automatic enrolment

Each AF install now appears as its own monitor on the central Uptime Kuma at https://kuma.smoothbyteit.dev, beating every minute and flipping red within ~90 seconds when a site goes dark. Auto-enrolled — no manual Kuma UI clicks per site.

How it works

1. First contact: when the plugin calls /request-access or /report-health, wpdeploy's new KumaProvisioner opens a Socket.IO connection to Kuma as a dedicated auctionforge-bot user, calls the official add event, and gets back a fresh push token. The resulting URL is shipped to the plugin in the JSON response as kuma_push_url.

2. Plugin-side: a generic interceptor on api_request() persists kuma_push_url to the option auctionforge_kuma_push_url whenever it appears in any wpdeploy response, and immediately schedules the new auctionforge_kuma_heartbeat cron on the existing bp_minutely interval.

3. Heartbeat: the cron handler sends a single wp_remote_get to the push URL each minute with msg=<wp_version>|<plugin_version> so Kuma's dashboard shows the running stack at a glance. Kuma's silence-detection window is 90s, so a single missed wp-cron tick won't false-DOWN.

4. Idempotency: the Kuma monitor's description field stores wpdeploy_site_id:<id>. Re-registering the same site short-circuits at the wpdeploy layer (existing kuma_monitor_id on sites), or — if that's missing — Kuma's existing row is reattached via the description anchor. Re-installing the plugin never duplicates monitors.

Why Socket.IO and not direct DB insert

Kuma's monitor scheduler does not poll its own DB for new rows — startMonitors() only loads monitors at boot, and new ones are armed via the authenticated Socket.IO add event handler (which calls startMonitor() and arms the per-monitor safeBeat setTimeout). A direct INSERT would create a "phantom" monitor that accepts pushes but never flips DOWN on silence, defeating the whole feature.

Notifications + monitor ownership

Provisioner reads existing Kuma notification rows whose channel is Telegram (or marked default-for-new-monitors) and attaches them to every new monitor via the add event's notificationIDList. After the Socket.IO add succeeds, the provisioner direct-writes user_id=1 to the new monitor row in Kuma's SQLite — Kuma's add handler hardcodes user_id=socket.userID (the bot at user 2), which causes the frontend's real-time monitor-list updates to skip the admin's session. The follow-up UPDATE stamps ownership to the human admin so monitors render with their full name on the admin dashboard immediately.

Failure modes

Every call boundary degrades safely. If Kuma is unreachable when a site registers, registration completes without kuma_push_url; the next twicedaily /report-health retries. Heartbeat HTTP failures are silent (which is the desired outcome — Kuma's silence-detection is the signal). Kuma reset / monitor row deleted: provisioner's pre-flight check NULLs the wpdeploy anchors and falls through to fresh provisioning on the next call.

Operator setup

Already done: the auctionforge-bot Kuma user has been created and credentials populated in wpdeploy's config.php. To rotate or migrate Kuma later, edit KUMA_URL / KUMA_BOT_USER / KUMA_BOT_PASS in config.php — no plugin redeploy needed.

---

[3.7.0.13] — 2026-05-04

Wide shortcode: hide Register button for logged-in users

• When a user is logged in to BidSpirit (body.bp-login), the Register button is now automatically hidden on wide-format auction cards (bp_upcoming_wide and bp_auction_list layout="wide").
• The View Catalog / Catalog Coming Soon button expands to full width when the Register button is hidden.
• Uses a lightweight MutationObserver to react to BidSpirit's async session init.
• Applied to both UpcomingAuctionWide.php and AuctionList.php shortcode CSS blocks.

---

[3.7.0.12] — 2026-05-03

Stop-word denylist for BidSpirit category-tag concatenations

BidSpirit's wp_bp_meta_data.tags field arrives as PascalCase category names lowercased without separators (uscollectibles, firearmsaccessoriesammunition, usdecorativearts, printsandmultiples). They look like keywords but they're really categories, and on sites where the tags field is populated they completely swamp the top-5 chips for power users (e.g. one buyer's profile was led by uscollectibles 453 views despite that being a label rather than a real interest signal).

29 known patterns added to stop-words.php so the tokenizer drops them at extraction time. New ones surfacing from sites we haven't seen yet should be added here as they appear; the wpdeploy ?tab=keywords corpus page makes them easy to spot (sort by most users with low lots count and look for non-word concatenations).

---

[3.7.0.11] — 2026-05-03

Keyword extractor — capture model years + hyphenated calibers, drop more auction noise

The People view's top-5 keyword chips were filling up with generic descriptors (household, model, original, assortment) instead of the brand/maker terms (mauser, whitworth, colt) that actually distinguish one buyer from another. Live-data review on the new ?tab=keywords Keyword Corpus page on wpdeploy confirmed the cause: real signal was being lost at the tokenizer stage.

Tokenizer changes (inc/stats/class-keyword-extractor.php)

Three pre-passes now run before the standard split-on-non-alpha:

1. Hyphenated / x-separated calibers — .45-70, .30-06, 7.62x54r, 8x57. Without this they're split into pure-digit fragments and dropped, losing the actual model identifier.

2. Caliber-with-suffix — 9mm, .22lr, .45acp, .380acp. Previously only survived by accident because of the trailing letters; now extracted explicitly.

3. 4-digit model years 1700–2099 — 1873, 1903, 1911, 1971. Pure-digit tokens were unconditionally dropped; now retained when year-shaped.

Standard pass relaxed to allow 4-digit pure-digit tokens between 1700 and 2099.

Stop-word additions (inc/stats/stop-words.php)

Conservative — only universally empty auction descriptors:

original, marked, accessories, decorative, household, goods, made, condition, assortment

Deliberately NOT added: antique, vintage, rare, fine — those carry buyer-segmentation signal (antiquarian buyers vs. modern-collectibles buyers). Borderline cases (metal, wooden, american, model) are left to the wpdeploy-side IDF re-rank.

Companion change on wpdeploy (no plugin update needed)

refresh_people_rollup.php now multiplies each keyword's score by an IDF factor pulled from keyword_idf (refreshed hourly by refresh_lot_keyword_index.php). Generic keywords that appear in many lots get demoted automatically; brand/maker words that only appear on a handful get lifted into the top-5 chips.

After deploying this version, reset the auctionforge_lots_sync_watermark option on each site and clear the wp_af_stats_lot_keywords table to force re-extraction of every lot through the new tokenizer.

---

[3.7.0.10] — 2026-05-03

Lots sync — ship resolved CDN image URL, not bare BidSpirit filename

class-lots-sync.php was sending imagesListStr's first comma-token verbatim as image_url — that's the raw BidSpirit storage value (e.g. 001.jpg). Wpdeploy received a bare filename, the browser resolved it against the wpdeploy host, and every lot thumbnail 404'd.

The lots-sync now instantiates LotImage and pulls the resolved CDN URL (LABEL_MEDIUM thumbnail), with fallback to LABEL_ORIGINAL and a final defensive check that drops anything that doesn't start with http(s)://. Resolution is wrapped in try/catch — a missing class or BidSpirit settings issue leaves image_url empty rather than blowing up the sync batch.

After deploying this version on a site, reset its auctionforge_lots_sync_watermark option (delete the row) to re-push existing lots through the new resolver. The wpdeploy view skips <img> rendering when image_url isn't a real URL, so dirty rows degrade silently while the watermark catches up.

---

[3.7.0.9] — 2026-05-03

Keepalive sweep — auto-clears WP upgrader debris that produces silent "Could not create directory" failures

WordPress 6.x's atomic-rollback flow leaves wp-content/upgrade-temp-backup/ lying around when its post-install cleanup misfires (the user-facing symptom is "Update failed: Could not create directory" after an update that has actually already succeeded). Stale wp-content/upgrade/<plugin>-tmp/ and .maintenance lockfiles from crashed upgrades cause the *next* upgrade attempt to fail the same way. None of WP's own scheduled cleanup catches these reliably.

The keepalive mu-plugin (KEEPALIVE_VERSION 1.1.0) now sweeps all three classes of debris on every page load, transient-guarded to once per hour. Safety thresholds prevent it touching anything actually in flight: .maintenance files less than 5 min old, wp-content/upgrade/* entries less than 60 min old, and upgrade-temp-backup/ less than 30 min old are left alone. Wrapped in try/catch with no throws, so the sweep can never block a request.

The keepalive installer detects the version bump and rewrites wp-content/mu-plugins/auctionforge-keepalive.php automatically on the next AF load, no manual reactivation needed.

---

[3.7.0.8] — 2026-05-03

Shop auction UI refinements & share button settings

Shop (Buy-It-Now) catalog improvements

• Shop sorting dropdown: Added a dedicated sorting dropdown for shop catalogs with options: Recently Added, Price: High, and Price: Low. Sorts by buyoutPrice metadata. Regular auction catalogs retain the original sorting options.
• Removed "Buyout price:" label: On shop lot pages, the redundant "Buyout price:" text before the price is now hidden. Only the price and "Buy Now" button are displayed. Regular auction buyout lots still show the label.
• Removed increments table & terms links: On shop lot pages, the "Increments table" and "Terms and conditions" links are hidden since they don't apply to buy-it-now items. The "Make an inquiry" link remains.

Buyout confirmation modal overhaul

• Sales tax logic: The buyout confirmation modal now follows the same sales tax detection as the regular bid modal. When the auction house has a US state configured, displays "Sales Tax" instead of "VAT", with the correct percentage for same-state buyers and 0% for out-of-state.
• Hide 0% buyer's premium: The Buyer's Premium line is hidden when the commission is 0%.
• Shop-specific text: For shop buyouts, all disclaimer text is replaced with: *"You will receive an email with your invoice, including shipping, and a secure payment link."*
• Shop-specific buttons: "I don't Agree" → "Cancel", "I Agree" → "Buy". The "Terms of sale" button is removed for shop buyouts. Non-shop buyouts retain the original layout.

Purchase confirmed screen

• Title changed from "Confirm purchase:" to "Purchase Confirmed".
• Thank you message updated to: *"Thank you for your order. We will confirm your order within 1-2 business days and email you an invoice, including shipping, and a secure payment link."*

Share button settings (Appearance tab)

• Added a Share Buttons section to the BidSpirit Appearance settings tab with individual checkboxes for each sharing platform: Copy Link, WhatsApp, Facebook, Telegram, X (Twitter), VK, Pinterest, and Email.
• All platforms default to enabled (shown). Unchecking a platform hides that share button on all lot pages (both shop and regular auctions).

---

[3.7.0.7] — 2026-05-02

Identity stitch on bidder login — keyword interest tallying now actually fires

Why

The keyword extractor was filling wp_af_stats_lot_keywords correctly (197 lots, 734 distinct keywords on Clumber), but wp_af_user_interests and wp_af_user_recent_activity were both empty — zero rows of any dimension. Same on every site running the new sync streams.

Root cause: identity stitching (visitor_hash → email) only fired in the tracker AJAX when is_user_logged_in() returned true. On these auction sites the actual bidders authenticate via BidSpirit, never as wp_users — so the WP login check was always false, the stitch table stayed empty, and maybe_record_lot_view($url, $email, …) got called with an empty email and bailed out before tallying. Lot views by real bidders never landed in the user-side interest profile.

What changed (no auth-path intervention)

The fix piggybacks on the *existing* fire-and-forget tracking AJAX that already runs after a successful BidSpirit login (afLogIP("login", bidspiritUser)). It does not touch the BidSpirit auth path itself.

• inc/ip-logger.php auctionforge_ajax_log_ip() — after the existing auctionforge_user_tracking insert, if the request carries a visitor_hash and the email is valid, calls AF_Stats_Visitor_Email_Map::record($vh, $email, $ip). Wrapped in try/catch so any failure here can never break the existing tracking response.
• assets/js/app.js + src/js/app.js afLogIP() — reads localStorage['af_vid'] (defensively, ITP/private-mode safe) and includes it as visitor_hash in the POST body.
• inc/stats/class-stats-init.php maybe_record_lot_view() — when $email is empty (the common case for BidSpirit-only bidders) but a visitor_hash is present, falls back to AF_Stats_Visitor_Email_Map::lookup($visitor_hash). If a stitch exists, the view tallies; if not, it stays anonymous.

Net effect: a bidder logs in (BidSpirit), the post-login tracker AJAX fires as it always has, and now also writes one extra row into af_stats_visitor_emails. From that point onward, every page they view on the same browser/device tallies into af_user_interests keyed on their email. The BidSpirit transaction itself is untouched.

---

[3.7.0.6] — 2026-05-02

Critical fix — X-API-Key header collision with sibling SmoothByte plugins

What was wrong

On any site running both AuctionForge and another SmoothByte-stack plugin that also points its updater at wpdeploy.smoothbyteit.dev (e.g. seo-aeo-optimizer), the second plugin's http_request_args filter overwrote AuctionForge's X-API-Key header on every outbound API call. Wpdeploy then 401'd because the key it received belonged to a different plugin instance — usually a seo_aeo_update_api_key that wpdeploy had no record of.

The symptom was a quiet, total auth failure: report-health, check-updates, every sync-* route, all 401. The watchdog flagged streams as "gone" and updates stopped flowing. Affected sites: any install where the AuctionForge key and the sibling plugin's key happen to differ. Sites where both plugins shared a key were silently safe (the overwrite was a no-op).

Fix

AuctionForge_Auto_Updater::add_download_auth() now refuses to clobber an existing X-API-Key and, for download URLs, only stamps when the URL slug matches our own. That keeps targeted calls from api_request() intact regardless of filter ordering, and prevents either plugin from writing its key onto the other's download URL.

The same fix has been applied to seo-aeo-optimizer so both ends of the collision are defensive.

---

[3.7.0.5] — 2026-05-02

Sync Status admin panel — diagnostic + manual triggers in wp-admin

Why

Diagnosing sync issues used to require shell access on the site or piecing together state from wpdeploy's app.log. This release surfaces the same diagnostics inside wp-admin so a site admin (or anyone with manage_options) can see exactly what's happening and trigger fixes in one click.

Lives inside the existing Sync Status menu (Lots → Sync Status) — appended below the existing content as a "Sync Diagnostics & Manual Controls" section, no duplicate menu entry.

What's on the panel

Connection summary — plugin version, af_stats_db_version, wpdeploy server URL, last 8 chars of API key, keepalive install state + auto-reactivation count.

Sync streams table — for each of the 10 cron hooks (user-tracking, user-profile, user-interests, user-activity, lots, bids+wins, vulnerabilities, report-health, check-updates, fraud-enforcement):

• Configured schedule
• Last fired timestamp + status colour-coded (green=success, blue=idle/empty, red=error)
• Record count from last run
• Next scheduled run
• Current watermark (where applicable)
• "Fire now" button — clears doing_cron, calls do_action($hook) synchronously, shows the result

One-shot utilities

• Test wpdeploy connection — calls /api.php/info with the site's API key
• Clear stuck cron lock — deletes the doing_cron transient (the classic fix when scheduled events stop firing)
• Reinstall keepalive — overwrites mu-plugins/auctionforge-keepalive.php from the bundled template
• Backfill bids from legacy tracking — replays last_event_type='bid' rows from wp_auctionforge_user_tracking into wp_af_bid_events so the bids-wins stream picks them up. Useful for sites that have years of bid history in the legacy table but nothing in the new queue
• Run all due events now — clears doing_cron and fires every auctionforge_* cron event whose timestamp is past due, in one go

Live response output panel shows the JSON returned from each action so you can see what just happened without leaving the page.

Files Changed

• Created: inc/admin/class-sync-status-page.php
• Modified: inc/stats/class-stats-init.php (load + init the panel)
• Modified: admin/view/sync-status.php (append AF_Sync_Status_Page::render_panel() call at the bottom)
• Modified: auctionforge.php (Version 3.7.0.4 → 3.7.0.5)

Verification

Navigate to Lots → Sync Status in wp-admin on any 3.7.0.5 site. Scroll past the existing content to the new "Sync Diagnostics & Manual Controls" section. Click "Test wpdeploy connection" — you should see {"success": true, "auth_type": "site"}. Click "Fire now" on any stream — the row's last-fired timestamp should refresh after 1–2 seconds.

---

[3.7.0.4] — 2026-05-02

Self-healing: failed plugin updates can no longer take a site offline

Why

WordPress's plugin updater isn't transactional — when an update fails partway (corrupt unzip, fatal during the new version's plugins_loaded, disk pressure, theme conflict, etc.) WP often deactivates the plugin and leaves the site without it. Once AuctionForge is dropped from active_plugins, no AF code runs again — including its sync handlers — until someone notices and reactivates manually. On the AuctionForge site fleet, this had quietly happened to ~5 sites we found; almost certainly more on production sites we don't have filesystem access to.

This release ships an autonomous watchdog that lives outside the AuctionForge plugin entirely so it survives even when AF gets knocked out.

What changed

1. Self-installing keepalive (mu-plugin)

• inc/keepalive/auctionforge-keepalive.template.php — a 50-line WordPress must-use plugin. Lives in wp-content/mu-plugins/, which WordPress can't deactivate. On every plugins_loaded (priority 1, before any regular plugin), it checks: is auctionforge/auctionforge.php on disk but missing from active_plugins? If yes AND the file has a valid Plugin Name: header (smoke check — don't reactivate a corrupt zip), it re-adds AF and includes the file in the same request.
• inc/keepalive/class-keepalive-installer.php — runs on every successful AF load. Copies the template into wp-content/mu-plugins/auctionforge-keepalive.php if missing or version-bumped. Idempotent: compares KEEPALIVE_VERSION headers, only writes on change. Refuses to overwrite a foreign mu-plugin (defensive against name collisions). Failure is non-fatal — install errors are recorded in wp_options for wpdeploy visibility but never throw.

Net effect. Any site that successfully loads AF 3.7.0.4 or later will have the keepalive permanently installed in mu-plugins. From that point forward, even if a future update hard-fails, the keepalive recovers AF on the next pageview without any manual intervention or filesystem access. Crucially: this works on sites we don't own — the keepalive ships inside the AF zip, gets installed during the first successful update, and lives in mu-plugins thereafter.

2. Forensic markers

The keepalive writes three options on each recovery:

• auctionforge_auto_reactivated_at — most recent recovery timestamp
• auctionforge_auto_reactivated_count — total recoveries
• auctionforge_auto_reactivated_failed_at — set when the keepalive saw AF on disk but with no Plugin Name header (genuinely corrupt — needs operator attention)

These get picked up by the AF sync streams and surfaced on the wpdeploy dashboard so you can see which sites have been quietly recovering themselves and whether a particular release is failing more than it should.

3. Companion: post-update-silence alerts on wpdeploy (server side)

Wpdeploy's report-health route now compares incoming plugin_version against the row and writes last_version_changed_at + previous_plugin_version on change. The SyncWatchdog cron then alerts if a site has reported a version change but not sent any heartbeat for 2+ hours since — likely a failed install. Emits sync_incidents rows with kind=post_update_failure so the existing Telegram fan-out picks them up. Each version-change event alerts at most once.

Files Changed

• Created: inc/keepalive/auctionforge-keepalive.template.php, inc/keepalive/class-keepalive-installer.php
• Modified: inc/stats/class-stats-init.php (call AF_Keepalive_Installer::maybe_install() on every plugin load)
• Modified: auctionforge.php (Version 3.7.0.3 → 3.7.0.4)

Companion server-side changes (already deployed on wpdeploy.smoothbyteit.dev — not in this zip):

• sites table: last_version_changed_at TIMESTAMP NULL, previous_plugin_version VARCHAR(20) NULL
• api.php /report-health route detects version changes
• SyncWatchdog::maybe_alert_post_update_failure() emits the new alert kind

Verification

1. Drop a 3.7.0.4 install on any site. Confirm wp-content/mu-plugins/auctionforge-keepalive.php exists post-load.

2. Manually deactivate AF from the database (DELETE FROM wp_options ...active_plugins...). Hit the homepage. AF reappears in active_plugins; auctionforge_auto_reactivated_count increments.

3. Delete mu-plugins/auctionforge-keepalive.php. Trigger AF load (any pageview). The file reappears.

4. Bump KEEPALIVE_VERSION in the source template, ship a new release, observe the installed mu-plugin update on next AF load.

Operator notes

• Sites currently in the broken state (AF deactivated, no keepalive yet) are NOT auto-rescued by this release — they need a one-time manual reactivation in wp-admin OR a fresh AF install via wp-admin's Upload Plugin. After that, the keepalive is in place and future failures self-heal.
• The post-update-failure alert won't fire for upgrades that happened before this release (no last_version_changed_at was recorded). It activates from the first version change wpdeploy sees from each site after this update lands.

---

[3.7.0.3] — 2026-05-02

Fix: profile re-sync on login / profile-edit / register (no more empty names)

Why

The hourly profile sync uses a user_registered watermark — once a user has been pushed once, the watermark advances past them and they're never re-pulled. That meant:

1. Existing users whose first_name/last_name became populated AFTER their first sync stayed empty on wpdeploy forever.

2. BidSpirit-driven sites that don't write WP's standard first_name/last_name fields shipped empty rows even though the canonical name was visible in display_name.

The People view was showing — for the name on rows that absolutely had a name available — just not where the sync handler was looking.

Fixes (inc/sync/class-profile-sync.php + inc/stats/class-stats-init.php)

• AF_Profile_Sync::push_for_user_id($user_id, $blocking=false) — new public method that builds a single user's profile row, normalises it, and POSTs to wpdeploy bypassing the watermark. Non-blocking by default (wp_remote_post with blocking=false, timeout=2s) so login latency is unaffected.
• build_user_row($user_id) extracted as a reusable helper. Both the hourly batch and the on-demand push call it. Centralises role-filtering + display_name fallback + usermeta probing.
• display_name fallback. When wp_usermeta.first_name / last_name are both empty (typical on BidSpirit-only sites), build_user_row() parses display_name ("John Smith" → first=John, last=Smith) so we don't ship a row with a blank name when the data is sitting on the user record itself.
• Three new action hooks registered in class-stats-init.php::init():
• wp_login → push_for_user_id($user->ID) — every login refreshes the row
• profile_update → same — profile edits in wp-admin refresh
• user_register → same — new registrations get pushed instantly (instead of waiting up to 60 min for the next cron tick)

Files Changed

• Modified: inc/sync/class-profile-sync.php (refactor + new method + display_name fallback)
• Modified: inc/stats/class-stats-init.php (three new action hooks)
• Modified: auctionforge.php (Version 3.7.0.2 → 3.7.0.3)

Verification

1. On a 3.7.0.3 site, find a user whose wpdeploy.user_profiles.first_name is empty:

SELECT site_id, email, first_name FROM user_profiles WHERE email='something@example.com'

2. Log in as that user (or have them log in).

3. Within ~2 seconds, re-query — first_name should now be populated, either from the standard meta key OR parsed from display_name.

4. The non-blocking POST means the user's login experience is unchanged — no spinner, no extra latency.

Operator note

Existing wpdeploy rows with empty first_name/last_name will refresh automatically as users log in or edit their profile. To force a one-shot re-walk of every user on a site (regardless of watermark), reset the watermark there:

DELETE FROM wp_options WHERE option_name='auctionforge_profile_sync_watermark';

Next hourly cron will re-pull every non-admin user with the new fallback applied.

---

[3.7.0.2] — 2026-05-02

Fix: sync-lots datetime mismatch + idle syncs now heartbeat

Why

Two issues surfaced in the wpdeploy Sync Health dashboard:

1. Every site's sync-lots was stuck on api_error. The plugin sends last_modified straight from wp_bp_meta_data.lastUpdate, which is a Unix epoch string ("1756919754"). wpdeploy's lots.last_modified column is a DATETIME, so MariaDB rejects the insert with SQLSTATE[22007]: Incorrect datetime value. The handler records api_error and the watermark never advances, so every cron tick re-fails on the same batch.

2. Sites with nothing to sync looked dead. When a sync handler had an empty batch (e.g. no non-admin users yet) it was returning early without POSTing anything. wpdeploy's update_sync_health() only fires on a successful POST, so sites.sync_health_json stayed NULL and the dashboard showed grey dots — indistinguishable from a broken cron. WP-Cron was actually firing fine; the watchdog just couldn't tell.

Fixes

• inc/sync/class-lots-sync.php — new epoch_to_datetime() helper converts the BidSpirit epoch field to UTC Y-m-d H:i:s before shipping. Idempotent: already-formatted datetimes pass through untouched, invalid values become NULL.
• inc/sync/class-sync-base.php::run() — always POST, even when the batch is empty. Empty payload is {records: []} and wpdeploy's existing handlers handle it gracefully (loop is skipped, update_sync_health() still fires with synced=0). This makes the dashboard reflect cron liveness, not just data flow.

Files Changed

• Modified: inc/sync/class-lots-sync.php
• Modified: inc/sync/class-sync-base.php
• Modified: auctionforge.php (Version 3.7.0.1 → 3.7.0.2)

Verification

1. On Clumber: do_action('auctionforge_sync_lots') — confirm the previous auctionforge_last_sync-lots_status = api_error flips to success(N) and that wpdeploy.lots now contains rows.

2. On a site with no non-admin users: do_action('auctionforge_sync_user_profile') — confirm auctionforge_last_sync-user-profile_status = idle(0) AND that wpdeploy's Sync Health page now shows a green dot for that cell.

---

[3.7.0.1] — 2026-05-02

Fix: marketing data leaks WordPress admins into the people list

Why

After the 3.7.0.0 rollout the central people view on wpdeploy was showing site administrators alongside real auction-house users — the sync-user-profile handler read straight from wp_users with no role filter, so any account with administrator/editor/author/contributor/shop_manager capabilities was getting shipped as if it were a buyer. Marketing audiences must contain buyers, not staff.

Fixes (inc/sync/class-profile-sync.php)

• The read_batch() SQL now LEFT JOINs {$wpdb->usermeta} on the prefix-aware capabilities key ({$wpdb->prefix}capabilities) and filters out any user whose serialized capabilities meta_value contains administrator, editor, author, contributor, shop_manager, or super_admin. Users with IS NULL (no roles registered) are still allowed through — those are typically subscribers/buyers on this fleet.
• Watermark on auctionforge_profile_sync_watermark is unchanged; the next run after upgrade picks up the same batch with the new filter applied. Operationally the wpdeploy team also wiped the existing admin rows from user_profiles, user_interests, user_recent_activity, bids_wins, and people to clear the leak server-side — total of 35 rows scrubbed.

Files Changed

• Modified: inc/sync/class-profile-sync.php
• Modified: auctionforge.php (Version 3.7.0.0 → 3.7.0.1)

Verification on Clumber dev

1. Find a logged-in admin: SELECT u.user_email FROM wp_users u JOIN wp_usermeta um ON um.user_id=u.ID AND um.meta_key='wp_capabilities' WHERE um.meta_value LIKE '%administrator%';

2. Reset the watermark: DELETE FROM wp_options WHERE option_name='auctionforge_profile_sync_watermark';

3. Trigger sync: do_action('auctionforge_sync_user_profile');

4. On wpdeploy: confirm those admin emails do NOT appear in user_profiles (SELECT * FROM user_profiles WHERE email='admin@…'; returns zero rows).

Privacy / scope

• No API contract changes. The wpdeploy /api.php/sync-user-profile route accepts the same payload shape; this is purely a source-side filter narrowing what gets sent.

---

[3.7.0.0] — 2026-05-02

Cross-site user data lake — full Phase 2 + Phase 3 build

Why

AuctionForge sites were exposing per-lot engagement (views, favourites, bids, wins) keyed only on the anonymous af_vid localStorage hash, with no central aggregation. Marketing — even the "collect data now, send later" phase — needs a per-person view across the whole AF network: name + phone + postcode + country + IP + device fingerprint + the keywords they engage with + the bids they place + the lots they win, all rolled up across every site they've used. This release wires every piece needed for that, and keeps it sustainable: per-site aggregates rather than raw event firehose, watermarked syncs with retry, 14/30-day site-side retention, watchdog + Telegram alerts for dead streams.

See /root/.claude/plans/i-want-to-add-synthetic-goose.md for the full architecture.

New tables (idempotent dbDelta on the existing plugins_loaded migration path)

• wp_af_stats_lot_keywords — per-lot keyword cache. Title + tags + author tokenized (lowercase → drop stop-words → drop ≤2-char → drop pure-digit), one row per (post_id, keyword). Populated on save_post_lot.
• wp_af_user_interests — running tally per (user_email, dimension, dimension_value) where dimension ∈ keyword | category | author | price_band. UPSERT-keyed so increments are atomic. Bounded by users × distinct interests (typically a few dozen rows per user).
• wp_af_user_recent_activity — capped per-user activity log (last 50 events per email). Seeds the drill-down timeline on the wpdeploy person view.
• wp_af_bid_events — bid + win events (auto-created by the bids sync handler). Drained and shipped to wpdeploy hourly.
• synced_at columns added to wp_af_stats_pageviews, wp_af_stats_sessions, wp_af_stats_searches, wp_af_stats_outbound. Powers the durable sync-and-purge lifecycle.
• af_stats_db_version bumped 2 → 3. The existing AF_Stats_Init::maybe_create_tables() picks up the new tables on the next admin page load after auto-update.

New helper classes

• AF_Keyword_Extractor (inc/stats/class-keyword-extractor.php) — pure tokenizer + cache writer + read-through helper. Hooks save_post_lot to refresh on lot changes. Stop-words tunable via apply_filters('af_keyword_stop_words', ...).
• AF_User_Interests (inc/stats/class-user-interests.php) — record_view / record_favorite / record_bid / record_win. All idempotent UPSERTs. Calls AF_Stats_Tracker::should_skip() first so admins/bots never pollute interest profiles.
• AF_Sync_Base (inc/sync/class-sync-base.php) — abstract durability backbone. Reads synced_at IS NULL batches, POSTs, marks rows synced only on a confirmed 200, retries on next cron run if the POST fails. Idempotent UNIQUE keys on the wpdeploy side mean retries never duplicate.
• AF_Profile_Sync / AF_Interests_Sync / AF_Activity_Sync / AF_Lots_Sync / AF_Bids_Sync — five concrete sync streams.
• AF_Data_Purge (inc/maintenance/class-data-purge.php) — daily cron: 14-day floor on synced rows, 30-day hard cap with CRITICAL alert if any unsynced row hits the cap (which would mean wpdeploy has been unreachable for a month).

New cron schedules (auto-registered on plugins_loaded if auctionforge_update_server_url + _api_key are configured)

| Hook | Schedule | Endpoint |

|---|---|---|

| auctionforge_sync_user_profile | hourly | POST /api.php/sync-user-profile |

| auctionforge_sync_user_interests | hourly | POST /api.php/sync-user-interests |

| auctionforge_sync_user_activity | hourly | POST /api.php/sync-user-activity |

| auctionforge_sync_lots | every 10 min | POST /api.php/sync-lots |

| auctionforge_sync_bids_wins | hourly | POST /api.php/sync-bids-wins |

| auctionforge_purge_synced_data | daily | (purge cron — local) |

All sync handlers are watermarked or synced_at-gated; cron mid-run failure is harmless because the next run picks up the same rows.

Hooks fired

• af_stats_pageview_recorded($url, $email, $visitor_hash) — fires inside AF_Stats_Ajax::handle_track() after a logged-in pageview is recorded. Default listener resolves URL → lot post → AF_User_Interests::record_view().
• af_stats_lot_favorited($email, $post_id) — fires from the existing lot_analytics_record_favorite AJAX handler when a watchlist add happens. Default listener calls record_favorite().

Server-side companion (wpdeploy)

This release is paired with wpdeploy changes (handled out-of-band; not in the plugin zip):

• 5 new API routes matching the sync streams above. All return synced + watermark metadata so the plugin can advance / mark rows synced.
• update_sync_health() helper in wpdeploy — every successful sync POST writes (stream, last_seen_at, last_synced_count, state) into sites.sync_health_json.
• SyncWatchdog — 5-minute cron on wpdeploy that scans every (site × stream) cell and runs an ok → overdue → gone → recovering → ok state machine. Emits alerts via the existing sync_incidents Telegram fan-out.
• People section in the wpdeploy admin — ?tab=people (cross-site rollup with top keywords / lifetime spend), ?tab=person&email=... (drill-down with timeline + bids), ?tab=people-export (Google Customer Match + Meta Custom Audience CSV with sha256 hashing per spec).
• ?tab=sync-health — site × stream traffic-light grid showing every sync's state.

Files Changed

• Created: inc/stats/class-keyword-extractor.php, inc/stats/class-user-interests.php, inc/stats/stop-words.php
• Created: inc/sync/class-sync-base.php, inc/sync/class-profile-sync.php, inc/sync/class-interests-sync.php, inc/sync/class-activity-sync.php, inc/sync/class-lots-sync.php, inc/sync/class-bids-sync.php
• Created: inc/maintenance/class-data-purge.php
• Modified: inc/stats/class-stats-database.php (DB_VERSION = 3, new dbDelta calls, synced_at column adds)
• Modified: inc/stats/class-stats-init.php (require new classes, register sync crons, wire af_stats_pageview_recorded and af_stats_lot_favorited listeners)
• Modified: inc/stats/class-stats-ajax.php (fire af_stats_pageview_recorded after pageview record; fire af_stats_lot_favorited on watchlist add)
• Modified: auctionforge.php (Version: 3.6.4.0 → 3.7.0.0)

Verification on Clumber dev

1. After auto-update + first wp-admin page load: wp_af_stats_lot_keywords, wp_af_user_interests, wp_af_user_recent_activity all exist; af_stats_db_version = 3.

2. Save a test lot titled "Pair of Victorian silver candlesticks by Mappin & Webb" → wp_af_stats_lot_keywords has rows for victorian, silver, candlesticks, mappin, webb (and not pair, of, by).

3. Log in as throwaway test user, view 3 of those lots → wp_af_user_interests shows (test@…, keyword, 'victorian', view_count=3).

4. Wait one hourly cron, confirm wpdeploy.user_interests mirror via the wpdeploy admin → ?tab=people → search for the test email.

5. Confirm wpdeploy.sites.sync_health_json has user-interests.state = 'ok' for the Clumber site.

6. Pause the cron, wait 2h, watch the watchdog flip the cell to overdue and emit a Telegram alert.

Privacy / scope

• Admins and bots are filtered out at write time via AF_Stats_Tracker::should_skip().
• Email is normalized lowercase + trim before storage; phone normalized to E.164 (UK-aware) on the sync side.
• No outbound activation yet — wpdeploy stores everything but doesn't send anything to anyone. Marketing send mechanics (consent flag, suppression list, sender) explicitly deferred.

---

[3.6.4.0] — 2026-05-02

Identity stitching: visitor_hash → user_email

Why

The af_stats_* tables (pageviews, sessions, searches, outbound) and the lot-engagement tables (af_lot_analytics, af_lot_shares) currently store activity keyed only on the anonymous af_vid localStorage hash — there is no link from any browsing event to the user's email even when they're logged in. Without that link, the central wpdeploy server can never aggregate behavioural data on a per-person basis, which is the prerequisite for the cross-site user-data lake being built on wpdeploy (see /root/.claude/plans/i-want-to-add-synthetic-goose.md Phase 1).

This release adds the bridge: every authenticated tracker hit records a (visitor_hash, user_email) pair into a new table. From here on, anonymous browsing can be resolved to an email via JOIN for any session the user was logged in.

Changes

• New table wp_af_stats_visitor_emails — (visitor_hash, user_email, ip_address, first_seen, last_seen) with UNIQUE(visitor_hash, user_email) + index on user_email. Created via dbDelta inside the existing AF_Stats_Database::create_tables() so it ships through the standard plugins_loaded migration path — no manual reactivation needed after auto-update.
• af_stats_db_version bumped 1 → 2. AF_Stats_Init::maybe_create_tables() now compares against the new AF_Stats_Database::DB_VERSION constant rather than a hard-coded < 1, so future schema bumps (Phase 2 onwards) just require constant edits + new dbDelta calls.
• Identity record on every authenticated tracker hit. AF_Stats_Ajax::handle_track() now calls AF_Stats_Visitor_Email_Map::record($visitor_hash, $email, $ip) whenever is_user_logged_in() is true. Trust boundary: the email is read server-side from wp_get_current_user() — clients cannot assert who they are.
• Defensive table-exists guard. The new helper short-circuits silently if the migration hasn't run yet on a given site (race window on the very first request after auto-update); the next request finds the table and proceeds. No fatals, no missing rows.
• Email normalised at write time — lowercase + trim + is_email() validation before storage. Marketing audience match-rates downstream depend on consistent casing.

Files Changed

• Created: inc/stats/class-visitor-email-map.php
• Modified: inc/stats/class-stats-database.php (DB_VERSION constant; new table; drop_tables list)
• Modified: inc/stats/class-stats-init.php (require new helper; migration check uses constant)
• Modified: inc/stats/class-stats-ajax.php (record pair in handle_track)
• Modified: auctionforge.php (Version header bump)

Verification on Clumber dev

1. After auto-update, load any wp-admin/* page once → wp_af_stats_visitor_emails exists, af_stats_db_version = 2.

2. Log in as a test user, browse 5 lots → exactly one row in wp_af_stats_visitor_emails for that (visitor_hash, email) pair, with last_seen updating on each hit.

3. SELECT email FROM wp_af_stats_visitor_emails WHERE visitor_hash IN (SELECT visitor_hash FROM wp_af_stats_pageviews WHERE created_at > NOW() - INTERVAL 1 HOUR) returns the test email — proving the JOIN works.

Privacy / scope

• This change writes a (visitor_hash, email) pair to a single new table on the AF site. Nothing is sent to wpdeploy yet — the sync stream lands in Phase 2.
• Anonymous (logged-out) browsing is unaffected: no row is created until the user authenticates.
• Bots are still skipped via AF_Stats_Tracker::is_bot() before any tracking writes.

---

[3.6.3.1] — 2026-05-01

Fix: New lots never processed + Live console improvements

Why

When BidSpirit adds new lots to an auction (e.g. items 683-692), the sync pipeline correctly staged all 709 lots into import_history but the InsertLotsBS processing loop exited after the first batch of 500 unchanged lots, never reaching the genuinely new lots at the tail of the queue. This caused new lots to remain permanently stuck in staging — synced but never created as WordPress posts.

Separately, the admin Live Console was replaying the entire log history from the beginning on every page load, and showed long silent gaps during API calls with no indication of what the worker was doing.

Fixes

• InsertLotsBS loop break condition — The stage 5 insert loop in CatalogSyncWorker::process() and processDayEnded() previously broke when updated lots === 0, even if the batch had cleared hundreds of unchanged ("unupdated") lots from the queue. New lots with higher IDs were never reached. Now breaks only when both updated lots and unupdated lots are 0, meaning the staging queue is truly empty.
• Live Console starts from current position — consoleSinceId was hardcoded to 0, causing the console to page through the entire af_sync_log table (50 rows at a time) before reaching real-time entries. Now initializes to SyncLogger::getLatestId() so only entries created after page load appear.
• queueIsActive declaration order — Variable was declared after functions that referenced it, causing the console to always start at the slow 3s polling rate even when a worker was active. Moved declaration before first use.
• Progress logging during API calls — LotList::auctionProcessing() made 2-3 BidSpirit API calls with zero SyncLogger entries, creating long silent gaps in the console. Added log entries for API fetch start, response received (with duration), data staged, and API errors.
• Per-auction progress in bulk runs — LotList::run() now logs Processing auction X/Y: {id} for each auction in the bulk loop, and logs skipped auctions.
• processDayEnded insert loop logging — Added batch progress logging and timeout guard matching the process() method pattern. Previously this loop was completely silent.

Files Changed

• Modified: inc/sync/CatalogSyncWorker.php, inc/import/LotList.php, admin/view/sync-status.php

---

[3.6.3.0] — 2026-05-01

Public Auctions API — Token Authentication

Why

The /wp-json/auctionforge/v1/public/auctions endpoint added in v3.6.2.9 was publicly accessible. Since auction data should only be served to authorized aggregator sites, the endpoint now requires a valid auth token.

Changes

• Token verification — The PublicAuctions REST endpoint now validates an X-AF-Token header (or ?token= query parameter) against the site's existing Webhook auth token from AuctionForge settings.
• Returns 401 Unauthorized for missing/invalid tokens and 403 Forbidden if no auth token is configured on the site.
• Uses hash_equals() for timing-safe comparison.

Files Changed

• Modified: auctionforge.php, inc/api/PublicAuctions.php

---

[3.6.2.9] — 2026-05-01

Public Auctions REST API Endpoint

Features

• New REST endpoint GET /wp-json/auctionforge/v1/public/auctions — Exposes auction list data (title, date, image, state, catalog link) for consumption by the AuctionForge Hub plugin on parent/main sites.
• Parameters: type (upcoming or past, default: upcoming), limit (max results, default: 50).
• Handles multi-day auctions with correct part numbers and catalog links.
• Returns auction metadata including auction_id, source_site, and day_index for deduplication.

Files Changed

• Modified: auctionforge.php, inc/coreIncludes.php
• Created: inc/api/PublicAuctions.php

---

[3.6.2.8] — 2026-04-30

Suppress alerts for transient retry conditions

Why

The "BidSpirit API returned 0 lots — catalog may not be ready yet" message is logged when the BidSpirit webhook fires before the auction catalog is fully published. The safety cron retries the job automatically and it usually succeeds on the next attempt — there's no operator action required, so a Telegram alert is just noise.

Fix

• New private helper SyncLogger::isSuppressedFromAlerts($message, $context) matches the message against a substring allowlist of known-transient errors. When matched, the row is still inserted into af_sync_log (so the in-app sync console still shows the retry chain) but the auctionforge_sync_error_logged fan-out action does NOT fire — wpdeploy and Telegram stay quiet.
• Default suppression substrings: "BidSpirit API returned 0 lots", "catalog may not be ready yet".
• Extendable via the new auctionforge_sync_alert_suppress_patterns filter — themes/MU plugins can add their own substrings.

Files Changed

• Modified: auctionforge.php, inc/sync/SyncLogger.php

---

[3.6.2.7] — 2026-04-30

Typo fix

• Settings → Connections tab: the placeholder/help text under the Server field showed https://my-accaunt.bidspirit.com/ (extra "a"). Now reads https://my-account.bidspirit.com/.

Files Changed

• Modified: auctionforge.php, inc/controllers/Settings.php

---

[3.6.2.6] — 2026-04-30

Fix stale plugin_version in reports

Why

Sites were reporting their old version to wpdeploy long after they'd been upgraded — e.g. Lonsdale Auctioneers ran v3.6.1.1 but kept telling wpdeploy it was on v2.9.6. Root cause: the constant AUCTIONFORGE_VERSION is read from the plugin file's Version: header *once at plugin load*, then frozen into $this->current_version on the auto-updater instance. After a plugin upgrade replaces the file on disk, existing PHP-FPM workers keep using the cached constant value until they're recycled, so every report from those workers carries the old version.

Fix

• New helper AuctionForge_Auto_Updater::get_live_version() reads the version directly from the plugin file's header on each call (via get_file_data() — uncached).
• report_health, push_sync_error_immediate, and retry_sync_errors now send get_live_version() instead of the cached constant.
• The pre-existing iteration through active plugins inside report_health already used get_plugin_data() per plugin, so secondary plugin entries were already accurate; only the top-level plugin_version field was stale.

Files Changed

• Modified: auctionforge.php, inc/class-auto-updater.php

---

[3.6.2.5] — 2026-04-30

Real diagnostics for plugin self-updates

Why

The wpdeploy update_queue table had a 46% historical failure rate, but every single failure row stored the literal string "Installation failed" — collapsing every failure mode into one opaque error with no diagnostic value. Root cause: the install_update() method in both clients (AF auto-updater and wpd-client) treated Plugin_Upgrader::upgrade() as a boolean, throwing away WP_Error objects and skin-emitted error messages.

Fixes (inc/class-auto-updater.php install_update())

• Refreshes the update_plugins transient before invoking the upgrader. The upgrader reads from this transient to know what version to download; if WP hasn't checked recently, the upgrader silently returns false (looking like a failure even though there's a real update queued at wpdeploy).
• Distinguishes WP_Error, false/null, and success. WP_Error was previously treated as truthy → reported as "completed" even on failure. Now extracts the error code and message.
• Reads Automatic_Upgrader_Skin::get_errors() to surface the real upgrader-emitted error messages.
• Reads $upgrader->result which holds the final WP_Error for some failure paths.
• Captures PHP errors/warnings emitted during the upgrade (file-move issues, etc.) via a temporary set_error_handler.
• Detects "no update in transient" as a distinct failure cause and labels it explicitly so we know it's a transient-cache problem, not an actual install failure.
• Truncates the combined diagnostic to 1000 chars before sending.

The same fix is applied to wpd-client.php (the WPD client plugin shipped from client-plugin/wpd-client.php on the wpdeploy server).

Files Changed

• Modified: auctionforge.php, inc/class-auto-updater.php

---

[3.6.2.4] — 2026-04-30

Bulk-sync worker dispatch fix

Fixes

• The HTTP-loopback worker (auctionforge_rest_sync_worker in auctionforge.php) had its own switch statement for job-type dispatch, distinct from the one in crontasks/syncWorker.php. The new full_sync_upcoming and full_sync_past job types were only added to the CLI worker, so the loopback path produced "Unknown job type" errors. Both switches now route those types to BulkSyncWorker::process.
• inc/coreIncludes.php now require_onces BulkSyncWorker.php so the class is available wherever sync code runs.

Files Changed

• Modified: auctionforge.php, inc/coreIncludes.php

---

[3.6.2.3] — 2026-04-30

Fixes for end-to-end Telegram round-trip

Fixes

• verify_api_key reads the option fresh on every call (hash_equals against get_option('auctionforge_update_api_key')) instead of relying on the cached $this->api_key from constructor time. Different FPM workers can hold different cached values when the option drifts (e.g. via auto-heal collisions), which previously produced intermittent 401s on REST endpoints.
• New REST endpoint POST /wp-json/auctionforge/v1/sync/version — wraps the existing trigger-install flow with a JSON response (always HTTP 200 with success flag). The original endpoint returned WP_Error('no_update', …, status: 404) when the plugin was already on the latest version, which nginx's error_page 404 directive then clobbered with a static HTML 404 page on hosts using aaPanel/BTWAF. Keeping the URL under /sync/* matches the pattern that's already proven to pass through host WAFs.

Files Changed

• Modified: auctionforge.php, inc/class-auto-updater.php

---

[3.6.2.2] — 2026-04-29

Catalog-sync kind disambiguation

Fix

• catalog_sync jobs target a single auction that may be either active or archived. Until now their alerts were always classified as kind=upcoming. The classifier now resolves the auction's auction_state term meta and routes:
• ARCHIVED / ENDED / POST_AUCTION → kind=past → Kill + Full Past buttons
• anything else (or unresolvable) → kind=upcoming → Kill + Full Upcoming buttons

Files Changed

• Modified: auctionforge.php, inc/class-auto-updater.php

---

[3.6.2.1] — 2026-04-29

Telegram Sync Monitoring follow-ups

Features

• Context-aware alert buttons. Each Telegram alert now shows the action set most relevant to the failing sync: upcoming-sync errors get Kill + Full Upcoming, past-sync errors get Kill + Full Past, everything else gets Kill only. Button choice is driven by a new kind field classified at log-write time from the queue's job_type.
• Plugin version in alerts + Update button. Each push now includes the live plugin_version. wpdeploy compares it to the latest is_stable=1 row in its versions table and only renders an Update plugin button when the site is behind. Tapping Update calls the existing POST /wp-json/auctionforge/v1/trigger-install endpoint to force the upgrade.

Architecture

• New private helper AuctionForge_Auto_Updater::classify_error_kind($jobId) looks up the job's job_type and maps it to 'upcoming' / 'past' / 'other'. Used by both the immediate push and the 1-min retry cron.
• Outbound payloads now include plugin_version at the top level; wpdeploy refreshes sites.plugin_version on every /sync-errors POST.

Files Changed

• Modified: auctionforge.php, inc/class-auto-updater.php

---

[3.6.2.0] — 2026-04-29

Telegram Sync Monitoring & Remote Control

Features

• Instant Telegram alerts on sync errors. Any level='error' row written to af_sync_log is pushed (fire-and-forget, non-blocking) to wpdeploy, which fans it out to a configured Telegram group with inline-keyboard action buttons (Kill / Full Upcoming / Full Past / Acknowledge).
• Remote command surface. Any group admin can tap a button to:
• Kill sync — flips DB flags via SyncQueue::cancelAll(), then SIGTERMs every active worker; a 5-second watchdog escalates to SIGKILL for any survivor.
• Full sync upcoming — full re-import of every active auction and its lots (queued, observable, killable). Replaces the re-sync?do=importBidSpiritUpcoming flow with a queued equivalent.
• Full sync past — same, for archived auctions.
• Safety-net retry cron (auctionforge_retry_sync_errors, every minute) re-pushes recent error rows. wpdeploy dedupes via UNIQUE(site_id, af_log_id) so duplicates are silent.

Architecture

• SyncLogger::log() now fires do_action('auctionforge_sync_error_logged', …) on level='error' so any handler can react. The auto-updater listener does a 2 s non-blocking POST to /api.php/sync-errors.
• New REST endpoint POST /wp-json/auctionforge/v1/sync/cancel-all (X-API-Key auth) — runs SyncQueue::cancelAll() + SIGTERM + watchdog. Logs every action through SyncLogger.
• POST /sync/start extended with a mode parameter (upcoming default, past for archived). Bulk re-sync is now a queued job, not a synchronous block.
• New job types full_sync_upcoming and full_sync_past on SyncQueue, dispatched to a new BulkSyncWorker that wraps the existing AuctionList::init() + LotList::init($upcoming) pipeline.
• syncWorker.php installs a SIGTERM handler that flips the in-flight job to failed with a "Killed by admin (SIGTERM, cleanup OK)" marker and closes the DB cleanly before exiting. Watchdog escalates to SIGKILL after 5 s grace.
• LotList::auctionProcessing() now heartbeats the active bulk-sync job between auctions, preventing the safety cron from auto-failing long bulk runs as stale (the 600 s threshold is unchanged).

Files Changed

• Modified: auctionforge.php, inc/sync/SyncLogger.php, inc/sync/SyncQueue.php, inc/class-auto-updater.php, crontasks/syncWorker.php, inc/import/LotList.php
• Created: inc/sync/BulkSyncWorker.php

---

[3.6.1.6] — 2026-04-29

High-Value Lot Modes for [bp_lot_list]

Features

• high_value_past mode — Displays past auction lots ordered by their catalog estimate (estimatedPriceInt), highest first. Useful for "Top Lots" or "Highlights" sections.
• high_value_sold mode — Displays past sold lots ordered by their actual sold price (soldBid), highest first. Only includes genuinely sold lots (soldBid > 0) and reuses the same false-positive guard as random_past to skip lots where soldBid was carried over from startPrice without real bidding activity.
• Admin documentation updated — The Shortcodes reference page in WP Admin now lists both new modes in the mode attribute description and includes example shortcode usage.

Architecture

• New constants MODE_HIGH_VALUE_PAST and MODE_HIGH_VALUE_SOLD on LotsWidget.
• New method LotsWidget::getLotListHighValue($mode, $limit) builds the query, applies the past-auction tax filter, sets bp_orderby to the relevant meta field with DESC order, and (for the sold variant) filters out unsold-but-stale lots in PHP.
• New filter hook bp_lot_list_high_value_args_filter for downstream customization of the WP_Query args.

Files Changed

• Modified: inc/widgets/LotsWidget.php, inc/controllers/ShortcodesPage.php

---

[3.6.0.18] — 2026-04-25

Brevo SMS Notifications Integration

Features

• Transactional SMS via Brevo API — The plugin now sends text message alerts through the Brevo transactional SMS service, running alongside existing Firebase push notifications.
• Four Notification Types:
• New Auction Published — Broadcast SMS to all opted-in subscribers when an auction is published.
• Auction Starting Soon — Targeted SMS to users registered for an auction when it is about to start.
• Favorited Item Live Soon — Targeted SMS to users who favorited a lot when it is approaching in the auction.
• Outbid Notice — SMS sent when a user's leading bid is surpassed, with a 5-minute per-item cooldown to prevent spam.
• SMS Subscriber Database — New af_sms_subscribers table stores user phone numbers, country codes, and per-notification-type opt-in preferences (GDPR-ready explicit consent).
• Admin Settings Tab — New "SMS Notifications" tab in Settings with:
• Brevo API Key input
• SMS Sender Name (11 char max)
• Master enable/disable toggle
• Per-notification-type on/off switches
• Test SMS widget with phone input and send button
• Live subscriber count display
• Profile SMS Preferences — Users can opt into SMS notifications directly from their profile page with phone number entry and granular notification type selection.

Architecture

• BrevoSMS Service (inc/services/BrevoSMS.php) — cURL-based API wrapper with broadcast, targeted, and single-send methods, message builders with 160-char limit awareness, rate limiting, and comprehensive error logging.
• SMSSubscriber Model (inc/model/SMSSubscriber.php) — CRUD operations, email-to-phone resolution, opt-in filtering, and upsert logic.
• Webhook Integration — SMS dispatch hooks added to AuctionsAPI.php methods: leading_bid_surpassed(), item_live_soon(), auction_starts_soon(), and auctionPublishedPush().

AJAX Handlers

• auctionforge_sms_save — Save SMS preferences from profile page
• auctionforge_sms_load — Load SMS preferences for profile page
• auctionforge_sms_test — Admin-only test SMS endpoint

Database

• New table: af_sms_subscribers — Phone numbers, country codes, per-notification opt-ins, timestamps

Files Changed

• Modified: auctionforge.php, inc/coreIncludes.php, inc/controllers/AuctionsAPI.php, inc/controllers/Settings.php, admin/view/settings.php, templates/parts/profile-templates.php
• Created: inc/services/BrevoSMS.php, inc/model/SMSSubscriber.php

---

[3.6.0.7] — 2026-04-14

Hotfix

Fixes

• Namespace resolution — Fixed fatal error in wp_footer commission label hook caused by unqualified SettingsHelper and Settings class references. Now uses fully qualified namespaces.

Files Changed

• Modified: auctionforge.php

---

[3.6.0.6] — 2026-04-14

Commission Label Override Fix

Fixes

• Theme template override compatibility — Moved the commission label JS override from the single-lot.php template into auctionforge.php via wp_footer hook (priority 99). Sites with theme-level template overrides (e.g. themes/*/auctionforge/single-lot.php) were not picking up the inline script. The wp_footer approach works universally on all single lot pages.

Files Changed

• Modified: auctionforge.php, templates/single-lot.php

---

[3.6.0.5] — 2026-04-14

Commission Label Override

Features

• Commission Label Setting — New dropdown in Settings → Appearance allowing admins to choose between "Buyer's Premium" (default) and "Auction House Commission" as the label displayed on lot pages. This overrides the Bidspirit JS client's default label using a MutationObserver that catches asynchronously injected text.

Files Changed

• Modified: inc/controllers/Settings.php, templates/single-lot.php

---

[3.6.0.4] — 2026-04-12

Auction Approval Modal Redesign

Changes

• Removed BidSpirit Terms of Use — The generic BidSpirit "Terms of Use" section that appeared at the top of the non-credit-card approval modal has been removed. The modal now shows only the auction house's own legal agreements managed within the plugin.
• Renamed Modal Title — Changed "Terms of conditions" to "Terms & Conditions".
• Larger Scroll Area — The Terms & Conditions scroll box is now 350px tall (up from 200px) for easier reading.
• Proportional Section Heights — Refund & Return Policy and Chargeback Waiver sections use a shorter 260px scroll box to visually distinguish them from the primary Terms & Conditions.

Files Changed

• Modified: templates/js-chunks/approval-info.php, assets/js/app.js

---

[3.6.0.2] — 2026-04-10

Webhook Token Generator

Features

• Token Generator Widget — Added a 16-character random token generator directly below the "Webhook auth token" field on the Settings page. Includes a "Generate Token" button and a clipboard copy icon with visual feedback.

Files Changed

• Modified: inc/controllers/Settings.php

---

[3.6.0.1] — 2026-04-10

Patch

Changes

• Version bump.

---

[3.6.0.0] — 2026-04-10

Legal Agreements for Auction Approval

Features

• Terms & Conditions — A mandatory, scrollable Terms & Conditions document is now displayed during the auction approval process. Bidders must scroll to the bottom and check an agreement box before their approval request is submitted. Always enabled.
• Refund & Return Policy — An optional, scrollable Refund & Return Policy can be enabled in Settings. When enabled, bidders must read and accept it during auction approval.
• Chargeback Waiver — An optional, scrollable Chargeback Waiver can be enabled in Settings. When enabled, bidders must read and accept it during auction approval.
• Admin Management — New "Legal Agreements" page under the Bidspirit admin menu with tabbed TinyMCE editors for each agreement type. Includes automatic version numbering (incremented on content change) and full version history.
• Consent Logging — Every agreement acceptance is logged to a dedicated database table (af_user_agreement_log) with the agreement type, version, user email, IP address, user agent, auction ID, and timestamp.
• User Tracking Integration — Agreement events (terms_agreement, refund_agreement, chargeback_waiver) are also recorded in the existing IP tracking system alongside registration, login, and bid events.
• Placeholder Content — Default sample content is seeded on plugin activation for all three agreement types.

Settings Added

• Enable Refund & Return Policy — Toggle to require bidders to accept the refund policy during auction approval.
• Enable Chargeback Waiver — Toggle to require bidders to accept the chargeback waiver during auction approval.

Database

• New table: af_legal_agreements — Current active agreement content per type
• New table: af_legal_agreement_versions — Version history archive
• New table: af_user_agreement_log — User consent records

Files Changed

• Modified: auctionforge.php, inc/controllers/Settings.php, inc/controllers/BidspiritViews.php, inc/ip-logger.php, templates/js-chunks/approval-info.php, assets/js/app.js
• Created: inc/legal/class-legal-agreements.php, admin/view/legal-agreements.php

---

[3.5.0.6] — 2026-04-08

Bid Event Tracking

Features

• Bid Tracking — All successful bids (regular, catalog, pre-sale buyout, post-sale purchase) now fire afLogIP("bid", bidspiritUser) to capture the bidder's full identity in the user tracking table.
• Whitelist Update — Added bid to the allowed event_type values in both the local plugin and the central WPDeploy API.

---

[3.5.0.5] — 2026-04-08

Self-Healing Database Schema

Features

• Auto-Migration — The plugin now auto-detects and adds any missing tracking table columns on version upgrade, ensuring sites with older schemas seamlessly migrate without manual SQL.

---

[3.5.0.4] — 2026-04-08

API Key Auto-Healing

Features

• Seamless Self-Registration — The WordPress plugin now autonomously regenerates and saves a fresh API Key whenever WPDeploy rejects a payload with an api_key_collision error. This guarantees zero-downtime security handovers when developers clone instances to proxy/staging servers.

---

[3.5.0.3] — 2026-04-08

API Key Collision Defense

Features

• Network-Level Quarantine — Central API dynamically extracts and strictly validates the incoming payload domain against the registered API Key domain, forcefully blocking mismatched traffic (HTTP 403).
• Local Critical Alert Banner — Added a persistent crimson warning banner in the WordPress admin panel that intercepts api_key_collision errors, directly instructing developers to update cloned keys.

---

[3.5.0.2] — 2026-04-08

Modal Trigger Hotfix

Fixes

• Restructured internal UI rendering priority to gracefully deploy the inline Modal triggers inside custom IP log view without colliding with cached z-index stacks.

---

[3.5.0.1] — 2026-04-08

Hotfix

Fixes

• Timed Auction Badge Visibility — Fixed a strict type-matching bug in the main auction_list.php core file that incorrectly hid the "Timed Auction" badge overlay from valid timed/online auctions on the main upcoming/archive views. The badge now displays properly across all manual and Bidspirit-synced objects when toggled on.

Files Changed

• Modified: templates/main/auction_list.php

---

[3.2.9.1] — 2026-03-30

Timed Auction Display Enhancements

Features

• Timed Auction Countdown Text Toggle — Added a WP-Admin setting "Change text to 'Auction will close in'" that conditionally changes the countdown label for timed/online auctions on single lot pages.
• Shortcode Text Toggle Support — Extended the new countdown text logic to the bp_upcoming_wide shortcodes so "Live bidding starts in:" successfully transitions to "Auction will close in:" for timed auctions.

Files Changed

• Modified: inc/controllers/Settings.php, templates/single-lot.php, templates/shortcodes/upcoming-auction-wide.php, templates/shortcodes/upcoming-auction-wide-manual.php

---

[3.2.9.0] — 2026-03-29

Billing & Invoices Polish

Fixes

• Profile Invoice ID Tracking — Prevented internal auction codes (e.g. 002 or ai4) from breaking into the clean hyphenated titles inside the profile-templates.php view.
• Dynamic Payment Statuses — Replaced Bidspirit's default/cached NOT PAID HTML payloads by wiring the dompdf generator to directly respect the current $b.status string from the API (resolving instances where a paid invoice still printed "NOT PAID" atop the document).
• Payment Instructions Conditional — Automatically hide the "Payment Instructions" block from the PDF footer when an invoice is fully paid.
• Improved Nomenclature — Changed "Invoice No:" to "Bidder No:" on document output to prevent confusion with static invoice ledger IDs.

---

[3.2.6.0] — 2026-03-28

Multi-Day Auction Lot Filtering Fix

Fixes

• Day 2+ showing lots from Day 1 in multi-day auctions — The itemIndex column in bp_meta_data is varchar(55), but the day-range filter in BidspiritQuery::bp_query_where() was comparing it as a string. With string comparison, lot numbers like '11', '101'–'145' incorrectly fell between '1001' and '1450', causing Day 1 lots to leak into Day 2 results. Fixed by using CAST(bpMeta.itemIndex AS UNSIGNED) for numeric comparison and intval() on the PHP-side boundary values. Letter lots (e.g. 14A, 1025A) are handled correctly — CAST strips the suffix, keeping them grouped with their base lot number.

Files Changed

• Modified: inc/controllers/BidspiritQuery.php

---

[3.2.5.9] — 2026-03-27

Catalog Page Fix

Fixes

• Duplicate preview hours on catalog pages — The displayHours field was rendered twice: once via the bp_after_description_auction hook in BidspiritViews.php and once inline in the auction template. Removed the hook-based rendering to eliminate the duplication.

Files Changed

• Modified: inc/controllers/BidspiritViews.php, templates/main/auction.php

---

[3.2.5] — 2026-03-19

Sync Reliability & Stuck Lot Prevention

Fixes

• CATALOG_PUBLISHED webhook now triggers catalog sync — Previously only sent push notifications without syncing lots. When the earlier AUCTION_CATALOG_UPDATED fired before the catalog was ready on BidSpirit, lots were never imported. CATALOG_PUBLISHED now calls auctionCatalogUpdated() to trigger a full catalog sync when the catalog is actually available.
• 0-lot API results now fail instead of silently succeeding — When BidSpirit API returns 0 lots (catalog not yet ready), the sync job now fails with an explicit error message, allowing the next webhook to create a fresh retry job.
• Expanded CDN allowlist in pre_http_request filter — The HTTP filter during bulk post insertion now allows all *.bidspirit.com subdomains and BidSpirit image CDNs (fastly.net, cloudfront.net). Previously only bidspirit.com and www.bidspirit.com were allowed, blocking image downloads during sync and causing worker hangs.
• InsertLotsBS timeout guard — Stage 5 (InsertLotsBS processing loop) now has a 180-second timeout and logs progress every 2 batches. Prevents indefinite hangs that previously required manual force-kill.
• fixResult() no longer marks lots as done when postId=0 — When lotProcessing() fails to create a WP post, the staging row now keeps syncFinished=0 so the lot is retried on the next sync pass, instead of being permanently marked as complete with no actual post.
• lotProcessing() logs error on missing auction term — Previously returned 0 silently when Auction::findAuctionById() failed. Now logs an explicit error that feeds into fixResult() to keep the lot retryable.
• Hourly orphan detection in safety cron — New step in syncSafety.php detects lot posts that exist in bp_meta_data but are missing their auction taxonomy assignment (caused by workers killed mid-batch) and auto-repairs them with wp_set_object_terms().

Files Changed

• Modified: inc/controllers/AuctionsAPI.php, inc/sync/CatalogSyncWorker.php, inc/abs/InsertLotsAbstract.php, inc/import/InsertLotsBS.php, crontasks/syncSafety.php

---

[3.2.4] — 2026-03-18

Sync Worker Hang Fix

Fixes

• Sync workers hanging at InsertLotsBS stage — Third-party plugins (Smush Pro, SmartCrawl SEO, WPMU DEV Updates) hook into wp_insert_post() and make blocking outbound HTTPS calls for every lot processed. With 489+ lots per auction, this caused workers to hang indefinitely on socket reads to WPMU DEV servers (32.193.94.25, 32.193.93.106). Added WP_IMPORTING constant at the REST worker entry point and a pre_http_request filter in CatalogSyncWorker that blocks all non-essential external HTTP during the batch post-insertion phase. Loopback (127.0.0.1, localhost) and BidSpirit API calls remain allowed.
• Stuck staging rows after force-kill — When workers were force-killed mid-sync, staging rows in import_history were left with syncstart=1 and never unblocked. Subsequent sync runs could not see these rows (filtered out by Lot::getRawLots()), causing the InsertLotsBS loop to exit immediately with 0 posts processed. Combined with job deduplication (SyncQueue::enqueue() skips if a processing job exists), this created a deadlock where no new sync could proceed.

Files Changed

• Modified: auctionforge.php, inc/sync/CatalogSyncWorker.php

---

[3.2.2] — 2026-03-17

Full Sync Auction Discovery Fix

Fixes

• Full Sync finds no auctions on fresh sites — The v3 full_sync action only queried the WordPress database for existing auction terms, but on a freshly deployed site the database has zero auctions. Added AuctionList::init() discovery step before querying the DB, so Full Sync now fetches all auctions from the BidSpirit API and creates taxonomy terms first, then enqueues catalog sync jobs for each.

Files Changed

• Modified: auctionforge.php

---

[3.2.0] — 2026-03-14

Webhook Pipeline Fixes, Archive Sync & Admin UI Overhaul

New Features

• Archive Sync — New "Archive Sync" button on Sync Status admin page. Enqueues catalog sync jobs for all ARCHIVED/ENDED auctions. Past auctions now appear in the auction dropdown with an optgroup separator and state label.
• Sync Tasks v3 — Replaced old v2 task cards (importData, importBidSpirit, lotBidSpiritOld) with v3 queue-based tasks. "Sync Active Auctions" and "Sync Archived Auctions" now enqueue jobs via the queue system. Maintenance tasks (Clean Draft/Trash Lots, Clean Orphaned Meta) remain as direct-execution tasks.
• How It Works guide rewritten — Complete rewrite of the admin guide for v3 architecture. Documents webhook-first flow, all 5 job types, queue system mechanics, cron setup (external + WP-Cron), configuration constants, and troubleshooting.

Fixes

• Dual-write removed — Removed legacy handlers from auctionCatalogUpdated(), auctionDayEnded(), and itemsUpdated() webhook methods. The old handlers were racing with the v3 worker, creating orphaned staging rows in import_history that were never processed. All three methods now exclusively use the v3 enqueue → spawn path.
• ITEMS_UPDATED webhook — Fixed itemsUpdated() failing to enqueue jobs. The ITEMS_UPDATED payload has auctionId nested in itemsByLanguage.{lang}[0].item.auctionId, not at the top level. Added extraction logic to resolve it.
• ItemUpdateWorker incomplete — ItemUpdateWorker::process() was only calling Lot::bulkSave() (staging table) without running InsertLotsBS to process staged data into WP posts and bp_meta_data. Added the InsertLotsBS processing step with autocommit restore. Item updates now flow: stage → InsertLotsBS → WP post + meta → cache clear.
• Worker spawn reliability — Changed SyncQueue::spawnWorker() from non-blocking HTTPS to blocking HTTP loopback (http://127.0.0.1 with explicit Host header, 2s timeout). Fixes nginx 403/404 errors when HTTPS loopback hits the default vhost instead of the site's vhost.
• API token constant — Plugin expects AUCTIONFORGE_API_TOKEN in wp-config.php (renamed from UCO_API_TOKEN during the plugin rename). Documented in readme.

Database

• DB version: 22 → 23

Files Changed

• Modified: inc/controllers/AuctionsAPI.php, inc/sync/ItemUpdateWorker.php, inc/sync/SyncQueue.php, auctionforge.php, admin/view/sync-status.php, readme.txt

---

[3.0.0] — 2025-03-14

New Feature: Webhook-First Sync Architecture (Sync v3)

Overview: Complete redesign of the BidSpirit data synchronisation pipeline. Replaces the old two-phase polling system (importBidSpirit every hour + importData every minute) with a webhook-driven job queue that processes data in near real-time.

Architecture

• Webhook-driven sync — BidSpirit webhooks now enqueue jobs into a dedicated queue table (af_sync_queue) instead of relying solely on polling cron tasks. Data flows: webhook → queue → background worker → WordPress posts.
• Dual-write mode — During transition, webhooks enqueue jobs AND still run the legacy handlers. Once verified, legacy handlers can be removed cleanly.
• Job deduplication — Prevents duplicate work by checking for existing pending/processing jobs with the same auction_id + job_type.

New Components

• Job Queue System (inc/sync/SyncQueue.php) — Priority-based FIFO queue with atomic job claiming, status tracking (pending/processing/completed/failed/skipped), worker PID tracking, and automatic stuck job recovery.
• Sync Logger (inc/sync/SyncLogger.php) — Real-time log table for admin console polling with level filtering (info/success/warning/error) and incremental cursor-based retrieval.
• Catalog Sync Worker (inc/sync/CatalogSyncWorker.php) — Processes catalog_sync, full_sync, and day_ended jobs by reusing existing LotList::singleRun() logic.
• Item Update Worker (inc/sync/ItemUpdateWorker.php) — Processes individual item_update jobs with the same logic as the webhook itemsUpdated handler.
• Background Worker (crontasks/syncWorker.php) — Async CLI process spawned by webhooks via exec() or by the safety cron. Claims and processes queued jobs with a configurable timeout (default 240s).
• Safety Net (crontasks/syncSafety.php) — Hourly cron that resets stuck jobs (>10min), spawns workers for pending jobs, runs a 24-hour health check (auto-enqueues full sync if no webhooks received), and purges old data.

Admin UI

• Queue Status Dashboard — New card on Sync Status page showing pending/processing/completed/failed/skipped counts, recent jobs table with real-time refresh, worker status badge, and action buttons:
• Full Sync — Enqueues catalog sync for all active auctions
• Sync Selected — Enqueue a single auction from dropdown
• Spawn Worker — Manually trigger a background worker process
• Live Console — Dark-themed terminal console on the Sync Status page. Polls af_sync_log every 1.5s showing timestamped, color-coded log entries from webhooks, workers, queue operations, and the safety cron. Supports pause, clear, and auto-scroll.

Cron Changes

• Removed importData (ran every minute — ~1,440 PHP executions/day)
• Removed importBidSpirit (ran hourly — ~24 PHP executions/day)
• Added syncSafety (runs hourly at :10 — 24 PHP executions/day)
• Net effect: ~62 PHP executions/hour → 1 PHP execution/hour
• WP-Cron safety hook (auctionforge_sync_safety) — Always-active hourly event, independent of external cron
• setup.sh v3 — Updated task definitions, new migrate command for interactive v2→v3 transition

Database

• New table: af_sync_queue — Job queue with status, priority, source, attempts, worker PID, timing columns
• New table: af_sync_log — Real-time log entries with context, level, auction_id, job_id
• DB version: 20 → 22

Constants Added

| Constant | Default | Description |

|---|---|---|

| AUCTIONFORGE_SYNC_WORKER_TIMEOUT | 240 | Worker process timeout in seconds |

| AUCTIONFORGE_SYNC_STALE_JOB | 600 | Seconds before a processing job is considered stuck |

| AUCTIONFORGE_SYNC_HEALTH_CHECK | 86400 | Seconds without webhook before triggering full sync |

| AUCTIONFORGE_SYNC_LOG_RETENTION | 7 | Days to keep log entries |

| AUCTIONFORGE_SYNC_QUEUE_RETENTION | 30 | Days to keep completed queue jobs |

| AUCTIONFORGE_CURL_TIMEOUT | 30 | BidSpirit API cURL timeout in seconds |

| AUCTIONFORGE_PHP_BINARY | /www/server/php/83/bin/php | PHP CLI binary path for spawning workers |

AJAX Handlers Added

• auctionforge_sync_log_poll — Incremental log polling for live console
• auctionforge_sync_queue_status — Queue counts + recent jobs for dashboard
• auctionforge_sync_enqueue — Admin-triggered sync actions (full_sync, sync_auction, spawn_worker)

Fixes

• cURL timeout — BidSpiritRequest now enforces a 30-second timeout (was unlimited/0), preventing hung connections from blocking the sync pipeline.

Files Changed

• Modified: auctionforge.php, inc/coreIncludes.php, inc/controllers/AuctionsAPI.php, inc/BidSpiritRequest.php, admin/view/sync-status.php, crontasks/setup.sh
• Created: inc/sync/SyncQueue.php, inc/sync/SyncLogger.php, inc/sync/CatalogSyncWorker.php, inc/sync/ItemUpdateWorker.php, crontasks/syncWorker.php, crontasks/syncSafety.php

---

[2.7.3.0]

Fixes

• Various stability improvements and bug fixes.

[2.7.1.2]

Fixes

• Added missing vatAndCommission() function in loadBid() — the sales tax display on single lot pages was never being rendered because the code to call loadTemplate for vat-and-commission-template was missing from app.js.

[2.7.1.1]

Fixes

• 2 decimal places now only appear in the bid modal (Your max bid, Total Price) via showDecimals flag. Start price, increments list, and other prices show whole numbers as before.

[2.7.1.0]

Fixes

• Fixed Buyer's Premium value not showing on single lot pages.

[2.7.0.9]

Fixes

• Fixed fatal error during plugin install/upgrade: class-stats-database.php require failure.

[2.7.0.0]

New Features: Advanced Lot Analytics

• Conversion Tracking, Peak Viewing Times, Pre-Sale vs Live Comparison, Category Performance, Share Analytics, Search → View Funnel, Click-Through Tracking, CSV Export, Hot Lot Badge.
• New DB table: af_lot_shares. New columns on af_lot_analytics. DB version bumped to 20.

[2.6.0.0]

New Feature: Lot Analytics

• Comprehensive lot view and favorite tracking system with admin dashboard.

[2.5.0.0]

New Features

• Site Statistics System — Full website analytics built into the plugin admin.
• Recently Viewed Items — Profile page tab showing last 20 viewed lots per user.

AuctionForge Changelog

All notable changes to the AuctionForge plugin are documented in this file.

---

[3.7.1.12] — 2026-07-20

Fixed — Open-invoices banner ignored the "Enable My Invoices tab" setting

The site-wide "⚠ This account has open invoices / Pay Now" banner rendered for logged-in users with unpaid BidSpirit bills even on sites where the My Invoices profile tab is disabled — and its "Pay Now" button linked to #bp-bills, a tab that does not exist on those sites, so it led nowhere. checkUnpaidBillsBanner() had no gate on the setting.

BidspiritViews::bp_footer() now emits window.afBillingTabEnabled, computed from the same enable_billing_tab expression that gates the tab markup in profile-templates.php (so banner and tab can never disagree), and checkUnpaidBillsBanner() returns immediately when it is false — no banner, and no bills/getUnpaidBills / unpaid-status AJAX traffic on such sites. Sites with the tab enabled are unchanged. No schema or config-version change.

Fixed — US auction houses resolved to the UK "Catalogue" dialect in Auto mode (regression)

Restores the address-signature detection that was lost in an earlier merge (originally fixed 2026-06-26, silently reverted by a later version sync). US house addresses typically name no country and end in "City, ST 12345", so Dialect::captureRegionFromAuctions() took the "ST 12345" tail as an unknown country name and resolved UK. countryToDialect() now takes the full address and recognises a US state code + 5-digit ZIP tail (const US_STATE_CODES, uppercase-only match), plus a bare trailing ZIP with a $ currency as a secondary signal. Conservative by design: named countries still resolve UK — Canadian ("ON M5V 3L9") and Australian ("WA 6000", 4-digit postcode) tails cannot match the 5-digit requirement.

Fixed — LiteSpeed cache purges during sync stacked "Purge url" admin notices

CachePurge purged per-lot URLs via the public litespeed_purge_url action, which calls Purge::purge_url() with $quite=false and enqueues a dismissible admin notice per URL — a full-auction sync stacked hundreds of "Purge url …" notices on the next wp-admin page and looked like a fault to clients. Purges now call \LiteSpeed\Purge::cls()->purge_url($u, false, true) directly (identical purge, no notice), falling back to the action when the class is unavailable. Manual purges elsewhere keep their confirmations.

Fixed — Sync log wrote one row per skipped auction

LotList::updateData() logged " Skipping auction N (excluded or not matched)" for every excluded auction on every worker run — the dominant source of af_sync_log table growth on multi-house sites (observed in the GBs fleet-wide). It now counts the skips and writes a single "Skipped N/M auctions (excluded or not matched)" summary line per run. The per-auction detail remains available via Debug::logData().

Housekeeping

Removed stray .bak working files (auctionforge.php.bak-*, readme.txt.bak-verbump, app.js.prephonebypass-*.bak, CachePurge/BidspiritViews backups) that had been shipping inside the plugin tree since 3.7.1.4.

[3.7.1.11] — 2026-07-20

Added — "Auction is live" popup on single-lot pages

When BidSpirit reports an auction as live, single-lot pages now show the "Auction is live — Enter live auction" popup (linking to the BidSpirit bidding console), exactly as auction catalogue pages already did. Previously a one-lot auction had no live indication anywhere on the site, because its catalogue URL redirects straight to the lot page and only the catalogue code path surfaced the live state. (Entry backfilled — 3.7.1.11 shipped with this note in readme.txt only. 3.7.1.10 was an internal bump with no separate changes.)

[3.7.1.9] — 2026-07-14

Fixed — Catalog pagination stayed broken for returning visitors (stale session)

Follow-up to 3.7.1.8. That fix stopped *new* sessions from getting a bad per-page baseline, but a returning visitor whose session already held the old baseline (the session cookie lives 24h) kept getting page 2+ reset to page 1 at any non-default items-per-page — only a full "clear site data" (which drops the session cookie) fixed it for them.

The server no longer resets pagination from session state at all. Per-page changes already return to page 1 on the client (the items-per-page dropdown navigates to the page-1 URL), so the session-based reset in BidspiritLots::search_filter() and bidspirit_lot_per_page() was both redundant and the source of the stale-baseline problem — it has been removed. Pagination is now correct for every visitor (new or returning, any session state) on the next page load, with no cache/cookie clearing required. No schema or config-version change.

[3.7.1.8] — 2026-07-14

Fixed — Catalog pagination broke at any non-default "Items per page"

On auction catalog pages, setting Items per page to any value other than the site's WordPress default (posts_per_page) made page 2 and beyond redirect straight back to page 1 — so it appeared to "show the same lots" — while the value matching the default worked. BidspiritLots::bp_session_starter() seeded the per-page change-detection baseline from get_option('posts_per_page'); because auction pages are served from full-page cache / behind a CDN that drops the PHP session cookie, that baseline reset to the default on every request, so any non-default size looked "just changed" on every page load and was force-redirected to page 1 by maybe_redirect_to_first_page().

The baseline is now seeded to null ("unknown previous value"), matching the existing category/search baselines, so a page reset only fires when a genuinely-known prior per-page value differs (isset && !== null && !=). The items-per-page dropdown additionally returns to page 1 client-side, so "change size → page 1" no longer depends on the session. No schema or config-version change.

[3.7.1.7] — 2026-07-13

Added — Per-house toggle to bypass phone verification (UK houses auto-bypass)

BidSpirit's users/phone/sendPhoneVerificationCode returns a generic UNKNOWN_ERROR for UK houses (e.g. rosanreeves, edwards) even for valid +44 mobiles, because SMS/phone-verification is not provisioned on those BidSpirit accounts. As the requirement is enforced only plugin-side, this left UK bidders unable to bid.

A new per-house setting require_phone_verification (in the bidspirit_settings option) makes the client-side bid gate conditional:

• auto (default) — enforce EXCEPT on UK houses (Dialect::isUk()), which are bypassed while their BidSpirit accounts lack SMS provisioning.
• off — never enforce (per-house override, e.g. wp option patch update bidspirit_settings require_phone_verification off).
• on — always enforce.

BidspiritViews::bp_footer() emits window.afRequirePhoneVerification; both bid gates (submitBid, submitBidCatalog) and the profile “Verify phone” CTA honour it. Fails closed (enforces) when the flag is absent. No schema or config-version change.

---

[3.7.1.2] — 2026-06-30

Fixed — Background sync worker spawn timing out ("Worker spawn HTTPS failed: cURL error 28")

On busy or memory-pressured hosts the background sync worker frequently failed to start, logging Worker spawn HTTPS failed: cURL error 28: Operation timed out after 5002 milliseconds with 0 bytes received (observed ~29×/day on one site). SyncQueue::spawnWorker() triggers the worker with a blocking loopback HTTP request to the site's own REST endpoint; the timeout was hard-coded to 5 seconds, so whenever the site's own backend took longer than 5s to respond (DB/FPM contention) the spawn aborted *as a hard error* and raised a sync alert — even though the site was up and serving.

Three changes make the spawn resilient:

• Configurable, longer timeout. The 5s hard-coded timeout is now 15s by default, overridable via the AUCTIONFORGE_WORKER_SPAWN_TIMEOUT constant or the auctionforge_worker_spawn_timeout filter.
• Scheme-matched loopback. Strategy 1 now issues the 127.0.0.1 loopback using the site's own scheme (https when the site is https) instead of always http. Previously an http→https redirect (301) made the loopback look like a failure and forced the slower public-URL fallback; the POST now reaches the worker endpoint directly.
• Non-blocking best-effort fallback. If both blocking attempts can't confirm a start within the timeout, the worker is now triggered with a final non-blocking (fire-and-forget) request, logged at warning instead of error. A merely-slow backend still starts its worker, the hourly SafetySync cron re-spawns if it genuinely didn't, and the condition no longer raises a hard sync alert.

No schema, DB, or config-version change. Behaviour is unchanged on healthy hosts (the loopback still returns 2xx immediately); the new paths engage only when the backend is slow. The underlying slow backend was a server-side issue (MariaDB query-cache lock contention + memory pressure) fixed at the infrastructure level; this release hardens the plugin so a transiently slow backend can no longer turn into a failed sync.

---

[3.7.1.1] — 2026-06-29

Added — Active uptime monitoring via Kuma keyword health marker

The keepalive mu-plugin now emits an invisible <!-- af-health:ok --> marker into every rendered front-end page (hooked on wp_head and wp_footer, emitted once per request, pure echo — no DB/IO, lands inside cached HTML). Uptime Kuma monitors each site by pulling the homepage and asserting the marker is present, which measures real user-facing availability (DNS + TLS + nginx + PHP + WordPress + DB + render) instead of the old push-heartbeat model that only measured whether WP-Cron was firing — and routinely false-flagged perfectly healthy sites as down (the worst offenders flapped 50–60×/day while serving HTTP 200 the entire time).

Because the marker lives in the mu-plugin (which WordPress can't deactivate and AuctionForge re-asserts on every load), it reflects "WordPress is rendering pages" independently of AuctionForge's own activation state, and it survives failed or in-progress plugin updates. The bundled keepalive template is bumped to 1.3.0, so the installer rewrites wp-content/mu-plugins/auctionforge-keepalive.php on update. The legacy push heartbeat is retained in this release for a safe transition to active monitoring.

---

[3.7.0.43] — 2026-06-22

Fixed — Submission "Need help?" contact was hardcoded (one tenant's details on every site)

The vehicle-submission help panel (templates/js-chunks/submissions.php) rendered a single hardcoded email and phone, so every AuctionForge site displayed the same contact regardless of which auction house it was — e.g. one tenant's info@absoluteclearance.co.uk / 01536 674804 showed on unrelated sites.

The panel now resolves the contact dynamically, in priority order:

• apply_filters('auctionforge_help_email', '') / apply_filters('auctionforge_help_phone', '') — explicit per-site override (any source, e.g. a theme/global/Elementor setting);
• otherwise the SEO & AEO Optimizer LocalBusiness details stored in the seo_aeo_options option (local_email / local_phone);
• if neither yields a value the corresponding row is omitted, and the whole "Need help?" block is hidden when no contact is available — so no placeholder or wrong-tenant detail is ever shown.

Internal

• Modified: templates/js-chunks/submissions.php — replaced the two hardcoded <p> contact values with filtered, esc_html-escaped values resolved from seo_aeo_options, each row guarded by an if.
• Modified: auctionforge.php — plugin header → 3.7.0.43.
• No database schema change (AUCTIONFORGE_DB_VERSION unchanged at 25).

---

[3.7.0.42] — 2026-06-22

Fixed — Submission templates emitted extra <h1>s and placeholder content site-wide

The vehicle-submission view (templates/js-chunks/submissions.php) is rendered on wp_footer on every page, so its <script type="text/template"> chunks shipped into the source of all pages. Two of those chunks used <h1> headings ("Submit your vehicle for auction" and "Detail received successfully"), meaning every page's HTML source contained three <h1> elements. While these live inside inert <script> templates (so a DOM-rendering crawler like Googlebot still resolves a single true H1), raw-source SEO tooling and some AI crawlers flag the duplicates, and the templates also shipped vendor placeholder text.

• Both template headings demoted from <h1> to <h2> — a single H1 per page in source.
• Replaced Lorem-ipsum placeholder copy in the intro and progress panels with real submission guidance.
• Replaced the dummy "Need help?" contact details (support@domain.com / +3265464325) with the live business contact (info@absoluteclearance.co.uk / 01536 674804).

No functional/JS changes — template IDs and structure are unchanged.

---

[3.7.0.41] — 2026-06-19

Fixed — Duplicate auction terms (auction shown twice, catalogue split)

A newly published auction could be created twice in WordPress as two identical auction_number terms, so the auction rendered twice on the listing and its catalogue was split across the two copies (e.g. 145 lots stored as 144 + 1). The lot posts themselves stayed unique — this was a duplicate *auction*, not duplicate *lots*.

Root cause: auction terms are only created in Auction::save() via wp_insert_category, which inserts whenever the caller's lookup returned no term. That lookup (findAuctionByIdWithLang() → get_terms() meta_query) can return nothing for a brand-new auction when two syncs run concurrently — for example a full_sync_* bulk run (via BulkSyncWorker / AuctionList) overlapping a catalogue webhook. Both see "no term" and both insert one. The only fallback, findAuctionByNumber(), looks up by the auction *number* slug and never matched the real term slug, so it could not catch the miss. This path is not covered by the existing CatalogSyncWorker per-auction lock, which serialises catalogue syncs to prevent duplicate *lot posts* but does not guard *term* creation.

Auction::save() now, before inserting a term:

• acquires a per-auction MySQL advisory lock (GET_LOCK('<prefix>af_term_<auctionId>', 10)) so concurrent creators serialise — the loser then finds the just-created term and updates it instead of inserting a second one; and
• performs an authoritative, cache-bypassing lookup by auction_id (direct termmeta ⋈ term_taxonomy query) and switches to update-in-place when a term already exists.

Polylang-aware: under full multilingual support it only reuses a term in the requested language, so legitimate per-language terms are still created.

Internal

• Modified: inc/model/Auction.php — save() gains a pre-insert dedup guard; new private helpers findTermIdByAuctionId(), acquireTermLock(), releaseTermLock(). InstanceDB wraps the global $wpdb, so the advisory lock and the wp_insert_category insert share a single DB session (the same property that makes the existing CatalogSyncWorker lock effective).
• No database schema change (AUCTIONFORGE_DB_VERSION unchanged at 25).

---

[3.7.0.40] — 2026-06-14

Fixed — Lot "begin to close" countdown now shows minutes (and seconds in the final minute)

The lot-page countdown (#auctionStartTimer, the *"Auction will begin to close in …"* line) only ever rendered whole days and whole hours, and computed once on page load. With less than an hour to go it therefore read "0 days and 0 hours" — e.g. a lot closing at 20:00 looked like a dead/expired timer from 19:00 onwards, even though ~46 minutes remained. The time maths was correct; the widget simply had no sub-hour granularity and never ticked.

It now updates every second and shows the largest meaningful units, dropping leading zero units:

• 44 minutes • 3 hours and 20 minutes • 1 day, 2 hours and 5 minutes
• In the final minute it counts the seconds down (40 seconds → 1 second) so it never sits on a flat "0".
• Once the close time passes (result < 0) the timer hides itself, as before.

getCountdownText() now wraps the suffix in a .bp-start-countdown span so the script can rewrite the whole phrase; if that wrapper is ever absent (e.g. a stale page-cached markup), getLeftDate() falls back to the original days+hours behaviour rather than erroring — important because app.js also carries the live bidding logic.

Internal

• Modified: inc/controllers/Settings.php — getCountdownText() suffix wrapped in .bp-start-countdown.
• Modified: assets/js/app.js — getLeftDate() rewritten: 1s ticking via setInterval, days/hours/minutes/seconds, zero-unit omission, pluralisation, and a wrapper-missing fallback. This is the file actually served (front-end $jsFile is hardcoded to .js).
• Modified: src/js/app.js — same getLeftDate() change, to keep the gulp source in sync. app.min.js is intentionally not regenerated (unused — the unminified app.js is enqueued).
• Modified: auctionforge.php — plugin header → 3.7.0.40. (3.7.0.39 was present in the header with no changelog entry; this release supersedes it.)

---

[3.7.0.38] — 2026-06-02

Added — Spelling Dialect "Auto" mode (match the auction house region)

The Spelling Dialect setting (Settings → Appearance) gains a third option, "Auto — match the auction house region", which becomes the new default for sites that haven't chosen one:

• During the existing auction sync (getAllAuctions), Dialect::captureRegionFromAuctions() reads the auction house's country from the auction address (trailing segment; currency as a fallback) and stores the resolved dialect in the spelling_dialect_auto option. No API calls happen on page loads — it's a fixed, site-wide value refreshed each sync, so it's fully page-cache-safe.
• Mapping: US → Catalog; every other country → Catalogue (American "Catalog" is US-only; UK/IE/AU/NZ/CA/etc. use "Catalogue").
• The admin field shows what was detected, e.g. *"Detected region: United Kingdom → Catalogue."* United States and United Kingdom remain manual hard-overrides.

Default change: new/unconfigured sites now default to Auto (was UK). Until a site's first sync resolves the region, Auto falls back to UK, so behaviour is unchanged until detection kicks in — then it self-corrects (a US house starts showing "Catalog" automatically).

Internal

• Modified: inc/helpers/Dialect.php — auto mode, FALLBACK_DIALECT, countryToDialect(), captureRegionFromAuctions(); DEFAULT_DIALECT → auto.
• Modified: inc/import/AuctionList.php — capture the house region during the auctions sync.
• Modified: inc/controllers/Settings.php — Auto dropdown option + detected-region note.
• Modified: auctionforge.php — plugin header → 3.7.0.38.

---

[3.7.0.37] — 2026-06-02

Fixed — Per-lot "full price VAT" now drives the VAT statement

The standalone VAT line on lot pages (vat-and-commission → .vat-field) was keyed off the auction-house VAT rule, so it always read *"VAT: X% on item price and commission"* regardless of a lot's full-price-VAT toggle — and toggling a lot off didn't change it. It now branches on the live per-lot flag (itemInfo.item.fullPriceVat), matching the price-breakdown calc in getFullPriceInfo():

• Full-price VAT on → *"VAT: X% on item price and commission"* (VAT applied to hammer + commission)
• off (default) → *"VAT: X% on commission only"*

This only changes the wording to match the amount getFullPriceInfo() already computes per the toggle; the VAT figure itself was already correct. The separate renderVatField() "no VAT on commission" path is unchanged.

Internal

• Modified: templates/js-chunks/vat-and-commission.php — VAT statement branches on the per-lot fullPriceVat instead of houseCommissionVatRule.
• Modified: auctionforge.php — plugin header → 3.7.0.37.

---

[3.7.0.36] — 2026-06-02

A Site Statistics release: day-of-week analysis, an opt-in weekly email report, lot-focused "top pages", and several dashboard refinements.

Added — Day-of-week tabs on the hourly charts

The Hourly Distribution (Site Statistics → Overview) and Peak Viewing Times (Lot Analytics) charts now have a day tab strip — All days · Mon · Tue … Sun — each showing that weekday's total. Selecting a day redraws the 24-hour chart consolidated across every matching date in the range, so you can see *which days and times* visitors are active. The lot-analytics data already carried day_of_week; it was previously flattened to 24 hours and is now surfaced.

Added — Scheduled weekly email report (opt-in, off by default)

A new report under Site Statistics → Settings emails a polished weekly summary: headline KPI cards (Visitors / Pageviews / Sessions with this-week-vs-last-week change), a visitor journey funnel (Visitors → Viewed a lot → Left a bid), busiest hour for each weekday, and the week's most-viewed lots. Driven by a daily cron that sends once on a configurable weekday. Supports one or several recipients (comma/semicolon/space/newline separated, validated and de-duped) and a "Send test now" button that sends to whatever is currently in the Recipient(s) box. Built table-based with inline CSS for Gmail/Outlook/Apple Mail compatibility.

Added — New vs Returning visitors, auction markers, engagement funnel

• New vs Returning visitor KPI cards on the Overview (new = authoritative af_stats_visitors.first_seen within the period, joined so it can never exceed total visitors).
• Auction-date markers drawn on the *Traffic Over Time* chart (dashed lines + a captioned list) so traffic can be read against sale dates.
• Engagement funnel panel: Visitors → Viewed a lot → Viewed 5+ lots → Bidders (bidders from synced af_bid_events).

Changed — "Top pages" is now lot-focused ("Top Lots" / "Most viewed lots")

Both the dashboard Overview panel and the email now list the most-viewed individual lot pages only (/lot-…), excluding home, catalogue listing/pagination and profile pages as low-signal. Email page titles are shown in full (no mid-word truncation) with the site-name suffix stripped; the dedicated Pages tab remains the unfiltered drill-down.

Changed — Lot Analytics "Peak Viewing Times" honours the global date range

Previously hard-coded to the last 30 days; it now respects the dashboard's range picker. The Lot Analytics tab also auto-loads on first click (previously required a manual refresh).

Changed — Chart.js bundled locally

The Statistics and plugin dashboards loaded Chart.js from a CDN at two different versions (@4 and @4.4.1). Chart.js 4.4.1 is now bundled at admin/assets/js/chart.umd.min.js and loaded from the plugin (version-busted), so charts work offline / behind strict CSP and the version is pinned.

Internal

• Added: inc/stats/class-stats-report.php — AF_Stats_Report (weekly cron, recipient parsing, HTML builder, "send test" AJAX). admin/assets/js/chart.umd.min.js — bundled Chart.js 4.4.1.
• Modified: inc/stats/class-stats-ajax.php — hourly-by-DOW query; new_visitors, auction_events, funnel in the dashboard payload; lot-only top pages; global date range passed to peak times; weekly-email settings saved.
• Modified: inc/model/LotAnalytics.php — getPeakViewingTimes() accepts an explicit $from/$to range.
• Modified: inc/stats/class-stats-init.php — require + register AF_Stats_Report.
• Modified: admin/view/stats/dashboard.php — day-of-week tabs, KPI cards, auction-marker plugin, funnel, Top Lots, weekly-email settings UI + test button, local Chart.js.
• Modified: admin/view/dashboard.php — local Chart.js.
• Modified: auctionforge.php — plugin header → 3.7.0.36.

---

[3.7.0.35] — 2026-06-02

Added — Regional spelling dialect ("Catalog" US / "Catalogue" UK)

A new Spelling Dialect dropdown at the top of Settings → Appearance lets each site choose how the word "catalog" is presented on the public front end:

• United States — Catalog — US spelling (the plugin's original authored wording).
• United Kingdom — Catalogue — UK spelling.

When UK is selected, every front-end occurrence is rewritten — *"Catalogue will be available soon"*, *"View catalogue"*, *"Catalogue Coming Soon"*, *"Download catalogue"*, *"Back to the catalogue"*, the lot-page Catalogue tab, and the "catalogue published" app notification.

How it works. Every user-facing catalog string already passes through the auctionforge text domain (__()), so the swap is implemented as a single gettext / gettext_with_context filter rather than by editing template files. Dialect::toUk() rewrites whole words only, preserving case and pluralisation (Catalog→Catalogue, View catalog→View catalogue, CATALOG→CATALOGUE, Catalogs→Catalogues), and is idempotent. The filter is front-end only (is_admin()-guarded, with a wp_doing_ajax() exception so front-end AJAX is still covered) and is scoped to the auctionforge domain, so it never touches WordPress core, the theme, or other plugins. Code identifiers, option keys (catalog_layout, bids_in_catalog), CSS classes (af-catalog-sidebar, catalog-section, bp-back-to-catalog-button) and JS variables are all left intact. On US sites the filter is not registered at all, so there is zero added overhead.

Internal

• Added: inc/helpers/Dialect.php — Dialect helper: get()/isUk() (reads the spelling_dialect option, default UK), word() for non-translated strings, the case/plural-preserving toUk() transform, the gettext filter callbacks, and register() (no-op on US sites).
• Modified: inc/coreIncludes.php — require Dialect.php and call Dialect::register() at plugin load.
• Modified: inc/controllers/Settings.php — use the Dialect helper; add the "Regional Spelling" sub-heading and Spelling Dialect field at the top of the Appearance section, plus the fill_bidspirit_options_spelling_dialect() renderer. The value persists through the existing bidspirit_settings option and sanitize callback.
• Modified: auctionforge.php — plugin header → 3.7.0.35.

Note for existing sites. The default dialect is UK ("Catalogue"). Any site that upgrades without an explicit spelling_dialect value will therefore display "Catalogue" on the front end. Sites that should keep US spelling must set Settings → Appearance → Spelling Dialect to United States — Catalog (stored as spelling_dialect = us). Admin labels are unaffected in either dialect.

---

[3.7.0.34] — 2026-05-30

Fixed — Duplicate lot posts created by concurrent catalog syncs for the same auction

When two catalog-sync jobs for the same auction ran at the same time, every lot was imported twice and the front-end showed each lot as a pair (the second post taking a -2 slug). Observed on a live sale: 157 lots became 313 published lot posts.

Root cause. Two BidSpirit webhooks arriving in the same second (e.g. CATALOG_PUBLISHED + AUCTION_CATALOG_UPDATED) each enqueue a catalog_sync. SyncQueue::enqueue() deduplicates with a non-atomic *SELECT-then-INSERT* (no DB unique constraint), so two simultaneous calls both pass the "already pending?" check and both jobs land in the queue. Job *claiming* is atomic per-job, but nothing serialised two different jobs for the same auction, so two workers ran concurrently. The matcher Lot::findByBSMeta() only sees committed publish/draft posts, so during the overlapping insert windows each worker saw "no existing post" for every lot and inserted a fresh full set. Worse, findByBSMeta does GROUP BY lotId, so the resulting duplicate pair is collapsed to a single row in every later sync — the importer never detects or repairs it, and the count($datum) > 1 "Double" guard in InsertLotsBS::init() is effectively dead code.

Fix. CatalogSyncWorker::process() and processDayEnded() now take a per-auction MySQL advisory lock (GET_LOCK('<prefix>af_sync_<auctionId>', 0)) around the API-fetch + post-insertion work. If another worker already holds the lock for that auction, the duplicate job logs concurrent-lock busy and returns cleanly — marked completed, since the in-flight sync already covers the work — instead of racing. The lock is held on the worker's own DB connection and auto-releases if the process dies, so it can never deadlock the queue. This serialises all catalog and day-ended processing per auction no matter how many duplicate jobs reach the queue.

Internal

• Modified: inc/sync/CatalogSyncWorker.php — new acquireAuctionLock() / releaseAuctionLock() helpers; process() and processDayEnded() acquire the lock up front (skip-on-busy) and release it in a finally.
• Modified: auctionforge.php — plugin header → 3.7.0.34.

Note for existing sites. This prevents *new* duplicates; it does not remove ones already created. To find them, look for published lot posts where two share one BidSpirit lot id (bp_meta_data.id). Keep the most-recently-synced post per lot id and set the rest to post_status = 'trash' — the lot post type has trash disabled, so do it via SQL, and do not use draft (which findByBSMeta still matches). Then recount the auction_number term and clear caches.

---

[3.7.0.33] — 2026-05-30

Fixed — auctionforge_sync_lots cron never scheduled (Lots push to wpdeploy silently stopped)

AF_Lots_Sync uses the custom bp_ten_minutely schedule. The sync crons were registered from AF_Stats_Init::init(), which runs at plugin-load time — *before* auctionforge.php adds bp_ten_minutely to the cron_schedules filter further down the same file. So wp_schedule_event(time(), 'bp_ten_minutely', 'auctionforge_sync_lots') ran against an unknown schedule, failed silently, and left the hook permanently unscheduled. The other four sync hooks use core's hourly and were unaffected — which is why only the Lots push to wpdeploy went stale (observed: 3 days with no push while every other stream ran on time). Fixed by deferring the sync register() calls to the init hook, by which point every custom schedule is registered. The hook self-arms on the next request after upgrade.

Fixed — Safety Sync admin run reported a false "Request failed (HTTP 200)"

auctionforge_ajax_run_cron_task returns its result as JSON, but a stray PHP notice/deprecation emitted by a task (e.g. the Safety Sync BidSpirit delta-check on PHP 8.1) printed into the response body ahead of the JSON, so the browser couldn't parse it and the modal showed a misleading "Request failed (HTTP 200)" even though the task succeeded. The handler now buffers task output, discards it before emitting JSON, and logs any suppressed output via SyncLogger (context admin) so the offending notice can still be found and fixed at the root.

Added — "Clear duplicate cron events" button on Sync Status

The one-shot AF_Cron_Cleanup migration only runs once per site, so per-hostname duplicate events created by an older build *after* the migration had already marked itself done were never swept. New AF_Cron_Cleanup::force_sweep() runs the same sweep on demand, exposed via a Clear Cron Dupes button in the Sync Queue toolbar (AJAX auctionforge_clear_cron_dupes). It removes legacy-args duplicates of the four per-hostname hooks plus the two orphan hooks, keeping one clean event each.

Internal

• Modified: inc/stats/class-stats-init.php — sync register() calls wrapped in add_action('init', …, 20).
• Modified: inc/maintenance/class-cron-cleanup.php — new public force_sweep() reusing the existing sweep helpers.
• Modified: auctionforge.php — auctionforge_ajax_run_cron_task() output-buffered against stray output; new auctionforge_ajax_clear_cron_dupes() handler + registration; plugin header → 3.7.0.33.
• Modified: admin/view/sync-status.php — added the "Clear Cron Dupes" button and handler.

Note: with all scheduling now arg-free (3.7.0.28+), the duplicates do not regenerate once swept; a canonical-hostname redirect (www ↔ apex) at the web-server level remains good hygiene but is no longer required to keep the cron table clean.

---

[3.7.0.32] — 2026-05-30

Fixed — V3 sync worker never spawned on some hosts (silent import stall)

On some sites (confirmed on a LiteSpeed/cPanel install) the V3 queue worker never actually started, so catalog lots were staged into import_history but never converted to WordPress posts — postId IS NULL, syncFinished = 0, syncTimes = 0, and no errors logged. Clearing the queue and reprocessing re-stalled immediately.

Root cause. SyncQueue::spawnWorker() starts the worker by POSTing the REST route /wp-json/auctionforge/v1/sync-worker. It tried an HTTP loopback to http://127.0.0.1/ with the site's Host: header first, and the success test was if (!is_wp_error($result)) — it never inspected the HTTP status code. On hosts where 127.0.0.1 + Host header resolves to the wrong vhost (or the route is blocked), that request returns 404/403, which is not a WP_Error. The old code therefore treated the 404 as a successful spawn, logged Spawned … (HTTP 404), returned true, and never reached the HTTPS fallback. The worker never ran; nothing drained the queue or the staging table. Sites whose 127.0.0.1 loopback resolves correctly returned 200 and were unaffected — which is why this was host-specific.

Fix. spawnWorker() now reads the response code and only treats 2xx as a successful spawn. On any non-2xx (or a WP_Error) from the loopback it logs a warning and falls through to the rest_url() HTTPS path, which is likewise status-checked. A new constant short-circuits the doomed attempt on known-bad hosts:

```php

define('AUCTIONFORGE_WORKER_SKIP_LOOPBACK', true); // wp-config.php — skip 127.0.0.1, go straight to HTTPS

```

Added — Automatic staging recovery on the safety cron

The hourly auctionforge_sync_safety cron previously only spawned a worker when the queue had pending jobs. Lots that were staged into import_history but left unconverted (e.g. after a worker died, or while the spawn bug above was in effect) had no queue job attached, so nothing ever picked them up. The safety cron now also checks SyncQueue::stagingBacklogCount() and, when it is non-zero, kicks the staging processor (non-blocking) to convert the backlog into posts — making the pipeline self-healing without manual intervention.

Added — "Process Staging" button on Sync Status

A new Process Staging button in the Sync Queue toolbar (Lots → Sync Status) runs InsertLotsBS over the staging table on demand — for when lots are staged but not appearing on the site. It fires non-blocking and switches the Live Console into fast-poll so the operator can watch posts being created in batches of 50.

Internal

• Modified: inc/sync/SyncQueue.php — spawnWorker() rewritten with HTTP-status-aware fallback + AUCTIONFORGE_WORKER_SKIP_LOOPBACK support; triggerStagingProcessor() gained a $blocking parameter (non-blocking fire-and-forget mode for cron/admin); new stagingBacklogCount() helper (counts import_history rows with syncFinished = 0).
• Modified: auctionforge.php — auctionforge_sync_safety_action() now drains orphaned staging via the non-blocking processor when a backlog exists; new process_staging case in the auctionforge_sync_enqueue AJAX handler; plugin header bumped to 3.7.0.32.
• Modified: admin/view/sync-status.php — added the "Process Staging" button and its click handler.

---

[3.7.0.28] — 2026-05-21

Fixed — WP-Cron duplicate-event accumulation

A scan across 18 WordPress installs found that 16 sites had duplicate cron events for the AuctionForge sync hooks — some with up to 20 copies of bp_auto_close and 6 copies of auctionforge_sync_safety. Root-cause analysis identified three distinct bugs in the plugin's scheduling code, all fixed in this release.

Bug 1 — $_SERVER['SERVER_NAME'] baked into scheduling args. auctionforge.php:2511-2554 scheduled bidspirit_import, data_import, bidspirit_archive_import, and auctionforge_sync_safety with $attr = array($_SERVER['SERVER_NAME']). WP-Cron's wp_next_scheduled() guard matches on hook plus args signature, so every distinct hostname the site was reached under (canonical, www., IP-direct, internal cron caller hitting 127.0.0.1, an old domain from before a rename) bypassed the guard and scheduled its own copy. The handlers unset($host) — the argument was always vestigial. Removed $attr entirely; events now schedule with empty args. Also dropped the !empty($_SERVER['SERVER_NAME']) outer guards so wp-cli / OS-cron bootstraps can prime the schedule on a fresh install.

Bug 2 — bp_auto_close per-term scheduling with no cleanup. inc/controllers/BidspiritLots.php scheduled one 10-minutely event per running auction term, keyed on ['term_id' => …, 'slug' => …] — correct in principle, but nothing ever unscheduled the event when the auction ended or its term was deleted. Long-running sites accumulated dozens of dangling per-term events polling the BidSpirit API for auctions that no longer existed. Added two cleanup paths:

• bidspirit_auto_close_action() now self-cleans: if the term has been deleted, or if the remote auction state returned by BidSpirit is not RUNNING or ENDING, the handler writes the remote state to auction_state term meta and calls wp_clear_scheduled_hook('bp_auto_close', $args) for that term. The meta write is necessary because check_is_live() runs on every wp_loaded and re-arms bp_auto_close for any term still marked STATE_RUNNING in local meta — without writing the remote state through, the unschedule would be undone on the next request. The meta write is consistent with what SafetySync::run() and inc/import/AuctionList.php:229 already do on non-RUNNING upstream states.
• New pre_delete_term hook on the auction_number taxonomy unschedules the matching event when an auction term is deleted, so a deleted auction can't leave a poll behind.

Bug 3 — Orphan hooks from removed plugin code. bidspirit_meta_migrate_sync and bidspirit_migrate_sync were scheduled by a previous plugin version whose code has since been removed. They sat in wp_options.cron firing into the void on every site (the MIGRATE_SYNC constant in Settings.php:36 is the lone survivor — commented out). No upgrade path ever called wp_clear_scheduled_hook() for them.

Added — One-shot migration: AF_Cron_Cleanup

New class at inc/maintenance/class-cron-cleanup.php, registered from class-stats-init.php, runs once on the first request after upgrading and:

1. Walks _get_cron_array() and unschedules every event for the four hooks rewritten in Bug 1 whose args are non-empty — clearing per-hostname stragglers. The new scheduling code at the top of auctionforge.php has already armed a clean no-args event by the time the migration runs (the scheduling code runs at plugin-load time; the migration runs on init priority 20). Preserving empty-args events means the schedule remains continuously populated — no gap between sweep and the next page load.

2. Unschedules every event (any args) for the two orphan hooks from Bug 3 — those have no callbacks anywhere in the codebase, so empty-args entries are also dead weight.

3. Marks itself done via the auctionforge_cron_cleanup_v1 option and never runs again.

Note that wp_clear_scheduled_hook($hook) alone only matches events with empty args — events scheduled with non-empty args (which is exactly our duplicate population) are left behind. The migration walks the cron array directly and calls wp_unschedule_event($timestamp, $hook, $event['args']) for each match.

Logs a summary line via SyncLogger so the per-site outcome is auditable: e.g. cron-cleanup: Cleared duplicate/orphan cron events: {"bp_auto_close":20,"auctionforge_sync_safety":3,"bidspirit_meta_migrate_sync":2}.

Failure modes after this release

| State | Outcome |

|---|---|

| Fresh install (no duplicates) | Migration runs, finds nothing, sets the option, exits in microseconds. |

| Upgrade on a site with N duplicates | Migration clears them on first load post-upgrade; scheduling code re-arms each hook once with empty args. |

| Site reached under multiple hostnames going forward | No new duplicates — args no longer carry the hostname, so the wp_next_scheduled() guard catches re-registration regardless of which hostname triggers it. |

| Auction term deleted via wp-admin | pre_delete_term clears the matching bp_auto_close event in the same request. |

| Auction ends remotely (state != RUNNING/ENDING) | Next handler run sees the state change and self-cleans the event. |

| Auction term deleted while a bp_auto_close cron is mid-flight | Handler's get_term() returns null, falls through unschedule_auto_close() cleanup branch, returns without an API call. |

Internal

• Created: inc/maintenance/class-cron-cleanup.php (~80 LOC).
• Modified: auctionforge.php lines 2511-2573 — removed SERVER_NAME args and outer guards from bidspirit_import / data_import / bidspirit_archive_import / auctionforge_sync_safety scheduling blocks; handler signatures changed from ($host) to (); add_action(..., 10, 1) simplified to add_action(...).
• Modified: inc/controllers/BidspiritLots.php — added pre_delete_term action registration; rewrote bidspirit_auto_close_action() with term-existence check and state-based self-clean; added unschedule_auto_close() and cleanup_auto_close_on_term_delete() helpers; dropped the SERVER_NAME guard from the per-term scheduling loop.
• Modified: inc/stats/class-stats-init.php — requires and registers AF_Cron_Cleanup alongside AF_Data_Purge.

---

[3.7.0.21] — 2026-05-05

Added — Connection Diagnostics on the Updates admin page

A new Connection Diagnostics card on Lots → Updates that detects and one-click-heals identity mismatches between this site and the deployment server.

The problem it solves. When a WordPress install is cloned (template → customer site, dev → prod, backup → restore), the cloned wp_options carry the original site's auctionforge_update_api_key over to the new home_url(). The new install then makes API calls to wpdeploy *authenticated as the original site*. wpdeploy looks up by api_key, not by URL, so every /sync-user-tracking, /check-updates, /report-health, and most importantly the Kuma push URL, gets recorded against the WRONG wpdeploy.sites row. The cloned site's monitor stays silent; the original's monitor shows traffic that isn't from it.

What the diagnostic does:

• Run Identity Check — calls the new wpdeploy GET /api.php/whoami endpoint and compares the returned caller_site_url against home_url(). Renders a verdict ("matches" / "MISMATCH") plus the full server-side view (site_id, site_name, last_check, plugin version on file, remote IP). The "Re-register & Reset Kuma" button only appears if there's a mismatch.
• Re-register & Reset Kuma — calls /request-access (which is idempotent on site_url — wpdeploy returns the canonical api_key for *this* home_url(), regardless of whatever wrong key we were holding), wipes auctionforge_kuma_push_url and any leftover heartbeat cron events, then immediately fires /check-updates so the api_request interceptor catches the freshly-correct kuma_push_url for *this* site. The keepalive mu-plugin's heartbeat picks it up on the next 60s tick.

Internal

• AuctionForge_Auto_Updater::whoami() (new) — thin wrapper over api_request('whoami', [], 'GET'). Returns the parsed wpdeploy /whoami payload.
• AuctionForge_Auto_Updater::reset_connection() (new) — three-step heal: re-register → wipe Kuma cached state → re-fetch via /check-updates. Returns shape suitable for wp_send_json_success.
• Two new AJAX actions: auctionforge_diagnose_connection, auctionforge_fix_connection. Both behind manage_options capability + nonce check.
• auctionforge_normalize_host() helper for case/scheme/www-tolerant URL comparison.

Server-side companion

Requires the wpdeploy /api.php/whoami endpoint added in the same release window. The endpoint is gated behind whatever api_key the caller already presented (a master key returns type=master with no site row; a per-site key returns the site row that key resolves to). Reveals nothing the caller doesn't already implicitly authenticate against.

---

[3.7.0.20] — 2026-05-04

Changed

• Kuma heartbeat path is now wpdeploy-independent. The actual heartbeat firing — wp-cron schedule, page-load piggy-back, outbound HTTP — moved out of AF and into the AuctionForge Keepalive mu-plugin (wp-content/mu-plugins/auctionforge-keepalive.php, bumped to v1.2.1). Once a site has been provisioned once and auctionforge_kuma_push_url is cached locally, the heartbeat keeps reporting forever even if AF is deactivated, mid-upgrade, deleted from disk, or wpdeploy is offline. The mu-plugin can't be deactivated by WordPress, can't be broken by an AF release, and depends on AF for nothing.
• AF only writes the kuma_push_url option now. It no longer schedules the cron, no longer fires the heartbeat, and no longer holds any heartbeat-related state. The api_request() interceptor still catches kuma_push_url from /check-updates and /report-health responses and persists it; the mu-plugin reads it from there.
• Migration block. init_hooks() clears any leftover auctionforge_kuma_heartbeat wp-cron event from AF ≤ 3.7.0.19 on first plugin load after upgrade. The mu-plugin runs the same clear on its own plugins_loaded hook — belt and braces. The new event the mu-plugin schedules is kuma_heartbeat_tick on a new kuma_60s schedule.
• AuctionForge_Auto_Updater::kuma_heartbeat() no-opped. Kept as a safety landing pad so any stale auctionforge_kuma_heartbeat wp-cron event that fires one last time before migration kicks in doesn't trip a "no callback registered" warning. Real heartbeat work happens in the mu-plugin.

Added — operator override

• AUCTIONFORGE_KUMA_PUSH_URL constant. Define it in wp-config.php to point a site directly at Kuma without ever involving wpdeploy:

```php

define('AUCTIONFORGE_KUMA_PUSH_URL', 'https://kuma.example.com/api/push/<token>?status=up&msg=&ping=');

```

The constant takes precedence over the auctionforge_kuma_push_url option. With it set, the site can be operated fully outside wpdeploy — useful for one-off installs, customer-managed sites, or disaster-recovery scenarios where wpdeploy is unreachable for an extended period.

Internal — Keepalive mu-plugin v1.2.1

The bundled keepalive template at inc/keepalive/auctionforge-keepalive.template.php now also handles Kuma heartbeats. Three layered triggers ensure cadence stays tight regardless of site traffic:

1. Dedicated wp-cron event kuma_heartbeat_tick on a new 60-second kuma_60s schedule

2. Page-load piggy-back on init: any request older than 50s since the last beat fires another, transient-guarded so concurrent hits coalesce. Free on busy sites; rescues low-traffic sites the moment any visitor arrives.

3. Self-heal inside the cron callback: if the event somehow gets cleared, re-arm it before sending the beat.

HTTP is timeout=2, blocking=false — fire-and-forget, never slows page loads. External IP introspection (ipify → ifconfig.me → icanhazip fallback chain, 24h transient cache) is duplicated in the mu-plugin so it doesn't depend on AF being loaded for the IP lookup.

The keepalive installer (class-keepalive-installer.php) detects the KEEPALIVE_VERSION: 1.2.1 header bump and idempotently overwrites every site's mu-plugin on the next AF load. No manual reactivation needed.

Failure modes after this release

| State | Heartbeat? |

|---|---|

| AF active and healthy | ✅ via mu-plugin |

| AF deactivated by an operator | ✅ mu-plugin runs anyway |

| AF deleted from disk | ✅ as long as auctionforge_kuma_push_url option exists OR constant is set |

| AF mid-upgrade / partial install | ✅ mu-plugin doesn't depend on AF code paths |

| wpdeploy down (existing site) | ✅ option is cached locally, no wpdeploy round-trip |

| wpdeploy down (brand-new site, never provisioned) | ❌ first-time URL provisioning still needs wpdeploy. One-shot, accepted trade-off. |

| Site has zero traffic AND wp-cron isn't firing | ❌ truly nothing to trigger a beat. Mitigation is OS-level cron / DISABLE_WP_CRON, out of scope here. |

---

[3.7.0.19] — 2026-05-04

Changed

• Reverted Kuma heartbeat cadence: 3 min → 1 min. auctionforge_kuma_heartbeat is back on the bp_minutely schedule. With Kuma's 310s silence window, 60s cadence tolerates 4 missed wp-cron ticks before flipping a monitor red — the original "give-it-leeway" semantics. The 3-min cadence introduced in 3.7.0.18 was strictly less chatty but tighter (a single missed tick would trip Kuma), and the trade-off wasn't worth it operationally.
• Migration block updated. init_hooks() now detects any existing event scheduled on a non-bp_minutely cadence (e.g. the bp_3_minutely set by 3.7.0.18) and re-schedules onto bp_minutely. Sites that took 3.7.0.18 roll back automatically on first plugin load after upgrade.
• First-fire jitter narrowed back to 0–60s to match the new cadence.

Notes

• The bp_3_minutely cron schedule registration in auctionforge.php is kept (harmless; available for future use). Only the heartbeat scheduling sites have been reverted.
• Apparent latency in Kuma flipping a monitor red after a real outage is governed by Kuma's per-monitor interval (silence-detection window, currently 310s on the wpdeploy/Kuma side), not by this cron's cadence. To detect outages faster, lower the Kuma interval; to add more tolerance to wp-cron drift, raise it.

---

[3.7.0.18] — 2026-05-04

Changed

• Kuma heartbeat cron cadence: 1 min → 3 min. auctionforge_kuma_heartbeat now runs on a new bp_3_minutely schedule (180s) instead of bp_minutely (60s). This pairs with Kuma's 310s silence-detection window — a single late wp-cron tick (3 min + drift) still lands inside the threshold, but normal traffic to Kuma drops by ~3×.
• Random first-fire offset widened from 60s → 180s. With ~50 sites on a single Kuma instance, spreading first-fires across the full 3-min window prevents synchronised bursts every 3 minutes.
• Auto-migration of existing scheduled events. On plugin upgrade init_hooks() calls wp_get_scheduled_event('auctionforge_kuma_heartbeat') and, if the existing event is on bp_minutely, clears it and reschedules onto bp_3_minutely. Idempotent — a no-op once migrated.

Internal

• New cron schedule registered: bp_3_minutely (BP_MINUTELY * 3 = 180s). Defined alongside the existing bp_minutely / bp_ten_minutely / bp_hourly / bp_24_hourly schedules in auctionforge.php.

---

[3.7.0.17] — 2026-05-04

Fix: "Install Now" always returned up_to_date

The /sync/version REST endpoint (called by wpdeploy's Install Now button) was always responding success: false, reason: up_to_date regardless of the actual installed version, defeating the button's whole purpose.

Root cause

rest_force_plugin_update() did:

```

delete_site_transient('update_plugins');

$this->check_pending_updates();

$updates = get_site_transient('update_plugins');

```

check_pending_updates() calls the /pending-updates endpoint on wpdeploy (which returns the deploy queue), but it does not touch the WP update_plugins transient. The transient just got deleted on the line above and never gets re-populated, so the isset($updates->response[…]) check always failed → always returned up_to_date.

Fix

• Use wp_update_plugins() instead — that's what fires the pre_set_site_transient_update_plugins filter chain that AF's own check_for_updates() callback hooks into to seed the transient. Same pattern is already used correctly in install_update() at line 280.
• Belt-and-braces: when the request body carries an explicit target version and that version is strictly greater than the on-disk plugin version (per version_compare), bypass the transient check and force the install. This handles edge cases where the transient seeding fails (network blip during the wp-cron cycle, hosting-side cache, etc.) so the explicit Install Now command still does what it says.

---

[3.7.0.16] — 2026-05-04

Server external IP reported to wpdeploy + included in Kuma heartbeats

Each AF install now reports its server's outbound external IP. Two channels:

1. Kuma heartbeat msg — the per-minute push payload now reads <wp_version>|<plugin_version>|<external_ip> (e.g. 6.9.4|3.7.0.16|152.53.187.82) so you can spot at a glance which physical box each site lives on. When a host goes dark, multiple monitors flip red simultaneously with the same IP — instant root-cause hint.

2. /report-health payload — a new external_ip field that wpdeploy stores on sites.external_ip. Visible in the Sites admin view as a tappable IP chip; clicking it filters the table to all sites sharing that IP.

How the IP is detected

AuctionForge_Auto_Updater::get_external_ip() calls one of three public echo services in turn — api.ipify.org, ifconfig.me/ip, icanhazip.com — with a 4-second timeout each. The first one that returns a valid IP wins. Result is cached in a transient for 24 hours so we don't hit external services on every report cycle.

Wpdeploy fallback for older plugins

/report-health now also captures REMOTE_ADDR (or HTTP_CF_CONNECTING_IP when behind Cloudflare) when the payload doesn't include external_ip. So sites still on 3.7.0.15 or older start populating their IP today via the same route, no plugin update needed for that data path.

---

[3.7.0.15] — 2026-05-04

Kuma monitors land in an "Unallocated" group by default

New AuctionForge installs are auto-enrolled into Kuma under a new top-level group called Unallocated so the operator can review them and drag-drop into the right home (Bidspirit Auction Sites, Stephen's Auctions, Misc Websites, etc.) before classification. Without this every new monitor would appear at the dashboard top level alongside whatever group hierarchy already exists.

What changed (wpdeploy-side, no plugin behaviour change)

• KumaProvisioner now ensures an "Unallocated" group exists in Kuma (find-or-create via the same Socket.IO add path used for monitors, with type='group') before provisioning each new push monitor, and passes parent=<group_id> in the add payload so the new monitor lands inside it.
• The Node helper accepts arbitrary type and parent fields on the input payload (previously hardcoded to type='push').
• The group itself gets the same user_id=1 reassignment so it shows up on the human admin's dashboard.

Existing Clumber monitor (id=71) was migrated into the new group as part of this release.

This is a wpdeploy infrastructure change — the AF plugin code is unchanged from 3.7.0.14. Version bumped only to mark a clean snapshot point.

---

[3.7.0.14] — 2026-05-04

Uptime Kuma push heartbeat with automatic enrolment

Each AF install now appears as its own monitor on the central Uptime Kuma at https://kuma.smoothbyteit.dev, beating every minute and flipping red within ~90 seconds when a site goes dark. Auto-enrolled — no manual Kuma UI clicks per site.

How it works

1. First contact: when the plugin calls /request-access or /report-health, wpdeploy's new KumaProvisioner opens a Socket.IO connection to Kuma as a dedicated auctionforge-bot user, calls the official add event, and gets back a fresh push token. The resulting URL is shipped to the plugin in the JSON response as kuma_push_url.

2. Plugin-side: a generic interceptor on api_request() persists kuma_push_url to the option auctionforge_kuma_push_url whenever it appears in any wpdeploy response, and immediately schedules the new auctionforge_kuma_heartbeat cron on the existing bp_minutely interval.

3. Heartbeat: the cron handler sends a single wp_remote_get to the push URL each minute with msg=<wp_version>|<plugin_version> so Kuma's dashboard shows the running stack at a glance. Kuma's silence-detection window is 90s, so a single missed wp-cron tick won't false-DOWN.

4. Idempotency: the Kuma monitor's description field stores wpdeploy_site_id:<id>. Re-registering the same site short-circuits at the wpdeploy layer (existing kuma_monitor_id on sites), or — if that's missing — Kuma's existing row is reattached via the description anchor. Re-installing the plugin never duplicates monitors.

Why Socket.IO and not direct DB insert

Kuma's monitor scheduler does not poll its own DB for new rows — startMonitors() only loads monitors at boot, and new ones are armed via the authenticated Socket.IO add event handler (which calls startMonitor() and arms the per-monitor safeBeat setTimeout). A direct INSERT would create a "phantom" monitor that accepts pushes but never flips DOWN on silence, defeating the whole feature.

Notifications + monitor ownership

Provisioner reads existing Kuma notification rows whose channel is Telegram (or marked default-for-new-monitors) and attaches them to every new monitor via the add event's notificationIDList. After the Socket.IO add succeeds, the provisioner direct-writes user_id=1 to the new monitor row in Kuma's SQLite — Kuma's add handler hardcodes user_id=socket.userID (the bot at user 2), which causes the frontend's real-time monitor-list updates to skip the admin's session. The follow-up UPDATE stamps ownership to the human admin so monitors render with their full name on the admin dashboard immediately.

Failure modes

Every call boundary degrades safely. If Kuma is unreachable when a site registers, registration completes without kuma_push_url; the next twicedaily /report-health retries. Heartbeat HTTP failures are silent (which is the desired outcome — Kuma's silence-detection is the signal). Kuma reset / monitor row deleted: provisioner's pre-flight check NULLs the wpdeploy anchors and falls through to fresh provisioning on the next call.

Operator setup

Already done: the auctionforge-bot Kuma user has been created and credentials populated in wpdeploy's config.php. To rotate or migrate Kuma later, edit KUMA_URL / KUMA_BOT_USER / KUMA_BOT_PASS in config.php — no plugin redeploy needed.

---

[3.7.0.13] — 2026-05-04

Wide shortcode: hide Register button for logged-in users

• When a user is logged in to BidSpirit (body.bp-login), the Register button is now automatically hidden on wide-format auction cards (bp_upcoming_wide and bp_auction_list layout="wide").
• The View Catalog / Catalog Coming Soon button expands to full width when the Register button is hidden.
• Uses a lightweight MutationObserver to react to BidSpirit's async session init.
• Applied to both UpcomingAuctionWide.php and AuctionList.php shortcode CSS blocks.

---

[3.7.0.12] — 2026-05-03

Stop-word denylist for BidSpirit category-tag concatenations

BidSpirit's wp_bp_meta_data.tags field arrives as PascalCase category names lowercased without separators (uscollectibles, firearmsaccessoriesammunition, usdecorativearts, printsandmultiples). They look like keywords but they're really categories, and on sites where the tags field is populated they completely swamp the top-5 chips for power users (e.g. one buyer's profile was led by uscollectibles 453 views despite that being a label rather than a real interest signal).

29 known patterns added to stop-words.php so the tokenizer drops them at extraction time. New ones surfacing from sites we haven't seen yet should be added here as they appear; the wpdeploy ?tab=keywords corpus page makes them easy to spot (sort by most users with low lots count and look for non-word concatenations).

---

[3.7.0.11] — 2026-05-03

Keyword extractor — capture model years + hyphenated calibers, drop more auction noise

The People view's top-5 keyword chips were filling up with generic descriptors (household, model, original, assortment) instead of the brand/maker terms (mauser, whitworth, colt) that actually distinguish one buyer from another. Live-data review on the new ?tab=keywords Keyword Corpus page on wpdeploy confirmed the cause: real signal was being lost at the tokenizer stage.

Tokenizer changes (inc/stats/class-keyword-extractor.php)

Three pre-passes now run before the standard split-on-non-alpha:

1. Hyphenated / x-separated calibers — .45-70, .30-06, 7.62x54r, 8x57. Without this they're split into pure-digit fragments and dropped, losing the actual model identifier.

2. Caliber-with-suffix — 9mm, .22lr, .45acp, .380acp. Previously only survived by accident because of the trailing letters; now extracted explicitly.

3. 4-digit model years 1700–2099 — 1873, 1903, 1911, 1971. Pure-digit tokens were unconditionally dropped; now retained when year-shaped.

Standard pass relaxed to allow 4-digit pure-digit tokens between 1700 and 2099.

Stop-word additions (inc/stats/stop-words.php)

Conservative — only universally empty auction descriptors:

original, marked, accessories, decorative, household, goods, made, condition, assortment

Deliberately NOT added: antique, vintage, rare, fine — those carry buyer-segmentation signal (antiquarian buyers vs. modern-collectibles buyers). Borderline cases (metal, wooden, american, model) are left to the wpdeploy-side IDF re-rank.

Companion change on wpdeploy (no plugin update needed)

refresh_people_rollup.php now multiplies each keyword's score by an IDF factor pulled from keyword_idf (refreshed hourly by refresh_lot_keyword_index.php). Generic keywords that appear in many lots get demoted automatically; brand/maker words that only appear on a handful get lifted into the top-5 chips.

After deploying this version, reset the auctionforge_lots_sync_watermark option on each site and clear the wp_af_stats_lot_keywords table to force re-extraction of every lot through the new tokenizer.

---

[3.7.0.10] — 2026-05-03

Lots sync — ship resolved CDN image URL, not bare BidSpirit filename

class-lots-sync.php was sending imagesListStr's first comma-token verbatim as image_url — that's the raw BidSpirit storage value (e.g. 001.jpg). Wpdeploy received a bare filename, the browser resolved it against the wpdeploy host, and every lot thumbnail 404'd.

The lots-sync now instantiates LotImage and pulls the resolved CDN URL (LABEL_MEDIUM thumbnail), with fallback to LABEL_ORIGINAL and a final defensive check that drops anything that doesn't start with http(s)://. Resolution is wrapped in try/catch — a missing class or BidSpirit settings issue leaves image_url empty rather than blowing up the sync batch.

After deploying this version on a site, reset its auctionforge_lots_sync_watermark option (delete the row) to re-push existing lots through the new resolver. The wpdeploy view skips <img> rendering when image_url isn't a real URL, so dirty rows degrade silently while the watermark catches up.

---

[3.7.0.9] — 2026-05-03

Keepalive sweep — auto-clears WP upgrader debris that produces silent "Could not create directory" failures

WordPress 6.x's atomic-rollback flow leaves wp-content/upgrade-temp-backup/ lying around when its post-install cleanup misfires (the user-facing symptom is "Update failed: Could not create directory" after an update that has actually already succeeded). Stale wp-content/upgrade/<plugin>-tmp/ and .maintenance lockfiles from crashed upgrades cause the *next* upgrade attempt to fail the same way. None of WP's own scheduled cleanup catches these reliably.

The keepalive mu-plugin (KEEPALIVE_VERSION 1.1.0) now sweeps all three classes of debris on every page load, transient-guarded to once per hour. Safety thresholds prevent it touching anything actually in flight: .maintenance files less than 5 min old, wp-content/upgrade/* entries less than 60 min old, and upgrade-temp-backup/ less than 30 min old are left alone. Wrapped in try/catch with no throws, so the sweep can never block a request.

The keepalive installer detects the version bump and rewrites wp-content/mu-plugins/auctionforge-keepalive.php automatically on the next AF load, no manual reactivation needed.

---

[3.7.0.8] — 2026-05-03

Shop auction UI refinements & share button settings

Shop (Buy-It-Now) catalog improvements

• Shop sorting dropdown: Added a dedicated sorting dropdown for shop catalogs with options: Recently Added, Price: High, and Price: Low. Sorts by buyoutPrice metadata. Regular auction catalogs retain the original sorting options.
• Removed "Buyout price:" label: On shop lot pages, the redundant "Buyout price:" text before the price is now hidden. Only the price and "Buy Now" button are displayed. Regular auction buyout lots still show the label.
• Removed increments table & terms links: On shop lot pages, the "Increments table" and "Terms and conditions" links are hidden since they don't apply to buy-it-now items. The "Make an inquiry" link remains.

Buyout confirmation modal overhaul

• Sales tax logic: The buyout confirmation modal now follows the same sales tax detection as the regular bid modal. When the auction house has a US state configured, displays "Sales Tax" instead of "VAT", with the correct percentage for same-state buyers and 0% for out-of-state.
• Hide 0% buyer's premium: The Buyer's Premium line is hidden when the commission is 0%.
• Shop-specific text: For shop buyouts, all disclaimer text is replaced with: *"You will receive an email with your invoice, including shipping, and a secure payment link."*
• Shop-specific buttons: "I don't Agree" → "Cancel", "I Agree" → "Buy". The "Terms of sale" button is removed for shop buyouts. Non-shop buyouts retain the original layout.

Purchase confirmed screen

• Title changed from "Confirm purchase:" to "Purchase Confirmed".
• Thank you message updated to: *"Thank you for your order. We will confirm your order within 1-2 business days and email you an invoice, including shipping, and a secure payment link."*

Share button settings (Appearance tab)

• Added a Share Buttons section to the BidSpirit Appearance settings tab with individual checkboxes for each sharing platform: Copy Link, WhatsApp, Facebook, Telegram, X (Twitter), VK, Pinterest, and Email.
• All platforms default to enabled (shown). Unchecking a platform hides that share button on all lot pages (both shop and regular auctions).

---

[3.7.0.7] — 2026-05-02

Identity stitch on bidder login — keyword interest tallying now actually fires

Why

The keyword extractor was filling wp_af_stats_lot_keywords correctly (197 lots, 734 distinct keywords on Clumber), but wp_af_user_interests and wp_af_user_recent_activity were both empty — zero rows of any dimension. Same on every site running the new sync streams.

Root cause: identity stitching (visitor_hash → email) only fired in the tracker AJAX when is_user_logged_in() returned true. On these auction sites the actual bidders authenticate via BidSpirit, never as wp_users — so the WP login check was always false, the stitch table stayed empty, and maybe_record_lot_view($url, $email, …) got called with an empty email and bailed out before tallying. Lot views by real bidders never landed in the user-side interest profile.

What changed (no auth-path intervention)

The fix piggybacks on the *existing* fire-and-forget tracking AJAX that already runs after a successful BidSpirit login (afLogIP("login", bidspiritUser)). It does not touch the BidSpirit auth path itself.

• inc/ip-logger.php auctionforge_ajax_log_ip() — after the existing auctionforge_user_tracking insert, if the request carries a visitor_hash and the email is valid, calls AF_Stats_Visitor_Email_Map::record($vh, $email, $ip). Wrapped in try/catch so any failure here can never break the existing tracking response.
• assets/js/app.js + src/js/app.js afLogIP() — reads localStorage['af_vid'] (defensively, ITP/private-mode safe) and includes it as visitor_hash in the POST body.
• inc/stats/class-stats-init.php maybe_record_lot_view() — when $email is empty (the common case for BidSpirit-only bidders) but a visitor_hash is present, falls back to AF_Stats_Visitor_Email_Map::lookup($visitor_hash). If a stitch exists, the view tallies; if not, it stays anonymous.

Net effect: a bidder logs in (BidSpirit), the post-login tracker AJAX fires as it always has, and now also writes one extra row into af_stats_visitor_emails. From that point onward, every page they view on the same browser/device tallies into af_user_interests keyed on their email. The BidSpirit transaction itself is untouched.

---

[3.7.0.6] — 2026-05-02

Critical fix — X-API-Key header collision with sibling SmoothByte plugins

What was wrong

On any site running both AuctionForge and another SmoothByte-stack plugin that also points its updater at wpdeploy.smoothbyteit.dev (e.g. seo-aeo-optimizer), the second plugin's http_request_args filter overwrote AuctionForge's X-API-Key header on every outbound API call. Wpdeploy then 401'd because the key it received belonged to a different plugin instance — usually a seo_aeo_update_api_key that wpdeploy had no record of.

The symptom was a quiet, total auth failure: report-health, check-updates, every sync-* route, all 401. The watchdog flagged streams as "gone" and updates stopped flowing. Affected sites: any install where the AuctionForge key and the sibling plugin's key happen to differ. Sites where both plugins shared a key were silently safe (the overwrite was a no-op).

Fix

AuctionForge_Auto_Updater::add_download_auth() now refuses to clobber an existing X-API-Key and, for download URLs, only stamps when the URL slug matches our own. That keeps targeted calls from api_request() intact regardless of filter ordering, and prevents either plugin from writing its key onto the other's download URL.

The same fix has been applied to seo-aeo-optimizer so both ends of the collision are defensive.

---

[3.7.0.5] — 2026-05-02

Sync Status admin panel — diagnostic + manual triggers in wp-admin

Why

Diagnosing sync issues used to require shell access on the site or piecing together state from wpdeploy's app.log. This release surfaces the same diagnostics inside wp-admin so a site admin (or anyone with manage_options) can see exactly what's happening and trigger fixes in one click.

Lives inside the existing Sync Status menu (Lots → Sync Status) — appended below the existing content as a "Sync Diagnostics & Manual Controls" section, no duplicate menu entry.

What's on the panel

Connection summary — plugin version, af_stats_db_version, wpdeploy server URL, last 8 chars of API key, keepalive install state + auto-reactivation count.

Sync streams table — for each of the 10 cron hooks (user-tracking, user-profile, user-interests, user-activity, lots, bids+wins, vulnerabilities, report-health, check-updates, fraud-enforcement):

• Configured schedule
• Last fired timestamp + status colour-coded (green=success, blue=idle/empty, red=error)
• Record count from last run
• Next scheduled run
• Current watermark (where applicable)
• "Fire now" button — clears doing_cron, calls do_action($hook) synchronously, shows the result

One-shot utilities

• Test wpdeploy connection — calls /api.php/info with the site's API key
• Clear stuck cron lock — deletes the doing_cron transient (the classic fix when scheduled events stop firing)
• Reinstall keepalive — overwrites mu-plugins/auctionforge-keepalive.php from the bundled template
• Backfill bids from legacy tracking — replays last_event_type='bid' rows from wp_auctionforge_user_tracking into wp_af_bid_events so the bids-wins stream picks them up. Useful for sites that have years of bid history in the legacy table but nothing in the new queue
• Run all due events now — clears doing_cron and fires every auctionforge_* cron event whose timestamp is past due, in one go

Live response output panel shows the JSON returned from each action so you can see what just happened without leaving the page.

Files Changed

• Created: inc/admin/class-sync-status-page.php
• Modified: inc/stats/class-stats-init.php (load + init the panel)
• Modified: admin/view/sync-status.php (append AF_Sync_Status_Page::render_panel() call at the bottom)
• Modified: auctionforge.php (Version 3.7.0.4 → 3.7.0.5)

Verification

Navigate to Lots → Sync Status in wp-admin on any 3.7.0.5 site. Scroll past the existing content to the new "Sync Diagnostics & Manual Controls" section. Click "Test wpdeploy connection" — you should see {"success": true, "auth_type": "site"}. Click "Fire now" on any stream — the row's last-fired timestamp should refresh after 1–2 seconds.

---

[3.7.0.4] — 2026-05-02

Self-healing: failed plugin updates can no longer take a site offline

Why

WordPress's plugin updater isn't transactional — when an update fails partway (corrupt unzip, fatal during the new version's plugins_loaded, disk pressure, theme conflict, etc.) WP often deactivates the plugin and leaves the site without it. Once AuctionForge is dropped from active_plugins, no AF code runs again — including its sync handlers — until someone notices and reactivates manually. On the AuctionForge site fleet, this had quietly happened to ~5 sites we found; almost certainly more on production sites we don't have filesystem access to.

This release ships an autonomous watchdog that lives outside the AuctionForge plugin entirely so it survives even when AF gets knocked out.

What changed

1. Self-installing keepalive (mu-plugin)

• inc/keepalive/auctionforge-keepalive.template.php — a 50-line WordPress must-use plugin. Lives in wp-content/mu-plugins/, which WordPress can't deactivate. On every plugins_loaded (priority 1, before any regular plugin), it checks: is auctionforge/auctionforge.php on disk but missing from active_plugins? If yes AND the file has a valid Plugin Name: header (smoke check — don't reactivate a corrupt zip), it re-adds AF and includes the file in the same request.
• inc/keepalive/class-keepalive-installer.php — runs on every successful AF load. Copies the template into wp-content/mu-plugins/auctionforge-keepalive.php if missing or version-bumped. Idempotent: compares KEEPALIVE_VERSION headers, only writes on change. Refuses to overwrite a foreign mu-plugin (defensive against name collisions). Failure is non-fatal — install errors are recorded in wp_options for wpdeploy visibility but never throw.

Net effect. Any site that successfully loads AF 3.7.0.4 or later will have the keepalive permanently installed in mu-plugins. From that point forward, even if a future update hard-fails, the keepalive recovers AF on the next pageview without any manual intervention or filesystem access. Crucially: this works on sites we don't own — the keepalive ships inside the AF zip, gets installed during the first successful update, and lives in mu-plugins thereafter.

2. Forensic markers

The keepalive writes three options on each recovery:

• auctionforge_auto_reactivated_at — most recent recovery timestamp
• auctionforge_auto_reactivated_count — total recoveries
• auctionforge_auto_reactivated_failed_at — set when the keepalive saw AF on disk but with no Plugin Name header (genuinely corrupt — needs operator attention)

These get picked up by the AF sync streams and surfaced on the wpdeploy dashboard so you can see which sites have been quietly recovering themselves and whether a particular release is failing more than it should.

3. Companion: post-update-silence alerts on wpdeploy (server side)

Wpdeploy's report-health route now compares incoming plugin_version against the row and writes last_version_changed_at + previous_plugin_version on change. The SyncWatchdog cron then alerts if a site has reported a version change but not sent any heartbeat for 2+ hours since — likely a failed install. Emits sync_incidents rows with kind=post_update_failure so the existing Telegram fan-out picks them up. Each version-change event alerts at most once.

Files Changed

• Created: inc/keepalive/auctionforge-keepalive.template.php, inc/keepalive/class-keepalive-installer.php
• Modified: inc/stats/class-stats-init.php (call AF_Keepalive_Installer::maybe_install() on every plugin load)
• Modified: auctionforge.php (Version 3.7.0.3 → 3.7.0.4)

Companion server-side changes (already deployed on wpdeploy.smoothbyteit.dev — not in this zip):

• sites table: last_version_changed_at TIMESTAMP NULL, previous_plugin_version VARCHAR(20) NULL
• api.php /report-health route detects version changes
• SyncWatchdog::maybe_alert_post_update_failure() emits the new alert kind

Verification

1. Drop a 3.7.0.4 install on any site. Confirm wp-content/mu-plugins/auctionforge-keepalive.php exists post-load.

2. Manually deactivate AF from the database (DELETE FROM wp_options ...active_plugins...). Hit the homepage. AF reappears in active_plugins; auctionforge_auto_reactivated_count increments.

3. Delete mu-plugins/auctionforge-keepalive.php. Trigger AF load (any pageview). The file reappears.

4. Bump KEEPALIVE_VERSION in the source template, ship a new release, observe the installed mu-plugin update on next AF load.

Operator notes

• Sites currently in the broken state (AF deactivated, no keepalive yet) are NOT auto-rescued by this release — they need a one-time manual reactivation in wp-admin OR a fresh AF install via wp-admin's Upload Plugin. After that, the keepalive is in place and future failures self-heal.
• The post-update-failure alert won't fire for upgrades that happened before this release (no last_version_changed_at was recorded). It activates from the first version change wpdeploy sees from each site after this update lands.

---

[3.7.0.3] — 2026-05-02

Fix: profile re-sync on login / profile-edit / register (no more empty names)

Why

The hourly profile sync uses a user_registered watermark — once a user has been pushed once, the watermark advances past them and they're never re-pulled. That meant:

1. Existing users whose first_name/last_name became populated AFTER their first sync stayed empty on wpdeploy forever.

2. BidSpirit-driven sites that don't write WP's standard first_name/last_name fields shipped empty rows even though the canonical name was visible in display_name.

The People view was showing — for the name on rows that absolutely had a name available — just not where the sync handler was looking.

Fixes (inc/sync/class-profile-sync.php + inc/stats/class-stats-init.php)

• AF_Profile_Sync::push_for_user_id($user_id, $blocking=false) — new public method that builds a single user's profile row, normalises it, and POSTs to wpdeploy bypassing the watermark. Non-blocking by default (wp_remote_post with blocking=false, timeout=2s) so login latency is unaffected.
• build_user_row($user_id) extracted as a reusable helper. Both the hourly batch and the on-demand push call it. Centralises role-filtering + display_name fallback + usermeta probing.
• display_name fallback. When wp_usermeta.first_name / last_name are both empty (typical on BidSpirit-only sites), build_user_row() parses display_name ("John Smith" → first=John, last=Smith) so we don't ship a row with a blank name when the data is sitting on the user record itself.
• Three new action hooks registered in class-stats-init.php::init():
• wp_login → push_for_user_id($user->ID) — every login refreshes the row
• profile_update → same — profile edits in wp-admin refresh
• user_register → same — new registrations get pushed instantly (instead of waiting up to 60 min for the next cron tick)

Files Changed

• Modified: inc/sync/class-profile-sync.php (refactor + new method + display_name fallback)
• Modified: inc/stats/class-stats-init.php (three new action hooks)
• Modified: auctionforge.php (Version 3.7.0.2 → 3.7.0.3)

Verification

1. On a 3.7.0.3 site, find a user whose wpdeploy.user_profiles.first_name is empty:

SELECT site_id, email, first_name FROM user_profiles WHERE email='something@example.com'

2. Log in as that user (or have them log in).

3. Within ~2 seconds, re-query — first_name should now be populated, either from the standard meta key OR parsed from display_name.

4. The non-blocking POST means the user's login experience is unchanged — no spinner, no extra latency.

Operator note

Existing wpdeploy rows with empty first_name/last_name will refresh automatically as users log in or edit their profile. To force a one-shot re-walk of every user on a site (regardless of watermark), reset the watermark there:

DELETE FROM wp_options WHERE option_name='auctionforge_profile_sync_watermark';

Next hourly cron will re-pull every non-admin user with the new fallback applied.

---

[3.7.0.2] — 2026-05-02

Fix: sync-lots datetime mismatch + idle syncs now heartbeat

Why

Two issues surfaced in the wpdeploy Sync Health dashboard:

1. Every site's sync-lots was stuck on api_error. The plugin sends last_modified straight from wp_bp_meta_data.lastUpdate, which is a Unix epoch string ("1756919754"). wpdeploy's lots.last_modified column is a DATETIME, so MariaDB rejects the insert with SQLSTATE[22007]: Incorrect datetime value. The handler records api_error and the watermark never advances, so every cron tick re-fails on the same batch.

2. Sites with nothing to sync looked dead. When a sync handler had an empty batch (e.g. no non-admin users yet) it was returning early without POSTing anything. wpdeploy's update_sync_health() only fires on a successful POST, so sites.sync_health_json stayed NULL and the dashboard showed grey dots — indistinguishable from a broken cron. WP-Cron was actually firing fine; the watchdog just couldn't tell.

Fixes

• inc/sync/class-lots-sync.php — new epoch_to_datetime() helper converts the BidSpirit epoch field to UTC Y-m-d H:i:s before shipping. Idempotent: already-formatted datetimes pass through untouched, invalid values become NULL.
• inc/sync/class-sync-base.php::run() — always POST, even when the batch is empty. Empty payload is {records: []} and wpdeploy's existing handlers handle it gracefully (loop is skipped, update_sync_health() still fires with synced=0). This makes the dashboard reflect cron liveness, not just data flow.

Files Changed

• Modified: inc/sync/class-lots-sync.php
• Modified: inc/sync/class-sync-base.php
• Modified: auctionforge.php (Version 3.7.0.1 → 3.7.0.2)

Verification

1. On Clumber: do_action('auctionforge_sync_lots') — confirm the previous auctionforge_last_sync-lots_status = api_error flips to success(N) and that wpdeploy.lots now contains rows.

2. On a site with no non-admin users: do_action('auctionforge_sync_user_profile') — confirm auctionforge_last_sync-user-profile_status = idle(0) AND that wpdeploy's Sync Health page now shows a green dot for that cell.

---

[3.7.0.1] — 2026-05-02

Fix: marketing data leaks WordPress admins into the people list

Why

After the 3.7.0.0 rollout the central people view on wpdeploy was showing site administrators alongside real auction-house users — the sync-user-profile handler read straight from wp_users with no role filter, so any account with administrator/editor/author/contributor/shop_manager capabilities was getting shipped as if it were a buyer. Marketing audiences must contain buyers, not staff.

Fixes (inc/sync/class-profile-sync.php)

• The read_batch() SQL now LEFT JOINs {$wpdb->usermeta} on the prefix-aware capabilities key ({$wpdb->prefix}capabilities) and filters out any user whose serialized capabilities meta_value contains administrator, editor, author, contributor, shop_manager, or super_admin. Users with IS NULL (no roles registered) are still allowed through — those are typically subscribers/buyers on this fleet.
• Watermark on auctionforge_profile_sync_watermark is unchanged; the next run after upgrade picks up the same batch with the new filter applied. Operationally the wpdeploy team also wiped the existing admin rows from user_profiles, user_interests, user_recent_activity, bids_wins, and people to clear the leak server-side — total of 35 rows scrubbed.