=== Ethan's Admin Palettes ===
Contributors: Ethan J. Hulbert
Tags: admin, color scheme, dashboard, customization
Requires at least: 5.0
Tested up to: 6.6
Stable tag: 1.0.0
License: GPLv2 or later

Adds 40 additional admin color schemes to Users → Profile, plus a Settings
→ Admin Palettes builder for creating your own, with a live preview that
restyles the actual sidebar and admin bar on the builder page itself as
you pick colors.

== Installation ==

1. Upload the `ethans-admin-palettes` folder to `/wp-content/plugins/`.
2. Activate the plugin through the "Plugins" menu.
3. The 40 built-in palettes appear immediately under Users → Profile →
   Admin Color Scheme, alongside WordPress's own defaults (and any other
   color-scheme plugin's schemes, if one is active — nothing here
   collides, every scheme this plugin registers is prefixed `eap-`).
4. To build your own, go to Settings → Admin Palettes.

== How it works ==

Every scheme — built-in or custom — is defined by eight color roles:
Menu Background, Menu Text, Menu Icons, Menu Highlight Background, Menu
Highlight Text, Admin Bar Background, Admin Bar Text & Icons, and an
Accent color used for links, buttons, and focus states. This is smaller
than the full set of colors a WordPress admin theme could theoretically
touch, but covers the large majority of the dashboard's visual identity
— menu, admin bar, buttons, links, focus rings — without hand-authoring
every notice color and hover state per scheme.

The 40 built-in presets were generated ahead of time (see
build-presets.py, included for reference / future regeneration) by
running eight role colors for each through a shared CSS template, and
their stylesheets ship as static files in assets/schemes/ — no runtime
generation, no writable-directory dependency, for those 40.

Custom schemes built via Settings → Admin Palettes go through the same
template at save time (includes/color-roles.php's
eap_generate_scheme_css()), writing the resulting stylesheet to
wp-content/uploads/eap-schemes/{slug}.css. If that directory isn't
writable, the palette's name and colors still save, but you'll see a
warning that the stylesheet itself couldn't be written.

The live preview on the builder page runs a third copy of the same
template in JavaScript (assets/builder.js), rewriting an in-page <style>
tag on every color change — nothing is saved or written to disk until you
click Save.

== Notes ==

- All three copies of the CSS template (PHP, the Python build script, and
  the JS live preview) need to be edited together if the template itself
  ever changes — they're written to stay in sync, not to share code
  across languages.
- Deleting a custom palette removes its option data and its stylesheet
  file. Deactivating the plugin leaves everything in place; uninstalling
  it (via Plugins → Delete) removes all custom palette data and files.
  The 40 built-in presets are just files bundled with the plugin, so they
  simply disappear when the plugin folder is removed either way.
- Palette colors aren't checked against any accessibility contrast
  standard — a few of the 40 lean bold rather than subtle. Nothing stops
  you from picking low-contrast colors in the builder either.
