Codeinwp / Codeinwp/neve

Allow setting Dark Palette as default initial state in Palette Switcher

Open
#4,613 0 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

customer report feature-request-triage
Dominant language
PHP
Stars
306
Forks
88
Avg merge
2d 16h
Merged PRs (30d)
12

Description

Impact: 70 · Confidence: 90 · Complexity: 50

Description

Problem: Currently, the Palette Switcher component in Neve always defaults to the 'Base Palette' (Light) for first-time visitors when 'Automatically adjust color scheme' is disabled. Site owners who want a dark-themed site by default are forced to swap color definitions between Base and Dark palettes, which breaks semantic OS-aware color scheme detection (prefers-color-scheme) and accessibility expectations.

Desired Behavior: Provide an option in the Palette Switcher component settings (and/or a PHP filter) to define which palette (Base/Light or Dark) serves as the default state for first-time visitors before any preference is stored in local storage, while retaining correct semantic mapping when OS-aware detection is active or when the user toggles modes.

Acceptance Criteria:

  • Add a setting in the Customizer Palette Switcher component (or PHP filter neve_default_color_palette) to specify the default initial palette (Light/Base vs Dark).
  • First-time visitors without a stored palette choice receive the configured default palette.
  • Palette Switcher toggling, local storage persistence, and OS-aware logic continue to work correctly with their respective semantic light/dark designations.

Customer Context

The customer is a WordPress developer on Neve Pro (Business plan) who redesigned their site with a dark theme as the primary design. They want new visitors to see the Dark Palette on first load, but cannot swap colors between Base and Dark palettes because doing so inverts OS-aware logic (prefers-color-scheme) for visitors with native Light OS settings.

Root Cause Analysis

The root cause is that Neve's Palette Switcher hardcodes the 'Base Palette' (Light) as the default fallback for unvisited sessions when automatic OS detection is disabled or unsupported. Site owners who design dark-first websites cannot configure the initial default palette to be Dark without swapping palette color definitions, which degrades accessibility and breaks semantic OS-aware preference detection.

Reasoning

The customer (a Pro WordPress developer on a Business plan) needs to set the Dark Palette as the initial default palette for first-time visitors without breaking the semantically correct Light/Dark roles or OS-aware logic (prefers-color-scheme). Currently, Neve hardcodes the 'Base Palette' (Light) as the default first-visit state when automatic OS adjustment is disabled. Swapping colors in the Customizer is an invalid workaround because it breaks accessibility and OS-aware detection. Allowing site owners to select which palette serves as the initial default (Base/Light vs Dark) or providing a filter to set initial palette state is a legitimate net-new capability.


Source: HelpScout #3439746979
Generated by feature-request-triage workflow (ID: feature-request-triage_6a9953537c3006.83729601)

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Start by tracing the Palette Switcher component settings in the Customizer and the neve_default_color_palette filter, then inspect how first-visit state, local storage, and prefers-color-scheme handling are connected. Done means a configured Light/Base or Dark default applies only when no preference is stored, while toggling, persistence, and OS-aware semantic mapping remain correct.

Written by the indexing model from the issue text.

Assessment

Tech stack
php
Domain
frontend
Issue type
Feature
Difficulty
4/5
Estimated time
3-5 days
Activity status
Active
Clarity
Mostly clear
Newbie friendliness
52/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.