Size Change: -258 B (0%)

Total Size: 889 kB

_{compressed-size-action}

We need to replicate the patterns introduced at #21131 and #21132 with this PR and update their JSON as well.

@nosolosw Good catch, it should be fixed.

The following bit in packages/block-library/src/button/style.scss could be removed as well:

.wp-gs .wp-block-button__link:not(.has-background) {
	background-color: var(--wp--color--primary);
}

I meant to delete it in some PRs that didn't land yet because it uses the wp-gs class that we don't want to expose atm. I guess it's fine to do it here as well to remove any trace of CSS vars just yet (although not really necessary if you don't want, as it is previous to the addition of the colors hook).

We also need to bring back these editor-styles.

Actually, I think it may be a theme issue (2019). Tested with 2020 and it works fine.

@nosolosw I'm still curious to understand why. Maybe some specificity issue somewhere.

I'll check. I believe we have something in the dev version of the plugin that resets the color palette in order to avoid failures in e2e tests due to theme changes. I wonder if it's related. Did you check if you had the same color palette before and after using the plugin?

I believe I ran into what you mention myself. However, I think it was due to the environment and not the plugin, though? I mention it because I'm not using any env bundled with Gutenberg for this testing.

Also: yes, same palette. In case it rings any bell:

OK, I think I got it. One thing that this PR modifies from WP 5.4 is that it doesn't inline the styles in the editor for presets (only for custom styles). It looks like that isn't enough for 2019 and this declaration kicks-in and takes precedence over the classes added by the presets.

Perhaps we can add that behavior back, even for the presets?

I'm pretty sure we didn't change anything about how presets are applied though. with or without this PR.

I've come to this today with fresh eyes, and this is what I've observed: what I reported before happens for old and new content using the TwentyNineteen theme --- in this branch, but also in master. I've pinpointed this issue to the addition of color hooks to the paragraph block (before that it works nicely).

This PR is a great addition that is good to land as soon as we can to avoid potential conflicts (like what happened for patterns). So, I wonder how do you want to proceed: shall we merge this one and investigate the issue separately? I'm happy to approve if so.

So, I wonder how do you want to proceed: shall we merge this one and investigate the issue separately?

Yes, let's do that, I'm planning to investigate the other issue today too.

@nosolosw @kjellr

I think I know what's happening. Previously we used to add the colors chosen as inline styles in the editor markup even if you choose a preset, while with the new approach, we're getting closer to the frontend and if you choose a palette color, we just apply the className. Twenty nineteen is not loading the entire palette color stylesheet in the editor which means when it's just the class that is added, the colors are not applied properly.

I believe the new approach is the right one since it matches frontend and backend more closely but it means 2019 needs to be patched to load the palette colors on the editor too.

I believe the new approach is the right one since it matches frontend and backend more closely but it means 2019 needs to be patched to load the palette colors on the editor too.

Ok cool, that's doable. Are other themes having this problem too?

Are other themes having this problem too?

Can't tell for sure, I can say that it works well in 2020

Previously we used to add the colors chosen as inline styles in the editor markup even if you choose a preset, while with the new approach, we're getting closer to the frontend and if you choose a palette color, we just apply the className. Twenty nineteen is not loading the entire palette color stylesheet in the editor which means when it's just the class that is added, the colors are not applied properly.

I believe the new approach is the right one since it matches frontend and backend more closely but it means 2019 needs to be patched to load the palette colors on the editor too.

Just noting that I opened a core issue for this...

https://core.trac.wordpress.org/ticket/50120

... and also discovered that it requires patches for almost all of the core themes. This makes me a little nervous that this change might end up resulting in widespread breakage of the color palettes in the editor. The fact that 2020 includes its custom colors in the editor styles might just be an anomaly.

@kjellr yeah, we should probably just add these inline styles again but I'm wondering how we can nudge folks to actually enqueue these styles in the editor too.

I'm wondering how we can nudge folks to actually enqueue these styles in the editor too.

For a lot of these sorts of updates, I see block-based themes & global styles as a potential changeover point. If your theme has block templates and a theme.json (or whatever we call it), then perhaps that's also an indication that your theme is ready to opt into future-forward updates like this and the alternate buttons markup.