aurora-wordpress-admin/CHANGELOG.md

Changelog

All notable changes to Aurora Admin, newest first — one entry per version bump. Versioning restarted at 1.0 on 2026-07-25 for the first public release; the earlier internal 3.x history is preserved in CHANGELOG-legacy.md.

[1.13] — 2026-07-26

Fixed

• Theme File Editor (theme-editor.php) and Plugin File Editor (plugin-editor.php) rendered their file-tree sidebar essentially unreadable in dark mode — core's #templateside > ul sets an explicit light background (#f6f7f7) that nothing in native-dark.css covered, and since this file's own text/link colors are tuned for a dark surface, the combination was light text on a light background rather than just unstyled. Both screens share the exact same #templateside component, so one rule (#templateside > ul { background: transparent; }) fixes both. Visual-only; direct file editing remains entirely native WordPress functionality, framed the same way as Site Health and Updates rather than rebuilt.

[1.12] — 2026-07-26

Added

• Disable Gutenberg toggle (Settings > Screens > Editor, admin/src/Editor/DisableGutenberg.php): opt-in, off by default. Filters use_block_editor_for_post_type to fall back to WordPress core's own classic (meta-box/TinyMCE) post editor — the same core-supported mechanism the official Classic Editor plugin uses — rather than framing or rebuilding the block editor. The block editor remains one of the two deliberate "still native" exceptions in the admin takeover; this is an escape hatch around it, not a conversion of it.

[1.11] — 2026-07-26

Fixed

• Updates (update-core.php) rendered available plugin/theme updates with unreadable white table rows in dark mode. Two stacked gaps: (1) this table is class="widefat updates-table", not .wp-list-table — native-dark.css had zero coverage for .widefat, so it's now covered by the same generic table/td/th rules added for Export/Erase Personal Data in 1.10. (2) Even after that, the <tr> itself stayed white — traced to WP core's list-tables.css, which sets .plugins tr { background: #fff; } for the real native Plugins screen; both the plugin-update and theme-update tables reuse <tbody class="plugins">, so the plain class name collides and wins over the dark background. Fixed with a scoped .plugins tr { background: transparent; } override in native-dark.css. Verified live via an injected mock table matching update-core.php's real markup shape — both rows render fully dark and readable. Visual-only; update checking/installation stay entirely native.

[1.10] — 2026-07-26

Fixed

• Export Personal Data and Erase Personal Data (the privacy/GDPR tools) rendered with unreadable white table rows — WordPress core sets an explicit white background directly on <td> elements (not just <tr>), which silently wins over .wp-list-table's own dark background. This is a generic WP_List_Table gap, not specific to these two screens, so the fix (native-dark.css) applies broadly to any native list-table screen, not just these.
• Per an explicit decision: these two screens' request queue, bulk actions, and the AJAX-driven export/erase processing (which runs every plugin's own registered wp_privacy_personal_data_exporters/erasers callbacks) stay entirely native — a subtly-wrong rebuild here has real compliance consequences, not just cosmetic ones, unlike Tools/Export/Import. Same "frame native content" treatment as Site Health.

[1.9] — 2026-07-26

Changed

• Activity Log rebuilt from a master-detail sidebar list into a full data table (Date, Author, IP Address, Type, Action, Description), matching a reference design. Two tabs — Admin (site/content activity) and User (account activity: login/logout/registration/profile updates) — filter via a new scope REST param (object_type = 'user' vs != 'user').
• The Author column now shows the user's avatar, role, and a link to their profile, plus email — batch-fetched at query time from user_id rather than duplicated into every log row, so it always reflects the account's current role/email.
• object_type for content events is now the post's real type (post/page/a custom post type) instead of a hardcoded "post" — Page edits now correctly show as "Page", not "Post".
• action_type values unified to generic verbs (created/updated/deleted/etc.) reused across content types, instead of type-prefixed strings (post_deleted, plugin_activated, ...) — Type and Action are now cleanly orthogonal filterable columns. Pre-existing log rows keep their original values (no backfill).

