aurora-wordpress-admin/CHANGELOG-legacy.md

Changelog

All notable changes to Aurora Admin are documented here, one entry per version bump. Starts at 2.1.0 — earlier history (the theming rebuild, window chrome/taskbar, Site Editor support, etc.) lives in git log and PROJECT_STATUS.md, not reconstructed here.

[3.6.1] - 2026-07-11

Fixed

• Second round of misplaced phpcs:ignore fixes, found via another fresh Plugin Check report after 3.5.1's fix. Turns out WordPress.DB.DirectDatabaseQuery.DirectQuery/NoCaching and WordPress.DB.PreparedSQL.NotPrepared/InterpolatedNotPrepared are attributed by PHPCS to different lines within the same multi-line $wpdb->get_results()/get_row() call — DirectQuery/NoCaching to the outer call's opening line, NotPrepared to whichever inner line the interpolated table name physically appears on. 3.5.1's fix moved every ignore comment down to cover the inner line (fixing NotPrepared) but broke coverage of the outer line (DirectQuery/NoCaching came back) for four calls in MenuCreatorData.php and Notices.php/NoticesData.php that hadn't already been collapsed to a single line. Fixed by collapsing those four remaining multi-line calls too — consistent with the single-line-call pattern used everywhere else in the 3.5.1 fix, which a single ignore comment reliably covers regardless of which sniff PHPCS attributes to that line. Re-verified with the automated scan plus live REST-dispatch functional round-trips.

[3.6.0] - 2026-07-11

Changed

• Site Backup extracted into a standalone companion plugin, at the user's explicit request, following the same pattern as File Manager (3.4.0) and Database Explorer (3.5.0) — proactive risk reduction, not a WP.org rejection: restoring a backup means writing arbitrary files back into the site, the same class of thing that's kept file-management functionality out of Aurora Admin proper.
  • The entire admin/src/Backup/ tree (job/schedule storage, DB dumper, file archiver, the state-machine engine, wp_cron safety net, and all four storage providers — local, S3-compatible, Google Drive, plus the provider interface/factory) and all four Backup REST controllers moved, unmodified in behavior, into a brand-new sibling plugin: Aurora Site Backup (aurora-site-backup.php, own bootstrap, own REST namespace aurora-site-backup/v1, own Vite build). Since this plugin needs its own settings storage independent of Aurora Admin (S3 credentials, Google Drive OAuth tokens), a small standalone Options\Settings class was added, backed by its own aurora_site_backup_settings option — same minimal shape as Aurora Admin's own Settings class, just a separate store.
  • CompanionPluginData.php's PLUGINS config array (already generalized in 3.5.0) gained a site-backup entry — no new PHP needed beyond the config line. The Settings → Add-ons screen now lists all three companion plugins.
  • Verified live via a full rest_do_request() dispatch: created a real backup job, stepped it through the DB-dump phase, and canceled it — end-to-end confirmation the extracted code still works, not just that it loads without fatals.
  • Deployment gap, same as the other two companion plugins: the aurora-site-backup.zip is not yet hosted at https://aurora.auroradragon.studio/aurora-site-backup.zip — the Add-ons "Install & Activate" button for it will fail with a fetch error until that's deployed (needs explicit go-ahead).

[3.5.1] - 2026-07-11

Fixed

• Misplaced phpcs:ignore comments from the 3.3.2 compliance pass, found via a fresh Plugin Check report. WPCS's phpcs:ignore suppresses violations reported on the exact next physical line — but several annotations added in 3.3.2 sat above the opening line of a multi-line $wpdb->get_results()/get_row()/get_var() call (e.g. $rows = $wpdb->get_results(), while PHPCS actually attributes the violation to whichever line further down inside that call contains the interpolated table-name/column tokens. Those suppressions were silently never taking effect. Fixed across MenuCreatorData.php, NoticesData.php, Notices.php, BackupSchedules.php, BackupJobs.php, MediaFolders.php (the largest cluster — collapsed most multi-line query calls to a single physical line so one ignore comment reliably covers every sniff PHPCS reports on that line, added a MediaFolders::name_taken() helper to replace an inline while() condition that couldn't otherwise be annotated), DbDumper.php, AnalyticsData.php, and MediaData.php's post__not_in VIP-advisory comment. Also added a genuinely missing annotation on Analytics::record()'s $wpdb->insert() call. Verified with an automated scan confirming every $wpdb-> call with dynamic table/query construction is now immediately preceded by its ignore comment.
• Real bug found during verification, unrelated to Plugin Check: MenuCreatorData::create() built its internal follow-up "fetch the row I just inserted" request as new \WP_REST_Request("GET", "", ["id" => $wpdb->insert_id]) — but WP_REST_Request's third constructor argument doesn't populate what get_param() reads, so get_one() always received a null id and returned "Menu not found" instead of the newly created menu. Confirmed via a full rest_do_request() dispatch (not just a direct function call) that this reproduced through the real REST route. Fixed by building the request with set_url_params(), WP core's own documented pattern for this.
• Confirmed the compressed_files/hidden_files/unexpected_markdown_file findings in the Plugin Check report (build zips, .gitignore, .claude/, PROJECT_STATUS.md) are scanner noise from scanning the whole development repository, not the actual submission zip — verified via unzip -l that none of those paths exist in wporg-submission/aurora-admin.zip.

[3.5.0] - 2026-07-11

Changed

