Glücklicherweise bietet FeedBurner selbst eine geeignete Funktion an, um wieder auf den originale Feed zu migrieren. Logge dich einfach bei FeedBurner ein und und klicke oben auf Delete Feed… FeedBurner blendet dann folgende Box ein, bei der du unbedingt darauf achtest, dass die Option Use 30 days redirection ausgewählt ist und erst dann auf Delete Feed klickst:

Wenn du auf Learn more… klickst, erfährst du auch, was hinter der Option steckt:

Übersetzt heisst das: die ersten 15 Tage wird FeedBurner alle Anfragen zu dem originalen Feed umleiten. Von Tag 16 bis 30 liefert FeedBurner die Meldung aus, dass der Feed umgezogen ist (inklusive Angabe der neuen URL). Nach den 30 Tagen wird der Feed endgültig deaktiviert und der Besucher bekommt nurnoch eine Fehlermeldung zurück.

Um die Kopfgrafik zu verkleinern, legt man zunächst ein Child-Theme an (falls nicht bereits geschehen). Das Yoko Theme verwendet zwei Konstanten, um die Größe der Kopfgrafik zu bestimmen. Diese Konstanten überschreibt man dann einfach in der functions.php des Child-Themes. Um die Höhe der Kopfgrafik zu verändern, muss die Konstante HEADER_IMAGE_HEIGHT überschrieben werden. Die Breite wird dann logischerweise über die Konstante HEADER_IMAGE_WIDTH definiert. Da ich nur die Höhe auf 150px verändern wollte, habe ich folgendes in meine functions.php eingetragen:

<?php
	define('HEADER_IMAGE_HEIGHT', 150);
?>

Für die Breite geht man natürlich unter Angabe des anderen Konstanten-Namens genauso vor. Wer noch den Strich unter der Kopfgrafik loswerden möchte, muss folgendes zu der style.css des Child-Themes hinzufügen:

#wrap {
	border-top: none;
}

Benutzung

Zwar sollte die Bedienung der Anwendung intuitiv genug sein, ich erkläre dennoch einmal kurz alle Schritte. Zunächst muss man sich natürlich anmelden. Da sich die Webanwendung in die WordPress-Datenbank einklinkt, müssen hier die Benutzerdaten des WordPress-Administrators eingetragen werden:

Danach wählt man den Artikel, aus dem die Kommentare verarbeitet werden sollen. Es werden hierbei die neusten 100 Artikel chronologisch absteigend angezeigt. Ich denke, das sollte ausreichen…

Auf der nächsten Seite werden dann die Kommentare des Artikels angezeigt. Pro E-Mail-Adresse werden die Kommentare gebündelt dargestellt. Über den Faktor auf der rechten Seite kann festgelegt werden, wieviele Lose für diesen Benutzer in den Topf kommen sollen. Unten kann dann schließlich ausgewählt werden, wieviele Gewinner ausgelost werden sollen:

Dann werden auch schon die Gewinner aufgelistet:

Algorithmus zur Auslosung

Jetzt möchten einige bestimmt wissen, wie die Gewinner ermittelt werden. Es werden zunächst für jeden Besucher so viele Lose in den Topf (Programmierer werden dies als Array kennen ) geworfen, wie für ihn angegeben wurde. Danach wird alles durchgemischt. Letztendlich ermittelt ein Zufallszahlen-Generator die Gewinner. Damit ein Besucher nicht zweimal ausgelost wird, wird immer nachgeprüft, ob dieser nicht schon einen Gewinn gezogen hat.

Der Algorithmus funktioniert also fast genau so, wie bei einer echten Verlosung (hier kann man allerdings mehrmals einen Gewinn ziehen )

Hinweis

Die Anwendung wird so ausgeliefert, wie sie ist. Das heisst, dass ich trotz intensiver Prüfung die Fehlerfreiheit des Programms nicht garantieren kann. Um immer über aktuelle Neuerungen informiert zu bleiben, solltet ihr die Benachrichtigungen für neue Kommentare in diesem Artikel abonnieren. Ein kleines Dankeschön als Kommentar (damit ihr die Benachrichtigung abonnieren könnt) reicht mir schon

Download und Installation

Nach dem Download der Anwendung muss das entsprechende Archiv einfach in das Hauptverzeichnis deiner WordPress-Installation entpackt werden. Danach kann die Anwendung über http://<Deine WordPress-URL>/lottery aufgerufen werden.

Alternative PHP Cache

Zunächst habe ich den Alternative PHP Cache (APC) installiert. Da PHP eine interpretierte Sprache ist, muss ein PHP-Script vor der Ausführung erst kompiliert werden. APC cached das Kompilat, sodass beim nächsten Aufruf des Scripts das Kompilieren entfällt. Unter Ubuntu installiert und aktiviert man APC ganz einfach wie folgt:

aptitude install php-apc
/etc/init.d/apache2 restart

Nach dem Neustart des Webservers ist APC automatisch aktiviert – es ist keine weitere Konfiguration erforderlich (es sei denn, man will noch das letzte Quäntchen heraus holen).

memcached

Als nächstes habe ich memcached installiert. Mit memcached können Daten im Arbeitsspeicher gehalten werden. Zwar gibt es das entsprechende PHP-Modul für memcached in den Paketquellen von Ubuntu, aber aus unerklärlichen Gründen konnte das benötigte Plugin FlexiCache für WordPress nichts mit der PHP-Erweiterung aus den Paketquellen anfangen. Also habe ich das Modul wie folgt manuell installiert. Im gleichen Abwasch werden noch der memcached-Server sowie die SQLite-Unterstützung für PHP installiert (mehr dazu gleich):

aptitude install php-pear php5-dev memcached php5-sqlite
pear install memcache
echo "extension=memcache.so" >> /etc/php/apache2/php.ini
/etc/init.d/apache2 restart

Nachdem alle benötigten Pakete installiert wurden, muss das Plugin FlexiCache für WordPress installiert werden. Nach der Aktivierung des Plugins sind kleinere Einstellungen zu machen, wobei die Grundeinstellungen bereits sehr gut sind.

In den Main Options von FlexiCache aktiviert ihr zunächst einmal den Cache, stellt als Storage Engine memcached ein und erhöht ggf. noch die Ablaufzeit des Caches:

Des Weiteren habe ich den Standalone Mode von FlexiCache aktiviert. Hierbei werden Anfragen über eine entsprechende Umleitung direkt an FlexiCache gerichtet. Sollte ein gültiger Cache-Eintrag vorhanden sein, wird dieser direkt ausgeliefert, ohne das eine Zeile WordPress-Code ausgeführt wird. Sollte kein passender Cache-Eintrag vorhanden sein, übergibt FlexiCache die weitere Behandlung an WordPress und cached die Seite dann natürlich.

Die entsprechende Modifikation für eure .htaccess-Datei kann bequem über den Punkt Standalone Mode aktiviert werden, sofern die Datei über entsprechende Zugriffsrechte verfügt. Ansonsten werden euch die Anpassungen auch angezeigt und müssen per Hand in die .htaccess-Datei eingefügt werden.

Die vorhin installierte SQLite-Unterstützung für PHP wird übrigens automatisch von FlexiCache für interne Zwecke verwendet. Es erleichtert FlexiCache, veraltete Cache-Einträge zu identifizieren und diese dann zu löschen. Solltet ihr keine SQLite-Unterstützung installiert haben, wird sich dies aber laut Dokumentation des Plugins nicht negativ auf die Ladezeit auswirken.

.htaccess raus, VirtualHost rein

Über die vielfach verwendete .htaccess-Datei kann bequem das Verhalten des Webservers beeinflusst werden: Umleitungen einrichten, HTTP-Header versenden, Authentifizierung einrichten – alles kein Problem. Der Nachteil ist jedoch, dass die Datei bei jeder einzelnen Anfrage vom Webserver ausgewertet wird. Sollte also zum Beispiel eine Seite drei JavaScripts, zwei CSS-Dateien und fünf bilder einbinden, seit ihr im Besten fall mit 11 Anfragen dabei und somit muss die .htaccess-Datei 11x ausgewertet werden.

Besser ist es, die Inhalte aus der .htaccess-Datei direkt in die Konfiguration des Webservers zu übernehmen. Dort wird die Konfiguration einmal beim Start des Webservers eingelesen und muss nicht mehr erneut ausgewertet werden.

Die VirtualHost-Konfiguration für diese Domain habe ich dazu wie folgt angepasst:

<VirtualHost *:80>
	<Directory /var/www/www.techspread.de>
		// hier die Inhalte aus der .htaccess-Datei
	</Directory>
</VirtualHost>