Added

• IP address capture (REMOTE_ADDR only — deliberately not trusting X-Forwarded-For, which is spoofable and this plugin has no way to know if a given host's proxy is trustworthy).
• Logout tracking (wp_logout) and media upload/delete tracking (add_attachment/delete_attachment), both absent before.

Fixed

• Login and self-registration events were recorded as done by "System" instead of the actual user. Root cause: wp_get_current_user() isn't reliable at the moment either hook fires — wp_login fires from inside wp_signon(), before the caller sets the current user, and a self-registering visitor isn't authenticated yet at user_register time (confirmed via WP core source, not a guess). Both hooks already receive the right user identity as a parameter for exactly this reason; record() now accepts an explicit actor override, used by both.

[1.8] — 2026-07-25

Added

• Full admin takeover: the Import screen (import.php) is now a real Aurora-built replacement via ScreenHijack, gated behind full_admin_takeover. Only the listing/install page is rebuilt — running an already-active importer still opens admin.php?import={id}, a screen entirely owned and rendered by whichever third-party importer plugin registered that id, which is unpredictable, arbitrary UI outside this hijack's scope and stays native (same category as the block editor).
• Install/activate reuses two already-proven mechanisms instead of new logic: WordPress core's own admin-ajax.php?action=install-plugin (the exact request native's "Install Now" button triggers) for installing, and Aurora's own aurora-admin/v1/plugins/activate route for activation. Any third-party output hooked to import_filters is captured and re-rendered, same as Tools' tool_box handling.

Fixed

• get_importers() returns null (not an empty array) until something has actually called register_importer() — true on any site with no active importer plugins, including this dev site. Native import.php never hits this directly (it only reads the result via isset(), and by the time it ever foreaches, PHP has already auto-vivified the variable into an array via an earlier assignment) — but this code foreaches the raw result directly and needed its own explicit is_array() guard. Reproduced live, fixed, verified clean.

[1.7] — 2026-07-25

Added

