WeizenSpr.eu » Aufbau

Hetzner und SSL: Was lange währt…

Mea Culpa — Wed, 26 May 2010 22:03:54 +0000

In den letzten Tagen habe ich viel über den Hoster Hetzner geschimpft. Mehrfach wurde mir von deren Support mitgeteilt, dass einige Mehrkosten auf mich zukommen würden, wenn ich für alle meine Domains SSL einrichten lassen würde. Nicht nur das! Auch für die SSL-Einrichtung für Subdomains sollte ich zahlen, sobald diese nicht auf ein gemeinsames Document Root verweisen. Schlussendlich hatte ich mir eine Lösung überlegt, mit der ich zumindest die Kosten für die Subdomains einsparen könnte.

Nun hatte ich natürlich langsam die Nase voll und wollte endlich sehen, ob die Arbeit irgendetwas genützt hat. Also habe ich gestern SSL für eine meiner Domains einrichten lassen und das fertige Setup heute getestet.
Was soll ich sagen? Die Subdomains werden korrekt geschützt, wenn sie, wie beschrieben, im gleichen Document Root liegen, wie die eigentliche Domain. Mein gezeigter Trick mit der “.htaccess”-Datei funktioniert also problemlos.
Es gibt aber noch etwas viel besseres! Solange die Addon-Domains auf das gleiche Rootverzeichnis zeigen, wie die SSL-konfigurierte Domain, werden auch diese mit dem eingespielten Zertfikat versorgt ! Das nenne ich einen Jackpot ! Genau so möchte ich es seit Tagen haben!
Die Domains kann man übrigens über den gleichen Weg behandeln, wie es auch mit den Subdomains gemacht wurde – einfach per “.htaccess”-Datei das tatsächliche Verzeichnis zuordnen. Das klappt wunderbar!

Eine Sache muss man übrigens erledigen, sobald SSL eingerichtet worden ist – nämlich den DNS-Server so konfigurieren, dass die Domains auf die neue IP-Adresse zeigen, für die SSL konfiguriert worden ist. Bei der DNS-Konfiguration heißt das, dass man die IP für den Eintrag “@” und “www” korrekt setzen muss.

Hetzner - Erweiterte DNS-Konfiguration

Ich habe euch auf dem Bild übrigens gleich noch eine weitere Zeile markiert, die ihr – je nach Belieben – zur DNS-Konfiguration hinzufügen könnt. Diese lautet:

1	* IN CNAME www

Die Bedeutung ist schnell erklärt: Jede Subdomain, für kein separater Eintrag existiert, wird auf die IP der www-Subdomain umgelenkt. Dieser Wildcard-Eintrag hat einen riesigen Vorteil: Man muss nicht jedes Mal extra eine neue Subdomain über das Webinterface erstellen, wenn man sie benötigt. Man muss sie einfach nur in der “.htaccess”-Datei berücksichtigen.

Zudem sind mit diesem Wildcard-Eintrag superlustige Sachen möglich ! Ich habe z.B. unter der Domain test.coltishware.net eingerichtet, dass alle darunter liegenden Domänen einfach als Text ausgegeben werden. Probiert z.B. mal mit du.bist.doof.test.coltishware.net aus!

Im ersten Augenblick mag das nicht so sinnvoll sein, aber stellt euch mal vor, ihr wollt eine Community aufbauen, in der jeder Benutzer seine persönliche Internetpräsenz bekommt. Hier müsstet ihr nun nicht mehr manuell die Subdomains einrichten, sondern könnt diese einfach per Script verwalten lassen.

Ich bin ob dieser gestalterischen Freiheit jedenfalls heute das erste Mal froh, mich für Hetzners Level-19-Paket entschieden zu haben. Ich hoffe, dieser ganze SSL-Wahnsinn war das erste und einzige Mal, dass ich solche großen Probleme mit Hetzner hatte. Und apropos SSL: Der Support hat mir versichert, dass der Austausch des Zertifikats (wenn es z.B. mal ablaufen sollte) vollkommen unentgeldlich stattfindet.

