[Resolved] Footer element generating inline CSS

[Rekindle]

Hi,

I’m in the process of migrating our site to GeneratePress + GenerateBlocks, and I’m loving my experience so far.

I’ve created a footer element using GP + GB. Both GP and GB are set to print CSS to an external file. But for some reason, on some pages, the footer’s CSS is being printed to an external file, but on some others, it prints it correctly to an external file.

Page with inline CSS: https://snipboard.io/TLtvbz.jpg (it’s behind a login)
Page with external CSS: https://snipboard.io/s5NMdA.jpg (link to page)

Why is this happening? How can I make sure that it always prints CSS to an external file?

Thanks!

[Tom]

Hi there,

The plugin isn’t always able to create an external file – some pages simply don’t allow it (mainly ones without a page ID, like dynamic pages). In those cases, it will default to printing inline.

However, the external file/inline embedding shouldn’t really matter if you use a plugin like Autoptimize (or any caching plugin) that compiles all of your CSS in one CSS file. That may be the way to go here?

Let me know 🙂

[Rekindle]

Hi Tom, thanks for the explanation. Maybe I’ll explain what I’m trying to do so you can let me know if there is a GP-way of solving this.

We have a webpage being dynamically generated for each user using PHP at the backend. (It therefore doesn’t have a page ID, and that explains why it ends up with inline footer CSS). Before GP + GB, the PHP and the associated CSS was hand-coded. I’m trying to get rid of as much hand-written CSS as possible for easy maintenance.

What I did was to create that page design using GB, went to the source HTML, and copy-pasted sections of that back into the HTML file. I copied GB’s dynamically generated CSS file into the plugin folder. Everything works well, except some of this inline footer CSS is overriding rules in the external CSS.

The only solution I can think of is for me to manually change some of the rules in the external file, but this will make maintenance more difficult. Is there a neater solution to this problem?

Thanks!
p.s. I love your support forum! I have searched a ton of my queries using site:generatepress.com (also similarly for GB) and I’ve found answers for every one of them.

[Tom]

except some of this inline footer CSS is overriding rules in the external CSS.

If this is a static HTML page, how is the inline footer CSS being added? Any chance you can show me a screenshot of this CSS in the source?

Just to confirm, you have a static HTML page (not WordPress), and you’ve added the HTML and CSS from a GenerateBlocks page to it?

[Rekindle]

Hi Tom,

I see what you mean. To clarify, this is not a static HTML page (I’m not a developer so I used that word wrongly). It is a WordPress page with a shortcode in it. The content for that shortcode is being generated by a custom plugin. So this page does have an ID on the backend.

So what I did was create another page using GB that would look like how I want the original page (we call it the Today page) to look. I then copied the HTML bits from the GB page, stuck it into the plugin, saved the CSS file under a different name and hoped it would work. But the Today page has inline CSS for the footer – I’m not sure why. You can see screenshots and login info below.

Thanks again.

[Tom]

Is there any particular reason for doing it that way? The HTML you’re copying is the HTML that’s been parsed by WordPress – it’s not the actual full HTML generated when you save your content.

GenerateBlocks needs the un-parsed HTML in order to generate CSS, as that un-parsed HTML holds all of your settings.

Once the HTML makes it to your live page, it’s been parsed and no longer has your settings in the HTML comments.

[Rekindle]

Hi Tom,

I didn’t quite understand your comment, so I clicked on “Edit as HTML” option in GB, and now I have a better understanding of how it works behind the scenes.

But if I replace the final HTML with the unparsed HTML in the plugin, it looks like GenerateBlocks doesn’t get a chance to parse it. All the GenerateBlocks settings just show up as HTML comments on the frontend.

So how would I solve this? Should I just have individual shortcodes for different pieces of information and then put those shortcodes in the GenerateBlocks editor? This will turn out to be a longer project since I’ll have to significantly change the plugin.

Thanks!
p.s. You can find a couple of screenshots below to make sure I’m explaining things clearly.

[Tom]

Just to be clear, are you trying to add GB-created HTML inside a shortcode?

If so, it’s definitely a complicated thing to do, as it kind of goes against how Gutenberg itself works.

Perhaps it would make more sense to create shortcodes for the dynamic aspects of your content, then add them onto the page you’ve built using GenerateBlocks? That way it will parse correctly and the dynamic aspects of the content will still be dynamic due to the shortcodes?

[Rekindle]

Hi Tom,

are you trying to add GB-created HTML inside a shortcode?

Yes. I think this is the quicker solution for now, since I don’t to create multiple shortcodes for now (my PHP skills are limited, and I want to change the theme to GeneratePress soon).

Perhaps it would make more sense to create shortcodes for the dynamic aspects of your content, then add them onto the page you’ve built using GenerateBlocks? That way it will parse correctly and the dynamic aspects of the content will still be dynamic due to the shortcodes?

This makes sense longer-term.

Thanks again for your help Tom. I love what you’re doing with both GeneratePress & GenerateBlocks!

[Tom]

No problem! It will definitely be easier to work with WP and GB instead of against them. While it’s likely possible to do it your way, it would involve multiple parsing steps and quite a bit of trial and error to get going.

[Author]

Posts