johnny2r

This was a pretty stupid one in the end. I took another look at wp-config.php and noticed that the commands to define WP_DEBUG etc. were at the end of the file, after the ‘/* That’s all, stop editing! Happy publishing. */’ line and the code below that, so WordPress was loading before the lines were reached.

As mentioned in the previous post, there is no hosting company involved. This is a VPS I am in control of.

As mentioned in the original post, the debug.log is not showing, for reasons unknown to me. This is on a VPS I have complete control over (root access).

Apologies for the belated reply. I have, I think, followed this guide closely, and used WordFence to clean the site. Unfortunately the problems keep coming back. WordFence successfully deals with the damage caused by the malware – the files which shouldn’t be there and the changes to existing files. But it doesn’t seem to root out whatever it is which causes these files to reappear (or rather, new variants, it’s not usually exactly the same files). What am I missing? What malware can be left over after a WordFence scan and subsequent amendments?

If it’s significant, we have a live site and a staging site and on the live site the plugin version is 5.2.0.7 and all seems to be OK. The problem only exists on the staging site (otherwise identical) where the plugin was updated to 5.2.1.02.

LATER: Having reverted to 5.2.0.7, the problem has gone away. So there may be some new issue there.

• This reply was modified 2 years ago by johnny2r.

Solved with help from ServMask. The answer is given here: https://help.servmask.com/knowledgebase/too-many-redirects-on-plugin-deactivation/

Thanks, figured it out (I edited my post).

OK, thanks, that’s clearer. I don’t think I’m doing it quite right, though. I used this:

wp search-replace –all-tables –precise --allow-root "https://www” "https://staging”

and got a message saying Couldn’t find any tables matching: https://www” https://staging. So could you perhaps help me by giving an exact command to replace all instances of https://www.mysite.com with staging.mysite.com? I assume this applies only to the database?

LATER: It’s OK, thanks, I’ve done it: wp search-replace 'www.mysite.com' 'staging.mysite.com' --precise --recurse-objects --all-tables --allow-root

• This reply was modified 2 years ago by johnny2r.

What do you mean by ‘exactly the same length’? What length are you talking about? My understanding is that using wp search-replace –all-tables –precise as you say will have exactly the same effect as doing it directly on the mysqldump file. Is this not the case? I’ll give it a go nonetheless.

The answer to this, the key difference between the two systems, turned out to be to do with the use of the nginx reverse proxy. There were some extra settings required in ‘wp-config.php’, as delineated here: https://blog.ldev.app/running-wordpress-behind-ssl-and-nginx-reverse-proxy/. I haven’t looked into why these were required for my migrated site but not for the original, which is also sitting behind a nginx reverse proxy, but it may well be to do with the fact that in the original, the WP site is on a different host, accessed via https whereas in the copy it’s under the same host, accessed via http on port 8040. I imagine that the issue is possibly to do with http -> https redirection.

Thanks, but sadly this didn’t help (unless I’m not doing it right). I didn’t expect it to, though, because what the proxy is doing is not redirecting so much as rewriting. It is passing on the https://staging.mysite.com/ as the Host header, so as far as the virtual host is concerned, it is has no knowledge that it is not the receiving server – the proxying is invisible to it.

I have got to the bottom of this now. It was nothing to do with WordPress as such, but to do with an incorrectly figured virtual host preventing mod_rewrite from working, combined with the fact that the headers module was not loaded.

Apart from not working with WordPress, I don’t usually work with Apache either, pretty well always using nginx instead, so this has been a bit of a learning curve for me. Thanks for the help, all.

All modules were already installed, in fact.

Yes, I manage the server myself. I’ll install these modules and report back. Thanks!

Given that I have a complete backup of the entire directory for the WordPress site, wouldn’t these modules already be installed? I mean, I can’t imagine I need a lot of modules for this site to work on Server B which aren’t present in the working installation on Server A? The entirety of a WordPress installation is within the site directory, is it not? That is, everything WordPress related for this site will be in the directory /var/www/mydomain.

• This reply was modified 2 years, 3 months ago by johnny2r.