CoderJosh

FTP is used for updates instead of direct filesystem access when the file permissions don’t allow the update script to overwrite your current WordPress files.

So either Rackspace uses another mechanism than UK2 to execute PHP scripts (for example, mod_php instead of mod_suphp), or your file permissions are different.

If you have to (or want to) use FTP for the updates, you could store the FTP login credentials in wp-config.php so that you don’t have to enter them again and again. That’s not necessarily secure, however, depending on your server’s configuration.

phpMyAdmin would help you to debug database problems, but as I see it, that’s rather a rewriting issue:

Your rules in .htaccess rewrite certain URLs to index.php, but as you said, you don’t have this file up yet. Instead you currently have wp-index.php, so your rewrites should go there for now.

There might be other issues as well, but that’s what I’d try first.

Yes, that’s a rewriting issue, because the error message you’re seeing when you try to access the file you’ve mentioned comes from your web server (Apache), not from WordPress.

Can you show us your .htaccess file?

Did you create a new database for the test site or did you copy your existing database?

Also, have you checked that you can log in manually (using a tool like phpMyAdmin, for example) with the database login credentials configured in wp-config.php of the test site?

You should check your MySQL server configuration with a tool like mysqltuner.pl (https://mysqltuner.pl/) or tuning-primer.sh (https://forge.mysql.com/projects/project.php?id=44) to get an overview about your current configuration and some ideas for improvements.

The queries you’ve shown here aren’t complete, so besides the fact that MySQL has to create a temporary table to execute them, there’s not much I can say. Try to determine which script causes these queries first, then you can debug it.

As you’re having a heavy WordPress site with many plugins on a dedicated server, it would be well worth the effort to optimize your server and analyze what exactly causes those queries that are inefficient.

As a first step, benchmarking your site (or a copy of it) with the default theme and with all the plugins disabled should give you an idea of the difference your plugins and theme make, then you could enable them one by one and see how the performance is affected.

As a reply to my earlier post, you wrote that you’re already using the W3 Total Cache plugin, but then you mention the WP Super Cache plugin in your list of plugins. If you had used one of these plugins first and then switched to the other one, you might need to check if it’s working properly.

If your provider allows you to upload a theme of your choice or edit your theme’s files, in particular functions.php, you could indeed put some plugin functionality in your theme.

To check what a particular plugin does when it’s activated, you’d have to read its source code.

This permalink structure is fine, it shouldn’t cause any problems and you don’t need to change it.

To reduce the number of SQL queries, you could look into using a cache plugin like WP Super Cache or W3 Total Cache.

Check out the WP Exploit Scanner (https://www.ads-software.com/extend/plugins/exploit-scanner/) plugin, it comes with MD5 hashes for all the core files.

You could use these hashes along with a custom script on your server(s) that checks if the core files have been modified. It’s easy to implement that and it works like a charm!

WordPress runs fine on Linux servers. In fact, I’d daresay that most servers running WordPress installations are Linux servers.

If you’re in doubt about a particular webhosting provider, just ask them about WordPress before you sign up and check out WordPress’s list of requirements (https://www.ads-software.com/about/requirements/).

You should empty or delete your existing tables before re-importing the database.

Also, be careful when changing the blog URL in the database dumps, if you’re using a simple Search & Replace: In some places, the URL stored to the database is part of a “serialized” data structure, so just replacing it might break this data structure, if the length of your new URL doesn’t match the length of your old URL.

In this case, it’s quite likely that your local computer was compromised and your FTP login credentials were stolen.

You should make sure that your local computer is clean (malware scan) and change all your passwords for your hosting account(s), such as FTP passwords, database passwords and Control Panel passwords, before cleaning WordPress itself. Otherwise you might run into the same problem again.

So where’s the list of your sites?

That depends on what your web hosting company deleted. The user accounts are stored in the database, not in any file. If you can see your posts, the restored WordPress can access the database, and that’s a good thing.

As you mention your email address, I assume that you’ve tried the password reset already, and it didn’t work?! In this case, you should use phpMyAdmin to check the user account information in the database.

You’re having PHP memory limit (php.ini, memory_limit) of 32 MB and you need to increase this limit, try 64 MB.

See https://codex.www.ads-software.com/Editing_wp-config.php#Increasing_memory_allocated_to_PHP for more details.