I have a problem with the mobile layout of our website when caching is enabled.
The problem occurs with WP-Rocket cache but also with SWIFT Performance-cache.
The guys from WP-Rocket tried to solve it – but told me that is a SiteOrigin Layout problem within the JS-code.
You can see the problem on our integration site: https://int.magped.com (only on the German version)
The second (ENDURO) and the forth pedal (ULTRA) are very tiny pictures.
Compare how it should look like with https://www.magped.com
The problem only occurs on mobile (iPhone X in Safari and Chrome) on a PageBuilder row which has “Collapse Order” = “Right on Top”.
As soon as the cache of WP-Rocket or SWIFT Performance is cleared the picture has the richt size again for about 20 to 60min then it turns small again…
I also tried to replace the SiteOrigin Image slider with “SmartSlider 3” –> same problem.
I think it is a problem with the layout builder in connection with time of the caching…
Thanks for your help
:: Paul
Hi Paul
Thanks for reaching out.
Please, see my iPhone 10, Chrome screenshot https://imgur.com/a/HFIqDoT. Am I looking at the correct part of the German page?
Please, create a test page on the site with the issue and insert a Smart Slider on its own, not in Page Builder. That’ll be a quick test to see if the issue is occurring outside of Page Builder.
Hi Andrew!
Thanks a lot for your response.
I did refresh the WP-Rocket cache on int.magped.com and since then the problem didn’t appear again.
If I do that on production http://www.magped.com the problem appears much faster –> within 10 to 30min.
I think the problem is also triggered by certain load on the website.
What I have done now on production: I deactivated WP-Rocket picture lazy loading on a page level.
Sind I did this yesterday the problem didn’t show up again.
The really strange thing is, that when I deactivate the WP-Rocket lazy loading globally – the problem still appears.
I need to further investigate on that with the WP-Rocket support.
–> I pretty sure that the problem is caused by the lazy-loading of pictures. After a certain time the high of the pictures isn’t calculated correct by the JavaScript code???
greetings
:: Paul
Hi Andrew!
Now it happened again on production http://www.magped.com on the English version of the website.
Even if the Lazy loading for pictures is disabled.
I will not rest the Cache until you saw the problem –> please let me know as soon as you saw it yourself,
then I will deactivate the whole caching for mobile phones again…
greetings
:: Paul
I’m really sorry Andrew!
Now it’s gone again on production, because the cache refreshed it self after 1h.
I changeant the auto cache refreshing to “off” now and will inform you
as soon as the problem appears again in production environment.
greetings
:: Paul
Hi Andrew!
Now it appears on the Italian version of the website.
Please see the screenshot here:
https://1drv.ms/u/s!At48GCH6HFrwkc5ORuvhZi1uQFih6Q?e=ab3M4P
I will also do not touch the cache, so that you can load it on mobile Chrome yourself.
Please let me know as soon as you saw it on your mobile phone browser,
so that I can disable the caching for mobile version again.
many thanks
:: Paul
Thanks, I can see the issue.
Lazy Loading appears to still be active on the IT site. I can see the issue in Chrome on my laptop when resizing the browser.
To confirm the issue I recommend temporarily deactivating all plugins except for:
* Those plugins authored by SiteOrigin.
* Language plugin necessary to load the IT site.
* WP Rocket.
Does the issue persist with only those plugins activated?
If the issue persists with the above setup, please, deactivate WP Rocket completely after clearing any caches. I’ll send you the paths to exclude so that the slider resources hopefully aren’t impacted by WP Rocket.
Hi Andrew!
I can not deactivate all the plugin’s because it’s a production environment.
It also happened on our integration (int.magped.com) but only in a very rare case…
It happens much more frequently in a much shorter period of time in proaction.
I think it load related…
What I already tested:
1) deactivate the WP-Rocket mobile cache –> the problem does not appear.
2) deactivate the whole WP-Rocket plugin –> the problem does not appear.
3) Using “SWIFT Performance” instead of “WP-Rocker” –> the problem appears
4) deactivating all WP-Rocket optimizations: Lazy loading for images, Minify HTML, Minify/combine CSS, Minify/combine CSS, Minify/combine CSS –> the problem appears
5) replacing the “SiteOrigin Slider” with “SmartSlider 3” –> the problem appears
The problem only appears on PageBuilder rows where “Collapse order” is “Right on Top”
I had a lot off support session with WP-Rocket but they where not able to fix it.
As it also appears with another coaching plugin: “SWICFT Performance” they told me it could not be a WP-Rocket issue.
Hope you can help me…
:: Paul
Hi Paul
Thanks for the update.
Plugin conflict tests on live sites
It is possible to do a plugin conflict test on a production environment using a maintenance mode plugin. I understand if you don’t want to do it but it’s possible. The test only takes a few minutes. A shorter version happens when you update your plugins, WordPress puts your site into maintenance mode while plugin updates are run.
Excluding the slider files/assets
Is WP Rocket able to exclude files from the mobile cache? The options as I currently see them are:
* Disable mobile caching completely.
* Exclude the home page from mobile caching, assuming that’s possible.
* Try excluding slider files from mobile caching if that’s possible (I asked about deactivating WP Rocket in my previous reply so I could provide you with those paths).
* Change the design to use left on top for mobile.
Testing
If you send us a copy of WP Rocket to [email protected] we can confirm the issue on one of our demo sites.
Hi Andrew!
I implemented a workaround.
I bought the SiteOrigin Premium Widgets, which offer now to toggle the visibility of PageBuilder rows
depending on the device (mobile, tablet, desktop).
—> I have removed the collapse behaviour „right on top“ from the rows and implemented a separate copy of
the row which is already collapsed and only visible on mobile and tablet.
the original row is only visible on desktop.
For now it looks good and the problem didn’t appears again…
cheers
:: Paul
Hi Paul, thanks for your support, it’s most appreciated. That’s great news. I’m all for workarounds. I’m really glad you were able to work through this and find a method that resolved the issue.
For any questions moving forward, please, reach out to our premium helpdesk via email on [email protected]. Thanks.