mblack2000
Forum Replies Created
-
Thanks for the reply. I understand the steps you outlined for clearing Divi’s Static CSS and regenerating Hummingbird’s assets. Those steps do not address the underlying issue I described.
The problem appears to be trigger-related rather than cache corruption.
When editing pages using the Divi Visual Builder (although, upon testing, it appears to be for any editor), the save action does not appear to trigger Hummingbird’s per-page critical CSS regeneration. As a result, Hummingbird continues serving the previously generated critical CSS file even though the page structure has changed. Because Divi dynamically numbers sections and columns, the stale CSS often ends up applying background images or layout styles to the wrong elements.
Manually clearing Divi’s Static CSS and regenerating Hummingbird assets fixes it temporarily, but the problem returns after subsequent edits through the Visual Builder.
After reviewing Hummingbird’s Critical CSS module code, I implemented a workaround that forces Hummingbird to regenerate the page’s critical CSS whenever a page is updated. This appears to resolve the issue reliably.
Sharing the solution here in case it helps other users encountering the same behavior with Divi.
This essentially:
• Hooks into the page save event
• Prevents autosaves or revisions from triggering regeneration
• Confirms Hummingbird is available
• Calls the Critical CSS module’srecreate_post_css_file()method for that pageThis removes the stale critical CSS file, queues regeneration, and clears the page cache for that page.
So far this has resolved the issue when saving pages via the Divi builder without requiring manual cache clearing.
If there is a recommended or more official way to trigger this behavior through Hummingbird’s API or hooks, I would be happy to implement that instead. But based on the current codebase, this appeared to be the most direct solution.
Thanks again.
WordPress hook to force Hummingbird critical CSS regeneration on page save:
//--- Regenerate Critical CSS on Page Save ---//
add_action('save_post_page', 'trefoil_force_hummingbird_critical_css_regen', 20, 3);
function trefoil_force_hummingbird_critical_css_regen($post_id, $post, $update) {
if (defined('DOING_AUTOSAVE') && DOING_AUTOSAVE) {
return;
}
if (wp_is_post_revision($post_id) || wp_is_post_autosave($post_id)) {
return;
}
if (!$update) {
return;
}
if ('publish' !== get_post_status($post_id)) {
return;
}
if (!class_exists('\Hummingbird\Core\Utils')) {
return;
}
try {
$critical_css_module = \Hummingbird\Core\Utils::get_module('critical_css');
if (
$critical_css_module &&
method_exists($critical_css_module, 'recreate_post_css_file')
) {
$critical_css_module->recreate_post_css_file($post_id);
}
} catch (\Throwable $e) {
error_log('Hummingbird Critical CSS regen failed for post ' . $post_id . ': ' . $e->getMessage());
}
}- This reply was modified 2 months, 2 weeks ago by mblack2000.
You’ve made it very difficult to contact you about support for companies that choose to separate the billing user from the technical administrator without paying for extra seats. As such, I’m hoping you can see this request on this thread.
It appears when using Divi as a theme and clicking “save” within the Divi builder, the critical CSS does not regenerate for the page, painting outdated styles onto elements. Since Divi numbers its sections and columns, adding or removing these objects moves things like background images within the CSS to the object with the new number rather than utilizing the actual CSS saved to the page.
I suspect the critical CSS regeneration trigger is listening for the actual “save changes” button to be clicked within the WordPress page editor. If we use the visual builder from Divi, to save changes, we click the “Save” button on that interface, not the default WordPress page editor.
I was hoping you could add the ability for critical CSS to trigger a regeneration for a page from this save method in addition to the default page editor trigger.