Note: These instructions assume Apache is running as the user apache under the group apache. This may not be how your installation is setup.  For instance, my MediaTemple account runs apache under the user clifgriffin.com and the group clifgriffin.com.  Your mileage may vary.  Substitute your user and group for apache and apache in the instructions below.

If you’re looking for a quick solution, skip down to “The easy way”.

I manage three WordPress installations currently. Two are personal.  One is for my employer.  The personal installations are hosted with MediaTemple. The other is hosted internally on a Dell server with RedHat.

Quite awhile ago, I upgraded this WordPress installation to 2.5.1. At the time, I noticed that automatic plugin upgrades were not functioning, but I didn’t bother to figure out why.  After I upgraded to 2.7-RC1, I noticed that the same fate had befell WordPress upgrades. I couldn’t automatically upgrade WordPress or plugins.

When trying to upgrade, I would be presented with a screen asking for my FTP information, including hostname, username, and password.

So, today, armed with absolutely nothing else to do, I decided to attempt to fix this problem.  Initially, I was suspicious that the only way WordPress can do upgrades is by utilizing an ftp server on the current machine.  Fortunately, this was not the case–in fact its the last resort. While a few Google searches turned up nothing initially, I eventually found this which led me to this.  In this article, Keith outlays a few steps to fix this (if you need to fix this, do not perform the following steps…there is an easier way…read on):

• Change the group for the wp-content/plugins directory to apache.
• Manually define a WP_TEMP_DIR
• Set write permissions for this folder and assign apache as the group for this folder as well.
• Lastly, he recommends replacing the function getmyuid() with posix_getuid() in wp-admin/includes/file.php

This last step he identifies as either a bug or a feature. (He isn’t sure which.)

These steps seemed to fix the problem–especially the last one–but I wasn’t satifised the result. I’m using WordPress 2.7-RC1…that means this problem has persisted two major versions.  I decided to investigate further.

As Keith explaisn, getmyuid() and posix_getuid() return two different things.  getmyuid() returns the UID of the person who owns the script that is running.  posix_getuid() returns the UID of the process running the script.  This led me to believe that the underlying problem was not a bug and simply an issue of file ownership.

The easy way:

I reverted the changes to /wp-admin/includes/file.php and proceeded to do a recursive ownership change across my whole WordPress installation. I also made sure that wp-content/ was user writeable.  Simply put, run the following commands from the directory in which WordPress is installed:

chown -R apache:apache *
chmod 755 wp-content/

The first command sets both the owner and group of all files and folders in the current directory to apache.  It is important to do this because WordPress uses the apache user to accomplish the upgrade. If any of the files are owned by your user, root, or anyone else, it will fail.

After I made these changes, I was able to do all upgrades (both plugins and WordPress) with no issues.  Keith’s instructions are very nearly correct. They simply overlook the owner and focus on the group. The group may be important, but it isn’t the problem in this scenario.

If you do not have root access…

If you do not have root access, you will not be able to change ownership of the files.  You should be able to compensate for this with more liberal permissions.

If this is true for you, try setting wp-content/ to 775 instead of 755.

So, in short to enable automatic plugin upgrades on WordPress 2.5.1 and later:

1. Change owernship and group of all WordPress files to apache.
2. Make sure the wp-content/ directory is writeable by apache.

[Thanks to commenter Daniel for non-root user instructions.]