- **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.
- **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.
- **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.
- **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).
- 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.
- 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.
- **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 `foreach`es, PHP has already auto-vivified the variable into an array via an earlier assignment) — but this code `foreach`es 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.
- 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.
- 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).
- 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.
