Dark mode functionality - by Claude - #1022
Conversation
- Create ThemeModeProvider for managing light/dark/system theme preferences - Implement user preferences storage in user data - Add dark mode styles for UI components in Tailwind and CSS - Create theme toggle control in user settings panel - Support system theme preference detection
- Create custom theme icons since the sun and moon icons aren't available in @wordpress/icons - Add missing getUserPreference and saveUserPreference methods to IPC API interface
This commit improves dark mode styling throughout the app, with a focus on: 1. Fixed modal styling for Add Site modal by adding body.dark selectors 2. Enhanced form controls with proper dark mode colors for text inputs, borders, and placeholder text 3. Improved site form elements in dark mode including folder icons, help text, and borders 4. Added dark mode support for button variants to ensure proper styling in all contexts 5. Fixed text colors and contrast ratios for better readability in dark mode 🤖 Generated with [Claude Code](https://claude.ai/code) Co-Authored-By: Claude <noreply@anthropic.com>
Not sure I like the background color too much but I guess it works for people that like Dark mode. cc @matt-west for design input. |
| @@ -0,0 +1,25 @@ | |||
| # WordPress Studio Development Guide | |||
There was a problem hiding this comment.
We should probably remove that file, I'm not sure we should be adding the config files/intructions for all the AIs at the moment.
|
|
||
| export const ThemeModeProvider = ({ children }: { children: ReactNode }) => { | ||
| const [themeMode, setThemeModeState] = useState<ThemeMode>('system'); | ||
| const [isDarkMode, setIsDarkMode] = useState(false); |
There was a problem hiding this comment.
It might worth consolidating theme state with language state at some point instead of local state that is spread between multiple Providers/hooks.
Ideally all the preferences are handled in the same low level abstraction/way.
It's fine to be a follow-up I would say but let's not let this kind of thing slip.
| }; | ||
|
|
||
| export default TextControlComponent; | ||
| export default TextControlComponent; No newline at end of file |
| ); | ||
| }; | ||
| export default Root; | ||
| export default Root; No newline at end of file |
| .dark .assistant-markdown hr { | ||
| border-top: 1px solid theme( 'colors.gray.700' ); | ||
| } | ||
|
|
There was a problem hiding this comment.
Feels like there's a lot of CSS overrides for dark mode, I wonder if there's a way to avoid all of that by using CSS variables.
There was a problem hiding this comment.
Heavy +1. These CSS overrides will be incredibly difficult to maintain as we add new features. It also makes it harder to introduce new themes in the future (i.e. high contrast, custom user themes).
| return window.isFullScreen(); | ||
| } | ||
|
|
||
| export async function getUserPreference( _event: IpcMainInvokeEvent, key: string ): Promise< unknown > { |
There was a problem hiding this comment.
I'm not sure we need these two functions or the nested "preferences" key. For the "locale", there's no nested "preferences" key, so I think we should just map what we're doing for the user's "locale".
|
I noticed that some modals apply dark mode (add site) but others don't (edit site, user preferences, connect site) |
matt-west
left a comment
There was a problem hiding this comment.
Thanks for the ping @youknowriad!
I did some explorations into how dark mode could look a while back. These aren’t complete, but gives an idea of the direction we were headed.
RToz6tIuQ7nlZrikBte4GU-fi-4369_162098
The most important thing is to implement this in a way that’s easy to maintain and scalable if we want to add other themes in the future (high contrast, custom user themes, etc.).
I agree with @youknowriad that we need to create a set of CSS variables that define a theme, and then use those to set colors for each component within the app. Ideally this integrates with theming in @wordpress/components once that's in place.
|
Thanks for jumping in and putting together this proposal, @matt-west! 🙌 @draganescu, what’s the best way for design to stay ahead of these issues? I’ve added the |
|
@matt-west @crisbusquets thanks for lending a hand. This is a draft PR I did exclusively by spending tokens - Riad looped you in, which is good, I'd have done it once the PR was not a draft anymore. PRs don't have to land - e.g. in this one what interests me is the feature mechanism but there is a lot of cleanup to do. |
|
Closing this. I'll spin up a new PR and reuse whatever Claude managed to solve on its own. The goal here was to see how far vibe coding could get and to see what places are not ready for theming. |
|
We merged dark mode in this PR: #2652, and it will be available in the next WordPress Studio release. Thanks for your work. We identified some errors thanks to this PR. |






Playful attempt at adding #553
Summary
options
Details
This PR implements a comprehensive dark mode solution for the WordPress Studio application:
New Features
UI Enhancements
Technical Implementation
Accessibility
Technical Details
The implementation uses Tailwind's dark mode with the 'class' strategy, applying a 'dark'
class to the root element when dark mode is active. For elements that may be appended to the
document body (like modals), we've implemented both .dark and body.dark selectors to ensure
consistent styling.
Theme preference is stored in the app's user preferences system via IPC calls to ensure
persistence across sessions.
Testing
Screenshots