zerobullhosting

Hi littlegreenpig,

It sounds like your host may have identified your site as compromised, and disabled plugins to mitigate the issue.

I hope you have a backup of the site files / database, or can recover one from the host, as that would be the easiest starting point. Here’s the steps we’d take here:

1. Change your passwords to any high level services like SSH/FTP/SQL/Panels/etc to ensure that the attacker does not have this level of access.
2. Recover from a backup that you know was functional, before the host disabled anything. Your host might have this if you don’t.
3. Once recovered, disable all plugins and change your administrative passwords. Ensure that there are no additional administrator users.
4. Install a security plugin that can scan for changes to the files, such as WordFence
5. Run the scan to ensure that the attacker did not insert backdoors within the plugins
6. Once the scan is complete and you’re sure you’ve cleared up anything left by the attacker, turn plugins back on one by one.

After you’ve completed this cleanup, ensure that the plugins are as up to date as possible. The majority of problems like this come from either weak passwords that can be brute-forced, or outdated plugins that have a known vulnerability attackers can exploit.

If you have any questions, just let me know!

It sounds like there may be a permissions issue with your temp directory (/tmp/). Check to ensure that the permissions there are set correctly.

If you’re on a host which doesn’t allow you access to the /tmp/ directory they’ve set – you can change your sites temp directory either through the settings in php.ini or through the wp-config.php like so:

define('WP_TEMP_DIR','/wp-tmp');

After you set it like that you’ll need to create that folder in your site root and assign it proper ownership/permissions as well.

If you have more questions, just let me know!

Hi landed,

First you’ll want to check what user/group apache is running as. It can differ based on your distribution. For example, in RHEL/CentOS you can edit this in /etc/httpd/conf/httpd.conf – there’s a user and group setting pretty early on in the configuration file. Lets say they’re both set to Apache.

For this, you’ll want to set Apache as the owner, and your SFTP user group as the group, then set folder permissions to 775 and file permissions to 664 (folders need execute permissions to display during browsing while files do not). Here’s our article on it for examples. If you don’t require a SFTP user/group due to it being localhost (likely with shared folders on a virtual machine), you can use 755 and 644.

To answer the original question, the reason it can’t upload to its own directory is because Apache is likely running as a user that is different than the one you’re using to upload files – so it doesn’t necessarily have permissions.

If you have any more questions, just let me know!

Hi dgrblr,

It’s hard to say what’s going on here based on just this info – it could be caused by errors introduced by a plugin, but it sounds like you may be having the issue on a fresh install.

I’d advise turning on debug mode, then attempting to change the order of the pages through the editor. This should help identify the issues source.

Hi Dave,

You’re right that there really isn’t much to go on in the error there. What I’d suggest will assume you have SSH access to the server:

1. Enable debug mode
2. Let the site run until the erorr appears, get the exact time it occurs if you can
3. Connect to the server with SSH, preferably immediately after the error
4. Use commands to search the error.log file, wherever your host keeps it. Usually it’s in /var/www/path-to-site-root/logs/

The commands you’ll be using for this may require a bit of previous linux experience, but it gets a lot simpler if you’re able to reproduce it yourself or SSH right after it happens. To get started you could use this:

cat error.log | grep “Wed Jul 27”

You can continue to filter by piping more grep commands on, like so:

cat error.log | grep “Wed Jul 27” | grep GET | grep 123

If you have any followup questions, just let me know!

Hi thvs2,

You may or may not have access to all of the relevant logs, depending on your hosting providers configuration. If you do, you’ll generally see a /logs/ folder that contains an error.log and an access.log, which are the main two you’ll be looking at when diagnosing issues in WordPress.

access.log will contain a listing of requests made to the site. This can help you determine what page an error is occurring on if a client is reporting an issue in vague terms. It’s also useful for determining use patterns, detecting attacks, and ensuring that a connection is being made to the proper server.

error.log will contain any errors that the application decides to write to it. By default this isn’t very much, and the best case is usually identifying the source of an issue, but if you enable debug mode (as tsure suggests) the log will contain a lot more information and should point you towards a solution with a little bit of reading and searching. Keep in mind that enabling debug mode will slow the performance of your site – and it’ll grow the error.log file very quickly. You should only keep debug mode on while you are actively testing, or the server you’re on could run out of space in short order.

Let me know if you have any more questions!