After an upgrade of wordpress to a version > 2.1 all special characters had been displayed in a crazy style. The reason for that, was a change of the characterset inside wordpress from latin to utf8.

Solution:

1. Change the wp-config.php
old version (after the upgrade):
define(’DB_CHARSET’, ‘utf8′);
define(’DB_COLLATE’, ”);

After your changes:
define(’DB_CHARSET’, ”);
define(’DB_COLLATE’, ”);

2. The better way is to run a script on the database, in order to switch its content from latin to utf8. A ready-to-use solution can be found here.
The plugin will complain about a wrong (too new) wordpress version, and that it had not been tested with it. But after a backup of the mysql-database, I started the plugin - and it worked.
But no guarantee from my side! So, please make a backup before you start!

Conclusion: The abnormal display of special characters after a wordpress-upgrade is a result of the change inside the database from latin to utf8-character-set. The named solutions make sure, that your blog looks, as you expect it…

Nach dem Upgrade von wordpress auf eine Version > 2.1 wurden sämtliche deutschen Umlaute im Text falsch dargestellt. Grund dafür war eine Umstellung des Character-sets von latin auf utf8.

Zwei Möglichkeiten zur Lösung:

1. Die config wp-config.php ändern
vorher:
define(’DB_CHARSET’, ‘utf8′);
define(’DB_COLLATE’, ”);
Nachher
define(’DB_CHARSET’, ”);
define(’DB_COLLATE’, ”);

2. Ein script über die Datenbank laufen lassen, um den ganzen Inhalt auf utf8 umzustellen. Dazu gibt es ein vorgefertigtes Plugin. Kann hier downgeloaded werden.
Das Plugin wird sich möglicherweise beschweren, dass es mit der aktuellen Wordpress-Version nicht getestet wurde. Ich habe es (nach einem Backup der Datenbank) trotzdem gestartet. Und es ging!
Ich gebe aber keine Garantie. Also: unbedingt vorher ein Backup der Datenbank machen!
Funktioniert aber sauber!

Fazit: Die fehlerhafte Darstellung von Umlauten in Wordpress nach einem upgrade, liegt vermutlich an einer Änderung des Charsets. Die o.g. Möglichkeiten stellen sicher, dass der Text wieder vernünftig aussieht.

It was high time, to apply the most recent security patches to my Debian-systems. Was done this afternoon.

But due to the fact, that there were some very vulnerable topics with open-ssl, I also had to create new keys. So, all known_hosts and authorized_keys files have to be updated.

During upgrading the ftp-server proftp had been updated. And this created a problem. I keep this service running as ServerType = standalone. During the update, the /etc/proftpd/proftpd.conf - file had not been changed. But somehow the proftpd could not be started as normal (/etc/init.d/proftpd start). And: no /var/run/proftpd.pid - file was existent.
Finally I killed the proftpd after executing ps aux | grep proftp and started the service new - and then everything was running fine. But, I don’t know why. In the log-files I found lots of lines like:

Sep 28 17:16:45 ...gimme-th.at proftpd[29948] ....gimme-th.at: Check the ServerType directive to ensure you are configured correctly.
Sep 28 17:17:32 .....gimme-th.at proftpd[9422] .....gimme-th.at: Failed binding to 0.0.0.0, port 21: Address already in use

Oviously the service could not be restarted fully and it had to be killed by hand first.

I always wonder, why people make a big fuss out of their new design for their blogs. Now, I do it myself. And just because of the fact, that it’s a lot of work - and needs more coffee than anything else.

And, I didn’t change lots of things, just colors and header-images. But, it’s enough for today. One big advantage: I start to understand how this css-stuff works. If everything is programmed properly, there’s just one place where you should start to change things.

Today, I copied my blog to a local webserver - just for testing. And then I was in the need of changeing some basic information in the database. I had to change the siteurl of the blog, which is stored inside the mysql-database.

So, how can you change your site-url of the wordpress-blog by using mysql?
First log into your mysql-database

mysql -u user -p

After this have a look at all your databases:

mysql>show databases;

This may look somewhat like that:

+--------------------+
| Database           |
+--------------------+
| information_schema |
| wordpress          |
| mysql	             |
+--------------------+

Now, choose your database (in this case wordpress):
mysql>use wordpress;

After this, let’s have a look at the tables:
mysql>show tables;
The result looks like that.

+---------------------------+
| Tables_in_wordpress       |
+---------------------------+
| wp_comments               |
| wp_ec3_schedule           |
| wp_links                  |
| wp_metar_cache            |
| wp_now_reading            |
| wp_now_reading_books2tags |
| wp_now_reading_meta       |
| wp_now_reading_tags       |
| wp_options                |
| wp_postmeta               |
| wp_posts                  |
| wp_term_relationships     |
| wp_term_taxonomy          |
| wp_terms                  |
| wp_usermeta               |
| wp_users                  |
+---------------------------+

Most certainly, the needed information is stored in wp_options. So let’s have a more detailled look at this table:
mysql>describe wordpress_options;

+--------------+-------------+------+-----+---------+----------------+
| Field        | Type        | Null | Key | Default | Extra          |
+--------------+-------------+------+-----+---------+----------------+
| option_id    | bigint(20)  | NO   | PRI | NULL    | auto_increment |
| blog_id      | int(11)     | NO   | PRI | 0       |                |
| option_name  | varchar(64) | NO   | PRI |         |                |
| option_value | longtext    | NO   |     |         |                |
| autoload     | varchar(20) | NO   |     | yes     |                |
+--------------+-------------+------+-----+---------+----------------+
5 rows in set (0.00 sec)

Now, we are searching for the right name inside the database.

mysql>select option_name from wordpress_options;
(Output is slightly abridged :-) )

+-----------------------------------------+
| option_name                             |
+-----------------------------------------+
| siteurl                                 |
+-----------------------------------------+

OK, now let’s see, what is stored in this value…

mysql>select option_value from wp_options where option_name=’siteurl’;

+-----------------------------+
| option_value                |
+-----------------------------+
| http://www.gimme-th.at/blog |
+-----------------------------+
1 row in set (0.00 sec)

So, the last task is to change the value to the new url.
mysql>update wp_option set option_value=’http://localhost/blog’ where option_name=’siteurl’;

And that’s it.