• Database Explorer extracted into a standalone companion plugin, for the same reason and following the exact same pattern as File Manager in 3.4.0: direct database-query tooling (browsing tables, running free-form SELECT/SHOW/DESCRIBE/EXPLAIN queries from wp-admin) is treated by WordPress.org's Plugin Directory review the same way as file-management functionality — outside what it accepts in a directory-listed plugin. Rather than wait for a rejection to confirm it or delete the feature outright:
  • admin/src/DatabaseExplorer/DatabaseExplorerData.php and its Vue UI (plus the shared AppListShell/AppListItem list-detail layout it's built on) moved, unmodified in behavior, into a brand-new sibling plugin: Aurora Database Explorer (aurora-database-explorer.php, own bootstrap, own REST namespace aurora-database-explorer/v1, own Vite build). Works completely standalone, verified live via direct HTTP request with a server-generated auth cookie — the admin page renders its mount div and enqueued script correctly, and the REST namespace is registered and reachable.
  • CompanionPluginData.php was generalized from a single file-manager-only class into a small PLUGINS config array keyed by slug, so both File Manager and Database Explorer (and any future companion plugin) share the same install/activate/status REST routes and Plugin_Upgrader-based installer logic — adding a new companion plugin going forward is a config entry, not new PHP.
  • The Settings → Add-ons screen now lists both companion plugins.
  • Deployment gap, same as File Manager: the Database Explorer zip is not yet hosted at https://aurora.auroradragon.studio/aurora-database-explorer.zip — the Add-ons "Install & Activate" button for it will fail with a fetch error until that's deployed (needs explicit go-ahead, same as any other production deploy).

[3.4.0] - 2026-07-11

Changed

• File Manager extracted into a standalone companion plugin. WordPress.org's second review response was unambiguous: the entire category of file-management/code-editing functionality isn't accepted into the Plugin Directory, regardless of the restrictions added in v3.2.1 — the feature had to come out of Aurora Admin entirely for the submission to be reconsidered. Rather than delete the functionality:
  • admin/src/FileManager/FileManagerData.php and its three Vue components moved, unmodified in behavior, into a brand-new sibling plugin: Aurora File Manager (aurora-file-manager.php, own bootstrap, own REST namespace aurora-file-manager/v1, own Vite build). It works completely standalone — verified live with Aurora Admin fully deactivated.
  • The Theme Editor → File Manager redirect (AppearancePages.php) is gone; visits to theme-editor.php now fall through to WordPress core's own Theme Editor unmodified, which already respects DISALLOW_FILE_EDIT itself.
  • A new Settings → Add-ons screen offers one-click installation of Aurora File Manager, wrapping Plugin_Upgrader::install() — the same core API the native Plugins → Add New "Install Now" button uses — pointed at a fixed, non-client-supplied HTTPS zip URL. No settings/data are shared between the two plugins; Aurora Admin has zero remaining code that touches the filesystem beyond its own Site Backup archives.

[3.3.2] - 2026-07-11

Fixed

• WordPress.org Plugin Check compliance pass — a full re-run of the official Plugin Check tool against the whole codebase (279 findings across 26 files) surfaced several real gaps beyond the earlier v3.0.1/ v3.0.2/v3.2.1 passes, all now fixed:
  • readme.txt's Stable tag had drifted to 3.2.1 while the plugin itself moved through 3.3.0/3.3.1 — a real mismatch that can prevent WordPress.org from serving the correct download to users. Now kept in lockstep with every version bump.
  • Analytics::country() read $_SERVER[$h] directly for an empty()/strlen() check before the existing sanitized copy was computed — fixed by sanitizing once up front and using that everywhere, rather than touching the raw superglobal at all.
  • AuroraAdmin.php's defined("ABSPATH") || exit() guard sat after 49 use import statements — functionally fine, but far enough into the file that at least one automated file-access-protection scanner didn't detect it. Moved to immediately after the namespace declaration, this file's one deliberate departure from the rest of the codebase's "guard after imports" convention.
  • Roughly 230 WordPress.DB.DirectDatabaseQuery/PreparedSQL/ UnescapedDBParameter findings across every custom-table feature (Site Backup, Media Folders, Activity Log, Analytics, Menu Creator, Notices, Database Explorer) — verified each one is safe (internal $wpdb->prefix-based table names or already-validated/escaped identifiers, never raw user input) and annotated with the justified phpcs:ignore the review process expects, matching the standard already established for Database Explorer's query runner.
  • A handful of fread()/fwrite()/fclose() calls adjacent to an already-annotated fopen() were still individually flagged — WPCS suppression is strictly per-line, so each sibling call in Site Backup's file/S3/Google Drive streaming code now has its own annotation too.
  • Several RuntimeException messages interpolating internal (never user-supplied) values were flagged as unescaped output — annotated as exception messages, not HTML/browser output, the same false-positive class WPCS is known to flag on exception constructors.

[3.3.1] - 2026-07-11

Fixed

• Settings page: nav and content now scroll independently. Previously the left category list and the right content panel scrolled together as one long page — scrolling down the nav to reach a category near the bottom (e.g. "Modern Image Formats") and clicking it left the content panel's top scrolled out of view above the fold, requiring an extra scroll back up to actually see it. Both panels now have their own fixed-height scroll region, and switching categories resets the content panel's scroll position to the top regardless of the nav's own scroll position.

[3.3.0] - 2026-07-11

Added

• Modern Image Formats — a new Settings section that automatically generates a WebP or AVIF sibling for every size WordPress produces from a newly uploaded JPEG/PNG, and (optionally) rewrites <img> markup into a <picture> element offering the modern format with the original as a fallback source. "Automatic" output format prefers AVIF, falling back to WebP, based on what the server's image editor actually supports (wp_image_editor_supports()) — gracefully generates nothing on a host that supports neither, rather than erroring. Purely additive: original JPEG/PNG files are always kept, nothing about the attachment's own metadata or file is changed, and generated files are cleaned up automatically when the attachment is deleted. Only affects new uploads — existing library images need a regenerate-thumbnails-style tool to pick up the feature.
  • Built entirely on documented WordPress core hooks (wp_generate_attachment_metadata, delete_attachment, wp_editor_set_quality, wp_content_img_tag, wp_get_attachment_image_html) and WP_Image_Editor::save()'s documented mime-type-conversion parameter — no third-party plugin code, no Composer dependency.
  • Verified live end-to-end: uploaded a real JPEG, confirmed a smaller AVIF sibling was generated and recorded in attachment metadata, confirmed a post embedding the image rendered a correct <picture><source type="image/avif" srcset="..."> wrapper, and confirmed both the original and generated files were removed with no orphans left behind after deleting the attachment.

[3.2.1] - 2026-07-11

Changed

• File Manager: PHP/executable editing removed. Rejected from the WordPress.org Plugin Directory because File Manager let a manage_options user open and overwrite existing .php files in-place with immediate execution effect — no different in risk from WordPress core's own Theme/Plugin editor, which core lets hosts disable via DISALLOW_FILE_EDIT specifically because of that risk. File Manager previously blocked creating/uploading/renaming-to executable file types, but that same list wasn't enforced on editing an existing file of that type — closed now: opening or saving any file matching BLOCKED_EXTENSIONS (php, phtml, cgi, py, sh, and others) is refused. File Manager also now honors DISALLOW_FILE_EDIT (blocks all editing) and DISALLOW_FILE_MODS (blocks all create/upload/rename/delete/copy/ move/write operations), the same host-level lockdown constants WordPress core's own file-modification flows already respect. Browsing, downloading, and viewing file info are unaffected.

[3.2.0] - 2026-07-11

Added

• Google Drive remote storage for Site Backup — a second remote storage option alongside S3-compatible, via OAuth 2.0. Each site connects its own Google Cloud OAuth client (Client ID + Secret, pasted into Settings) since a free, publicly-distributed plugin can't ship a shared client secret; scope is the narrow drive.file (only files/folders Aurora itself creates). Resumable upload and Range-header chunked download against Drive API v3 mirror the bounded-per-step design S3's multipart upload already established — no changes to the job engine itself were needed, confirming the storage-provider abstraction's original design goal. Shipped code-complete and protocol-verified (request shapes checked against Google's published API reference, and live-tested against Google's real OAuth endpoints with placeholder credentials to confirm genuine API errors come back); a full live "Connect" round-trip is left for the user to verify once they have a real Google Cloud OAuth client and HTTPS on the target site.

[3.1.0] - 2026-07-11

Added

• Site Backup — a new free sub-app: full site backup (database + wp-content) and restore-in-place, on-demand or on a recurring daily/ weekly/monthly schedule, storing archives locally or on any S3-compatible remote (AWS S3, Backblaze B2, Cloudflare R2, DigitalOcean Spaces — one implementation via a configurable endpoint, no vendor SDK, SigV4 signing implemented directly and verified against AWS's own published test vectors).
  • Built on a new resumable job-processing engine (BackupEngine + BackupJobs) — the first background-job infrastructure in this codebase. Every backup/restore step is bounded (row/file/byte count and a wall-clock budget) so a multi-GB site never risks a single request's timeout or memory limit. Two trigger paths converge on the same step function: foreground polling from the Vue UI (fast feedback while a tab is open) and a wp_cron safety net (BackupCron) that keeps a job moving with no browser involved — closing the tab mid-backup, or a scheduled backup with nobody watching, both still reach completion.
  • Database export/import (DbDumper) — paginated dump with schema captured per-table (DROP TABLE IF EXISTS + CREATE TABLE, so restore is deterministic and re-runnable from scratch), chunked restore via a byte-cursor into the dump file. Aurora's own backup-tracking tables are excluded from what gets backed up — a real bug caught during testing, where restoring a snapshot of those tables was overwriting the very job row driving the restore mid-flight.
  • File archiving (FileArchiver) — a manifest of every file under wp-content/ (excluding the backup storage directory itself and, structurally, wp-config.php, which lives outside wp-content/ entirely), zipped/extracted in bounded batches via ZipArchive, reopened and appended to across isolated requests. Every extracted entry is containment-checked (zip-slip protection) before anything is written — verified live with a deliberately crafted malicious archive entry, confirmed rejected.
  • Local storage hardening — wp-content/uploads/aurora-backups/ gets WordPress core's own index.php/.htaccess stub pair; the real protection is that every archive read goes through a manage_options-gated REST route streaming the file through PHP, never a guessable direct URL.
  • Recurring schedules with count-based retention — a scheduled backup prunes older ones (both the job row and its stored archive, local or remote) down to the schedule's configured retention count.
  • v1 deliberately does not include cross-domain migration (Duplicator's own headline feature — generating an installer.php for a totally different host) or restoring from an arbitrary uploaded archive (restore only ever sources from Aurora's own backup history) — both are real scope/risk decisions, not oversights.
• Live-verified end-to-end on the dev site, including catching and fixing two real bugs along the way: a job's phase column wasn't updated to a clean terminal value on completion (stale "Archiving files…" label after a backup had actually finished), and a data-corruption bug where manually pre-escaping newlines before $wpdb->_real_escape() (which already does this) caused restored text fields to contain literal backslash-n characters instead of real line breaks.

[3.0.2] - 2026-07-11

Fixed

• Plugin header validation error from the WordPress.org submission checker: Plugin URI and Author URI were both https://auroradragon.studio, and WP.org requires them to be distinct (one identifies the plugin, the other the author). Plugin URI now points to https://aurora.auroradragon.studio (the plugin's own marketing site); Author URI stays on the studio's root site.

[3.0.1] - 2026-07-11

Fixed

• WordPress.org Plugin Check compliance pass. Ran the official Plugin Check tool ahead of submission and fixed every real issue it surfaced (257 flagged items, several dozen real):
  • WidgetsData.php: replaced the forbidden wp_get_sidebars_widgets() (internal-only core function) with a local helper reading the sidebars_widgets option directly.
  • FileManagerData.php: converted every raw filesystem call (move_uploaded_file(), mkdir(), rename(), unlink(), rmdir(), is_writable(), readfile()) to the WP_Filesystem API, which works across hosting setups that don't allow direct filesystem access. move_uploaded_file()'s upload-tampering check is preserved via an explicit is_uploaded_file() call before handing off to WP_Filesystem::move().
  • BugReportData.php: parse_url() → wp_parse_url().
  • SubApps.php: fixed a translation-function rule violation (page titles now wrapped in __() at definition instead of being passed as a variable to __() at the call site) and added justified nonce-check suppressions on two read-only routing checks.
  • Fixed missing wp_unslash()/sanitization on a handful of superglobal reads (Analytics.php, Shell.php, AnalyticsData.php) and added missing translator comments for two placeholder strings.
  • Annotated dynamic-table-name SQL queries across MediaFolders.php, AnalyticsData.php, DatabaseExplorerData.php, NoticesData.php, MenuCreatorData.php, and ActivityLogData.php with justified phpcs:ignore comments — every flagged table name comes from an internal $wpdb->prefix-based helper, never user input, and table identifiers can't go through $wpdb->prepare()'s value placeholders (WordPress core has no API for arbitrary custom tables).
  • Removed the stale Domain Path: /languages/ plugin header (pointed at a folder that's never existed — see 2.x-era removal of the fake "13 languages" marketing claim).
  • All changes live-verified against the LocalWP install: File Manager's full create/rename/delete cycle exercised directly against the REST routes (folder create, file create, rename, soft-delete, empty trash), Widgets' sidebar-read endpoint, Database Explorer's table browsing, and Media Folders' filtered listing all confirmed working with zero console/PHP errors.

[3.0.0] - 2026-07-06

Removed

• The entire licensing/monetization system. Aurora Admin is being given away free on the WordPress.org plugin repository — every feature previously gated behind a paid license (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) and bin/build-integrity-manifest.php.
  • Deleted the "Pro feature" upgrade-prompt UI (UpgradeNotice.vue, locked-feature.js) and every lock badge in the sidebar.
  • Removed the License key field and the dev-only "Simulate active license" toggle from Settings — there's nothing left to license or simulate.
  • license_key and dev_license_override are actively purged from any site's stored settings on upgrade (same cleanup pattern used for the earlier Remote Site Switcher removal), not just hidden from the UI.
  • 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 (beta licenses, Pro purchases) — that server-side system is untouched and unaffected by this change, it's simply no longer wired into this codebase.

[2.27.0] - 2026-07-06

Added

• Restored the dev-only license override (AURORA_ADMIN_DEV_MODE wp-config.php constant + Settings > Developer > "Simulate active license" toggle), reversing the 2.25.0 removal. Requested explicitly for local testing on admin.local — lets Pro features be exercised without a real license key. This must be stripped again before the next release/beta build — same standing rule as before, now re-documented in PROJECT_STATUS.md. Only has any effect when AURORA_ADMIN_DEV_MODE is defined truthy in a given install's own wp-config.php, never set in the repo or any built zip.

[2.26.0] - 2026-07-05

Added

• "Report a Bug" page (Aurora sidebar section), a real WordPress admin page (aurora-admin-bug-report, registered via SubApps.php like Menu Creator/Admin Notices) with a single free-text field plus auto-filled, read-only diagnostics (plugin version, WordPress version, PHP version, active theme, last 4 characters of the license key — not the full key). Submits to a new POST aurora-admin/v1/bug-report REST route (admin/src/Rest/BugReportData.php), which forwards to a new License::submit_bug_report() method that calls the license server.
  • License server (aurora-licensing plugin, not this repo): added a wp_aurora_bug_reports table (DB version 3 → 4, same version-gated migration idiom) and a new public POST /report-bug REST route, storing the description plus whatever license key/domain/diagnostics fields were sent. Deliberately a plain wpdb->insert with no admin UI yet — reports are reviewable via wp db query for now; a dashboard can come later if report volume justifies it.
  • Verified live end-to-end (not mocked): submitted a real report through the actual Report a Bug page, confirmed it landed correctly in wp_aurora_bug_reports on the production server, then deleted the two test rows (one from an earlier curl smoke test) by exact ID.

[2.25.0] - 2026-07-05

Removed

• Dev-mode license override (AURORA_ADMIN_DEV_MODE wp-config.php constant, Settings > Developer category's toggle, and every call-site in License::is_active()/is_feature_available()) — this was a build-time-only escape hatch for testing paid features without a live license, marked in PROJECT_STATUS.md as "MUST BE REMOVED BEFORE A RELEASE BUILD" since it shipped in the plugin zip. Real beta testers are about to install real builds, so it had to go before that zip goes out. Paid features now gate purely on License::is_active() for everyone, no exceptions.

[2.24.0] - 2026-07-05

Added

• Beta tester license support, end to end. User asked for 10 new 30-day beta licenses plus a way to flag/display beta status in the plugin.
  • License server (aurora-licensing plugin on the live auroraplugins.com box, not this repo): added an is_beta column to wp_aurora_licenses (migrated in place via a plugins_loaded-hooked check, since the file was updated without re-activation — same version-gated migration idiom this plugin's own ActivityLog.php etc. use), a wp aurora-lic generate-beta <count> [--days=<n>] [--max-sites=<n>] WP-CLI command (not a public REST route — generating free licenses has to stay admin/shell-only), and is_beta added to /validate and /activate's response payloads. Generated the 10 requested keys (30-day expiry, 1 site each) — see the conversation for the actual key list; not duplicated here since this file ships to customers.
  • Client (this plugin): License::is_beta_tester() reads the server's is_beta flag (already flowing through the existing status() cache — no new caching logic needed). Settings > General's license status line now shows "Beta Tester license active — expires in N days (date)" instead of the normal "License active (plan)" text when a beta key is active. A beta license is a real, fully-functional is_active() license like any other — this is a display flag only, not a separate gating path.
  • Verified against the real production license server, not a mock: generated a real key via the new CLI command, activated it from the dev site's actual Settings page, confirmed the badge and expiry countdown render correctly, then cleared the key (deactivating it server-side via the existing on_settings_updated flow).

[2.23.0] - 2026-07-05

Added

• Full field-set parity for Writing/Reading/Discussion native Settings screens, closing the gap flagged in 2.22.0's audit.
  • Writing: Default Post Category and Default Post Format are now real dropdowns (populated from get_categories()/ get_post_format_strings()) instead of raw numeric IDs. Added use_smilies — registered in core's own REST settings schema but never actually added to this screen.
  • Reading: Homepage/Posts Page are now page-title dropdowns (via get_pages()) instead of raw page IDs, and only appear once "Homepage Displays" is set to "A static page" — matching native WordPress's own conditional reveal. New generic showIf field property in NativeSettings.vue ({key, equals}) drives this, reusable by any future field.
  • Discussion: went from 2 fields to full native parity (~24 fields: pingback/comment defaults, moderation rules, threaded-comment settings, pagination, three notification-email toggles, comment moderation/disallowed-keys blocklists, and avatar settings). Core's REST settings schema (register_initial_settings()) only ever exposed 2 of Discussion's real options — everything else needed a new dedicated controller, DiscussionData.php, doing raw get_option()/ update_option() reads/writes against an explicit key allowlist (same pattern as PermalinksData.php, generalized to many keys instead of one).
  • New textarea field type in SettingsField.vue for the two moderation-keys blocklist fields (multi-line plain text — nothing else on any settings screen needed one until now).
  • Verified live: dropdowns populate with real data, conditional fields show/hide correctly, and a real save-then-reload round trip on Discussion (toggled a setting off, saved, reloaded fresh, confirmed the change persisted) — not just an optimistic-UI check.

[2.22.0] - 2026-07-05

Full plugin audit, requested after the plugin-delete crash raised the question of what else might be broken or incomplete. Checked every sidebar screen live (console + PHP error log at each stop), re-verified the license-activation claim from last session against the actual code, and closed the one remaining documented security gap.

Fixed

• REST-bypass gap closed for Role Editor, Activity Log, and Database Explorer — their REST controllers only checked current_user_can('manage_options'), not the license, so a direct REST call could reach paid functionality (including Database Explorer's raw SQL runner) with no license at all. Same fix already applied to File Manager/Media Folders earlier this session, just never circled back for these three. Verified every other paid-feature REST controller (Themes, Nav Menus, Widgets, Permalinks, Analytics, White Label) already had the check — this was the last of them.
• Permalinks screen was missing the standard structure presets (Plain, Day and name, Month and name, Numeric, Post name) — only the raw "Custom Structure" text field existed, which is the one part of that screen almost nobody actually uses by hand. Added the five presets as radio options with live example URLs, auto-detecting which preset (or "Custom") matches the currently-saved structure.

Verified (no changes needed)

• Clicked through Dashboard, Posts, Pages, Media, Users, Comments, Plugins, all Aurora sub-apps (Menu Creator, Admin Notices, Role Editor, Activity Log, Database Explorer, File Manager), Media Upload, Add New User, Profile, all 5 native Settings screens, and several Aurora Settings categories (General, White Label, Analytics) — no fatals, no new console errors anywhere in the pass.
• Confirmed License.php's activation/validation flow is real (calls auroraplugins.com's REST API, caches with TTL, tamper-checks) — corrected a stale "still a placeholder" claim from earlier this session and removed the outdated doc line that caused it.

Known gaps (not fixed — flagged for a decision, not silently patched)

• Writing/Reading/Discussion native Settings screens expose only a handful of fields each, several as raw text/numeric-ID inputs where native WordPress has dropdowns (post category, post format, homepage page picker) — functional but poor UX, and Discussion in particular is missing most of its native moderation options. Larger effort than the Permalinks fix; needs new endpoints (categories list, post formats) and new field types, not just a values tweak.
• Comments list's pagination footer shows "0 to 0 of 0" despite the "All" tab correctly showing a count — cosmetic, not investigated further.

[2.21.2] - 2026-07-05

Fixed

• Deleting a plugin from Aurora's Plugins page ("major issue" per user report) fataled the whole site with WordPress's generic "There has been a critical error" page instead of actually deleting anything. Root cause, found in the PHP error log: PluginsData::delete_plugin() called core's delete_plugins(), which internally calls request_filesystem_credentials() (WP_Filesystem setup) — that function lives in wp-admin/includes/file.php, which a REST API request doesn't load the way a normal wp-admin page load does, and delete_plugin() only required plugin.php. update_plugin() right below it already required file.php for the same underlying reason; delete_plugin() just never got the same fix. Verified live: deleted a real plugin (WP File Manager) end to end with no fatal, "Plugin deleted." message shown correctly, confirmed no new error logged.

[2.21.1] - 2026-07-05

Fixed

• Sidebar section accordion closed the wrong section on "hidden child" native screens (theme-install.php, media-new.php, user-new.php, ...). User: expand Appearance, click "Add New Theme", and the Appearance section collapsed while the "AURORA" section at the bottom opened instead — this was a different bug than the overlay-covers-the-sidebar issue fixed in 2.21.0, this was specifically about which section stays expanded. Root cause: Sidebar.vue's accordion decides the open section by matching the current URL against each menu item's own submenu array (MenuSerializer::serialize(), scraped from WP's $submenu global) — but these screens are deliberately absent from $submenu (WP's own native left menu doesn't list "Add New Theme" as a link either, only "Themes"/"Customize"/"Editor"), so no section ever matched and the accordion fell through to its Aurora-expanded default.
  • WP core itself solves this exact problem for its own native menu highlighting via a $parent_file global, set directly in each of these pages' own PHP (theme-install.php sets $parent_file = 'themes.php', media-new.php sets 'upload.php', user-new.php sets 'users.php') — reused that instead of hardcoding a list of "hidden child screen" mappings ourselves. Shell::print_mount() now reads it and passes it through as activeParentFile; Sidebar.vue's isSectionActive() treats a menu item as active when its id matches, alongside the existing exact-URL checks. General fix — covers any current or future WP core (or third-party plugin) screen using this same convention, not just the three confirmed here.

[2.21.0] - 2026-07-05

Changed

• The theme-install.php "Preview & Install" overlay (clicking a theme card under Appearance > Themes > Add New Theme) is now framed like the block editor window instead of covering Aurora's sidebar/toolbar entirely. User reported "it closes the menu" — confirmed this is WP core's own native behavior (the fullscreen overlay covers the native admin menu too, on a totally vanilla install), not a regression, but agreed a framed treatment was worth the risk for visual consistency with how the block editor is already handled.
  • .wp-full-overlay (WP core's overlay component, shared with the Customizer — only .theme-install-overlay specifically is touched, not .wp-full-overlay generally) is reframed to Aurora's standard inset box: the overlay itself plus its two independently position: fixed children (.wp-full-overlay-sidebar, .wp-full-overlay-main) each need the same left/top/bottom math applied directly, since fixed descendants don't inherit an ancestor's padding-box positioning the way absolutely-positioned ones do. margin-left on .expanded/.collapsed mirrors WP core's own three responsive breakpoints with Aurora's frame offset added on top, so the sidebar collapse/expand slide animation keeps working unmodified.
  • Root-caused and fixed two real bugs found while building this: (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 set back to visible — Aurora's entire shell inherited that hidden visibility too (nested in body), which is what silently erased the sidebar/toolbar instead of just having them covered. Fixed with one override re-enabling visibility for Aurora's own root specifically. (2) The overlay's own height: 100% (WP core) combined with our top+bottom insets was the exact same over-constrained-box bug already known from the block editor's .interface-interface-skeleton — same height: auto !important fix.
  • The traffic-light winbar needed a permanently-running MutationObserver rather than a one-shot check: the overlay doesn't exist in the initial DOM (WP core creates it lazily on first click), and every subsequent theme selection fully re-renders the overlay's contents, wiping out anything inserted into it — confirmed live (bar present after the first click, gone after picking a second theme) before switching to an idempotent "ensure inserted" observer callback.
  • Verified live end-to-end: opening via natural clicks (not just direct URL navigation), switching between themes with the prev/next arrows (triggers the content-destroying re-render), closing and confirming the sidebar/toolbar return correctly, no console errors at any step.

[2.20.2] - 2026-07-05

Fixed

• Appearance > Themes was missing two capabilities the native Themes screen has: browsing/installing themes from the WordPress.org directory, and uploading a theme zip. AppearancePages.php's load-themes.php hijack never passed a link to theme-install.php (only customizeUrl), so there was no way to reach either from Aurora's Themes page. Themes.vue gains an "Add New Theme" button (next to Customize) linking to native theme-install.php, gated on current_user_can('install_themes') — that native screen already has both the WordPress.org browser (Popular/ Latest/Block Themes/Favorites/Feature Filter tabs, search) and an "Upload Theme" button built in, so neither needed rebuilding. Same reuse-native-flow-for-add pattern already used for Plugins' addUrl (plugin-install.php) and Media's newMediaUrl (media-new.php).

[2.20.1] - 2026-07-05

Fixed

• Font Library (font-library.php) rendered with a jarring mix of Aurora's dark frame around a completely white, near-unreadable content area (light text on a white card). WP 6.5+ built this screen on @wordpress/ components' newer "boot-layout" primitives instead of classic postbox markup, so native-dark.css's existing postbox/card rules never matched its DOM. Added targeted dark-theme coverage for the screen's stable, hand-authored class names (.boot-layout-container, .boot-layout__stage, .admin-ui-page, .admin-ui-navigable-region, .admin-ui-page__header, .font-library-page__tab-panel, .font-library__tabpanel-layout, .font-library__footer, .font-library__fonts-list-item, .font-library__font-card) — deliberately not touching this screen's Emotion-generated hash classes (e.g. css-qi2azi), which aren't stable across WP builds.
• Regenerated admin/src/Licensing/integrity-manifest.json and rebuilt dist/aurora-admin-v2.zip from a fresh staging copy — the protected files' checksums (Integrity::is_tampered()'s manifest) had gone stale after this session's edits to aurora-admin.php, Shell.php, and others. Also excluded .claude/ from the staged copy — the internal tooling config had been getting bundled into the distributable zip.

[2.20.0] - 2026-07-05

Added

• Media Folders (paid — License::PAID_FEATURES["media-folders"]): a folder tree for the Media Library, duplicating the organizing capability of the FileBird Pro plugin at the user's request, with its own independent schema (wp_aurora_media_folders / wp_aurora_media_folder_items, distinct from FileBird's own wp_fbv* tables so both can coexist) rather than importing FileBird's data.
  • New MediaFolders.php model (create/rename/delete/reparent, one folder per attachment) + MediaFolderData.php REST routes (/media-folders, /media-folders/assign), every route double-gated (current_user_can + License::is_feature_available) per this project's established REST-bypass-hardening pattern.
  • Media.vue gains a folder sidebar (MediaFolderTree.vue): create, rename, delete, right-click context menu, drag-and-drop reparenting, and drag-and-drop (or a "Move to folder" fallback) to file media into folders. "All Media" and "Uncategorized" are pinned pseudo-folders.
  • The Media Library page itself stays free/ungated either way — only the folder capability is paid. Unlicensed users keep today's flat grid unchanged; the sidebar shows an inline UpgradeNotice instead of disappearing or locking the whole page — a new gating shape for this codebase (previously: whole sub-app free or whole sub-app paid).

Fixed

• Shell::is_own_page() didn't recognize ScreenHijack-based pages (Posts, Pages, Media, Users, Comments — they keep their native URL, no ?page=aurora-admin to key off), so it misclassified them as native pages and loaded native-dark.css's own-page exclusion incorrectly, letting that stylesheet's generic a color rule leak into the real Aurora UI. Invisible until now because no earlier hijacked page rendered a link relying on accent/contrast coloring — Media Folders' new "Enter a license key" CTA in the unlicensed sidebar was the first. ScreenHijack::register() now flags is_hijack_active() the moment any registered hijack activates for the current request, and is_own_page() checks it.

[2.19.0] - 2026-07-05

Removed

• Remote Site Switcher: the Settings > General "Remote Sites" repeater and "Remote Site Switcher Capability" field, and the toolbar dropdown they fed. User asked what it did; investigation found it was inert scaffolding — it collected and stored a remote site's URL/username/application password, but nothing anywhere in the codebase ever used the credentials (no REST calls, no proxying, no SSO). The toolbar "switcher" was just a plain link opening the remote site's own /wp-admin/ in a new tab. User's call: "doesn't really do much for the software" — removed rather than built out, since a real cross-site integration wasn't the ask.
• License::PAID_FEATURES["remote-site-switcher"] — the feature's paid gate, now dead code since the feature itself is gone.

Added

• Settings::remove_retired_keys() — actively deletes now-unused settings keys from the database on init, rather than leaving them inertly stored. Added specifically because remote_sites held a real secret (WordPress application passwords); once the field stopped being read or written, the safer move was to purge it, not just stop touching it.

[2.18.0] - 2026-07-05

Added

• Role Editor: an info icon next to every capability checkbox, with a hover tooltip explaining what it actually does — user asked directly, pointing at level_0/level_1 as an example of capabilities with no explanation anywhere in the UI. New capabilityDescriptions.js covers all ~55 WordPress core capabilities (edit_posts, manage_options, unfiltered_html, etc.) plus the legacy level_0–level_10 "user level" system specifically — a pre-2.0 permissions scheme WordPress still assigns to every default role purely for backward compatibility with old themes/plugins that check current_user_can('level_N') directly instead of a named capability; core itself hasn't checked a level in years. Any capability not in the dictionary (e.g. one added by another plugin) gets a generic "custom capability" fallback rather than showing nothing. Verified live: hovering level_0's info icon on the Subscriber role shows the explanation described above.

[2.17.2] - 2026-07-05

Fixed

• AppListShell.vue (the shared master/detail layout used by Database Explorer, Role Editor, Activity Log, Admin Notices, and Menu Creator): the list pane and detail pane shared one page-level scroll instead of scrolling independently. Selecting an item near the bottom of a long list (e.g. Database Explorer's 40 tables) left the detail panel's newly-loaded content rendered off-screen above the current scroll position — looked like nothing happened until you scrolled all the way back up. Root cause: the shell only set a min-height on the outer flex container, so it just grew with content instead of giving each pane a capped height + its own scrollbar. Fixed by giving the container a real height and both panes height: 100%; overflow-y: auto, with a separate mobile-breakpoint treatment (stacked panes get natural height with their own max-height instead of squashing to 50/50). Verified live: scrolled Database Explorer's table list to the bottom, selected wp_users, confirmed its data appeared immediately without scrolling.

[2.17.1] - 2026-07-05

Fixed

• File Manager's right-click context menu never appeared for real users (it worked in earlier automated testing, which turned out to be triggering the bug's absence rather than confirming its fix). Root cause: right-clicking — especially via a trackpad's 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 "click anywhere else closes it" listener was attached synchronously the moment the menu opened, so that trailing click closed it in the same tick it appeared — a real race condition, not a rendering bug. Fixed by deferring the outside-click listener's registration by one tick (setTimeout(..., 0)) so it only starts listening after the opening event has fully finished. Verified by simulating the exact race (contextmenu immediately followed by click on the same element, same tick) and confirming the menu stays open; also confirmed a genuine later click still closes it.

[2.17.0] - 2026-07-05

Added

• File Manager: right-click context menu, mirroring the toolbar exactly (same functions, just a different trigger) so the two can't drift out of sync. Right-clicking an item outside the current selection selects just that item first (standard file-manager behavior); right-clicking within an existing multi-selection leaves it intact so bulk actions still work from the menu. Right-clicking empty space shows folder-level actions (New Folder/File, Upload, Paste) instead. Closes on Escape or a click anywhere else.
• File Manager: the plain <textarea> editor is now a real code editor (CodeMirror 6 — codemirror + per-language packages for JS/TS, CSS, HTML, JSON, PHP, Markdown, XML, SQL), with syntax highlighting, line numbers, code folding, and active-line highlighting. Language is chosen by file extension; unrecognized extensions fall back to plain text rather than guessing wrong. Themed directly off Aurora's own CSS variables (not a hardcoded palette) so it matches whatever theme preset is active instead of looking like a foreign widget. Adds real bundle weight (~250KB gzipped) — only loaded when the File Manager page itself is opened, not part of the main admin bundle.
• Verified live: context menu appears correctly for both selection and empty-space cases with the right actions enabled/disabled, Escape closes it; PHP syntax highlighting confirmed rendering correctly on a real file (index.php — comments, strings, keywords all colored, doc-block folding visible).

[2.16.0] - 2026-07-05

Changed

• File Manager's actions consolidated into a single elFinder-style toolbar (back/forward/up navigation history, new folder/file, upload, copy/cut/paste, rename, trash, download/edit/info, list/grid view toggle, fullscreen, search) matching the layout of the "WP File Manager" reference plugin, replacing the previous split of header buttons + a per-row Actions column. Selection is now click-to-select (checkbox) + toolbar action, double-click to open a folder or editable file — the toolbar's buttons enable/disable based on what's currently selected (e.g. Rename/Info only with exactly one item selected, Download only for a single file).
• Move/copy switched from a destination-picker modal to clipboard-style copy/cut/paste — select item(s), click Copy or Cut, navigate anywhere (tree sidebar, breadcrumb, double-click into a folder), click Paste. A copy clipboard survives repeated pastes; a cut clipboard clears itself after the first successful paste. Same /file-manager/bulk endpoint underneath, just a different frontend trigger.
• Added a grid view (thumbnails/icons in a card layout) as an alternative to the list view, and a fullscreen toggle for the File Manager panel itself.
• Verified live: copy → navigate into a folder → paste (file appeared in the new location) → select → trash → confirmed removed; back-navigation and grid view toggle both confirmed working.

[2.15.0] - 2026-07-05

Added

• File Manager closed most of the feature gap against the reference "WP File Manager" plugin, adding everything that didn't carry the security risk of the already-excluded zip/unzip and chmod features:
  • Move & copy between folders (copy_item/move_item), with same-containment checks as everything else plus a specific guard against moving/copying a folder into its own descendant. Name collisions at the destination get " (2)", " (3)", etc. appended rather than silently overwriting.
  • Multi-select + bulk actions — one /file-manager/bulk endpoint drives trash/move/copy across any number of selected items, reusing the exact same per-item logic as the single-item buttons so bulk behavior can't drift from what those do. Partial failures don't abort the rest — every path gets its own attempt, failures are reported back.
  • Trash instead of permanent delete — deleting now moves the item into a flat UUID-named folder under wp-content/uploads/aurora-admin-trash/ plus a JSON manifest (original path, name, type, deleted-at), rather than encoding the original path into the filename (nesting/special characters/length limits make that fragile). Trash view offers restore (recreates parent folders as needed, blocks if something's since taken the original spot), permanent delete, and empty-trash.
  • Folder tree sidebar — lazy-loaded (only fetches a folder's children when expanded) via the existing list endpoint filtered to directories, no new backend route needed. Reused as the destination picker for move/copy.
  • File info panel — read-only permissions/owner/size/dates/mime type via a new /file-manager/info endpoint; directory size is computed on-demand for this one-off request rather than for every row in the main list (would slow down browsing large folders for no benefit).
  • Image thumbnails — a new /file-manager/preview endpoint serves image files inline (not as an attachment) for use as an <img> src; no server-side resizing, just the extension allowlist + size cap every other endpoint here already uses.
  • Drag-and-drop upload (multiple files at once) and sortable columns (Name/Size/Modified, folders always first regardless of sort) — both frontend-only, no new backend surface.
  • Aurora's own trash folder is hidden from the normal browser view when listing wp-content/uploads — it's an implementation detail, not a real user-created folder.
  • Verified live: multi-select, info panel, and the full create → trash → restore round trip through the UI; copy/bulk-trash/empty-trash verified directly against the REST endpoints.
• Still deliberately not built (unchanged from the original scope decision): zip/unzip (zip-slip risk) and chmod/permissions editing (too easy to lock yourself out).

[2.14.0] - 2026-07-05

Added

• Developer-only license override for local testing — lets Pro features be tested without buying a license against the developer's own software. Settings > Developer's "Simulate active license" toggle treats every paid feature as fully licensed, bypassing both the real license check and the file-integrity tamper check. Two gates keep this from ever doing anything on a real install even if this code ships by accident: (1) it only has any effect at all when AURORA_ADMIN_DEV_MODE is defined truthy in wp-config.php — never set anywhere in this repo or the release zip, only in a local dev environment's own config — and (2) the Settings > Developer category itself only renders in the UI when that constant is present. This entire feature (the DEV_MODE_CONSTANT checks in License.php, the devModeAvailable flag in SettingsPage.php, and the "Developer" category in settingsConfig.js/Settings.vue) must be removed before packaging a release build — every touch point is marked DEV ONLY in comments. Verified live: toggling it on/off correctly unlocks/re-locks a Pro feature (Role Editor) end-to-end, including the sidebar's lock badge.

[2.13.1] - 2026-07-05

Fixed

• Every ScreenHijack-mounted page (Posts, Pages, Media, Users, Comments, the 5 native Settings screens, Media Upload, Add New User, Nav Menus, Themes, Widgets, Profile) was missing the traffic-light title bar and rendering outside the normal card frame — the DOM structure didn't match native/other Aurora pages. Root cause: WordPress prints <div id="wpbody"><div id="wpbody-content"> after the in_admin_header hook fires (confirmed directly in core's admin-header.php), but ScreenHijack.php started its output buffer on in_admin_header — so those wrapper divs' opening tags, and later their closing tags (printed before admin_footer fires), both ended up inside the buffer and got discarded along with the native content they were meant to replace. The mount div ended up a level too high in the DOM (a direct child of #wpcontent), which broke windowChrome.js's #wpbody-content-based traffic-light insertion and the shell's card framing CSS. Fixed by having ScreenHijack.php re-print the #wpbody/ #wpbody-content wrapper divs itself around the mount point, so the DOM matches what WordPress would have produced. Verified live on Posts, Media, Users, and Profile.

[2.13.0] - 2026-07-05

Added

• Sixth and final phase of the "full admin takeover" initiative: the block editor (post.php/post-new.php). Deliberately a reskin, not a rebuild — Gutenberg stays completely native, extending the framing windowChrome.js/shell-frame.css already had working (traffic-light dots overlaid on the editor). Added a "← Posts"/"← Pages" breadcrumb next to the dots, resolved from the post-type-{slug} body class WP core already adds to every post edit screen (needed since Posts/Pages moved off a fixed admin.php?page=... URL onto their native URLs earlier this phase, so there's no single URL to hardcode).
  • Caught and fixed a real bug while testing: the Site Editor (site-editor.php) shares the same block-editor-page body class the breadcrumb logic keyed off, but has no post-type-* class (it edits templates, not a post) — the original version defaulted to guessing "Posts" there, which was wrong. Now returns no breadcrumb at all when no post-type-* class is present, verified live on both the post editor (crumb shows, correct link) and the Site Editor (no crumb, nested-skeleton framing unaffected).
  • This is the last screen in the "full admin takeover" initiative's original 9-item build order. All 9 phases are now shipped.

[2.12.0] - 2026-07-05

Added

• Fifth phase of the "full admin takeover" initiative: Profile (profile.php), reskinning WordPress's own fields (name, contact info, bio) via core's /wp/v2/users/me REST route, plus a small new ProfileData.php route for password changes (core deliberately excludes password from its own REST schema). Free, gated by modern_users.
  • Deliberately does not attempt to host third-party plugin fields (2FA setup, WooCommerce customer fields, etc., added via the show_user_profile/personal_options hooks) — a Vue reskin has no safe way to render another plugin's raw HTML/JS. Instead, the hijack checks has_action('show_user_profile')/has_action('personal_options') at hijack time and falls through to the real native screen whenever either has a callback registered, rather than silently hiding those plugins' fields. Verified live both ways: installed a test mu-plugin hooking show_user_profile and confirmed the native screen renders instead of the reskin; removed it and confirmed the reskin returns.
  • Password changes re-issue the auth cookie immediately after wp_set_password() (which invalidates the current session, since it's derived in part from the password hash) — same as core's own user-edit.php does when you change your own password.

[2.11.0] - 2026-07-05

Added

• Fourth phase of the "full admin takeover" initiative: the Appearance batch. Nav Menus (nav-menus.php) and Widgets (widgets.php) are real, purpose-built replacements — not wired into the existing Menu Creator, which manages Aurora's own admin sidebar and turned out to be an unrelated feature despite the similar name. Themes (themes.php) is a real list/activate/delete replacement (ThemesData.php + Themes.vue). Theme Editor (theme-editor.php) redirects to the existing File Manager instead of getting a second in-browser file editor — building one would duplicate File Manager's exact RCE risk surface for no benefit. Tools, Import/Export, and Site Health are deliberately left un-hijacked; Shell's existing native-page framing already covers them and a full rebuild has no real value-add over core's own screens.
  • Widgets is deliberately simplified to reordering/moving/deactivating existing widget instances between sidebars — adding a brand-new instance of an arbitrary widget type still uses WordPress's own block-based widgets screen (each widget type owns its own default settings and form; genericizing that is a full editor's worth of scope on its own, same reasoning as not rebuilding the block editor).
  • Nav Menus supports the common paths: create/delete menus, add pages/posts/categories/custom links, reorder and indent/outdent (sub-menu) items, assign menus to theme locations.
  • All three (plus Native Settings, previously shipped) are gated by the full_admin_takeover master toggle and the "admin-takeover" paid feature; every new REST controller checks the license directly in its own permission_callback, not just at the page level.
• Fixed a real frontend bug caught while testing these against a 403 (no license): Themes.vue, Widgets.vue, and NavMenus.vue's fetch calls didn't check res.ok before treating the response body as the expected data shape — a REST error object ({code, message, data}) got rendered as if it were the actual list, producing bogus placeholder rows instead of a clear error message. All three now surface the real error.
• Verified live: Themes' activate/list/screenshot rendering confirmed working end-to-end (switched between all 3 installed themes); Nav Menus and Widgets' REST layer verified directly (create/add-item/list/delete round trip, real sidebar data) — the pages themselves couldn't be rendered in this dev environment since none of the 3 installed themes register classic nav-menu/widget support (all are block/FSE themes, which core itself refuses these screens for too — not a defect in the hijack).

[2.10.0] - 2026-07-05

Added

• Third phase of the "full admin takeover" initiative: Media Upload (media-new.php) and Add New User (user-new.php) are now hijacked in place. Both are Vue-only — no new PHP REST controllers — talking directly to core's own /wp/v2/media and /wp/v2/users REST routes, which already cover file upload and user creation. Free, gated by the same modern_media/modern_users toggles as their already-free list-view companions (no reason to paywall mid-workflow between "browse" and "add"). Verified live end-to-end: created a real user and confirmed it appears in the Users list.

[2.9.0] - 2026-07-05

Added

• Second phase of the "full admin takeover" initiative: the 5 native Settings screens (General, Writing, Reading, Discussion, Permalinks) are now hijacked in place (NativeSettingsPages.php), sharing one generic Vue page (NativeSettings.vue) driven by a per-screen field schema. Most fields read/write through core's own /wp/v2/settings REST route; Permalinks has no core REST route for rewrite rules, so it gets its own small PermalinksData.php controller instead (calls $wp_rewrite->set_permalink_structure() + flush_rules(), same as core's own settings page does).
• New master toggle, Settings > Admin Takeover > "Full admin takeover" (default off — these new areas cover more ground and carry more risk than the already-migrated Posts/Pages/Media/Users/Comments, so opt-in rather than on by default), plus a new "admin-takeover" paid feature key. Every new REST controller in this phase checks License::is_feature_available("admin-takeover") directly in its own permission_callback, not just at the page level — the same defense the File Manager REST controller already has, verified live by confirming a direct REST call still 403s with the setting on but no license.
• SettingsField.vue (shared by the main Settings page and the new native Settings screens) gained two small additions: readonly support on text fields (Site Address shouldn't be editable inline) and a select field type (a plain dropdown, distinct from the existing multiselect checkbox list) — both minimal, generically useful additions, not one-offs.

[2.8.0] - 2026-07-05

Added

• First phase of the "full admin takeover" initiative: Posts, Pages, Media Library, Users, and Comments no longer redirect to a separate admin.php?page=... URL — they now hijack their native screens in place (ScreenHijack.php, registered via HijackedNativePages.php), the same approach the original uixpress reference plugin used. WordPress's load-{page}.php hook fires before the native screen prints anything, so Aurora buffers and discards the native output and mounts its own Vue page in its place — the URL never changes, so there's no separate slug that can fall out of sync with a plugin's own redirect, a bookmark, or any other direct visit. This is exactly the bug class already hit and fixed once for Plugins; the other five pages are now structurally immune to it. Plugins itself stays on the redirect mechanism — plugins.php prints output in a way that can't be cleanly buffered, confirmed by the reference plugin's own abandoned attempt at hijacking it.
• Existing REST controllers and Vue pages for all five are unchanged — only the mounting mechanism moved.

[2.7.2] - 2026-07-05

Fixed

• Installing/activating a plugin dropped back to the native WordPress Plugins page instead of staying in Aurora's UI, until the sidebar's "Plugins" link was clicked again. Unlike Posts/Pages/Media/Users/ Comments, Plugins only ever had its sidebar link rewritten (MenuSerializer.php) — there was no redirect_native_pages() case for direct visits to plugins.php, which is exactly what WordPress's own post-activate/post-install redirect does (wp_redirect(self_admin_url('plugins.php?activate=true')), no ?page= param). Added the missing case, matching the pattern already used for the other four pages.

[2.7.1] - 2026-07-05

Fixed

• Native form fields (text inputs, textareas, selects) on several classic/non-block-editor screens — most visibly the title field on the Edit Media screen, but the same fix applies wherever it occurred — were showing stark white, breaking the dark theme. Root cause: some native WP screens style specific fields via a 2-ID selector (e.g. core's #titlediv #title { background: #fff }), which beats our existing rule's single #wpbody-content id no matter how many classes are stacked on it — the exact same CSS-specificity trap as an earlier block-editor background bug. Added !important to the form-field rule block, since there's no legitimate case where a native admin form field should stay white.

[2.7.0] - 2026-07-05

Added

• New File Manager (aurora-admin-file-manager), browsing/editing the WordPress install's own files — built fresh (not embedding elFinder), in the spirit of the "WP File Manager" plugin already on this site (same root, same manage_options-only gate). Create/upload/download/ rename/delete files and folders, plus a plain-text editor for code/config files. A Pro feature — the riskiest surface in the whole plugin (arbitrary read/write access to the site's own PHP files), so it's gated the same way as Database Explorer.
  • Every path a client sends is resolved to a real, ABSPATH-contained path via realpath() before any filesystem operation — containment is checked against the resolved path, not string-matched against the raw input, so symlink tricks and encoded traversal can't slip past.
  • Uploads/new files/renames all reject a blocklist of server-executable extensions (.php, .phtml, .cgi, .sh, etc.) — the single most important control here, since uploading a webshell is the whole ballgame.
  • Deliberately not built: zip/unzip (zip-slip extraction vulnerability), chmod/permissions editing, and cross-directory move/copy — each is a meaningfully larger, riskier scope than a first pass warrants.

Fixed

• File Manager's REST endpoints now also check License::is_feature_available('file-manager'), not just manage_options — found while wiring it up that the page-level lock alone doesn't stop a direct REST call from bypassing it entirely. The same gap exists in Database Explorer, Role Editor, and Activity Log's REST controllers and is not yet fixed — flagged as a follow-up.

[2.6.0] - 2026-07-05

Added

• Real replacement pages for Pages, Media Library, and Users — the remaining native admin screens that were only dark-themed skinning, now built the same way as Posts/Comments/Plugins (own REST controller, own Vue page, native screen redirected away):
  • Pages (PagesData.php + Pages.vue): same as Posts, but shows the parent page instead of categories. edit.php?post_type=page redirects; other post types are untouched.
  • Media Library (MediaData.php + Media.vue): a thumbnail grid (not a rebuilt drag-drop uploader) with type filters (Images/Audio/ Video/Documents/Unattached), search, and delete. upload.php (both grid and list mode) redirects; media-new.php (the actual upload screen) is untouched, same reasoning as leaving the block editor alone for Posts/Pages.
  • Users (UsersData.php + Users.vue): filterable by role, with edit/delete actions. Deleting a user always reassigns their content to whoever performs the deletion, rather than exposing WP core's reassign-or-delete-everything choice as a one-click REST action — deliberately simplified to avoid a surprising, highly destructive default. users.php redirects; user-new.php (account creation) is untouched.
  • All four gated by their own Settings toggle (modern_pages, modern_media, modern_users — modern_posts already existed), each defaulting to on.

[2.5.0] - 2026-07-05

Added

• Real replacement Posts management page (aurora-admin-posts), the same kind of full custom page as Comments/Plugins rather than dark-themed skinning over the native edit.php list table. New PostsData.php REST controller (list with status/search filters, trash, restore, permanent delete) and a new Vue page matching the Comments layout (status filter pills, search, table with title/author/categories/comments/date/status, inline row actions, pagination). The native Posts screen (edit.php, default post type only — Pages and other post types are untouched) redirects to it, gated by Settings > Posts' restored "Modern posts table" toggle (removed a few commits ago when it had no implementation behind it — now it does).

Fixed

• The modern_plugins/modern_comments settings toggles now default to visually "on" in the Settings UI to match their actual PHP default (previously they defaulted true server-side but showed off in the UI until explicitly saved) — same fix applied to the new modern_posts.

[2.4.2] - 2026-07-04

Fixed

• Admin Notices only ever showed on the Aurora Dashboard — everywhere else, admin_notices fired normally, but on the Dashboard specifically the notice was invisible: DashboardTakeover hides #wpbody entirely there (to hide the native dashboard, not our own), and that's exactly where WordPress prints admin_notices output. Notices now render directly inside the Aurora dashboard frame instead on that one page. Along the way, also worked around a separate WordPress core behavior (common.js unconditionally relocates every .notice element to right after the page's <h1>) using core's own documented below-h2 opt-out class, since without it the notice would've just been silently moved back into the hidden #wpbody by that script regardless of where it was placed server-side.

[2.4.1] - 2026-07-04

Fixed

• Dashboard scrolling was broken — content below the first ~1500px (Server Health, Media Analytics, etc.) was completely unreachable. .aurora-dashboard-frame never got the height cap + internal scroll treatment #wpbody-content got in an earlier fix; combined with html/body being locked to overflow: hidden (to fix a phantom scrollbar on a different page), there was no scroll mechanism left at all for the dashboard specifically. Mirrored the same max-height/overflow-y treatment onto .aurora-dashboard-frame.

[2.4.0] - 2026-07-04

Added

• Settings > Menu's "Menu search" toggle now actually does something — previously had no implementation at all. Shows a real search box at the top of the sidebar that filters both the WP-native menu list and the Aurora nav section by title, auto-expanding every section with a match.

Fixed

• Settings > Dashboard's "Custom dashboard" toggle now actually gates the dashboard takeover — previously the Aurora dashboard always replaced the native one regardless of this setting, with no way to turn it back off.
• Settings > Plugins' "Modern plugins page" and Settings > Comments' "Modern comments page" toggles now actually gate their respective takeovers/redirects the same way — previously both ran unconditionally regardless of these settings.

Removed

• Settings > Posts' "Modern posts table" and Settings > Users' "Modern users page" toggles — both described a custom management interface that was never built. Shipping a checkbox with nothing behind it is worse than not having the checkbox; removed rather than left as dead UI. Their categories are removed too, since they had no other fields.

[2.3.1] - 2026-07-04

Fixed

• Sidebar accordion now treats the "Aurora" branded nav section as part of the same single-open accordion as the WP-native menu list, instead of being the one exception that stayed open regardless of what else was expanded. Expanding any native section now collapses Aurora too, and vice versa.

[2.3.0] - 2026-07-04

Added

• Settings > Media's "Allow SVG uploads" toggle now actually does something — previously existed in the UI with no implementation behind it, so every SVG upload was rejected. Fixes both of WordPress's default blocks (the upload_mimes allowlist and the real-mime sniff that nulls out the file type for SVGs specifically), plus a PHP warning (wp_get_missing_image_subsizes() reading undefined width/height metadata keys that SVGs never had) that could otherwise corrupt the upload response on environments with warnings displayed inline. Also does basic sanitization on upload (strips <script> tags, inline event handler attributes, javascript: URIs) since SVG can carry executable content.

[2.2.0] - 2026-07-04

Added

• Settings > Login's "Style login page" and "Login logo" fields now actually do something — previously they existed in the UI with no implementation behind them at all. Styles wp-login.php with a dark theme (background, card, inputs, button) and swaps in the configured logo image in place of the WordPress logo, linked to the site's home URL instead of wordpress.org.

[2.1.1] - 2026-07-04

Fixed

• Image fields (Logo, Dark mode logo, Login logo, Admin favicon) now open the real WordPress media library picker. wp_enqueue_media() was never called, so wp.media was undefined client-side and every image field silently fell back to a plain URL prompt instead.

[2.1.0] - 2026-07-04

Added

• Free/paid feature gating: Role Editor, Activity Log, Database Explorer, Analytics, White Label, and the remote site switcher are now Pro features. Menu Creator, Admin Notices, Comments, Plugins, and the core shell/theming stay free. Locked pages show an upgrade prompt instead of the real feature; the sidebar shows a lock badge on locked items.
• Real license validation against the auroraplugins.com license server (validate/activate/deactivate), replacing the earlier placeholder that treated any non-empty key as active. Status is cached for 12 hours and re-checked immediately on a license-key change. The Settings page shows a live status line (active/invalid/unreachable) under the License key field.
• File-integrity tamper protection: if the code implementing the license gate has been modified, every paid feature re-locks regardless of an otherwise-valid license — makes stripping the check out of a redistributed copy not actually unlock anything.

Fixed

• Role Editor's REST endpoint 500'd when hit via the REST API — it called get_editable_roles(), which WordPress only auto-loads for normal wp-admin page requests, not REST requests.