Gehetzte Grüße, Kenny

1 Jahr + 1 Tag WeizenSpr.eu

Mea Culpa — Wed, 03 Feb 2010 12:48:51 +0000

Hach, wie ärgerlich! Da kann man schonmal ein Jubiläum feiern und dann verpasst man es auch noch ! Aber das geht mir bei runden Tweetzahlen bei Twitter ja auch nicht anders . Deswegen jetzt mit einem Tag Verspätung: WEIZENSPR.EU IST EIN JAHR ALT GEWORDEN!

In dem einen Jahr ist eine Menge passiert. Wir haben gesehen, wie eine Zensurinfrastruktur aufgebaut werden sollte, ich habe ein paar Projekte realisiert und der Öffentlichkeit zugänglich gemacht, ich habe neue Leute in der Blogosphäre und dem Twitterversum kennenlernt, ich habe mein Studium erfolgreich abgeschlossen und konnte direkt ins Berufsleben einsteigen, ich bin Onkel geworden, ich bin in die Politik eingetreten und – was ich am wenigsten erwartet hätte – ich habe es geschafft, dass WeizenSpr.eu sich noch im Jahr der Entstehung selbst refinanziert hat (mit, wie ich hoffe, unaufdringlichen Werbeformen).

Doch auch im zweiten Jahr von WeizenSpr.eu erwarte ich viele interessante, lustige und schlechte Nachrichten. Derzeit habe ich ein paar Projekte, über die ich gerne noch schreiben möchte (z.B. wartet PESD seit fast einem halben Jahr auf seine Veröffentlichung). Doch auch was meinen Alltag angeht, werden noch einige Dinge kommen: So werde ich z.B. im Sommer umziehen, was sicherlich wieder Fragen aufwerfen und neues zutage fördern wird. Man darf also gespannt sein, was da noch kommen wird.

Wie habt ihr WeizenSpr.eu bisher erlebt? Was gefällt euch am Blog und was könnte man besser machen? Mögt ihr diesen Mix aus Privatem, Politik und Informatik oder seid ihr eher auf der Suche nach einem typischen Nischenblog?

Nachträgliche Grüße, Kenny

WeizenSpr.eu mit neuem Design!

Mea Culpa — Sat, 16 Jan 2010 17:31:33 +0000

Es ist vollbracht ! WeizenSpr.eu erblüht im tiefsten Winter mit einem neuen Design. Im Einsatz ist nun das geniale Mainstream-Theme von WooThemes. Diese Gruppe veröffentlicht normalerweise kommerzielle WordPress-Themes, bietet aber hier und da auch ein paar kostenlose an !

Über die Änderungen, die ich vorgenommen habe, damit Mainstream so aussieht und funktioniert, wie es das hier tut, werde ich den nächsten Tagen schreiben. Hier und da haben sich nämlich ein paar Bugs eingeschlichen, die man erstmal beseitigen muss, damit das Theme ordentlich arbeitet.
Ich würde mich übrigens sehr über Feedback zum neuen Design freuen. Nette Worte sind gern gesehen, aber vor allem die Kritik würde mich interessieren. Das heißt: Wenn etwas falsch angezeigt wird, etwas von früher fehlt oder etwas schlecht aussieht – sagt einfach Bescheid! Ich gucke mir das ganze dann an.

Zwei Sachen habe ich übrigens selbst schon auf dem Schirm:

Das WeizenSpr.eu-Logo muss verbessert werden. Der Kontrast zum Weizenfeld im Hintergrund ist zu gering.
Viele Elemente haben derzeit englische Beschriftungen. Ich muss mich also ransetzen und die Language-Datei des Blogs ins Deutsche übersetzen.

