Fix - Background image does not update dynamically in Customizer preview

[rajatgautam755421]

Closes themegrill/radiate-pro#48

Free counterpart of themegrill/radiate-pro#103 (issue themegrill/radiate-pro#48).

WordPress live-previews the background settings by rewriting the theme's <style id="custom-background-css">, but Radiate paints its background on #content. In free that rewrite also deleted the theme's own #content rule, so a chosen image never showed until publishing. customizer.js now mirrors the image, repeat, position, attachment and colour settings onto #content. The preview script is also versioned with the theme version, so browsers that cached the old file get this fix.

Before (image chosen, preview unchanged)	After

Test

1. Appearance → Customize → Background Image: choose an image. It shows in the preview at once, without publishing.
2. Change repeat, position, attachment and colour: each updates live. Remove the image: it disappears.
3. Publish and reload the site: the front end matches the preview. Other live-preview options (site title, header colour) still work.

Adds a @fresh spec: fails on develop, passes 3/3. Full suite: 11 passed, 5 skipped. PHPCS: the one changed PHP line adds no violation, but the file already has many, which the file-level CI check reports.

Changelog: Fix - Background image now updates live in the Customizer preview.

[github-actions]

QA suite — passed ✅

All 10 checks passed.

_{6 passed · 0 failed · 4 skipped · 0 flaky · 12s}

_{Automated check — no AI involved. It runs the tests in this branch.}

[Copilot]

Copilot review overview

🟡 Changes recommended

Two moderate issues remain, including invalid color updates and ineffective cache invalidation.

Review effort: Lite
Findings: 1

Open (1)

• Background color preview omits required # prefix · New

What changed in this PR

Fixes live Customizer background previews by syncing settings to #content, versioning the preview script, and adding regression coverage.

Changes:

• Mirrors background image settings onto #content.
• Adds preview script versioning.
• Adds an end-to-end Customizer test.

Review findings:

• inc/customizer.php — Moderate (1 vote): the unchanged theme version does not invalidate cached customizer.js.
• js/customizer.js — Moderate (3 votes): background colors need a leading #.
• js/customizer.js — Nit (1 vote): tests do not cover color, position, attachment, or clearing the image.

File	Description
tests/​e2e/​specs/​customizer/​background-image-preview.spec.ts	Tests live image and repeat updates.
js/​customizer.js	Applies background settings to #content.
inc/​customizer.php	Enqueues the preview script with a version.

---

💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.

[rajatgautam755421]

Not an issue here. Core registers background_color with sanitize_js_callback => maybe_hash_hex_color (wp-includes/class-wp-customize-manager.php), so the value the Customizer passes to the preview script already includes the #; the stored theme mod is the no-hash form, the JS value never is. Verified in the Customizer on this WordPress: the initial value is #EAEAEA, and picking #12ab34 with the real colour control gives a #content background of rgb(18, 171, 52). The cache-versioning part of your summary is addressed: the preview script is now versioned with the theme version.