Follow-up to the player-modal / maintenance-page fix: the same root cause --
colours hard-coded for the light theme -- affected the whole app, in two
places.
1) Inline style attributes (inline outranks the theme rules, so the light
value survives dark mode and the inherited text colour turns
light-on-light). base.html now carries a single, property-scoped
dark-mode override layer that maps every light literal found in the
templates to the theme variables: light backgrounds/whites -> dark
surfaces, semantic pastels -> dark equivalents, dark text -> light text,
light borders -> dark borders, plus .back-link. Scoped to
body.dark-mode, so the light theme is untouched. This covers all
templates, including ones not edited here and any added later.
2) Page-level <style> blocks with no dark support:
* admin/https_config.html hard-coded a light-only palette (blue-tint
panels, dark labels) -- added a body.dark-mode block for it.
* dashboard.html / help.html / manage_player.html coloured text links
with --primary-color (#7c3aed in dark = too dim). Introduced a
dedicated --link-color (#667eea light / #a78bfa dark) and used it for
text links, leaving --primary-color for button/background use.
Verified with an automated luminance scan of all 18 pages in both themes:
dark mode has 0 light backgrounds and 0 dark-on-dark text (the only
remaining light surfaces are the intentional white buttons on the admin
gradient cards), and light mode is unchanged.
- Content model: add url column + is_weblink() for web page content items
- Player model: add deployment tracking fields (status, timestamps, message)
- Content blueprint: add add_weblink and add_weblink_to_playlist routes;
weblinks auto-deleted when removed from playlist
- Players blueprint: add SSH deploy mode in add_player; weblink-aware playlist
- API blueprint: weblink URL served directly in playlist response;
add /api/deploy/test-ssh and /api/deploy/player endpoints
- Admin blueprint: add build-player page (clone from Gitea, write base config);
replace nginx status card with Caddy status on HTTPS config page
- caddy_manager: rewritten to generate proper HTTPS/internal-CA Caddyfiles
and reload Caddy via admin API (/load) for live config updates
- ssh_deploy, background_tasks, player_build: new utils for SSH deployment
- background_tasks: push Flask app context into background thread so DB
updates after deployment complete correctly
- ssh_deploy: robust install script detection with passwordless sudo injection
(uses SSH credentials, cleaned up after install)
- Dockerfile: add git, sshpass, openssh-client, rsync
- docker-compose: switch nginx to Caddy on ports 80/443; add port 5000 for dev
- Templates: add_player deploy mode UI, weblink form in playlist/upload pages,
build_player admin page, Caddy status on HTTPS config page
- Migrations: add_url_to_content, add_deployment_fields_to_player
- app.py: call db.create_all() on startup for schema bootstrap
- config.py: add PLAYER_CODE_DIR and PLAYER_REPO_URL settings
- Detect actual HTTPS status from current request (scheme + X-Forwarded-Proto)
- Auto-sync database when HTTPS status mismatch is detected
- Show real-time connection info (protocol, host, port)
- Display helpful message when accessing via HTTPS but config shows disabled
- Add CSS styling for detection status display
- Users now see accurate HTTPS status even if database wasn't in sync
ske087
root
Quality App Developer