Production site is fine, but the test site I copied from (in a subdomain) has stopped working

[Angstony_2]

I developed my site using a 'testing' subdomain of the production domain. When it came to deployment I followed @Traumflug's instructions here as best I could. I created a new database on the site with a different name, duplicated the original database, added the same user, and edited the settings.inc.php file. Then I copied everything from the testing subdomain's folder into the home folder (public_html), went to the back office and edited the URLs.

All of that went well: the production site worked straight away and everything is in order. However, when I go back to the test site now I'm getting this error:

The server encountered an internal error or misconfiguration and was unable to complete your request.

Please contact the server administrator at webmaster@testing.example.com to inform them of the time this error occurred, and the actions you performed just before this error.

More information about this error may be available in the server error log.

Additionally, a 500 Internal Server Error error was encountered while trying to use an ErrorDocument to handle the request.

I've tried to figure it out but I can't find any error logs anywhere on the site and none of my online searches have turned up anything useful or that I can understand. As I've mentioned before on these forums, I'm a complete novice with all of this, so I've probably done something stupid and/or things don't work the way I thought. Fingers crossed one of you experienced guys here will be able to point me in the right direction.

[wakabayashi]

More than a year ago, I did a migration video. In the first part I basically just make a test site. Maybe its helpful: https://www.youtube.com/watch?v=LN7KD9W_MY4

[Traumflug]

I’ve tried to figure it out but I can’t find any error logs anywhere on the site

There are at least three locations where errors get logged:

1. You server's (Apache's) log. On plain Debian/Ubuntu systems that's /var/log/apache2/error.log. On a web hosting it depends on where the hoster provides it. Usually right next to access logs, but I've seen hosting where it's simply turned off (ouch!).
2. thirty bees' log. In log/ in the root of each shop installation. In a properly working shop, nothing appears there. On errors, log files appear.
3. Using Firefox, hit F12 to open a developer console, choose the Network analysis tab, reload the page, and you see each request listed as it get sent and the answer comes in. There should be one with a violet 500 badge. Click on it and see what was requested and what the answer was. Even if you don't understand the voodoo provided there, you can at least see which request went wrong.

In some cases it helps to turn off debug mode. Code not PHP 7.2 safe can respond to Ajax requests not with JSON, but with an error message instead. Applies when running PHP 7.2, only.

[Angstony_2]

Thank you both for two very useful replies!

@wakabayashi, your video has given me confidence that I didn't do anything stupid, because AFAICT I took exactly the same steps, albeit in a slightly different order and copying from the sub to the main of course. I would try copying the live site back to the sub, but I'm really nervous of breaking the live site, so I've opened a ticket with my hosting company first as I'm beginning to think it could be something to do with their server settings rather than anything I've done.

@Traumflug I'd found the TB logs but the last entry in them was from over three weeks ago. Unfortunately, it looks like my hosting company has turned off error logging, as the /var/ folder appears to be empty! I'm annoyed about that as they came highly recommended by a friend whose company uses them.

Network analysis shows only two requests, both of which were met with 500 responses. The first shows the file as just \, whereas the second shows it as favicon.ico, which is weird, because there is a favicon in that folder.

Anyway, as I said to wakabayashi, I've put in a ticket with the hosting company so I'm hoping they can pinpoint the problem and I can stop tearing my hair out! :-)

[Traumflug]

I'd ask the hosting provider to turn the error log on.

I mean, it's understandable why hosters turn it off. One client of mine (client, because he wants to upgrade to thirty bees) runs PS 1.6.1.5 on PHP 7.0 and this combination produces no less than 140 MB of error logs every single day. Most hosting clients couldn't care less about error logs as long as their site appears to work. They only chime in if the error log gets big enough to eat away all available disk space.

A properly running site should be free of PHP errors in the logs, only listing those unavoidable intrusion trials (requests for wp_admin/ or whatever). Having the last error log entry from three weeks ago is a very good sign.

[Angstony_2]

@Traumflug Thanks, I will do that.

Well I've finally gotten the test site working again but I'm not sure how. The hosting company just said it was something to do with the .htaccess file causing a peculiar redirect to %{ENV:REWRITEBASE}img/c/$2.jpg which it evidently was. When I compared the htaccess file to the one in the home directory the only differences were the URL sub-domains (www ~ testing) and some 'protected directory' lines located underneath the TB rules. When I remmed out those lines it started working again, albeit without the password protection kicking in, of course. So I used cPanel to re-apply password protection to the testing folder and lo, it added the exact same lines back in! But it wasn't broken this time, so I guess cPanel must also be editing something else somewhere.