Falls euch übrigens das alte Design fehlen sollte: Dank meinem WordPress-Plugin SelTheme habt ihr jederzeit die Möglichkeit, zum alten Design zurück zu kehren . Folgende Möglichkeiten stehen euch zur Verfügung:

WeizenSpr.eu?theme= für das aktuelle WeizenSpr.eu-Design
WeizenSpr.eu?theme=kubrick für das alte WeizenSpr.eu-Design
WeizenSpr.eu?theme=classic für das uralte WordPress-Design

Und nun viel Spaß mit dem neuen alten WeizenSpr.eu!

Mainstreamige Grüße, Kenny

WordPress-Trash ohne automatische Leerung

Mea Culpa — Tue, 05 Jan 2010 15:26:17 +0000

Wie ihr evtl. schon mitbekommen habt, enthält WordPress seit der Version 2.9 einen Papierkorb, in den “gelöschte” Artikel und Kommentare verschoben werden. Einträge, die im Papierkorb liegen, werden standardmäßig nach 30 Tagen gelöscht.

Die Anzahl der Tage, nach denen der Papierkorb geleert werden soll, kann mit Hilfe des Wertes EMPTY_TRASH_DAYS in der Datei wp-config.php beeinflusst werden. Der Wert “0″ bedeutet in dem Fall, dass der Papierkorb komplett deaktiviert wird (wer den Papierkorb deaktiviert hat, sollte sich übrigens unbedingt WordPress 2.9.1 ansehen).

Ich persönlich finde den Papierkorb toll, mag es aber nicht, wenn Dinge von mir automatisch gelöscht werden. Deshalb habe ich mich durch den Quelltext der 2.9.1er Version gehangelt und geguckt, was zu tun ist, um dem ganzen Abhilfe zu schaffen. Glücklicherweise wird fast überall auf “EMPTY_TRASH_DAYS” bzw. “!EMPTY_TRASH_DAYS” geprüft, sodass nur wenige Änderungen nötig sind.

Fangen wir mit der ersten an. In der Datei wp-includes/post.php finden wir in der Zeile 1178 eine Abfrage, die überprüft, ob statt wp_delete_post() (wo wir uns gerade befinden) nicht lieber wp_trash_post() aufgerufen werden sollte:

1	if ( !$force_delete && ( $post->post_type == 'post' \|\| $post->post_type == 'page') && get_post_status( $postid ) != 'trash' && EMPTY_TRASH_DAYS > 0 )

Diese ändern wir nun so ab, dass sie dann wahr ist, sobald EMPTY_TRASH_DAYS gleich true ist – wir unterscheiden also nicht mehr zwischen positiven und negativen Werten:

1	if ( !$force_delete && ( $post->post_type == 'post' \|\| $post->post_type == 'page') && get_post_status( $postid ) != 'trash' && EMPTY_TRASH_DAYS )

Eine ganz ähnliche Zeile gibt es auch in der Datei wp-includes/comment.php. Dort wird in Zeile 821 geprüft, ob statt wp_delete_comment() nicht lieber wp_trash_comment() aufgerufen werden sollte:

1	if (wp_get_comment_status($comment_id) != 'trash' && wp_get_comment_status($comment_id) != 'spam' && EMPTY_TRASH_DAYS > 0)

Auch diese ändern wir so ab, dass das Vorzeichen des Wertes EMPTY_TRASH_DAYS egal ist:

1	if (wp_get_comment_status($comment_id) != 'trash' && wp_get_comment_status($comment_id) != 'spam' && EMPTY_TRASH_DAYS )

Nun kommt noch eine Änderung in der Datei wp-includes/functions.php an die Reihe. In dieser beginnt ab Zeile 3531 die Funktion wp_scheduled_delete(). Diese ist dafür zuständig, dass nach der Anzahl der Tage, die in EMPTY_TRASH_DAYS angegeben ist, die entsprechenden Einträge im Papierkorb gelöscht werden. Dies können wir dadurch verhindern, indem wir gleich ganz am Anfang der Funktion folgenden Quelltext einfügen:

