Skip to content

Configurable background and text colour for ContentOverview and Testimonial#1487

Open
koechkevin wants to merge 2 commits into
mainfrom
fix/testimonial-background-color
Open

Configurable background and text colour for ContentOverview and Testimonial#1487
koechkevin wants to merge 2 commits into
mainfrom
fix/testimonial-background-color

Conversation

@koechkevin

@koechkevin koechkevin commented Jun 12, 2026

Copy link
Copy Markdown
Contributor

Summary

Extends the OpportunitiesList colour pattern to the ContentOverview and Testimonial blocks, so editors can set the section background and text colour from the CMS instead of relying on hard-coded values.

Changes

Each block now exposes backgroundColor and textColor via the shared colorSettingsField (defaults #fff / #000, rendered by the native ColourPicker), and each component applies them on its root Box (background + color):

File Change
payload/blocks/ContentOverview.js Add colorSettingsField (bg #fff, text #000)
components/ContentOverview/ContentOverview.js Read backgroundColor/textColor; apply on root Box, replacing hard-coded common.white
components/ContentOverview/ContentOverview.snap.js Snapshot update (root Box class hash)
payload/blocks/Testimonial.js Add colorSettingsField (bg #fff, text #000)
components/Testimonial/Testimonial.js Read backgroundColor/textColor; apply on root Box, replacing hard-coded #fff

Screenshots

image

Testing

  • eslint clean on all changed files.
  • ContentOverview: 5 tests + snapshots pass. Testimonial: 7 tests pass.

Kevin Koech added 2 commits June 12, 2026 15:57
Mirror the OpportunitiesList pattern: the block exposes backgroundColor and
textColor via colorSettingsField (defaults #fff / #000), and the component
applies them on its root Box (background + color), replacing the hard-coded
white background.
Mirror the OpportunitiesList/ContentOverview pattern: the block exposes
backgroundColor and textColor via colorSettingsField (defaults #fff / #000),
and the component applies them on its root Box (background + color),
replacing the hard-coded white background.
@koechkevin koechkevin self-assigned this Jun 12, 2026
@koechkevin koechkevin added the enhancement New feature or request label Jun 12, 2026
@koechkevin koechkevin requested a review from kelvinkipruto June 12, 2026 13:55
@koechkevin

Copy link
Copy Markdown
Contributor Author

@claude review

@claude

claude Bot commented Jun 12, 2026

Copy link
Copy Markdown

Claude finished @koechkevin's task in 1m 43s —— View job


Code Review

  • Gather context and understand the request
  • Read changed files
  • Analyze for bugs, security issues, and best practices
  • Post review findings

Overall the approach is clean and consistent with the OpportunitiesList pattern. Two items worth addressing, one of which is functional.


textColor has limited effect in ContentOverview

This is the main concern. Setting color: textColor on the root Box relies on CSS inheritance to propagate the colour to child elements. However, nearly every text element in ContentOverview sets an explicit hardcoded color in its sx style object, which takes precedence over inherited values:

// ContentOverview.js – static sx objects with hardcoded colours
const headingSx       = { ..., color: "#0A1628" };
const bodySx          = { ..., color: "#252B37" };
const cardTitleSx     = { ..., color: "#0A1628" };
const cardRichTextBodySx = { ..., color: "#3E4159" };
const itemLabelSx     = { ..., color: "#3E4159" };
const itemLinkSx      = { ..., color: "#1020E1" };
const itemValueSx     = { ..., color: "#3E4159" };

Because these sx declarations always win over inherited color, an editor who sets a white text colour on a dark background will see no change in any of those elements — the text will still render with its hardcoded dark colour. The textColor prop is effectively a no-op for the visible content of ContentOverview.

Contrast with Testimonial, where the title Typography only sets fontWeight/mb (no color), and LexicalRichText's TypographyProps only sets lineHeight — so textColor inheritance works correctly there.

To fix this in ContentOverview, the static sx objects would need to be converted to dynamic sx functions/callbacks that read from props (or accept textColor as a parameter), so the colour slots can be derived from textColor rather than hardcoded. Fix this →


Minor: background vs backgroundColor shorthand

OpportunitiesList (the reference pattern being followed) uses the CSS background shorthand:

// OpportunitiesList.js:246
sx={{ background: backgroundColor, color: textColor, ...sx }}

Both ContentOverview and Testimonial use backgroundColor instead. backgroundColor is actually the more precise choice (it won't accidentally reset background-image), but it's a minor inconsistency with the established pattern. Fine to keep as-is.


Everything else looks good

  • Payload block definitions are correct — colorSettingsField is called with the right overrides, CMS defaults (#fff/#000) match the component-level prop defaults.
  • The colorSettingsField base default for textColor is #FFFFFF but the textOverrides: { defaultValue: "#000" } override correctly changes it to black for both blocks.
  • Testimonial changes are clean — backgroundColor and color: textColor work correctly there since child text styles don't override the inherited colour.
  • Snapshot hashes change due to the sx change on the root Box (from backgroundColor: "common.white" to backgroundColor: "#fff" + color: "#000"). Correct.
  • The colorSettingsField placement in the ContentOverview payload block (between content and card) is reasonable CMS UX.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

enhancement New feature or request

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant