# 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.7.2] - 2026-07-05 ### Fixed - Installing/activating a plugin dropped back to the native WordPress Plugins page instead of staying in Aurora's UI, until the sidebar's "Plugins" link was clicked again. Unlike Posts/Pages/Media/Users/ Comments, Plugins only ever had its sidebar *link* rewritten (`MenuSerializer.php`) — there was no `redirect_native_pages()` case for direct visits to `plugins.php`, which is exactly what WordPress's own post-activate/post-install redirect does (`wp_redirect(self_admin_url('plugins.php?activate=true'))`, no `?page=` param). Added the missing case, matching the pattern already used for the other four pages. ## [2.7.1] - 2026-07-05 ### Fixed - Native form fields (text inputs, textareas, selects) on several classic/non-block-editor screens — most visibly the title field on the Edit Media screen, but the same fix applies wherever it occurred — were showing stark white, breaking the dark theme. Root cause: some native WP screens style specific fields via a 2-ID selector (e.g. core's `#titlediv #title { background: #fff }`), which beats our existing rule's single `#wpbody-content` id no matter how many classes are stacked on it — the exact same CSS-specificity trap as an earlier block-editor background bug. Added `!important` to the form-field rule block, since there's no legitimate case where a native admin form field should stay white. ## [2.7.0] - 2026-07-05 ### Added - New File Manager (`aurora-admin-file-manager`), browsing/editing the WordPress install's own files — built fresh (not embedding elFinder), in the spirit of the "WP File Manager" plugin already on this site (same root, same `manage_options`-only gate). Create/upload/download/ rename/delete files and folders, plus a plain-text editor for code/config files. A **Pro feature** — the riskiest surface in the whole plugin (arbitrary read/write access to the site's own PHP files), so it's gated the same way as Database Explorer. - Every path a client sends is resolved to a real, `ABSPATH`-contained path via `realpath()` before any filesystem operation — containment is checked against the resolved path, not string-matched against the raw input, so symlink tricks and encoded traversal can't slip past. - Uploads/new files/renames all reject a blocklist of server-executable extensions (`.php`, `.phtml`, `.cgi`, `.sh`, etc.) — the single most important control here, since uploading a webshell is the whole ballgame. - Deliberately not built: zip/unzip (zip-slip extraction vulnerability), chmod/permissions editing, and cross-directory move/copy — each is a meaningfully larger, riskier scope than a first pass warrants. ### Fixed - File Manager's REST endpoints now also check `License::is_feature_available('file-manager')`, not just `manage_options` — found while wiring it up that the page-level lock alone doesn't stop a direct REST call from bypassing it entirely. **The same gap exists in Database Explorer, Role Editor, and Activity Log's REST controllers and is not yet fixed** — flagged as a follow-up. ## [2.6.0] - 2026-07-05 ### Added - Real replacement pages for Pages, Media Library, and Users — the remaining native admin screens that were only dark-themed skinning, now built the same way as Posts/Comments/Plugins (own REST controller, own Vue page, native screen redirected away): - **Pages** (`PagesData.php` + `Pages.vue`): same as Posts, but shows the parent page instead of categories. `edit.php?post_type=page` redirects; other post types are untouched. - **Media Library** (`MediaData.php` + `Media.vue`): a thumbnail grid (not a rebuilt drag-drop uploader) with type filters (Images/Audio/ Video/Documents/Unattached), search, and delete. `upload.php` (both grid and list mode) redirects; `media-new.php` (the actual upload screen) is untouched, same reasoning as leaving the block editor alone for Posts/Pages. - **Users** (`UsersData.php` + `Users.vue`): filterable by role, with edit/delete actions. Deleting a user always reassigns their content to whoever performs the deletion, rather than exposing WP core's reassign-or-delete-everything choice as a one-click REST action — deliberately simplified to avoid a surprising, highly destructive default. `users.php` redirects; `user-new.php` (account creation) is untouched. - All four gated by their own Settings toggle (`modern_pages`, `modern_media`, `modern_users` — `modern_posts` already existed), each defaulting to on. ## [2.5.0] - 2026-07-05 ### Added - Real replacement Posts management page (`aurora-admin-posts`), the same kind of full custom page as Comments/Plugins rather than dark-themed skinning over the native `edit.php` list table. New `PostsData.php` REST controller (list with status/search filters, trash, restore, permanent delete) and a new Vue page matching the Comments layout (status filter pills, search, table with title/author/categories/comments/date/status, inline row actions, pagination). The native Posts screen (`edit.php`, default post type only — Pages and other post types are untouched) redirects to it, gated by Settings > Posts' restored "Modern posts table" toggle (removed a few commits ago when it had no implementation behind it — now it does). ### Fixed - The `modern_plugins`/`modern_comments` settings toggles now default to visually "on" in the Settings UI to match their actual PHP default (previously they defaulted true server-side but showed off in the UI until explicitly saved) — same fix applied to the new `modern_posts`. ## [2.4.2] - 2026-07-04 ### Fixed - Admin Notices only ever showed on the Aurora Dashboard — everywhere else, `admin_notices` fired normally, but on the Dashboard specifically the notice was invisible: `DashboardTakeover` hides `#wpbody` entirely there (to hide the *native* dashboard, not our own), and that's exactly where WordPress prints `admin_notices` output. 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.js` unconditionally relocates every `.notice` element to right after the page's `

`) using core's own documented `below-h2` opt-out class, since without it the notice would've just been silently moved back into the hidden `#wpbody` by 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-frame` never got the height cap + internal scroll treatment `#wpbody-content` got in an earlier fix; combined with `html`/`body` being locked to `overflow: 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_mimes` allowlist and the real-mime sniff that nulls out the file type for SVGs specifically), plus a PHP warning (`wp_get_missing_image_subsizes()` reading undefined `width`/`height` metadata 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 `