I Hate FTP [en]

[fr] Je hais le FTP. Donnez-moi un accès SSH et screen sur le serveur, et me voilà heureuse.

Ever since I discovered the magical combination of SSH + screen, I have come to loathe FTP. Although some of you will cringe at the idea, I like working directly on the server. No stray copies lying around, dated I-don’t-know-what. No chance of mistakenly overwriting your last set of changes.

Screen is a terminal multiplexer (just learned the term). What you do, basically, is climb inside it when you’re on the server, and do everything from there. The advantage is that:

  • when you disconnect your SSH connection, screen keeps running, so your workspace is how you left it next time you come in
  • you can have multiple “screens” (ie, terminal windows) you can easily switch around, so you can have your IRC channel running in one screen, be editing a file in another, etc. (basically, multi-tasking like you would do with windows in a graphical environment).

I learnt shell commands as I went along. Those I use the most are:

  • wget http://wordpress.org/latest.zip to download (instantly!) the latest version of WordPress directly on the server
  • unzip latest.zip to unzip it, still directly on the server
  • mv wp old-200910 to archive an old installation of wordpress (or move other files around)
  • cp -Rf plugins/* ../../wordpress/wp-content/plugins/ to copy all my plugins to the freshly unzipped install of WordPress
  • nano wp-config-sample.php to add my settings to the file and save it as wp-config.php

These are just a few examples. Once you know these commands and have them at the tip of your fingers, how fast you work is only limited by how fast you can type them. And you’re doing things directly on the web server. You’re not stuck looking at the “real world” (= the server) through the imperfect lens of an FTP client, waiting for uploads to happen (or downloads), paying attention not to overwrite stuff, having everything ready on your computer before pressing the magic button and hoping everything will be all right, because otherwise you’re in for another bout of download, edit, upload…

Some of my clients have WordPress installations on servers with no shell access. Obviously, I don’t have as much practice doing things the FTP way, but I swear it takes me 5 times as much time to do things with no SSH access. When you know how to use it, the command-line is wickedly fast.

The only situation where I actually do like FTP is when I’m using CSSEdit, because coupled to an FTP client, I can be editing my CSS file with the added power of the programme on my Mac, and have it upload and update the file on the server each time I hit save. Because yes, it’s nicer to write CSS in CSSEdit than in nano.

But for managing files and moving them around and minor edits… I’m much happier sitting on my server inside my screen.

Similar Posts:

Scripts for a WordPress Weblog Farm [en]

A first step to WordPress-farming: a shell script and a PHP script which allow you to easily install a whole lot of WordPress weblogs in only a few minutes (I installed over 30 in less than 5 minutes). Scripts require adapting to your environment, of course.

Update 03.11.06: Batiste made me realise I should point the many people landing here in the search of multi-user WordPress to WordPress MU. All that I describe in this post is very pretty, but nowadays completely obsolete.

Here is the best solution I’ve managed to come up with in half a day to finally install over 30 WordPress weblogs in under 5 minutes (once the preparation work was done).

A shell script copies the image of a WordPress install to multiple directories and installs them. A PHP script then changes a certain number of options and settings in each weblog. It can be used later to run as a “patch” on all installed weblog if a setting needs modifying globally.

Here are the details of what I did.

I first downloaded and unzipped WordPress into a directory.

wget http://wordpress.org/latest.tar.gz
tar -xzvf latest.tar.gz
mv wordpress wp-farm-image

I cleaned up the install (removing wp-comments-popup.php and the import*.php files, for example), added a language directory (as I’m wp-farming in French) and modified index.php to my liking; in particular, I edited the import statement for the stylesheet so that it looked like this:

@import url( http://edublogs.net/styles/toni/style.css );

The styles directory is a directory in which I place a bunch of WordPress styles. I don’t need the style switcher capability, but I do need to styles. Later, users will be able to change styles simply by editing that line in their index.php (or I can do it for them).

Another very important thing I did was rename wp-config-sample.php to config-sample and fill in the database and language information. I replaced wp_ by xxx_ so that I had $table_prefix = 'xxx_';.

To make it easier to install plugins for everyone, correct the language files, and edit whatever may be in wp-images, I moved these three directories out of the image install and replaced them with symbolic links, taking inspiration from Shelley’s method for installing multiple WordPress weblogs.

mv image/wp-content common
mv image/wp-images common
mv image/wp-includes/languages common
ln -s common/wp-content image/wp-content
ln -s common/wp-images image/wp-images
ln -s common/languages image/wp-includes/languages

I also added an .htaccess file (after some painful tweaking on a test install).

Once my image was ready, I compiled a list of all the users I had to open weblogs for (one username per line) in a file named names.txt, which I placed in the root directory all the weblog subfolders were going to go in.

I then ran this shell script (many thanks to all those of you who helped me with it — you saved my life):

for x in `cat names.txt`
cp -rv /home/edublogs/wp-farm/image/ $x
cat $x/wp-config.php | sed "s/xxx/${x}/" > config.tmp
mv config.tmp $x/wp-config.php
wget http://st-prex.edublogs.net/$x/wp-admin/install.php?step=1
wget http://st-prex.edublogs.net/$x/wp-admin/install.php?step=2
wget http://st-prex.edublogs.net/$x/wp-admin/install.php?step=3

This assumes that my WordPress install image was located in /home/edublogs/wp-farm/image/ and that the weblog addresses were of the form http://st-prex.edublogs.net/username/.

This script copies the image to a directory named after the user, edits wp-config to set the table prefix to the username, and then successively wgets the install URLs to save me from loading them all in my browser.

After this step, I had a bunch of installed but badly configured weblogs (amongst other things, as I short-circuited the form before the third install step, they all think their siteurl is example.com).

Entered the PHP patch which tweaks settings directly in the database. I spent some time with a test install and PHPMyAdmin to figure out which fields I wanted to change and which values I wanted to give them, but overall it wasn’t too complicated to do. You’ll certainly need to heavily edit this file before using it if you try and duplicate what I did, but the basic structure and queries should remain the same.

I edited the user list at the top of the file, loaded it in my browser, and within less than a few seconds all my weblogs were correctly configured. I’ll use modified versions of this script later on when I need to change settings for all the weblogs in one go (for example, if I want to quickly install a plugin for everyone).

In summary:

  1. compile list of users
  2. prepare image install
  3. run shell script
  4. run PHP script

If you try to do this, I suggest you start by putting only two users in your user list, and checking thoroughly that everything installs and works correctly before doing it for 30 users. I had to tweak the PHP script quite a bit until I had all my settings correctly configured.

Hope this can be useful to some!

Update 29.09.2005: WARNING! Hacking WordPress installs to build a farm like this one is neat, but it gets much less neat when your weblog farm is spammed with animal porn comments. You then realise (oh, horror!) that none of the anti-spam plugins work on your beautiful construction, so you weed them out by hand as you can, armed with many a MySQL query. And then the journalist steps in — because, frankly, “sex with dogs” on a school website is just too good to be true. And then you can spend half a day writing an angry reaction to the shitty badly-researched article.

My apologies for the bad language. Think of how you’re going to deal with spam beforehand when you’re setting up a school blog project.

Similar Posts: