Dark Mode & Night Mode – Darkify

Registro de cambios

2.1.2 – 31 August 2026

• Fixed: Admin dark mode did nothing on the admin screens of Fluent Forms, FluentCRM, Fluent Booking, FluentSMTP and WP Social Ninja, and the admin-bar toggle reported an error when clicked. Each of those plugins runs a «no-conflict mode» that removes every script served from the plugins directory on its own screens, and it runs after scripts are enqueued — so Darkify’s engine was stripped while the admin-bar switch it powers stayed on the page, wired to a function that no longer existed. Darkify now registers with the allow-lists those plugins publish, re-adds its own engine after the sweep for the ones that publish none, and the switch fails quietly rather than throwing if it is ever removed again.
• Fixed: With a colour preset selected, the current item in Darkify’s own settings sidebar was invisible, as was the highlight on a hovered menu entry. Preset colours are pushed into the screen’s design tokens, and the selected-item token was being handed the same value as the surface behind it — so the highlight was painted, in exactly the colour it was meant to stand out from. It now takes the preset’s next step up, the same relation the screen’s own dark theme uses.
• Fixed: Switching Admin Panel Dark Mode off left the settings screen in a broken half-state — dark cards and unreadable text on a light page — until it was reloaded. Turning the option off returned the page to light but left the preset’s colours written into the screen’s tokens, because the engine that wrote them never re-ran. It is now asked to re-run, which clears them in the same step.
• Fixed: With a colour preset selected, links inside admin notices stayed WordPress blue while every other link took the preset’s colour. WordPress styles notice links more specifically than plain links, and the darkening engine marks everything it rewrites as important — so Darkify’s own rule no longer outranked it, it merely tied and lost. The rule is now specific enough to win, while still leaving the admin menu, the admin bar and buttons to their own colours.

2.1.1 – 26 August 2026

• Fixed: Primary buttons, switches and selected states on Darkify’s own settings screens ignored the Admin Panel Palette and stayed on a near-white default. Those parts are drawn from a --primary / --primary-foreground pair, and the pair had been left out of the palette map on the grounds that overwriting half of a contrast pair makes a button unreadable. Both halves are now taken from the palette’s own button fill and button text — a pair its author already chose to be readable together — so a chosen palette finally reaches the last part of the screen it never did.
• Fixed: Switch tracks and thumbs rendered transparent under some palettes. A palette that did not carry a field was still writing that field’s variable, as the literal text undefined, and a custom property that parses but never resolves takes its whole declaration down with it — so the track did not fall back to a default colour, it lost its background outright. A missing field now clears the variable instead of writing it, leaving the stylesheet’s own value to stand.
• Fixed: Toggles were hard to see once they did have a colour, because the checked track took the palette’s button fill — a colour chosen to sit on the page background, not to be read at a glance against a card, and measuring between 1.21 and 2.86 against each palette’s card. The track now takes the palette’s accent colour (4.29 to 14.50 across the same palettes) and the thumb takes the page background, so the moving part reads clearly against the part that does not.
• Fixed: Changing a colour preset in Live Preview only partly applied until the preview was reloaded. Rules written in terms of Darkify’s variables follow a preset instantly, but the engine also writes colours inline as it walks the page — gradients, shadows, overlays, image brightness, icon colour — and an inline declaration has no variable in it to re-resolve. Worse, the gradient and shadow writers refuse to run twice by design, so a second pass changed nothing at all. Live Preview now clears those markers and re-runs the writers against the new colours, so a hero gradient follows the preset with everything else.

2.1.0 – 25 August 2026

• Changed: Dark mode in wp-admin is now rendered by Dark Reader instead of the per-element engine. The old engine walked every element on the screen, read its computed style, and re-walked on any DOM change — workable on a page that settles, and untenable in wp-admin, which never does. Dark Reader works a stylesheet at a time and generates an inverted sheet once, so the cost no longer scales with how busy the screen is. The front end is untouched and still uses the original engine.
• Fixed: The block editor became unresponsive with Admin Panel Dark Mode on, and stayed that way — typing, adding a block or opening the inserter could each trigger it. Every DOM change queued a fresh walk of the whole editor, each visited element forcing a style recalculation, and the editor changes the DOM continuously; the work never finished before more arrived. The new admin engine does no per-element work at all.
• Added: Admin Panel Palette and Block Editor Palette settings, chosen independently. Both default to Auto, which derives a colour for every colour on screen rather than pinning a background and a text colour — that derivation is what lets unfamiliar admin screens from other plugins come out right, and a preset gives it up. Presets remain available for anyone who wants a fixed look, and the block editor’s toolbar picker still overrides both for that user.
• Fixed: The classic editor’s dark mode button did nothing whenever the admin itself was light. Its state had been folded into the admin’s, so a light admin ruled out a dark writing area — a combination people deliberately choose. The two are independent again, and the editor body now follows the chosen palette instead of a fixed grey.
• Fixed: Short admin screens were painted in two tones, with a horizontal seam roughly a screen-height down. WordPress colours body and leaves html unpainted, so the two were being darkened from different starting points and the join showed wherever the content was shorter than the window. Both now resolve to the same colour, measured rather than predicted, so it holds under every palette.
• Fixed: Darkify’s own settings screens rendered card borders and toggle backgrounds in red. Those screens ship their own dark theme, so darkening them a second time layered two themes over each other — and the modern colour values they use could not be parsed by the darkening engine, leaving the unresolved ones to settle on the theme’s error colour. Those screens are now left to the theme they already have.
• Fixed: The Darkify menu icon in the WordPress sidebar sat noticeably brighter than every other icon. WordPress renders a menu icon as a background image, which cannot take the menu’s colour the way its own font icons do, so ours stayed flat white. It now takes its colour from the menu like everything around it, under any admin colour scheme.
• Fixed: Resizing the browser window could freeze the page outright. Whether the admin menu needs its own scrollbar is a measurement that its own answer changes, and with a single threshold a menu sitting near that boundary flipped between the two answers without ever settling — a resize drag holds it there. The test now needs clear evidence in each direction before it changes its mind.
• Changed: The block editor has one dark mode toggle instead of two. The admin bar carried a second one alongside the toolbar button, both doing the same thing. The toolbar button is the one that survives, because the admin bar is hidden in the editor’s fullscreen mode — which is its default.
• Fixed: The Help screen collapsed awkwardly at narrower widths — review cards wrapping to a word per line, plugin titles crushed against their install button, a tab clipped mid-word behind the upgrade button. Each of those laid itself out from the browser window’s width while sitting in a column that only ever had a fraction of it. They now measure the space they are actually given, which also means collapsing the WordPress menu reflows them correctly.
• Fixed: Several Help screen elements were unreadable in dark mode: video play buttons vanished into their own white circles, the Lite vs Pro table header became a bright white band, and hovering a plugin card drew a hard white outline. Each used a colour that inverts between light and dark against something that does not — imagery, or a full-width band.
• Added: Pro colour presets now appear in the palette pickers as locked, badged entries rather than being absent. They cannot be selected or saved, and the engine falls back to Auto if one is ever set.
• Fixed: The «Upgrade To Pro!» menu link replaced the current admin screen instead of opening in a new tab, losing whatever was being configured.

2.0.4 – 18 August 2026

