diff --git a/PROJECT_STATUS.md b/PROJECT_STATUS.md index 6cbaf22..ae2120b 100644 --- a/PROJECT_STATUS.md +++ b/PROJECT_STATUS.md @@ -1,6 +1,6 @@ # Aurora Admin v2 — Project Status -_Last updated: 2026-07-03 (evening session — theme system rebuild + window chrome)_ +_Last updated: 2026-07-03 (late session — Site Editor support, permissions bug fix, Comments sub-app, taskbar rewrite)_ ## What this project is @@ -179,17 +179,29 @@ not a hue applied on top of a shared light/dark base. `app/src/pages/settings/settingsConfig.js`, rendered by `app/src/pages/settings/components/SettingsField.vue` (types: text, toggle, color, image, repeater, multiselect, segmented, remote-sites). -- **5 sub-apps** (`admin/src/Pages/SubApps.php` + one PHP feature-class pair +- **6 sub-apps** (`admin/src/Pages/SubApps.php` + one PHP feature-class pair each + one Vue page + one Vite entry each) — reachable only via the sidebar's Aurora nav section, not the native WP menu: - - Registered via `add_submenu_page('aurora-admin', ...)` then immediately - `remove_submenu_page()`'d on a late `admin_menu` hook — the - register-but-hide trick: real page/capability/URL, but never appears in - WP's native `$submenu` global (so `MenuSerializer` never sees them, - nothing to filter there). + - Registered via `add_submenu_page('aurora-admin', ...)` (or `'plugins.php'` + for Plugins) and **left registered** in WP's native `$submenu` global — + **no longer hidden via `remove_submenu_page()`**. An earlier version did + call it (the standard register-but-hide trick) but that corrupts WP + core's own `user_can_access_admin_page()` capability lookup, which partly + depends on the page still being present in `$submenu` to resolve its + required capability — removing it caused "Sorry, you are not allowed to + access this page" for every user, including admins, on Menu Creator/ + Activity Log/Role Editor/Comments. Root-caused and fixed this session by + deleting `hide_from_native_submenu()` entirely; duplication in the + sidebar's native-menu section is instead prevented in + `MenuSerializer::serialize()` (see below), which has no such side effect. - All slugs prefixed `aurora-admin-*` so `Shell::is_own_page()`'s existing `strpos($page, "aurora-admin") === 0` check covers them for free (full - custom dark theme, `native-dark.css` skipped). + custom dark theme, `native-dark.css` skipped). `MenuSerializer::serialize()` + skips any submenu slug starting `aurora-admin-` (in addition to already + skipping the `aurora-admin` top-level slug) so none of them are + duplicated in the sidebar's native-menu section — needed because most are + parented under `aurora-admin` (already skipped wholesale) but + `aurora-admin-plugins` is parented under the real `plugins.php` menu. - Each page uses the shared two-pane layout `app/src/pages/_shared/AppListShell.vue` (generalized from Settings.vue's box-pair CSS) + `AppListItem.vue` for list rows. @@ -219,14 +231,18 @@ not a hue applied on top of a shared light/dark base. `GET /activity-log?action_type=&object_type=&search=&page=`. - **Plugins** (`admin/src/Rest/PluginsData.php` + `app/src/pages/plugins/Plugins.vue`): custom plugin management list (activate/deactivate/delete), also using - `AppListShell.vue`. **Known bug, unresolved**: unlike the other sub-apps, - Menu Creator/Activity Log/Role Editor currently throw WordPress's native - "Sorry, you are not allowed to access this page" for the logged-in admin - user when navigated to directly, while Settings/Plugins/Dashboard work - fine — likely a capability-check mismatch in how those three register - their submenu pages vs. the working ones. Not yet root-caused; a - background investigation task was spawned for it but not completed this - session — check for it before re-investigating from scratch. + `AppListShell.vue`. + - **Comments** (`admin/src/Rest/CommentsData.php` + `app/src/pages/comments/`): + newest sub-app, `edit_posts`-gated (not `manage_options` like the others). + `SubApps::redirect_native_pages()` (`admin_init`) redirects the native + `edit-comments.php` (when hit with no `?page=` param, i.e. a direct nav + or an old bookmark/menu link) to `admin.php?page=aurora-admin-comments`. + `MenuSerializer::resolve_url()` also maps the `edit-comments.php` slug + straight to the Aurora URL so the native-menu-derived sidebar entry (for + users who can `edit_posts` but not `manage_options`, so don't see the + Aurora nav section) still lands on the Aurora page. The Dashboard's + comments card (`DashboardData.php`'s `listUrl`) was updated to point at + the same Aurora URL instead of the native one. - **Database Explorer** (`admin/src/DatabaseExplorer/`): no custom table — reads real `$wpdb` schema. `GET /db-tables` (SHOW TABLE STATUS), `GET /db-tables/:table` (columns + paginated rows — table name validated @@ -273,61 +289,108 @@ not a hue applied on top of a shared light/dark base. Known gap: the plugin "More Details" popup renders inside an `