steveush

Hi @oscash,

The Justified template uses JavaScript to perform it’s layout and items are positioned absolutely within the gallery container. Unfortunately this means you can not change the layout through CSS alone.

If you use the developer tools and inspect one of the gallery items you’ll see that the JavaScript applies an inline style with the position, width and height properties to the div.fg-item elements. These act as the container for each item and position it within the gallery. Your custom CSS only targets the figure.fg-item-inner element, so essentially you’re setting the item inner and thumbnail to use only 50% of the item’s height and width without changing the item’s actual dimensions and position, hence the large gaps that appear.

To achieve what you are wanting would require JavaScript customizations that fall outside of our free support. Unfortunately I have not created this sort of customization in the past, otherwise I would simply forward it onto to you to use.

Thanks

Hi @dumel,

The issue here is basically the resolution of the phone is so large the JS & CSS detects it as being a desktop. On that device the resolution is 1080×2400. Unfortunately the free version does not have any way to alter the settings necessary to correct the issue.

I’ll make the changes but they will only become available with the next free release of the plugin.

Thanks

Hi @dumel, the default behavior on the phone should be the same as shown in your Chrome video. If it is not could you please let me know what device you’re testing on so I can replicate and see what’s going on?

Hi @aresa3,

I just want to clarify that this is not an error, it is merely a warning intended for developers, FooBox is still working as intended and your site will not be impacted performance wise at all by this.

This warning is displayed as we use jQuery under the hood in FooBox for the swipe functionality on mobile devices and the way they do event bindings prevents us from passing in the “passive” option. This is on our backlog to take a look at but as it causes no harm it is marked as low priority. You can see the discussion around this still open issue on jQuery’s GitHub repo which has been open since 2016.

This warning is there to advise developers that the event they are using, in this case, touchstart, may cause the native scrolling behavior of the browser to become jittery if that event handler is called while a user is actively scrolling the page. In our scenario the touchstart event is only triggered when the lightbox is open and a user is swiping on the active item, which means they are not scrolling the page and so the warning does not actually apply.

Thanks
Steve

@b3nb123 that’s great to hear! I’ll mark this as resolved.

FYI; The reason masonry layout got messed up is that the other lazy load plugin uses a blank 1×1 pixel transparent gif as a placeholder while FooGallery uses a blank SVG with the correct size for that specific thumbnail. Using placeholders with the correct size allows Masonry to correctly lay itself out ??

Hi @b3nb123 & @elviiso,

TDLR; Exclude FooGallery images from your third party lazy loading plugin using the CSS class skip-lazy or disable lazy loading in the FooGallery settings.

The issue here is actually a problem with multiple lazy loads occurring on the images. FooGallery is currently set to lazy load its’ own images, which it is doing, however there is another lazy load plugin altering our gallery markup which is causing the blank images to appear.

As the two lazy loads are essentially racing against each other sometimes the other one completes after FooGallery. This is when you see the blank images.

The reason the other lazy load plugin is producing blank images is because FooGallery with lazy load enabled outputs the thumbnail src as a blank placeholder directly from the server. The other plugin then replaces our placeholder with its own and then tries to load our placeholder as the actual image, resulting in the blank images if it completes after FooGallery.

I would try to configure the other lazy loading plugin to ignore FooGallerys’ images rather than disable its lazy loading. I know our lazy loading works for all our templates and combinations of options. If your other lazy load plugin has an exclude list you should hopefully be able to add the CSS class skip-lazy to it and it should ignore our images as they all have this class applied.

Thanks

Hi,

I just double checked myself and you are correct, the option to select a lightbox no longer seems to be available for the Responsive Album Layout however it does reappear for the All-In-One album. I’ll look into this and chat with our PHP developer to see how/why it has disappeared and get back to you.

Thanks
Steve

Hi,

It seems you added some custom CSS to the old galleries using your styles.css file. The custom CSS is below and can be found starting on line 396:

.fbx-link {
    width: 200px;
    height: 200px;
    position: relative;
    text-align: center;
}

.fbx-link img {
    max-width: 200px;
    max-height: 200px;
    position: absolute;
    margin: auto;
    top: 0;
    left: 0;
    right: 0;
    bottom: 0;
}

Unfortunately you used a FooBox CSS class, .fbx-link, to apply the custom style to your old galleries by having the lightbox option set to FooBox. Your new galleries do not have a lightbox attached to them and so the CSS is not being applied.

I see two ways to resolve this;

1. Set the lightbox on the new galleries to FooBox as well, or…
2. Change the custom CSS selector to target the items using FooGallery specific CSS classes. This means it will be applied regardless of the attached lightbox.

If you decide to try #2 above you could simply change .fbx-link in your custom CSS to instead be .foogallery-default > a. Your custom CSS would then become:

