le blog » PHP

Updating WordPress via SSH instead of FTP

norm — Tue, 01 Dec 2009 19:09:54 +0000

I’ve shut off FTP access to my server a while back, since FTP passwords are passed in plaintext over the net which is A Bad Thing™. For the occasions that I would need to update WordPress via its web interface, I would start up the FTP daemon so that I could use WordPress’ auto-update feature, and then shut it back down after I was done. Not that big of a hassle, but it required me to login into my server before doing anything from the web interface which was one step too many.

I discovered that WordPress has built-in support for updating via SSH2 if PHP has the PECL SSH2 library installed. Following is a quick summary of how to get it running.

The PECL ssh2 library requires libssh2 which I downloaded and then compiled painlessly with a

$ ./configure
$ make
$ make install

Once libssh2 was compiled and installed, I installed the PECL ssh2 library via

$ pecl install -f ssh2

The -f flag is to force the install since ssh2 is still in beta & you’d otherwise get a warning like

Failed to download pecl/ssh2 within preferred state "stable", latest release is version 0.11.0, stability "beta", use "channel://pecl.php.net/ssh2-0.11.0" to install

After installing ssh2 via pecl, i edited the php.ini file (located at /etc/php.ini for me) to tell PHP to load this extension

extension=ssh2.so

and then restart apache afterwards (via apachctl, service httpd restart, or whatever is appropriate for your system) so that the library would be available to PHP.

After apache comes back up, you should see a new option (SSH) in the wordpress upgrade page (which applies to plugins as well).

BTW, if you’re on a Red Hat Fedora system and/or use yum, you might be able to just pull the libssh2 rpm from yum instead of compiling it:

$ yum install libssh2
$ yum install libssh2-devel
$ yum install libssh2-docs

ZendCon 2007 Day 1

norm — Wed, 10 Oct 2007 07:39:47 +0000

was not too bad. I went to 5 sessions and found at least 2 of them moderately helpful, namely Ben Ramsey’s session on memcached and Eli White’s PHP & MySQL scaling techniques. I might put up a short list of take aways in a few days.

View from the back

PHP’s curl_multi to the rescue

norm — Tue, 11 Sep 2007 23:48:18 +0000

One of my Facebook apps hits Amazon’s Ecommerce Service (ECS) for item information via REST queries. I needed to process 19 separate queries searching for a title (basically searching 1 of 19 “browse nodes”), and return that data onto the Facebook canvas.

Simple enough, I could just do a foreach loop to make each REST request. Only problem was, say, each loop took 500 milliseconds total. That’s not hard when you consider all the steps: DNS, performing the REST query, waiting for the response, receiving the response, and then parsing the XML (in this case, using the SimpleXML extension). At 19 requests that’s 9.5 seconds which is way too slow, not to mention Facebook times out the request as well and returns a lovely error page.

For the test REST query I was benchmarking, it was averaging 9.65 seconds for the entire PHP script to complete (performing all 19 REST queries and then formatting the output). Simply switching from file_get_contents() to PHP’s cURL functions dropped the average to 7.32 seconds, a roughly 24% improvement. That was a great improvement, but still too slow and Facebook was still timing out the pages.

The root of the problem was that the 19 REST queries were sequential and as a result too slow. I needed to make those requests concurrently. Fortunately, PHP supported multi curl (basically making multiple cURL requests concurrently) via curl_multi_* functions.

BAM. Using curl_multi dropped the page generation time down to 1.6 seconds — much more reasonable and a 83.4% improvement. w00t.