Nate

A big thank you to both @awelzel and @generalnumpty, I have solved my issue. I realize this is originally @generalnumpty’s thread with a little different issue, but I will post what I THINK (not completely sure) did it for me.

I was using emojis on my gallery page, but back when I pasted them in my text via Gutenberg editor, I forgot to enable emojis on caching plugin Swift. I enabled emojis sometime after the fact, and no issues I noticed either way, so I wasn’t suspicious about it. Note that the emojis were also placed near the galleries such that the image swiping area overlaps with the emojis. I deactivated Swift plugin a few times and opted to keep its settings and such stored. Photoswipe issue was fixed while Swift plugin was deactivated, but came back when activated. Well, recently I deactivated Swift but this time completely wiped all Swift settings and DB during deactivation, and then reactivated and ran the auto config once again (should have tried this much earlier I guess). This time, Swift must have detected the emojis in a different way than before, because now I was getting a wp-emoji-release.min.js showing up in GTMetrix, which I don’t believe I ever had before. And the Photoswipe issue never came back since, regardless of any other Swift/caching settings I played with.

@generalnumpty I haven’t seen your page, but thought I’d throw this statement out there just in case from the Photoswipe Performance Tips: “Make sure that you don’t have complex styles on UI over PhotoSwipe sliding area. For example, text-shadow on caption text can cause issues.” Not sure what kind of items you have over the swiping area. And I assume you checked mobile browser settings like Lite Mode/Data Saver, etc. Thank you for checking my page for me, you described the same as I was experiencing before the fix.
Best to you all,
Nate

@awelzel Thanks but actually I meant does the language in your plugin’s Advanced settings refer to any particular type of caching plugin? “Use WordPress cache instead of the database table _SDX_lightbox_photoswipe_img (use this option if you use caching plugins like “Redis Object Cache”)”?
I assume Swift counts.
I’m still going to play with things before abandoning Swift, but appreciate the tip!

The settings in Swift are a little peculiar; when caching is disabled, it also basically cancels a lot of other settings that appear to still be switched on (such as merging CSS, etc). So it’s been difficult trying to isolate what exactly it is.

@generalnumpty Sure: https://goseongguy.com/goseong-cafes/
The issue happens after a minute or two of opening and closing the galleries.
I can also try your page if you like to share.

BTW, perhaps we experienced this because of the setting under Caching->Warmup->Discover New Pages, which is only for Pro.
“Let the plugin to discover new pages for warmup (eg: pagination, plugin-created pages, etc)”

Thanks for the suggestion, I’ve saved it for future consideration.
As I continue checking that my setup is ideal, would you be able to explain more about the setting:
“Use WordPress cache instead of the database table _SDX_lightbox_photoswipe_img (use this option if you use caching plugins like “Redis Object Cache”)”?

Does this refer to a particular kind of WordPress cache plugin, or any WordPress cache plugin?
I don’t observe any difference when tested, but if intended to be for increased performance (reference cache instead of DB) then I’ll leave it ticked.

CDN URL Prefix:
Is it mandatory to add https, or more than just the CDN domain here? My images are served via Optimole, whose domain is mlrsd9l8mxvh.i.optimole.com. (The plugin optimizes the images on the fly, which are still in my wp-uploads directory but optimized and served via CDN on the fly).
But the actual images have a long prefix, and I’m not sure if it’s dynamically generated. For example, https://mlrsd9l8mxvh.i.optimole.com/udZe3-c.Lpwr~36747/w:auto/h:auto/q:90/https://goseongguy.com/wp-content/uploads/2020/12/BG9-700.jpg
In the field for this setting, I tried a few variations but not sure to know what is working, or what’s best practice. I tried typing https://mlrsd9l8mxvh.i.optimole.com/udZe3-c.Lpwr~36747/w:auto/h:auto/q:90/ and some other variations.

Many thanks again.

• This reply was modified 3 years, 10 months ago by Nate.

Hi @sdenis,

Were you able to replicate the issue?

I created a new Table of Contents block on another page that I haven’t translated yet. The block functions well (jumps to the correct heading when clicked) when I am on either the original page (domain/testingPage/) or the “translated” page, which I haven’t translated yet (domain/ko/testingPage/).
But as soon as I add a translation string for a few of the headings in the block, and leave the rest of the headings in the block in English, the functionality of the block is broken in the following ways:

