lyncd

The real scoop on WordPress ‘Connections Information’ request for FTP info

The last few versions of WordPress have had a feature that lets you install or upgrade a plugin directly through the WordPress GUI. There’s just a small problem — for many people, the process fails and, instead of explaining the issue, WordPress redirects to an inscrutable “Connections Information” screen requesting FTP server credentials. Which, for people like me who don’t use FTP, is kind of a dead end.

I deploy all my code through a VCS, so it wasn’t until I started testing activation/deactivation/uninstall hooks for a plugin that I ran into the problem. Anyway, the reason I’m writing this post is that, while the workaround is just a one-liner, unfortunately, most of the “solutions” I found on the web were wrong or at best incomplete. Also, I think what WordPress is doing here could use improvement.

Almost always, the answer to this sort of problem (i.e., WordPress can’t upload images!) is to use chown and/or chmod or your FTP program to make some directories or files webserver-writable. It’s just a filesystem permissions issue. But not this time.

It’s a feature

In this case, yes, the problem does have to do with filesystem permissions, but it’s not that WordPress doesn’t have permission to write into a particular location, it’s that it’s choosing not to. This is a “feature,” folks. It’s one that falls under the category of “protecting users from themselves” even if, for some users, it may cause more problems than it would ever have solved.

Here’s what WordPress is trying to do: Suppose you’re on a shared hosting account or another server owned by someone else, and the webserver or PHP CGI process runs as a particular user: say, www. But, all the files in your directory are owned by you, johndoe. (Now, most real shared hosts these days are using something like suEXEC so that everything runs as johndoe, but that’s a separate issue and, if you’re reading this, probably doesn’t apply to you.)

What WordPress is trying to prevent is the situation where you install a plugin through the uploader (so, the files are created and owned by www) and then, later, you decide you need to delete or move parts of your website. Well, if you’re using FTP or the shell, johndoe won’t be have the permissions to delete or move the plugin files owned by www. Instead, he’ll get error messages and it’ll be a support headache for somebody.

So, what WordPress is doing before it lets you upload a plugin is: creating a temp file, seeing what user it’s created by, and then only proceeding if that user matches the owner of the calling PHP script (i.e., wp-admin/update.php). Here’s one blog that got the explanation right.

The fix

If you want to be able to do direct uploads of plugins and don’t care that they’ll be created by the webserver user (i.e., if you’re reading this article), then the solution is simple. You just need to define the global constant FS_METHOD as “direct” somewhere. Most likely, in wp-config.php:

define('FS_METHOD', 'direct');

Alternately, you could also do as the linked post above suggests, and chown some or all of your WordPress application files to the webserver user, but chances are there’s a reason (security!) you didn’t want to do that in the first place.

(You may also have to create or chown/mod some directories, such as the upgrade and plugin folders, if you haven’t installed or updated a plugin through the GUI before, but WordPress will walk you through that.)

But I’m still angry

Well, not really. I just think that WordPress is altogether too slick of an end-user application to be popping up this bogus “Connections Information” screen instead of doing something smarter, or at least pointing users in the right direction more smartly.

Personally, I’m against this “feature” and think WordPress should just do a standard check of whether it can write to the filesystem. After all, that’s all WordPress checks when you upload a photo. And, users who install a plugin through the GUI can always delete it through the GUI, even if their FTP or shell user account can’t. But then again, I’m not the one working user support for WordPress or a big hosting company who has to explain that to them, so that’s easy for me to say.

I’ve reopened one of the many old bug reports on this issue with a patch and (as a backup) a couple of suggestions for a more user-friendly UI. So, hopefully, we can make this “feature” better, even if it’s here to stay.