1	if (EMPTY_TRASH_DAYS < 0) { return; }

Damit sorgen wir dafür, dass die Funktion garnicht erst durchlaufen wird, wenn der Wert in EMPTY_TRASH_DAYS kleiner Null ist.

Der Wert EMPTY_TRASH_DAYS muss jetzt nur noch in der Datei wp-config.php entsprechend gesetzt werden:

1	define("EMPTY_TRASH_DAYS", -1);

Herzlichen Glückwunsch! Du hast gerade dein WordPress 2.9.1 so abgeändert, dass dein Papierkorb aktiv ist, dieser jedoch nicht nach einer bestimmten Anzahl an Tagen einfach geleert wird !
Ich hoffe, du wirst mit dieser Änderung genauso viel Spaß haben, wie ich.

Alles neu macht das neue Jahr I

Mea Culpa — Mon, 04 Jan 2010 03:46:17 +0000

Habt ihr etwa nichts davon gemerkt? Umso besser ! Das bedeutet, dass alle wichtigen Funktionen wieder an Ort und Stelle sind .

Ich habe mich nämlich erdreistet, in der Nacht spontan den Blog von WordPress 2.7.1 auf WordPress 2.9 zu hieven und bin im Moment noch erstaunt, wie reibungslos das funktioniert hat !
Dabei muss ich gestehen, dass ich den harten Weg gegangen bin: Im alten Blog alle Artikel, Seiten und Kommentare exportiert und in den neuen Blog importiert. Nunja, fast. Denn vorher musste ich die Exportdatei in mehrere aufteilen, um sie importieren zu können. Die war nämlich zu groß, um sie in den Blog hochzuladen .
Zwischendurch hatte ich noch ein paar kleinere Problemchen mit der Zeichenkodierung (nach einem Umlaut war der restliche Artikeltext weg) und mit einem störrischen Plugin (WP Security Scan hat den Umzug nicht überlebt).

Ich habe noch nicht alle Plugins wieder in Betrieb genommen, aber ich denke, das hole ich in den nächsten Tagen nach . Und dann ist WeizenSpr.eu endlich wieder state-of-the-art ! Apropos: Seit dem Upgrade funktioniert auch das Plugin WP Ajax Edit Comments wieder. Ihr könnt also nach langer Zeit endlich wieder eure Kommentare korrigieren, falls ihr euch verschrieben haben solltet .

Und da wir gerade bei neu sind: Nachdem er zuerst bei den Blogflöten mitgemacht hatte (die zur Zeit eine Pause einlegen), hat JHB nun seinen ersten eigenen Blog gestartet: WaitFor.It
So, wie ich sein Geschreibsel kenne, kann es nicht schaden, seinen Feed zu abonnieren. Ich habe ihn jedenfalls schon geadded .

Neue Grüße, Kenny

[Update] WordPress mit mehreren Datenbank-Zugängen

Mea Culpa — Fri, 25 Dec 2009 14:31:23 +0000

Da ich in letzter Zeit einige Probleme mit dem MySQL-Servers meines Hosting-Anbieters habe, habe ich überlegt, was für Alternativen ich habe. Jedes Mal, wenn der Server in die Knie geht, sind alle meine Webseiten nicht erreichbar: Vor allem bei diesem Blog ist das sehr ärgerlich, die Ausfälle der anderen Seiten kann ich noch verschmerzen.

Also habe ich mich mal drangesetzt, den WordPress-Quelltext analysiert und mir eine Lösung einfallen lassen. Um diese einzusetzen, müssen ein paar Modifikationen am Kern von WordPress vorgenommen werden. Die gezeigten Quelltextausschnitte und Zeilennummern beziehen sich auf WordPress 2.7.1.
Mit den Änderungen ist es übrigens gleichzeitig möglich, WordPress via SSL mit der MySQL-Datenbank sprechen zu lassen.

