Need a WordPress website this weekend? Start here...

How To Fix FTP Connection Error on Localhost WordPress

(Reading time: 6 – 9 minutes)

Updated January 27, 2012. Thank you for visiting. This is the most popular blog post on Website In A Weekend. Your +1 is highly appreciated!

Overcast and drizzling here in paradise, that is, the east side of San Francisco Bay. This is the second time it’s rained in June. It never rains in June here! Not since 1998 that I can remember. In any case, let’s see what else the day brings.

Since WordPress 2.8 is scheduled for release sometime today, let’s check out a copy of WordPress 2.8 from subversion, install it on localhost, and poke around a bit.

My handy instructions for 5 minute WordPress installation don’t work exactly the same when installing on locahost. I don’t have cPanel installed locally, so I had to create the MySQL database and database user manually using a cygwin shell window.

First look: no major changes obvious to me other than the spiffy theme browser. So, let’s install a new theme, right from the WordPress.org theme repository.

Uh oh… FTP Connection Information required.

FTP connection information required indicates permission problem on host

FTP connection information required indicates permission problem on host

The WordPress connection information is telling me I can’t upgrade because WordPress doesn’t have permission to write files new files on the host.

That’s not good, and it needs to be fixed, pronto.

This wasn’t a problem when I initially installed WordPress, because I manually copied the WordPress files to the correct location.

Short answer

Have your FTP information ready and type it into the form as required. You should have FTP account information as part of your web hosting account. If everything is working correctly, the installation should proceed without issue.

Longer story

When typing your information into the web form simply will not work, you need to investigate more:

  • Ensure your FTP account information actually is correct. If necessary, create a new FTP account with “known good” username and password. Make sure to test the new FTP account in an FTP client other than WordPress. Now try the above procedure again.
  • If you’re still having problems, check to ensure your directory permissions are set correctly. One way to check your permissions is to use the WP Security Scan plugin, which will scan your WordPress installation and let you know which file and directory (folder) permissions are correct, and which are incorrect.

By the way, if you’re finding this article useful, I send out updates to Website In A Weekend via the newsletter. You can sign up using the form at the top of the sidebar. Thanks!

If you’re a developer, check out more articles in Extending WordPress.

What if you’re running on localhost?

I’m running on localhost, I shouldn’t need to provide FTP information. So why the problem? Let’s poke around on Google and see what we get… using “wordpress connection information” gives us two likely pages from wordpress.org (here, and here), and “Why WordPress Asks for Connection Info” from Chris Abernethy. You should read all three of these pages, and if you’re running on a remotely hosted server such as bluehost.com, these three links should be enough.

If you’re running on localhost, read on…

(or skip down to what to do on your hosted server)
Fire up a cygwin shell window and take a look. You could almost as easily do this using Windows cmd shell, but I prefer cygwin and bash.

File system ownership change fixing FTP connection error

File system ownership change fixing FTP connection error

See the top red box? One of these things is not like the other!

All the WordPress installations running on localhost run as Admistrators, but wp28 is running as my username “doolin.” How did that happen? Hard to say. Perhaps a slight change in how 2.8 installs itself. That’s a matter to dig into deeper in the future. Right now, we have other work to do.

If you like this article and find it helpful, you could help me in return with a +1. Thanks!

Clearly, the ownership of the “wp28″ directory needs to be changed. Since I don’t remember exactly what the flag for recursive changes are using the “chown” command. It’s either “-r” or “-R” so let’s look it up first using the man page, as indicated by the blue arrow. The unix man page browser opens in a pager, when the pager closes, it advances one line in the shell; you don’t see the chown information in the screenshot.

Now that you have the correct information, issue the chown command as shown in the bottom red box.

All fixed!

But is it…?

One of my first tasks after installing a new WordPress blog is checking the security setup. It should be one of your first tasks as well. Downloading and activating Michael Torbert’s WP-Security shows us the following problems with respect to file system permissions:

Use WP-Security to check file system permissions

Use WP-Security to check file system permissions

That’s nasty. Now, since this installation of WordPress is running on localhost, it probably doesn’t matter all that much whether I fix them or not. But I should, and I will:

  1. Good habits are hard to make and easy to break. So just do it.
  2. Changing permissions is trivial using the bash shell from the cygwin command line. bluehost.com allows ssh access to a bash shell on the host, so I can use the exact same commands there in the future, if necessary.

When you get an FTP Connection error when upgrading or updating, block aside a little bit of time to dig into the problem, and prepare to learn a tiny bit of unix magic. It’s not difficult, and it will pay you back later.

