Commit Graph
11 Commits
Author SHA1 Message Date
NixReaperandClaude Sonnet 5 24be114f9a Advance full admin takeover from v1.1 to v1.12
Batches everything built since the 1.0 WP.org submission reset: Login
Redirect, the Tools/Export/Import screen takeovers, Modules rebuilt as
an addon marketplace, Menu Creator's reorder fix, Activity Log
redesigned into a filterable table with Admin/User tabs, dark-theme
fixes for Site Health/Personal Data/Updates, and an opt-in Disable
Gutenberg toggle. Continues the "nothing stays native" takeover goal
and closes gaps found via live testing and the WordPress Plugin Check
tool. See CHANGELOG.md for the full per-version breakdown (1.1-1.12).

Co-Authored-By: Claude Sonnet 5 <[email protected]>
2026-07-26 13:37:35 -05:00
NixReaperandClaude Opus 4.8 e2db2ad4b5 Snapshot synced v3.6.1 working state as baseline
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]>
2026-07-12 08:41:18 -05:00
nixpanelandClaude Sonnet 5 07d77bda57 Fix Plugins dropping to native page after activating a plugin (v2.7.2)
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]>
2026-07-05 07:17:47 -05:00
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
nixpanelandClaude Sonnet 5 204c4365e2 Add real replacement pages for Pages, Media Library, and Users (v2.6.0)
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]>
2026-07-05 06:40:22 -05:00
nixpanelandClaude Sonnet 5 56b6674527 Add a real replacement Posts management page (v2.5.0)
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]>
2026-07-05 05:59:11 -05:00
nixpanelandClaude Sonnet 5 fb93888d3f Wire up remaining placeholder settings, implement menu search (v2.4.0)
- Custom dashboard, Modern plugins page, and Modern comments page
  toggles previously had no effect at all — their respective takeovers/
  redirects (DashboardTakeover, SubApps' Plugins/Comments handling,
  MenuSerializer's link rewrites) ran unconditionally regardless of the
  setting. All three now default to their previous always-on behavior
  but can actually be turned off.
- Menu search had zero implementation. Sidebar.vue now shows a real
  search box (gated on the setting) that filters both the WP-native menu
  and the Aurora nav section by title, auto-expanding matching sections.
- Removed "Modern posts table" and "Modern users page" toggles (and
  their now-empty Posts/Users settings categories) — both described a
  custom management page that was never built. A checkbox with nothing
  behind it is worse than no checkbox.

Verified all four live: dashboard/plugins/comments toggles correctly
flip between the Aurora and native experience and back; menu search
filters correctly and clears back to the full menu.

Co-Authored-By: Claude Sonnet 5 <[email protected]>
2026-07-04 09:35:00 -05:00
nixpanelandClaude Sonnet 5 6d502604d7 Add free/paid feature gating (Role Editor, Activity Log, DB Explorer,
Analytics, White Label, remote site switcher are paid)

- New License class is the single gate every paid feature checks —
  today it's a placeholder (any non-empty license_key counts as active)
  since there's no license server yet, but every gated feature already
  funnels through it so swapping in real remote validation later won't
  touch anything else.
- Role Editor, Activity Log, and Database Explorer stay registered/
  capability-checked as before, but render an UpgradeNotice screen
  instead of the real feature when unlicensed (and skip loading the
  real JS bundle/REST data). Menu Creator, Admin Notices, Comments,
  and Plugins stay free.
- Analytics' tracking hooks and REST endpoint, and White Label's
  favicon/rename/text-replace hooks, simply don't register without a
  license. Settings fields for both stay visible/editable either way.
- Remote site switcher gated alongside its existing capability check.
- Sidebar shows a small lock badge on locked Aurora nav items; the
  Dashboard's Analytics tab shows the same upgrade prompt when locked.
- Fixed an unrelated bug surfaced while testing Role Editor: RolesData's
  REST callback called get_editable_roles() without loading
  wp-admin/includes/user.php first, which REST requests don't get for
  free (only real wp-admin page loads do) — 500'd every time.

Co-Authored-By: Claude Sonnet 5 <[email protected]>
2026-07-03 19:59:00 -05:00
nixpanelandClaude Sonnet 5 8153d4397c Fix sub-app permissions bug, add Comments app, support Site Editor
- 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]>
2026-07-03 18:48:25 -05:00
nixpanelandClaude Sonnet 5 4a547d2c50 Add theme presets, gradient backgrounds, and macOS-style window chrome
Replaces the old light/dark toggle with 10 fixed color themes (plus
Black & Grey and White) that drive a coordinated gradient palette across
the whole admin UI, a Google Fonts picker, and a native-page dark-mode
stylesheet that now covers modals and plugin/theme card grids. Fixes
several background/gradient seams where the sidebar, toolbar, and content
frame were each painting their own independent copy of the page gradient
instead of sharing one continuous plane.

Also adds a macOS-style traffic-light title bar to every page (close,
minimize, maximize) and a persistent bottom taskbar so a minimized page
can be restored from anywhere, plus a Plugins management page.

Co-Authored-By: Claude Sonnet 5 <[email protected]>
2026-07-03 11:49:15 -05:00
Kris Parish 03cabe2fe4 Initial commit: Aurora Admin plugin 2026-07-03 02:53:29 -05:00