LordSilver

Hello,

I always make a backup before every update on my site, and the last one I could find with guid still not modified/removed is just before updating iThemes plugin and yours. The problem is that I noticed this thing 3 days after, while I’ve already made some changes to db, and since guid doesn’t seem to affect my site, I’d prefer to have an easy query I can run to regenerate the correct links. I basically need to replace any string (random chars or empty) with ‘https://www.domain.com/p=’ + ID. Unfortunately I couldn’t find how to do it in MySQL.

• This reply was modified 7 years, 7 months ago by LordSilver.

Well, that’s a big lie.

Updating from 4.2.3 to 4.2.4 breaks the “Prevent caching of objects after settings change” feature: so now every resource is followed by a query. Not to mention the others well known bugs like CloudFlare API not working and so on. How can they even state it’s compatible? Ridiculous.

Another thing I’ve recently discovered is that the “Cache Preload” feature doesn’t use any user-agent (they usually put “W3 Total Cache/0.9.X.X”) for fetching the pages on the web-site, thus it generates 500 errors in the access_log if you have rules for blocking that kind of requests, which happened to me having iTSec plugin installed for security.

Honestly I’m quite disappointed seeing how poorly supported is this plugin, which is just the most popular one for caching on WordPress.

Disabling iTSec, if I access https://mysite.com/wp.login.php, I’m correctly redirected to https://www.mysite.com/wp.login.php

What should I fix exactly?

Yes, sorry for the typo. It should be an hyphen, not a dot.

Anyway, you are wrong: https://mysite.com is correctly redirected, along with https://mysite.com/whatever.

When I disable the Hide Backend and then access:

https://mysite.com/wp-admin

I’m redirected to:

https://www.mysite.com/wp-login.php?redirect_to=…etc

But if I access:

https://mysite.com/wp.login.php

I’m not redirected, so I’m still on:

https://mysite.com/wp.login.php

Yes, that’s exactly my problem. The steps are:

– Type https://mysite.com/secretloginslug
– Insert my credentials and confirm
– It doesn’t accept your credentials, you are redirected to https://www.mysite.com/secretloginslug
– Insert my credentials and confirm again
– Logged

In the other case:

– Type https://www.mysite.com/secretloginslug
– Insert my credentials and confirm
– Logged

Up.

Up.

Up.

When will the plugin updated and all these bugs fixed?

Up.

My hosting managed to solve the problem after I told them about my discovery.

Thank you anyway dwinden for your support, I really appreciated it.

It doesn’t work either. Anyway, I noticed that all the emails were actually received, but they are in the wrong place (on my site main server, instead of the email dedicated server), that’s why I couldn’t see them. Is it maybe a DNS problem caused by some wrong MX records or something like that?

I find it really strange that I can receive emails on the right server if I send them using any email client. Just the backup function integrated in the plugin seems to be a problem.

Actually I already use [email protected] as my WordPress admin notification email and [email protected] as ITSec backup delivery address.