Montag, 6. Februar 2017
[*]

WordPress-Updates vergessen .htaccess

, 23:31

Nachdem das Social Plugin von Mailchimp, das hier früher so schön die Reaktionen von Facebook und Twitter als Kommentare ins Blog importiert hat, zu funktionieren aufgehört hatte, habe ich mich ein wenig mit IndieWeb beschäftigt. Lange noch nicht tiefgehend genug, aber die Plugins funktionierten erstmal ganz gut und brachten meinem Blog Webmentions bei (wie z.B. hier zu sehen ist).

Doch am vorletzten Wochenende habe ich ein paar Updates installiert (sowohl für WordPress als auch für das Webmentions-Plugin), und am Anfang der letzten Woche kamen dann gar keine Webmentions mehr an. Bei Bridgy fand ich erstmal nur nichtssagende Fehlermeldungen.

Auf meinen frustrierten Tweet meldeten sich aber sofort freundliche Helfer, darunter der Autor des Webmentions-Plugins, und gemeinsam konnten wir der Ursache auf die Spur kommen: tatsächlich hatte Bridgy eine ordentliche Logdatei, aus der hervorging, dass mein Apache einen Serverfehler 500 zurückgibt:

0.1.0.2 - - [30/Jan/2017:00:42:03 -0800] "POST /_ah/queue/propagate HTTP/1.1" 304 1071 "https://brid.gy/retry" "AppEngine-Google; (+http://code.google.com/appengine)"

2017-01-30 08:42:00.032720 D Params: NestedMultiDict([('response_key', u'aglzfmJy...')])
2017-01-30 08:42:00.937850 I Source: Thomas Renger (Facebook) 10153250416376118, http://brid-gy.appspot.com/facebook/10153250416376118
2017-01-30 08:42:01.030590 I Created by this poll: http://brid-gy.appspot.com/log?start_time=1485727919&key=aglzfmJyaWQtZ3lyIwsSDEZhY2Vib29rUGFnZSIRMTAxNTMyNTA0MTYzNzYxMTgM
2017-01-30 08:42:01.130020 I Starting Response like tag:facebook.com,2013:10155005024956118_liked_by_10153108342655662 https://www.facebook.com/10153250416376118/posts/10155005024956118#liked-by-10153108342655662
2017-01-30 08:42:01.729090 I Webmention from https://brid-gy.appspot.com/like/facebook/10153250416376118/10155005024956118/10153108342655662 to https://dentaku.wazong.de/2017/01/29/digitale-albtraeume-teil-2/
2017-01-30 08:42:01.834260 I Using cached webmention endpoint u'W https dentaku.wazong.de': https://dentaku.wazong.de/wp-json/webmention/1.0/endpoint
2017-01-30 08:42:01.845109 I Sending...
2017-01-30 08:42:02.543940 W Error sending to endpoint: {'body': u'<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">\n<html><head>\n<title>500 Internal Server Error</title>\n</head><body>\n<h1>Internal Server Error</h1>\n<p>The server encountered an internal error or\nmisconfiguration and was unable to complete\nyour request.</p>\n<p>Please contact the server administrator,\n [no address given] and inform them of the time the error occurred,\nand anything you might have done that may have\ncaused the error.</p>\n<p>More information about this error may be available\nin the server error log.</p>\n<hr>\n<address>Apache/2.2.22 (Debian) Server at dentaku.wazong.de Port 80</address>\n</body></html>\n', 'code': '...', 'request': u'POST https://dentaku.wazong.de/wp-json/webmention/1.0/endpoint (with source=https://brid-gy.appspot.com/like/facebook/10153250416376118/10155005024956118/10153108342655662, target=https://dentaku.wazong.de/2017/01/29/digitale-albtraeume-teil-2/)', 'http_status': 500}
2017-01-30 08:42:02.544750 W Propagate task failed

Aber vorher war das doch auch gegangen. Was hatte sich also geändert?

Nun, in der neuen Version war der API-Endpunkt für Webmentions in den Namespace der WordPress-REST-API hinein verlegt (wo er auch logisch hin gehört). Nach einigem Experimentieren fanden wir aber heraus, dass die komplette REST-API auf meinem Server nicht funktionierte — und zwar bei allen Blogs. Im Errorlog sah das dann so aus:

