-
Anonymous
This is a bit of a long post, and I will say upfront that I found a workaround. It’s just not optimal, and I wanted to bring this to your attention in case you can address it as you help GeneratePress and GenerateBlocks work more seamlessly together.
We have some base CSS styles that we load sitewide, including in Gutenberg so we can get editing content in Gutenberg to be as similar to the frontend as reasonably possible. To that end, the ‘generateblocks_default_button_attributes’ filter is very helpful because we can get GenerateBlocks 2.0 buttons to have a ‘button’ class by default so we can style them as buttons and remove default attributes that are included when you add a Button block. That’s working great!
One CSS property that I found is not as simple to get to match in Gutenberg is the border-radius for buttons. By default GeneratePress adds some CSS for the ‘a.button’ selector (among other ones). Interestingly, this style is not added in the front end of the site (just Gutenberg). Since this ends up being loaded later in Gutenberg than our custom CSS, we’d have to use a higher specificity to override it, which is not ideal for base styles that we are trying to make easy for the theme or user to override. (I’d like to just have our selector just be ‘.button’ anyway.)
Since this style is loaded by default without any easy way to override it, the only way I’ve been able to remove it is by using the ‘block_editor_settings_all’ filter with some regex parsing to remove the border-radius property. This could be a bit fragile and is certainly not super efficient since I have to run the regex against all the editor settings since I haven’t found a way to reliably select just that specific GeneratePress setting that adds the CSS.
The CSS property causing this is added by line 313 in generatepress/inc/block-editor.php. From what I can tell, it seems to be added unconditionally (at least I haven’t found a way to stop it from being added). And as I mentioned before, that style is not added to the front end (so no issue there). It is only Gutenberg where the border-radius is set to 0 by default.
All in all, I’m loving GeneratePress and GenerateBlocks 2.0. So thanks for all your hard work!
-
Hi there,
I do not see the CSS in my block editor.
I checked line 313 of
block-editor.php, but I couldn’t see if the code is related to the CSS.For your reference, this is the screenshot of the
block-editor.phpfile.
https://app.screencast.com/d9VrXLTgppLMlAre you able to take a screenshot of the CSS in the editor?
Let me know 🙂
-
Anonymous
I see where the confusion is. I forgot that I had added some debugging lines to the code in my local copy, which of course would change the line number. It should be 307. Here’s a link to the line number I’m talking about in GitHub: https://github.com/tomusborne/generatepress/blob/e0de8debd876b1aea3136c815dc01ad1c95d778f/inc/block-editor.php#L307
Below is the CSS that contains the
border-radius:0in the block editor. WordPress is loading the iframed editor since I have any blocks less than API version 3 disabled. I don’t know if that affects the GeneratePress CSS or not.<style>:root{--neutral:#ffffff;--primary-dark:#0d6030;--primary-medium:#217444;--text-shadow:#000000;--accent-light:#f9f9eb;--accent-medium:#e0d0b6;}.has-neutral-color{color:var(--neutral);}.has-neutral-background-color{background-color:var(--neutral);}.has-primary-dark-color{color:var(--primary-dark);}.has-primary-dark-background-color{background-color:var(--primary-dark);}.has-primary-medium-color{color:var(--primary-medium);}.has-primary-medium-background-color{background-color:var(--primary-medium);}.has-text-shadow-color{color:var(--text-shadow);}.has-text-shadow-background-color{background-color:var(--text-shadow);}.has-accent-light-color{color:var(--accent-light);}.has-accent-light-background-color{background-color:var(--accent-light);}.has-accent-medium-color{color:var(--accent-medium);}.has-accent-medium-background-color{background-color:var(--accent-medium);}body{--content-width:calc(1300px - 40px - 40px);}body .wp-block{max-width:var(--content-width);}.wp-block[data-align="full"]{max-width:none;}.wp-block[data-align="wide"]{max-width:1300px;}.wp-block a{text-decoration:none;}.wp-block-group__inner-container{max-width:1300px;margin-left:auto;margin-right:auto;padding:40px;}a.button, a.button:visited, .wp-block-button__link:not(.has-background){color:#ffffff;padding:10px 20px;border:0;border-radius:0;}a.button:hover, a.button:active, a.button:focus, .wp-block-button__link:not(.has-background):active, .wp-block-button__link:not(.has-background):focus, .wp-block-button__link:not(.has-background):hover{color:#ffffff;}body{color:#000000;}.content-title-visibility{color:#000000;}.block-editor__container .edit-post-visual-editor{background-color:#ffffff;}body{background-color:#ffffff;}a{color:#0060dd;}a:hover, a:focus, a:active{color:#0060dd;}</style> -
Anonymous
Minor update to this. Since working on this more, I’ve expanded my regular expression to take out more of the CSS that I noted above as it helps the sitewide CSS be picked up better and not overwritten in Gutenberg. So maybe it would be nice for there to be an easy way to opt-out of some of the styling GeneratePress adds in if we are relying more on a combination of custom CSS and GenerateBlocks styling. Though admittedly, we may be a more unique use case since we use some basic custom CSS in a custom plugin to lay out some shared styles between sites and then GenerateBlocks to build on top of that for more specific customizations per site/page.
-
Thanks for the info, I can see the inconvenience with custom stylesheets in your case.
This is the first time I actually heard such an issue, so it’s likely working fine for most of the users.
I’ll pass the issue to the dev team 🙂
-
Hi there,
Definitely not ideal as we continue to move toward a block-based design system where the theme does very little.
I wonder if simply disabling theme styles in your case would be beneficial, or if there are still some theme styles in there that are essential?
You could do so like this:
add_filter( 'generate_show_block_editor_styles', '__return_false' );Let me know 🙂
-
Anonymous
Sorry for the delayed response. I’m out of the office this week, but I’m still trying to keep up with some things.
Thank you for calling out the
generate_show_block_editor_stylesfilter. That did disable editor styles that were getting in the way. It also removed the global colors that are configured in the Customizer, but I was able to add those back in by getting them fromgenerate_get_global_colors()and adding them as inline styles (similar to what GeneratPress was doing before turning off the block editor styles I think).I still need to do more thorough testing, but it seems to be working well at first glance.
Please let me know if any of what I said above regarding colors seems problematic to you.
Thanks!
-
That sounds good to me. It would be nice if we could implement a better solution that didn’t require a workaround. I’ve made a note of it.
Thanks!
-
Anonymous
Thanks! I appreciate it. At least this is better than the growing regex I was using before.
- You must be logged in to reply to this topic.