Five new dark themes shipped in one release, verified working, screenshots checked, ready to go. For a full release cycle afterward, four of those five silently didn’t work at all on the one surface that mattered most: the actual dashboard content. Here’s the one line of code responsible, why it took a full sweep with a different theme active to notice, and why this exact shape of bug is so easy to write without realizing it.
What the engine actually does, in one sentence
Mawu’s per-element recoloring engine walks the dashboard’s DOM, reads each element’s real computed color, and adjusts it, the mechanism that handles arbitrary content a fixed stylesheet can’t anticipate: other plugins’ admin screens, list tables, anything not on a hand-picked list. Whether that engine runs at all is gated behind one check: is the current user’s active admin color scheme one of ours.
The line that only worked for one theme
When Mawu had exactly one theme, that check was written the obvious way: compare the active scheme against the literal string 'mawu'. Reasonable code, for a plugin with one theme. Five more themes shipped in the next release, Canopy, Tide, Dune, Ember, and Fern, each fully built: its own palette, its own per-theme CSS files for the editor canvas, the Classic Editor, the login screen. Nobody updated the one line that decided whether the recoloring engine should run at all, on either side of the codebase, the PHP gate and its JavaScript counterpart both still compared against the single string 'mawu' specifically.
The practical effect: pick any of the five new themes, and the entire per-element engine silently never ran. Not “ran with some gaps.” Never executed at all. Everything that engine is responsible for, arbitrary content, other plugins’ screens, anything not covered by a hand-picked critical CSS rule, stayed in its default light appearance. The five new themes weren’t half-finished. They were fully built and then never actually activated for the one mechanism that does most of the real work.
Why this took a full sweep to notice, not the initial testing
The five new themes were checked when they shipped, and they looked fine, because the initial verification pass, like most testing naturally does, mostly reused whichever theme had already been tested most: Mawu itself, still the default, still what a screenshot comparison or a quick spot-check would land on by habit. A bug that only manifests when a NON-default option is active is exactly the kind of thing a natural testing pattern misses, not because anyone testing was careless, but because “check the new thing” and “check it with a truly different configuration active” are two different disciplines, and only the first one happens automatically.
It surfaced during a dedicated re-sweep specifically done with a nature theme active instead of Mawu, checking every admin screen again. That’s the entire difference: the same screens, the same plugin, one different color scheme selected, and the gap became immediately obvious once someone was actually looking at it under those conditions rather than assuming the earlier all-clear generalized.
The fix, and why it’s a different shape of bug than a missing selector
The corrected check reads the plugin’s own registered theme list and asks whether the active scheme is a member of it, not whether it equals one specific string: in_array( get_user_option( 'admin_color' ), Mawu_Palette::keys(), true ) on the PHP side, with the equivalent theme-key list injected into the page for the JavaScript engine to check the same way, since client-side code can’t directly reach a PHP class’s own registry.
This is worth separating from an ordinary missing-selector bug, the kind where one specific element loses a CSS specificity fight and stays the wrong color. That’s a real but bounded problem: one element, one property, one screen. A wrong gate check is a different category entirely, a single condition deciding whether an entire mechanism runs at all. Every gap five-sixths of users saw across every screen that mechanism was ever responsible for traced back to this one line, not to a list of individually missing rules that would each need finding and fixing on its own.
Why “only one theme exists” code is a trap by construction
The natural first version of any “is one of ours active” check, written at a point when there’s really only one theme, is always going to be a direct equality comparison against that theme’s name. There’s no other reasonable way to write it at that moment, and nothing about it looks wrong in isolation. The trap springs later, when a second option gets added somewhere else in the codebase and nothing forces a revisit of a comparison that was completely correct when it was written and silently stopped being correct the moment a second valid value existed.
The generalizable version: any code whose job is “check if the current value is one of the valid options for X” should read that list from wherever X’s options are actually defined, never hardcode today’s only member as if it were the only one that will ever exist. It costs nothing when there’s only one option, and it’s exactly the difference between this bug existing and not existing once a second one shows up.
See all 13 themes, all now equally and identically covered by the same recoloring engine, or Mawu Dark Mode to check for yourself.