[Mon Jan 30 10:09:56 2017] [error] [client 0.0.0.0] Request exceeded the limit of 10 internal redirects due to probable configuration error. Use 'LimitInternalRecursion' to increase the limit if necessary. Use 'LogLevel debug' to get a backtrace.
[Mon Jan 30 10:09:56 2017] [debug] core.c(3116): [client 0.0.0.0] r->uri = /wp-json/webmention/1.0/endpoint
[Mon Jan 30 10:09:56 2017] [debug] core.c(3122): [client 0.0.0.0] redirected from r->uri = /wp-json/webmention/1.0/endpoint
[Mon Jan 30 10:09:56 2017] [debug] core.c(3122): [client 0.0.0.0] redirected from r->uri = /wp-json/webmention/1.0/endpoint
[Mon Jan 30 10:09:56 2017] [debug] core.c(3122): [client 0.0.0.0] redirected from r->uri = /wp-json/webmention/1.0/endpoint
[Mon Jan 30 10:09:56 2017] [debug] core.c(3122): [client 0.0.0.0] redirected from r->uri = /wp-json/webmention/1.0/endpoint
[Mon Jan 30 10:09:56 2017] [debug] core.c(3122): [client 0.0.0.0] redirected from r->uri = /wp-json/webmention/1.0/endpoint
[Mon Jan 30 10:09:56 2017] [debug] core.c(3122): [client 0.0.0.0] redirected from r->uri = /wp-json/webmention/1.0/endpoint
...

Es brauchte einiges an weiterem Debugging um herauszufinden, was meine Installation von anderen unterschied: meine .htaccess-Datei stammte noch von der ursprünglichen WordPress-µ-2.9-Installation, in die ich die Blogs 2009 umgezogen habe. Die Unterschiede, die sich da über die Jahre ergeben haben, sind bei WordPress auch ordentlich dokumentiert, aber da steht leider nicht, dass mit den älteren Varianten einige neue Funktionen gar nicht … äääh … funktionieren.

Nachdem ich die zentralen Rewrite-Regeln von:

# add a trailing slash to /wp-admin
RewriteCond %{REQUEST_URI} ^.*/wp-admin$
RewriteRule ^(.+)$ $1/ [R=301,L]

RewriteCond %{REQUEST_FILENAME} -f [OR]
RewriteCond %{REQUEST_FILENAME} -d
RewriteRule . - [L]
RewriteRule  ^([_0-9a-zA-Z-]+/)?(wp-.*) $2 [L]
RewriteRule  ^([_0-9a-zA-Z-]+/)?(.*\.php)$ $2 [L]
RewriteRule . index.php [L]

zu:

# add a trailing slash to /wp-admin
RewriteRule ^wp-admin$ wp-admin/ [R=301,L]

RewriteCond %{REQUEST_FILENAME} -f [OR]
RewriteCond %{REQUEST_FILENAME} -d
RewriteRule ^ - [L] 
RewriteRule ^(wp-(content|admin|includes).*) $1 [L] 
RewriteRule ^(.*\.php)$ $1 [L]
RewriteRule . index.php [L] 

„modernisiert“ hatte, funktionierte auch die REST-API. Und schon kamen die Webmentions wieder an.

Also Achtung! Überprüft auch Eure WordPress-Blogs mal, ob die .htaccess-Datei auf dem neuesten Stand ist, denn das Update aktualisiert sie nicht für Euch. Ruft mal ${euerblog}/wp-json/ auf und guckt, ob da ein JSON-String oder eine Fehlermeldung kommt.

Vielen Dank an @pfefferle für die Hilfe beim Debugging.

Mittwoch, 15. April 2015
[*]

08:57  Hmmtja, da der Dienst hinter dem #MailChimp #Social Plugin für #WordPress gerade down zu sein scheint, dann eben von Hand: #
Tags , ,   Kommentare  1

Donnerstag, 19. Juni 2014
[*]

13:55  #WordPress -Plugins, die Dinge nachladen wollen, und #https . Eine immerwährende Mixed Content Warning. #seufz  #
Tags , ,   Kommentare  0

Freitag, 7. Februar 2014
[*]

Today is Pungenday, the 38th day of Chaos in the YOLD 3180

, 23:27

