Loading as https causes problem

I note in page source that when loading the site in https the stylesheet link is http –

<link rel=’stylesheet’ id=’foogallery-core-css’ href=’https://carnethy.com/wp-content/plugins/foogallery/extensions/default-templates/shared/css/foogallery.min.css?x14836&ver=2.2.16&#8242; type=’text/css’ media=’all’ />

And when loading the http site the stylesheet link is https

<link rel=’stylesheet’ id=’foogallery-core-css’ href=’https://carnethy.com/wp-content/plugins/foogallery/extensions/default-templates/shared/css/foogallery.min.css?x14836&ver=2.2.16&#8242; type=’text/css’ media=’all’ />

But I don’t know what this might mean, if anything.

The post containing the gallery – https://carnethy.com/2022/10/manor-water-photos/

User reports that my ‘fix’ of adding .fg-justified {position: relative !important;} to the custom css of the gallery has fixed the problem but this is just a hack. I don’t want to go back through all the galleries adding this in. Nor do I want to add it to the overall settings as they are added as a stylesheet and not inserted into the page source.

Hi @digbymaass

Thanks for getting back to us.

First of all, I want to start by clarifying that loading the page as HTTP instead of HTTPS isn’t the cause of this issue. This is because, just by using the developer tools, I can see that the FooGallery scripts – both CSS sheet and JS script – have been properly loaded as HTTP.

Now looking at the gallery pages you’ve shared with me, the first one actually has one gallery created with FooGallery whose layout looks like it is properly displayed, while the other looks to have been created using either another gallery plugin or by an in-built gallery builder that came with the theme.

Also, for the fix you added, it shouldn’t have any effect since there’s a similar style in the FooGallery CSS sheets that sets the position of the gallery to “relative” by default. You can even use the Developer tools in your browser and you’ll see it rendered.

If possible, could you kindly create a test page with one or two galleries created using FooGallery that are exhibiting the issue you described so that we can be able to carry out further analysis before we can advise on this? Thanks in advance for doing so.

Kind regards,
Elvis.

I’m not sure what you mean about

Now looking at the gallery pages you’ve shared with me, the first one actually has one gallery created with FooGallery whose layout looks like it is properly displayed, while the other looks to have been created using either another gallery plugin or by an in-built gallery builder that came with the theme.

. I’ve shared a screenshot page and a link to the post containing the foogallery. Any other galleries you can see on the main news page are native WP galleries.

The post containing a foogallery – https://carnethy.com/2022/10/manor-water-photos/

As you can see from the screenshot page https://carnethy.com/screenshot/ foogallery loads the opposite as I said previously. All other plugins load stylesheets appropriate to http or https. As you say, the javascript loads the correct version for http or https.

The fix I added does have an effect as it is not loaded as a stylesheet but is inserted directly into the page source/

Only a very few browsers are displaying the fault so if yours aren’t, it makes it difficult to reproduce. However you can see the screenshot of our user’s browser where you can see the gallery floating to the top left.
His user details:
> > Firefox 103.0.2 (64-bit)
> > arch linux 5.19.2-arch1-1
Another user with the same issue uses chrome, but I have no further details.

Hi @digbymaass

First, to clarify what I meant by the part of the message you highlighted, when I loaded the page you shared with us (https://carnethy.com/) I saw a number of Galleries, and only one of them (this one: https://prnt.sc/QNrbiuhoAZWo) was created using FooGallery. Thanks for clarifying that the rest were created using the native WordPress gallery builder.

Secondly, thanks for the extra info about the browser and OS you are using. On my end, I have tested the same page you’ve shared (https://carnethy.com/2022/10/manor-water-photos/) on the latest versions of Chrome, Firefox, and Safari on both Windows 11 and MacOs Ventura, and here are some screenshots to show you the results:

Windows Chrome: https://prnt.sc/uXH2j-AjfQsa
Mac Chome: https://prnt.sc/NKbXchHuz8nI

Windows Firefox: https://prnt.sc/YVOmSqh4KMDp
Mac Firefox: https://prnt.sc/HWClz8VRUotg

Safari: https://prnt.sc/BrL-IWDCrt1U

As you can see from the screenshots shared above, the galleries are loaded perfectly and do not look like the one in the screenshot you shared with us (https://carnethy.com/screenshot/)

From this, I believe the issue may be happening because of the platform you are using. Just to confirm this, could you kindly test this on a Windows,Mac or even a mobile device to see if you’ll still make the saame observations as before? Thanks in advance for doing so.

Kindly let me know what yoor observations will be.

Kind regards,
Elvis.

• This reply was modified 2 years, 4 months ago by elviiso.

I see that all your examples were loaded as http. Since the problem happens when loading as https it’s not surprising that all of them loaded fine. However even if you had used https my fix would have ensured they loaded fine.

I’ve added a gallery without my fix to the screengrab page. Load it as https screenshot page and see if the gallery misbehaves. Something I should have thought of sooner!

For the first time my own firefox (78.15.0esr (64-bit) mac OS El Captitan) is displaying the error. Loading as https the gallery is floating top left. Loading as http it’s fine.

I’ve had reports from 2 users as I said before.

> > Firefox 103.0.2 (64-bit)
> > arch linux 5.19.2-arch1-1
Another user with the same issue uses chrome, but I have no further details.

I’ve asked the second user for more details but no reply so far.

Both users reported that changing back to http solved the issue (prior to my fix solving it for https).

Have anoher look at the screenshot page and see how foogallery is loading the stylesheet opposite to the http/https request (screengrabs of page source).

I see from the support forum that others have a similar issue. Could they be related?

I see my chrome – Version 103.0.5060.134 (Official Build) (x86_64) OS X 10.11. is now showing the error too. Perhaps caches have cleared.