fix: remove colour label changes to avoid bleeding into other blocks

[laurelfulford]

All Submissions:

• Have you followed the Newspack Contributing guideline?
• Does your code follow the WordPress' coding standards and VIP Go 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:

The Author Profile block's Social Links block includes some code that relabels the Color and Background colour pickers to Icon Color and Icon Background. This is having an unintended side effect and bleeding into other block settings.

This PR changes the approach to match how this is handled in Core's Social Links block, to (hopefully!) make it a little less fragile (the alternative seemed to be checking if the Author Profile social links block was active again and again, and adding/removing the label, but that seemed subpar).

Another option would be just to show the default 'Text' prefix. It's not as nice UX-wise, but much simpler under the hood. It doesn't match Core's Social Links block, but it matches the labelling in Core's new Icon block coming in WP 7.0.

Closes NPPD-1458

How to test the changes in this Pull Request:

1. Using the Block Theme, edit one of the Single Post templates in the Site Editor (after resetting it if it has saved changes). These templates will already have the Author Profile block in place.
2. In the site editor, click on any of the other blocks -- like the Post Title block -- and note the colour settings:

3. Apply this PR and run npm run build.
4. Refresh the editor, and ensure standard blocks are no longer inheriting the 'Icon' prefix on the colour picker.
5. Edit the Author Profile block and select the Social Icons block.
6. Confirm the Colors panel shows up on the Style tab, under the Styles panel
7. Ensure each colour has the prefix 'Icon'
8. Try togglng the block between Default and Brand styles, and confirm that the colour pickers go away when "Brand" is picked, and appear again when "Default" is picked.
9. Try changing the icon colours and saving - confirm colours can be changed and saved, and switching back to the Brand style switches back to the branded colours.

Other information:

• Have you added an explanation of what your changes do and why you'd like us to include them?
• Have you written new tests for your changes, as applicable?
• Have you successfully ran tests with your changes locally?

[Copilot]

Pull request overview

This PR narrows the editor-side color-panel relabeling logic for the Author Social Links block so the “Icon color / Icon background” overrides only run when that block is selected, instead of affecting unrelated block inspectors in the Site Editor.

Changes:

• Adds isSelected to the Author Social Links edit component and gates the sidebar mutation effect on block selection.
• Updates the effect dependencies so the relabel/hide behavior re-runs when selection state changes.
• Documents the new prop and the intent of limiting the sidebar mutations to the active block.

---

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

[Copilot]

Pull request overview

Copilot reviewed 3 out of 3 changed files in this pull request and generated 3 comments.

---

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

[adekbadek]

The bug fix itself is well-targeted and works end-to-end in the Site Editor — Article Subtitle and other unrelated blocks now show plain Text/Background labels, and the new in-block colour panel works as described, including the Brand-style hide/show.

One blocker before merge: removing the color supports from block.json without a deprecated registration is a silent-data-loss path for posts saved under the current shipped version.

A handful of polish items below — see the inline comments.

[adekbadek]

Blocker: Removing color.text / color.background supports without a deprecated registration is a silent-data-loss path for the ~30 days of posts (production since v6.37.0 / 2026-04-13) that have been saving textColor / backgroundColor / style.color.text / style.color.background under the previous schema. Because save: () => <InnerBlocks.Content /> returns no attribute markup, block validation won't fail loudly — the old keys are dropped from parsed attributes on first load, and on the frontend the new PHP resolve_color() never reads them, so the configured colours disappear silently and the data is gone on next resave. Verified in-env by saving a post with the old shape and loading the frontend: no --icon-color / --icon-background set despite the saved attrs.

Needs a deprecated entry registering the previous attribute shape with a migrate(attrs) mapping textColor → iconColor, style.color.text → iconColorValue, backgroundColor → iconBackgroundColor, style.color.background → iconBackgroundColorValue (and stripping the empty style.color).

[adekbadek]

Suggestion: Worth manually confirming that picking a theme preset colour writes to iconColor (the slug attribute), not just iconColorValue. ColorGradientSettingsDropdown's onColorChange passes a single value, and withColors' setter is responsible for resolving it back to a slug by iterating the palette — Core's core/social-links uses the same pattern, but if for any reason iconColor never gets populated, the docblock claim in class-author-profile-social-block.php ("Prefers the preset slug so theme switches reflect new palette values") doesn't hold and the frontend always emits a raw hex.

[adekbadek]

Suggestion: resolve_color() returns var(--wp--preset--color--<slug>) whenever the slug is set, even if the active theme doesn't define that slug — the resulting CSS variable is unresolved and the icon renders uncoloured on the frontend. The editor side (via withColors's getColorObjectByAttributeValues) falls back to iconColorValue in that case, so editor preview and frontend can diverge on theme switch.

Either make the fallback symmetric (prefer iconColorValue when present, regardless of slug), or drop the "theme switches reflect new palette values" claim from the docblock.

[adekbadek]

Nit: Good that the rationale is documented now. The actual reason for the snapshot is more defensive than "the inner blocks have already rendered": each inner WP_Block::render() snapshots/restores $block_to_render around its own callback, so this should already be back to the parent's parsed_block by the time get_block_wrapper_attributes() is called. The snapshot here guards against a third-party filter or future Core change breaking that chain. Worth rewording the comment to reflect "defensive against the inner-render chain leaking the static" rather than "already rendered".