Einer der wazong-Benutzer trug den Feature-Request an mich heran, dass sein Blog die Datumsangaben bitte gemäß Diskordianischem Kalender anzeigen sollte. Das ist eine Funktion, die ich auch länger schon haben wollte, dafür müsste es doch ein Plugin geben — das hier ist schließlich WordPress.

Leider fand ich nur dieses: Discordian Date. Aber das konnte nur das aktuelle Datum in einem Widget darstellen. Na gut, dann musste ich eben selbst ran.

Ich habe mich also zwei Abende hingesetzt, und nun ist Version 0.1 meines kleinen Plugins fertig geworden. Es unterstützt bisher nur die ausgegebenen Daten an Artikeln und Kommentaren, hier zu sehen auf einer Artikelseite:

Screenshot mit Diskordianischen Daten

Um auch die Archivstruktur nach dem Gesetz der Fünf anzuordnen, muss ich noch tiefer in WordPress eingreifen. Das kommt später. Dafür habe ich mir Mühe gegeben, die Implementation so sauber wie möglich in die API einzufügen, damit das Diskordianische Datum genau so wie das Gregorianische Datum mit PHP-Formatstrings formatiert werden kann.

Für spätere Version habe ich noch folgendes auf der „Roadmap“:

  • Implementierung der noch fehlenden Formatstrings (z.B. Wochennummer, zweistelliges Jahr,…)
  • WordPress-Archive nach Diskordianischem Kalender
  • Apostelfeiertage und Monatsfeiertage
  • Sprachunterstützung (die soll abschaltbar werden, denn manche Leute mögen die Übersetzungen der Monate und Wochentage nicht)

Bis dahin Viel Spaß mit ddate Version 0.1!

Donnerstag, 29. August 2013
[*]
[*]
Freitag, 25. Januar 2013
[*]

23:37  Und weg ist die Widget-Area. Langsam verstehe ich die Childtheme-Endwicklung. #WordPress  #
Tags   Kommentare  0

Donnerstag, 15. November 2012
[*]

Serious Drinking

, 17:45

Langsam entwickelt sich Wazong zu einem kleinen Bloghoster. Ich darf Freund R. hier herzlich willkommen heißen, der sich auf der neuen Seite Serious Drinking in Zukunft ebendamit beschäftigen möchte.

Prost!

Montag, 22. Oktober 2012
[*]

#neuesblogfürpercanta

, 15:42

Es hat sich so ergeben, dass ich für @Percanta ein neues Blog aufgesetzt habe (Blogspot zickte irgendwie rum, auf Twitter war Mimimi, ich bot Platz an). Das alte Blog sollte natürlich importiert werden.

Schnell ein Blog zu klicken war natürlich überhaupt kein Problem, der Import ging am Wochenende mit zwei Plugins erstaunlich schnell und einfach, ein paar kosmetische Anpassungen am HTML der Blogeinträge und ein paar Plugins zum Aufhübschen noch, und ich hatte eine Grundlage.

Mit Hilfe von Malte Widenka, der die Domain schon früher mal gesichert hatte, konnte ich heute früh noch die Adresse percanta.de (statt nur percanta.wazong.de) für die Seite aktivieren.

Im Moment sieht es bis auf die Headergrafik noch wie ein frisch aufgesetztes WordPress aus, am Design muss also noch etwas getan werden, es gibt aber schon einen Umzugsartikel. Deshalb wünsche ich der Percanta schon mal viel Spaß und uns mehr zu lesen.

(ich bin dann wieder auf der Baustelle)

Freitag, 12. Oktober 2012
[*]

Twitterpause

, 23:24

Dass Twitter die Richtlinien zur API-Benutzung enger zieht ist ja schon länger bekannt. Da ich aber eigentlich gerade keine Twitterclients entwickle, hatte ich den Zeitplan dieser Abschaltungen bisher nicht im Kopf.

Am Mittwochabend haben aber die Twitter-Tools, und damit die WordPress-Integration aufgehört zu funktionieren. Nun aktualisiert sich also mein Tweetarchiv nicht mehr, und meine in Twitter gekippten Gedanken scrollen vorbei und sind weg.

