Tag: command line

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:

Converting MySQL Database Contents to UTF-8 [en]

I finally managed to convert my WordPress database content to UTF-8. It’s easy to do, but it wasn’t easy to figure out.

[fr] Voici comment j'ai converti le contenu de ma base de données WordPress en UTF-8. C'est assez simple en soi, mais ça m'a pris longtemps pour comprendre comment le faire!

A few weeks ago, I discovered (to my horror) that my site was not UTF-8, as I thought it was. Checking my pages in the validator produced this error:

The character encoding specified in the HTTP header (iso-8859-1) is different from the value in the XML declaration (utf-8). I will use the value from the HTTP header (iso-8859-1).

In all likeliness, my server adds a default header (iso-8859-1) to the pages it serves. When I switched to WordPress, I was careful to save all my import files as UTF-8, and I honestly thought that everything I had imported into the database was UTF-8. Somewhere in the process, it got switched back to iso-8859-1 (latin-1).

The solution to make sure the pages served are indeed UTF-8, as specified in the meta tags of my HTML pages, is to add the following line to .htaccess:

AddDefaultCharset OFF

(If one wanted to force UTF-8, AddDefaultCharset UTF-8 would do it, but actually, it’s better to leave the possibility to serve pages with different encodings, isn’t it?)

Now, when I did that, of course, all the accented characters in my site went beserk — proof if it was needed that my database content was not UTF-8. Here is the story of what I went through (and it took many days to find the solution, believe me, although it takes only 2 minutes to do once everything is ready) to convert my database content from ISO-8859-1 to UTF-8. Thanks a lot to all those who helped me through this — and they are many!

First thing, dump the database. I always forget the command for dumps, so here it is:

mysqldump --opt -u root -p wordpress > wordpress.sql

As we’re going to be doing stuff, it might be wise to make a copy of the working wordpress database. I did that by creating a new database in PhpMyAdmin, and importing my freshly dumped database into it:

mysql -u root -p wordpress-backup < wordpress.sql

Then, conversion. I tried a PHP script, I tried BBEdit, and they seemed to mess up. (Though as I had other issues elsewhere, they may well have worked but I mistakenly thought the problem was coming from there.) Anyway, command-line conversion with iconv is much easier to do:

iconv -f iso-8859-15 -t utf8 wordpress.sql > wordpress-iconv.sql

Then, import into the database. I first imported it into another database, edited wp-config.php to point to the new database, and checked that everything was ok:

mysql -u root -p wordpress-utf8 < wordpress-iconv.sql

Once I was happy that it was working, I imported my converted dump into the WordPress production database:

mysql -u root -p wordpress < wordpress-iconv.sql

On the way there, I had some trouble with MySQL. The MySQL dump more or less put the content of all my weblog posts on one line. For some reason, it didn’t cause any problems when importing the dump before conversion, to create the backup database, but it didn’t play nice after conversion.

I got this error when trying to import:

ERROR 1153 at line 378: Got a packet bigger than 'max_allowed_packet'

Line 378 contained half my weblog posts… and was obviously bigger than the 1Mb limit for max_allowed_packet (the whole dump is around 2Mb).

I had to edit my.cnf (/etc/mysql/my.cnf on my system) and change the value for max_allowed_packet in the section titled [mysqld]. I set it to 8Mb. Then, I had to stop mysql and restart it: mysqladmin -u root -p shutdown to stop it, and mysqld_safe & to start it again (as root).

This is not necessarily the best way to do it, and it might not work like that on your system, but it’s what I did and the site is now back up again. Comments welcome, and hope this can be useful to others!

Similar Posts: