As much as I like screwing around with software, I spent some time this weekend looking into ways to spend less time maintaining my WordPress installs. WordPress has had the ability to automatically update plugins for awhile but it’s never worked for me.
Whenever I tried to do a plug-in update I’d get prompted to enter a ftp account and password. This isn’t something I want to do (keys to the kingdom in an unencrypted webpage) but I figured security and file permissions were a place to start.
Long story short, I found 95% of the solution from Keith Garner in his post here. The write-up is for an earlier version of WordPress and a different flavor or version of Apache, but the differences are easy to spot. I did have to add one additional step.
You’ll need admin access to the server in order to make these changes. I’ll comment on his steps here but refer to his original post for the exact syntax. I did my changes in Apache 2 on Ubuntu.
- Change the permissions on the wp-content/plugins directory (and sub-directories). This makes the directory contents writable by the Apache server process. I’m running Apache on Ubuntu so the group is www-data instead of apache in his example.
- Make sure you define the WP_TEMP_DIR after the ABSPATH define.
- One commenter mentioned that the “last step”, the sanity check, isn’t needed in WordPress 2.71. I’m running WordPress 2.7.1 and did need to make the change. In WordPress 2.7.1 the function is on lines 626 & 628. [Update] If you are using WordPress 2.8 or later you can add
define('FS_METHOD', 'direct')to wp-config.php instead of editing file.php
- After the above changes I received an error that the wp-content/upgrade directory couldn’t be created. True enough, as I hadn’t changed permissions on wp-content itself. Rather than change permissions I created a wp-content/upgrade directory and gave it the same permissions used for wp-content/tmp.
Giving the Apache server process owner access to the plugin directories along with tmp and upgrade are a minor security risk. If Apache is compromised someone could write files to the directory (or modify what’s there). I do daily backups with archiving so I figure the risk is acceptable.
I’ve only had one plugin to upgrade, but it went successfully.
[Update] – I reviewed the WordPress bug report related to changing the sanity check. The fix outlined by Keith (use posix_getuid instead of getmyuid) isn’t a universal solution and may have side effects. In my case I prefer the side effects over the alternative of using FTP. The side effect is that the files updated by auto-update are owned by the server ID and my own ID can no longer delete them through terminal. This is minor as it’s something I’d rarely do and I have a script which will modify ownership on all plugin files should I need to delete them myself. Some configurations may not require this change (such as the server process running under the same ID you use) so leave it out if you don’t need it. This does help explain why there’s so many conflicting comments about how to fix this issue. Also, as of WordPress 2.8 it’s no longer necessary to edit file.php, see step 3 above for the update.