Es gibt eine komplett neue Version 3.0 der Twitter-Tools, in der die Zugriffe wohl auf in Zukunft noch unterstützte API-Endpunkte umgestellt sind. Die vorherige Version 2.4 hatte ich aber in vielen Punkten an meine persönlichen Bedürfnisse angepasst. Bis das wieder mit meiner Seite funktioniert, könnte etwas Zeit vergehen. Bis dahin versuche ich, Twitterpause zu machen, auch als eine Form des schwachen Protests.

Das ist aber nicht so einfach: mehrfach hatte ich heute bereits den Impuls, einen kurzen Gedanken mitzuteilen.

Entzugserscheinungen.

Freitag, 10. August 2012
[*]

13:12  Spannende Idee in #wmr : ein Plugin für #WordPress , das alte Artikel auch in dem zu der Zeit aktuellen Theme anzeigt. Mal rumspielen…  #
Tags ,   Kommentare  0

Donnerstag, 21. Juni 2012
[*]

22:37  Heute benutze ich übrigens seit 6 Jahren #WordPress für mein Blog (vorher aus historischen Gründen phpWiki). dentaku.wazong.de/2006/06/21/o…-ein-blog/  #
Tags   Kommentare  0

Dienstag, 27. März 2012
[*]

Sonderservice: WordPress um eine Verzeichnisebene nach oben verschieben

, 23:57

Svensonsan bastelt. Irgendwas klappt noch nicht so richtig. Ich habe Hilfe angeboten.

Wir stellen uns also vor, wir hätten ein WordPress (ganz normal, ohne Multisite-Funktion) auf einer Domain im Unterverzeichnis blog liegen. Das soll sich jetzt ändern, das „/blog“ soll aus allen URLs raus, die ganzen existierenden Links und Suchmaschinenergebnisse dürfen dabei aber nicht kaputt gehen. Der folgend beschriebene Weg dürfte der einfachste sein. Er funktioniert aber nur, wenn sich nicht gleichzeitig auch die Permalink-Struktur geändert hat:

Der Anfang liegt in der WordPress-Konfiguration. In der Datenbank oder wp-config.php müssen WP_HOME und WP_SITEURL auf die neue Adresse eingestellt werden. Jetzt funktioniert erstmal nichts mehr.

Als nächstes rücken die Dateien alle um ein Verzeichnis nach oben. Da ist es gut, wenn man Shellzugang zu seinem Webserver hat, denn nur mit ftp wird das beliebig eklig oder zumindest langwierig (abhängig davon, was den Server kann). Also zum Beispiel:

cd /var/www
mv htdocs htdocs.old
mv htdocs.old/blog htdocs

Jetzt funktionieren die neuen URLs aber die alten nicht mehr (dadurch sind wahrscheinlich auch alle Bilder kaputt etc. etc. — das war beabsichtigt, also keine Sorge). Wir legen deshalb in unserem Rootverzeichnis der Domain (im Beispiel /var/www/htdocs) einen neuen Ordner blog an und lassen Apache die Umschreibarbeit machen. In die Datei blog/.htaccess schreiben wir:

<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule ^(.*)$ http://www.example.com/$1 [R=301,L]
</IfModule>

Dadurch werden alle angeforderten Dateien unterhalb von „/blog“ auf dieselbe Adresse ohne „/blog“ umgeleitet. Schon sollte alles wieder funktionieren. Jedenfalls habe ich so den Umzug von WordPress in einem Verzeichnis auf WordPress µ für die ganze Domain geschafft.

(Übung für Fortgeschrittene mit genug Adminrechten: den Ordner blog muss man nicht unbedingt im WordPress-Verzeichnis anlegen, er kann auch durch die Apache-Konfiguration von anderer Stelle eingeblendet werden.)

Montag, 12. März 2012
[*]

Plugin: Automatic Hashtags

, 14:46

Ich habe mir mal wieder ein kleines WordPress-Plugin geschrieben. Es fügt im Postinhalt gefundene Hashtags zu den Posttags von WordPress hinzu. Man schreibt also #Hashtag, und es wird das Tag Hashtag an den Artikel gehängt.

Wozu soll das gut sein? Es soll mit den üblichen Twitter-Plugins zusammenarbeiten. Leider klappt das ausgerechnet mit dem beliebten Twitter Tools nicht. Das setzt nämlich die Tags im letzten Moment vor dem Speichern noch einmal auf seine Liste. Ändert man aber in twitter-tools/twitter-tools.php in der Funktion do_tweet_post ungefähr in Zeile 515 wp_set_post_tags in wp_add_post_tags ändert, dann klappt’s:

