Skip to Content

Updating WordPress with libssh (and what I did when it was broken)

Posted on 4 mins read

This post should be treated as an historical artifact. It probably contain broken external links and it may no longer reflect my views or opinions.

This was orig­i­nally about auto­matic updates over SSH2 not working for me when I upgraded to Word­Press 2.8. Word­Press 2.9 is out now, and this problem turned out not to be their fault.

After filing a bug report and working through it with the Word­Press team, a solution was even­tually found (see the final update to this post). If you’re not inclined to skip to the end then here’s your TL:DR: turn off open_basedir or make the decla­ration less restrictive.

If you’re not expe­ri­encing this problem (and Google says you’re landing here if you’re looking for help setting up SFTP/SSH updating for Word­Press), I don’t think this write-up will be of much help. After upgrading to Word­Press 2.8 I discovered that this update has broken auto­matic core and plugin updates for me. I use SSH2/SFTP as I don’t trust, like, need, or support FTP, and the SSH log only shows that the PECL module is opening a connection and then closing it, with Word­Press returning only the following to to the browser window.

Unable to locate Word­Press Content directory (wp-content).

I dug through how Word­Press handles upgrades, and tracked this all down to the /wp-admin/includes/class-wp-filesystem-ssh2.php file.

UPDATE 6/13/2009 @4:40 p.m. EST

From what I found, the rewrite of the SSH/SFTP2 update function happened because the ssh2.sftp wrapper was intro­duced. This replaced the older version of the function which copied contents into temp files and pushed the data around. It was a drastic speed increase, but it doesn’t bloody work on my system for one reason or another.

UPDATE 6/13/2009 @7:16 p.m. EST

I’ve offi­cially cried “uncle!” and turned to the most wretched hive of scum and villainy in blogging, the Word­Press forums (as well as their bug reporting and tick­eting system). I also iden­tified the patch which intro­duced the code which caused SSH2 support to go flying off the rails for me.

UPDATE 6/18/2009 @4:17 p.m. EST

The Word­Press team has marked this bug as belonging to mile­stone 2.9. There is a slim chance that maybe I’ll see some relief in 2.8.1, but more than likely they’re going to yet again refactor how SSH2 works for auto­matic upgrades. If this changes, I will update this post accord­ingly. For now, I believe I may have to simply let it be broken.

UPDATE 12/19/2009 @10:30 p.m. EST

Months later, I worked out what the problem was. Ulti­mately a conflict caused by use of PHP’s open_basedir and safe_mode kept the SSH2 module from accessing resources it needed. The way the ssh2.sftp wrapper works would bump into overly restrictive basedir decla­ra­tions. If you are expe­ri­encing this problem and you check your error logs after turning them up to “debug”, you’ll probably find out what directory or file is causing this conflict. It’s ulti­mately moot, since things like safe_mode are depre­cated in PHP 5.3 and being outright removed in PHP 6.

Oddly enough, updating libssh2 to some­thing more up-to-date than the outdated RPM provided by Dag for RedHat Enter­prise Linux/CentOS made a HUGE speed difference. Defi­nitely some­thing to look into if SSH updating is slow for you.


Other than that, this round of upgrades has been mostly painless, and the hyped speed increases are not just hyperbole. Word­Press 2.8 feels only slight under-baked beyond SSH2 hiccups. I confess that I haven’t had a chance to play with the redesigned sidebar widget admin­is­tration yet though, as I haven’t even figured out how I want to implement support for sidebar widgets into this theme.

The bug that deletes some custom fields if you update posts that have them is still there. No idea how to begin tracking that one down, but I can state author­i­ta­tively that it’s theme and plugin inde­pendent. Why am I linking to some dudes blog, and not the official Word­Press bug tracker? because I don’t even know where Word­Press keeps its bug tracker.

I also had to reset Word­Press Blog stats because Word­Press was tracking the wrong subdomain for all of my stats. The numbers tallied up with Google Analytics and the AWFFull log grinder, but the URLs were all effed up. I fixed the problem on the WordPress.com backend, and in the process lost months of aggre­gated history.

The upshot to this loss is that I hope to have a new round of search hit inspired commentary ready to go in a week or two.