steveush
Forum Replies Created
-
Hi @kirstenosa,
That seems to be a different issue related specifically to the Justified template and paging which I can replicate. I’m looking into it at the moment.
Thanks
SteveHi @healthyuandi,
Could you please try clearing your browser cache on your phone. There was a change made in the latest version that if the old JavaScript is served along with the new HTML loading issues could occur. Android generally has a very aggressive caching policy and I just want to make 100% sure that this is not simply a caching problem before I begin digging deeper into the code.
I have tested your site using a Samsung S4, S5, S8 and S9 phone and the built-in browser and your page loads as expected along with all the images.
Thanks
SteveHi @healthyuandi,
I believe that is a different issue to the one started in this thread. Could you please open a new thread or add a comment to this https://wordpress.org/support/topic/1-7-4-images-dont-automatically-display-on-mobile/ thread and provide some more information. I’m looking for your make of phone and your Android and browser versions.
Thanks
SteveHi @jorge75,
Please can you try clearing your cache. We made some changes to the HTML structure of the items and currently your gallery is being output using the new HTML structure but your caching plugin is serving the old JavaScript and the two are having issues talking to each other.
@agustin26 and @kirstenosa please can you double check any caching plugins on your site as this is more than likely the issue on your sites as well but without a URL to check I cannot confirm.
Thanks
SteveHi @iguanamom,
Could you provide some more details please, like your type of phone and your Android and Chrome versions? Also a link to your site would help me out as I can’t reproduce the issue in testing.
Thanks
SteveHey @brandllama I’m going to resolve this as per your feedback from testing. Thanks for helping us resolve this.
Hi @kdcartoon,
Unfortunately this is as I suspected, your theme loads the HTML via Ajax but never does anything for the JS. On the page you linked above you can open the console and simply type
FooGallery.load()and the gallery will initialize and then be visible. I went through the theme code that actually loads the page looking for an event or a hook so I can simply call the above snippet whenever an Ajax load is performed but there is none that I can see. The theme outputs STARTED LOADING PAGE and ENDED LOADING PAGE in the console but it doesn’t provide any points for us to hook into. In short I can’t fix this without changing your themes main-min.js file as that is the source of the issue and is where the initialize code for all the built in plugins/features exists.If you are set on using the Ajax load feature then I’m afraid FooGallery will not be compatible with your theme as it stands at the moment. If you would like to use FooGallery in the future you will need to either disable the Ajax load feature causing the issue or contact your theme support and ask them to add in an event that is triggered whenever the ENDED LOADING PAGE message is. If they add in the event it’s simply a matter of listening for it and telling FooGallery to load. I would also like to point out that any other plugins not hard coded to work with your theme will also experience issues while you are using the Ajax load feature and I would recommend against using it at all.
Thanks
Hi @kdcartoon,
Unfortunately this is usually an issue with the theme and not FooGallery itself. Basically themes that provide the ajax load functionality generally only support a limited number of plugins as they hard code the supported plugins initialize code directly into the theme JS itself. So while the HTML for the gallery is loaded via ajax the JS for FooGallery is never run. An easy way to test this is to simply turn off the ajax loading feature of the theme. If FooGallery then loads correctly then it’s assets and/or initialize code is not being loaded correctly through the themes ajax load feature.
That said I tried to look at the issue on your site and could not actually find any galleries. I tried following your instructions but couldn’t find wallpapers under latest news and couldn’t find the short movies. Could you please provide me with some direct links I could look at.
Thanks
Hi @mnelson4,
I’ve taken a look at this and it is not something I think is possible. A solution could be cobbled together but it would not work 100% across all browsers or even 100% of the time in the same browser. The answer to this Stack Overflow question lists the reasons why but to summarize them:
1. Hooking into the onbeforeprint event and forcibly loading the images will not guarantee that they have actually loaded before the browser takes the snapshot to print. Images are loaded asynchronously so once the load is triggered the browser will immediately snapshot the page and print what is available without waiting for the images to finish.
2. You can’t stop/stall the print request from the browser. We do not have this kind of control over the browser when working with client side scripts other wise the web would be a lot more dangerous to navigate. There are ways to try and stall it but they all involve JavaScript that is not recommended as it basically hangs the browser to perform the stall.
I’ll add a story for this to our backlog that we can keep checking in on in the future but at present I don’t believe a viable option that could be added into the core code exists. All solutions I have seen require custom Print buttons within the page which kind of defeats the whole point as most people will use the browsers print feature.
Thanks
Hi @redkite,
I’m glad you found a replacement that works. I would like to say that as it is now with FooGallery lazy loading on, the gallery is loading the correct size images from the srcset. It is the same images that were being loaded by BJ Lazy Load when you said they were sharp so I’m not sure what to say about the blurriness. As it stands FooGallery seems to be working as expected and to me using Chrome the thumbs do not look blurry.
I’ll mark this as resolved as you have found a solution and the behavior from FooGallery is the expected one now.
Thanks
Hi @redkite,
I see you disabled our lazy loading and kept the BJ Lazy Load plugin enabled. Could you please try the following as it looks like there are still conflicts between it and FooGallery:
1. Re-enable the FooGallery lazy loading.
2. Navigate to the BJ Lazy Load settings and in the option called Skip images with classes please enter fg-imageThis should let FooGallery do it’s thing while the BJ Lazy Load plugin ignores its’ markup, hopefully resolving the issue.
If the above does not work could you please try disable BJ Lazy Load and confirming if the issue is still present?
Thanks
Hi @brandllama,
I’ve spent the day figuring this one out and I believe I have a working solution. As I suspected the violations are not the issue, they are actually a known “bug” with jQuery, the link to the open issue can be found here on GitHub. I will be looking into some of the suggestions to work around the issue but performance wise there should be minimal impact on your site. Especially after my fix is applied.
Onto the actual issue, it is being caused by the number of galleries on your page along with an integration issue between FooGallery and FooBox. The actual issue is FooBox is being reinitialized many, many times, slowing down the page. By many, many times, I mean it is reinitializing 49 x 49 times. The reason for this is that after each FooGallery is initialized for the first time it raises a post-load event on the document which is used to notify other plugins that something has changed in the page and to perform any required actions. Unfortunately in this case FooBox is listening for this event so it can reinitialize itself to pick up any new images.
In our test environments and on most of our users’ pages we only deal with a couple of galleries at once so this performance hit was not picked up in testing and you are the first to report it to us. That said I have made changes to FooGallery to better handle this scenario and it will now only reinitialize the single instance of FooBox that is bound to it. So far in testing, where I duplicated your page layout, it has resolved the problem and I hope to have the fix ready to deploy this week.
If you would like to help us test the fix please go to our sites support page and select Pre-Sales Question from the dropdown. For the Ticket Subject you can put something like Att: Steve so that it can be correctly assigned across to me and then we can take it from there.
Thanks
Steve- This reply was modified 7 years, 5 months ago by steveush. Reason: Added link to support page
Hi @brandllama,
Just dropping you a message to let you know I am looking into this and will get back to you once I figure out the issue. The scroll blocking violations would not be causing the long load time problem however there does seem to be an issue between the FooGallery and FooBox scripts with so many Image Viewer galleries being displayed on a single page.
I’ll update you once I know more.
Thanks
Hi @lenschith,
I’m following up with our PHP developer on this as theoretically both should be able to be enabled at the same time unless Jetpack is actively altering the output of our galleries. If Jetpack is altering the output of the galleries then we would have to try find a way to exclude them from the process which at present I’m not even sure is possible.
Thanks
Hi @jefferisp7,
I believe this is an issue with Jetpack’s Image CDN which I think you are using. The CDN does not allow images to be resized once uploaded, so the thumbnails which should be cropped to the size specified in the gallery options are never actually served to the page.
I’m following up with our PHP developer on this to see if there is something we can do from our side to alleviate this issue.
Thanks