Fangen wir mit den Änderungen an der Datei wp-config.php an – diese enthält unter anderem sämtliche Informationen, die WordPress benötigt, um sich zur Datenbank zu verbinden. Normalerweise sieht die Konfiguration der Datenbank in etwa so aus:

1
2
3
4
5
6
7

// ** MySQL Einstellungen ** //
define('DB_NAME', 'DATENBANKNAME'); // Der Name der Datenbank, die du benutzt.
define('DB_USER', 'BENUTZERNAME'); // Dein MySQL-Datenbank-Benutzername.
define('DB_PASSWORD', 'PASSWORT'); // Dein MySQL-Passwort.
define('DB_HOST', 'SERVER'); // In 99% der Fälle musst du hier nichts ändern.
define('DB_CHARSET', 'CHARSET');
define('DB_COLLATE', '');

Das ganze erweitern wir nun ein bisschen, damit wir die Daten von mehreren verschiedenen Datenbankservern angeben können. Hierfür schreiben wir alle Daten jeweils in ein Array. Jedes Array sollte gleichviele Einträge haben, wobei alle Einträge mit einem bestimmten Index zusammengehörig sind:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21

// ** MySQL Einstellungen ** //
define('CLIENT_SSL', 2048); // Wert für Konstante CLIENT_SSL
// define('ENABLE_DB_SELECT', 'true'); // Einkommentieren, um manuelle Wahl der Datenbank zu aktivieren

$wpdbname = array('DATENBANKNAME1', 'DATENBANKNAME2'); // Der Name der Datenbank, die du benutzt.
$wpdbuser = array('BENUTZERNAME1', 'BENUTZERNAME2'); // Dein MySQL-Datenbank-Benutzername.
$wpdbpassword = array('PASSWORT1', 'PASSWORT2'); // Dein MySQL-Passwort.
$wpdbhost = array('SERVER1', 'SERVER2'); // In 99% der Fälle musst du hier nichts ändern.
$wpdbssl = array('SSL1', 'SSL2'); // Verbindung via SSL => 'true'
$wpdbtimeout = array(60, 60); // Verbindungstimeout in Sekunden
$wpdbcharset = array('CHARSET1', 'CHARSET2');
$wpdbcollate = array('', '');

define('DB_NAME', serialize($wpdbname));
define('DB_USER', serialize($wpdbuser));
define('DB_PASSWORD', serialize($wpdbpassword));
define('DB_HOST', serialize($wpdbhost));
define('DB_SSL', serialize($wpdbssl));
// define('DB_TIMEOUT', serialize($wpdbtimeout)); // Einkommentieren, um Timeout-Konfiguration zu aktivieren
define('DB_CHARSET', serialize($wpdbcharset));
define('DB_COLLATE', serialize($wpdbcollate));

Ich hoffe, jemandem ist die neue Variable $wpdbssl und der neue definierte Wert DB_SSL aufgefallen. Über diese ist es später möglich, WordPress dazu zu bewegen, sich via SSL mit der Datenbank zu verbinden – wenn sie denn entsprechend konfiguriert ist. Der Wert ‘false’ bedeutet, dass SSL deaktiviert ist – jeder andere Wert aktiviert die SSL-Verbindung.

Nachdem die Konfiguration fertig ist, müssen wir nun an WordPress selber herumschrauben. Dazu müssen wir die Datei wp-includes/wp-db.php bearbeiten. In dieser wird die initiale Datenbankverbindung hergestellt.

In der Funktion __construct() befindet sich ab Zeile 312 folgender Quelltext:

1
2
3
4
5
6
7

if ( defined('DB_CHARSET') )
$this->charset = DB_CHARSET;

if ( defined('DB_COLLATE') )
$this->collate = DB_COLLATE;

$this->dbh = @mysql_connect($dbhost, $dbuser, $dbpassword, true);

Diesen ersetzen wir nun durch folgenden Quelltext. Dieser ist für die Verarbeitung der Arrays zuständig – es werden nacheinander alle Konfigurationen durchprobiert, bis eine Verbindung zu eine der MySQL-Datenbanken hergestellt werden kann. Dabei wird auch berücksichtigt, dass es ja mal passieren kann, dass nicht alle Konfigurations-Arrays gleich lang sind; ebenso wird SSL berücksichtigt und der Timeout der Verbindung gesetzt, falls nötig:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100

// which database to select
$selectedName = '';

// get array values
$dbuser = unserialize($dbuser);
$dbpassword = unserialize($dbpassword);
$dbname = unserialize($dbname);
$dbhost = unserialize($dbhost);

$dbssl = null;
if ( defined('DB_SSL') ) {
$dbssl = unserialize(DB_SSL);
}
$dbtimeout = null;
if ( defined('DB_TIMEOUT') ) {
$dbtimeout = unserialize(DB_TIMEOUT);
}
$dbcharset = null;
if ( defined('DB_CHARSET') ) {
$dbcharset = unserialize(DB_CHARSET);
}
$dbcollate = null;
if ( defined('DB_COLLATE') ) {
$dbcollate = unserialize(DB_COLLATE);
}

$this->dbh = false;

// get number of available complete config sets
$minCount = count($dbuser);
if (count($dbpassword) < $minCount) { $minCount = count($dbpassword); }
if (count($dbname) < $minCount) { $minCount = count($dbname); }
if (count($dbhost) < $minCount) { $minCount = count($dbhost); }
if ($dbssl != null) { if (count($dbssl) < $minCount) { $minCount = count($dbssl); } }
if ($dbtimeout != null) { if (count($dbtimeout) < $minCount) { $minCount = count($dbtimeout); } }
if ($dbcharset != null) { if (count($dbcharset) < $minCount) { $minCount = count($dbcharset); } }
if ($dbcollate != null) { if (count($dbcollate) < $minCount) { $minCount = count($dbcollate); } }

// find first working config set
if ($minCount > 0) {
$index = 0;

// allow manual selection of used config set
if (defined('ENABLE_DB_SELECT')) {
if (ENABLE_DB_SELECT == 'true') {
$dbid = null;
if (isset($_GET['dbid'])) {
$dbid = $_GET['dbid'];
} else {
if (isset($_COOKIE['dbid'])) {
$dbid = $_COOKIE['dbid'];
}
}

if ($dbid != null) {
if (isset($_SERVER['HTTP_HOST'])) {
$domain = $_SERVER['HTTP_HOST'];
} else {
$domain = $_SERVER['SERVER_NAME'];
}

if ((strlen(trim($dbid)) > 0) && (is_numeric($dbid))) {
$dbid = intval($dbid);

if ($minCount > $dbid) {
$index = $dbid;
$minCount = $dbid + 1;
}

setcookie('dbid', $dbid, time() + 300000, '/', $domain);
} else {
setcookie('dbid', '', time(), '/', $domain);
}
}
}
}

do {
$selectedName = $dbname[$index];

if ($dbtimeout != null) {
ini_set('mysql.connect_timeout', $dbtimeout[$index]); // set connect timeout
}

if (($dbssl != null) && ($dbssl[$index] == 'true')) {
$this->dbh = @mysql_connect($dbhost[$index], $dbuser[$index], $dbpassword[$index], true, CLIENT_SSL);
} else {
$this->dbh = @mysql_connect($dbhost[$index], $dbuser[$index], $dbpassword[$index], true);
}

if ($dbcharset != null) {
$this->charset = $dbcharset[$index];
}
if ($dbcollate != null) {
$this->collate = $dbcollate[$index];
}

$index++;
} while ((!$this->dbh) && ($index < $minCount));
}

Nun folgt nur noch eine kleine Änderung in der Zeile 435. Dort müssen wir dafür sorgen, dass die richtige Datenbank ausgewählt. Das bisherige…

1	$this->select($dbname);

