CoderJosh

The file /home3/leo/public_html/wp-content/themes/minamaze/admin/main/framework.php is either missing or its file permission don’t allow reading it. This could indicate that your files have been tampered with, you’d need to log in using FTP to get more information.

CryptoPHP is a backdoor used by attackers to gain unauthorized access to your site. It basically allows them to run arbitrary PHP code.

By itself, it doesn’t modify the WordPress database, but an attacker might well use it for that purpose, depending on their goal(s). It would therefor be best to thoroughly scan all your files as well as your database for malicious code and content before going online again.

@pimpwise: As you’ve got plenty of RAM, you could look into moving the directory where MySQL stores its temporary tables to a “tmpfs” volume. This can make a big difference, as writing the temporary tables won’t hit the disk anymore.

Judging from your post, you should probably start with WordPress.com. Once you have a better understanding and need something that cannot be done with WordPress.com, you can consider to run a self-hosted version of WordPress, which would be www.ads-software.com.

So, in a nutshell: WordPress.com is a service providing WordPress sites to its users. www.ads-software.com is a software that you can download and install on a web server or hosting account of your choice.

As you’re locked out and cannot access your WordPress dashboard, you need to access your site from outside somehow. This could be either cPanel or FTP, so if you don’t have this kind of access, you have to take care of this first.

Once you can use cPanel or FTP, go to public_html/wp-content/themes and rename your theme folder from “raindrops” to anything else. This will cause WordPress to fall back to its default theme and you should be able to access the dashboard again.

Note that suPHP is just used to call the PHP interpreter, so the module doesn’t need to be updated whenever PHP is updated. So the fact that it hasn’t been updated since two years doesn’t necessarily mean it’s insecure.

Depending on the Linux distribution your server uses, you might be able to find a package supported for your distribution. For example, there’s an EPEL package for RHEL/CentOS servers.

I don’t see any problem with the setup you have in mind, i.e. multiple WordPress Network installations on one server. Each site will have its own Apache vhost, and if these are set up properly, there won’t be any collisions.

That the error pages and favicon.ico cannot be found isn’t a critical problem, but the last line indicates that there’s a problem with your PHP script execution.

Apparently, you configured your .htaccess file for mod_suphp, but this isn’t being used (or not properly configured) on your server. So that’s really something your host should help you with.

Choose a “non-unlimited” host with reasonable limits. There’s no such thing as unlimited webhosting.

First of all, this doesn’t seem to be related to WordPress Network or WordPress Multisite, because you want your users to maintain their individual WordPress installations.

For security reasons, on a shared server it’s indeed a good idea to execute PHP programs with the permissions of the user owning that particular site, to isolate the various sites running on the server from each other.

There’s different ways to accomplish that. You’ve mentioned suexec and suPHP, the former being used for executing CGI scripts in general and the latter exclusively for PHP. Between these two, suPHP would be better suited for WordPress.

If performance is an issue and if you don’t have too many accounts on your server, you could also look into FCGI.

If you cannot reset your password from within WordPress, check out https://codex.www.ads-software.com/Resetting_Your_Password for other options.

Try to locate your web server’s error log (assuming that you’re using some kind of a control panel to manage your hosting account, you can most likely find it there), attempt to load the WordPress URL again and look at the most recent lines in your error log.

If you cannot make sense of these, post them here to get assistance. Without this kind of information, we cannot tell you what’s wrong with your particular installation.

Changes made in .htaccess files are in effect instantly.

As none of the rewrite rules seem to work, check your server configuration to see if rewrite rules are allowed in .htaccess files and double check the .htaccess file’s file permissions to be sure that the web server can read it.

Accessing https://testgallery.dualcoregroup.com/wp-includes/ms-files.php?file=2011/07/lae084143-m13x3.jpg works fine, so it’s definitely a rewrite problem.

As a test, change this line:

RewriteCond $1 \.(gif|jpg|ico|css|js)$ [NC,OR]

into something like:

RewriteCond $1 \.(gif|jpgxx|ico|css|js)$ [NC,OR]

and check accessing https://testgallery.dualcoregroup.com/files/2011/07/lae084143-m13x3.jpg again.

Assuming that you don’t have a phpMyAdmin plugin for WordPress installed and it’s the standalone version of phpMyAdmin that keeps interfering with your WordPress installation, you should check your rewrite rules.

I’d recommend that you move phpMyAdmin to an URI like /phpmyadmin and change the rewrite rules accordingly.

Try using https://www.smaltiaustralia.com/wpexample/wp-admin/install.php instead, this should work.