Reworded "What this project is" to describe Aurora on its own terms and
dropped the stale uixpress/ folder archaeology from the Repo section.
Co-Authored-By: Claude Opus 4.8 <[email protected]>
Machine-sync snapshot: the working tree carried the full 3.0.0-3.6.1 arc
(licensing/FileManager/DatabaseExplorer removal, all new replacement screens
and REST controllers) that had not been committed on this machine. Captured
here as a safety baseline before starting the Adminify-parity revamp.
Co-Authored-By: Claude Opus 4.8 <[email protected]>
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 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, landing on the true native
page until the sidebar link was clicked again.
Added the missing case, gated by modern_plugins like the others,
redirecting to plugins.php?page=aurora-admin-plugins 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, confirmed with FileBird Lite showing Active in the list.
Co-Authored-By: Claude Sonnet 5 <[email protected]>
Native form fields (title inputs, textareas, selects) on screens that
don't use the block editor — most visibly Edit Media's title field —
were showing stark white, breaking the dark theme. WP core styles some
fields via a 2-ID selector (#titlediv #title { background: #fff }),
which beats native-dark.css's existing form-field rule regardless of
class count, same specificity trap as an earlier block-editor
background bug. Added !important to the whole form-field rule block —
safe everywhere, no legitimate case for a native admin field to stay
white.
Verified this one rule fixes Edit Media, Edit Post (classic fields),
and Comment edit simultaneously; Add User was already clean. The
WYSIWYG editor body staying white is a separate, deliberate decision
(matches the block editor's own canvas) and wasn't touched.
Co-Authored-By: Claude Sonnet 5 <[email protected]>
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]>
Completes the "skinned vs. replaced" conversion started with Posts —
every native list-table screen the user asked about now has a genuine
custom Vue page behind it instead of dark-themed CSS over the native
markup. All three follow the same pattern as Posts: own REST controller
in admin/src/Rest/, own Vue page matching the Comments layout, native
screen redirected away (direct visits too, not just the sidebar link),
gated by its own Settings toggle defaulting to on.
- Pages (PagesData.php + Pages.vue): same as Posts, parent page shown
instead of categories. edit.php?post_type=page redirects; other post
types untouched.
- Media Library (MediaData.php + Media.vue): thumbnail grid with type
filters (Images/Audio/Video/Documents/Unattached). Replaces the
browse/library experience only — 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. 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 action — deliberately simplified to avoid a surprising,
highly destructive default. user-new.php untouched.
Verified live: Media's grid renders real thumbnails/dimensions/file
sizes with working filters and search; Users shows real accounts with
role filters and correctly hides delete for the current user; both
redirect correctly from their native URLs.
Co-Authored-By: Claude Sonnet 5 <[email protected]>
Posts was previously just dark-themed skinning over the native
edit.php list table, unlike Comments/Plugins which are genuine
replacements. Built the same way: new PostsData.php REST controller
(list with status/search filters matching native tabs, trash, restore,
permanent delete) and a Vue page matching the Comments layout.
- SubApps.php registers it as aurora-admin-posts, parented under
edit.php (same pattern as Plugins under plugins.php).
- redirect_native_pages() redirects direct edit.php visits (typed URL,
not just the sidebar link) to the Aurora page — gated to the default
post type only, so Pages and other custom post types are untouched.
- MenuSerializer rewrites the sidebar's Posts/All Posts links the same
way Plugins/Comments already were.
- Gated by Settings > Posts' "Modern posts table" toggle, re-added now
that it has a real implementation (it was removed a few commits ago
for describing a feature that didn't exist).
- Fixed modern_plugins/modern_comments/modern_posts all defaulting to
visually "on" in the Settings UI to match their actual PHP default.
Verified live: trash/restore/status filters/search all work correctly,
edit.php redirects to the Aurora page, edit.php?post_type=page (Pages)
correctly does not.
Co-Authored-By: Claude Sonnet 5 <[email protected]>
admin_notices fires everywhere, but prints inside #wpbody, which
DashboardTakeover hides entirely on the Dashboard (to hide the *native*
dashboard, not ours) — notices went down with it as collateral damage.
Notices::render_for_dashboard() now renders directly inside the visible
dashboard frame instead, called from DashboardTakeover::render_mount();
the normal admin_notices path bails on the Dashboard so it isn't
rendered twice.
Second, independent bug found along the way: wp-admin/js/common.js
unconditionally relocates every .notice element on the page to right
after the page's <h1>, regardless of where it was placed server-side —
without opting out, it would've silently moved our notice right back
into the hidden #wpbody. Used core's own documented `below-h2` class to
opt out, only for the dashboard render path.
Verified live: notice now shows correctly inside the dashboard frame
with proper dark styling, and dismisses correctly.
Co-Authored-By: Claude Sonnet 5 <[email protected]>
- New Integrity class checksums the files that implement/enforce the
free/paid split (SubApps, Analytics, AnalyticsData, WhiteLabel, Shell,
License itself, and the two bootstrap files) against a manifest
generated at zip-build time. No manifest present (a dev checkout) is
never treated as tampered.
- License::is_feature_available() checks Integrity::is_tampered() before
checking the actual license, so a distributed copy with the check
stripped/commented out re-locks every paid feature even with an
otherwise-valid license, rather than the plugin trusting whatever code
happens to still be there.
- bin/build-integrity-manifest.php generates the manifest against a
staged zip-build copy (gitignored build artifact, same pattern as
app/dist) — now a required step in the zip-build workflow.
- Verified live: untampered+unlicensed stays locked, untampered+licensed
unlocks, one tampered file re-locks regardless of license status
(tested via a temporary mu-plugin faking an active license, kept
outside any protected file so it didn't itself trip the check).
This raises the bar against the realistic low-effort case (finding and
deleting/inverting the one license-check line) but can't stop someone who
rewrites a file's logic to never call the gate, or who edits this
integrity check itself — an inherent limit of protection living in plain,
editable PHP.
Co-Authored-By: Claude Sonnet 5 <[email protected]>
- License.php now calls the aurora-licensing plugin's REST API
(/wp-json/aurora-licensing/v1/validate|activate|deactivate) instead of
treating any non-empty license_key as active. Result is cached in the
aurora_admin_license_status option for 12 hours; is_active() and
is_feature_available() read the cache instead of hitting the network on
every admin page load.
- Hooks update_option_aurora_admin_settings to activate/deactivate
immediately when the license_key setting actually changes, rather than
waiting out the cache. Instantiated in AuroraAdmin.php so that hook
registers.
- Settings page now surfaces the real status (active/invalid/unreachable,
with the server's own message) as a status line under the License key
field, instead of a field that silently does nothing.
- Verified live against the real server: a fake test key correctly came
back locked with the server's own "License key not found." message.
Co-Authored-By: Claude Sonnet 5 <[email protected]>
- Apply the taskbar's max-height/overflow-y:auto treatment to
#wpbody-content unconditionally, so tall native/Aurora pages (Add
Plugins, Add User, Profile, Fonts, file editors, Settings, Activity Log,
Database Explorer, Comments) scroll internally within their frame
instead of growing past the viewport and scrolling the whole document.
- Fix a Chrome scroll-anchoring bug this surfaced on Add Plugins (page
loaded scrolled ~1700px into content instead of at the top) via
overflow-anchor: none.
- Fix a phantom document-level scrollbar with dead space below the frame
by locking html/body's own overflow, since the sidebar/toolbar are fixed
and content is only ever meant to scroll internally.
- Make the sidebar's native-menu sections a single-open accordion:
expanding one now collapses whichever else was open.
Co-Authored-By: Claude Sonnet 5 <[email protected]>
- Root-cause fix for "Sorry, you are not allowed to access this page" on
Menu Creator/Activity Log/Role Editor: remove_submenu_page() was
corrupting WP core's user_can_access_admin_page() capability lookup.
Sub-apps now stay registered in $submenu; MenuSerializer filters them
out of the sidebar instead.
- Add a 6th sub-app, Comments, with a redirect from native edit-comments.php.
- Extend the window-chrome/taskbar framing to the Site Editor
(site-editor.php), including a fix for a CSS position:fixed
over-constraint bug that let its frame run past the viewport.
- Rewrite the taskbar from a single sessionStorage slot to a list so
multiple minimized windows are each independently restorable.
- Extend native-dark.css coverage to the block editor's own chrome.
Co-Authored-By: Claude Sonnet 5 <[email protected]>
Documents this session's work: the new fixed-preset theme system
(gradients, the recurring "independently-painted gradient" seam bug
pattern), the macOS-style window chrome + taskbar feature, extended
native-page dark styling coverage, and the still-open sub-app permissions
bug.
Co-Authored-By: Claude Sonnet 5 <[email protected]>
