Enable gradients in the theme.json, added dynamic gradient color palette

[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:

Enabled gradients in the theme.json and added functionality into our existing memberlite_filter_theme_json where we build dynamic color palettes based on the active color scheme. The gradient color palette is also dynamic and uses colors in the active theme.

Example of gradients in the editor on the "Seaside Linen" color scheme:

Example of gradients when on the "Gotham" color scheme:

Example of gradient background on a group block using Cocoa Ash color scheme versus Evergreen

(Some of these gradients will pop more once the new action/accent colors have been merged in)

ℹ️ I also enabled the dropCap attribute and link colors for paragraph blocks in the theme.json file.

How to test the changes in this Pull Request:

Confirm that you can see the gradient color palette in the block editor for background and that you can apply gradients to button and group blocks. Confirm that these colors change when the color scheme in Appearance > Customize > Colors is changed.

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

New dynamic gradient color palette for button and group blocks, that change based on the active color scheme.

[Copilot]

Pull request overview

Enables gradient support in the block editor for Memberlite by turning on per-block gradient controls in theme.json and dynamically generating a gradients preset palette from the active Customizer color scheme via memberlite_filter_theme_json.

Changes:

• Enabled gradients + custom gradients for core/button and core/group, and enabled paragraph link color support in theme.json.
• Added memberlite_build_gradient_palette() and wired it into memberlite_filter_theme_json() to register a dynamic gradients preset palette and disable default gradients.
• Enabled dropCap in theme.json.

Reviewed changes

Copilot reviewed 2 out of 2 changed files in this pull request and generated 1 comment.

File	Description
theme.json	Enables gradients/custom gradients for specific blocks; enables paragraph link color UI; turns on drop caps.
functions.php	Adds dynamic gradient preset generation based on active color scheme and registers it into filtered theme.json data.

---

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

[flintfromthebasement]

PR: #330 — Enable gradients in theme.json, dynamic gradient color palette
RachelRVasquez → dev | 2 files, +93 -1
#330

---

Summary
Solid feature, cleanly built and safely sanitized, but there's a real logic bug in the fallback path plus a naming mismatch in one gradient preset. Not mergeable as-is — both are quick fixes.

---

Issues

• Major functions.php:869 (new code, right after the palette-build block) — $theme_json_data['settings']['color']['defaultGradients'] = false; runs unconditionally, outside the if ( ! empty( $gradient_palette ) ) guard just above it:

  $gradient_palette = memberlite_build_gradient_palette( $active_colors );
  if ( ! empty( $gradient_palette ) ) {
      $theme_json_data['settings']['color']['gradients'] = $gradient_palette;
  }
  $theme_json_data['settings']['color']['defaultGradients'] = false;

  If any of color_button/color_secondary/color_action is missing from $active_colors, memberlite_build_gradient_palette() returns array() — but WP's default gradients still get disabled. Result: an empty gradient picker on button/group blocks instead of falling back to WP defaults. Move the defaultGradients = false line inside the non-empty check.

• Major functions.php (memberlite_build_gradient_palette(), the secondary-to-accent entry) — every other preset follows a base-color → its-own-darkened/lightened-variant pattern (secondary-to-dark = $sec→$sec_dark, accent-to-dark = $acc→$acc_dark), but this one is:

  'gradient' => "linear-gradient(90deg, {$sec_dark} 0%, {$acc_dark} 100%)",

  It uses the darkened variants of both colors instead of the plain $sec/$acc its name implies — a duller, muddier gradient than "Secondary to Accent" suggests, and inconsistent with the rest of the array. Looks like a copy/paste slip — swap in $sec and $acc.

• Minor — the live Customizer preview doesn't recompute gradients when colors change. js/customizer.js (untouched by this PR) only maintains --memberlite-color-* and --wp--preset--color--* CSS variables on color changes; there's no equivalent for --wp--preset--gradient--*. Gradients are baked into theme.json at page-load time from PHP, so a user changing color scheme in the live Customizer preview will see button/group backgrounds keep the old gradient until a full reload. Palette colors update live, gradients don't — worth a follow-up if live-preview parity matters here.

• Minor functions.php (the isset() guard in memberlite_build_gradient_palette()) — the all-or-nothing check on color_button/color_secondary/color_action means one missing color zeroes out all 7 gradients, including ones that don't use it (e.g. losing button-to-dark because color_action is absent). Combined with the defaultGradients bug above, one missing color currently means zero gradients in the picker. Consider gating each preset only on the colors it actually needs.

• Minor — the new function's docblock uses @since TBD; every other function in functions.php uses a concrete version (e.g. @since 7.1, @since 7.0.1), and current style.css version is 7.1.2. Fill in the real target version before merge.

---

Looks Good
Color handling is safe — $active_colors values are pre-sanitized via sanitize_hex_color_no_hash() upstream before this function sees them, so the raw interpolation into linear-gradient(...) carries no injection risk. The return-type declaration and early-return guard on memberlite_build_gradient_palette() are good defensive style, and the theme.json block-level enablement (core/button, core/group) is scoped correctly without disturbing anything pre-existing.

---

Questions

1. Was secondary-to-accent intentionally built from the darkened variants, or should it use plain color_secondary/color_action?
2. dropCap and paragraph link-color changes are unrelated to the gradient feature — intentional scope bundling, or split into a separate PR?

[RachelRVasquez]

Responding to Flint here.

• Major functions.php:869 (new code, right after the palette-build block) — $theme_json_data['settings']['color']['defaultGradients'] = false; runs unconditionally, outside the if ( ! empty( $gradient_palette ) ) guard just above it:

  $gradient_palette = memberlite_build_gradient_palette( $active_colors );
  if ( ! empty( $gradient_palette ) ) {
      $theme_json_data['settings']['color']['gradients'] = $gradient_palette;
  }
  $theme_json_data['settings']['color']['defaultGradients'] = false;
  

  If any of color_button/color_secondary/color_action is missing from $active_colors, memberlite_build_gradient_palette() returns array() — but WP's default gradients still get disabled. Result: an empty gradient picker on button/group blocks instead of falling back to WP defaults. Move the defaultGradients = false line inside the non-empty check.

I've made this fix. ✅

• Major functions.php (memberlite_build_gradient_palette(), the secondary-to-accent entry) — every other preset follows a base-color → its-own-darkened/lightened-variant pattern (secondary-to-dark = $sec→$sec_dark, accent-to-dark = $acc→$acc_dark), but this one is:

  'gradient' => "linear-gradient(90deg, {$sec_dark} 0%, {$acc_dark} 100%)",
  

  It uses the darkened variants of both colors instead of the plain $sec/$acc its name implies — a duller, muddier gradient than "Secondary to Accent" suggests, and inconsistent with the rest of the array. Looks like a copy/paste slip — swap in $sec and $acc.

This is not a copy/paste slip, I intentionally want this gradient to be a darker version of the Secondary and Accent colors. I've re-named the gradient to make that clearer. As for the "muddier" comment, this gradient will "pop" a but more once we merge in the new action/accent colors from PR #327.

• Minor — the live Customizer preview doesn't recompute gradients when colors change. js/customizer.js (untouched by this PR) only maintains --memberlite-color-* and --wp--preset--color--* CSS variables on color changes; there's no equivalent for --wp--preset--gradient--*. Gradients are baked into theme.json at page-load time from PHP, so a user changing color scheme in the live Customizer preview will see button/group backgrounds keep the old gradient until a full reload. Palette colors update live, gradients don't — worth a follow-up if live-preview parity matters here.

I've updated our customizer.js so gradients can be previewed in the live preview too. ✅

• Minor functions.php (the isset() guard in memberlite_build_gradient_palette()) — the all-or-nothing check on color_button/color_secondary/color_action means one missing color zeroes out all 7 gradients, including ones that don't use it (e.g. losing button-to-dark because color_action is absent). Combined with the defaultGradients bug above, one missing color currently means zero gradients in the picker. Consider gating each preset only on the colors it actually needs.

I'm okay with this all or nothing approach. Also makes future troubleshooting easier should we accidentally remove a color. We either have all the colors we need to provide a custom gradient palette for Memberlite or we don't. No need to over-engineer.

• Minor — the new function's docblock uses @since TBD; every other function in functions.php uses a concrete version (e.g. @since 7.1, @since 7.0.1), and current style.css version is 7.1.2. Fill in the real target version before merge.

Gets updated upon Pre-Release.

2. dropCap and paragraph link-color changes are unrelated to the gradient feature — intentional scope bundling, or split into a separate PR?

It's intentional. The change is so tiny, it seems like overkill to create an entire PR for two lines that are low risk when we're already making other changes to the theme.json. If there were more changes that were not related to the gradient changes, I'd consider a separate PR.