Conflict with lazy-load feature of Perfmatters

Hey @rockyourblog! ??

It appears the issue is caused by temporary image links being used before they are fully loaded on the front end of your website. Once the images are loaded, these links are not replaced, so the lightbox doesn’t recognize the new content.

When dealing with async images, you should use the “renderMeowLightbox();” function. This function is exported to your DOM and can be called by anything at any time. As the name suggests, it will rerender the lightbox, and everything should work properly.

You can do this manually with a simple line of JavaScript, for example, through a code snippet. As you can see here:

Hey @valwa

thanks for your quick reply!

Unfortunately, that doesn’t really solve the problem because I can call “renderMeowLightbox();” as many times as I want. As long as there are still images in the DOM that were not yet in the viewport, they do not work in the lightbox because the “src=” of the images are pointing to the placeholder.

A workaround would be to display only the image in the lightbox that has been clicked on instead of all eligible images in the content. Because to click on an image it has to be in the viewport which means “src=” has been updated and I could call “renderMeowLightbox();” before.

Is it possible to set this in Meow Lightbox? So that only the image you clicked on is displayed and not all images at once in a slider?

I hope you understand what I mean. Thank you for your time! ??

Cheers
Philipp

• This reply was modified 6 months, 1 week ago by RockYourBlog.

Hey?@rockyourblog!???

It seems that the process of Perfmatters is to directly modify your DOM for every image it finds and use an SVG placeholder as long as it’s not in the viewport, marked with the “pmloaded” class. The lightbox content is generated ahead for optimization, so it’s already part of your DOM, then following a similar approach as regular images to create the lazy-load behavior, it’s unable to reload the original “data-src” back. Since this is a very specific use case and won’t be helpful for the vast majority of users, I believe the best approach would be for this plugin to perform a check and only execute this action when necessary or allow you to use an anti-selector (if not already available) to exclude certain classes (like the lightbox in this case).

On our end, we could add an option to force the use of “mwl_data” (a window-accessible variable containing lightbox information), but it would require rewriting the content after a certain amount of time or through observation, which isn’t optimal either.

If you have technical knowledge, you can use this variable to build the system yourself, but it’s more of a hacky way to ensure the correct output rather than anything else, I believe, creating some kind of plugin battle in your DOM!

Thank you for your understanding!