v9.7.0
v9.7.0 — 2026-07-03
Small release — found the real cause: admin.css was never loading on the Exhibitions/Settings pages
Root cause
enqueue_admin_assets() only loads admin.css when the current page's WordPress "hook name" matches a hard-coded list. That list had the wrong hook names — exhibitions_page_rhg-exhibitions-list and exhibitions_page_rhg-exhibitions-settings — missing the rhg- prefix.
WordPress builds a submenu page's hook name from its parent menu's actual slug as the prefix. Since the top-level menu here is registered with the slug rhg-exhibitions, the real hook names are rhg-exhibitions_page_rhg-exhibitions-list and rhg-exhibitions_page_rhg-exhibitions-settings. Because the hard-coded list didn't match, the in_array() check silently failed and wp_enqueue_style() never ran on those two pages — admin.css has never actually loaded on the Exhibitions or Settings pages, only on the top-level Registrations page (where the hook happened to coincidentally match).
Why it looked the way it did in your screenshots
- Closed accordion (ugly): the category boxes' borders, backgrounds, padding, and hover states are all defined in
admin.css— none of it ever arrived, so it rendered as plain unstyled text - Open accordion (looked fine): the exhibition table inside uses WordPress's own built-in
wp-list-table widefat fixed stripedclasses, which are core WordPress styles loaded on every admin page automatically, regardless of whether our own plugin stylesheet loads — so it looked properly styled by coincidence, while the category header/box around it did not
Fix
Corrected the hook names in the $admin_pages allow-list to match WordPress's actual naming convention. admin.css will now load correctly on all three HimoEXPO admin pages (Registrations, Exhibitions, Settings), including the category box borders, backgrounds, and hover states that were missing.