Getting WordPress Automatic Upgrade to Work on Pair.com

This was a seriously painful problem for a while. Took a bit of searching to come up with a very easy solution (which would have been even easier if I hadn’t made a typo).

What was happening:

1. Automatic upgrades of some plugins worked — but VERY slowly (as in it took HOURS). And it would ususally hang at the end, but I could reload the web page and everything seemed fine and worked. Obviously not the slick interface that was intended.

2. Some plugins — including the old WordPress Automatic Upgrade plugin — just failed.

And the big “aha!” — I went to manually upgrade WordPress by uploading a new copy and there were WordPress files in my account that I couldn’t delete.

I got lucky with some searching and found someone who had this same problem with pair.com and pointed to the solution. However, I suspect that this could happen on many hosting configurations and the reason why it does or doesn’t gets into details that are beyond me.

This is the post describing the problem at pair.com and WordPress Automatic Upgrade.

This is the page with the php-cgiwrap solution.

Before I could make any progress, I needed to get all the files in my account back to being owned by me so that I could delete them and upload a fresh copy of WordPress. I called pair.com tech support (this was a Sunday afternoon) and explained my problem to someone who understood it right away. He went into my account and changed all my files back to being owned by me. The entire call took 5 minutes and 40 seconds from dialing to hanging up. That’s what I mean by right away.

So in order for WordPress to own the files it creates, the has to be a copy of php5 in your account and it gets called using php-cgiwrap. Then it runs under your userid instead of as user nobody.

There are interesting security implications to this too — pair.com says

Running PHP pages under your own userid allows you to use chmod 700 to lock out other users on the server from viewing the source code. Locking out other users can be especially important if you are interfacing with a MySQL database, thereby preventing people from obtaining your password.

That needs some pondering on another day.

The instructions say:

To use PHP 5 with php-cgiwrap, you must first copy php5.cgi to your own Web directory’s (public_html) cgi-bin directory by SSH:

  cp /usr/www/cgi-bin/php5.cgi ~/public_html/cgi-bin/
  chmod 755 ~/public_html/cgi-bin/php5.cgi

To connect with SSH, you need a terminal program like PuTTY (I work on Windows, mostly).

Unfortunately, I made a silly typo and typed:

  cp /usr/www/cgi-bin/php5.cgi ~/public_html/cgi-bin
  chmod 755 ~/public_html/cgi-bin/php5.cgi

This copied php5 into a file in my account named “cgi-bin” instead of copying it to my “cgi-bin” directory. It’s been a long time since I’ve worked in a command prompt environment and that was an easy thing to mis-type since I wasn’t clear on the meaning of what it was doing.

The chmod line then failed since there was no php5.cgi in the cgi-bin directory.

I had enough understanding of working with a command line to realize I made a boo-boo, but not enough understanding of linux commands to navigate around my account and fix it.

I tried to look around using FileZilla, but I somehow couldn’t locate the misplaced & misnamed file. Another quick call to pair.com tech support and this was taken care of. (Due to the way the file redirection works, something about trying to look at /usr/www/cgi-bin I think made FileZilla act weird — I don’t know.)

Another quick call to pair.com tech support and the file was set up in the proper location.

The next steps are:

You must then add the following lines to your .htaccess file (please note that this code should be two lines in length with a space before “/cgi-sys”):

  Action application/x-pair-sphp5 /cgi-sys/php-cgiwrap/USERNAME/php5.cgi
  AddType application/x-pair-sphp5 .php

USERNAME should be replaced with your account username. The .htaccess file mentioned above is a plain text file of that name and can be used to configure certain Web settings. If you do not already have a .htaccess file, you can create a regular file with that name to use. This should be placed into the Web directory containing the scripts you wish to wrap.

Once this is done, all .php files are run under your own user ID. If you want to use a different file extension, replace .php on the second line with whatever you prefer.

I already have the .htaccess file for WordPress, so I added those two lines at the top of the file.

That’s that – everything works great now and intalling and upgrading plugins is super-fast.

UPDATE February 21, 2013

Pair recently moved my sites to a new fast 64 bit server. Apparently one of the issues with switching to 64 bit is that certain tasks take more memory and my WordPress sites were throwing memory allocation errors.

I managed a quick fix by adding this line to the wp-config.php file so that WordPress would grab more memory:

define('WP_MEMORY_LIMIT', '64M');

However, the more general-purpose solution is to put a php.ini file in the same directory with the copy of php5.cgi

In the php.ini file, increase the memory limit with this one line of code:

memory_limit = 64M

Back to happy times!

—

Here’s some other references I found to this in case the above doesn’t solve your problem. To me these all looked like reasonable info, but a little over my head at points. I have no idea what the proposed solutions do — I just know that what I did above is what worked for my hosting situation.

This post describes the situation as “Filesystem access is available, the files are owned by me, but the webserver doesn’t run as me, and thus, WordPress doesn’t detect the automatic update correcly.” A plugin is provided that solves the problem.

This is the WordPress support ticket the above post references. One of the posts in it says “you should not use the Direct FS access because files created by the web server are not owned by the same user that owns the WordPress files, It creates headaches when a user comes along and wants to delete a file via FTP, and finds that, because they’re running as user xyz and not www-data, they cant delete files out of their own directory.” All I can say about that is that is exactly what happened to me — I couldn’t delete files via FTP and had to call pair.com tech support to fix the ownership of the files.

Also, there have been WordPress problems if you are running php4 instead of php5.

This lists the hosts that it is compatible with the WordPress Core Update — next to pair.com it says it works using php-cgiwrap and has a link to more information. If I had come across this first I would have found my answer sooner. The power of google is that most of the time if you can correctly describe your problem, then you can find someone who has already had it.