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.css to match: flex layout moved from the (now <tr>) header onto an inner wrapper <div> inside the <td> — a <tr> cannot itself be display:flex without breaking table layout
• Toggle animation switched from slideUp()/slideDown() to plain show()/hide() — jQuery's slide animation manipulates height directly, which doesn't behave reliably on <tbody> elements across browsers; show()/hide() correctly restores display: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.

---