…ersetzen wir schnell durch die neue Version:

1	$this->select($selectedName);

Herzlichen Glückwunsch! Wenn du alles richtig gemacht hast, sollte dein WordPress nun in der Lage sein, sich via SSL zu einer Datenbank zu verbinden und obendrein auch noch die Fähigkeit besitzen, sich zu einer Ersatzdatenbank zu verbinden, falls die erste(n) Datenbank(en) nicht erreichbar sind!

Für Tipps, Ideen und Anregungen bin ich jederzeit offen . Die Idee, die Arrays serialisiert zu übergeben, habe ich übrigens bei PHP.net gefunden ! Die Definition der Konstante CLIENT_SSL stammt ebenfalls von dort.

Und nicht vergessen: Ich hafte nicht für Schäden an Software, Hardware oder für Vermögensschäden, die durch Anwendung dieser Änderungen entstanden sind oder entstehen könnten.

Update:
Es gibt da noch eine kleine Ergänzung, die ich gerne noch loswerden möchte. Zuerst einmal ist es durchaus möglich, den Quelltext so zu erweitern, dass unterschiedliche Anfragen an verschiedene Datenbanken weitergereicht werden – dadurch ist es möglich Load-Balancing zu implementieren.
Auf der anderen Seite gibt es jedoch auch ein Problem: Man muss es hinkriegen, die verschiedenen Datenbanken möglichst synchron zu halten. Es wäre ärgerlich, wenn ein Artikel in einer Datenbank erstellt wird, dieser aber in der anderen nicht zu sehen ist. Genauso problematisch sind Kommentare und Trackbacks, da diese schnell verloren gehen könnten. Eine funktionierende Synchronisation muss ich deshalb erst noch erstellen. Derzeit gebe ich mich damit zufrieden, dass nur bei der Aktivität einer Datenbank kommentiert werden kann, während dies bei der anderen Datenbank deaktiviert ist.

Update:
Ich habe noch einmal den gesamten Quelltext überarbeitet und dabei einige Änderungen überflüssig gemacht. Nun muss nur noch die Funktion __construct() in der Datei wp-db.php bearbeitet werden.

Mehrfache Grüße, Kenny

Eintrittskarten am Fahrkartenautomaten

Mea Culpa — Thu, 17 Dec 2009 06:53:19 +0000

Ich hatte es bereits vor einigen Wochen im Infoblatt der BVG gelesen, doch jetzt habe ich einfach mal geguckt, wie das ganze in natura aussieht.

Eintrittkarten am Fahrkartenautomaten

Seit neustem ist es möglich, an den Fahrkartenautomaten der BVG Eintrittskarten für einige wenige berliner Attraktionen wie Madam Tussaud’s, dem Aquadome oder dem Legoland zu erwerben. Wie es scheint, handelt es sich bisher nur um Eintrittskarten, bei denen keine Reservierung notwendig ist.

Ich persönlich finde die Idee hinter dem ganzen recht gut, spart man sich doch das Anstehen an der Kasse. Wirklich toll würde die Lösung dann werden, wenn eine Anbindung an eventim möglich wäre, denn dann könnte man am Automaten sogar kompliziertere Buchungen mit Reservierung vornehmen. Das wäre dann ein riesiger Mehrwert, wenn man bereits unterwegs ist und vorher noch schnell ein Ticket ergattern will.

Gibt es solch ein Automaten-Ticketsystem auch in anderen Städten? Ist es dort möglich auch Sitzplatzreservierungen vorzunehmen? Habt ihr solch ein Angebot schon einmal genutzt?

Eintretende Grüße, Kenny

Der Kalender hängt!

Mea Culpa — Mon, 14 Dec 2009 19:54:22 +0000

Seit dem 08.12.2009 ist die Twitter-Kalender-Aktion von Druckerei.de beendet. Statt der versprochenenen drei Kalender haben ganze zehn Kalender den Weg zu mir nach Hause gefunden!

