Files
aurora-wordpress-admin/CHANGELOG.md
T
nixpanelandClaude Sonnet 5 15d6060ae3 Add File Manager sub-app (Pro feature) (v2.7.0)
New browse/edit interface for the WordPress install's own files, built
using the installed "WP File Manager" plugin (elFinder-based) as a
functional reference rather than embedding it. Own REST controller
(FileManagerData.php) + Vue page, same pattern as every other sub-app.

Security is the whole point here (highest-risk surface in the plugin —
arbitrary filesystem read/write):
- Root is ABSPATH, manage_options-gated throughout.
- Every client path is resolved via realpath() and checked for root
  containment against the *resolved* path, not string-matched against
  the raw input — catches symlink tricks and encoded traversal that a
  naive "../" check would miss.
- Uploads/new files/renames reject a blocklist of server-executable
  extensions (.php, .cgi, .sh, etc.) — the single most important
  control, since uploading a webshell is the classic exploit path for
  this class of feature.
- Deliberately not built: zip/unzip (zip-slip vulnerability class),
  chmod/permissions editing, cross-directory move/copy.

Gated as a paid feature (riskier than Database Explorer, which is
already paid) — a judgment call flagged to the user, not something they
specified.

Also fixed a real bug found while wiring this up: SubApps.php's
page-level lock doesn't stop someone with manage_options from calling
the REST endpoints directly, bypassing the license check entirely.
File Manager's REST permission callbacks now also check
License::is_feature_available(). The same gap exists in Database
Explorer, Role Editor, and Activity Log's REST controllers and is
flagged as a follow-up task, not fixed here (out of scope for what was
asked, affects three unrelated features).

Verified live via direct REST calls: path traversal blocked (404),
blocked extensions rejected (400), root deletion blocked (400), and a
full create/write/read/rename/delete round trip succeeded cleanly.

Co-Authored-By: Claude Sonnet 5 <[email protected]>
2026-07-05 06:59:24 -05:00

203 lines
10 KiB
Markdown

# Changelog
All notable changes to Aurora Admin are documented here, one entry per
version bump. Starts at 2.1.0 — earlier history (the theming rebuild,
window chrome/taskbar, Site Editor support, etc.) lives in `git log` and
`PROJECT_STATUS.md`, not reconstructed here.
## [2.7.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.