How To Fix WordPress Automatic Upgrades in WordPress 2.5. – 2.7 (Plugins and WordPress)


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.]

, , ,

  1. #1 by Raju at December 10th, 2008

    Awesome!! Bookmarked on Reddit :)

  2. #2 by Daniel at December 11th, 2008

    Non-root users can’t change file ownership to another user, and many systems don’t use “apache” as the user that apache runs under.

    Another way to do this, but still not possible for non-root users who don’t belong to the webserver’s group is to only change the group that the files belong to and change their permissions to 775. Use this when you don’t want to change the files’ owner.

    Good article though, I’d been meaning to look into that issue and you just saved me the trouble :)

  3. #3 by clifgriffin at December 11th, 2008

    Ahh! You called my bluff. :)

    Right after writing this I started thinking about that, but I didn’t get around to changing it. Even in some of my own installations apache isn’t the user apache runs on.

    I have made the necessary edits. I didn’t think about changing the permissions 775…thank you. I have credited you for the edits.

    Cordially,
    Clif

  4. #4 by Dan Schoppe at December 12th, 2008

    Hey Clif,
    Thanks for the article, as this exactly describes my trouble with the automatic updates! I’m a bit newer to Ubuntu, which is what I have WP running on in my bedroom.

    I’m on the server trying to update my plugins after installing WP 2.7. I ran “sudo chmod 755 /var/www/ -R” to change permissions (I think?) of my WP install. I’m not sure how to change the group of all of these files. Right clicking my /var/www/ folder and going Properties -> Permissions lets me change the group, but apache isn’t an option to select.

    Did I change permissions / group correctly with chmod 755? In the “Connection Information” page on WP, what do I use as the Hostname, Username, Password, Connection Type if I’m already on my server? Do I just use my Ubuntu login, my WP login, localhost, or something else?

    Thanks in advanced, I look forward to hearing your reply!
    Dan

    • #5 by clifgriffin at December 12th, 2008

      Hi Dan,
      When things are setup properly you should never see the FTP connection information screen at all. That is a last resort that is only shown when it is unable to write to the temporary directory.

      I’m not positive how you tell what user apache is running as, but a good first start would be to run ps -aux from a terminal window as root and look for an apache process and see what user it is running as.

      You should be able to tell what group that user is in by running:
      cat /etc/group | grep GGG

      Where GGG is the user in question.

      Once you have that, run chown -R user:group * from the director y your wordpress files are in.

      Finally, make sure that wp-content/ is set to 755. (chown 755 wp-content/)

      It seems you have set your entire wordpress installation to 755, which is possibly too liberal. See http://codex.wordpress.org/Changing_File_Permissions for more information.

      Lastly, if the above doesn’t work, try Daniel’s suggestion of setting wp-content/ to 775.

      Let me know if this doesn’t solve your particular problem.

      Clif

  5. #6 by Dan Schoppe at February 8th, 2009

    Clif,
    Thanks for such a speedy response. I’ve been torn away from my blog for some time, but I’ve now tried the fix you’ve described. I found out the Apache user was www-data and the group was www-data. Hence, I ran the following commands:
    sudo chown -R www-data:www-data *
    sudo chown 775 wp-content/

    Thanks for all the help! Everything seems to be updating just fine now, and I’m back on track!

    Thanks again,
    Dan

  6. #7 by Frank Lores-Penalver at February 9th, 2009

    Hi Clifton,

    I followed your steps and it works great, the only problem is that by changing ownership of all files you cut access through the ftp client, so what I’ve done is to follow Dan’s recommendation and add the group permissions. I also discovered that 1and1 runs apache:apache so what I did was to add apache to my ftp group, didn’t change the ownership of my files just added write permissions to the group and that seems to work too.

    Thanks for the write-up.

    Frank

  7. #8 by Julie at February 17th, 2009

    Thanks so much for the attempt at solving this problem for people.

    I must admit, I’m pretty savvy when it comes to WordPress and I think it’s totally ridiculous that it’s this complicated to simply upgrade to newer versions and to upgrade my plug-ins. Putting it nicely, I’m very, very frustrated.

    How do I “Change the group for the wp-content/plugins directory to apache.”? I don’t even know what that means. :-(

    Is there not a simple way that this can be done? Any help would be much appreciated.

  8. #9 by Julie at February 17th, 2009

    Can I just pay someone to fix this for me? On this and future sites? I’m serious. It’s making me crazy.

    • #10 by clifgriffin at February 17th, 2009

      Hi Julie,
      Changing the group is done by the this command, referred to above:

      chown -R apache:apache *

      The format for chown is user:group so this assumes that apache has been installed as the user apache *and* the group apache.

      A few commenters have noted this is not always the case.

      If you have sufficient access to your machine you can run:
      ps -aux | grep “httpd” you should see the user on the left.

      You can look in /etc/group to figure out which group the user is in.

      Then simply change the command above to reflect your findings:

      chown -R user:group *

      Make sure you run this from the directory your wordpress installation is in! If you run this from / or any other directory, you’re going to mess things up.

      All this assumes you have SSH access to your machine, of course.

      Let me know if you have any issues,
      Clifton

  9. #11 by Bradford at February 28th, 2009

    For me on Debian, the user had to be www-data in group www-data, NOT apache. Thanks for the start though!

  10. #12 by Emil at March 21st, 2009

    All right I must say wow!
    It took me entire day to google this and voila, you came to the rescue, this was so unbelievable easy.

    As you said: wp-content/ (CHMOD to 0775) and posix_getuid() change made my life an easy.

    Man you would not believe how annoying is to type in that FTP info every time I want to do simple plugin upgrade, but now thanks to you that is 100% eliminated.

    Once again thanks,
    Emil :-)

  11. #13 by palm pre at March 31st, 2009

    The apache user change didn’t work for me, however, the change mentioned in the referenced article did. For wordpress 2.7.1, I changed wp-admin/includes/file.php line:

    if ( getmyuid() == fileowner($temp_file) )

    to

    if ( posix_getuid() == fileowner($temp_file) )

    no other changes were needed, however i already had all my plugins folders as 755 anyway, so that might be needed as well.

  12. #14 by Justin at April 6th, 2009

    Hello – I’m happy to have come across this information because I just encountered this problem, and I have run a dozen Wordpress sites and never came across this issue.
    I do have to say, that I did not understand even half of the technical information you provided. I am not much of a back end programmer. I even read the easy way, and it didn’t make sense. What does it mean to “Run those commands” – how do I do that?
    I just upgraded an old wordpress for a client, and this happened. It was a pretty old one too, but I have upgraded others before without this issue.
    Is there a step-by-step way to go about this?
    Thank you very much!

    • #15 by clifgriffin at April 7th, 2009

      By “Run those commands” I’m assuming two things that I probably could have made clearer.

      1. You’re on a *nix environment. (Linux, BSD, etc)
      2. You have SSH or direct access to the server.

      The commands I list are SSH commands.

  13. #16 by nick at January 7th, 2010

    1. I don’t know why the upgrade function not working never bothered me until now, but it didn’t.

    2. I am amazed that I remembered reading this post and that I also remembered it was on your blog.

    3. Thank you! Apache runs as nobody:nobody on my server. Easy enough to fix. Now to fix the 20 other WP installs on the server…

(will not be published)