-
Notifications
You must be signed in to change notification settings - Fork 4.2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Different class names for preset slugs #32347
Comments
This seems that has been in Gutenberg for a long time: I hadn't seen reported before, so either theme authors adapted to this quirk or nobody had run into this yet. I'd think I'd discard 2, as I don't think the lodash's kebab case logic for numbers is something consistent or easy to understand. Also, porting the same behavior to the server may prove problematic should the lodash's behavior change to add new cases. 1 vs 3. We take slugs, which is something people already provide normalized (using cc @jorgefilipecosta @youknowriad for thoughts. |
I think we should just remove has-${ kebabCase( slug ) }-preset, from the client and do any processing on the slug. Slugs were expected to be used as is in the class. |
Note that by doing 1 (or 3, for that matter), existing blocks will still work as expected:
Going to implement 1 then. We can refine after if necessary. |
I've prepared #32352 to remove the processing from the client. However, I'm having second thoughts about removing the processing entirely. It feels we should make sure classes don't have whitespace. If the slug contains whitespace there may be other things that break, I haven't checked. Anyway, making sure the classes the system generates don't break because they have whitespaces seems something to care about. |
Reopening as we have to revert the PR that fix it #32742 |
I think it's fine to continue to use It's probably okay to ignore the special treatment of ordinals for now -- it's enough of a edge case to tell people "don't use those" maybe 😬 |
So, If a slug is not actually invalid, it should not be altered. Can we get a flag or hook for handling this on our own? |
Got an in-progress PR to fix this at #32766 |
@justintadlock I hear your frustration and I feel it myself. I wish we didn't have to do this. To clarify direction: the front and the site editor are going to behave like the post editor has been behaving since the beginning. This is, a slug such as |
I'm just asking that we have an easy way for those of who wish to fix this on our end be able to do so. Please just add filter hooks in the appropriate areas as part of the changes or a way to flag a slug with a number in it from being mangled. |
I'm not really familiar with the JavaScript side of things, but looking over the JS hooks system, something like this could suffice for colors: // Original
return `has-${ kebabCase( colorSlug ) }-${ colorContextName }`;
// New
return applyFilters(
'colorPresetSlug',
`has-${ kebabCase( colorSlug ) }-${ colorContextName }`,
colorSlug
); And, for font sizes: // Original
return `has-${ kebabCase( fontSizeSlug ) }-font-size`;
// New
return applyFilters(
'fontSizePresetSlug',
`has-${ kebabCase( fontSizeSlug ) }-font-size`,
fontSizeSlug
); The proposed |
Hi @justintadlock, thank you for suggesting a possible fix using filters. The problem with a filter-based approach is that given that classes are part of the blocks markup as soon as the plugin that has this filter is installed all the blocks created with the old markup before the filter was there don't match the new markup and would be considered invalid. The same after a plugin is disabled the markup produced for a block without the plugin would be different and blocks created while the plugin was active would become invalid after the plugin is disabled. |
I was more thinking the filter would come from a theme, but it doesn't really matter. Are you saying that the block markup would literally be invalid in terms of creating an error? Or, are you saying that simply the markup would be different? I have seen no block invalidation between the time before the fix was added, the time since the fix went in, and the time of the reversal of the fix. The classes are merely different. Now, I have sites (and some of my theme users have sites) with different classes. And, the more recent "fix" of the whole system looks like it will break my earlier front-end correction of the markup. Of course, I can probably just address this with some extra bloat to my CSS for covering both cases. It seems to me to be no different than when users switch between one theme and the next, each with their own slugs. |
Themes provide some presets to the editor, such as font sizes and colors, either via the
add_theme_support
#26940 or thetheme.json
#31629The slug of the preset values is used to generate a class name in two different situations:
.has-slug-preset { ... }
What's the issue
When the slug contains a number, the class attached to the block markup and the class generated for the stylesheet are different. See issues reported at #31629 and #26940 There's also issues with slugs that contain camelCased words.
slug1
.has-slug-1-preset
.has-slug1-preset
2slug
.has-2-slug-preset
.has-2slug-preset
slug3number
.has-slug-3-number-preset
.has-slug3number-preset
4th
.has-4th-preset
.has-4th-preset
5sl
.has-5-sl-preset
.has-5sl-preset
slugNumber
.has-slug-number-preset
.has-slugnumber-preset
Notice how the server doesn't process the slug but the client splits by number, except if the slug is an English ordinal such as
4th
. The client also converts camelCased slugs into kebab-cased slugs, while the server doesn't.Why this happens
In the client, both for font-sizes and colors we use the lodash's kebabCase function to process the incoming slug such as:
The lodash's kebabCase function has the particularity that it considers numbers as something to separate as well, unless they're English ordinals.
In the server, we don't process the slug but output it as it is:
How to fix it
Do not do any processing to the slug in the client, but use the incoming value. Existing classes would still work: the old slug is recognized as an extra class and because the theme should have enqueued it, it'll still work.
Replicate the lodash's kebabCase logic (including English ordinals) in the server.
Use our own regexp / function to do the same in both places, to make sure changes to lodash's kebabCase don't affect us.
The text was updated successfully, but these errors were encountered: