Paddy Landau

Thank you for your responses.

I hadn’t heard of UpdraftPlus. It looks interesting, worth a good look.

I discovered that I had the widget in two different places!

It’s all fixed now.

I feel a bit stupid!

• This reply was modified 5 years, 5 months ago by Paddy Landau.

Thank you for this idea, Tammie.

• I use Chrome.
• Trying Firefox instead, it worked.
• Using a new (empty) profile in Chrome, it worked.

The solution was to delete the cookies relating to my website, and then it worked.

Thank you again.

Hello Rodica,

Sorry, I’ve already uninstalled Hestia and installed a replacement.

No, I didn’t use a child theme; it was straight Hestia, without any editing to code or CSS or anything like that. I had tried uninstalling and reinstalling Hestia, but that didn’t work.

We’ll have to take this as one of those unknowns.

Regards

Paddy

Thanks for the reply, Jan. As the Apache redirects are identical, I was wondering if something in WordPress was redirecting, maybe a setting of which I am unaware?

• This reply was modified 6 years, 4 months ago by Paddy Landau.

@nintechnet Thank you for your reply.

After a lot of looking around and carefully reading your instructions, I decided to copy bf_conf.php from one of the working websites to all of those that don’t work.

This fixed the problem!

I have reset the Login Protection settings with new usernames and passwords for each of those websites, and everything works well now.

Looking over the usernames and passwords, I believe that I know what caused the problem.

On the sites that weren’t working, I had chosen a username with a space in it. I see that your system no longer accepts a space, but once upon a time it did, and so those usernames now caused a problem.

Thanks for your help!

• This reply was modified 6 years, 4 months ago by Paddy Landau. Reason: Mark as resolved

@gregross That is helpful, thank you.

All right, so what could I do about this? Is there a command that I could manually run (perhaps from the command line, which I could automate) that would “kick-start” the process?

Curiously, since yesterday, one of the sites has updated its GeoIP database. I don’t know why; I haven’t manually updated it. The others remain out-of-date.

I have PHP version 5.4.19.

@gregross, sorry for the long delay in replying.

The next due date was yesterday early afternoon. They were all due yesterday; an example was due Thursday 8 September 2016 @ 1:42 pm, and is still due for that time!

WP Cron Cleaner currently reports wp_statistics_geoip_hook due as Sep 10, 2016 @ 13:42:06 - Once Daily. Yesterday, it reported the 9th, and the day before, the 8th.

Neither my host (GoDaddy) nor PHP has logged any errors.

The interesting thing is that the other two databases (browscap and Piwik) both seem to work reliably and consistently.

I get the same results on my other sites (five of them): the GeoIP doesn’t download unless I do it manually, but the browscap and Piwik work well.

What else can I do to diagnose GeoIP’s download problems, please?

@gregross, thank you for your reply.

Unfortunately, the PHP logs are too old (my host clears them every 7 days). I have manually downloaded the update, which means that the next due download date is 4th August. I’ve added a note to my diary to check after then, and I’ll report back here.

In the meantime, which cron jobs should there be? The following ones are listed for WP Statistics.

wp_statistics_dbmaint_visitor_hook
wp_statistics_geoip_hook
wp_statistics_add_visit_hook
wp_statistics_browscap_hook
wp_statistics_referrerspam_hook

@techjase, I have just tried your link. It works on all of the following:

• Desktop (Chromium on Linux)
• Sony (Chrome on Android 5.1.1)
• Nexus (Chrome on Android 6.0.1)
• iPhone (Safari on iOS 9, I think)

I don’t know where the problem might lie on your side.

Regarding the OP, interestingly, I have discovered that the problem occurs only on the desktop; the mobile device (Chrome on Android) works properly.

Jérémy has found the problem and is working on a solution.

In the meantime, an effective workaround is to use the attribute xml=”no” for the affected images.

Thanks, Sean. Do you have any idea why that restriction is being put in place? (Buying an SSL certificate is a bit of a money-waste for me considering that it is a private, family-only website that will be password-protected.)