function do_tweet_post($tweet) {
    global $wpdb;
    global $aktt;
    remove_action('publish_post', 'aktt_notify_twitter', 99);

[...]

    $post_id = wp_insert_post($data);
    add_post_meta($post_id, 'aktt_twitter_id', $tweet->tw_id, true);
    wp_add_post_tags($post_id, $this->blog_post_tags);
    add_action('publish_post', 'aktt_notify_twitter', 99);
}

In Zukunft sind hier also die Microblog-Einträge besser in die Taxonomie eingebunden.

Falls jemand das Plugin gebrauchen kann (es ist aber wirklich nur ein Zehnzeiler), kann es hier runtergeladen werden.

Dienstag, 19. Juli 2011
[*]

Mein Speed-Setup, Teil2: Cache und PURGE

, 23:08

In Teil 1 haben wir Varnish (und Pound) vor WordPress gestellt. Das ergibt erstmal nur eine geringe Beschleunigung. Im Folgenden sehen wir uns an warum — und wie es besser geht:

WordPress hält sich selbst (und das nicht ganz zu unrecht) für eine dynamische Webseite. Alle von WordPress ausgelieferten Seiten enthalten daher Hinweise an den Empfänger, die Seite doch bitte auf keinen Fall zwischenzuspeichern:

Normalerweise hält sich Varnish daran und traut sich außerdem auch nicht an die Zwischenspeicherung von Seiten, die mit gesetztem Cookie angefordert wurden (schließlich könnte am Cookie ja eine Benutzersitzung mit Einkaufskorb oder ähnlichem dranhängen).

Wir müssen Varnish also unsere eigenen Vorstellungen davon aufdrängen, wie lange die Cacheobjekte ihre Gültigkeit behalten sollen, und welche Bereiche der Seite tatsächlich mit angemeldeten Benutzern arbeiten.

mehr…

Samstag, 18. Juni 2011
[*]

Mein Speed-Setup, Teil1: https

, 19:08

Vor einiger Zeit hatte ich mal mit der Beschleunigung dieses Blogs (und der anderen wazong-Seiten) beschäftigt. Dabei hatte ich mit Varnish schnell mittelgute Ergebnisse bekommen, es waren aber einige Fragen offengeblieben. Für einen Teil habe ich inzwischen Lösungen gefunden, bei anderen bastle ich noch.

Da war zuerst das access.log, in dem nur noch Zugriffe von 127.0.0.1 verzeichnet wurden. Dafür gibt es ein Apache-Modul, das den verbindenden Client durch den Inhalt des „X-Forwarded-For:“-Headers ersetzt (wo der herkommt, dazu später mehr). Debian hat’s praktischerweise als fertiges Paket herumliegen, so dass man das Problem mit:

apt-get install libapache2-mod-rpaf
cd /etc/apache2/mods-enabled
ln -s ../mods-available/rpaf.* .

erledigt hat.

Das https-Caching ist mit WordPress als Backend komplizierter; da WordPress viel mit vollständigen (auch selbst erzeugten) URLs arbeitet, wird man beim einfachen Ansatz (also einen TLS-Offloader vor den Proxy-Cache setzen) ständig auf die unsichere Verbindung umgeleitet. Die eine Seite wird also wirklich über die verschlüsselte Verbindung geladen, alle Bilder und StyleSheets aber schon wieder unverschlüsselt, und die Links auf des Seite führen auch alle zur unverschlüsselten Version.

Mein erster Ansatz war, nginx die TLS-Verarbeitung durchführen zu lassen (das ging gut damit) , und Links auf http://dentaku.wazong.de/ automatisch zu https://dentaku.wazong.de/ umschreiben zu lassen. Leider ist das nicht die einzige Domain, die auf diesem Server wohnt, und das zuerst geeignet erscheinende HttpSubModule kann leider keine regulären Ausdrücke verarbeiten und ist auch auf eine Ersetzungs pro Virtual Host beschränkt. Ich ließ also nginx wieder nginx sein (wer will schon einen kompletten Webserver vor einem anderen Webserver haben?) und kehrte zu einem zweiten Versuch mit Pound zurück.

