You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Adding a palette entry in the Edit Theme Settings modal currently requires the user to type both the human-readable Name and a separate slug. The slug must be lowercase alphanumeric + dashes/underscores (server-side sanitize_key()), so users either type it twice or hit save-time errors. Worth auto-deriving slug from name as the user types.
Behavior
On a new palette row, typing in the Name field auto-fills the Slug field with the slugified name.
Auto-sync stops the moment the user manually edits the Slug field (per-row sticky flag).
Existing rows (loaded from theme.json) do not auto-sync — changing a saved slug is breaking, since CSS variables reference it (--wp--preset--color--<slug>).
If slugification produces an empty string (e.g. a name composed entirely of non-Latin characters), the slug field stays empty and the existing server-side validation surfaces the issue at Update time.
Transliteration
cleanForSlug from @wordpress/url is the JS equivalent of PHP's sanitize_title(). It quietly strips characters it can't normalize:
#812 (reported by @hagege) calls this out as a bug in the existing "Save Changes to Theme" flow — the same transliteration concern applies to both flows.
Mappings the issue asks for:
ä → ae, Ä → Ae
ö → oe, Ö → Oe
ü → ue, Ü → Ue
ß → ss
Other languages with common transliterations (Nordic, Polish, Turkish, etc.) likely deserve coverage too. A general-purpose library (unidecode, transliteration) handles a wide range at the cost of bundle size; a curated map of European-language characters keeps the bundle small but misses long tail. Worth a design discussion in this issue before implementation.
Scope
Implementation should:
Live in a shared util (src/utils/slugify.js or similar) so both the new Edit Theme Settings modal and the existing Save Changes to Theme flow (Issue with (german) umlaut #812) can use the same logic.
Follow-up to #838.
Why
Adding a palette entry in the Edit Theme Settings modal currently requires the user to type both the human-readable Name and a separate slug. The slug must be lowercase alphanumeric + dashes/underscores (server-side
sanitize_key()), so users either type it twice or hit save-time errors. Worth auto-deriving slug from name as the user types.Behavior
theme.json) do not auto-sync — changing a saved slug is breaking, since CSS variables reference it (--wp--preset--color--<slug>).Transliteration
cleanForSlugfrom@wordpress/urlis the JS equivalent of PHP'ssanitize_title(). It quietly strips characters it can't normalize:cleanForSlugGrüngr-ngruenÜber rotber-rotueber-rotStraßestraestrasseCafécafecafe✓色#812 (reported by @hagege) calls this out as a bug in the existing "Save Changes to Theme" flow — the same transliteration concern applies to both flows.
Mappings the issue asks for:
ä→ae,Ä→Aeö→oe,Ö→Oeü→ue,Ü→Ueß→ssOther languages with common transliterations (Nordic, Polish, Turkish, etc.) likely deserve coverage too. A general-purpose library (
unidecode,transliteration) handles a wide range at the cost of bundle size; a curated map of European-language characters keeps the bundle small but misses long tail. Worth a design discussion in this issue before implementation.Scope
Implementation should:
src/utils/slugify.jsor similar) so both the new Edit Theme Settings modal and the existing Save Changes to Theme flow (Issue with (german) umlaut #812) can use the same logic.References