[Hummingbird] Elementor & Hummingbird

There seems to be a problem with Elementor Page Builder and Hummingbird. I need to manually clear page from cache each time I have done changes to a page in Elementor.
I thought the option "Clear full cache when post/page is updated" would help with this issue, but no such luck.

  • Adam Czajczyk

    Hello Kjetil Wikestad

    I hope you're well today and thank you for your question!

    I have just run some tests for this on my test site and I couldn't replicate the issue. When I checked the caching debug.log, it was showing that cache was purged upon editing. I could also see all the changes on front-end (checking in another browser as a not-logged in visitor) without the need to clear cache.

    However, it's possible that either my test was a bit "too simple" and I missed something or that there's something "interfering" on your setup. That being said, I would like to take a closer look at your site in order to test it again. To do so, I would need to be able to access your site so could you please enable support access for me?

    You can do it by going to the "WPMU DEV -> Support" page in your site's back-end and clicking on "Grant support access" button there:

    Let me also know, please, if there are any specific changes/steps I should make with Elementor to see the issue and where on your site (e.g. any specific page or can I just create some temporary page for testing?) can I test that.

    Best regards,
    Adam

  • Kjetil Wikestad

    Hi!

    I have done some research and I found the problem with Elementor and Hummingbird on my sites.

    On my webserver resources like css and js are set to expire in 8 days.

    I have optimized my assets in Advanced mode in Hummingbird so that a page only requests 1 .css file that contains all css for that page.

    If I use Elementor to make css changes on a page then the .css file for that page is updated, but my optimized page .css will not change. The only way for me to get an updated .css file is for me to clear the assets cache.

    To make things even worse, the updated hash name for the new .css is the same as the old one. So visitors to the site will only get an updated version after 8 days!

    To make this work I think the following is necessary:
    - Make sure that the hash is different each time files are created (Or maybe just add an cache busting version number)
    - Make an option for Hummingbird to clear assets cache each time a post have changed.

  • Predrag Dubajic

    Hi Kjetil,

    I was doing some additional tests but I'm afraid that I still can't replicate the issue, I tried with changing the color of the paragraph and the changes were visible to me right away.

    Are you making changes by using the Elementor options like color picker etc. or you're using Pro version and use Custom CSS option?

    Could you grant us support access to your site, as Adam mentioned above, so we can check your settings so we can create a detailed report to our developers?

    Best regards,
    Predrag

  • Kjetil Wikestad

    Hi, have done some more testing and I can know pinpoint exactly what the problem is.

    I have also given you support access.

    On the page https://infotech.no/itbase the two buttons doesn't match up (se image).

    The css for this page is stored in the file post-792.css

    If this file is compressed in Hummingbird then the two buttons mismatch, but when is not then the css is correct.

    This happens because the filename of the compress css file does not change even though the file have changes so that users will be served the cached version of the file if they have visited the page before.

    Therefore, if you visit the page you will see matching buttons because you get served a fresh copy of the file. But try to change som css and the page will not be updated. Try to purge the assets optimization and page cache and still the page will not be updated.

  • Adam Czajczyk

    Hello Kjetil Wikestad

    Thank you for your response and this detailed explanation. I can see that currently those two buttons that do not match on a screenshot, they do match on the page. Since purging asset optimization and page cache didn't help, can you tell me please what did help?

    Also, I would like to take a closer look at your setup to make sure that when I'm testing that on my test sites I'm doing it the right way, using configuration as close to yours as possible. Unfortunately, the support access that you enabled doesn't seem to work and I'm getting "expired token" error. That happens sometimes and in such case usually revoking and re-granting access helps. Could you please do it for me and let me know here when done?

    I'll then access the site to review its configuration so I could try to replicate the issue on my end fully and look for solution.

    Best regards,
    Adam

  • Kjetil Wikestad

    Hi, and thank you for helping me.

    So the problem is not a problem with Hummingbird per se, because Hummingbird creates a compressed version of the css file and serves that. But the problem is how Hummingbirds interact with the browser and webserver. The webservers tells the browser to cache .css files and users that revisited the site will not download any .css files.

    If I tell Hummingbird not to touch the file then the file is served as post-792.css?ver=123456, where the version number will increment on each change, meaning that this looks like a new file for the browser. So each change will trigger a new request for the file.

    When Hummingbird minimize the file it creates a new file, but do not keep the ver parameter. If only Hummingbird would change the filename each time it was created, then this would not be a problem, but since the filename is exactly the same browsers doesn't know that they need to redownload the file.

    I have regranted support access.

  • Adam Czajczyk

    Hello Kjetil Wikestad

    Thank you for additional explanation and enabling access. I was finally able to see that and I believe you're right about the reason.

    However, that seems to be an Elementor-caused issue rather than HB cache. What I mean is that what Elementor does by letting you actually edit the style the way it does and by saving/generating style file is in fact what should be considered a "development work". Such work should never be done with caches enabled and in fact style files or template files should also never change on a production site.

    That is, if it comes to "good practices" but, unfortunately, it's more and more common that plugins and themes just ignore that. It's also understandable because it's all for "user convenience". But that also means that we actually need additional compatibility layer especially for that specific plugin.

    I did a little research into Elementor's docs and it seems we need to use special way to hook into it. It's not about the file names per-se but rather the way Elementor's saving data (with regular themes and standard way of creating posts, HB would actually clear/regenerate caches).

    That said, since I don't have full access to your site (on file level) I'd like to ask you to perform a quick test. Could you please download attached .zip file, extract it to your local drive and then upload the "elementor-hb-clear.php" file from inside the .zip file to the "/wp-content/mu-plugins" folder of your site install?

    Once it's done, do some tests with editing via Elementor and see if the issue is still there or not. I'm not 100% sure if the file I'm sending will work but if it either doesn't work or causes any additional issues, simply remove it from you server and everything will get back to current state.

    Let me also know if that worked or not and depending on that I'll either talk to developers on how to integrate that into Hummingbird or I'll look for yet another solution.

    Best regards,
    Adam

  • Kjetil Wikestad

    Hi Adam, and thanks for helping me.

    Your file that fix part of the problem. But the hash filename is still the same and would therefore not be refreshed.

    So I have poked around in the code and found that the Minify_Group class had an add_handler() function with an unused parameter called version. Did some more debuging and found that if I added the $registered_dependency->ver to the add_handler() calls in Minify::group_dependencies_by_attributes() then the site would refresh each time an edit in Elementor occurred.

    To me this seems to be the preferred behavior in Hummingbird. Files should be recreated and renamed if an resource version number gets incremented

  • Adam Czajczyk

    Hello Kjetil Wikestad

    My point was to actually not mess with how those files are handled but to clear all caches (including minification/Asset Optimization cache) which should then rebuild it with new files. There is, however, also a matter of browser caching that I missed so yeah, with those hashes not being changed the files - even if rebuilt - might indeed be served from either browser cache or server cache or CDN cache (depending on setup).

    Can you tell me please if you're now using both mine code and plugin tweaked by you or only the tweak that you added is enough?

    Also, could you please tell me what exactly (the file(s) and parts of the code) did you change and tow what? I'd like to give it some more tests and consult with Hummingbird lead developers so that would be extremely helpful.

    Best regards,
    Adam

  • Kjetil Wikestad

    Hi Adam.

    I recently updated to Hummingbird 1.9.0 and the changes that are needed is minor.

    class-module-minify.php:545
    $new_group->add_handle( $handle, $registered_dependency->src, $registered_dependency->ver );

    class-module-minify.php:555
    $groups[ $last_key ]->add_handle( $handle, $registered_dependen\
    cy->src, $registered_dependency->ver );

    I am using your code as well, but maybe it is not necessary? The page cache has an option called "Clear full cache when post/page is updated". Wouldn't this apply each time an Elementor page is saved? And also assets optimization, wouldn't detect if there is a new version and then update the assets?
    I have not tested these assumptions but is seems possible to me that your code is not needed at all.

  • Adam Czajczyk

    Hello Kjetil Wikestad

    Thank you for your response.

    I have tested this again and no, you actually don't need my code. After previous testing I was under impression that Elementor is actually not even triggering cache clearing. I was able to replicate that same issue again but it look like it was my mistake rather than the problem.

    Anyway, following your suggested code changes I run some more tests and I think you're completely right about that. Updating changes in Elementor seems to be working fine with Hummingbird but since the CSS file name is not changed - only the version - the hash (used as the name of the optimized file) is not changed as well so in fact it's not even that the optimized CSS is cached but it's not even recreated. For Hummingbird it simply looks like it was the same file, no need to do anything with it.

    This in fact makes sense because in a production environment CSS file should not change unless a development work is being done and if so - any caches and optimization should be disabled. Elementor and other builders are braking that rule unfortunately, as I already mentioned previously.

    The bottom line is: we can't avoid Elementor (and other builders) doing that so I agree with you that we need to adjust here. I've already sent you some points for such a great feedback and suggesting a working solution and I have reported all the details (along with proposed solution) to our developers so they could take care of this.

    I'm not able to give you an ETA on that, I'm afraid, but when you're updating the plugin please check the list of changes and once this is "rolled out" you should see it listed there.

    Kind regards,
    Adam

Thank NAME, for their help.

Let NAME know exactly why they deserved these points.

Gift a custom amount of points.