saturnusdj

Yesterday I reinstalled the site from scratch. Beforehand I did configuration by opening it on the ip address because the domain name was not transferred yet. This time I opened and configured it on the domain name plus HTTPS. Not sure if that was the problem of course but it could make sense. Technically the issue in this topic is not fixed, but worked around, thus the “resolved” status being nonrepresentative, despite also being unsure if this has todo with FooGallery. It works now, hope it stays like that.

Yeah same. It probably depends on if the cache cycle (every 30 minutes) is a bad one. Plus after every site update there is a chance.

Looks like starting from scratch is the only way to go then.

After not running a caching plugin for a while, I tried a different caching plugin today: W3 Total Cache. It is quite aggressive in caching. After a while the galleries are broken all the time, on refreshes too. Maybe this helps to debug?

Could it be that the “The authorization header is missing.” in site health is related? Having tried a lot of the tips online, I could never get that one solved.

@bradvin
What does head mean in this context?

Yet only the FooGallery CSS has the problem of not appearing. So not certain yet if it is not the problem.

Thanks.

Maybe the issue does appear less, I am seeing it less, but it did happen. Maybe there have been visitors a short while before your visit that triggered the file to be loaded/cached, as described in the topic start. Sorry, this issue is very strange to debug.

The ‘SSL Insecure Content Fixer’ plugin is now installed and active at the highest level, ‘Capture All’. At the lower levels I got the issue happening very quickly.

The Bitnami topic is at https://community.bitnami.com/t/certificate-and-bncert-tool-problems/97420

Sadly the issue remains.

@steveush

Thanks!

That makes sense, however where would the HTTP+IP (that you mentioned earlier) be called from? The IP address is not in the WordPress database anymore according to phpMyAdmin. On the file system level it was found in:

Binary file /opt/bitnami/mysql/data/ib_logfile0
Binary file /opt/bitnami/mysql/data/binlog.000013
Binary file /opt/bitnami/mysql/data/undo_002
Binary file /opt/bitnami/mysql/data/binlog.000010
Binary file /opt/bitnami/mysql/data/ib_logfile1
Binary file /opt/bitnami/mysql/data/bitnami_wordpress/wp_postmeta.ibd
Binary file /opt/bitnami/mysql/data/#ib_16384_1.dblwr
Binary file /opt/bitnami/mysql/data/binlog.000012
Binary file /opt/bitnami/mysql/data/#ib_16384_0.dblwr
Binary file /opt/bitnami/mysql/data/binlog.000009
Binary file /opt/bitnami/mysql/data/undo_001
/opt/bitnami/apache2/logs/error_log
/opt/bitnami/apache2/logs/access_log:

So not even in files like wp-config. I do not know why it is found in the wp_postmeta file. Maybe MySQL keeps old data in the file that is not used in the database.

Concerning the Apache logs, it seems (hack/crawl) bots try to access parts of the site via the ip address. And the WordPress wp-cron task opens things via the ip too. Not sure how that works. I followed https://thewp.pro/tutorials/wp-cron/ to get rid of it.

In any way…I do not understand what could make it so that resources for visitors would be loaded over the ip address and/or non-https. The network interface does not even have the public ip address assigned to it.

I removed some apache mod_pagespeed stuff just now, let’s see if that does any good.

@steveush

Thanks. Glad to hear that it happened.
Which browser are you using?

The mixed content error happened a lot a while ago. I think because the domain name was linked to the ip after setup of WordPress etc. Therefore I replaced all occurrences of the ip address in the database (via WP phpMyAdmin) and WordPress settings with the domain name, including https where needed. After that I never saw the mixed content error again, in Firefox.

As mentioned in the topic start Force HTTPS was enabled. After reinstall it was not enabled, but I enabled it again now. It did not help.

In Microsoft Edge Console, I now found this:
Item foogallery.min.css:1. Error: Failed to load resource: net::ERR_CERT_COMMON_NAME_INVALID. However the suggested solutions for that do not make sense. I am opening a topic on the Bitnami forum, see if they have an idea as at this point I am not sure if it is a FooGallery problem, despite this only happening with FooGallery.

Another update.
When I give .all-header opacity 0.5, the following becomes visible:

https://i.ibb.co/CnjNJkN/Screenshot-2021-07-12-Marcus-Pasveer-Content-creator-for-agribusinesses.png

Galleries 1-4 are placed underneath the header, covering each other. Top to bottom: 4,3,2,1.

I tried another theme, same thing. A visitor reported this problem.

• This reply was modified 3 years, 4 months ago by saturnusdj.

(Sorry editing the last post is time limited.)

That also did not work. This is really not good and I have no clue anymore what to try. If you know how to do debugging, please let me know.

I tried the pages. Both test pages came up fine, but the frontpage/home had the problem again…

I removed the page (home) and made a new one with same content. ‘New’ home. Let’s see.

• This reply was modified 3 years, 4 months ago by saturnusdj.

Hey @elviiso ,

The ‘good news’ though is that the site barely has visitors at this moment.
I tried a full reinstall of the plugin, including Foobox as well. The problem still occurred.

So, I made marcuspasveer.com/test-new/ with different galleries, but same media as the homepage and marcuspasveer.com/test-old/ that uses the exact same galleries as on the home page.

Thanks!

In another try I found that foogallery.css was present while the problem happened.

Hey @elviiso,

Thanks.
I tried Firefox, Firefox private window, Microsoft Edge, iPhone Safari, iPad Safari and seen it happening on all of them. However as noted it seems like for ~30 minutes there have to be no visitors for it to occur.

Remember your post @ https://www.ads-software.com/support/topic/force-column-amount-from-6-to-3-2-1-skipping-4-and-5/#post-14613844? I think that’s when it happened to you too.