Refactor so we no longer save customizer colors with # symbols

[RachelRVasquez]

All Submissions:

• Have you followed the Contributing guidelines?
• Does your code follow the WordPress' coding standards?
• Have you checked to ensure there aren't other open Pull Requests for the same update/change?

Changes proposed in this Pull Request:

WordPress does not store colors (hex values) with the #, so to eliminate the need for conditionals sprinkled throughout to either remove or add hashes, we thought it made more sense to refactor to WordPress standards. Also includes a migration function in updates to keep color schemes intact/consistent.

How to test the changes in this Pull Request:

1. Switch to the dev branch where we still have our legacy color schemes.
2. Go to the WP Admin, Memberlite > Tools > Reset Theme. Click the button to reset your theme settings.
3. Go to Appearance > Customizer. Select a color scheme. (These will be legacy) Publish.
4. Confirm all is good on the customizer preview and front-end of the site.
5. Then switch to this branch in Git.
6. We need to trigger an update since we're coming from legacy. Basically replicate updating our Memberlite theme. Being on the branch is not enough to test.
7. I went to my database, and on the wp_options table, ran UPDATE wp_options SET option_value = '0' WHERE option_name = 'memberlite_db_version';
8. Check your customizer and the front-end of the site. The legacy color scheme should be intact before you've made any changes.
9. In the customizer, change to a different color scheme. Are you seeing your changes in the preview? The individual color pickers? If you select a specific color and change it, is the result the same?
10. Publish your changes and check the front-end. Does the front-end reflect your changes?
11. Go to a page/post on the WP-Admin, to the block editor. Are the color scheme's colors in the color palette? Are colors/fonts applying properly to blocks?

Known Issues

There is a known issue with some of the WordPress preset vars being undefined. We'll be tackling that on a separate branch.

Other information:

• Have you added an explanation of what your changes do and why you'd like us to include them?
• Have you successfully run tests with your changes locally?

Changelog entry

We're standardizing how we save colors from the customizer into the WordPress database by saving them without the hash. We've added conditionals where necessary to put the hash back when we need it, mainly for when we're redefining CSS vars. We've also included a function in the updates.php file to convert color scheme colors and keep them intact with the update.

[Copilot]

Pull request overview

This PR standardizes how Memberlite stores Customizer hex colors by saving them without a leading # (matching WordPress core behavior), and updates the theme’s output/migration logic to keep legacy schemes working during upgrades.

Changes:

• Refactors default + legacy color scheme definitions to store hex values without #.
• Updates Customizer preview/control JS to add # only when needed for CSS/pickers.
• Adds/adjusts an update migration to trim # from stored theme_mod color values.

Reviewed changes

Copilot reviewed 6 out of 7 changed files in this pull request and generated 4 comments.

Show a summary per file

File	Description
js/customizer.js	Ensures live-preview CSS variable updates use hash-prefixed colors and can add missing vars to :root.
js/customizer-controls.js	Adjusts scheme→picker updates to handle scheme colors that no longer include #.
inc/updates.php	Updates migration logic to trim hashes when writing theme_mod color values.
inc/deprecated.php	Removes # from legacy scheme definitions.
inc/defaults.php	Removes # from modern scheme/default color values.
inc/customizer.php	Updates sanitization/output to work with no-hash storage and reworks the CSS var output.
functions.php	Minor doc comment whitespace change.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.