Natürlich handelt es sich hierbei nicht um die komplette Konfiguration des VirtualHosts, sondern nur um die Inhalte, die nötig sind, um das Übertragen der .htaccess-Einträge in die Konfiguration zu beschreiben. Der Verzeichnispfad muss absolut angegeben werden und entspricht dem Speicherort auf dem Server.

GravatarCache einrichten

Die meisten Blogs verwenden Gravatare, um vor allem die Kommentare etwas persönlicher zu gestaltet. Der Nachteil besteht darin, dass die Gravatar-Server nicht unbedingt sie schnellsten sind. Deshalb habe ich den GravatarCache von Sergej eingerichtet.

Google Web Fonts auf den eigenen Webserver packen

Zwar war die Webseite nach diesen Anpassungen schon sehr schnell, ein Blick auf die Ladezeiten mit Firebug zeigte jedoch, dass die meiste Ladezeit damit verbracht wird, die vom Theme verwendeten Google Web Fonts herunterzuladen. GoogleCDN hin oder her, die Ladezeiten stimmten einfach nicht. Deshalb habe ich die Fonts einfach auf meinen eigenen Server gepackt und das Stylesheet entsprechend angepasst.

Hierzu muss zunächst im Stylesheet der entsprechende @import für die Google Web Fonts gesucht werden. Die angegebene URL wird dann einfach im Browser geöffnet. Bei mir war diese URL eingetragen: http://fonts.googleapis.com/css?family=Droid+Sans:regular,bold|Droid+Serif:regular,italic,bold,bolditalic&subset=latin

Das @import habe ich dann durch die entsprechende Ausgabe ersetzt. Der Abschnitt enthält diverse URLs, über welche die Google Web Fonts referenziert werden. Einfach die URLs aufrufen, .woff-Dateien herunterladen und auf dem eigenen Server ablegen. Danach müssen die URLs noch an den eigenen Server angepasst werden und fertig.

Weitere Optimierungen

Neben den vorgestellten Optimierungen können noch diverse Tricks umgesetzt werden. So sollte man sich zum Beispiel einmal den Apache Caching Guide durchlesen. Dass die Anzahl der installierten Plugins die WordPress-Performace beeinträchtigt und die Datenbank gepflegt werden sollte, muss ich wohl nicht großartig erwähnen.

#! /bin/bash

