Releases: I-HiMo-I/UKExhibition-Wordpress-Plugin
Release list
v10.1.0
v10.1.0 — 2026-07-03
Small release — optional phone number field
What changed
- Added a Phone Number field to the registration form, right after Email — clearly marked "(optional)" and not required, so customers can leave it blank
- New
phonecolumn on the registrations database table (nullable) — will be created automatically on next load via the auto-upgrade check added in v10.0.0, no reactivation needed - Included in the admin notification email when provided (omitted entirely if left blank — no "Phone: " with nothing after it)
- New Phone column added to both the Registrations admin page and the per-exhibition registrants list, showing "—" when not provided
- Works identically for both normal registrations and the "Can't find your exhibition?" manual-entry flow from v10.0.0
v10.0.0
v10.0.0 — 2026-07-03
Major release — "Can't find your exhibition?" section with manual registration
What's new
- New banner at the top of the page, above the search bar: "Can't find your exhibition on this list? [Register Your Interest]"
- Clicking it opens the same registration popup, but in a special mode with one extra field: "Exhibition Name & Date" — a free-text box where the visitor types the exhibition they were actually looking for
- The rest of the form (Name, Email, Job Title, Country, Town) is identical to a normal registration — same validation, same design
- Emails are worded differently for this flow — the admin gets "Exhibition request (not found on site): [what they typed]" instead of a normal registration notice, and the customer gets "We received your exhibition request" instead of a booking confirmation, so nobody mistakes this for a real listing
- Admin → Registrations page now shows a red "Not Found" badge next to these entries, followed by the exhibition name/date the visitor typed — so you can tell at a glance which registrations are for real listings vs. requests for exhibitions you don't have yet
Database change
Added a requested_exhibition column to the registrations table for this free-text entry. Important: added an automatic schema-upgrade check that runs on every plugin load (comparing a stored version number against the current one) — this means the new column gets created automatically the next time the site loads this version, without needing to deactivate and reactivate the plugin. This will also make any future schema changes apply automatically going forward.
v9.15.0
v9.15.0 — 2026-07-03
Major release — email diagnostics, a real bug fix, and a Send Test Email button
Most likely explanation for "registration saves but no emails arrive"
Registration saving is a database write (always works). Sending email depends entirely on the server's mail transport, which is a completely separate system. If you're running this on local XAMPP without an SMTP plugin, this is almost certainly the cause — PHP's built-in mail sending has no real mail server to talk to on a local machine, so it fails silently for every outgoing email on the whole site, not just this plugin. The fix is the same for any WordPress site on localhost: install WP Mail SMTP (free) and connect it to a real account (a free Gmail account works fine), which routes outgoing mail through an actual mail server instead of relying on PHP's native — and typically nonfunctional on localhost — mail() function.
A real bug fixed either way
Both email bodies were using esc_html() on plain-text content. esc_html() converts characters like & and ' into HTML entities (&, ') — correct for HTML output, but wrong for a plain-text email, where it would literally corrupt exhibition/venue names containing those characters (e.g. "Fashion & Retail" would render as "Fashion & Retail" in the email body). Removed the incorrect escaping.
New: you can now actually see why an email failed
Previously, wp_mail() failures were completely invisible — it just silently returns false with no error anywhere. Added:
- A
wp_mail_failedhook that captures the real PHPMailer error message (bad SMTP credentials, connection refused, invalid recipient, etc.) to a new option - An error box on the Settings page showing that captured message directly — copy-pasteable for diagnosis
- A "Send Test Email" button next to the admin email fields — sends one test message immediately and reports success or the exact failure reason, without needing to submit a full registration to test
v9.14.0
v9.14.0 — 2026-07-03
Small release — renamed accordion column headers
What changed
Renamed the three column headers on the "All Exhibitions by Category" accordion table:
- "Name" → "Exhibitions Category"
- "Number" → "Number of Exhibitions"
- "Register" → "Registered Person"
Widened the two stat columns slightly (160px → 190px) to comfortably fit the longer labels. The Registrations page and exhibition detail page still correctly say "Name" for registrant names — those are unrelated columns and were left untouched.
v9.13.0
v9.13.0 — 2026-07-03
Major simplification — rebuilt to match the sketch: one simple 3-column table (Name | Number | Register)
What changed
Scrapped the colspan-alignment approach from v9.9–9.12 entirely in favour of a much simpler, sketch-matching structure:
- One table with three real column headers: Name | Number | Register
- Each category is one genuine
<tr>in that table — name on the left, exhibition count centred under "Number", registered count centred under "Register" - Clicking a row reveals a second
<tr>directly below it (spanning all 3 columns), containing that category's full exhibition table — with its own headers (Exhibition/Date/City/Cycle/Registrations/Action), shown only while expanded
This is plain, valid table markup throughout — no colspan tricks, no matching <colgroup>s between separate tables, nothing to keep in sync. It reads correctly as a real table with real columns in both the closed and open states, matching the sketch exactly.
v9.12.0
v9.12.0 — 2026-07-03
Small release — clearer left/right split: name gets more room on the left, both counts grouped tightly at the far right
What changed
Adjusted the column mapping in the closed category header row:
- Category name now spans 4 of 6 columns (colspan=4, covering Exhibition/Date/City/Cycle) — giving it noticeably more room on the left rather than being squeezed into 3 columns
- Exhibition count and registered count are now the final two cells, occupying the Registrations (110px) + Action (130px) columns — roughly two columns' worth of width at the very right edge of the page, with no empty trailing cell between them and the edge
- This creates a clear visual gap between the name (left) and the two stats (grouped together, right), rather than the stats sitting in the middle of the row
Still uses the same shared <colgroup> as the exhibition table below, so this stays perfectly aligned once a category is opened.
v9.11.0
v9.11.0 — 2026-07-03
Small release — header columns now precisely aligned with the exhibition table below via a shared colgroup
What changed
Each category's header row now uses the exact column mapping requested:
| Cell | Content | Spans |
|---|---|---|
| 1 | ▶ Category name | 3 columns (under Exhibition/Date/City) |
| 2 | 🗂 Exhibition count | 1 column (under Cycle) |
| 3 | 👥 Registration count | 1 column (under Registrations) |
| 4 | (empty) | 1 column (under Action) |
Both the header's mini-table and the exhibition table (shown once opened) now share an identical <colgroup> defining the same 6 column widths. This is what makes the alignment precise rather than approximate — both tables compute their column widths from the same source, so the name/count cells in the closed header land exactly above the columns they represent once you open that category.
This keeps v9.10's fix (each category is still its own independent <div> with its own table — not one shared table for the whole page) while adding the real column structure you asked for, so a closed category reads as organised columns rather than loose text sitting next to other text.
v9.10.0
v9.10.0 — 2026-07-03
Small release — reverted to per-category divs (v9.7.0 structure), kept v9.9's separate-td-cells improvement
Why
v9.8/v9.9 wrapped the entire accordion (all 15 categories) in ONE giant <table> with a single shared <thead> at the top of the page. That header row's column labels ("Exhibition / Date / City / Cycle / Registrations / Action") describe the exhibition rows once a category is opened — but they don't describe the category summary rows (name / exhibition count / registered count) sitting above them. Having one mismatched header for the whole page looked wrong, as flagged.
What changed
Went back to v9.7.0's structure — each category is its own self-contained <div class="rhg-cat-block">, not part of one page-spanning table — while keeping v9.9's genuine improvement:
- Each category's header is now its own tiny one-row table, with real
<td>cells for name / exhibition count / registered count (no custom flexbox layout needed for basic readability) - Each category's exhibition list, once opened, is its own independent table with its own column headers — exactly matching the data inside it, not a shared header from elsewhere on the page
.rhg-cat-blockis a real<div>again, so its border/border-radius/background render reliably (these don't work consistently on<tbody>, which is why v9.8/9.9 had to drop them)- Toggle animation restored to smooth
slideUp()/slideDown()— that only misbehaves on<tbody>elements, and the body is a plain<div>again now
v9.9.0
v9.9.0 — 2026-07-03
Small release — category header row now uses separate td cells per data point instead of one merged cell
What changed
The category header row previously used a single <td colspan="6"> containing a <div style="display:flex"> to lay out the name and stats side by side. That inner flexbox layout is custom CSS — if admin.css ever failed to load again, the name and stats would have no layout at all and could render stacked/overlapping.
Rebuilt using genuinely separate <td> cells, mapped onto the same 6-column grid the exhibition rows below use:
colspan="3"— category name + toggle icon (spans where "Exhibition / Date / City" would be)- 1 cell — exhibition count (aligned under "Cycle")
- 1 cell — registration count (aligned under "Registrations")
- 1 empty cell (aligned under "Action", keeping the column count consistent)
Each piece of information now has its own table cell with native cell padding/alignment, rather than depending on a custom flexbox wrapper to position things correctly. The colour/hover/open-state styling in admin.css is still there as polish on top, but the row is now legible even without it.
v9.8.0
v9.8.0 — 2026-07-03
Major release — accordion rebuilt as one continuous table (tbody/tr/td), per user's suggested fix
The insight
You correctly spotted the pattern: when the dropdown is open, the exhibition list uses real <table><tbody><tr><td> markup — which automatically inherits WordPress's own built-in .wp-list-table borders and striping (loaded on every admin page by default, regardless of our plugin). When closed, the category header was just plain <div> tags with no such fallback — so it depended entirely on our own admin.css loading correctly, which (per v9.7.0) had been failing.
What changed
Rebuilt the whole accordion as one continuous <table>, so both states get the same free WordPress styling as a baseline, with our own CSS layered on top rather than being the only thing holding it together:
- Each category is now two
<tbody>elements back to back: a header tbody (always visible, containing one<tr>with a single<td colspan="6">for the clickable category summary) followed by a body tbody (hidden until clicked, containing that category's exhibition<tr>rows — unchanged from before) - The whole thing lives inside one
<table class="wp-list-table widefat fixed striped">, so even in a worst-case scenario where our CSS fails to load again, WordPress's own table borders and row striping still apply to the category headers automatically - Updated
admin.cssto match: flex layout moved from the (now<tr>) header onto an inner wrapper<div>inside the<td>— a<tr>cannot itself bedisplay:flexwithout breaking table layout - Toggle animation switched from
slideUp()/slideDown()to plainshow()/hide()— jQuery's slide animation manipulates height directly, which doesn't behave reliably on<tbody>elements across browsers;show()/hide()correctly restoresdisplay:table-row-group
No visible functional changes — same stats, same "closed by default" behaviour, same columns — but the page should now look reasonable even in the failure case that caused v9.7.0's bug in the first place.