.foogallery-default > a {
    width: 200px;
    height: 200px;
    position: relative;
    text-align: center;
}

.foogallery-default > a > img {
    max-width: 200px;
    max-height: 200px;
    position: absolute;
    margin: auto;
    top: 0;
    left: 0;
    right: 0;
    bottom: 0;
}

Thanks
Steve

Hi,

I’ve taken a look at the supplied page and scrolled down to the second Conferences link to a YouTube video and taken a look. I don’t think this issue is due to FooBox. When FooBox decides to handle a link it will be decorated with the fbx-link CSS class. Its handler code will also show up under the developer tools Event Listeners tab when inspecting the elements click event. Neither of these are present in your page, FooBox is not trying to handle the YouTube link, and if you click it it still does not open at all which points to another piece of code causing the issue.

If this started happening after installing FooBox then it may still be caused by a conflict in code however all of FooBox’s code resides in a “namespace” as it were to avoid collisions so the likely hood of a conflict should be fairly low.

Thanks
Steve

Hi @gcsawebmaster,

You should be able to add the below CSS to remove the navigation elements.

.foogallery {
    --fg-carousel-navigation-size: 0;
}
.fg-carousel-prev,
.fg-carousel-next,
.fg-carousel-bottom {
    display: none!important;
}

Thanks
Steve

Hi @chrisinhouseartist,

Thanks for letting us know about this issue. It seems to be a problem with the Gallery Settings > Appearance > Loaded Effect option. Currently you have the value Fly selected. I think this value in combination with some of the other options you have enabled are causing this issue.

As a quick fix could you try selecting another value for this option and seeing if the layout issues are resolved?

I’ll need to dig in a bit to figure out a proper fix seeing as this is a Safari only issue and with the release of 15.4 they have made quite a few changes to the browser and introduced a number of odd bugs in the process.

Thanks
Steve

Hi @jamespond,

The core issue is that the gallery is set to perform lazy loading however something is stripping the required data- attributes off of the <img/> elements and setting the src directly. As the JS is expecting to lazy load the images and there is no data- attributes it instantly fails and displays the error icon.

A quick fix would be to simply disable lazy loading in FooGallery and then everything should work as expected. Lazy loading is currently not being performed anyway due to whatever is modifying the markup.

The longer fix would be trying to find what is modifying the markup and either disabling it or excluding FooGallery images from it.

Thanks
Steve

Awesome! Glad to hear it’s resolved, hopefully there is a Safari update soon to fix the root issue.

Thanks
Steve

Hi @rjmark,

Ok so this does seem to be an issue with Jetpacks Lazy Loading module. I found this GitHub issue here https://github.com/Automattic/jetpack/issues/23553 which describes your issue perfectly. The developers then referenced this issue further down https://github.com/Automattic/jetpack/issues/23583 and in that there is a workaround described.

This is conflicting with the Lazy Load module of Jetpack — disabling that from the Settings > Performance area of WordPress.com resolves it, though!

Transferring to the Jetpack repo for further investigation!

Hopefully this helps!

Thanks
Steve

Hi @rjmark,

I’ve made a bit more progress on this. It is not the ResizeObserver changes like I originally thought but rather Apples implementation of the loading="lazy" attribute for images and iframes.

Essentially the plugin is loading all the images and setting their src attributes, however if you check in the Developer Tools > Network tab you’ll see the browser is not actually performing the request. If I remove the loading="lazy" attribute from any of the blank <img/> elements it suddenly pops into view. You can also test this by going to your iOS Settings > Safari > Experimental WebKit Features and scrolling down in the list until you see Lazy image loading is enabled by default in 15.4. If you temporarily disable this and refresh your page, everything loads correctly.

Now obviously this is not a solution, but here in lies the tricky part. We’re not outputting this attribute in our gallery markup. If you view page source you can see the markup as it is received from the server and checking the <img/> elements within the gallery, you’ll see none have the loading="lazy" attribute. This was done as it was not fully supported and we have a JS implementation providing the lazy loading logic.

So currently I’m trying to find the bit of JavaScript in your page that is going along and adding this attribute to all the images. This is also probably why it is inconsistent with the hard refresh. Clearing the cache forces the script adding the attribute to be downloaded again and the time it takes to do this is all that is needed to correctly trigger the requests for the images. Without clearing the cache the script is in memory and so is being executed without the small delay of the download.

TDLR;

The issue is being caused by a 3rd party script adding loading="lazy" to all <img/> elements in the page in conjunction with the Image lazy loading feature of Safari being shipped enabled in 15.4.

I’ll continue looking for the script and update once I’ve found it but it is currently 1AM here so it may only be tomorrow.

Thanks
Steve