# Korrekte Parameteranzahl überprüfen
if [ $# -ne 4 ];
then
	echo "Usage: wordpress-cleanup <Database> <Table-Prefix> <Username> <Password>"
	exit 0
fi

# Variablen deklarieren
DATABASE=$1
WPPREFIX=$2
USERNAME=$3
PASSWORD=$4

# MySQL-Queries ausführen
mysql -u$USERNAME -p$PASSWORD $DATABASE <<EOF

	# Revisionen und automatische Speicherungen löschen
	DELETE FROM ${WPPREFIX}posts WHERE post_type=’revision’;

	# Automatisch angelegte Entwürfe löschen
	DELETE FROM ${WPPREFIX}posts WHERE post_type=’auto-draft’;

	# Als Spam markierte Kommentare löschen
	DELETE FROM ${WPPREFIX}comments WHERE comment_approved=’spam’;

	# Kommentare aus dem Papierkorb löschen
	DELETE FROM ${WPPREFIX}comments WHERE comment_approved=’trash’;

	# Nicht genehmigte Kommentare löschen
	DELETE FROM ${WPPREFIX}comments WHERE comment_approved=’0′;

EOF

# Tabellen auslesen
TABLES=`mysql -u$USERNAME -p$PASSWORD $DATABASE -se ‘SHOW TABLES’`

# Tabellen durchgehen
for TABLE in $TABLES;
do

	# Tabellen optimieren
	mysql -u$USERNAME -p$PASSWORD $DATABASE -e "OPTIMIZE TABLE $TABLE" > /dev/null

	# Tabellen reparieren
	mysql -u$USERNAME -p$PASSWORD $DATABASE -e "REPAIR TABLE $TABLE" > /dev/null

done

Wenn ihr noch weitere Optimierungen für die WordPress-Datenbank habt, werde ich die entsprechenden Vorschläge prüfen und ggf. in das Script einpflegen.

So wird bei den meisten Blogs eine Angabe der E-Mail-Adresse zum Kommentieren verlangt. Zusätzlich protokolliert WordPress immer die IP-Adresse des Kommentators. Die fragwürdigen Spalten comment_author_email und comment_author_ip finden sich in der Tabelle wp_comments.

Rechtlich gesehen müsste man die Kommentatoren vor dem Abgeben eines Kommentars darüber aufklären, dass die E-Mail- und/oder IP-Adresse im Klartext und dementsprechend nicht anonymisiert gespeichert werden. Das müsste wie z.B. bei Onlineshops über eine Datenschutzerklärung sowie eine Checkbox, die standardmäßig deaktiviert und dementsprechend von dem Besucher anzukreuzen ist, erfolgen.

Die IP-Adressen zu anonymisieren sollte kein Problem darstellen, die braucht WordPress meines Erachtens nach nicht. Blöderweise kann man bei WordPress nur die Angabe eines Benutzernamens zusammen mit einer Angabe der E-Mail-Adresse erzwingen. Der Punkt findet sich in der WordPress-Administration unter Einstellungen » Diskussion » Benutzer müssen zum Kommentieren Name und E-Mail-Adresse hinterlassen.

Hinzu kommt, dass Plugins zur automatischen Benachrichtigung bei neuen Kommentaren wie z.B. Subscribe to Double-Opt-In Comments ebenfalls sehr beliebt sind. Auch hier wäre eine Aufklärung des Benutzers aus meiner Sicht aus Datenschutzgründen erforderlich.

Und damit nicht genug: zwar machen sich viele Leute Gedanken über Google Analytics und Akismet, setzen dementsprechend Tools ein, die datenschutzkonform sind, aber bedenken nichtmal die Grundlage einer Webseite: den Webserver. Dieser protokolliert auch in den allermeisten Fällen personenbezogene Daten (die IP-Adresse), sofern man dies nicht deaktiviert.

Doch was tun? E-Mail- und IP-Adressen kann man anonymisieren oder löschen. Ebenso kann man das Protokoll des Webservers deaktivieren (sofern man den Server selber administriert) und bereits angelegte Log-Dateien löschen. Bei automatischen Benachrichtigungen zu neuen Kommentaren müsste man den Besucher meines Wissens nach darüber aufklären, dass seine E-Mail-Adresse gespeichert wird. Oder kann man hier grundsätzlich davon ausgehen, dass der Besucher aufgrund des Aktivierungstextes davon Kenntnis haben sollte, dass die E-Mail-Adresse hinterlegt wird?

Was meint ihr zu der ganzen Problematik?

Update:

• Apache datenschutzkonform: Logging deaktivieren

Der Code dafür steht in meiner functions.php und sieht wie folgt aus:

// Funktion zum Erzeugen des Tweet This-Links
function tweetlink($title, $url) {
   $href = str_replace(' ', '%20', "http://twitter.com/home?status=$title $url (via @P4G0)");
   echo '<a href="'.$href.'">Tweet this</a>';
}

Aufgerufen wird die Funktion in meiner Loop wie folgt:

<?php tweetlink(get_the_title(), wp_get_shortlink()); ?>

Wie man sieht, eine äußerst einfache und effektive Lösung, um einen Tweet This-Link zu erstellen.

Die Navigation wird über ein individuelles Menü geregelt, wobei der Dropdown-Effekt auf reinem CSS basiert. Ansonsten wird die Webseite noch angetrieben von den folgenden Plugins:

Die Seite ist in dem jetzigen Zustand noch nicht ganz fertig. Die Startseite bekommt noch eine GoogleMap spendiert, wobei auch gleich der Fotostreifen der alten Webseite weichen wird. Zudem soll die Startseite natürlich ein wenig informativer werden, nur der passende Text ist uns noch nicht eingefallen

Zunächst einmal habe ich natürlich die neuste Eclipse-Version (derzeit Helios) in der Variante für Java Entwickler installiert.

Dazu gesellen sich eine Reihe an Plugins:

Und da ich schon weiß, dass sich gleich wieder die Netbeans-Benutzer zu Wort melden werden: man teilt Eclipse einfach ein wenig mehr Arbeitsspeicher zu und optimiert an ein paar Stellen und alles läuft rund und flüssig

Ich würde ja sehr gerne sofort das Buch durchlesen, morgen geht es aber in die mündliche Prüfung meiner GPM-Zertifizierung, weshalb ich den Fokus nun erst einmal auf das Lernen richten muss. So sieht das gute Stück auf jeden Fall aus: