PaletteEdit: dedupe palette element slugs

[ramonjd]

What?

Part of #43197

First pass at deduping palette slugs

Why?

The color palette uses the palette item name to generate a slug. So, Test 1 will be custom-test-1.

If there are identical names, the slugs would normally be the same. Slugs should be unique identifiers so they can be correctly applied as CSS vars.

How?

When updating palette item names, check for duplicate slugs. If duplicates are found, update those slugs.

Testing Instructions

In Site Editor > Global Styles > Colors > Palette create multiple custom colors and gradients.

Give all or some of each the same name.

Save and try to apply your custom colors in the editor.

They should work in the front and backend.

Testing Instructions for Keyboard

Screenshots or screencast

Given a series of duplicate names:

The custom palette is still operable due to unique slugs:

Kapture.2024-10-01.at.16.45.27.mp4

Which are saved to global styles and output in the frontend

[github-actions]

The following accounts have interacted with this PR and/or linked issues. I will continue to update these lists as activity occurs. You can also manually ask me to refresh this list by adding the props-bot label.

If you're merging code through a pull request on GitHub, copy and paste the following into the bottom of the merge commit message.

Co-authored-by: ramonjd <[email protected]>
Co-authored-by: aaronrobertshaw <[email protected]>
Co-authored-by: ciampo <[email protected]>

To understand the WordPress project's expectations around crediting contributors, please review the Contributor Attribution page in the Core Handbook.

[aaronrobertshaw]

Thanks for fixing this one @ramonjd, I'm sure it was annoying for people maintaining color palettes 👍

This PR tests well for me. I didn't run into any issues and only left a couple of very minor nits as inline comments.

✅ Custom colors with various duplicate slugs now work
✅ Same for custom gradients
✅ Duplicate named colors work both frontend and in the editors (site/post)

LGTM 👍

Screen.Recording.2024-10-03.at.3.11.32.pm.mp4

[aaronrobertshaw]

I believe I've addressed the remaining feedback.

@ramonjd should be back online later next week but if you're happy enough with this PR @ciampo, it might be a nice one to land and get included in the next 6.7 beta. What do you think?

[ciampo]

Sounds good! I rebased, fixed conflicts, and will merge as soon as CI is green

[github-actions]

There was a conflict while trying to cherry-pick the commit to the wp/6.7 branch. Please resolve the conflict manually and create a PR to the wp/6.7 branch.

PRs to wp/6.7 are similar to PRs to trunk, but you should base your PR on the wp/6.7 branch instead of trunk.

# Checkout the wp/6.7 branch instead of trunk.
git checkout wp/6.7
# Create a new branch for your PR.
git checkout -b my-branch
# Cherry-pick the commit.
git cherry-pick 597c7d97e5da343eaab9556a30c875cde0a0647f
# Check which files have conflicts.
git status
# Resolve the conflict...
# Add the resolved files to the staging area.
git status
git add .
git cherry-pick --continue
# Push the branch to the repository
git push origin my-branch
# Create a PR and set the base to the wp/6.7 branch.
# See https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/proposing-changes-to-your-work-with-pull-requests/changing-the-base-branch-of-a-pull-request.

[ciampo]

it might be a nice one to land and get included in the next 6.7 beta

@aaronrobertshaw I tried but there's a conflict when merging. I'm about to go offline for the week — would you be able to take care of manually backporting when you're back offline? Otherwise I'll do it myself when I come back online on Monday

[ciampo]

Manual backport #65905