• Full admin takeover: the Export screen (export.php) is now a real Aurora-built form via ScreenHijack, gated behind full_admin_takeover. Safe to fully rebuild (unlike Tools/Site Health): the actual ?download=true file-generation request calls export_wp() and die()s before ever reaching in_admin_header/admin_footer (the hooks the hijack's buffering relies on), so it's never touched by the hijack — Aurora's form submits via a real browser navigation to that same URL, and the resulting WXR file is byte-for-byte what core would have produced.

Fixed

• The form initially only sent non-empty filter params, but native export.php reads $_GET['cat'] etc. directly with no isset() guard — omitting a param when "All" was selected triggered PHP "Undefined array key" warnings that get echoed straight into the downloaded file (verified: with display_errors on, this corrupted the XML with warning HTML before the <?xml declaration). Fixed by always sending every relevant param for the selected content type, matching native's own <select>-based form exactly. Verified live across All content/Posts/Pages/Media — clean output, no warnings, in all four cases.

[1.6] — 2026-07-25

Fixed

• Site Health (site-health.php) rendered with unreadable text — three of its own elements (.health-check-header, .health-check-accordion-trigger, .health-check-accordion-panel) painted a hardcoded white/off-white background that the generic dark-text cascade didn't reach, leaving light text against a light background (the same pattern already fixed for the block editor's "boot-layout" panels). Fixed in native-dark.css.
• Deliberately did not rebuild Site Health's own test logic: its Status tab hits WordPress core's own /wp-site-health/v1/tests/* REST routes, and third-party plugins can add their own checks via the site_status_tests filter — reproducing that risked both drifting from core and silently dropping other plugins' checks. Frame and theming are Aurora's; the tests themselves stay WordPress core's, same "frame native content" treatment as the Gutenberg editor.

[1.5] — 2026-07-25

Added

• Full admin takeover: the Tools screen (Available Tools, tools.php) is now a real Aurora-built replacement via ScreenHijack, gated behind full_admin_takeover like the other takeover screens.
• Core's "Categories and Tags Converter" card — which turned out to be hardcoded in tools.php's own template rather than produced by the tool_box hook — is reproduced with the identical capability gate (import + category/tag manage_terms) so visibility exactly matches native behavior.
• Any card another active plugin adds via the genuine tool_box hook is still captured and displayed, styled to match — Aurora owns the page shell, not third-party hook content, so nothing another plugin adds to this screen silently disappears.

[1.4] — 2026-07-25

Added

• Login Redirect (Settings > Appearance > Login Redirect): two opt-in, off-by-default redirects — send logged-out wp-admin visitors to a custom URL instead of the login screen (init-time guard, correctly scoped around admin-ajax.php/admin-post.php/REST/cron/network-admin so nothing else breaks), and send specific roles to a custom URL after logging in instead of the dashboard (standard login_redirect filter). Deliberately does not touch wp-login.php itself — hiding/changing the login URL is a separate, higher-risk feature not implemented here.
• Verified live: a logged-out request to /wp-admin/ correctly lands on the configured URL when enabled, and falls back to normal WordPress behavior when disabled. The after-login role redirect was verified by code review (the standard login_redirect filter pattern) rather than a live browser login, to avoid overwriting the tester's authenticated session cookies.

[1.3] — 2026-07-25

Added

• New Modules page (Aurora sidebar): an addon marketplace for Aurora's standalone companion plugins (File Manager, Database Explorer, Site Backup), each installable and activatable with one click. This is now the primary entry point for installing Aurora addons, including future ones as they're released.

Changed

• Settings' "Add-ons" category has been removed — its install cards moved to the new Modules page.

[1.2] — 2026-07-25

Fixed

• Menu Creator was effectively non-functional: its item list was always empty, because it fetched the menu over REST where WordPress doesn't build the admin $menu. The raw top-level menu is now captured at page load and passed via the page's serverData, so the editor actually shows the items.

Added

• Menu Creator: reordering now works. The item list is drag-to-reorder (with up/down buttons as a fallback), and the saved order is applied to Aurora's sidebar by MenuSerializer. Items the config doesn't mention — separators and newly installed plugins' menu items — are preserved after the ordered ones, so nothing disappears.

Changed

• Menu Creator now edits top-level items only; the previous submenu rows were removed because submenu hide/rename was never actually applied (a clean future addition).

[1.1] — 2026-07-25

Fixed

• Plugins screen now re-syncs with the real backend state after activate/deactivate/delete, so a plugin no longer keeps showing "deactivated" when WordPress's activate_plugin() returns a benign "unexpected output" error even though the plugin did activate.

Changed

• Documented a Plugin Check phpcs:ignore for the emoji_svg_url WordPress core filter used by the Security module's emoji-disable feature.

[1.0] — 2026-07-25

First public release.

Admin experience

• Full modern admin shell — fixed sidebar, toolbar, and global search — in place of the standard WordPress admin chrome.
• Custom takeover screens for Dashboard, Posts, Pages, Media, Users, and Comments, plus Add User, Media Upload, and Profile.
• Sub-apps: Settings, Setup Wizard, Menu Creator, Role Editor, Admin Notices, Activity Log, and Report a Bug.

Theming

• Live theme presets with an accent-driven palette applied across the whole admin, plus a Google Font picker for the interface typeface.
• Rounded content cards with a soft shadow so each page reads as a framed surface.
• Scroll areas sit inside the rounded frame — the scrollbar no longer squares off the right corners — and scrollbars are tinted with the active theme accent.

Under the hood

• REST API namespace aurora-admin/v1 backing every takeover screen.
• Security & performance hardening module, custom admin CSS/JS injection, and a login-screen customizer.