Changing permissions on your web host

The easiest way to check your relevant permissions is to use the WP-Security plugin as mentioned above.

What I do when I find anything out of order is use the FileZilla FTP client to change the permissions to the correct values. There’s plenty of information on Google about how to do this, leave a comment if you want more explanation here.

Hat tip Hat tip : If you’re an advanced user, check out Viper 007Bond’s explanation of new capabilities for file system handling in WordPress 2.8. (Hat tip Ricky Buchanan from the comments.)

Operating Your WordPress Website… Getting your IT systems squared away

(Reading time: 4 – 6 minutes)

One of the most unpleasant surprises to new internet entrepreneurs is that amount of overhead required to keep a single website operational. There’s just so much to know. Unless you’re able to outsource everything, as a website administrator, you need to be able to handle the following chores:

  • backing up databases
  • backing up files
  • upgrading and updating software

We’ll take a look at at each of these chores in detail, then discuss how you can make your chores a system that helps run itself. Once you have a system in place, you won’t have to spend energy thinking about what to do, and you will be better able to outsource tedious chores.

Hey! You're in the middle of the Website In A Weekend eCourse. Learn how to create and operate a complete WordPress-based website in a single weekend. Start here: Website In A Weekend: Friday Evening - Off to the Races. (If you already have a blog... "audit" the eCourse... you'll find plenty to do.)

Back up your databases

For every web application or set of web pages that requires a database, you need to have a plan for regularly backing up that database. For example, if you run a wiki and a project management tool along with WordPress on your server, you need to establish a system for backing up the wiki and project management databases as well. Dealing with the backup files is also important: you have to have them stored in a secure location, or back them up as well. This means “offsite” with respect to your hosting account.

In WordPress, backing up your WordPress database is easy using a plugin. My current choice is either Austin Matzko’s WP-DB-Backup, discussed in a previous article, or for more experienced users, Lester Chan’s WP-DBManager. Either works fine, pick one and learn to use it properly.

Files

File backups are different than database backups, yet equally important. In the same way as databases, backed up files need to be securely stored or backed up into a third location, offsite. There aren’t many plugins for handling this chore. I tried one recently and it crashed my WordPress with a whitescreen (that means bad PHP code). I won’t mention it by name as it doesn’t seem widely known, and I want to contact the author privately to see if I can get the issue resolved.

In the meantime, you should be keeping up with file system backups using an FTP client at the least. Download your WordPress files to your desktop, then upload them to a safe, 3rd location. Maybe burned to a CD, a thumb drive, or stashed elsewhere on a different hosting account.

Knowing which files to download is a very good question, and doesn’t have an easy answer. If you have modified any of your themes, or plugins, or any files associated with themes or plugins, you will need to back those up as well. But backing up your entire plugin directory is overkill, when plugins can be downloaded easily from WordPress.org. A middle way here is to back up your plugin directory one time to a convenient location on your hard drive, then all further backups should be only plugin files that you actively modify. An added benefit of having all your plugins quickly available from, say, a desktop folder, is using them to bootstrap a new blog. Instead of tediously installing each plugin from the plugin “Add >> New” menu, just FTP upload the lot right after you install the new blog.

Upgrade now…? Or wait…?

Updating and upgrading. This blessing and the curse of information technology is that it doesn’t stand still. It’s always evolving. You must evolve with it, or you will become so obsolete your entire system may need to be scrapped and completely replaced. In WordPress, updating and upgrading are fairly easy. WordPress installations now feature automatic upgrading capability, as do plugins. Themes, however, do not, and when you update a WordPress installation to a newer version, your theme may not work exactly the same. In the worst case, upgrading will break your theme. On the other hand, the longer you postpone moving to a new version, the more difficult it will be to perform an easy upgrade.

For a really great example, consider the browser share of Internet Explorer version 6. Nobody has been able to purchase IE 6 for years. But it’s hanging on in corporate IT departments which depend on certain functions of that browser which may break should they upgrade to IE versions 7 or 8. At some point, Microsoft will force an upgrade… which will be expensive to be sure for IE 6 users.

Here’s the tradeoff: when the cost of NOT upgrading exceeds the cost of upgrading, don’t hesitate.

Work your system

It’s important to have written policy for all of these activities. Backups need to be checked on a regular basis, for both databases and files. Upgrade policy should be established, and each site should be tested for behavior before pulling the upgrade trigger. Writing out procedure is much easier said than done. Start small. It may help to print your procedures to paper, and store in a 3 ring binder. Your exact procedure, when starting out, is much less important than simply having a procedure.