In den folgenden Artikeln erkläre ich also ein Setup, das etwa so aussieht:

mehr…

Mittwoch, 9. Februar 2011
[*]

Firnis (oder: Das muss schneller gehen!)

, 21:55

Vor einiger Zeit (oh, ist ja auch schon wieder ein Jahr her) hat mich bei Martin Thielecke ein Artikel aufgeschreckt. Seitdem steht Webserver-Tuning auf meiner ToDo-Liste (die ist geduldig). Nachdem auch Google sagt, dass meine Webseite langsam ist:

(ok, die scheinen das auch nur mal im letzten Mai gemessen zu haben), musste da jetzt echt mal was passieren. Das soll hier also alles ein wenig schneller (und belastbarer) werden. Als ersten Schritt habe ich nach etwas Einleserei vor meinen Apache jetzt einen Varnish-Cache gestellt. Der läuft im Moment noch mit Standardeinstellungen, was ein paar Nachteile hat:

  1. Die Cache-Hit-Rate ist eigentlich miserabel: WordPress liefert seine Seiten mit minimaler Lebenszeit aus und setzt auch sehr gern Cookies. Beides verhindert bei normaler Konfiguration eine Zwischenspeicherung im Cache. Varnish lässt sich aber sehr fein einstellen, da sollte sich noch einiges machen lassen.
  2. Die Apache-Accesslogs sehen eher eigenartig aus: alle Anfragen kommen im Moment von 127.0.0.1, aber auch das sollte mit Konfiguration wieder in den Griff zu bekommen sein.
  3. https ist noch nicht beschleunigt, weil Varnish kein TLS spricht. Da habe ich schon ein wenig herumexperimentiert mit Pound, aber damit kommt die Information, dass über https zugegriffen wird, nicht bei WordPress an, so dass alle ausgegebenen Links (auch die zu StyleSheets und Bildern des Themes) wieder auf die unverschlüsselte Variante zeigen. Da weder Varnish noch Pound die Links im Vorübergehen umschreiben können, muss ich mir da was anderes einfallen lassen (ich lese gerade ein wenig über nginx, damit könnte das gehen).

Wenn ich eine gangbare Konfiguration gebastelt habe, dann schreibe ich mal eine Anleitung (wenn Euch hier umgekehrt irgendwas auffällt, das nicht richtig funktioniert, dann beschwert Euch).

Montag, 15. Februar 2010
[*]

Quad-Damage, reloaded

, 11:48

Viel älter als dieses Blog und sogar noch etwas älter als die Domain wazong.de ist quad-damage.de. Quad Damage gehört ta und seinen Brüdern ca und ja. In einem selbstgeschriebenen CMS entstanden dort ab Dezember 1999 mit der Zeit 44 Artikel über Computerspiele, Witze und Zeug. Außerdem gab es ein „Gästebuch“, das im November 2000 sogar lernte, Antworten hierarchisch darzustellen.

Quad Damage lebte zuerst auf einem Root-Server bei Strato, aber das war wohl nicht so der Hit. ta war zu der Zeit mein Kollege, und wir legten deshalb ein wenig Hardware zusammen und bastelten uns im Serverraum unseres Arbeitgebers so eine Art Rootserver. Später zog der komplette Inhalt dieses Servers zu Hetzner um, deshalb hat Wazong einen älteren Untermieter.

Lange Zeit tat sich dann nichts mehr, und irgendwann, bei einer Spamaufräumaktion, ging die Kommentarmaske verloren. Der letzte Eintrag im Gästebuch war vom 29. Dezember 2007. Bis dahin hatten sich aber immerhin 5762 Kommentare angesammelt.

Eigentlich fand ich es schon länger zu schade, diese Inhalte einfach brachliegen zu lassen, deshalb habe ich in der letzten Woche mit ein wenig SQL-Magie aus den alten Artikeln WordPress-Artikel und aus dem Gästebuch Kommentare zu einer WordPress(µ)-Seite gemacht. Aus einem der vielen Kubrick-Ableger habe ich ein Theme gebastelt, das sich dem Originaldesign optisch annähert. Die dahinterstehende Layout-Technik sieht natürlich heute ganz anders aus (Frameset und Tabellen gegen CSS-Boxen).