MOBILE: Whole block broken on the “translated” (…/ko/…) page when a string in the block is translated. Even the headings that I left untranslated in English don’t work. But on the untranslated page, everything works (jumps to the headings when clicked).

DESKTOP: On the translated page, the headings that I left in English DO work (this is different than mobile). But translated headings do NOT work. On the untranslated page, everything works.

I tried not merging or deferring js scrips. I tried not merging CSS. I tried deactivating several plugins.

Any ideas? If you CANNOT replicate the issue, that would also be helpful for me to know it’s likely not something on my end.

Thanks!
Nate

I ended up using Wordfence Assistant Plugin, and it took care of the DB tables and wp-content/wflogs. Seems like things are okay…will mark as solved if nothing comes up in the next day or so.

I had this same problem. Since my site is still small, I added the URLs manually. It was very annoying though.

Thought I’d add an update to my previously stated situation (photos flick quickly at first, but after a minute or so of browsing the galleries, they require a deliberate slow drag):

When I deactivate my caching plugin, this problem is totally fixed. I’m using Swift Performance Lite for caching. I’m still trying to drill down to what exactly causes the conflict. I notice that Swift adds stuff to my .htaccess file, namely: CORS-enabled images, expires headers, mod_rewrites, and webfont access. When the plugin is deactivated of course, all of this is removed from my .htaccess.

[Skip this paragraph for the TL;DR] Another discovery is regarding Optimole, the plugin that optimizes my images on the fly. Deactivating Optimole was one of the first things I tried, and it had no effect on the issue. But Optimole has been causing 301 redirects on my background images only, which are not interacting with Lightbox at all. Optimole still optimizes the non-background images that Lightbox is working with as far as I know. But since there have never been 301 redirects on those non-background images (even before I found the Photoswipe-Lightbox plugin), and since deactivating Optimole doesn’t fix it, I assumed the issue is elsewhere. Here’s the point: when Swift’s caching is disabled (not deactivating the entire Swift plugin), then those 301 redirects go away. But to fix the slow drag issue, disabling caching is not enough, I need to deactivate the plugin.

(FYI I am using Cloudflare, but not for images. I don’t think CF is coming into play with this issue.)

TL;DR: This leads to think Optimole is not a problem but rather exposing an issue that seems to be caused by a conflict between Lightbox and Swift, or perhaps just Swift alone or the configuration Swift made. I’m determined to get to the bottom of this. I’m not experienced in .htaccess and mod_rewrite engines, but I’m researching a lot.

Hi Denis @sdenis,

My Table of Contents block is part of the Ultimate Addons for Gutenberg plugin. It’s a block in their library list. I’m using it with all the H2 headings on my page at https://goseongguy.com/goseong-cafes/ if you want to see it in context.

Thanks for checking,
Nate

Thanks for the replies guys. Arno’s galleries also work fine for me.
Even just listening and keeping it in mind for a solution that may all of a sudden come to mind later, being honest that we’re not sure ATM is good support in my book.
Cheers!
Nate

Hi @generalnumpty ,
Did you get any other conclusions on this? I have the same issue on a page with about 18 galleries (most are only 4 images each).
I also run Android 9 and it seems a little better on my wife’s Android 10 phone.
It seems to improve when I reduce the image size. For example, the galleries of 800x600px for example seem fine and flickable, whereas the galleries of 1200x900px require the slow drag. But these results were not 100% consistent. Also the 1200x900px galleries were farther down on the page.

One more observation: It seems like after a minute or two of browsing on the page, the flicks are becoming not possible and it requires me to slow drag. Not sure if it’s just something on my phone or my end. When I jump to a 1200×900 gallery right after opening the page, it’s fine, but even the 800×600 galleries are hard to swipe after some time of opening and closing images on the page.

Did you find which variables have the biggest effect or improvement to this for you?

Thanks,
Nate

• This reply was modified 3 years, 10 months ago by Nate.

Got it! Great, thanks!

Thanks @germankiwi for asking this, as I was about to attempt this myself. I also would love to these adjustments made.
And thank you @awelzel for your attention to these issues!
Looking forward to updates ??