Installing plugins in a duplicate folder (from wordpress)

You mustn’t publish passwords to anything to the public. If you included your actual DB password in your last post, you need to change it. There is little risk right now as long as public access is not yet working, but your plan is to get it working. Then the current password becomes a security risk.

Port 0 looks suspicious. However, it is a valid port, but I’m unaware of anything using it. The default for PHP mysqli functions is 3306. The user in the error message does not match the actual user name, but that could just be a parsing error. Your WP site at 192.168.1.234/projectionpictures/ is working correctly, yes? The error message indicates a configuration problem, but if WP is working, the srdb tool should also work, it works off the credentials in wp-config.php. The only time I have seen it fail until now is on a server with aggressive modSecurity rules.

You could try one of the plugins mentioned in #11 of Moving WordPress.

No, don’t change the home and site URL options. The current settings will eventually be correct. I didn’t phrase my question correctly. More accurately:
Back when the settings were set to http://192.168.1.234/projectionpictures/, the WP site there was working correctly, yes? My intent was just to narrow down what the possible cause for the srdb tool failing to work might be.

I really doubt Synology would have modSecurity running by default on Web Station. It’s primarily used by commercial hosts. But in fact, I don’t really know. Again, I didn’t phrase my statement very well. I should have just said “I can’t think of any reason the srdb tool would fail to work if the DB connection is working properly for WordPress.”

What is the site title of each WP installation? Both the one at /www/ and the one at /www/projectionpictures/? The value of option name “blogname” in the options table if you need to double check through phpMyAdmin. I don’t think the virtual hosts configuration is working correctly. I think domain requests are landing at /www/ and not /www/projectionpictures/ as expected. But it’s hard to tell with the various errors happening. The only useful clue I can see is the “Back to {$blogname}” link on wp-login.php.

At least it now looks like the DNS records are sorted. A bit of progress. Are you currently able to manage server files and folders? Once we’re sure virtual host is working, the next debugging step involves renaming and copying folders. As long as the site and home URL settings are set for the domain name, finding and replacing other URLs in the DB are of minor importance.

OK, cool. We’re landing in the right place and now need to resolve why the home page is going 500.

Thank you very much for offering privileged access. It would indeed make finding a resolution much easier. Unfortunately, I must decline. It is against the guidelines of these forums to let anyone gain privileged access to member’s sites or related accounts. Doing so carries greater liability and risk than most people realize. This “debugging by proxy” we need to do is certainly more difficult and carries with it its own set of problems, but it is the way it needs to be. Thank you for being so patient with all of this.

The following is all relative to the /www/projectionpictures/wp-content/ path.
First rename /plugins/ (/plugins.orig/ for example). This will disable all plugins. To restore plugins later on, restore the original name, then log into the back end and activate each plugin you want active.

Next, rename /themes/ in a similar manner. Create a new /themes/ folder. Be sure permissions are correct, usually 755. Copy (not move) one of the default twenty* theme folders along with all of its files and sub-folders from the renamed /themes/ to the new one. This forces WP to use the default theme. To restore your normal theme later on, delete the new /themes/ folder we just created, restore the original folder’s proper name, then log into the back end and switch to your normal theme.

This should resolve the 500 and let your home page display. It will not look right due to the theme change and anything dependent on a plugin will not work. But crucially, we have removed the cause of the 500 error. If by chance the 500 remains after these changes, we will need to follow a different debug course.

Assuming the 500 error is gone, we now zero in on the cause. First restore your normal theme as mentioned above. Check the home page loads correctly by doing a hard refresh in your browser after the page first loads. On PCs press Ctrl-5 to do this. Google how to do this for your specific browser if using a Mac. Next, start activating your plugins, one at a time, checking for a home page 500 error after each.

Sooner or later, the 500 error will recur. The last module you activated is the cause. Get with the responsible developer for resolution, or find an alternative.

For me, using Chrome, the www variant is working for both the .co.uk and .com domains. The non-www variant returns the web station page. Same using Firefox. This is for accessing the home page since I cannot access /wp-admin/. If you are only getting the page cannot be displayed error in IE when accessing /wp-admin/ but the home page works OK, it’s not a concern unless you or others require /wp-admin/ access through IE. If you normally use Opera and can access /wp-admin/ that way, it’s not worth worrying about IE.

Copying one of the default twenty* themes was a debugging step to eliminate your theme as a possible source of the 500 error. Since renaming /plugins/ resolved the 500 error, that step is no longer necessary. You may now delete the new /themes/ folder and restore the original folder’s name. Double check that your theme is in both the original and new /themes/ folder before deleting the new one. Restoring /plugins/ is fine, but do not activate any plugins if you don’t really need any.

755 permission is a Linux shortcut term. Since your permissions interface is different, it would be meaningless to you. Since WP is now working and you will be restoring the original folders, this aspect of the problem is moot.

“Log into the back end” is a common phrase of art among WP users for logging in through wp-login.php and using the admin area at http://www.projectionpictures.com/wp-admin/. Others call it the “back office”. (For some reason I really dislike that particular term.) Conversely, the public facing side of WP, your web site itself, is commonly referred to as the “front end”. But never “front office” 🙂

It has been slow and tedious, but we’ve been making progress. The remaining issue is the non-www variant of your domains returning the web station page instead of your home page. This sounds like a virtual hosts issue to me, but according to your last post, the DNS records still need corrections. Let’s deal with DNS first. Maybe I’m wrong about virtual hosts and correcting DNS will resolve the web station page problem.

Please remove these A records:
A projectionpictures.com 89.242.86.242
A http://www.projectionpictures.com 89.242.86.242

All you need are these:
A @ 89.242.86.242
A www 89.242.86.242

The @ record is shorthand for “projectionpictures.com” or whatever domain the DNS record is for. You don’t need a separate record for projectionpictures.com. And “http://whatever” never should be in any A record.