admin_notices fires everywhere, but prints inside #wpbody, which DashboardTakeover hides entirely on the Dashboard (to hide the *native* dashboard, not ours) — notices went down with it as collateral damage. Notices::render_for_dashboard() now renders directly inside the visible dashboard frame instead, called from DashboardTakeover::render_mount(); the normal admin_notices path bails on the Dashboard so it isn't rendered twice. Second, independent bug found along the way: wp-admin/js/common.js unconditionally relocates every .notice element on the page to right after the page's <h1>, regardless of where it was placed server-side — without opting out, it would've silently moved our notice right back into the hidden #wpbody. Used core's own documented `below-h2` class to opt out, only for the dashboard render path. Verified live: notice now shows correctly inside the dashboard frame with proper dark styling, and dismisses correctly. Co-Authored-By: Claude Sonnet 5 <[email protected]>
5.8 KiB
5.8 KiB
Changelog
All notable changes to Aurora Admin are documented here, one entry per
version bump. Starts at 2.1.0 — earlier history (the theming rebuild,
window chrome/taskbar, Site Editor support, etc.) lives in git log and
PROJECT_STATUS.md, not reconstructed here.
[2.4.2] - 2026-07-04
Fixed
- Admin Notices only ever showed on the Aurora Dashboard — everywhere
else,
admin_noticesfired normally, but on the Dashboard specifically the notice was invisible:DashboardTakeoverhides#wpbodyentirely there (to hide the native dashboard, not our own), and that's exactly where WordPress printsadmin_noticesoutput. Notices now render directly inside the Aurora dashboard frame instead on that one page. Along the way, also worked around a separate WordPress core behavior (common.jsunconditionally relocates every.noticeelement to right after the page's<h1>) using core's own documentedbelow-h2opt-out class, since without it the notice would've just been silently moved back into the hidden#wpbodyby that script regardless of where it was placed server-side.
[2.4.1] - 2026-07-04
Fixed
- Dashboard scrolling was broken — content below the first ~1500px
(Server Health, Media Analytics, etc.) was completely unreachable.
.aurora-dashboard-framenever got the height cap + internal scroll treatment#wpbody-contentgot in an earlier fix; combined withhtml/bodybeing locked tooverflow: hidden(to fix a phantom scrollbar on a different page), there was no scroll mechanism left at all for the dashboard specifically. Mirrored the same max-height/overflow-y treatment onto.aurora-dashboard-frame.
[2.4.0] - 2026-07-04
Added
- Settings > Menu's "Menu search" toggle now actually does something — previously had no implementation at all. Shows a real search box at the top of the sidebar that filters both the WP-native menu list and the Aurora nav section by title, auto-expanding every section with a match.
Fixed
- Settings > Dashboard's "Custom dashboard" toggle now actually gates the dashboard takeover — previously the Aurora dashboard always replaced the native one regardless of this setting, with no way to turn it back off.
- Settings > Plugins' "Modern plugins page" and Settings > Comments' "Modern comments page" toggles now actually gate their respective takeovers/redirects the same way — previously both ran unconditionally regardless of these settings.
Removed
- Settings > Posts' "Modern posts table" and Settings > Users' "Modern users page" toggles — both described a custom management interface that was never built. Shipping a checkbox with nothing behind it is worse than not having the checkbox; removed rather than left as dead UI. Their categories are removed too, since they had no other fields.
[2.3.1] - 2026-07-04
Fixed
- Sidebar accordion now treats the "Aurora" branded nav section as part of the same single-open accordion as the WP-native menu list, instead of being the one exception that stayed open regardless of what else was expanded. Expanding any native section now collapses Aurora too, and vice versa.
[2.3.0] - 2026-07-04
Added
- Settings > Media's "Allow SVG uploads" toggle now actually does
something — previously existed in the UI with no implementation behind
it, so every SVG upload was rejected. Fixes both of WordPress's default
blocks (the
upload_mimesallowlist and the real-mime sniff that nulls out the file type for SVGs specifically), plus a PHP warning (wp_get_missing_image_subsizes()reading undefinedwidth/heightmetadata keys that SVGs never had) that could otherwise corrupt the upload response on environments with warnings displayed inline. Also does basic sanitization on upload (strips<script>tags, inline event handler attributes,javascript:URIs) since SVG can carry executable content.
[2.2.0] - 2026-07-04
Added
- Settings > Login's "Style login page" and "Login logo" fields now
actually do something — previously they existed in the UI with no
implementation behind them at all. Styles
wp-login.phpwith a dark theme (background, card, inputs, button) and swaps in the configured logo image in place of the WordPress logo, linked to the site's home URL instead of wordpress.org.
[2.1.1] - 2026-07-04
Fixed
- Image fields (Logo, Dark mode logo, Login logo, Admin favicon) now open
the real WordPress media library picker.
wp_enqueue_media()was never called, sowp.mediawas undefined client-side and every image field silently fell back to a plain URL prompt instead.
[2.1.0] - 2026-07-04
Added
- Free/paid feature gating: Role Editor, Activity Log, Database Explorer, Analytics, White Label, and the remote site switcher are now Pro features. Menu Creator, Admin Notices, Comments, Plugins, and the core shell/theming stay free. Locked pages show an upgrade prompt instead of the real feature; the sidebar shows a lock badge on locked items.
- Real license validation against the
auroraplugins.comlicense server (validate/activate/deactivate), replacing the earlier placeholder that treated any non-empty key as active. Status is cached for 12 hours and re-checked immediately on a license-key change. The Settings page shows a live status line (active/invalid/unreachable) under the License key field. - File-integrity tamper protection: if the code implementing the license gate has been modified, every paid feature re-locks regardless of an otherwise-valid license — makes stripping the check out of a redistributed copy not actually unlock anything.
Fixed
- Role Editor's REST endpoint 500'd when hit via the REST API — it called
get_editable_roles(), which WordPress only auto-loads for normal wp-admin page requests, not REST requests.