• Fixed: Brand-coloured icons — star ratings, coloured logo marks — lost their colour and read as the same flat grey as body text. The icon recolouring introduced in 2.0.4 mapped every icon onto the page’s text colour unconditionally, with no exception for a colour that was never meant to blend in; a five-star testimonial rating was the clearest case, gold turning grey. Icon colour now runs through the same hue-preserving ramp gradients already use, so a brand colour keeps its hue and only its depth shifts for a dark backdrop.
• Fixed: A background writer added in 2.0.4 for empty decorative overlay divs (Elementor’s .elementor-background-overlay and similar) was also catching real, content-bearing elements that simply never picked up one of the class-based repaint’s own classes — a countdown timer’s number box, a page-builder button. Flattening a background with no matching foreground adjustment is how a white button with dark text, or a navy countdown box, ended up the same dark shade as its own text and effectively vanished. The writer now skips anything with real text content, which an empty overlay div never has.
• Fixed: A dark icon sitting on its own light background — a WordPress social icon link’s circle, for instance — was being recoloured to the page’s light text colour, because the contrast check only looked at the page’s general dark backdrop, not what the icon is actually sitting on. That turned a perfectly readable dark icon on a light circle into a light icon on the same light circle: invisible. Icon colour is now judged against the real, current colour immediately behind it, and left untouched whenever it already reads clearly there.
• Added: Border Color and Hover Border Color controls for buttons, in every color preset. A button’s border was the one color dark mode never touched, so an outline button kept its light-design brand edge — a bright ring around a dark fill — and no setting could reach it. Each preset now ships a border color that matches its button fill, so solid buttons look exactly as before and outline buttons finally follow the palette.
• Fixed: Card outlines drawn as a shadow ring (0 0 0 1px) disappeared in dark mode. A ring like that is a border written in the wrong property, and it was being painted black like a real shadow — black on near-black is nothing at all — so a card outlined this way lost its edge while the card beside it, outlined with a real border, kept one. Rings now take the palette’s border color, and turning shadows off no longer deletes them.
• Fixed: Body text and headings came out tinted on themes whose text color is a tinted near-black — inks like #0A232A or #101828, which most modern themes use instead of pure black. Those read as highly saturated brand colors and were lifted to a light teal or blue, overriding the text color chosen in settings. Near-black and near-white text is now treated as ink, while genuinely saturated deep colors stay on the brand path.
• Fixed: Hover effects, dropdowns, sliders and reveal animations snapped to their end state instead of easing. Darkify pauses CSS transitions while it reads a page’s real colors, and that pause was applied to the whole document — including elements the pass never looked at — on passes triggered by any class change anywhere on the page. The pause is now scoped to the element being read.
• Fixed: Live Preview hid the site header on many themes. The panel filters out cookie banners, chat widgets and popups so the preview shows the page itself, and headers named «sticky-bar», «top bar» and similar were caught by that filter — hiding the part of the page most worth previewing. Semantic headers, banner landmarks and header/nav class names are now recognized and kept.

2.0.3 – 11 August 2026

• Fixed: Pages could freeze or crawl once dark mode was on, worse the larger the page. Every element was watched for class changes individually, and each watcher had to be re-registered across the whole document whenever anything changed — on a 2,929-element page that came to 1.23 million registrations during load and 6.31 million on a single toggle, growing with the square of the page size. One watcher now covers the document, registered once, and the cost no longer scales with the page.
• Improved: Pages that keep changing after load — infinite scroll, carousels, WooCommerce cart and fragment refreshes, page builders and anything React-rendered — no longer re-scan the entire document on every change. Only the newly inserted parts are examined, so a long page stays as responsive as a short one.
• Improved: Switching between light and dark now only revisits the elements Darkify actually styled, and reads each one’s colours once instead of twice, so the toggle settles noticeably faster on large pages.
• Fixed: The dark mode toggle snapped between states instead of animating. Darkify pauses CSS transitions while it reads a page’s real colours, and the switcher was being caught by that pause even though its colours are never read.
• Improved: Pausing transitions during a pass is now a single rule on the page root rather than an inline style written to and removed from every element, which removed one forced style recalculation per element from every pass.
• Changed: The screen no longer dims while a page loads in dark mode. The brightness baseline added in 2.0.2 covered the gap before the first pass, but on a slow page it read as a grey overlay sitting over the whole site until loading finished, and it returned on every navigation. The page background is painted dark from the first frame instead, and the safety timeout that clears it drops from 2s to 0.8s.
• Added: A developer diagnostics mode for support and debugging, off by default and invisible to visitors. Add ?darkify_debug=1 to any URL, then run darkifyDebug.report() in the browser console for pass counts, timings and the number of elements Darkify processed.

For releases before 2.0.3, see the full changelog: https://plugins.svn.wordpress.org/darkify/trunk/changelog.txt