Also, fröhlichen Neustart!

[*]

08:12  Mist, die Spammer kommen jetzt am #NoSpamNX vorbei (6mal in dieser Nacht). Muss mir was anderes einfallen lassen. #
Tags ,   Kommentare  Kommentare deaktiviert für Mist, die Spammer kommen jetzt…

Donnerstag, 7. Januar 2010
[*]

WordPress, MySQL und unechtes UTF-8

, 22:20

Schonmal eine WordPress-Installation auf eine neue MySQL-Version umgezogen? Gerade wenn man von Version 4.x auf Version 5.x wechselt, dann stehen anschließend oft in den alten Artikeln Worte wie „heißt“ oder „größere“. Das liegt daran, dass WordPress irgendwann in der Vergangenheit (war das Version 2.3?) seine Datenhaltung auf UTF-8 umgestellt hat, ältere MySQL-Versionen aber noch keine saubere Zeichensatzunterstützung auf Tabellen- und Feldebene boten. Will man das reparieren, so muss man der Datenbank „verraten“, mit welcher Zeichencodierung die Daten in den Tabellenspalten gespeichert sind. Dazu habe ich das folgende Skript geschrieben, das von allen betroffenen Feldern die Zeichencodierung erst entfernt, um sie dann korrekt zu setzen:

alter table wp_comments change comment_author comment_author tinyblob;
alter table wp_comments change comment_author comment_author tinytext
            character set utf8;
alter table wp_comments change comment_content comment_content blob;
alter table wp_comments change comment_content comment_content text
            character set utf8;
alter table wp_links change link_name link_name varbinary(255);
alter table wp_links change link_name link_name varchar(255) character set utf8;
alter table wp_links change link_description link_description varbinary(255);
alter table wp_links change link_description link_description varchar(255)
            character set utf8;
alter table wp_links change link_notes link_notes mediumblob;
alter table wp_links change link_notes link_notes mediumtext character set utf8;
alter table wp_options change option_value option_value longblob;
alter table wp_options change option_value option_value longtext character set utf8;
alter table wp_posts change post_content post_content longblob;
alter table wp_posts change post_content post_content longtext character set utf8;
alter table wp_posts change post_title post_title blob;
alter table wp_posts change post_title post_title text character set utf8;
alter table wp_posts change post_excerpt post_excerpt blob;
alter table wp_posts change post_excerpt post_excerpt text character set utf8;
alter table wp_posts change post_content_filtered post_content_filtered blob;
alter table wp_posts change post_content_filtered post_content_filtered text
            character set utf8;
alter table wp_term_taxonomy change description description longblob;
alter table wp_term_taxonomy change description description longtext
            character set utf8;
alter table wp_terms change name name varbinary(200);
alter table wp_terms change name name varchar(200) character set utf8;
alter table wp_usermeta change meta_value meta_value longblob;
alter table wp_usermeta change meta_value meta_value longtext character set utf8;

Vielleicht hilft es ja jemandem…

Donnerstag, 10. Dezember 2009
[*]

Sonderservice: WP-Plugin-Bugfix

, 00:29

Da habe ich mich mal wieder aus dem Fenster gelehnt und behauptet:

“wpcontact form kann keine umlaute.” kann man aber reparieren.

Nunja, schließlich verdiene ich mein Geld als Softwareentwickler. Da muss man sowas schon hinbekommen. Hier also, extra für Caschy, eine Version von WP Contact Form, die mit Umlauten zurechtkommt.

wp-contact-form.1.5.1.1+wazong.zip

Das ist natürlich schnell zusammengehackt, und deshalb gelten ein paar Randbedingungen:

  • Der Mailserver muss 8bit-clean sein. Das sollte auf modernen Installationen kein Problem darstellen, aber ich sag’s lieber mal.
  • Ich habe nur mit UTF-8 als Blogzeichensatz getestet. Es sollte auch mit anderen Zeichensätzen gehen, aber wer weiß…

Ansonsten: viel Spaß.

To the original developers: your plugin didn’t cope too well with accented characters (that happen to be common in German words). I patched a few things in wp-contactform.php to add Quoted-Printable-encoding to some header fields and removed input sanitization that I thought was over-done. Feel free to incorporate some or all changes into future versions.

 1 2 3 »