Twitter-Kalender

Heute habe ich nun den ersten Kalender bei mir auf Arbeit im Zimmer aufgehängt. Damit sehen die grauen Wände doch gleich wesentlich wohnlicher aus!
Und damit der Kalender auch eine praktische Aufgabe hat, habe ich auch direkt meine Urlaubstage eingetragen. So kann ich die Tage zählen, bis ich endlich wieder ausspannen kann.

Hängende Grüße, Kenny

Datenbankfehler in WordPress: db-error.php

Mea Culpa — Wed, 09 Dec 2009 13:11:50 +0000

Da ich schon seit mehreren Tagen teilweise massive Probleme mit der Datenbank habe und mein Provider bisher keine zufriedenstellende Lösung gefunden hat, musste ich erstmal nach einer minimalen Alternative suchen.

Hintergrund ist, dass ich auf der Seite ein bisschen (kaum auffallende) Werbung geschaltet habe, um den Blog zu finanzieren. Natürlich wird regelmäßig geprüft, ob diese Werbung auch wirklich verfügbar ist: Diese Prüfung ist jedoch nicht möglich, wenn die Datenbank gerade mal wieder streikt.
Deshalb habe ich mich bei der Perishable Press informiert und herausgefunden, dass WordPress einem die Möglichkeit gibt, die Seite zu bearbeiten, die anzeigt wird, wenn ein Datenbankfehler aufgetreten ist.

Dazu muss lediglich die Datei wp-content/db-error.php erstellt und mit Inhalt gefüllt werden. Ist diese vorhanden, wird deren Inhalt zur Anzeige des Fehlers genutzt. Im ersten Schritt habe ich nun dort einfach erstmal die Werbung eingetragen, die permanent verfügbar sein sollte.
Im nächsten Schritt werde ich dann wohl auch dazu übergehen, eine Fehlerseite zu erstellen, die dem normalen Seitendesign entspricht.

Am liebsten wäre es mir jedoch, wenn das Datenbankproblem endlich vollständig behoben werden würde!

Fehlerhafte Grüße, Kenny

WP Mobile Edition, Subdomains UND Kommentare

Mea Culpa — Mon, 07 Dec 2009 12:51:37 +0000

Soderle. Nachdem ich mal wieder ein bisschen gebastelt habe, gab es heute ein Update des Artikels “WP Mobile Edition und Subdomains“.

Grund dafür war, dass mir bereits vor einiger Zeit ein Problem mit dem Proxy aufgefallen war, den ich bisher allerdings nicht beheben konnte: Es war bisher nicht möglich, über die Proxylösung Kommentare im WordPress-Blog zu hinterlassen. In meinen Augen ein großes Manko.

Erst heute ist mir die zündende Idee gekommen: Parameter!
Das Problem bisher war, dass die Daten, die im Kommentarfeld eingegeben wurden, nicht an die originale Seite weitergereicht worden sind. Dadurch konnte diese natürlich auch nicht die eingegebenen Daten verarbeiten. Durch die neue Version des Proxies gehört dieser Fehler nun der Vergangenheit an.

Hier übrigens der Grund, weshalb ich mitbekommen habe, dass die Kommentarfunktion immernoch deaktiviert war: Ich musste die Änderungen natürlich auch testen!

Leider funktioniert der Proxy nun nicht mehr “out-of-the-Box”. Stattdessen muss nun eine kleine Änderung an der wp-comments-post.php von WordPress vorgenommen werden. Diese versucht nämlich nach dem Hinzufügen des Kommentars auf diesen weiterzuleiten. Diese Weiterleitung schlägt jedoch fehl. Deshalb muss hier durch einen Meta-Refresh ein wenig nachgeholfen werden. Was genau zu tun ist, ist im Ausgangsartikel beschrieben.

Ich hoffe, euch gefällt die Verbesserung der Proxylösung.

Kommentierende Grüße, Kenny