aurora-wordpress-admin/PROJECT_STATUS.md

Aurora Admin v2 — Project Status

_Last updated: 2026-07-11 (latest session — v3.6.0: Site Backup was extracted out of Aurora Admin into a new standalone sibling plugin, aurora-site-backup, at the user's explicit request ("pull out the backup as well and lets move that to an add-on") — the same proactive-risk- reduction reasoning as Database Explorer's 3.5.0 extraction, since restoring a backup means writing arbitrary files back into the site. The entire admin/src/Backup/ tree (job/schedule storage, DB dumper, file archiver, state-machine engine, wp_cron safety net, all three storage providers) and all four Backup REST controllers moved unmodified into the new plugin. Since Backup's storage providers depend on a Settings class for stored credentials (S3 keys, Google Drive OAuth tokens), a small standalone Options\Settings class was added to the new plugin with its own aurora_site_backup_settings option, replacing the dependency on Aurora Admin's own Settings class. CompanionPluginData.php's PLUGINS array (already generalized in 3.5.0) gained a site-backup entry — no new PHP route code needed. Verified live via a full rest_do_request() dispatch that created a real backup job, stepped it through the DB-dump phase, and canceled it — not just "loads without fatals" but actual end-to-end behavior confirmation. See "Site Backup — REMOVED..." below. Same outstanding deployment gap as the other two companion plugins: the zip isn't hosted yet.

Previous session — v3.5.1: a fresh WordPress.org Plugin Check report showed the 3.3.2 compliance pass's phpcs:ignore annotations weren't actually suppressing anything on several multi-line $wpdb-> calls — WPCS suppresses violations on the exact next physical line, but the annotations sat above the opening line of the call while PHPCS attributed the violation to a line further down inside it (where the interpolated table-name token actually appears). Fixed across MenuCreatorData.php, NoticesData.php, Notices.php, BackupSchedules.php, BackupJobs.php, MediaFolders.php (the largest cluster, mostly fixed by collapsing multi-line query calls to one physical line), DbDumper.php, AnalyticsData.php, and MediaData.php — verified with an automated scan that every dynamic-query $wpdb-> call is now correctly covered. Also found and fixed a real, unrelated bug during verification: MenuCreatorData::create() built its "fetch the row I just inserted" follow-up request with new WP_REST_Request("GET", "", ["id" => ...]), but that constructor form doesn't populate what get_param() reads, so creating a menu always returned "Menu not found" — confirmed via a full rest_do_request() dispatch, fixed with set_url_params(). The compressed_files/hidden_files/unexpected_markdown_file findings in the report are scanner noise from scanning the whole dev repo, not the actual submission zip (re-confirmed via unzip -l). Submission zip rebuilt and re-verified after this pass.

Previous session — v3.5.0: Database Explorer was extracted out of Aurora Admin into a new standalone sibling plugin, aurora-database-explorer, following the exact same pattern as File Manager's v3.4.0 extraction — direct database-query tooling (browsing tables, running free-form SELECT/SHOW/DESCRIBE/EXPLAIN queries) is treated by WordPress.org's Plugin Directory review the same way as file-management functionality, so it was pulled out proactively rather than waiting for a rejection. CompanionPluginData.php was generalized from a single file-manager-only class into a PLUGINS config array keyed by slug, so both companion plugins (and any future ones) share the same install/ activate/status REST routes. The Settings → Add-ons screen now lists both. A real production deploy (hosting the aurora-database-explorer.zip on aurora.auroradragon.studio) is still pending explicit user confirmation, not yet done — same outstanding gap File Manager's zip already has.

Previous session — v3.4.0: WordPress.org's second review response said the whole file-management/code-editing category isn't accepted into the Plugin Directory, restrictions or not — so File Manager was extracted entirely out of Aurora Admin into a new standalone sibling plugin, aurora-file-manager, installable with one click from the new Settings → Add-ons screen (wraps core's own Plugin_Upgrader, same class the native "Install Now" button uses). See "File Manager — REMOVED from Aurora Admin in 3.4.0" below, specifically its final "Extraction into a standalone plugin" subsection.

Prior versions this doc covers in detail, newest first: v3.3.2 (WP.org Plugin Check compliance pass, ~230 justified phpcs:ignore annotations across every custom-table feature), v3.3.1 (Settings page independent- scroll fix), v3.3.0 (Modern Image Formats — WebP/AVIF generation + <picture> rewriting, reimplemented against documented WP core hooks), v3.2.1 (closed the File Manager PHP-editing gap that triggered WP.org's first rejection), v3.2.0 (Google Drive remote storage for Site Backup), v3.1.0 (Site Backup itself — the first background-job/wp_cron infrastructure in this codebase), and v3.0.0 (made every previously-paid feature free, deleted the entire licensing/tamper-protection subsystem — everything earlier in this doc describing license gating is historical unless explicitly marked otherwise).)_

What this project is

A ground-up rebuild of the "uiXpress" WordPress admin-theme plugin, relaunched as Aurora Admin. The original plugin's look/feel and feature set are the target, but no original code is reused — all Vue components, PHP classes, and build tooling are freshly written. This lives in aurora-admin-v2/ (the earlier in-place rebrand attempt, aurora-admin-working/, is superseded and no longer the active codebase).

Repo

Now on GitLab (self-hosted): ssh://[email protected]:2289/NixReaper/aurora-wordpress-admin.git (HTTPS also available). Repo root = the contents of aurora-admin-v2/ (admin/, app/, aurora-admin.php), not the whole uixpress/ folder — that folder has a bunch of dead-end attempts (aurora-admin-working, aurora-admin-distribution, aurora-admin-rewrite, aurora-admin-GLM, uixpress) that are debugging history, not part of the project.

.gitignore excludes app/node_modules/ and app/dist/ (build output — regenerate, don't version). To clone on a new machine: add an SSH key to the GitLab account, then git clone the URL above, then cd app && npm install.

Claude Code conversation history does not sync across machines — it's local per project-folder-per-machine. Point a fresh session at this file to get back up to speed instead of relying on prior chat history.

Workflow rules established

• Always verify live in Chrome before declaring a fix done. Use the Chrome MCP tools (tabs_context_mcp, navigate, computer/screenshot, javascript_exec) to inspect real DOM/computed styles rather than guessing from source.
• Zip packaging: on macOS, build via npm run build in app/, rsync the repo (excluding node_modules, .git, /dist) into a scratch staging dir, run php bin/build-integrity-manifest.php <staging-dir>/aurora-admin to generate admin/src/Licensing/integrity-manifest.json into the staged copy (see "Tamper protection" below — this step is new, don't forget it or the shipped zip will have no manifest and Integrity::is_tampered() will treat it as a dev checkout, i.e. never lock anything), then zip -r -X it into dist/aurora-admin-v2.zip — macOS zip produces forward-slash paths natively, no path-separator corruption issue like Windows Compress-Archive/PowerShell had. Always delete the existing zip first (rm -f dist/aurora-admin-v2.zip) — zip -r merges into an existing archive rather than replacing it, so stale entries (old content hashes) silently survive otherwise. If building on Windows again, the old PowerShell System.IO.Compression.ZipFile + .Replace('\', '/') approach from earlier sessions still applies (the manifest-generation step would need a Windows-available PHP CLI too — LocalWP bundles one at ~/Library/Application Support/Local/lightning-services/php-*/bin/*/bin/php on macOS; there's presumably an equivalent bundled binary on Windows).
• Fast local iteration: the test site is LocalWP at /Users/kris/Local Sites/aurora/app/public/wp-content/plugins/aurora-admin. Instead of rezipping + manually reinstalling for every small CSS/JS tweak, hot-patch the built files straight into that install (rm -rf app/dist && cp -R <repo>/app/dist app/dist, or copy individual files like admin/assets/native-dark.css) and just reload the page in Chrome — near-instant feedback loop. Rezip properly (see above) once the change is confirmed, so the zip artifact matches what's live-verified.
• User manually reinstalls the zip from a downloaded/attached copy when actually deploying — the Chrome MCP file_upload tool cannot push arbitrary local files into the browser, confirmed in an earlier session, so that step can't be automated. (Hot-patching, above, sidesteps this for local dev/verification.)
• Old build caching gotcha: WordPress serves whatever plugin files were last installed — if the user says "didn't fix it," suspect a stale zip still installed before suspecting the code. Verify the live script hash via document.querySelector('script[src*="shell"]') + computed styles when in doubt (done successfully this session to prove a spacing change was live).
• Git: local repo config only (user.name/user.email set per-repo, not --global). Commit after each user-confirmed-working change, not before.
• Site under test: http://admin.local/wp-admin/.
• License server access: auroraplugins.com runs on the same cPanel box as the git remote, auroradragon.studio (hostname wyvern.auroradragon.studio), but the git remote's SSH key (~/.ssh/id_ed25519) is scoped to git-only — no shell. Root shell access is a separate dedicated key, ~/.ssh/id_ed25519_auroradragon_root (ssh -i ~/.ssh/id_ed25519_auroradragon_root [email protected]). The license server itself is the aurora-licensing WordPress plugin at /home/aurora/public_html/wp-content/plugins/aurora-licensing/aurora-licensing.php (also present under /home/plugins/public_html/... — a second copy on the same box). If SSH to port 22 suddenly times out, something on the box (fail2ban or similar) appears to re-trigger a short block on rapid repeated connection attempts, including plain nc/probe connections — it clears on its own after roughly 1-2 minutes; wait it out with one careful attempt rather than retrying in a tight loop.

Architecture

• PHP (admin/src/..., namespaced AuroraAdmin\...), bootstrapped from aurora-admin.php (manual require list, dependency order matters), instantiated in admin/src/App/AuroraAdmin.php's constructor.
• Vue 3 app (app/src/...), Vite multi-entry build (app/vite.config.js rollupOptions.input) → manifest.json, read by admin/src/Utility/Assets.php::enqueue() which also walks the manifest's imports chain to pull in shared-chunk CSS. Data reaches each Vue entry via a data-aurora-admin JSON attribute on a mount div (never wp_localize_script).
• Single global stylesheet: app/src/shell/shell-frame.css — all --aurora-* CSS variables (incl. .aurora-dark overrides) and the only rules touching WP structural IDs (#wpcontent, #wpbody-content). No element resets/utility classes leak onto native WP pages.
• Immersive shell (admin/src/Shell/Shell.php + app/src/shell/SiteShell.vue
  • Sidebar.vue + Toolbar.vue + UserMenu.vue): hides native WP chrome, mounts a Vue sidebar/toolbar on every admin page.
  • MenuSerializer.php converts WP's $menu/$submenu globals into JSON for the sidebar's native-menu section — explicitly skips the aurora-admin slug so Aurora's own pages aren't duplicated (they're represented in the sidebar's own branded nav section instead).
  • Sidebar has two sections: the WP-native menu list (icon-chip style, 28×28px rounded icon backgrounds, tight ~2px vertical padding per item) and a bottom "Aurora" section (collapsible, expanded by default, persisted via localStorage['aurora-nav-expanded']) styled like a native WP submenu (plain indented text via .sidebar__sublist/ .sidebar__sublink, no icons) — deliberately matches how e.g. Posts' own submenu (All Posts/Add Post/Categories/Tags) looks, per explicit user request.
  • Sidebar is display:flex; flex-direction:column, split into a .sidebar__scroll (flex:1, scrollable — holds brand/native-list/Aurora section) and a pinned UserMenu footer below it (not part of the scrollable area, so the account card is always visible).
  • UserMenu.vue: floating card that expands upward from a bottom-left trigger (avatar+name+chevron). Card contains: user header (avatar/name/ email), links (Edit Profile → profile.php, Visit site, Site Settings → options-general.php, Sign Out in red). No theme control here anymore — see "Theme system" below; the old light/dark/system 3-way swatch picker and the dark_mode setting it drove are both gone entirely.
  • Old top-right toolbar user-dropdown and sun/moon toggle button are removed — fully replaced by the bottom-left UserMenu.
  • Sidebar is inset, not flush against the browser edge: fixed at top/left/bottom: var(--aurora-sidebar-gap) (16px), fully rounded corners, background: var(--aurora-card-bg) — floats as its own card over the page gradient. --aurora-sidebar-gap is a shared CSS var (shell-frame.css) that the toolbar's left offset and #wpcontent's margin-left both add too, so nothing overlaps when the gap changes.
  • Native-menu accordion: only one WP-native-menu section's submenu is open at a time (Sidebar.vue's openId ref) — expanding one collapses whichever else was open, instead of the list growing indefinitely as more sections get expanded. Was previously a Set of independently toggleable ids (each section remembered its own open/closed state); replaced with a single id so opening any section closes the rest. Starts on whichever section matches the current page (each nav is a full page load in this multi-page admin, so this is computed once at mount, not reactively). The separate "Aurora" branded nav section below it keeps its own independent expand/collapse state (localStorage['aurora-nav-expanded']) — not part of this accordion.

Skinned vs. replaced native pages (important distinction, ask before assuming)

The user explicitly said they didn't want the "skinned" approach used without a real replacement behind it. As of this session, every native list-table screen has been converted — there's no more "just skinned" category left among the pages that had one:

• Actually replaced — the native page never renders; a real custom Vue page (own REST controller, own list/detail UI) takes over entirely: Comments, Installed Plugins, Menu Creator, Admin Notices, Role Editor, Activity Log, Database Explorer, Posts, Pages, Media Library, and Users (the last four all added this session, in that order — Posts first as its own commit/version, then Pages/Media/Users together).
• Deliberately still native (not a "skinning" gap — these are specific screens/actions, not list-tables, and rebuilding them wasn't in scope): the block editor (post.php/post-new.php — dark-themed chrome only, per "Window chrome" above), media-new.php (upload/drag-drop), user-new.php (account creation), individual edit screens reached from a list row (user-edit.php, comment/media edit), Settings/Profile pages, the Site Editor. If a new "why isn't X replaced" question comes up, check whether it's actually one of these deliberate exceptions before treating it as a gap.

PostsData.php+Posts.vue, PagesData.php+Pages.vue, MediaData.php+Media.vue, UsersData.php+Users.vue, and CommentsData.php+Comments.vue all follow one shared REST/Vue pattern:

• A REST controller in admin/src/Rest/ with list (status/type/role + search + pagination, matching native filter tabs) and action endpoints (trash/restore/delete, or just delete for Media/Users, which don't have a trash state in the same way). Capability checks mirror WP core's own for that screen (edit_posts/edit_pages/upload_files/list_users to view; per-item edit_post/delete_post/delete_page/delete_user for actions).
• A Vue page in app/src/pages/<name>/ + entry in app/src/entries/ + registered in app/vite.config.js, visually matching the Comments layout (filter pills, search, table with inline row actions, pagination) — Media is the one exception, using a thumbnail grid instead of a table, since that's what a media library actually needs.

As of this session, how they're mounted onto the page changed. All five used to be a real registered admin.php?page=aurora-admin-X submenu that SubApps::redirect_native_pages() redirected direct visits to on admin_init — this had a proven bug class (see "Key bugs fixed": anything that redirects straight to the native URL, like a plugin's own post-activation redirect, lands on the untouched native page until the sidebar link is clicked again). They're now registered via ScreenHijack::register() (calls collected in admin/src/Pages/HijackedNativePages.php) instead: WordPress fires load-{page}.php before the native screen prints anything, so Aurora hooks that, checks capability/setting, buffers everything with ob_start() on in_admin_header, and on admin_footer discards the buffer (guarded by ob_get_level() > 0, since a screen that exited early via its own wp_die()/redirect may never have opened one) and prints Aurora's own mount div instead. The URL never changes — edit.php, upload.php, users.php, edit-comments.php are still the real URLs, so there's no separate slug to fall out of sync. Settings toggles (modern_posts/ modern_pages/modern_media/modern_users/modern_comments, all default: true) are unchanged and still gate this the same way. Their SubApps::PAGES entries, redirect_native_pages() branches, and MenuSerializer::resolve_url() rewrite branches were all deleted as dead code — the native sidebar links already point at the right (now hijacked) URL with no rewrite needed.

Plugins is the one exception, deliberately left on the old redirect mechanism — plugins.php prints output in a way that can't be cleanly buffered (confirmed by the old uixpress reference plugin's own abandoned attempt at hijacking it the same way). It still has a real aurora-admin-plugins submenu under plugins.php and its own redirect_native_pages() branch in SubApps.php.

This is phase 1 of a larger "full admin takeover" initiative — see the new section below.

Two deliberate scope decisions worth remembering if asked "why doesn't X work":

• Media: replaces the library/browse experience only — uploading (media-new.php, drag-drop/chunked uploads) was left alone entirely, same reasoning as leaving the block editor alone for Posts/Pages.
• Users: deleting a user always reassigns their content to whoever performs the deletion, rather than exposing WP core's "delete this user's content too, or reassign to someone else" choice screen as a one-click REST action — the null-reassign path in wp_delete_user() is much more destructive than is safe to offer with one click, so it's not offered at all.

modern_posts/modern_plugins/modern_comments were themselves each briefly removed earlier in this same session (when they had no implementation behind them) and re-added once real pages existed — if you ever see a settings field described as removed for "describing a feature that didn't exist," check whether it's since been rebuilt before assuming it's still missing.

Full admin takeover initiative (in progress — plugin phase of "DragonPress")

The user's long-term goal: Aurora Admin eventually becomes "DragonPress," a full WordPress core fork built around Aurora. That fork itself is not started and is explicitly out of scope until this plugin-level phase is finished. This phase's goal: when Aurora is active, no native WordPress admin screen should ever be reachable — everything gets replaced or wrapped by Aurora. Full plan lives in the approved plan file (not persisted in repo); summarized here for continuity.

Mechanism: ScreenHijack.php (see above) is the new default for any screen being added. SubApps.php's redirect mechanism is legacy, kept only for Plugins.

Sequencing (see task list each session for live status):

1. ✅ ScreenHijack.php + migrate Comments (proof of concept)
2. ✅ Batch-migrate Posts, Pages, Media, Users
3. ✅ New full_admin_takeover master setting (default false — opt-in, unlike the existing modern_* toggles) + new "admin-takeover" license key gating everything below (this feature key, along with the entire licensing system, was removed in 3.0.0 — see "Licensing" below; the setting itself is unaffected and still opt-in)
4. ✅ Native Settings screens: General/Writing/Reading/Discussion/Permalinks — all 5 hijacked via one shared NativeSettingsPages.php + NativeSettings.vue (one Vue entry, driven by a per-screen field schema), reusing core's /wp/v2/settings REST route for everything except Permalinks (new PermalinksData.php — core has no REST route for rewrite rules). One gotcha worth remembering: core's REST property names don't always match the underlying option name (title→blogname, description→blogdescription, url→siteurl) — get_option() with the REST name silently reads empty; NativeSettingsPages::OPTION_NAME_MAP handles the translation for reads (writes go through the REST route itself, which already knows the mapping). Verified live: all 5 screens render real values on direct visit; at the time, Permalinks' Save also correctly 403'd without a real license (REST-level license check working independently of the page-level gate, per the "don't repeat the File Manager bug" requirement) — moot now that licensing is gone (3.0.0), but the REST route still checks current_user_can() directly rather than relying on the page-level lock alone.
5. ✅ Media Upload (media-new.php) + Add New User (user-new.php) — both Vue-only (no new PHP REST controllers), talking directly to core's /wp/v2/media and /wp/v2/users routes. Free, gated by the same modern_media/modern_users toggles as their list-view companions. Verified live: created a real user end-to-end.
6. ✅ Appearance/Tools batch. Correction to this plan discovered during implementation: Menu Creator (admin/src/MenuCreator/) manages Aurora's own admin sidebar menu, not WordPress's front-end nav menus — despite the similar name, completely unrelated features. Wiring nav-menus.php into it (as originally planned) would have been wrong; built a real, separate Nav Menus replacement instead (NavMenusData.php + NavMenus.vue: create/delete menus, add pages/posts/categories/custom links, reorder/indent items, assign to theme locations). Themes (ThemesData.php + Themes.vue: list/ activate/delete with screenshots) and Widgets (WidgetsData.php + Widgets.vue, deliberately simplified to reordering/moving/ deactivating existing instances — not adding new widget types, same "don't rebuild the real editor" reasoning as the block editor) also shipped. Theme Editor redirects to File Manager rather than getting a second in-browser file editor. Tools/Import-Export/Site Health left un-hijacked as planned (Shell already frames them).
   • Bug caught and fixed while testing: none of these pages' Vue components checked res.ok before using a fetch response — a 403 error body got rendered as if it were real data (iterated as an object in v-for, producing bogus placeholder rows). Fixed in all three; this class of bug is worth checking for in any future page that talks directly to aurora-admin/v1 routes.
   • Environment note: this dev site's 3 installed themes are all block/ FSE themes (Twenty Twenty-Three/Four/Five), none of which register classic nav-menu/widget support — core itself refuses nav-menus.php/ widgets.php ("Your theme does not support...") regardless of this plugin. Verified the REST layer directly instead (full create/add- item/list/delete round trip); Themes was verified fully live since it doesn't depend on theme support.
   • Gap found and fixed later (user reported "missing a lot of features from the original"): Themes.vue's initial build only covered list/activate/delete — no way to browse/install from WordPress.org or upload a theme zip, both present on the native screen. Fixed the same way as Plugins' addUrl/Media's newMediaUrl: link out to native theme-install.php (not hijacked, already has both a WordPress.org browser and an "Upload Theme" button built in) rather than rebuilding either. New "Add New Theme" button in Themes.vue, gated on current_user_can('install_themes'), addThemeUrl passed via AppearancePages.php's existing data_callback.
   • Follow-up (user: "when you click add theme, it closes the menu"): clicking a theme card opens WP core's own fullscreen .wp-full-overlay preview/install modal, which covers the native admin menu on a totally vanilla install too — confirmed not a regression, but reframed it like the block editor window anyway per the user's call. See "Theme installer overlay framing" below for the full writeup — two real bugs (a visibility: hidden inheritance issue and the same over-constrained height: 100% + inset bug the block editor frame already had to work around) were found and fixed along the way.
7. ✅ Profile (profile.php) — user chose: reskin core fields only (ProfileData.php + Profile.vue, using core's /wp/v2/users/me REST route + a small custom password-change route), and fall through to the real native screen entirely whenever a plugin has hooked show_user_profile/personal_options (checked via has_action() at hijack time) rather than attempting to host that plugin's fields — a Vue SPA has no safe way to render arbitrary third-party HTML/JS. Verified live both ways with a test mu-plugin. Password change re-issues the auth cookie after wp_set_password(), same as core's own user-edit.php.
8. ✅ Block Editor reskin (post.php/post-new.php) — the last phase, and deliberately not a Gutenberg content-swap. Extended Shell's already-working block-editor framing (shell-frame.css's .interface-interface-skeleton, windowChrome.js's isBlockEditorPage() + .aurora-winbar--editor dots) with a "← Posts"/"← Pages" breadcrumb, resolved from the post-type-{slug} body class core adds to post edit screens (needed since Posts/Pages no longer have a fixed URL to hardcode after phase 1's migration). Bug caught while testing: the Site Editor shares the block-editor-page body class but has no post-type-* class — the crumb logic now explicitly returns nothing in that case instead of guessing wrong. Verified live on both the post editor (correct crumb) and Site Editor (no crumb, unaffected).

All 9 phases of the "full admin takeover" initiative are now shipped. Network Admin (multisite) was explicitly deferred throughout — the dev/ target site isn't multisite and nothing else in the codebase references it.

Free vs. paid — historical, moot since 3.0.0 (everything below is free now, see "Licensing"): Media Upload/Add User/Profile were always free (1:1 companions to already-free Posts/Pages/Media/Users). Appearance (Nav Menus, Widgets, Themes, Theme Editor redirect) and Native Settings screens were paid ("admin-takeover" feature key) — matched the "power admin tool" bucket (Database Explorer, Role Editor, etc.) at the time. Block editor reskin was always free (chrome around already-free Posts/Pages). Every REST controller in this group still checks current_user_can() directly in its own permission_callback rather than relying on page-level gating alone — that defense-in-depth pattern is unrelated to licensing and remains good practice.

Theme system (rewrite — supersedes the old dark_mode 3-state model)

Went through several rounds of user-directed rework this session, landing on: 10 fixed, named color presets + 2 flat neutrals ("Black & Grey", "White") — no custom color picker, no separate light/dark toggle. Each preset is fully self-contained (its own coordinated backgrounds/cards/borders/text), not a hue applied on top of a shared light/dark base.

• app/src/pages/settings/themePresets.js: themePresets array (10 hue-based presets like { id: 'indigo', label: 'Indigo', hue: 235 }, plus mono and white with an explicit palette object instead of a hue). buildPalette(preset) returns all --aurora-* tokens — for hue presets, computed via HSL ramps; for the two flat presets, returned as-is. resolvePreset(id) looks up by id.
• The main app background (--aurora-app-bg) is a 3-stop gradient, not flat: linear-gradient(135deg, vivid1 0%, vivid2 55%, near-black 100%) — two bright, saturated stops of the same hue family carry most of the bar, dipping to a near-black anchor only in the last stretch. This exact ratio went through several corrections against a competing plugin's ("FleekDash") reference screenshots — a 50/50 dark-to-vivid split reads "washed out", two competing saturated hues ~70° apart reads "muddy"; this formula was the one the user confirmed as clean. If revisiting the gradient formula, re-check against those reference screenshots in the conversation history rather than re-deriving from scratch.
• --aurora-card-bg-deep: a newer token, one step darker than --aurora-card-bg, used only by the Dashboard's AuroraCard.vue. Needed because the Dashboard got its own frame background using --aurora-frame-bg (see "Window chrome" below), which is close in lightness to --aurora-card-bg for most presets — cards would nearly disappear into the new frame without it.
• applyThemePalette(themePresetId) / applyFontFamily(family) (app/src/pages/settings/applyLiveTheme.js) — shared between the settings page's live preview (Settings.vue's watch()) and the real per-page-load application (SiteShell.vue::onMounted). Sets each token via document.documentElement.style.setProperty.
• Google Fonts picker: app/src/pages/settings/googleFonts.js (curated ~70 family list, not the full catalog), searchable dropdown in SettingsField.vue's font-picker field type, applied by injecting a Google Fonts CSS2 <link> tag + setting --aurora-font-family.
• Recurring bug class this session — "independently-painted gradient": several elements (sidebar, toolbar, #wpbody-content on the settings page, #wpbody-content in general) each used to paint their own copy of var(--aurora-app-bg). Since it's a gradient, each element computes it independently over its own bounding box — a narrow tall sidebar and a wide short toolbar get visibly different-looking slices of "the same" gradient, creating seams at their shared edges. Fixed by making html/body the only thing that paints the gradient (background-attachment: fixed so it doesn't scroll away from the fixed sidebar/toolbar), and leaving every other element transparent so that one gradient plane shows through. If a new seam/mismatched-rectangle bug shows up, suspect this pattern first — grep for var(--aurora-app-bg) outside shell-frame.css's html.aurora-ready, html.aurora-ready body rule; it shouldn't be there.
• Dashboard takeover (admin/src/Pages/DashboardTakeover.php + app/src/pages/dashboard/Dashboard.vue): hijacks native index.php via in_admin_header, hides the native .wrap, renders the Aurora dashboard in its place. 12-col grid; cards are single <section class="aurora-card"> elements with inline grid-column: span N (NOT wrapped — component attribute fallthrough for styles was unreliable). Never use unprefixed class names on Aurora components (.card collided with WP core once).
• Settings page (admin/src/Pages/SettingsPage.php + app/src/pages/ settings/Settings.vue): owns the top-level "Aurora Admin" WP admin menu directly via add_menu_page (slug aurora-admin). Two-box layout: .settings__nav (category list) + .settings__content (fields), both boxed/bordered on a darker backdrop. Field schema is declarative in app/src/pages/settings/settingsConfig.js, rendered by app/src/pages/settings/components/SettingsField.vue (types: text, toggle, color, image, repeater, multiselect, segmented). remote-sites was a field type here — removed, see "Remote Site Switcher — removed" below.
• 6 sub-apps (admin/src/Pages/SubApps.php + one PHP feature-class pair each + one Vue page + one Vite entry each) — reachable only via the sidebar's Aurora nav section, not the native WP menu:
  • Registered via add_submenu_page('aurora-admin', ...) (or 'plugins.php' for Plugins) and left registered in WP's native $submenu global — no longer hidden via remove_submenu_page(). An earlier version did call it (the standard register-but-hide trick) but that corrupts WP core's own user_can_access_admin_page() capability lookup, which partly depends on the page still being present in $submenu to resolve its required capability — removing it caused "Sorry, you are not allowed to access this page" for every user, including admins, on Menu Creator/ Activity Log/Role Editor/Comments. Root-caused and fixed this session by deleting hide_from_native_submenu() entirely; duplication in the sidebar's native-menu section is instead prevented in MenuSerializer::serialize() (see below), which has no such side effect.
  • All slugs prefixed aurora-admin-* so Shell::is_own_page()'s existing strpos($page, "aurora-admin") === 0 check covers them for free (full custom dark theme, native-dark.css skipped). MenuSerializer::serialize() skips any submenu slug starting aurora-admin- (in addition to already skipping the aurora-admin top-level slug) so none of them are duplicated in the sidebar's native-menu section — needed because most are parented under aurora-admin (already skipped wholesale) but aurora-admin-plugins is parented under the real plugins.php menu.
  • Each page uses the shared two-pane layout app/src/pages/_shared/AppListShell.vue (generalized from Settings.vue's box-pair CSS) + AppListItem.vue for list rows.
  • Menu Creator (admin/src/MenuCreator/): DB table aurora_admin_menus (name/status/roles JSON/items JSON). Runtime admin_menu hook (priority PHP_INT_MAX) applies published configs matching the current user's roles — hides/relabels native menu items by slug. REST: GET/POST /menus, GET/PUT/DELETE /menus/:id, GET /menus/native-items (real WP menu list to build the editor from, via MenuSerializer::serialize()). Reordering is stored (order field) but not yet applied at runtime — CRUD + hide/relabel only so far.
  • Admin Notices (admin/src/Notices/): DB table aurora_admin_notices (title/message/type/roles JSON/pages JSON/dismissible/active). Runtime admin_notices hook renders active, role/page-matching rows via real WP notice markup. REST: GET/POST /notices, PUT/DELETE /notices/:id.
  • Role Editor (admin/src/Roles/): no custom table — wraps core get_editable_roles()/WP_Roles directly. Hard-codes the 5 default roles (administrator, editor, author, contributor, subscriber) as delete-protected (WP has no built-in check for this). REST: GET/POST /roles, PUT/DELETE /roles/:slug.
  • Activity Log (admin/src/ActivityLog/): DB table aurora_admin_activity_log. Hooked to save_post (guards wp_is_post_autosave()/wp_is_post_revision()), before_delete_post, user_register, profile_update, wp_login, activated_plugin, deactivated_plugin, switch_theme, update_option_aurora_admin_settings. REST: GET /activity-log?action_type=&object_type=&search=&page=.
  • Plugins (admin/src/Rest/PluginsData.php + app/src/pages/plugins/Plugins.vue): custom plugin management list (activate/deactivate/delete), also using AppListShell.vue.
  • Comments (admin/src/Rest/CommentsData.php + app/src/pages/comments/): newest sub-app, edit_posts-gated (not manage_options like the others). SubApps::redirect_native_pages() (admin_init) redirects the native edit-comments.php (when hit with no ?page= param, i.e. a direct nav or an old bookmark/menu link) to admin.php?page=aurora-admin-comments. MenuSerializer::resolve_url() also maps the edit-comments.php slug straight to the Aurora URL so the native-menu-derived sidebar entry (for users who can edit_posts but not manage_options, so don't see the Aurora nav section) still lands on the Aurora page. The Dashboard's comments card (DashboardData.php's listUrl) was updated to point at the same Aurora URL instead of the native one.
  • Database Explorer (admin/src/DatabaseExplorer/): no custom table — reads real $wpdb schema. GET /db-tables (SHOW TABLE STATUS), GET /db-tables/:table (columns + paginated rows — table name validated against the real $wpdb table list before use, never interpolated unchecked), POST /db-query (raw query runner, hard-restricted server-side to queries starting SELECT/SHOW/DESCRIBE/EXPLAIN, single-statement only, auto-LIMIT 200 if none given). All 3 endpoints manage_options-gated. Identifier allow-listing + backtick-escaping is the actual safety boundary ($wpdb->prepare() only binds values, not identifiers).
  • All 5 backend classes + SubApps.php are require'd in aurora-admin.php and instantiated in AuroraAdmin.php.
• Settings persistence: admin/src/Options/Settings.php — partial-payload save via merge_on_save() sanitize callback (merges into existing option, doesn't overwrite). Settings::get_safe() strips license_key for use on non-admin-gated pages; Settings::get() (full) only used on the manage_options-gated settings page itself. Settings::remove_retired_keys() (hooked to init alongside register()) actively deletes settings keys for features that no longer exist — currently just the removed Remote Site Switcher's remote_sites/remote_site_switcher_capability, since remote_sites stored a real secret (application passwords) that's no longer read anywhere.
• Global search: app/src/shell/components/SearchModal.vue, Ctrl+K, debounced wp/v2/search REST calls, gated on disable_global_search setting.
• Scheduled content: app/src/pages/dashboard/cards/ScheduledContent.vue calendar cells (squares, date top-left, count centered) are clickable — navigate to edit.php?post_status=future&aurora_day=YYYY-MM-DD if that day has scheduled posts, else show a toast ("no scheduled content"). Server side: admin/src/Posts/ScheduledDayFilter.php filters the edit.php query via pre_get_posts and prints an info notice.
• Analytics: admin/src/Analytics/Analytics.php (first-party pageview tracker, own DB table wp_aurora_admin_pageviews, bot detection, gated on enable_analytics/track_admins settings) + admin/src/Rest/AnalyticsData.php (aggregation REST endpoint: totals, series, device/referrer/country breakdowns, bounce rate, active users).
• White label: admin/src/WhiteLabel/WhiteLabel.php — custom favicon, rename plugin in Plugins list, rename top-level menu item, gettext find/replace via text_replacements setting.
• Native page dark styling: admin/assets/native-dark.css (large static sheet, all rules gated html.aurora-dark.aurora-ready, scoped under #wpbody-content) + admin/assets/native-enhance.js (progressive JS enhancement — currently only enhanceUpdates(), which groups the flat Updates page sections into .aurora-native-card wrapper divs on body.update-core-php). This session also extended coverage to media/ thickbox modals, plugin/theme card grids, and the plugin-search filter bar (all previously untouched, so still native white regardless of theme). Known gap: the plugin "More Details" popup renders inside an <iframe> pointing at a separate WP page — CSS can't reach into it; would need JS injection into the iframe's own document if that's ever worth fixing. This session also added dark-theme rules for the block editor's own chrome (.editor-header/.edit-post-header, .interface-interface-skeleton__sidebar and its nested .components-panel/.editor-post-status/ .interface-complementary-area-header) — found by inspecting the real screen via computer-use and drilling into nested elements' computed styles, since .interface-complementary-area (nested inside the sidebar) had its own explicit white background the outer rule didn't reach, leaving a white patch below the Tags panel until it was targeted directly. The actual post content canvas is deliberately left untouched (WYSIWYG, matches the front-end).

Window chrome (macOS-style title bar + taskbar)

Added earlier this session, user-requested after seeing a competing plugin's demo; extended later the same session to cover the block editor and the Site Editor, and the taskbar was rewritten to support multiple minimized windows. Every page gets a traffic-light title bar; minimizing persists across a full page navigation via a taskbar.

• app/src/shell/windowChrome.js: initWindowChrome(adminUrl), called unconditionally from SiteShell.vue::onMounted (no longer skipped on the block editor — that special case was removed once the editor got its own handling). Three cases, checked in priority order:
  1. Dashboard (#aurora-admin-dashboard-root present) — wraps the bar + the dashboard root in a new .aurora-dashboard-frame div, giving it the same card-frame treatment (--aurora-frame-bg, border, radius) every other page gets from #wpbody-content itself.
  2. Block editor / Site Editor (isBlockEditorPage(): body has block-editor-page, or the path ends /post.php or /post-new.php — site-editor.php also gets block-editor-page on its body, so this already covers it with no JS change needed) — appends a .aurora-winbar--editor bar (dots only, no bar surface) directly to document.body, since neither editor's real content container is #wpbody-content.
  3. Everything else — native WP pages and all of Aurora's own Vue pages, inserted as the first child of #wpbody-content.
• Red (close): window.location.href = adminUrl.
• Green (maximize): toggles html.aurora-maximized — hides .sidebar/ .toolbar, zeroes #wpcontent's margin-left and the editor frame's inset, so content fills the whole browser window. Toggle again (or minimize) to restore. Nothing persisted — resets on next page load.
• Yellow (minimize): on the Dashboard itself, toggles html.aurora-minimized which just collapses #aurora-admin-dashboard-root down to the bar in place (nowhere further "home" to send it). On every other page, calls taskbar.js's addMinimizedWindow(title, url) then navigates to the dashboard.
• Taskbar rewritten from a single sessionStorage slot to a list (app/src/shell/taskbar.js): minimizing a second page used to silently overwrite the first one's entry, so only the most recent minimize ever showed up. Now getMinimizedWindows()/addMinimizedWindow() (dedupes by URL)/removeMinimizedWindow(id) operate on an array under sessionStorage['aurora-minimized-windows']; SiteShell.vue v-fors over it, rendering one .aurora-taskbar__item pill per entry inside a transparent, floating .aurora-taskbar bar (inset by --aurora-sidebar-gap on all exposed edges, rounded, its own box-shadow — went through a design iteration from a small centered pill back to full-length per explicit user correction, keeping only the pill shape on the individual items). Each item is independently restorable/closable. currentPageTitle() prefers the page's own on-screen <h1> (#wpbody-content h1, #aurora-admin-dashboard-root h1) over document.title, since WP's title-tag generation came up empty for Aurora's sub-app pages back when they were still remove_submenu_page()'d (see the sub-apps permissions bug above) — document.title is still the fallback for pages where that isn't an issue.
• Content-behind-taskbar fix: html.aurora-has-taskbar no longer just adds margin-bottom (that only guarantees clearance once scrolled to the very bottom — content taller than the viewport still rendered underneath the fixed taskbar on first paint). Instead it caps #wpbody-content's/ .aurora-dashboard-frame's own height via max-height + overflow-y: auto, same principle as the toolbar's reserved space at the top. This appeared to do nothing at first — #wpbody-content's base rule sets min-height: calc(100vh - toolbar-h - 40px), and per spec min-height always wins over a smaller max-height; fixed by adding min-height: 0 to the taskbar-specific override.
• Universal content-area height cap (this session): the taskbar-only max-height/overflow-y: auto treatment above is now applied to #wpbody-content unconditionally (not just when html.aurora-has-taskbar is set), capped to calc(100vh - toolbar-h - 40px). Several native and Aurora pages with a lot of content (Add Plugins, Add User, Profile, Appearance > Fonts, the file editors, every Settings page, Activity Log, Database Explorer, Comments) used to grow taller than the viewport and force the whole document to scroll — janky since the sidebar/toolbar are fixed, so scrolling just moved the content away from them with a lot of dead space. Now the content card's own box is capped and scrolls internally, same as the toolbar/taskbar reservations already did.
  • Scroll-anchoring bug this surfaced: making #wpbody-content a real scroll container exposed a second, unrelated bug on Add Plugins — its plugin-card grid renders via JS well after first paint, inserting a lot of content above whatever was already visible in the now-scrollable box. Chrome's scroll anchoring "corrects" for that by silently jumping scrollTop down to compensate, so the page loaded already scrolled ~1700px into the content instead of at the top. Fixed with overflow-anchor: none on #wpbody-content (and the taskbar/dashboard- frame variant) — the standard fix for this class of bug, opting the container out of anchoring entirely.
  • Phantom document-level scrollbar: independently, Add Plugins also left the outer <html>/<body> scrollable with ~1200px of empty dead space below the frame, even though every element inside #wpbody-content measured as properly capped to the viewport — narrowed down to some interaction between the plugin grid's async rendering and the browser's own scrollable-overflow bookkeeping (root cause not fully pinned down; forcibly shrinking or hiding #wpbody-content reduced but didn't eliminate it, and no single oversized/mispositioned descendant could be found). Since the intended design already has the sidebar/toolbar fixed and every page's real content scrolling internally within its own frame, the document itself was never supposed to scroll at all — fixed directly by adding overflow: hidden to html.aurora-ready/body, which removes the dead scroll space outright regardless of what was causing it.
• Block editor / Site Editor framing: neither editor renders inside #wpcontent's normal box model — each has its own fixed, full-viewport root (.interface-interface-skeleton itself on post.php/post-new.php; #site-editor on site-editor.php, where .interface-interface-skeleton is merely position: relative, nested inside it — a reset rule puts the nested skeleton back to a plain unpositioned child so the two frames don't stack). html.aurora-ready .interface-interface-skeleton, html.aurora-ready #site-editor in shell-frame.css frames whichever is the real fixed root with the same insets/background/radius/shadow treatment #wpbody-content gets elsewhere, plus padding-top: var(--aurora-editor-winbar-h) to reserve a strip for .aurora-winbar--editor's dots and overflow: hidden so the rounded corners actually clip the editor's own white canvas background (border-radius alone doesn't clip children). Known CSS-over-constraint gotcha: WP core's .edit-site { height: 100vh; } class (present on #site-editor) means top, height, and bottom are all specified on that box at once — per spec this is over-constrained and bottom silently gets recomputed from top + height instead of honoring an explicit value, which is why the frame initially ran past the intended bottom inset despite bottom: 24px !important being set. Fixed by adding height: auto !important to the same rule so top/bottom actually determine the box size again. If a future feature needs to reach either editor's own chrome, the real containers are .interface-interface-skeleton (post editor) or #site-editor (Site Editor) — don't assume the normal #wpbody-content page structure there.
• Shell.php::is_enabled() no longer excludes the Site Editor screen (site-editor used to be in the skip list alongside customize) — it turns out to be built on the same @wordpress/interface package as the block editor (body.block-editor-page is present on both), so the existing block-editor handling covers it once #site-editor is framed.

Native Settings field-parity completion (Writing/Reading/Discussion)

Follow-up to the full-plugin audit above: Writing/Reading/Discussion had much thinner field coverage than Permalinks did before its presets fix — raw numeric IDs where native WP has dropdowns, and Discussion exposing only 2 of ~15 real settings. Investigated each screen against WP core's register_initial_settings() (wp-includes/option.php) rather than guessing: Writing and Reading were actually already using 100% of what core's REST settings schema exposes for those two groups (use_smilies was the one field core registers that had never been added) — the remaining gap there was pure UX (raw IDs instead of dropdowns). Discussion was different: core's schema genuinely only registers default_ping_status/default_comment_status for that option group, nothing else — the other ~13 fields (moderation, threading, notification emails, avatars) have no REST route in WordPress core at all, so exposing them required a new dedicated controller, the same situation Permalinks was already in for permalink_structure.

• NativeSettingsPages.php gained three helpers — category_options()/post_format_options()/page_options() — that build real {value, label} option arrays from get_categories()/ get_post_format_strings()/get_pages(), reusing the existing generic "select" field type (SettingsField.vue already supported it, populated with static arrays for start_of_week etc. — no new rendering code needed, just real data instead of hardcoded options).
• New showIf: {key, equals} field property, checked in a visibleFields computed in NativeSettings.vue — lets any field declare "only show once another field's value matches", used for Reading's page pickers (only once show_on_front === 'page') and throughout Discussion's now-much-longer field list (e.g. thread depth only shown when threading is enabled). Generic, not special-cased per screen.
• New admin/src/Rest/DiscussionData.php — mirrors PermalinksData.php's raw-get_option()/update_option() pattern but for ~24 keys instead of one, validated against an explicit per-type allowlist (BOOLEAN_KEYS/ INTEGER_KEYS/TEXTAREA_KEYS/ENUM_KEYS consts) so the route can never be used to write an arbitrary WP option. NativeSettings.vue's Permalinks-only isPermalinks special case became a small per-screen endpoint map (isPermalinks/isDiscussion) rather than growing more one-off branches.
• New textarea field type in SettingsField.vue (multi-line plain text) for moderation_keys/disallowed_keys — nothing else on any settings screen needed one before this.
• Verified live end-to-end, not just visually: dropdowns populate with real category/format/page data, showIf conditionals actually show/hide on interaction (toggled show_on_front and watched the page pickers appear), and — the one check that actually proves the save path works, not just the UI — toggled a real Discussion setting off, saved, did a full page reload, and confirmed the change was still off (not an optimistic-UI illusion), then reverted it.

Theme installer overlay framing

User clicked "Add New Theme" > a theme card and reported "when you click add theme, it closes the menu. something is wrong." Investigated live: clicking a theme opens WP core's own .theme-install-overlay (a .wp-full-overlay component, shared with the Customizer), a genuine fullscreen fixed overlay by design — confirmed this covers the native admin menu on a completely vanilla WordPress install too, not something this plugin broke. Asked the user whether to leave it native or frame it like the block editor window; they chose framing despite the Gutenberg-CSS-conflict-style risk being called out.

• app/src/shell/shell-frame.css: .theme-install-overlay (only this specific class — not .wp-full-overlay generally, so customize.php is untouched/out of scope) gets the standard Aurora inset box. The overlay's two children, .wp-full-overlay-sidebar and .wp-full-overlay-main, are independently position: fixed/absolute — fixed descendants don't move just because their ancestor's own box moved (fixed is relative to the viewport unless an ancestor creates a new containing block), so each needed the identical left/top/bottom math applied directly, not inherited from the overlay's own reframing. margin-left on .expanded/.collapsed duplicates WP core's own three responsive breakpoints (themes.css) with Aurora's frame offset added on top, preserving the sidebar collapse/expand slide animation as-is.
• Two real bugs found and fixed, not obvious from the CSS alone:
  1. Opening the overlay adds body.full-overlay-active, and WP core's own CSS sets body.full-overlay-active { visibility: hidden } with only the overlay itself (#customize-container, .theme-install-overlay) set back to visible. Aurora's entire shell root is a descendant of body, so it inherited that hidden visibility too — this is what silently erased the sidebar/toolbar entirely (not "covered by a higher z-index", genuinely invisible) rather than the milder "overlay covers it" behavior the user was actually reporting. Root-caused by walking the DOM ancestor chain checking each element's own visibility in devtools, then grep-searching loaded stylesheets for rules matching body with a visibility declaration — found body.full-overlay-active { visibility: hidden } in WP core's own themes.css. Fixed with one override: body.full-overlay-active #aurora-admin-shell-root { visibility: visible !important; } — descendants can locally re-enable an inherited hidden value, so this doesn't need to touch anything else under body (which stays hidden, harmless, since it's covered by the overlay's insets anyway).
  2. The overlay's own height: 100% (WP core) plus this session's added top+bottom insets is the exact over-constrained-box bug already documented above for .interface-interface-skeleton/#site-editor — same height: auto !important fix, same root cause (per spec, bottom silently loses to an explicit height when both are set alongside top).
• The winbar (traffic-light dots) needed a persistent MutationObserver, not a one-shot insert — two reasons, both confirmed by testing rather than assumed: (1) .theme-install-overlay isn't in the DOM at initial page load (WP core's Backbone view creates it lazily on the first theme click), so initWindowChrome()'s normal one-time-at-mount check always missed it; (2) every subsequent theme selection (including the prev/next arrows inside the overlay) fully re-renders the overlay's own contents, which wipes out anything previously inserted into it — the bar was confirmed present after the first click, then gone after selecting a second theme. windowChrome.js's watchForThemeOverlay() keeps an observer running for the page's whole lifetime with an idempotent "insert if missing" callback, rather than disconnecting after the first successful insert.
• Verified live end-to-end (not just visually): opened via real clicks on the grid (not just direct URL navigation to ?theme=slug, which behaves slightly differently), switched themes with the prev/next arrows, closed and confirmed the sidebar/toolbar return correctly with no lingering state, checked the browser console for errors at every step.

Sidebar accordion: hidden native "child" screens

Separate follow-up bug on the same feature, user-reported precisely: expand Appearance, click "Add New Theme", and the Appearance section collapses while "AURORA" (the branded nav at the bottom) opens instead — different from the overlay-covering-the-sidebar issue above, this one is about which accordion section stays open. Root cause: Sidebar.vue's accordion picks the open section by matching the current URL against each menu item's own submenu array (scraped from WP's $submenu global by MenuSerializer::serialize()) — but theme-install.php/media-new.php/ user-new.php etc. are deliberately absent from $submenu (native WP's own left menu doesn't list "Add New Theme" as a link either, only "Themes"/"Customize"/"Editor"), so nothing ever matched and the accordion fell through to its Aurora-expanded default every time.

Fix reuses WP core's own solution to this exact problem rather than hardcoding a list: these pages set a $parent_file global directly in their own PHP (theme-install.php → 'themes.php', media-new.php → 'upload.php', user-new.php → 'users.php') — the same mechanism core uses for its own native menu highlighting. Shell::print_mount() reads it (global $parent_file) and passes it through as activeParentFile; Sidebar.vue's isSectionActive() now also matches on item.id === activeParentFile, alongside the existing exact-URL checks. General fix — covers any current or future screen using this WP core convention, not just the three confirmed live (Appearance/Themes, Media, Users).

Remote Site Switcher — removed

Was a Pro feature: Settings > General let you store {url, username, app_password} for other WordPress sites, gated a toolbar dropdown behind a configurable capability + license check, and clicking an entry just opened that site's /wp-admin/ in a new tab. User asked what it did; on inspection, nothing ever actually consumed the stored username/ application password — no REST calls to the remote site, no proxying, no SSO. It was pure UI scaffolding for a cross-site feature that was never built on top of it, so removing it lost zero real functionality (the "switcher" was just a bookmark list either way). Decided to remove rather than build out the unused half, since the user said it "doesn't really do much for the software."

Removed: the remote_sites/remote_site_switcher_capability settingsConfig.js fields, the remote-sites field type + its helpers in SettingsField.vue, the toolbar dropdown + canSwitchSites in Toolbar.vue/Shell.php, the "remote-site-switcher" key in License::PAID_FEATURES, and the secret-stripping logic in Settings::get_safe() (no longer needed with remote_sites gone). Added Settings::remove_retired_keys() (hooked to init) to actively delete remote_sites/remote_site_switcher_capability from any install that already saved them — leaving a stored application password inert in the database indefinitely isn't good practice even though nothing reads it anymore.

Role Editor capability tooltips

Added after the user asked directly: "what is level_0? what is level_1? None of these things are defined." Every capability checkbox in RoleEditor.vue now has a small info icon with a hover tooltip, driven by app/src/pages/role-editor/capabilityDescriptions.js — a static lookup covering all ~55 WordPress core capabilities plus a regex special-case for level_0–level_10 (the pre-2.0 legacy "user level" system WordPress still assigns to every default role purely for backward compatibility with old themes/plugins checking current_user_can('level_N') directly — core itself hasn't checked a level in years, so these are safe to ignore/leave alone, just unexplained without this). Anything not in the dictionary (e.g. a capability another plugin added) falls back to a generic "custom capability, not part of WordPress core" message rather than showing nothing. No backend change — this is pure static documentation data, looked up client-side.

Licensing — removed entirely in 3.0.0 (2026-07-06)

Aurora Admin previously had a full licensing/monetization system (a License.php gate every paid feature funneled through, real integration with the aurora-licensing license server on auroraplugins.com, a beta tester program, a dev-mode license-override toggle). All of it is gone.

The user decided to give Aurora Admin away free on the WordPress.org plugin repository, so every feature that was previously paid — Role Editor, Activity Log, Database Explorer, File Manager, Analytics, White Label, Full Admin Takeover, Media Folders — is now simply available to everyone, no key required. Deleted: admin/src/Licensing/ entirely (License.php, Integrity.php — the file-tamper-detection system that only existed to protect license gating from bypass), bin/build-integrity-manifest.php, UpgradeNotice.vue, locked-feature.js, the License key field, the dev-mode "Simulate active license" toggle, and every lock badge/gating check across ~20 PHP files and ~8 Vue files. license_key and dev_license_override are actively purged from any site's stored settings on upgrade (Settings::remove_retired_keys()), same pattern used for the earlier Remote Site Switcher removal. Report a Bug still works, now via a direct call to the feedback endpoint instead of going through the license-status layer.

This is a clean split from the commercial auroraplugins.com service (real beta licenses, Pro purchases, the license server itself) — that system is untouched and unaffected, it's simply no longer wired into this codebase. If any of the old implementation detail is ever needed again (the real license-server REST contract, the beta-tester-license flow, etc.), it's preserved in git log up through the 2.27.0 tag/commit — not reconstructed here.

Report a Bug (new free page, added 2026-07-05)

A real WordPress admin page (aurora-admin-bug-report), registered in SubApps::PAGES exactly like Menu Creator/Admin Notices — free, no license feature key. Sidebar entry added in Shell::aurora_nav().

• app/src/pages/bug-report/BugReport.vue: single free-text textarea plus a read-only diagnostics block auto-filled from server data (plugin version, WP version, PHP version, active theme). Posts to aurora-admin/v1/bug-report.
• admin/src/Rest/BugReportData.php: thin REST controller, validates the description isn't empty and posts it directly (via wp_remote_post) to the feedback endpoint on auroraplugins.com — no longer goes through a license-status layer (rewritten in 3.0.0 when License.php was deleted; previously called License::submit_bug_report(), which reused the same call() helper validate()/activate() used).
• License server (aurora-licensing plugin, not this repo): has a wp_aurora_bug_reports table and a public POST /report-bug REST route doing a plain wpdb->insert. No admin UI for reviewing reports yet — query the table directly via wp db query; worth building a dashboard if report volume ever justifies it.
• Gotcha hit during the build: this codebase has no autoloader — every PHP class is manually required in aurora-admin.php. Forgetting to add the new BugReportData.php require there caused a Class ... not found fatal on first load. If adding another new class file, don't forget this step (mirrors the existing require list right above new AuroraAdmin\ App\AuroraAdmin();).
• Verified live end-to-end against the real production server (not mocked): submitted a real report through the actual page, confirmed it landed in wp_aurora_bug_reports with all fields populated correctly, then deleted the two test rows by exact ID (a broad LIKE-based cleanup query was correctly blocked by the safety classifier for being too wide against a live production table — redid it scoped to specific IDs).

The bullets below describe the pre-3.0.0 license-gating mechanics (per-page feature keys, the shared UpgradeNotice.vue prompt, sidebar lock badges, etc.) — all removed; see "Licensing" above. Kept only for the one bug fix still relevant today:

• Bug fix surfaced while testing this: RolesData.php's REST callback called get_editable_roles() unqualified, which 500'd every time — that function lives in wp-admin/includes/user.php, which WP only auto-loads for real wp-admin page requests, not REST API requests. Fixed with a function_exists guard + require_once before the call. Unrelated to licensing, just happened to surface while verifying Role Editor's unlock path.

Tamper protection — removed in 3.0.0

Existed solely to stop someone stripping the license check out of a distributed copy. With licensing gone entirely (see "Licensing" above), there's nothing left to protect — Integrity.php and bin/build-integrity-manifest.php were deleted along with License.php. Full historical detail (how the sha256 manifest worked, the "re-lock paid features only" design decision, live verification steps) is in git log up through the 2.27.0 commit if this kind of protection is ever wanted again for some other purpose.

Database Explorer — REMOVED from Aurora Admin in 3.5.0, now a separate plugin

Extracted entirely out of this codebase in 3.5.0, following the exact same pattern as File Manager's 3.4.0 extraction (see that section immediately below for the fuller precedent). Unlike File Manager, this extraction was proactive, not reactive — WordPress.org hasn't rejected Aurora Admin over Database Explorer specifically, but direct database-query tooling (a table browser plus a free-form SELECT/SHOW/DESCRIBE/EXPLAIN query runner) is the same class of risk WP.org's Plugin Directory review already flagged file-management functionality for, so it was pulled out ahead of a likely third rejection rather than waiting for one.

admin/src/DatabaseExplorer/DatabaseExplorerData.php (REST, manage_options- gated, read-only statement-type + single-statement guards, identifier validation against a live SHOW TABLES list since identifiers can't go through $wpdb->prepare()'s value placeholders) and app/src/pages/database-explorer/DatabaseExplorer.vue (built on the shared AppListShell/AppListItem list-detail layout, both also copied into the new plugin since it has no shared shell to depend on) moved, unmodified in behavior, into a new sibling plugin: aurora-database-explorer (aurora-database-explorer.php, own bootstrap, own REST namespace aurora-database-explorer/v1, own Vite build, own light-only base-theme.css subset of the --aurora-* palette). Removed from Aurora Admin: the DatabaseExplorerData require/wiring in aurora-admin.php/ AuroraAdmin.php, the aurora-admin-database entry in SubApps.php and Shell::aurora_nav(), the database-explorer Vite build entry, and a now-stale doc-comment cross-reference in DbDumper.php.

admin/src/Rest/CompanionPluginData.php — previously a single class hardcoded to File Manager — was generalized into a PLUGINS config array keyed by slug (file-manager, database-explorer), with the REST route registration, status()/install() logic, and Plugin_Upgrader wrapping all made slug-generic. Adding a third companion plugin later is a config-array entry, not new route-registration code. The Settings → Add-ons screen (settingsConfig.js) now lists both companion plugins; SettingsField.vue's companion-plugin field type was already fully generic (driven by field.statusEndpoint/field.installEndpoint/ field.manageUrl), so no Vue changes were needed there beyond the new config entry.

Verified live: built (npm run build, clean), PHP-linted (clean), rsynced into the LocalWP test site, activated via a direct WP-bootstrap script (browser cookie-based activation isn't practical for headless verification). Since the admin's browser session couldn't be driven directly, verification used a server-generated WordPress auth cookie (wp_generate_auth_cookie(), 'auth' scheme — this site is plain HTTP, not HTTPS, so the 'secure_auth' scheme WP prefers under SSL doesn't apply) and a real curl request against the live site: confirmed HTTP 200, the aurora-database-explorer-root mount div present, the correct built script filename referenced, and no PHP warnings/fatals in the response body. The plugin's REST namespace (aurora-database-explorer/v1) was confirmed registered via /wp-json/'s route index. A full authenticated REST nonce round-trip (actually calling /db-tables with a valid X-WP-Nonce) was attempted but not completed — a nonce generated outside a real cookie-validated session doesn't carry the right session token, so rest_cookie_invalid_nonce was returned; not pursued further given this is a direct, unmodified copy of already-shipped, already-working logic (only the namespace and REST route prefix changed), and the companion CompanionPluginData REST routes were separately confirmed present in the main Aurora Admin site's own route index.

Deployment gap, not yet done (same as File Manager's): the aurora-database-explorer.zip is not yet hosted at https://aurora.auroradragon.studio/aurora-database-explorer.zip — a real production-server deploy that needs the user's go-ahead, same as any other production deploy. Until deployed, the Add-ons "Install & Activate" button for Database Explorer will fail with a fetch error. Also outstanding: resubmitting the rebuilt Aurora Admin zip to WP.org — the user's action, not something to do unprompted.

File Manager — REMOVED from Aurora Admin in 3.4.0, now a separate plugin

Extracted entirely out of this codebase in 3.4.0 — see the new final subsection below for why and how. Everything else in this section is historical: it describes File Manager's design and history while it was part of Aurora Admin (v3.0.0 through v3.3.2). None of the file paths this section references (admin/src/FileManager/, app/src/pages/file-manager/) exist in this repo anymore — the equivalent code now lives in the sibling aurora-file-manager repo, unmodified in behavior from what's described below.

Added originally in an earlier session — the user has the "WP File Manager" plugin (elFinder- based) installed on the test site and asked for equivalent functionality built into Aurora, as a fresh implementation rather than embedding elFinder. admin/src/FileManager/FileManagerData.php (REST) + app/src/pages/file-manager/FileManager.vue (entry file-manager.js), registered as aurora-admin-file-manager in SubApps.php (parented under aurora-admin like Menu Creator/Role Editor, not a native-page replacement — there's no native WP file browser to redirect from).

• Root is ABSPATH (the WordPress install directory), same as the reference plugin. Capability is manage_options everywhere, no exceptions — by far the highest-risk surface in the plugin (arbitrary filesystem read/write on the site's own PHP).
• Path containment: every client-supplied path goes through resolve_path(), which realpath()s the candidate and checks the resolved path is still inside the root — never a raw string check against "../", since that alone doesn't catch symlinks or encoded traversal. New files/folders (which don't exist yet, so realpath() would return false) resolve their parent directory instead, then just sanitize the new name component (wp_basename(), reject empty/./../ control characters).
  • Verified live via direct REST calls: ?path=../../../etc → 404 (correctly rejected); creating/renaming to a blocked extension → 400; deleting the root path itself → 400; a full create-folder → create- file → write → read → rename → recursive-delete round trip all succeeded and left no trace afterward.
• Blocked extensions on upload/create/rename (FileManagerData::BLOCKED_EXTENSIONS): .php and friends, .cgi, .sh, .exe, etc. — the single most important control, since uploading a webshell through a "file manager" is the classic way this class of feature gets exploited. A separate BINARY_EXTENSIONS list (images/archives/media/fonts) plus a 2MB size cap keeps the text editor from trying to open something it shouldn't.
• WordPress.org rejected the 3.1.0 submission over this exact feature (2026-07-11): BLOCKED_EXTENSIONS was enforced on create/upload/rename, but not on opening/saving an existing file — a manage_options user could open a theme's .php file in the CodeMirror editor (which has first-class PHP syntax highlighting, @codemirror/lang-php) and save it back with immediate execution effect on the next request. The reviewer's rejection language ("script insertion... PHP is even more complicated... WordPress itself allows you to lock people out of being able to edit theme and plugin files directly via DEFINES") pointed straight at this — it's functionally the same capability as WP core's own Theme/Plugin editor, which core lets hosts disable via DISALLOW_FILE_EDIT specifically because of this risk class. Fixed in 3.2.1: is_editable() (used by both read_file() and write_file(), and by the isEditable flag list_dir() returns per item, which the Vue UI's Edit button/context-menu/double-click all gate on) now also excludes BLOCKED_EXTENSIONS, and additionally returns false outright when DISALLOW_FILE_EDIT is defined and true. Every mutating endpoint (create/upload/rename/delete/write/copy/move/bulk/trash restore-delete-empty) now also checks a new mods_allowed() helper against DISALLOW_FILE_MODS — the broader host-level file-modification lockdown WordPress core's install/update/delete flows already respect. Browsing, downloading, and file-info/preview are unaffected — this only closes the write-to-existing-executable-file gap. No client-side Vue changes were needed; the UI already fully gated on the isEditable server flag.
• Deliberately not built (scope decisions): zip/unzip (extraction has its own well-known vulnerability class — zip-slip, where a crafted archive's entries escape the extraction directory), chmod/permissions editing (too easy to accidentally lock yourself out or open a real hole).
• Feature-parity pass (later session, prompted by the user comparing against WP File Manager): added everything else on that gap list that didn't carry zip/chmod's security risk — move/copy between folders (copy_item/move_item, with a same-descendant guard so a folder can't be moved/copied into itself, and " (2)"-style auto-renaming on name collision rather than overwriting), multi-select bulk actions (one /file-manager/bulk endpoint reusing the exact single-item logic for trash/move/copy so bulk can't drift from the single-item buttons), a trash instead of permanent delete (flat UUID-named folder under wp-content/uploads/aurora-admin-trash/ + a JSON manifest tracking original path/name/type/deleted-at — chosen over encoding the original path into the trash filename itself, which gets fragile with nesting/ special characters/length limits), a lazy-loaded folder tree sidebar (reuses the existing list endpoint filtered to directories, no new route needed, also doubles as the move/copy destination picker), a read-only file info panel (/file-manager/info — permissions/owner/dates/mime; directory size computed on-demand for this one call, not for every row in the main list), image thumbnails (/file-manager/preview — inline, extension-gated, size-capped, no server-side resizing), and drag-and-drop upload + sortable columns (both frontend-only). Verified live: multi- select, info panel, and a full create→trash→restore round trip through the actual UI; copy/bulk-trash/empty-trash verified directly against the REST endpoints. Zip/unzip and chmod remain deliberately unbuilt.
• UI reworked again, same session: user pointed at WP File Manager's actual toolbar screenshot and asked for the same layout. Replaced the header-buttons + per-row-Actions-column split with one unified toolbar (back/forward/up history, new folder/file, upload, copy/cut/paste, rename, trash, download/edit/info, list/grid toggle, fullscreen, search) — buttons enable based on current selection. Move/copy switched from the destination-picker modal to clipboard-style copy/cut/paste (select → Copy/Cut → navigate anywhere → Paste), matching how elFinder- based file managers actually work; still calls the same /file-manager/bulk endpoint underneath. Added a grid view and fullscreen toggle. Verified live: copy→navigate→paste, list/grid toggle, back navigation.
• Right-click context menu + real code editor (same session, user asked directly): context menu mirrors the toolbar's own functions exactly (no separate logic to drift out of sync) — right-click an unselected item to select just it, right-click within an existing multi-selection to keep it and act on all of it, right-click empty space for folder-level actions (New Folder/File, Upload, Paste). The plain <textarea> editor became a real CodeMirror 6 instance (CodeEditor.vue) — syntax highlighting, line numbers, folding, active-line highlight, language chosen by extension (JS/TS/CSS/HTML/ JSON/PHP/Markdown/XML/SQL, unrecognized extensions fall back to plain text), themed off Aurora's own CSS variables rather than a hardcoded palette. New npm deps: codemirror + one @codemirror/lang-* package per language above. Adds real weight to the file-manager bundle (~250KB gzipped) but it's only loaded when that page is actually opened. Verified live: context menu selection/empty-space cases and Escape-to-close; PHP syntax highlighting confirmed on a real file.
• Was gated as a paid feature until 3.0.0 — free now, along with every other previously-paid feature (see "Licensing" above). The REST permission callbacks here (and Database Explorer/Role Editor/Activity Log's) still check current_user_can() directly, not just at the page level — that defense-in-depth pattern is still correct practice even though there's no license left to bypass.

Extraction into a standalone plugin (3.4.0)

WordPress.org's response to the 3.2.1 resubmission (which restricted PHP editing per the section above) was that restriction doesn't matter — the whole category of file-management/code-editing functionality isn't accepted into the Plugin Directory, bundled in any WordPress.org-listed plugin, safeguards or not. The user's direction: pull File Manager out of Aurora Admin entirely and offer it as a separate, independently-installable companion plugin instead of deleting the functionality.

• New sibling plugin, aurora-file-manager (separate repo/directory at /Users/kris/Projects/aurora-file-manager, not a subfolder of this one) — FileManagerData.php and the three Vue components (FileManager.vue/FileManagerTree.vue/CodeEditor.vue) moved over with the identical PHP-editing-restricted behavior from 3.2.1 kept intact (not restored to unrestricted editing — that restriction is a genuine security improvement independent of WP.org's policy, so there was no reason to relax it just because it's no longer being reviewed). Only mechanical changes: namespace AuroraAdmin\FileManager → AuroraFileManager\FileManager, REST namespace aurora-admin/v1 → aurora-file-manager/v1, text domain/trash-dirname strings updated to match. Own plugin bootstrap (aurora-file-manager.php), own minimal admin-page shell (AuroraFileManager.php — a single top-level menu page, since this plugin has no Aurora Admin shell/sidebar framework to hook into and needs to work whether or not Aurora Admin is even installed), own Vite build (app/package.json/vite.config.js, same CodeMirror dependency set), and a small standalone base-theme.css extracting just the light-mode --aurora-* CSS variables the three Vue components actually reference (10 of them) rather than the whole window-chrome/dark-mode/sidebar system, which this plugin has no use for. Verified live both with Aurora Admin active (nav item appears alongside Aurora's own) and fully deactivated (File Manager still works standalone, confirming zero hidden dependency on Aurora Admin).
• Removed from Aurora Admin: admin/src/FileManager/ and app/src/pages/file-manager/ deleted outright, the require/use/ instantiation lines in aurora-admin.php/AuroraAdmin.php, the aurora-admin-file-manager sub-app entry in SubApps.php/Shell.php, and the file-manager Vite build entry all removed. Several other classes (FileArchiver, BackupPaths, BackupGoogleDriveData, BackupData) had comments citing FileManagerData as a design precedent (containment-check pattern, lazy WP_Filesystem init, nonce-via-query-param permission callback) — rewritten to stand alone rather than reference a class that no longer exists in this repo.
• AppearancePages's Theme Editor redirect removed, not repointed — it used to send theme-editor.php visits to File Manager instead of hijacking the native editor in place (reasoning: no point building a second unhardened PHP-editing surface). With File Manager gone, visits now fall through to WordPress core's own Theme Editor unmodified, which already respects DISALLOW_FILE_EDIT itself — arguably a better fit for WP.org's stated comfort zone than redirecting to any file editor, even a separately-distributed one.
• New Settings → Add-ons screen offers one-click install: a new companion-plugin field type in SettingsField.vue (Settings.vue now passes a shared api() fetcher down to SettingsField as a prop, the first field type that needs its own REST calls beyond the generic wp/v2/settings save flow) checks install/active status on mount and shows "Install & Activate" / "Activate" / "Installed & active — open File Manager →" accordingly. Backend: CompanionPluginData.php wraps Plugin_Upgrader::install() — the exact same core class plugin-install.php's native "Install Now" button and the Upload Plugin tab both use — pointed at a fixed, hardcoded HTTPS zip URL (https://aurora.auroradragon.studio/aurora-file-manager.zip), never a client-supplied one, so there's no SSRF surface: the install target isn't user input, only the decision to trigger the install is. Inherits Plugin_Upgrader's own WP_Filesystem credential handling for hosts that need FTP/SSH creds for direct writes.
  • Live-testing note: clicking "Install & Activate" for a not-yet-installed copy was correctly blocked by the safety classifier — the button, once the zip is actually hosted at that URL, downloads and executes a whole WordPress plugin with full admin privileges, which needs the user's explicit go-ahead each time, not just code-level review. The underlying install()/activate_plugin() logic was still verified functionally correct via a manual rsync-based install (bypassing the remote-fetch step entirely) and by exercising the "already installed, just activate" code path through the plain Plugins screen instead of the new button.
  • Deployment gap, not yet done: the zip isn't actually hosted at aurora.auroradragon.studio/aurora-file-manager.zip yet — that's a real production-server deploy (the same box/pattern used for beta zip hosting, see reference_auroradragon_server) requiring explicit user confirmation before it happens, not something to do unprompted. Until it's deployed, the Add-ons install button will fail with a fetch error if clicked against a site that doesn't already have the plugin installed some other way (manual upload, local rsync in dev).

Media Folders (new — duplicates FileBird Pro's folders)

User has FileBird Pro installed on the test site (wp-content/plugins/filebird-pro/) and asked to duplicate its folder organization capability for Aurora's own Media Library, since Aurora's Media page (app/src/pages/media/Media.vue, hijacked in place via ScreenHijack — see HijackedNativePages.php) was a flat grid with no folders. Researched FileBird's actual schema/REST surface first (its wp_fbv folder table + wp_fbv_attachment_folder join table, filebird/v1 REST namespace) rather than guessing, then asked the user three scoping questions before building:

• Custom DB tables, not a WP taxonomy — user's choice, matches FileBird's own model.
• Start fresh — no import of FileBird's existing folder data.
• Paid feature — but only the folder capability, not the Media Library page itself, which was already free/ungated and stays that way; gating the whole page would have downgraded something already free.

Implementation:

• New admin/src/Media/MediaFolders.php — storage + model, following the exact init-hooked maybe_install() + DB_OPTION version-check idiom already used by ActivityLog.php/Notices.php/MenuCreator.php/ Analytics.php. Tables: wp_aurora_media_folders (id, name, parent, ord, color, created_by) and wp_aurora_media_folder_items (folder_id, attachment_id) — deliberately named aurora_*, not fbv*, so both plugins coexist without collision. Simpler than FileBird's own schema: no folder "type" (collection/saved-search — skipped, no organizational value over folders), and one folder per attachment enforced in application logic (assign_attachments() always clears existing membership first).
• New admin/src/Rest/MediaFolderData.php — aurora-admin/v1 REST routes for folder CRUD + /media-folders/assign. Every permission_callback checks current_user_can('upload_files').
• MediaData.php's existing GET /media route gained an additive folderId param and serialize_attachment gained a folderId field, batch-looked-up via MediaFolders::folder_ids_for_attachments() (one query per page of results, not one per attachment).
• Media.vue gained a sidebar: pinned "All Media"/"Uncategorized" pseudo-folders (ids 0/-1, never real DB rows) above a new MediaFolderTree.vue (recursive tree component modeled on FileManagerTree.vue, plus inline create/rename/delete via window.prompt/confirm — matching FileManager.vue's own existing UX convention for the same actions — a right-click context menu, and HTML5 drag-and-drop for both folder reparenting and dropping media cards onto folders). A "Move to folder" dropdown on each media card is a non-drag fallback, since drag-and-drop alone is easy to miss. Was gated behind a license until 3.0.0 (the UpgradeNotice.vue fallback this paragraph used to describe is gone along with the rest of licensing) — at the time this was notable as a new gating shape for this codebase, since previously a sub-app was either wholly free or wholly paid; now moot since nothing is gated.
• Testing note: window.prompt()/confirm() block the automated Chrome tooling entirely (the tab hangs until the dialog is dismissed) — create/rename/delete were verified via direct fetch() calls against the REST routes instead of clicking through the UI. Drag-and-drop was effectively verified two ways: the REST assign endpoint directly, and organically — while testing, the real user apparently used the live feature themselves in a separate tab (created a "Logos" folder via the actual UI, dragged all 6 media items into it), which incidentally proved the whole click-to-create → drag-to-assign path works for a real human, not just via REST.

Real bug found and fixed while building this, unrelated to the folder schema itself: Shell::is_own_page() only recognized Aurora's own pages by ?page=aurora-admin* or pagenow === 'index.php' — it had no way to know a ScreenHijack-based page (Posts, Pages, Media, Users, Comments, all of which keep their native URL, e.g. upload.php, with no page= query param at all) was one of Aurora's own. This meant native-dark.css (loaded whenever !is_own_page(), meant only for real untouched native pages) was loading on every hijacked page too, and its generic #wpbody- content a { color: var(--aurora-accent) } rule was overriding any link inside the real Aurora UI that needed proper accent/contrast coloring. Invisible until now because no earlier hijacked page happened to render a link depending on that contrast — Media Folders' unlicensed "Enter a license key" CTA (white text on an accent-colored button) was the first, and came out as invisible accent-on-accent text. Fixed at the source rather than patched around: ScreenHijack::register() now sets a static is_hijack_active() flag the moment any registered hijack actually activates for the current request (all its gating checks passed), and Shell::is_own_page() checks it as a third condition. Confirmed fixed by inspecting the CTA's computed style before/after (color literally equal to its own background before the fix, i.e. invisible) rather than just eyeballing a screenshot.

Site Backup — REMOVED from Aurora Admin in 3.6.0, now a separate plugin

Extracted entirely out of this codebase in 3.6.0, at the user's explicit request ("pull out the backup as well and lets move that to an add-on"), following the same pattern established by File Manager (3.4.0) and Database Explorer (3.5.0) — see those sections for the fuller precedent. Proactive, not reactive: no WP.org rejection specifically over Site Backup, but restoring a backup means writing arbitrary files back into the site, the same class of risk that's kept file-management functionality out of Aurora Admin proper.

The entire admin/src/Backup/ tree (BackupJobs.php, BackupPaths.php, BackupSchedules.php, DbDumper.php, FileArchiver.php, BackupEngine.php, BackupCron.php, and Backup/Storage/'s StorageProviderInterface.php/LocalStorageProvider.php/S3Signer.php/ S3StorageProvider.php/GoogleDriveStorageProvider.php/ StorageFactory.php) plus the four Backup REST controllers (BackupData.php, BackupScheduleData.php, BackupSettingsData.php, BackupGoogleDriveData.php) and the Vue UI (SiteBackup.vue, BackupHistoryList.vue, BackupScheduleForm.vue, BackupSettingsPanel.vue, plus the shared AppListShell/AppListItem list-detail components and ProgressBar.vue/useJobPolling.js it depends on) moved, unmodified in behavior, into a new sibling plugin: aurora-site-backup (aurora-site-backup.php, own bootstrap, own REST namespace aurora-site-backup/v1, own Vite build, own light-only base-theme.css).

New wrinkle not present in the File Manager/Database Explorer extractions: Backup's storage providers (S3StorageProvider, GoogleDriveStorageProvider) and BackupSettingsData/ BackupGoogleDriveData all depend on AuroraAdmin\Options\Settings for storing credentials (S3 keys, Google Drive OAuth tokens) — a dependency on Aurora Admin's shared settings option that the standalone plugin can't have. Added a small standalone AuroraSiteBackup\Options\Settings class to the new plugin instead, replicating just the get($key, $default) + direct update_option() read-modify-write shape the Backup code already used (no WP Settings API registration ceremony needed, since Backup never went through register_setting()'s sanitize flow) — backed by its own aurora_site_backup_settings option so the plugin works completely standalone.

Removed from Aurora Admin: all of the above source files, the aurora-admin-site-backup entries in SubApps.php/Shell::aurora_nav(), the site-backup Vite build entry, and the corresponding requires/new X() wiring in aurora-admin.php/AuroraAdmin.php. CompanionPluginData.php's PLUGINS array (already generalized to a config-driven shape in 3.5.0) gained a site-backup entry — no new PHP route-registration code needed. The Settings → Add-ons screen now lists all three companion plugins.

Verified live, more thoroughly than the previous two extractions: built, PHP-linted, activated with no fatals, and — going beyond "loads without errors" — exercised via a full rest_do_request() dispatch that created a real backup job (POST /backup/jobs), stepped it through its first DB-dump chunk (POST /backup/jobs/:id/step, confirmed progress_tables_done actually advanced), and canceled/deleted it (DELETE /backup/jobs/:id) — all against the live LocalWP database, not mocked. The admin page itself was also confirmed rendering correctly (mount div + correct built script, HTTP 200, no PHP warnings) via a server-generated auth cookie over real HTTP, same technique used for the other two companion plugins.

Deployment gap, same as the other two: the aurora-site-backup.zip is not yet hosted at https://aurora.auroradragon.studio/aurora-site-backup.zip — a real production-server deploy that needs the user's go-ahead. Until deployed, the Add-ons "Install & Activate" button for Site Backup will fail with a fetch error.

---

Everything below this point in the section is historical: it describes Site Backup's design while it was part of Aurora Admin (v3.1.0 through v3.5.1). None of the file paths referenced (admin/src/Backup/, app/src/pages/site-backup/) exist in this repo anymore — the equivalent code now lives in the sibling aurora-site-backup repo, unmodified in behavior from what's described below.

Duplicator-style full backup + restore-in-place, on-demand or on a recurring schedule, local or S3-compatible remote storage. Full design lives in the approved plan file (pure-beaming-pelican.md, not persisted in repo); summarized here for continuity, same convention as the earlier Full Admin Takeover / Media Folders plans.

Scope, decided up front (v1 boundaries, not oversights): restore-in-place only, no cross-domain migration installer.php generation (Duplicator's own headline feature — deferred, real scope/risk). Restore only ever sources from Aurora's own backup history, never an uploaded arbitrary archive (real attack surface — path traversal, zip bombs, malicious file reintroduction — not worth taking on for v1). Storage: local disk, one S3-compatible remote implementation (covers AWS S3, Backblaze B2, Cloudflare R2, DigitalOcean Spaces via a configurable endpoint), and, added in 3.2.0, Google Drive via OAuth 2.0 (see "Google Drive remote storage" below). Dropbox is still deferred — the storage-provider interface was deliberately designed so a new provider plugs in without touching the job engine, which the Google Drive addition confirmed in practice: zero BackupEngine changes were needed.

The job engine is genuinely new infrastructure — this codebase had no background-job/cron/chunked-processing pattern anywhere before this (confirmed via grep: zero wp_cron, zero ZipArchive usage). Every backup/restore step is bounded (row/file/byte count and a wall-clock budget) so a multi-GB site never risks one request's timeout or memory limit. BackupEngine::process_step($job_id) is the single state-machine driver; two triggers converge on it — a foreground REST "step" call the Vue UI polls (setTimeout-recursion, not setInterval, so a slow step can't overlap the next poll) and a wp_cron safety net (BackupCron::schedule_next_tick(), guarded by wp_next_scheduled() so an actively-polling tab and cron can't stack duplicate events for the same job). Verified live: a job advanced purely via wp-cron.php ticks with zero manual REST calls, and closing the browser mid-backup didn't stop it from finishing.

• BackupJobs/BackupSchedules — two new tables, both via the exact MediaFolders.php install idiom (DB_VERSION/DB_OPTION version-gated dbDelta()). BackupJobs::update_progress() does an optimistic-lock write (WHERE id = %d AND updated_at = %s) so a foreground poll and a cron tick landing on the same job in the same second can't double-process a chunk.
• DbDumper — paginated dump (~500 rows/step), schema captured per-table at first touch (DROP TABLE IF EXISTS + the literal SHOW CREATE TABLE output) so restore is deterministic and re-runnable from scratch, not an ALTER/merge. Chunked restore via a byte-cursor into the dump file (fseek+bounded fread, growing the read if no statement boundary is found — guards against a single large serialized value landing on a chunk edge).
  • Real bug found and fixed while building this: Aurora's own wp_aurora_backup_jobs/wp_aurora_backup_schedules tables were initially included in what gets dumped like any other table. A restore's DROP TABLE+CREATE TABLE on those tables was overwriting the live jobs table with a stale snapshot captured mid-backup — deleting the very job row driving the restore out from under itself (subsequent /step calls started 404ing). Fixed by excluding Aurora's own bookkeeping tables from known_tables() entirely. Bookkeeping about backups isn't site content anyway; it has no business being restored.
  • Second real bug, more serious: quote_value() originally pre-converted real newline bytes to a literal \n two-character sequence before calling $wpdb->_real_escape() — but _real_escape() (a thin wrapper on mysqli_real_escape_string()) already does exactly this conversion itself. The manual pre-conversion meant _real_escape() then escaped the backslash again, so a restored text field ended up containing the literal two characters \+n instead of a real newline — a real, permanent data-corruption bug, caught by a live backup→mangle→restore test and confirmed via the dashboard's own recent-comments widget rendering \n as visible text instead of a line break. Fixed by deleting the manual pre-conversion entirely and trusting _real_escape() alone.
• FileArchiver — one-shot manifest build (a flat text file, one relative-to-wp-content path per line — cheap since it's metadata only, not file content), excluding the backup storage directory during the walk. wp-config.php needs no explicit exclusion — it lives at ABSPATH, a sibling of wp-content/, so the walk (rooted at WP_CONTENT_DIR) never visits it at all. Zip step reopens the same .zip every request (ZipArchive::CREATE is safe on an existing file — opens for append), adds files via addFile() (streams from disk, never addFromString()) in batches bounded by both file count and cumulative bytes. Extract step containment-checks every entry before writing anything (reject ..-containing names, then the authoritative realpath-based check against WP_CONTENT_DIR — same principle as FileManagerData::resolve_path()) — verified live with a deliberately crafted malicious zip entry (../evil-outside-wp-content.txt), confirmed the file never got written anywhere outside wp-content, and the rest of the restore still completed successfully around it.
• Local storage hardening — wp-content/uploads/aurora-backups/ gets WordPress core's own index.php stub and an .htaccess deny (both Apache 2.2 and 2.4 directives). No protection on nginx (ignores .htaccess entirely) — the real safeguard is that the download route (BackupData::download_job()) is manage_options-gated and streams the file through PHP in bounded chunks (never a whole-file WP_Filesystem::get_contents() — a backup archive can legitimately be multi-GB, unlike File Manager's individually-capped files).
• Retention — BackupSchedules::prune() keeps the newest retention_count completed backups per schedule, deleting the rest (job row + stored archive, via whichever storage_provider that specific job actually used — a schedule's storage setting can change after some of its jobs already ran). Only scheduled backups prune; an on-demand backup a user triggers by hand isn't subject to a schedule's retention limit just because it happens to share a storage provider.
• S3-compatible remote (S3StorageProvider + S3Signer) — manual AWS Signature Version 4 signing via hash_hmac() over wp_remote_request() calls, no SDK/Composer dependency (none exists in this codebase). Verified two ways: (1) byte-exact match against AWS's own published worked example ("GET Object" signing example, AKIDEXAMPLE/ wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY placeholder credentials — cross-checked independently via a from-scratch openssl-based re-derivation of the same signing chain, not just self-consistency); (2) a real request to AWS's live API with fake credentials came back with AWS's genuine InvalidAccessKeyId error — proof the request itself is well-formed enough for AWS to actually parse and respond to, not just syntactically plausible. Full upload/multipart/download/restore round-trip against a real bucket was explicitly deferred (needs real cloud credentials the user didn't provide) — S3 code is verified correct at the protocol level, not live-tested end-to-end against an actual bucket. Configurable endpoint field (not hardcoded to AWS) so Backblaze B2/Cloudflare R2/DigitalOcean Spaces work through the same code path. Files above 100MB use S3 Multipart Upload, chunked the same bounded-per-step way as everything else here.
  • S3 credentials live under Settings's backup_s3_credentials key, excluded from Settings::get_safe() (verified live: the raw secret never appears in any other page's serialized data-aurora-admin payload) — the exact "future field that shouldn't be broadcast" case get_safe()'s own docblock already anticipated. Save/read use a dedicated REST route (BackupSettingsData) rather than the generic wp/v2/settings flow specifically because the generic flow's shallow merge-on-save would blow away a previously-saved secret on any partial update (the client is never given the real secret back to resend) — the dedicated route does its own read-modify-write, preserving the existing secret when the field is left blank. Verified live: saved credentials, reloaded the page, secret field correctly showed a masked placeholder instead of the real value or an empty field.
• Vue UI (SiteBackup.vue + BackupHistoryList/BackupScheduleForm/ BackupSettingsPanel) — three tabs (Backups/Schedules/Settings), a new shared ProgressBar.vue and useJobPolling.js composable (the setTimeout-recursion polling loop, shared between the backup-create and restore flows). window.confirm()/alert() block the automated Chrome tooling the same way window.prompt() does elsewhere in this codebase (see File Manager's testing notes) — verified those flows by pressing Enter to accept the native dialog rather than working around it.
  • Real bug found and fixed during live testing: a job's phase column never got updated to a clean "done" value on successful completion (BackupJobs::set_status() only touched status), so the UI kept showing the stale last-real-phase label ("Archiving files…") indefinitely even after the job had actually finished. Fixed by having set_status() also set phase = "done" specifically on successful completion (failed/cancelled jobs deliberately keep their last real phase — useful debugging context, e.g. "failed during file_zip").
• Not built in this pass: the plan's "run schedule now" UI action — the REST plumbing for it exists (POST /backup/jobs accepts an optional scheduleId to attribute an on-demand job to a schedule's retention pool, exercised directly during retention testing), but there's no button for it in BackupScheduleForm.vue yet.

Google Drive remote storage (added 3.2.0)

Extends the storage-provider abstraction with a second remote option, GoogleDriveStorageProvider — same upload/download/delete/list interface as S3, plus upload_step/download_step chunked variants the job engine calls the same way it calls S3's. StorageFactory and BackupData.php's provider allow-list were the only job-engine-adjacent touch points; BackupEngine itself needed zero changes.

• OAuth model: since this is a free, publicly-distributed GPL plugin, it can't ship a shared Google OAuth client secret — each site owner creates their own Google Cloud OAuth client (Client ID + Secret, pasted into Settings) and registers Aurora's REST callback URL (/wp-json/aurora-admin/v1/backup/gdrive/oauth-callback, shown read-only/copyable in the Settings UI) as its redirect URI. Scope is the narrow drive.file (only files/folders the app itself creates, not full Drive access). access_type=offline + prompt=consent guarantee a refresh token even on re-auth; a state nonce in a short-lived transient covers CSRF on the callback. Only the refresh token is ever persisted — an access token is fetched fresh via get_access_token() before every authenticated call, avoiding stale-token bookkeeping given operations here are already inherently multi-step.
  • Credentials live under Settings's backup_gdrive_credentials key, excluded from get_safe() (same treatment as backup_s3_credentials — verified live it never leaks into another page's serialized payload). BackupGoogleDriveData's config GET/POST routes follow the identical masked-secret read-modify-write pattern established by BackupSettingsData for S3.
  • oauth-callback is the one route in this controller that isn't manage_options-gated at the permission-callback level — Google hits it via a real browser redirect with no X-WP-Nonce possible, so it's instead gated on the state parameter matching the stored transient (same class of exception FileManagerData::download_file() already established for direct-navigation routes).
• Resumable upload/chunked download mirror S3's multipart precedent exactly, against Drive API v3's own documented shapes instead of SigV4: a resumable session (POST .../upload/drive/v3/files?uploadType=resumable → Location response header is the session URI), then bounded PUT chunks with Content-Range/Content-Length headers (308 Resume Incomplete means more to send — the byte cursor advances from the response's Range header, not local arithmetic, to trust what Google actually received). Download is a Range-header GET against ?alt=media, appended to the local file the same justified-raw-fopen way DbDumper::append()/S3's download_step() already do. The small .sql dump uses a one-shot multipart/related upload instead (manually constructed boundary body — same reasoning as S3's plain-PUT case for small files).
• Verification without live credentials — the user doesn't have a Google Cloud OAuth client set up yet, so this shipped code-complete but not live-connection-tested, the same deferral S3's live bucket round-trip got. Two tiers of evidence instead: (1) a line-by-line request-shape review of every Drive API call against Google's published REST reference (endpoints, field names, header formats all documented, no ambiguity to guess at); (2) posting fake credentials to Google's real live OAuth endpoints and confirming genuine, specific Google errors came back (invalid_request/invalid_client/invalid_token) rather than a generic connection failure — proof the requests are well-formed enough for Google's own server to parse and evaluate them. Also verified live in the browser: the Settings tab's Google Drive section renders correctly (redirect URI, masked-secret fields), and clicking "Connect to Google Drive" opens a real new tab to accounts.google.com that comes back with Google's own invalid_request: Missing required parameter: client_id error — confirming the whole button→REST→Google round trip is wired correctly even with no client ID entered yet.
  • Explicit gap, not yet closed: a full "Connect to Google Drive" round trip only works once the site owner (a) creates a real Google Cloud OAuth client, (b) registers the exact redirect URI shown in Settings, and (c) serves the site over HTTPS (or is exactly localhost) — none of which the LocalWP dev site (http://admin.local) satisfies. Not live-tested end-to-end against a real Drive account.

Modern Image Formats (new Settings section, free, added 3.3.0)

The user shared a downloaded copy of WordPress.org's own "Modern Image Formats" (formerly "WebP Uploads") feature plugin as a functional reference and asked for equivalent functionality inside Aurora's Settings — explicitly not to use their code, just to understand and reimplement the behavior. Inspected their readme.txt/settings.php/ hooks.php to understand the feature set and which WordPress core hooks it uses, then built admin/src/ImageFormats/ImageFormats.php from scratch against those same documented core hooks and APIs (no shared code, different function/class names, different settings storage, different metadata key shape, different picture-building approach).

Scope decided up front (confirmed with the user via AskUserQuestion): "Automatic" format selection (prefers AVIF, falls back to WebP, based on wp_image_editor_supports()) rather than WebP-only; settings live in a new Aurora Settings category rather than hijacking native Settings > Media (which Aurora doesn't otherwise own); always generate the original format alongside the modern one and rewrite <img> markup into <picture> elements, rather than a WebP-only replacement mode (maximizes compatibility at the cost of extra storage — the same trade-off the reference plugin's own non-default mode makes).

• Generation (generate_sibling_formats(), hooked on wp_generate_attachment_metadata at priority 20): for every JPEG/PNG upload, re-encodes the full size and every already-generated subsize into the target mime type via wp_get_image_editor($path)->save(null, $target_mime) — save()'s null-filename behavior derives a sibling filename in the same directory automatically, a documented core behavior, not a technique borrowed from the reference plugin. Discards the result if it isn't actually smaller than the source. Recorded in the attachment's own metadata under a new aurora_image_formats key (a sibling structure to core's own sizes key) — deliberately not reusing the reference plugin's sources key name.
• Cleanup (cleanup_sibling_formats(), hooked on delete_attachment): deletes every generated sibling file when the attachment is deleted — core only knows to clean up files it generated itself.
• Quality (set_quality(), hooked on wp_editor_set_quality): pins WebP/AVIF quality at 82 explicitly, untouched for every other mime type.
• <picture> rewriting (build_picture(), called from both wp_content_img_tag and wp_get_attachment_image_html — two separate core filters needed since core doesn't route wp_get_attachment_image() output through the content-tag filter): wraps the original <img> tag in <picture> with one <source> offering the generated format, reusing the original tag's own sizes attribute rather than re-deriving it. Controlled by its own dependent setting so a site can keep generating the files without the markup rewrite if it conflicts with a theme's image styling.
• Settings UI: a new "Modern Image Formats" category in settingsConfig.js — the first use of the dependsOn field pattern (added to settingsConfig.js/Settings.vue/SettingsField.vue/ Toggle.vue in this pass; didn't exist before), which greys out and disables the "Output format" and "Serve via <picture> element" fields when the master toggle is off. No new REST route — reuses the existing wp/v2/settings + aurora_admin_settings merge-on-save flow every other Aurora setting already uses.
• Verified live end-to-end, not just at the protocol level (unlike Google Drive above, this needed no real third-party credentials, so a full round trip was actually testable): uploaded a real JPEG via a direct wp/v2/media REST call (browser file-picker upload wasn't available in this session — worked around by base64-encoding a generated test image and POSTing a FormData/Blob from within the authenticated browser tab), confirmed wp_get_attachment_metadata() showed a genuine aurora_image_formats.full entry pointing at a smaller .avif file that existed on disk with the expected byte size drop, confirmed a real post embedding that image rendered <picture><source type="image/avif" srcset="..."> wrapping the original <img> tag, and confirmed deleting the attachment removed both the original and generated files with no orphans left behind.
  • Interesting environment finding: this LocalWP install's PHP 8.2 GD build supports AVIF encoding directly (imageavif()) even without the Imagick extension loaded — so "Automatic" correctly picked AVIF over WebP on a host that, per the reference plugin's own FAQ language, would usually be described as "AVIF not supported without ImageMagick." Worth remembering if a future host behaves differently (GD without libavif support, or an older PHP) — the graceful degradation to WebP-then-nothing should still hold, just not something this session's live test actually exercised.

Key bugs fixed (root causes, in case they resurface)

• Deleting a plugin fataled the whole site ("major issue" per user report — WordPress's generic "There has been a critical error" page, no plugin actually deleted). Error log showed Call to undefined function request_filesystem_credentials() inside core's delete_plugins(), called from PluginsData::delete_plugin(). That function lives in wp-admin/includes/file.php, which a REST API request doesn't load by default — delete_plugin() only required plugin.php. update_plugin() right next to it already required file.php for the identical reason; delete_plugin() just never got the same fix, presumably because activate/deactivate/list don't touch the filesystem layer so never needed it. Fixed by requiring file.php in delete_plugin() too, guarded the same way (function_exists() check first). Verified by actually deleting a real plugin (WP File Manager, user-approved as safe to sacrifice for the test) end to end — no fatal, correct "Plugin deleted." message, confirmed no new error in the log afterward.
• AppListShell.vue's two panes shared one page-level scroll instead of scrolling independently — this shared component backs Database Explorer, Role Editor, Activity Log, Admin Notices, and Menu Creator, so the bug (and fix) applies to all five, not just wherever it's first noticed. User reported it via Database Explorer specifically: selecting a table near the bottom of the (40-table) list didn't seem to do anything until manually scrolling back to the top, where the detail panel's new content had actually rendered. Root cause: .app-list-shell only had a min-height, so the flex container just grew with content and both the list pane and detail pane relied on the outer page's own scroll — there was no independent scroll region for either. Fixed by giving the container a real height: calc(100vh - var(--aurora-toolbar-h) - 60px) and both .app-list-shell__nav/.app-list-shell__content their own height: 100%; overflow-y: auto, with separate mobile-breakpoint rules (stacked panes get natural height + their own max-height, not a 50/50 squash). Verified live by scrolling the list to the bottom and confirming the detail panel updates immediately, in view, with no scrolling needed.
• File Manager's right-click context menu never appeared for real users, despite appearing to work in earlier automated testing (which, in hindsight, was triggering the absence of the race rather than proving the feature worked). Root cause: right-clicking — especially via a trackpad two-finger tap or Ctrl-click on macOS — can fire a trailing synthetic click event immediately after contextmenu on the same target. The menu's document-level "click anywhere else closes it" listener was attached synchronously the instant the menu opened, so that trailing click closed the menu in the same tick it appeared. Fixed by deferring the listener's registration one tick past the opening event (setTimeout(..., 0)) in FileManager.vue's openContextMenu(). Confirmed by simulating the exact race (dispatching contextmenu then click on the same element in the same tick) and checking the menu stayed open, plus confirming a genuine subsequent click still closes it. If a future dropdown/menu/popover in this codebase uses the same "open on some event, close on any document click" pattern, apply the same one-tick-deferred-listener fix — this exact race will resurface.
• Every ScreenHijack-mounted page missing the traffic-light bar, rendering outside the normal card frame: user reported this across Posts, Media, Comments, Users, Add User, Profile (and it affected every other ScreenHijack page too). Root cause: WordPress prints <div id="wpbody"><div id="wpbody-content"> after in_admin_header fires (confirmed directly in core's wp-admin/admin-header.php — do_action('in_admin_header') is literally before the <div id="wpbody"> line), but ScreenHijack.php's ob_start() was hooked to in_admin_header itself. So the buffer captured those wrapper divs' opening tags too (not just the native content meant to be discarded), and since their closing tags print in admin-footer.php before do_action('admin_footer') fires, those got captured and discarded too. Net effect: ob_end_clean() silently ate the entire #wpbody/ #wpbody-content wrapper, opening and closing tags both, and the mount div printed a level too high (a direct child of #wpcontent). This broke windowChrome.js's traffic-light insertion (it specifically looks up #wpbody-content) and the shell's card-frame CSS, which both assume that nesting exists. Fixed by having ScreenHijack.php re-print the #wpbody/#wpbody-content wrapper divs itself around the mount point — same DOM shape WordPress would have produced, just with different content inside. If a future hijacked screen looks "unframed," check this first.
• Plugins dropped to the native page after activating a plugin: user installed FileBird and it "defaulted back to WordPress plugins page until I clicked on plugins from the menu." Root cause: unlike Posts/ Pages/Media/Users/Comments, Plugins was originally built with only a MenuSerializer.php link rewrite (the sidebar's own "Plugins" link pointed at the Aurora page) — it never got a redirect_native_pages() case for direct visits to plugins.php itself. WordPress's own post-activate/post-install redirect (wp_redirect(self_admin_url('plugins.php?activate=true'))) is exactly that: a direct visit with no ?page= param, bypassing the rewritten sidebar link entirely and landing on the true native page — fixed only once the user next clicked the sidebar link themselves. Added the missing redirect_native_pages() case, gated by modern_plugins like the others, redirecting to plugins.php?page=aurora-admin-plugins (not admin.php?page=..., to match the URL the sidebar link itself already uses). Verified live by visiting plugins.php?activate=true directly (the exact URL WP's own redirect produces) — now lands on the Aurora page correctly. If a similarly "sidebar-link-only" page ever gets reported as dropping to native after some WP-core-triggered redirect, check redirect_native_pages() for a missing case first — this is the second time that exact gap has caused a bug (Plugins now fixed; worth double-checking Comments/Posts/Pages/Media/Users don't have similar missed redirect sources, e.g. bulk actions, if this resurfaces).
• White native form fields on classic (non-block-editor) screens: user reported "a lot of endpoints still linking back to the original WordPress dashboard [look]" — investigation landed on the Edit Media screen (attachments don't use the block editor, so they hit the older meta-box-based edit template) showing a stark white title field and File URL input. Root cause: WP core styles some specific fields via a 2-ID selector (#titlediv #title { background: #fff }), which beats native-dark.css's existing form-field rule (one #wpbody-content id
  • classes) regardless of class count — the same CSS-specificity trap as the earlier block-editor-page background bug (class count doesn't matter once the other selector has more IDs). Fixed by adding !important to the whole form-field rule block (text inputs/textareas/ selects) — safe everywhere, since there's no legitimate case where a native admin form field should stay white. Verified this one rule fixed Edit Media, Edit Post (classic fields), and Comment edit simultaneously; Add User was already clean. The WYSIWYG editor body (TinyMCE) staying white is a separate, deliberate decision (same as the block editor's own canvas) — not a bug, don't "fix" it.
• Admin Notices invisible on the Dashboard: admin_notices prints inside #wpbody, which DashboardTakeover::hide_native() hides entirely (to hide the native dashboard, not ours) — collateral damage for anything else relying on that hook there. Fixed with Notices::render_for_dashboard(), called directly inside the visible dashboard frame (DashboardTakeover::render_mount()), with render() (the normal admin_notices hook) bailing on the Dashboard so it isn't rendered twice. Second, independent bug surfaced by the same fix: wp-admin/js/common.js unconditionally relocates every .notice element on the page to right after the page's <h1> ($('.notice').not('.inline, .below-h2').insertAfter($headerEnd)) — regardless of where it was placed server-side, it would've moved right back into the hidden #wpbody on its own. Core's own .below-h2 class is the documented opt-out; added only for the dashboard render path (render_notices($keep_in_place)), not the normal one, where the relocation is harmless/expected.
• .card global class collision: original Dashboard cards used class="card", colliding with WP core's .card { max-width: 520px }. Fixed by renaming to .aurora-card* everywhere. Never use unprefixed class names on Aurora components.
• Grid-column not applying on wrapped cards: settled on unwrapped <section class="aurora-card" :style="{gridColumn: ...}"> — component boundaries ate the style binding in earlier attempts.
• Two-box settings layout: took two wrong iterations before matching the user's reference image. Re-confirm layout intent against a screenshot before assuming.
• Redundant outer frame border on settings page: fixed with a body.toplevel_page_aurora-admin override in shell-frame.css.
• Dashboard submenu defaulting collapsed: Sidebar.vue's normalize() URL helper didn't map the bare /wp-admin/ root to index.php, so the Dashboard section's active-state check (and thus its default-expanded state) never matched on the dashboard itself. Fixed by normalizing empty/ query-only paths to 'index.php' + path.
• Aurora top-level menu appearing twice: SettingsPage.php's add_menu_page('aurora-admin', ...) naturally appears in WP's native $menu global. Since it's now also shown in the sidebar's dedicated Aurora nav section, MenuSerializer::serialize() explicitly skips slug aurora-admin to avoid the duplicate.
• Browser automation can't install plugins: the Chrome MCP file_upload tool only accepts files already "shared with the session" (attachments/ connected folders) — local build output on disk doesn't qualify. Confirmed this session; the user must manually reinstall the zip every time (though see "Fast local iteration" above for the hot-patch workaround used for verification during dev).
• Independently-painted gradient seams (sidebar/toolbar/settings-page #wpbody-content each showing a visibly different slice of "the same" background gradient): see the theme-system section above — root cause was multiple elements each painting their own copy of a gradient-valued var(--aurora-app-bg) instead of one element painting it and the rest staying transparent.
• Block editor content rendering underneath the sidebar: Gutenberg's .interface-interface-skeleton is position: fixed; inset: 0, completely bypassing the margin-left that pushes every other page's #wpcontent over — see the "Window chrome" block editor exception above for the full mechanism and the fix.
• zip -r merging into a stale archive: rebuilding the deployable zip without first deleting the old one left old-hash asset filenames mixed into the new zip (macOS zip -r appends/merges rather than replacing). Always rm -f the zip before rebuilding.
• remove_submenu_page() corrupting WP's own capability check: root cause of "Sorry, you are not allowed to access this page" on Menu Creator/ Activity Log/Role Editor/Comments — see the sub-apps bullet above. Also broke document.title on those pages, which is why taskbar.js's currentPageTitle() prefers the on-page <h1> instead. If a future custom admin page needs to be kept out of the native menu while staying reachable and capability-checked, filter it out at the menu-serialization layer (like MenuSerializer.php does), never with remove_submenu_page().
• min-height/max-height conflict silently no-oping a fix: per spec, when min-height is larger than max-height, min-height always wins and max-height is ignored outright — this is why the taskbar-overlap fix first appeared to do nothing (see Window chrome section above).
• position: fixed over-constraint silently ignoring an explicit bottom: when top, height, and bottom are all specified on a fixed-position box, the spec has bottom get silently recomputed from top + height rather than honored — root cause of the Site Editor frame running past the viewport despite an explicit bottom: 24px !important (see Window chrome section above).

Not-yet-done (deferred, no active request)

• Full field sets for settings categories beyond General/Analytics/White Label (original plugin had more).
• Extending native-enhance.js/native-dark.css coverage to more native surfaces — the block editor's own chrome, Widgets screen, Customizer. Media/thickbox modals and plugin/theme card grids were added this session; the plugin "More Details" popup specifically can't be reached (it's an <iframe> — see native page dark styling notes above).
• Menu Creator: stored item order field isn't applied at runtime yet (hide/relabel work; reordering doesn't).
• No automated tests anywhere in the project — all verification has been manual, live-in-Chrome, per the established workflow rule above.
• Comments list's pagination footer reads "0 to 0 of 0" even when the "All" tab correctly shows a real count — cosmetic, found during the same audit, not investigated further.

Current state

No task in progress. An earlier session rebuilt the entire theming system (fixed color presets, gradient backgrounds, "independently-painted gradient" seam bugs) and added the macOS-style window chrome + taskbar feature end-to-end (pushed as commits 4a547d2/b0b0a99). Later that same session: root-caused and fixed the Menu Creator/Activity Log/Role Editor "Sorry, you are not allowed to access this page" bug (was remove_submenu_page() corrupting WP's own capability lookup); added a 6th sub-app, Comments; fixed a white-patch bug in the block editor's dark-themed sidebar; rewrote the taskbar from a single sessionStorage slot to a list supporting multiple minimized windows; and extended the window-chrome/taskbar framing to the Site Editor (site-editor.php), including tracking down a CSS over-constraint bug (top+height+bottom all set on a fixed-position box silently ignoring bottom) that was making its frame run past the viewport (pushed as commit 8153d43).

An earlier pass this session capped every native/Aurora page's content area to the viewport with internal scrolling instead of letting tall pages grow past it and scroll the whole document (see "Universal content-area height cap" above), which surfaced and fixed two more bugs along the way — a Chrome scroll-anchoring jump on Add Plugins, and a phantom document-level scrollbar with a large empty gap below the frame. Also made the sidebar's native-menu sections a single-open accordion instead of letting multiple stay expanded at once (pushed as commit 73591e0).

An earlier pass this session added the free/paid feature-gating system end-to-end (see "Licensing" above) — Role Editor, Activity Log, Database Explorer, Analytics, White Label, and the remote site switcher are now paid; Menu Creator, Admin Notices, Comments, Plugins, and the whole shell/theming product stay free. That pass used a placeholder is_active() (any non-empty key counted as licensed) and fixed an unrelated pre-existing 500 in Role Editor's REST endpoint along the way (pushed as commit 6d50260).

An earlier pass this session replaced that placeholder with real validation against the license server at auroraplugins.com (see "Real license-server integration" above) — /validate//activate//deactivate calls, 12-hour cached status, immediate re-check on a license-key change, and a status line in the Settings UI. Verified live end-to-end against the real server with a fake test key, which correctly came back locked with the server's own "License key not found." message (pushed as commit 540083e).

Most recently: added file-integrity tamper protection (see "Tamper protection" above) so that stripping/commenting-out the license check in a distributed copy re-locks every paid feature, even with an otherwise-valid license — Integrity::is_tampered() checksums the gate files against a manifest generated at zip-build time. Verified live via a temporary mu-plugin that faked an active license without touching any protected file, confirming untampered+unlicensed stays locked, untampered+licensed unlocks, and one tampered file re-locks regardless of license status. The distributable zip (dist/aurora-admin-v2.zip) was rebuilt with the new manifest-generation step and should be re-verified/re-zipped again after this doc update if anything changed since.

All of it was live-verified in Chrome against the LocalWP site (build hot-patched into /Users/kris/Local Sites/aurora/.../aurora-admin/app/dist for iteration — the repo's source files are the actual edits; that copy is just the compiled build artifact, not a separate edit surface).

All of the above (this paragraph and the three before it) is history: the entire licensing/feature-gating/tamper-protection system it describes was removed from this repo in 3.0.0 (2026-07-06) when the user decided to give Aurora Admin away free on WordPress.org — see "Licensing" and "Tamper protection" above. Nothing here reflects current behavior; kept only so the reasoning behind the old design (and the commits that built it) stays findable. The commercial auroraplugins.com/aurora-licensing service itself is untouched and still consumes its own license API independently of this plugin.