-
Hi team,
I have read (somewhere here in the forum) that you should not copy the GB-blocks, but rather duplicate them, because otherwise there are problems with duplicate IDs and the associated css then gets mixed up.
I didn’t know that before. I have questions about this:
On the page I am currently building, I have copied a page-hero (an element) over and over again and used it on other elements. As a result, all page-heroes now have the same ID.
Now I would like to know: if I change one page-hero, the other page-heroes should automatically change as well, because they all have the same ID and therefore the same css class.
But this does not happen. If I change one, the others remain unaffected. See URL
When I now look at the source code of my page, I see that all the CSS is inline on the page!
But in the GB settings I have set “css output method” to external file.1. Why does all the css end up inline in the HTML file, although it should be written to an external file?
2. Which is better: copying or duplicating? Duplicating creates a new ID, but copying does not.
If I use many divs with the same class, this should actually become a problem. Right?3. I see that it only doesn’t become a problem because each HTML page carries the entire css inline.
So there is no conflict with the identical IDs.
But the inline css is problematic for performance!Thanks for clarification!
-
Hi there,
The only scenario where blocks might have identical unique class IDs and cause conflicts is when they exist on the same page. In that case, the styles may clash due to overlapping CSS.
However, if blocks with the same class ID are on separate pages, they don’t interfere with each other. Here’s why:
– CSS is generated per page – GenerateBlocks only outputs CSS for the blocks used on the current page.
– Blocks are stored independently – Each page stores its own copy of block data in the WordPress database, so editing a block on one page doesn’t affect blocks elsewhere.
– CSS generation is scoped – During page rendering, the GenerateBlocks_Block class (and its child classes like GenerateBlocks_Block_Container) generates styles only for the blocks present on that page. It tracks block IDs in memory to ensure styles apply correctly and only within that context.
This behavior is consistent with how Gutenberg works — each page has its own isolated block rendering and styling process, even if blocks share similar IDs or classes.
Regarding the inline CSS issue — I checked the page you shared and didn’t see any inline CSS in the HTML. Perhaps you were referring to something else? Let me know so I can take a closer look.
-
Hi Alvind,
thanks for the information.CSS is generated per page – GenerateBlocks only outputs CSS for the blocks used on the current page.
I had previously assumed that the CSS for the individual GB blocks would be written to a separate, external file.
(In the GB settings I have set “CSS output method” to external file.)
External file means: A separate, external file is created for it – just like style.css in my childtheme.
I assumed that this external file would then of course apply to the entire site and not just to a single page.
So I am confused here.I checked the page you shared and didn’t see any inline CSS in the HTML.
I searched the source-code for the class .gb-element-eaf13555. This is the class that I had copied several times.
What I found was this: https://prnt.sc/pB8zbrEfRGcr / https://prnt.sc/pV-0X0FN7u1OThanks for clarification!
-
If you click the Regenerate CSS Files button under GenerateBlocks > Settings, is the CSS still being output inline?
-
If you click the Regenerate CSS Files button
It makes no difference, the CSS is still being output inline.
If you search the source-code for the class .gb-element-eaf13555, you will see what I mean.Well, I would like to understand that.
On the one hand, this inline CSS guarantees that there are no conflicts when I copy blocks (with identical IDs) from one page to another.
On the other hand, I would expect the CSS to actually be written to an external file if I set this in the GB settings.
But if I had an external file, then there would again be conflicts with the copy/paste from one page to the other, wouldn’t there?
-
If you search the source-code for the class .gb-element-eaf13555, you will see what I mean.
Yes, I see that. However, if your CSS Embedding Method is set to External File, there should be no inline CSS output in the HTML. The expected behavior is for all block styles to be compiled into a separate CSS file.
Is there any caching or optimization plugin installed on your site? Also, try deactivating all plugins except GP Premium and GenerateBlocks to rule out any potential plugin conflict that could be causing the issue.
But if I had an external file, then there would again be conflicts with the copy/paste from one page to the other, wouldn’t there?
That shouldn’t be the case. The inline CSS and external CSS should contain the same styles, the only difference is how they are delivered. One is embedded directly in the HTML (inline), and the other is loaded from an external stylesheet.
-
Is there any caching or optimization plugin installed on your site?
No
try deactivating all plugins except GP Premium and GenerateBlocks
I did that, but it did nothing
I have now tested various other projects: in some I find the CSS inline, in others I find references to external css files.
Although I always set CSS Embedding Method to External File!
I never use any caching or optimization plugins!Sorry Alvind, I really want to understand the whole thing and be sure if I can copy blocks across pages or if I always have to duplicate, or I want to know what I am doing, and why it is the way it is. And of course, for performance reasons, I want to make sure that GB sticks to the settings and saves the CSS commands in a separate file. Unfortunately, this does not happen reliably.
For example: please visit the page “Kontakt”. URL is in private field. There I have inserted the same page-hero (.gb-element-eaf13555), but on this page the CSS is suddenly saved in a separate file!
This is completely confusing!!!
So, what is happening here??
Maybe David can shed some light on this?The inline CSS and external CSS should contain the same styles, the only difference is how they are delivered.
Yes, I know what you mean. But the big difference is: the inline CSS only works locally on the respective page in which it is embedded.
The external file, however, has a global effect for the entire website (just like the style.css of the childtheme applies to the entire website and not just to a single page).That would mean that all changes I make to the block with the class .gb-element-eaf13555 would affect all other blocks of the entire site with the same ID.
This would not be the case with an inline CSS, because this only works locally on the page. Right?
Thanks for clarification!
-
Hi there,
good question , I’ll break it down and cover all the key points.
Local Block CSS
Local Block CSS is generated dynamically for each page, ensuring that stylesheets from different pages, even with duplicate block IDs, remain independent. Duplicate block IDs only cause issues if they appear on the same page, such as a block in the content area that also appears in a GP Element.As a result, updating a local block on one page will not affect other instances of the same block ID on different pages.
Inline vs External CSS Print Methods
Inline CSS:
Works across a wider range of server setups.
Slightly less performant in building CSS.
Always writes the CSS to an inline<style>tag within the page.External CSS:
May not work with some server setups.
More performant method for generating the CSS.
May print the CSS to an external file, depending on certain conditions. If those conditions aren’t met, the CSS will be printed as an inline<style>tag instead.Conditions for External CSS File:
1. CSS exceeds 500 characters:
The CSS will be moved to an external file for better performance.
This threshold can be adjusted with thegenerateblocks_css_inline_lengthfilter:add_filter( 'generateblocks_css_inline_length', function() { return 500; } );2. The page is a single post:
External files are disabled by default to avoid creating thousands of CSS files on websites with many posts. However, you can disable this limitation using thegenerateblocks_css_print_methodfilter:add_filter( 'generateblocks_css_print_method', function( $method ) { $saved_method = generateblocks_get_option( 'css_print_method' ); if ( is_single() ) { $method = $saved_method; } return $method; }, 20 ); -
Thank you very much for your reply, David
However, the question still remains for me why the CSS is written inline on most pages, although I have set it differently in the GB settings. There are only 2 exceptions (these are also linked in the private field)
2. The page is a single post = External files are disabled
The pages that I have linked in the private field are not single posts!
Nevertheless all these pages save the CSS inline in the<style>tagWhy is the CSS written inline for all these pages?
I would prefer it if all these pages would write the CSS to an external file (for performance), and I have so far assumed that this is how GB implements it – if my CSS Embedding Method is set to External File.
-
Can you try adding the following PHP Snippets to force the conditions to always add an external file:
add_filter( 'generateblocks_css_inline_length', function() { return 1; } ); add_filter( 'generateblocks_css_print_method', function( $method ) { $saved_method = generateblocks_get_option( 'css_print_method' ); if ( is_single() ) { $method = $saved_method; } return $method; }, 20 ); -
Unfortunately that makes no difference at all.
-
I have asked Tom to take a look. Thanks for your patience.
-
No problem, there is no hurry.
It would just be good to know in general why GB does not adhere to the settings.
Because I have now checked other (former) projects and noticed the same behavior there.
GB very often saves the CSS inline in the<style>tag, although the settings always require something else.Thanks!
-
Hi there,
I believe what’s happening here is that these pages do not have a page ID (they’re all archives).
Our single page CSS generating function requires some sort of numeric identifier to append to the file name.
This is likely something we can improve upon, as we can check for the archive ID and build the file name that way.
That being said, as of GB 2, it makes almost zero difference to performance to go inline vs external, which is awesome.
-
Hi Tom,
they’re all archives
OKAY, now I understand!!!
It’s confusing when you look at the pages and don’t understand what’s going on.May I summarize once again whether I have understood everything correctly?
1. GB always generates the CSS for each page individually (whether inline or as an External file).
This ensures that there are no conflicts if I have G-Blocks with identical IDs on different pages.
Only on the same page do I have to duplicate G-Blocks instead of copying them!2. If my CSS Embedding Method is set to External File, a CSS file is created for each individual page (in the directory: uploads/generateblocks).
Exception 1: The page is a single post:
External files are disabled by default to avoid creating thousands of CSS files on websites with many posts.Exception 2: The page is an archive:
These pages do not have a page ID to append to the file name.Can I save it like this? 😉
Thanks!!
—-
… as of GB 2, it makes almost zero difference to performance to go inline vs external, which is awesome.
That sounds really awesome, even if I don’t understand it.
Because in HTML I see the same code in my v1 projects as in the v2 projects:<style id='generateblocks-inline-css'> code code code ...... </style> -
Your summary is 100% correct.
As of GB2, all the CSS is generated and minified as you build your pages. By the time a visitor reaches one of your pages, all the plugin is doing is outputting the already-generated CSS. It’s very fast, regardless of whether you’re using internal or external files 🙂
- You must be logged in to reply to this topic.