A few versions ago WordPress added two incredible features, a WordPress Automatic Upgrade that integrated the functionality of a plugin used to upgrade WordPress with the same name or WPAU for short, and automatic plugin upgrade. For those who were able to use these features without any problems they were incredible time savers, but for those who had problems it was a huge headache.
The reason for the upgrade failure, whether it is the WordPress upgrade or a plugin upgrade, is a file and directory permission issue that can be easily resolved.
Most often the first time you try to use the automatic upgrade for Wolrdpress or a plugin you will be taken to the form that asks for your FTP login information. Note the 21 is the normal port used for FTP. If you use a different FTP port simply type in your FTP address a colon and the port number as show in the Hostname field below.
After clicking the Proceed button you may get an error like the one below. This might mean you typed in the wrong FTP login information, but if your login information is correct then you have a file and directory permission problem in your WordPress installation directory.
These directions apply to Redhat Enterprise Linux, Fedora, and CentOS.
What Not To Do
One bad suggestion is to make your wp-content directory read-write-execute by everyone by typing:
chmod 777 /path-to-wp-content/wp-content
This would make your WordPress installation vulnerable to a security attack. Some plugins might ask you to do this temporarily, and then ask you to change the permissions back to 755 after the plugin finishes its setup. This won’t fix your problem without adding more problems. The might allow the plugin upgrade to work, but it won’t fix the WordPress upgrade issue unless you chmod 777 the entire WordPress installation directory, which is a huge security risk, and should never be done.
Another bad suggestion is to give ownership to the web server, such as Apache by typing:
chown -R apache:apache /var/www/wordpress-installation
The -R means recursive, and applies the changes to all files and directories in your WordPress directory. Some servers use www-data for the Apache account, and others use apache. This at first appears to fix the problem, but adds another problem. If you need to use FTP to upload, delete, or modify files or plugins you’ll find you can’t do anything with FTP except login. Why? Because the Apache account owns all the files and directories, and your user account doesn’t.
You could try to fix the ownership issue by applying the following permissions to the entire WordPress installation:
chmod 775 -R /var/www/wordpress-installation
This would give the apache owner read-write-execute permission 7, and your user group read-write-execute permission 7, and read-execute permission 5 to the rest of the world, but once again this would be a big security risk.
Another bad suggestion would be to put the Apache account into the same user group that owns your WordPress directory:
/usr/sbin/usermod -a -G apache your-user-group
To remove the apache group for your user group type:
/usr/sbin/usermod -G your-user-group your-user-group
To find out which group apache belongs to type:
id apache
Once again you would be forced to apply chmod 775 to the WordPress installation directory, and you would have opened a big security hole again.
There is another wrong way to fix this problem using an Access Control List to allow Apache to have read-write-execute access to your WordPress installation directory:
setfacl -m u:apache:rwe /var/www/wordpress-installation
To remove apache’s access type:
setfacl -x u:apache /var/www/wordpress-installation
To see who has ACL permission on your WordPress directory type:
getfacl /var/www/wordpress-installation
The reason I reviewed all the wrong ways to fix this problem was to demonstrate how many wrong ways there are, and all can fix this problem, except in the wrong way, while creating security issues. When automatic upgrading of both WordPress and the plugins was proposed these problems were exactly what developers were afraid would happen.
What To Do To Fix the Permission and Upgrade Problem
Beginning with Version 2.7 WordPress can perform an automatic upgrade. As such, all file operations are performed as the user that owns the files, not as the web server’s user. All files are set to 0644 and all directories are set to 0755, and writable by only the user and readable by everyone else, including the web server.
First we want to maintain ownership of the WordPress installation files and directories by your user account, so we won’t be making any of the mistakes listed above. As a reminder the window you probably are seeing looks something like the one below:
To fix this login to your server with Secure Shell (SSH), or the less secure Telnet, type su to become root, and type the following:
/usr/sbin/setsebool -P httpd_can_network_connect=1
This setting allows httpd (Apache) scripts, like PHP scripts, to connect out to the network, like an FTP server. The -P in the line above means this setting will persist across reboots, and the 1 means on, whereas 0 would mean off. SELinux blocks the http demon from doing a network connect via an httpd script to a remote port by default, so we need to enable this feature with the command string above. If your WordPress installation is on a shared hosting server you may want to send a link of this article to your blog server host.
To check and make sure your new setting is on type:
/usr/sbin/sestatus -b | grep httpd_can_network_connect
You should get a response something like this:
httpd_can_network_connect onhttpd_can_network_connect_db off
Now try to upgrade, install, or delete a plugin, or WordPress to make sure everything is working. You should see a window like the one below:
If the upgrade is still not working apply the following lines to make sure your permissions are correct:
find /var/www/wordpress-installation -type d -exec chmod 755 {} ’;
find /var/www/wordpress-installation -type f -exec chmod 644 {} ’;
find /var/www/wordpress-installation/wp-content/cache -type d -exec chmod 777 {} ’;
find /var/www/wordpress-installation/wp-content/backup-db -type d -exec chmod 777 {} ’;
chmod 666 /var/www/wordpress-installation/wp-content/advanced-cache.php
chmod 666 /var/www/wordpress-installation/wp-content/wp-cache-config.php
chmod -R 777 /var/www/wordpress-installation/wp-content/themes
chmod -R 777 /var/www/wordpress-installation/wp-content/plugins
chmod 777 /var/www/wordpress-installation/wp-content/uploads
chmod 777 /var/www/wordpress-installation/wp-content/upgrade
Be sure to change /var/www/wordpress-installation to the pathway to your WordPress installation directory. Also note the 4th line above lists the directory backup-db, which may or may not exist in your installation, or could be named differently. The -R in some of the lines means it is recursive and will be applied to all files and directories in that pathway. In order to edit theme and plugin files using the built-in editors, those files must be set with 777 permissions.
In the lines above the cache directory, wp-cache-config.php, and advanced-cache.php files all will exist if you have WP SuperCache installed.
Now you should be able to do secure upgrades of WordPress, and WordPress plugins, while also being able to have the full functionality afforded by your FTP client.
Leave a Reply