Update project status doc for the theme system rebuild and window chrome
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]>
This commit is contained in:
nixpanel
co-authored by
Claude Sonnet 5
Claude Sonnet 5
parent
4a547d2c50
commit
b0b0a9999a
+192
-35
@@ -1,6 +1,6 @@
|
||||
# Aurora Admin v2 — Project Status
|
||||
|
||||
_Last updated: 2026-07-03_
|
||||
_Last updated: 2026-07-03 (evening session — theme system rebuild + window chrome)_
|
||||
|
||||
## What this project is
|
||||
|
||||
@@ -34,20 +34,29 @@ get back up to speed instead of relying on prior chat history.
|
||||
Chrome MCP tools (`tabs_context_mcp`, `navigate`, `computer`/screenshot,
|
||||
`javascript_exec`) to inspect real DOM/computed styles rather than
|
||||
guessing from source.
|
||||
- **Zip packaging**: Windows `Compress-Archive` corrupts the WP upload
|
||||
(backslash path separators break PHP's unzip). Always build the zip via
|
||||
PowerShell `System.IO.Compression.ZipFile`, normalizing every entry path
|
||||
with `.Replace('\', '/')`. Full sequence used every time:
|
||||
1. `npm run build` in `app/`
|
||||
2. `robocopy` the whole `aurora-admin-v2/` tree into
|
||||
`aurora-admin-v2-dist/aurora-admin/` with `/MIR /XD node_modules .git`
|
||||
(exit code 3 = success, not an error)
|
||||
3. Rebuild `aurora-admin-v2-dist/aurora-admin-v2.zip` via the
|
||||
`System.IO.Compression.ZipFile` PowerShell snippet (see any recent
|
||||
commit's session for the exact script)
|
||||
4. User manually reinstalls the zip into WordPress — **the Chrome MCP
|
||||
`file_upload` tool cannot push arbitrary local files into the browser**,
|
||||
confirmed this session, so this step can't be automated.
|
||||
- **Zip packaging**: on macOS, build via `npm run build` in `app/`, `rsync`
|
||||
the repo (excluding `node_modules`, `.git`, `/dist`) into a scratch staging
|
||||
dir, then `zip -r -X` it into `dist/aurora-admin-v2.zip` — macOS `zip`
|
||||
produces forward-slash paths natively, no path-separator corruption issue
|
||||
like Windows `Compress-Archive`/PowerShell had. **Always delete the
|
||||
existing zip first** (`rm -f dist/aurora-admin-v2.zip`) — `zip -r` merges
|
||||
into an existing archive rather than replacing it, so stale entries (old
|
||||
content hashes) silently survive otherwise. If building on Windows again,
|
||||
the old PowerShell `System.IO.Compression.ZipFile` + `.Replace('\', '/')`
|
||||
approach from earlier sessions still applies.
|
||||
- **Fast local iteration**: the test site is LocalWP at
|
||||
`/Users/kris/Local Sites/aurora/app/public/wp-content/plugins/aurora-admin`.
|
||||
Instead of rezipping + manually reinstalling for every small CSS/JS tweak,
|
||||
hot-patch the built files straight into that install
|
||||
(`rm -rf app/dist && cp -R <repo>/app/dist app/dist`, or copy individual
|
||||
files like `admin/assets/native-dark.css`) and just reload the page in
|
||||
Chrome — near-instant feedback loop. Rezip properly (see above) once the
|
||||
change is confirmed, so the zip artifact matches what's live-verified.
|
||||
- User manually reinstalls the zip from a downloaded/attached copy when
|
||||
actually deploying — **the Chrome MCP `file_upload` tool cannot push
|
||||
arbitrary local files into the browser**, confirmed in an earlier session,
|
||||
so that step can't be automated. (Hot-patching, above, sidesteps this for
|
||||
local dev/verification.)
|
||||
- **Old build caching gotcha**: WordPress serves whatever plugin files were
|
||||
last installed — if the user says "didn't fix it," suspect a stale zip
|
||||
still installed before suspecting the code. Verify the live script hash via
|
||||
@@ -93,17 +102,68 @@ get back up to speed instead of relying on prior chat history.
|
||||
- `UserMenu.vue`: floating card that expands **upward** from a bottom-left
|
||||
trigger (avatar+name+chevron). Card contains: user header (avatar/name/
|
||||
email), links (Edit Profile → `profile.php`, Visit site, Site Settings →
|
||||
`options-general.php`, Sign Out in red), and a 3-way theme control.
|
||||
- Theme is a **3-state model**: `'light' | 'dark' | 'system'`, stored as
|
||||
that string in `settings.dark_mode` (old `'on'`/`'off'` values are
|
||||
migrated on read via `normalizeStoredTheme()` in `SiteShell.vue`).
|
||||
`system` tracks `matchMedia('(prefers-color-scheme: dark)')` live via a
|
||||
change listener. The theme control renders as 3 actual color swatches
|
||||
(white / near-black / diagonal split for light/dark/system) — **not**
|
||||
icons; an earlier icon-based version (sun/moon/gear) was explicitly
|
||||
replaced after user feedback that the gear "did nothing" visually.
|
||||
`options-general.php`, Sign Out in red). No theme control here anymore —
|
||||
see "Theme system" below; the old light/dark/system 3-way swatch picker
|
||||
and the `dark_mode` setting it drove are both gone entirely.
|
||||
- Old top-right toolbar user-dropdown and sun/moon toggle button are
|
||||
**removed** — fully replaced by the bottom-left `UserMenu`.
|
||||
- Sidebar is **inset**, not flush against the browser edge: fixed at
|
||||
`top/left/bottom: var(--aurora-sidebar-gap)` (16px), fully rounded
|
||||
corners, `background: var(--aurora-card-bg)` — floats as its own card
|
||||
over the page gradient. `--aurora-sidebar-gap` is a shared CSS var
|
||||
(`shell-frame.css`) that the toolbar's `left` offset and `#wpcontent`'s
|
||||
`margin-left` both add too, so nothing overlaps when the gap changes.
|
||||
|
||||
## Theme system (rewrite — supersedes the old dark_mode 3-state model)
|
||||
|
||||
Went through several rounds of user-directed rework this session, landing on:
|
||||
**10 fixed, named color presets + 2 flat neutrals ("Black & Grey", "White")
|
||||
— no custom color picker, no separate light/dark toggle.** Each preset is
|
||||
fully self-contained (its own coordinated backgrounds/cards/borders/text),
|
||||
not a hue applied on top of a shared light/dark base.
|
||||
|
||||
- `app/src/pages/settings/themePresets.js`: `themePresets` array (10 hue-based
|
||||
presets like `{ id: 'indigo', label: 'Indigo', hue: 235 }`, plus `mono` and
|
||||
`white` with an explicit `palette` object instead of a hue). `buildPalette(preset)`
|
||||
returns all `--aurora-*` tokens — for hue presets, computed via HSL ramps;
|
||||
for the two flat presets, returned as-is. `resolvePreset(id)` looks up by id.
|
||||
- The main app background (`--aurora-app-bg`) is a **3-stop gradient**, not
|
||||
flat: `linear-gradient(135deg, vivid1 0%, vivid2 55%, near-black 100%)` —
|
||||
two bright, saturated stops of the same hue family carry most of the bar,
|
||||
dipping to a near-black anchor only in the last stretch. This exact ratio
|
||||
went through several corrections against a competing plugin's ("FleekDash")
|
||||
reference screenshots — a 50/50 dark-to-vivid split reads "washed out", two
|
||||
competing saturated hues ~70° apart reads "muddy"; this formula was the one
|
||||
the user confirmed as clean. If revisiting the gradient formula, re-check
|
||||
against those reference screenshots in the conversation history rather than
|
||||
re-deriving from scratch.
|
||||
- `--aurora-card-bg-deep`: a newer token, one step darker than
|
||||
`--aurora-card-bg`, used only by the Dashboard's `AuroraCard.vue`. Needed
|
||||
because the Dashboard got its own frame background using `--aurora-frame-bg`
|
||||
(see "Window chrome" below), which is close in lightness to `--aurora-card-bg`
|
||||
for most presets — cards would nearly disappear into the new frame without it.
|
||||
- `applyThemePalette(themePresetId)` / `applyFontFamily(family)`
|
||||
(`app/src/pages/settings/applyLiveTheme.js`) — shared between the settings
|
||||
page's live preview (`Settings.vue`'s `watch()`) and the real per-page-load
|
||||
application (`SiteShell.vue::onMounted`). Sets each token via
|
||||
`document.documentElement.style.setProperty`.
|
||||
- Google Fonts picker: `app/src/pages/settings/googleFonts.js` (curated ~70
|
||||
family list, not the full catalog), searchable dropdown in
|
||||
`SettingsField.vue`'s `font-picker` field type, applied by injecting a
|
||||
Google Fonts CSS2 `<link>` tag + setting `--aurora-font-family`.
|
||||
- **Recurring bug class this session — "independently-painted gradient"**:
|
||||
several elements (sidebar, toolbar, `#wpbody-content` on the settings page,
|
||||
`#wpbody-content` in general) each used to paint their *own* copy of
|
||||
`var(--aurora-app-bg)`. Since it's a gradient, each element computes it
|
||||
independently over *its own* bounding box — a narrow tall sidebar and a
|
||||
wide short toolbar get visibly different-looking slices of "the same"
|
||||
gradient, creating seams at their shared edges. Fixed by making `html`/`body`
|
||||
the *only* thing that paints the gradient (`background-attachment: fixed`
|
||||
so it doesn't scroll away from the fixed sidebar/toolbar), and leaving
|
||||
every other element transparent so that one gradient plane shows through.
|
||||
**If a new seam/mismatched-rectangle bug shows up, suspect this pattern
|
||||
first** — grep for `var(--aurora-app-bg)` outside `shell-frame.css`'s
|
||||
`html.aurora-ready, html.aurora-ready body` rule; it shouldn't be there.
|
||||
- **Dashboard takeover** (`admin/src/Pages/DashboardTakeover.php` +
|
||||
`app/src/pages/dashboard/Dashboard.vue`): hijacks native `index.php` via
|
||||
`in_admin_header`, hides the native `.wrap`, renders the Aurora dashboard
|
||||
@@ -157,6 +217,16 @@ get back up to speed instead of relying on prior chat history.
|
||||
`deactivated_plugin`, `switch_theme`,
|
||||
`update_option_aurora_admin_settings`. REST:
|
||||
`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.
|
||||
- **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
|
||||
@@ -197,7 +267,67 @@ get back up to speed instead of relying on prior chat history.
|
||||
`#wpbody-content`) + `admin/assets/native-enhance.js` (progressive JS
|
||||
enhancement — currently only `enhanceUpdates()`, which groups the flat
|
||||
Updates page sections into `.aurora-native-card` wrapper divs on
|
||||
`body.update-core-php`).
|
||||
`body.update-core-php`). This session also extended coverage to media/
|
||||
thickbox modals, plugin/theme card grids, and the plugin-search filter bar
|
||||
(all previously untouched, so still native white regardless of theme).
|
||||
Known gap: the plugin "More Details" popup renders inside an `<iframe>`
|
||||
pointing at a separate WP page — CSS can't reach into it; would need JS
|
||||
injection into the iframe's own document if that's ever worth fixing.
|
||||
|
||||
## Window chrome (macOS-style title bar + taskbar)
|
||||
|
||||
Added this session, user-requested after seeing a competing plugin's demo.
|
||||
Every page gets a traffic-light title bar; minimizing persists across a full
|
||||
page navigation via a taskbar.
|
||||
|
||||
- `app/src/shell/windowChrome.js`: `initWindowChrome(adminUrl)`, called from
|
||||
`SiteShell.vue::onMounted` (skipped on the block editor — see below).
|
||||
Injects a `.aurora-winbar` div (3 dot buttons) as the first child of
|
||||
`#wpbody-content` — the one container shared by *every* page Aurora
|
||||
manages, native WP pages and all of Aurora's own Vue pages alike, since
|
||||
each Vue entry mounts its root div there. **Exception**: the Dashboard
|
||||
(`DashboardTakeover.php`) renders into a separate `#aurora-admin-dashboard-root`
|
||||
sibling *above* `#wpbody` (which it hides) to fully replace the native
|
||||
dashboard — `#wpbody-content` is empty/collapsed there. `windowChrome.js`
|
||||
detects this and instead wraps the bar + `#aurora-admin-dashboard-root` in
|
||||
a new `.aurora-dashboard-frame` div, giving the Dashboard the same
|
||||
card-frame treatment (`--aurora-frame-bg`, border, radius) every other
|
||||
page already gets from `#wpbody-content` itself.
|
||||
- Red (close): `window.location.href = adminUrl`.
|
||||
- Green (maximize): toggles `html.aurora-maximized` — hides `.sidebar`/
|
||||
`.toolbar`, zeroes `#wpcontent`'s `margin-left` and the block editor
|
||||
skeleton's `left`, so content fills the whole browser window. Toggle again
|
||||
(or minimize) to restore. Nothing persisted — resets on next page load.
|
||||
- Yellow (minimize): **on the Dashboard itself**, toggles `html.aurora-minimized`
|
||||
which just collapses `#aurora-admin-dashboard-root` down to the bar in
|
||||
place (nowhere further "home" to send it). **On every other page**, calls
|
||||
`taskbar.js`'s `setMinimizedWindow(title, url)` (persists `{title, url}` in
|
||||
`sessionStorage`, tab-scoped) then navigates to the dashboard. Only one
|
||||
minimized window is tracked at a time — this is "minimize sends you home
|
||||
with a way back," not a real window manager.
|
||||
- `SiteShell.vue` reads `taskbar.js`'s `getMinimizedWindow()` on every mount
|
||||
(so the taskbar shows up on whatever page you're on after minimizing) and
|
||||
renders a **full-width docked bar** at the bottom with one pill-shaped
|
||||
item; clicking it clears the sessionStorage entry and navigates back to
|
||||
the stored URL. `html.aurora-has-taskbar` (toggled alongside) reserves
|
||||
bottom margin on `#wpbody-content`/`.aurora-dashboard-frame` equal to
|
||||
`--aurora-taskbar-h` so page content stops above the bar instead of
|
||||
running underneath it. Went through two design iterations (small centered
|
||||
floating pill → back to a full-length bar per explicit user correction —
|
||||
the pill-shaped *item* stayed, just not as the whole bar).
|
||||
- **Block editor exception**: Gutenberg (`post.php`/`post-new.php`) doesn't
|
||||
render inside `#wpcontent`'s normal box model at all — its
|
||||
`.interface-interface-skeleton` is `position: fixed; inset: 0`, anchored to
|
||||
the viewport independent of any margin/padding on ancestors. `SiteShell.vue`
|
||||
detects `document.body.classList.contains('block-editor-page')` and: (a)
|
||||
skips rendering Aurora's own `<Toolbar>` (the editor has its own,
|
||||
equivalent one — stacking both left a gradient seam between them), (b)
|
||||
skips `initWindowChrome()` entirely (`#wpbody-content` is invisible/
|
||||
collapsed there, injecting into it would be dead clutter), (c) insets the
|
||||
skeleton itself via `left`/`top` in `shell-frame.css` so it doesn't render
|
||||
underneath the sidebar. **If a future feature needs to reach the block
|
||||
editor's own chrome**, its real container is `.interface-interface-skeleton`,
|
||||
not `#wpbody-content` — don't assume the normal page structure there.
|
||||
|
||||
## Key bugs fixed (root causes, in case they resurface)
|
||||
|
||||
@@ -226,28 +356,55 @@ get back up to speed instead of relying on prior chat history.
|
||||
- **Browser automation can't install plugins**: the Chrome MCP `file_upload`
|
||||
tool only accepts files already "shared with the session" (attachments/
|
||||
connected folders) — local build output on disk doesn't qualify. Confirmed
|
||||
this session; the user must manually reinstall the zip every time. No
|
||||
workaround found — don't attempt this again.
|
||||
this session; the user must manually reinstall the zip every time (though
|
||||
see "Fast local iteration" above for the hot-patch workaround used for
|
||||
verification during dev).
|
||||
- **Independently-painted gradient seams** (sidebar/toolbar/settings-page
|
||||
`#wpbody-content` each showing a visibly different slice of "the same"
|
||||
background gradient): see the theme-system section above — root cause was
|
||||
multiple elements each painting their own copy of a gradient-valued
|
||||
`var(--aurora-app-bg)` instead of one element painting it and the rest
|
||||
staying transparent.
|
||||
- **Block editor content rendering underneath the sidebar**: Gutenberg's
|
||||
`.interface-interface-skeleton` is `position: fixed; inset: 0`, completely
|
||||
bypassing the `margin-left` that pushes every other page's `#wpcontent`
|
||||
over — see the "Window chrome" block editor exception above for the full
|
||||
mechanism and the fix.
|
||||
- **`zip -r` merging into a stale archive**: rebuilding the deployable zip
|
||||
without first deleting the old one left old-hash asset filenames mixed
|
||||
into the new zip (macOS `zip -r` appends/merges rather than replacing).
|
||||
Always `rm -f` the zip before rebuilding.
|
||||
|
||||
## Not-yet-done (deferred, no active request)
|
||||
|
||||
- Full field sets for settings categories beyond General/Analytics/White
|
||||
Label (original plugin had more).
|
||||
- Extending `native-enhance.js` boxing to other native screens (Tools, etc.)
|
||||
beyond Updates.
|
||||
- Extending `native-enhance.js`/`native-dark.css` coverage to more native
|
||||
surfaces — the block editor's own chrome, Widgets screen, Customizer.
|
||||
Media/thickbox modals and plugin/theme card grids were added this session;
|
||||
the plugin "More Details" popup specifically can't be reached (it's an
|
||||
`<iframe>` — see native page dark styling notes above).
|
||||
- Porting the real license-key activation flow (built previously in the old
|
||||
`aurora-admin-working` project, not yet ported to v2 — currently just a
|
||||
text field).
|
||||
- Light-mode boxing for native pages (`native-dark.css`/`native-enhance.js`
|
||||
currently only styled for dark mode; light mode native pages are untouched
|
||||
WP default).
|
||||
- Menu Creator: stored item `order` field isn't applied at runtime yet
|
||||
(hide/relabel work; reordering doesn't).
|
||||
- **Unresolved from this session**: Menu Creator/Activity Log/Role Editor
|
||||
throw "Sorry, you are not allowed to access this page" for the admin user
|
||||
— see the Plugins sub-app bullet above. A background investigation task
|
||||
was spawned (`task_f8e56f60` at spawn time) but its outcome isn't recorded
|
||||
here — check whether it landed before re-investigating.
|
||||
- No automated tests anywhere in the project — all verification has been
|
||||
manual, live-in-Chrome, per the established workflow rule above.
|
||||
|
||||
## Current state
|
||||
|
||||
No task in progress. Last completed and pushed: theme-control swatches in
|
||||
the new floating `UserMenu`. Everything through commit `e1bd095` on
|
||||
`origin/main` is confirmed live-verified and working by the user.
|
||||
No task in progress. This session rebuilt the entire theming system (fixed
|
||||
color presets replacing the old light/dark toggle, gradient backgrounds,
|
||||
several "independently-painted gradient" seam bugs), added the macOS-style
|
||||
window chrome + taskbar feature end-to-end, and extended native-page dark
|
||||
styling coverage. All of it was live-verified in Chrome against the LocalWP
|
||||
site and is pushed to `origin/main` (commit `4a547d2` at session end — a
|
||||
single large commit covering the whole session's work, since it wasn't
|
||||
broken into incremental commits along the way). The one known open issue is
|
||||
the Menu Creator/Activity Log/Role Editor permissions bug noted above.
|
||||
|
||||
Reference in New Issue
Block a user