Durch Permalinks bekommen Artikel und Seiten lesbare URLs und auch Struktur. Alle Artikel in der Kategorie ‘Wordpess’ können mit schnurpsel.de/themen/wordpress/ aufgerufen werden, das Monatsarchiv für Juli 2010 mit schnurpsel.de/date/2010/07/.

Auf dem Webserver existiert aber kein Verzeichnis /themen/wordpress/ oder /date/2010/07/. Damit die Seiten trotzdem aufgerufen werden können, erstellt Wordpress eine einfache Regel für das Rewrite-Modul des Apache-Webservers:

RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]

Diese drei Zeilen führen dazu, das alles, was nicht tatsächlich als Datei oder Verzeichnis auf dem Server existiert, einfach an die index.php von Wordpress durchgereicht wird. Wordpress kümmert sich nun darum, ob es z.B. eine Kategorie “Wordpress” gibt, stellt die Liste mit den passenden Artikeln zusammen un gibt sie aus.

Was es alles nicht gibt

Im Moment sind wohl mal wieder ein paar Bots oder Skriptkiddies unterwegs, die einfach versuchen, irgendwelche php-Skripte aufzurufen, um mögliche Sicherheitslücken ausnutzen zu können. Das sieht dann etwa so aus:

/scripts/setup.php
/pma/scripts/setup.php
/phpMyAdmin/scripts/setup.php
/phpmyadmin/scripts/setup.php
/myadmin/scripts/setup.php

Solche Dateien gibt es hier allerdings nicht. Auch andere Sachen können zu fehlerhaften Aufrufen führen, z.B. Standard-Icons wie favicon.ico oder apple-touch-icon.png, die manche Browser einfach aufrufen oder durch Nutzer aus der Bildersuche falsch kopierte BILd-URLs.

Durch die für die Permalinks notwendigen mod_rewrite-Regeln werden alle dies Aufrufe nun an Wordpress weitergeleitet. Wordpress wird geladen, stellt eine Datenbankverbingung her, klappert die internene Rewriteregeln ab um schließlich nur festzustellen, daß es mit dem Aufruf nichts anfangen kann. Dann gibt Wordpress schließlich auch nur eine Fehlerseite aus, die möglicherweise auch noch aufwändig gestaltet ist und unnötig viel Daten als Antwort zurücküberträgt.

Wordpress und den Webserver entlasten

Damit nun nicht Wordpress wegen jeder Kleinigkeit behelligt werden, kann man eine spezielle Regel der Wordpress-Regel vorschalten, die einfach gegebenfalls die Abarbeitung der Rewrite-Regeln beendet:

<IfModule mod_rewrite.c>
RewriteEngine On
RewriteCond %{REQUEST_FILENAME} !-f
RewriteRule \.[^\.]+$ - [L]
</IfModule>

Die Idee dabei ist, daß alle Permalink-URLs normalerweise keine Dateierweiterung wie .html, .jpg oder .php haben. Falls nun eine Datei nicht existiert (RewriteCond) und diese Datei mit einem Punkt und mindestens einem weiteren Zeichen endet, wird die Abarbeitung der Regeln an dieser Stelle beendet (RewriteRule). Diese Zeilen müssen vor den Wordpress-Regeln stehen.

Wordpress bekommt diese Aufrufe nicht mehr zu sehen, der Fehler wird einfach vom Webserver behandelt. Hier kommt dann auch eine konfigurierte und vorhanden benutzerdefinierte Fehlerseite zu Anwendung.

Ich weiß, es gibt auch Blogger, die aus welchen Gründen auch immer, die Permalinks mit einem abschließenden .html konfiguriert haben. Aber auch das ist kein Problem, es muß nur eine Zeile hinzugefügt werden, welche die Regel für die Endung .html (oder eine andere) ungültig macht:

<IfModule mod_rewrite.c>
RewriteEngine On
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_URI}	!\.html$
RewriteRule \.[^\.]+$ - [L]
</IfModule>

Optimierte Version

Mann kann die zusätzlichen Bedingungen auch direkt in die Wordpress-Rules einfügen. Nachteil hierbei ist aber, daß sie bei Änderungen an den Permalinkeinstellungen verloren gehen, weil Wordpress den Block zwischen # BEGIN WordPress und # END WordPress neu schreibt:

# BEGIN WordPress
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteCond %{REQUEST_URI}	!\.[^\.]+$
RewriteRule . /index.php [L]
</IfModule>
# END WordPress

Die Version mit Endung .html:

# BEGIN WordPress
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteCond %{REQUEST_URI}	!\.[^\.]+$ [OR]
RewriteCond %{REQUEST_URI}	\.html$
RewriteRule . /index.php [L]
</IfModule>
# END WordPress

Plugin-Version

Angeregt durch die Kommentare von Ralf habe ich nun eine Plugin-Version fertig gestellt.

Download: 123 Rewrite Error 0.10

Das Plugin schreibt die Regeln beim Aktivieren, Deaktivieren und bei Änderungen an der Permalinkstruktur wie bei der Optimierten Version beschrieben automtisch mit den Wordpress-RewriteRules in die .htaccess. Dabei wird auch gleich berücksichtigt, ob in der Permalinkstruktur eine Erweiterung wie .html angegeben wurde.

Fazit

Wieviel Serverlast oder Traffic durch diese Maßnahme eingespart wird, kann ich nicht sagen. Das hängt sicher auch vom Nutzungsprofil und der Konfiguration der Website ab. Aber warum sollte man solch eine einfache Möglichkeiten auslassen, um Wordpress und dem Webserver das Leben ein bißchen leichter zu machen.

Das scheint aber nicht der Fall zu sein, denn in WP 3.0 RC1 wird die my-hacks.php weiterhin geladen, sofern sie aktiviert ist. Damit ist gewährleistet, daß nicht plötzlich nach dem Update wichtige Funktionen ausgesperrt werden, die möglicherweise in der my-hacks.php stehen.

Allerdings kann man nach einer Neuinstalltion die my-hacks-Erweiterung nicht mehr im Backend aktivieren. Dafür müßte man direkt in der Datenbank rumfummeln oder man verwendet das “123 Hackfile Option”-Plugin:

Download: Plugin 123 Hackfile Option 0.12

Die Option dafür erscheint nun allerdings nicht mehr bei Einstellungen->Verschiedenes (gibt es nicht mehr), sondern ganz am Ende von Einstellungen->Allgemein.

Wenn Besucher über Google auf die eigene Webseite kommen, ist das ja normalerweise eine schöne Sache. Allerdings nicht, wenn es über einen seltsamen Link, wie er oben zu sehen ist, passiert. Wie kommt aber soetwas überhaupt in den Index einer Suchmaschine?

Das gibts doch gar nicht

Bereits im Oktober letzen Jahres hatte ich etwas Ähnliches beobachtet. Da wurden Google massiv mit Links auf irgendwelche nicht existierende Seiten gefüttert. Wenn nun eine dieser nicht vorhandenen Seiten auf die Anfrage des Googlebots einen HTTP-Status “200 OK” zurückliefert, geht Google davon aus, daß es die Seite gibt und nimmt sie in den Index auf. Korrekterweise sollte aber mit dem Fehlerstatus “404 Not found” geantwortet werden, so daß die Seite nicht im Index landet. Genau das war damals bei mir der Fall, also ist eigentlich alles in Butter. Nur habe nicht mit der Großzügigkeit von Wordpress gerechnet.

Die Wordpress.presse.pressung

In manchen Dingen ist Wordpress recht großzügig. Früher war es möglich, wenn in den Permalinks die Artikel ID verwendet wurde, einen Artikel über nahezu beliebig viele URLs aufzurufen. Sobald die ID erkannt wurde und existierte, wurde der Rest der URL nicht weiter überprüft. So hätte man diesen Beitrag hier auch noch mit /alles-quark-399/ oder /blafasel-399/ aufrufen können. Das geht mittlwerweile nicht mehr. Allerdings ist zur Zeit etwas Ähnliches immer noch möglich, wenn man in den Permalinks die Kategorie verwendet.

Wenn nun eine Wordpress-Seite mit Parametern in der Form /?parameter=wert aufgerufen wird, ignoriert Wordpress einfach unbekannte Patemeter oder ungültige Paremeterwerte und tut so, als würde es diese Parameter gar nicht geben. Somit führen folgende Aufrufe zu gültigen Seiten:

http://testblog.schnurpsel.de/?q=Diese Seite gibt es nicht
http://testblog.schnurpsel.de/?quark=Gesund und schmeckt lecker
http://testblog.schnurpsel.de/?p=Hier steht normalerweise die ID

Bei den ersten beiden Beispielen wir ein unbekannter Paremeter verwendet, im dritten Beispiel der gültige Parameter p= (Short-Link), der allerdings eine numerische Artikel-ID erwartet. In allen Fällen wird die Startseite mit dem Status “200 OK” angezeigt. Es funktioniert aber ebenso mit Einzelseiten oder anderen Permalinks:

http://testblog.schnurpsel.de/...hallo-welt/?frage=was-soll-das
http://testblog.schnurpsel.de/2010/03/?jahreszeit=Frühling

Gut oder schlecht

Ob dieses Verhalten von Wordpress nun gut oder schlecht, gewollt oder ein Fehler ist, mag ich nicht beurteilen. Ich finde es zumindest suboptimal, denn dadurch entstehet z.B. die oben gezeigte URL als Google-Treffer, und sowas möchte ich nicht haben. Dabei wäre es für Wordpress kein größeres Problem, unbekannte Parameter oder ungültige Parameterwerte als Fehler zu behandeln. Das schöne an Wordpress ist ja, daß es recht einfach erweitert und modifiziert werde kann.

Fehler bleibt Fehler

Deshalb habe ich mir diese Parameterprüfung hier nachgerüstet (aber nicht für den Testblog!), übrigens auch für die worpdresseigene Suchfunktion. Denn falls es keinen Suchtreffer gibt, finde ich, ist das auch einen “404 Not Found” wert :-)
Nun sollte auch die ganz oben gezeigte, hier nicht existierende Seite nach einiger Zeit aus dem Suchindex verschwinden.

Nachtrag:
Weil es angefragt wurde, hier mein Code zur Parameterprüfung, der sich per Action-Hook in parse_request reinhängt:

<?php
 function plw123_parse_request( $data ) {
  // Liste der numerischen Parameter
  $num_para = array( 'p', 'page_id', 'attachment_id', 'tag_id',
          'page', 'paged',
          'year', 'monthnum', 'day', 'w', 'm',
          'hour', 'minute', 'second' );
  // Parameter übergeben, aber nicht gefunden
  foreach( $_GET as $key => $value )
   if( !array_key_exists( $key, $data->query_vars ) ) {
    $data->query_vars['error'] = '404';
    return;
   }
  // Numerische Parameter prüfen
  foreach( $data->query_vars as $key => $value ) {
   // Sonderbehandlung Kategorie-IDs
   if( 'cat' == $key ) {
    // darf eine Liste von kommaseparierten Integerwerten sein
    $test_value = preg_replace( '|[^0-9,-]|', '', $value );
    if( $test_value != $value ) {
     $data->query_vars['error'] = '404';
     return;
    }
   }
   // Numerische Werte
   if( in_array( $key, $num_para ) ) {
    $value = trim( $value );
    // Page bei Einzelansicht (Seite, Artikel) kann führenden Slash enthalten
    if( 'page' == $key )
      $value = ltrim( $value, '/' );
    $test_value = absint( $value );
    if( !$test_value ) {
     $data->query_vars['error'] = '404';
     return;
    }
   }
  }
 }
 add_action( 'parse_request', 'plw123_parse_request' );
?>

Pro Tag gecrawlte Seiten

Auf dem Diagramm ist noch das Ende vom November, der ganze Dezember und Januar und der Anfang vom Februar zu sehen. Scheinbar tritt der Googlebot auch über den Jahreswechsel etwas kürzer, feiert Weihnachten und Silvester und legt dann erst Mitte Januar wieder richtig los.

Pro Tag heruntergeladene Kilobyte

In etwa parallel dazu verläuft normlerweise die Kurve zu den täglich heruntergeladenen Datenmengen. Klar, je mehr Seiten angefragt werden, um so mehr Daten fallen da durchschnittlich an.

Eines fällt aber auf, denn obwohl die Anzahl der pro Tag abgefragten Seiten ab Mitte Januar und im Februar höher liegen als noch im November, ist die Datenmenge nicht in gleichem Maße angestiegen. Der Grund ist recht einfach. Ich hatte Anfang/Mitte Dezember die gzip-Komprimierung für die Seiten aktiviert.

Dauer des Herunterladens einer Seite (in Millisekunden)

Die Geschwindigkeit der Seitenauslieferung ist die für den normalen Nutzer, also den Besucher einer Website der wohl wichtigste, technische Wert. Wenn erstmal ein paar Sekunden nach dem Aufrufen einer Seite oder länger nichts passiert, ist das aus Anwendersicht eher unerfreulich.

Der Wert lag im November bei etwa 1,5 Sekunden und schließt damit an die Zahlen vom Oktober an. Anfang Dezember bin ich dann Dank SpeedPlus wieder zu Strato zurückgekehrt und seitdem liegen die Ladezeiten fast immer bei erfreulichen 0,8 Sekunden. Aber eben nur fast. Wie man im Diagramm sieht, gab es schon im Dezember und Anfang Januar Ladezeitspitzen, die dann im Februar nochmal deutlich zunahmen. Allerdings ist das eher darin zu sehen, daß durch die größere Anzahl der pro Tag abgefragten Seiten auch die Wahrscheinlichkeit für den Googlebots auf eine Lastspitze zu treffen, größer war.

Ungeachtet dessen gibt es aber diese Lastspitzen, die nicht nur der Googlebot “sieht”, sondern auch der normale Nutzer bemerkt. Wenn man Pech hat, dauert das Laden einer Seite wieder 4 bis 6 Sekunden, ganz so wie vor der SpeedPlus-Zeit bei Strato. Diesmal ist es aber meiner Meinung nach nicht die schlechte PHP-Performance, sondern eher die Datenbank. Die Datenbankserver sind zwar grundsätzlich nicht wirklich lahm, legen aber ab und zu ein paar Gedenkminuten ein, wie mir scheint. Und genau dann dauert der Seitenaufruf wieder mehrere Sekunden. Kürzlich gab es auch wieder mal einen Totalausfall, der dann zu einem 500er Fehler führt.

Hin und weg

Nun sind zwar PHP und Webserver bei Strato schnell, aber die Datenbank klemmt mitunter. Deshalb bin ich vorerst wieder zu meiner externen Datenbank zurückgekehrt. Das eigentlich langsame ist hierbei die Datenübertragung über das Internet zwischen Strato (Karlsruhe/Berlin) und Host-Europe (Köln). Um das etwas abzudämpfen, habe ich zusätzlich ein Datenbank-Cache-Plugin installiert, welches häufig benötigte Daten auf dem Webspace bei Strato im Dateisystem ablegt, um diese nicht jedesmal neu übertragen zu müssen. Zumal sich viele Daten, z.B. die Artikel und Seiten normalerweise eh nicht ändern.

Nun werde ich das Alles mal weiter beobachten, wie das mit den Ladezeiten so aussieht und hoffe aber trotzdem, das Strato die Datenbankaussetzer in den Griff bekommt.

Die Diskussion taucht immer wieder mal auf, wie sieht optimalerweise ein Permalink, also die Struktur der URL aus. Sollten das Datum oder die Artikel-ID enthalten sein, ist es sinnvoll Kategorien oder Tags mit aufzunehmen?

Eine allgemeingültige und endgültige Empfehlung kann es nicht geben, wenn man die unterschiedlichen Sichtweisen dazu berücksichtigt, die dann zu eher widersprüchliche Aussagen führen.

Betreibt man ein Blog im Sinne eines Tagebuches, ist sicher das Datum oder Bestandteile davon eine gute Wahl. Aus SEO-Gesichtspunkten bzw. für eine eher thematische Ausrichtung wird oft die Kategorie mit in die Permalinkstruktur aufgenommen. Für eine Webseite mit vielen Schreibern könnte auch der Autorenname eine geeignete Option sein.

Ich habe mir einfach mal die Permalink-Struktur der 33 deutschen Top-Blogs angesehen. Vielleicht läßt sich ja daraus eine Empfehlung ableiten.

Die Permalink-Struktur der 33 deutschen Top-Blogs

Zunächst stellt sich natürlich die Frage, welche sind denn die Top-Blogs in Deutschland? Auch hier kann man sich endlos streiten, wenn man will. Ich habe als erste Näherung einfach die aktuell zusammengerechnete Liste von heute, dem 24.02.2010, genommen. Die Permalinkstruktur habe ich in Gruppen zusammengefaßt, vor dem jeweiligen Blog steht der aktuelle Platz in der Top-33-Liste :

• Jahr, Monat, Tag und Artikelname (13)
  • 2. netzwertig.com
  • 3. Nerdcore
  • 4. Basic Thinking Blog
  • 10. Spreeblick
  • 12. Werbeblogger
  • 13. GoogleWatchBlog
  • 18. Die Fünf Filmfreunde
  • 19. Netzökonom (vorangstelltes ‘archive’)
  • 22. WordPress Deutschland Blog
  • 23. Lummaland
  • 25. MACNOTES.DE
  • 29. law blog (vorangstelltes ‘archives’)
  • 32. allesaussersport (vorangstelltes ‘archiv’)
• Jahr, Monat und Artikelname (5)
  • 11. Internet-Law
  • 15. Les Mads
  • 17. fscklog
  • 24. Indiskretion Ehrensache
  • 27. Alles Schall und Rauch
• Jahr und Artikelname (1)
  • 6. netzpolitik.org
• Artikelname (6)
  • 1. Stefan Niggemeier
  • 8. Caschys Blog
  • 16. Ruhrbarone
  • 30. 1x umrühren bitte (vorangstelltes ’stories’)
  • 31. Design Tagebuch
  • 33. Druckerei Blog
• Nummer und Artikelname (3)
  • 7. CARTA
  • 9. BILDblog
  • 20. UPLOAD Blog
• Artikelname und Nummer (1)
  • 5. StyleSpion
• Sonderformen (1)
  • 28. Elektrischer Reporter Kategorie (video) ? und Nummer
• Keine Permalink, Nummer als URL-Parameter (3)
  • 14. NachDenkSeiten
  • 21. MC Winkels weBlog
  • 26. Fefes Blog

Mehr als die Hälfte (57,6%) der Top-33-Blogs verwendet neben dem Artikelnamen das Datum oder einen Bestandteil davon in der URL. Bei allein fast 40% findet man das komplette Datum mit Jahr, Monat und Tag im Permalink. Gut 18% benutzen nur den Namen des Artikels als Permalink und weitere etwa 12% kombinieren dazu noch eine Nummer (Artikel-ID). Immerhin knapp 10% der Top-Blogs verwenden keine Permalinks, sondern setzen auf die Artikelnummer als URL-Parameter (?id=1234).

Erste Ableitung des Permalink-Aufbaus

Wenn man Permalinks verwendet, ist der Artikelname (in seiner Umwandlung zu einem URL-Pfad) gewissermaßen eine feste Größe. Die Einbeziehung des Datums oder von Teilen kann so schlecht nicht sein, diese Verwendet ein Großteil der Top-Blogs. Auch ganz auf Permalinks zu verzichten, hat gewisse Vorteile. Die URLs sind kurz und bleiben immer gültig, auch wenn man mal was am Artikel-Titel, dem Datum oder sonstigen Einflußfaktoren ändert.

Ich habe mir stichprobenartig noch weitere Blogs der Top-100 angesehen und zumindest keine Seite entdeckt, die etwa die Kategorie oder gar Tags in der URL verwendet. Mal davon abgesehen, daß Tags bei Wordpress bis zur Version 2.9.x nicht als Bestandteil der Permalinks funktionieren (obwohl in der Dokumentation genannt), gibt es auch noch andere Probleme.

Kategorie oder Tag im Permalink

In Wordpress kann man Artikel in mehreren Kategorien ablegen. Einem Artikel können zudem auch mehrere Tags zugeordnet werden. Verwendet man Kategorien oder Tags in Permalinks, erstellt Wordpress die die URL aus der Kategorie oder dem Tag mit der kleinsten ID. Ändert man nun die Kategoriezuordnung oder die Tags, kann sich möglicherweise auch die URL ändern.

Das ist aber erstmal nicht weiter schlimm, denn der Artikel wird auch weiterhin mit der alten Kategorie gefunden und angezeigt. Wordpress geht sogar soweit, einfach die Kategorie beim Auflösen der Permalinks zu ignorieren. Damit ergeben sich dann theoretisch beliebig viele URLs für einen Artikel.

Als Beispiel ist das auf meinem Testblog zu sehen. Die Permalink-Struktur sieht so aus:

/%category%/%postname%/

Der Artikel ist in der Kategorie “Allgemein” einsortiert, die URL sieht so aus:
http://testblog.schnurpsel.de/allgemein/hallo-welt/

Er ist aber auch mit der Kategorie “Blafasel”, “Hundekuchen” oder “Gibtesnicht” aufrufbar:
http://testblog.schnurpsel.de/blafasel/hallo-welt/
http://testblog.schnurpsel.de/hundekuchen/hallo-welt/
http://testblog.schnurpsel.de/gibtesnicht/hallo-welt/
Genau, diese Kategorien gibt es gar nicht.

Man hat damit potentiell also ganz viel bösen “Duplicate content” (DC). Da sage noch einer, die Kategorie im Permalink sei unter SEO-Gesichtspunkten empfehlenswert. ;-)

Permalink, so oder so

Letztendlich muß jeder selbst entscheiden, ob und wie er seine Permalinks gestaltet. Bei Putzlowitsch habe ich mich für das Datum entschieden, da ich dort eher im Sinne eines Tagebuchs schreibe. Hier verwende ich eine Kombination aus Artikelname und Artikel-ID, weil die sichtbare ID schnelle interne Links mit dem 123 IntLink-Plugin ermöglicht. Bei Twitter verwende ich übrigens gerne die WP-Shortlinks mit der ID als URL-Parameter, die sind schön kurz und funktionieren auch ohne Shortlink-Dienst.

Mit jeder neuen Wordpress-Version gab es meist neue Funktionen, manchmal war eine neue Ausgabe aber auch nur ein Sicherheits-Release, um bekannt gewordene Sicherheitslöcher zu stopfen. Damit sind Sicherheitslücken und deren Ausnutzbarkeit immer von der Wordpress-Version abhängig, wodurch die Versions-Information für einen Angreifer durchaus interessant ist.

Die Wordpress-Versionsnummer anzeigen

Wordpress liefert in der Standardinstallation die Versionsinformationen gleich an drei Stellen mit. Zwar sind diese für den normalen Besucher üblicherweise nicht sichtbar, aber in der Seite vorhanden.

Im Header der Seite
Wen man sich den HTML-Quelltext einer Seite ansieht, findet man dort möglicherweise im Header einen Eintrag wie <meta name=”generator” content=”WordPress 2.9.1″ />

Im Feed
Wen man sich den XML-Quelltext eines Feeds (RSS, Atom) ansieht, findet man dort möglicherweise am Anfang (channel) einen Eintrag wie <generator>http://wordpress.org/?v=2.9.1</generator>

In der readme.html
Mit jeder Wordpress-Version wird eine Datei readme.html und in der deutschen Version auch liesmich.html mitgeliefert bzw. installiert. Diese findet man im Wordpress-Wurzelverzeichnis. Da steht die Wordpress-Version ebenso drin:

Wordpress-Version verbergen

Man mag darüber streiten, ob es sinnvoll ist, die Versionsnummer vor Bots oder wem auch immer zu verbergen. Für die Unterdrückung der Ausgabe in den Seiten und Feeds gibt es diverse Lösungen. Wenn man nun aber so großen Wert darauf legt, die WP-Version zu verstecken, sollte man unbedingt auch die readme.html (liesmich.html) löschen. Aber Achtung, beim nächtens (automatischen) Update ist sie wieder da.

In Wordpress kann man für schönere URLs die Permalinks aktivieren. Diese werden nur für die Struktur der Artikel-URL festgelegt, zusätzlich kann ein Präfix für Kategorien und Tags vorgegeben werden, für Seiten jedoch gibt es keine extra Einstellmöglichkeit.

Für Artikle steht eine Vielzahl von von Platzhaltern (Variablen) zur Verfügung, die bei Zusammensetzen der URL durch die jeweiligen Daten des konkreten Artikels ersetzt werden.

Auch wenn man Permalinks nur für die Artikle wirklich konfigurieren kann, wirken sich die dort gewählten Optionen auch auf die Seiten und andere URLs in Wordpress aus. Einen sichtbaren Effekt hat die Entscheidung, ob man die Permalinks mit einem Schrägstrich abschließt oder nicht. Entsprechend erhalten auch alle anderen von Wordpress generierten URLs diesen Schrägstrich oder nicht. Das gilt übrigens nur für den Schrägstrich (Slash), alle anderen Endungen wie z.B. .html werden dabei nicht übernommen.

Wordpress und Rewrite-Rules

Damit Wordpress die Permalinks wieder in konkrete Artikel- und Seiten-IDs auflösen kann, wird eine Liste von Regeln (RewriteRules) erstellt, die sequentiell abgearbeitet wird. Mit dem ersten passenden Treffer wird dann die Datenbankabfrage für einen Artikel oder eine Seite, für eine Kategorie- oder Tagübersicht oder einen Feed usw. erstellt.

Wie diese interne Liste aussieht hängt unter anderem auch davon ab, welche Struktur für die Artikel bei der Permalinkkonfiguration gewählt wird. Wordpress muß Artikel von Seiten eindeutig unterscheiden können und das funktioniert nur, wenn die Permalinks als ersten Platzhalter keinen variablen Wert wie Postname (%postnam%), Kategorie (%category%), Tag (%tag%) oder Autor (%author%) enthalten. Andernfalls werden für jede statische Seite jeweils 11 Einträge in der Liste der RewriteRules erstellt, die so aussehen:

[seite-1/attachment/([^/]+)/?$] => index.php?attachment=$matches[1]
[seite-1/attachment/([^/]+)/trackback/?$] => index.php?attachment=$matches[1]&tb=1
[seite-1/attachment/([^/]+)/feed/(feed|rdf|rss|rss2|atom)/?$] => index.php?attachment=$matches[1]&feed=$matches[2]
[seite-1/attachment/([^/]+)/(feed|rdf|rss|rss2|atom)/?$] => index.php?attachment=$matches[1]&feed=$matches[2]
[seite-1/attachment/([^/]+)/comment-page-([0-9]{1,})/?$] => index.php?attachment=$matches[1]&cpage=$matches[2]
[(seite-1)/trackback/?$] => index.php?pagename=$matches[1]&tb=1
[(seite-1)/feed/(feed|rdf|rss|rss2|atom)/?$] => index.php?pagename=$matches[1]&feed=$matches[2]
[(seite-1)/(feed|rdf|rss|rss2|atom)/?$] => index.php?pagename=$matches[1]&feed=$matches[2]
[(seite-1)/page/?([0-9]{1,})/?$] => index.php?pagename=$matches[1]&paged=$matches[2]
[(seite-1)/comment-page-([0-9]{1,})/?$] => index.php?pagename=$matches[1]&cpage=$matches[2]
[(seite-1)(/[0-9]+)?/?$] => index.php?pagename=$matches[1]&page=$matches[2]

Das mag bei wenigen Seiten zwar kaum ins Gewicht fallen, bei hunderten oder gar tausenden Seiten aber schon. Einerseits belegen diese vielen Regeln Speicher, andererseits müssen sie jedesmal abgearbeitet werden, bei z.B. 300 Seiten mehr als 3300 Listeneinträge. Probleme kann es auch beim Anlegen und Ändern von Seiten geben, denn die Liste muß dann jedesmal neu erstellt werden.

Permalinks für statische Seiten optimieren

Wenn man viele statische Seiten verwendet oder vielleicht gar keine Artikel (Wordpress als CMS), sollte man als ersten Platzhalter (Strukturtag) in den Permalinks einen numerischen Wert wie Datum (year,monthnum,day), Zeit (hour,minute,second) oder die ID (post_id) verwenden. Die von Wordpress zur Auswahl angebotenen Möglichkeiten erfüllen diese Bedingungen:

Für Benutzerdefinierte Einstellungen wären z.B. /%post_id%-%postname%/ geeignet. Es darf auch ein fester Text vor dem ersten numerischen Wert stehen, also z.B. /news/%post_id%-%postname%/.

Mit diesen Permalinkeinstellungen werden keine extra Rules je Seite erzeugt, das spart zumindest bei Wordpressinstallationen mit sehr vielen statischen Seiten Speicherplatz und Abarbeitungszeit.

Damit das selbstinstallierten Wordpress auch ordentlich funktioniert, sind einige Dinge zu beachten, die ich nachfolgend erkläre. In vielen Fällen verweise ich auf die 1&1-FAQ, da dort einzelne Schritte gut beschrieben sind.

Vorbereitung der Installation – Datenbank

Zunächst muß, falls nicht schon geschehen, eine neue MySQL 5 Datenbank angelegt werden. Wichtig sind hier die Daten, welche später in die Datei wp-config.php eingetragen werden müssen (Beispiele):

define('DB_NAME', 'db123456789');
define('DB_USER', 'dbo123456789')
define('DB_PASSWORD', 'rh473256');
define('DB_HOST', 'db1234.1und1.de');

Auf den ersten Blick sehen DB_NAME und DB_USER gleich aus, sind sie aber nicht. Beim User steht zwischen ‘db’ und der Zahl ein kleines o (für Owner?). Zudem ist der Datenbank-Host eben nicht ‘localhost’, sondern der nach dem Anlegen der Datenbank in der Übersicht angezeigte dbxxxx.1und1.de.

Vorbereitung der Installation – Wordpress-Installationspaket

Die aktuelle deutsche Wordpress-Version kann man sich hier herunterladen. In der Installationsanleitung werden als nächste Schritte das Entpacken der ZIP-Datei, Editieren der wp-config.php und das Hochladen aller Dateien per FTP genannt. Für 1&1 empfehle ich eine leicht veränderten, weil schnelleren Weg, der ohne zusätzliches FTP-Programm auskommt.

Mit dem 1&1-WebspaceExplorer wird die wordpress.zip-Datei, so wie sie ist, hochgeladen. Anschließend wird sie direkt auf dem Server entpackt. Beim Entpacken entsteht ein Verzeichnis wordpress, welches man nach eigenen Wünschen umbenennen kann.

Nun holt man sich per Download aus diesem Verzeichnis die wp-config-sample.php auf den Rechner, bennent sie in wp-config.php um, trägt die Konfigurationsdaten ein und lädt sie mit dem WebspaceExplorer in das Wordpress-Verzeichnis auf dem Server.

Umstellung auf PHP 5

An erster Stelle ist die Umstellung auf PHP5 zu nennen. Mit PHP4 gibt es besonders im Wordpress-Backend Probleme, beispielsweise beim Hochladen von Bildern über die Medienverwaltung. Wie man bei 1&1 erreichen kann, daß alle PHP-Skripte mit PHP 5 ausgeführt werden, ist auch in den 1&1-FAQ beschrieben. Man erstellt eine Datei .htaccess oder ergänzt eine bereits vorhandene Datei mit folgenden Zeilen:

AddType x-mapp-php5 .php
AddHandler x-mapp-php5 .php

Diese Datei kopiert man per FTP oder mit dem 1&1-WebspaceExplorer in das Wurzelverzeichnis der Webpräsenz

Wordpress installieren

Nun kann man die Wordpress-Installation wie in der Dokumentation beschrieben starten:

http://wp-example.net/wp-admin/install.php

Maximal nutzbarer PHP-Speicher (memory_limit) 32M

Auch wenn für den PHP-Speicher bei 1und1 40M angezeigt werden, so sind doch nur effektiv 32M nutzbar. Deshalb kann durchaus folgende Fehlermeldung auftreten:

Fatal error: Out of memory (allocated 33030144)
(tried to allocate 4600 bytes) in …

Das ist etwas anderes als:

Fatal error: Allowed memory size of 33554432 bytes exhausted
(tried to allocate 4650 bytes) in …

Der Fehler kann z.B. beim automatischen Update von Wordpress vorkommen, obwohl WP intern das Speicherlimit auf 256M hochsetzt und das auch so angezeigt wird. Aber egal wie hoch man den Parameter memory_limit konfiguriert, es gibt bei 1&1 derzeit die Grenze bei 32 MB. Hier hilft nur, während des Updates den Speicherverbrauch zu reduzieren, indem man beispielsweise alle Plugins vorher deaktiviert und danach wieder aktiviert.

Auf eine Supportanfrage bei 1&1 bezüglich der 32M-Speichergrenze bekam ich folgende Antwort:

Effektiv liegt das von Ihnen nutzbare Speicherlimit bei 32 MB, da ein Teil der Ressourcen für die Ausführung von PHP selbst benötigt wird.

Nun ja, wirklich glauben kann ich das nicht.

Datenbankgeschwindigkeit, der Test

Bei Wordpress kann man sich alle Datenbankabfragen als SQL-String mit Ausführungszeiten und Aufrufhierarchie in Datenbank-Objekt unter $wpdb->queries speichern lassen. Dazu muß man in der wp-config.php die Konstante ‘SAVEQUERIES’ mit true definieren:

define( 'SAVEQUERIES', true );

Genau das habe ich für die Startseite von schnurpsel.de gemacht und mir die Daten als PHP-Array in eine Datei geschrieben:

global $wpdb;
ob_start();
var_export( $wpdb->queries );
$out1 = ob_get_contents();
ob_end_clean();
plw123_debugfile_write( $out1 );

Diese Liste mit 51 SQL-Abfragen habe ich in ein einfaches PHP-Skript eingebunden und arbeite die Abfragen hintereinander ab. Es wird zunächst ein Connect zur Datenbank ausgeführt und anschließend folgende Schleife durchlaufen:

foreach( $sql_queries as $query ) {
	$dbd = @mysql_query( $query[0], $dbh );

	while( $row = @mysql_fetch_object( $dbd ) ) {
		$last_result[$num_rows] = $row;
		$num_rows++;
	}
	@mysql_free_result( $dbd );
	$num_queries++;
}

Es werden natürlich nicht nur die SQL-Abfragen ausgeführt, sondern auch die Ergebnisdatensätze mit mysql_fetch_object abgeholt. Nur die Ausgabe der Daten spare ich mir, das hat dann aber sowieso nichts mehr mit der Datenbank zu tun.

Datenbankgeschwindigkeit, das Ergebnis

Mal von ein paar Lastspitzen abgesehen, werden die 51 Abfragen und 539 Ergebnisdatensätze vom Strato MySQL 5 Server in etwa 0,2 Sekunden abgearbeitet. Man kann das hier [test-db-mysql5] live testen.

Ich habe das auch mal mit MySQL 4 probiert, da sind die Werte sogar noch etwas besser und liegen meist bei 0,1 Sekunden oder darunter [test-db-mysql4].

Und als dritten Test habe ich eine externe Datenbank (bei Host-Europe) eingebunden [test-db-ext]. Die 0,5 bis 0,6 Sekunden sind gar nicht mal so schlecht wenn man bedenkt, daß alle Daten über das Internet von Strato (Karlsruhe/Berlin) zu Host-Europe (Köln) und wieder zurück befördert werden müssen.

Mein Fazit

Die schlechte Geschwindigkeit von Wordpress (und anderen umfangreichen PHP-Applikationen wie z.B. Joomla) liegt ursächlich nicht an einer schlechten Datenbankperformance, sondern vielmehr an einem nicht besonders schnellen Webserver/PHP.

Was hier nun im einzelnen das Problem ist, kann ich nicht sagen. Ein Geschwindigkeits-Nachteil ist sicher die Tatsache, daß PHP bei Strato als CGI läuft. Das bedeutet, daß für jeden Seitenaufruf ein neuer PHP-Prozeß gestartet werden muß. Konfigurationen, bei denen PHP als Apache-Modul läuft, haben da natürlich einen Geschwindigkeitsvorteil.
Vielleicht muß ja auch jede PHP-Datei bei Strato erst einen Sicherheitcheck durchlaufen, bevor sie geladen wird oder was auch immer.

Ein weiterer Hinweis für die mäßige PHP/Webserver-Performance sind auch die nicht besseren Ladezeiten des Strato Weblog-Basic, denn da ist überhaupt kein MySQL-Datenbankserver im Spiel. Die Daten liegen auf dem Webspace des Users und werden per SQLite eingebunden.

Trotz eigentlich nicht schlechter MySQL Datenbankgeschwindigkeit wird meine Startseite hier nicht schneller als in etwa 3,5 Sekunden geladen, dabei verwende ich fast eine WP-Standardkonfiguration ohne umfangreichen Plugins.

Meine Ausführungen tragen zwar nicht zur Lösung des Geschwindigkeitsproblems bei, aber vielleicht zum Verständnis der Ursache und Problematik an sich.

Nur gaaaanz unten, auf der letzten Einstellungsseite “Verschiedenes” traf mich fast der Schock. Die Option

[x] Die veraltete my-hacks.php-Datei unterstützen

ist verschwunde. Ein schwerer Schlag ins Kontor, für mich als bekennenden Fan der my-hacks.php-Datei.
Nachtrag: Hier findet man, warum es dazu kam.

Gut, wenn man die Option nicht mehr im Backend einstellen kann heißt das ja noch nicht unbedingt, daß sie nicht mehr vorhanden ist. Und tatsächlich, die Option ‘hack_file’ gibt es noch immer und die my-hacks.php wird in wp-settings.php auch noch geladen, sofern die Option aktiv ist. Allerdings ist die von mir getestete Version von Wordpress 2.8 eine noch recht frühe Version, also nicht Beta oder gar RC. Wenn alles schief läuft, fliegt die Unterstützung für die my-hacks.php doch noch ganz raus, was ich sehr bedauern würde.

Vielleicht überlebt sie aber doch noch im Hintergrund und für diesen Fall habe ich schnell ein kleines Plugin geschrieben, welches die Option wieder auf der Einstellungsseite “Verschiedenes” zum Leben erweckt läßt :-)

Download: Plugin 123 Hackfile Option 0.12

Diesen Maintenance-Modus kann man ganz ohne WP-Coreupdate auch manuell aktivieren. Vielleicht sind ja irgendwelche Abeiten an der Datenbank erforderlich oder man möchte das Blog aus anderen Gründen vorübergehend vom Netz nehmen.

So funktionierts

Wordpress legt beim Start des Aktualisierungsprozesses einfach im WP-Wurzelverzeichnis eine Datei .maintenance an. In der Datei steht nur eine Zeile PHP-Code drin, in welchem die Variable $upgrading mit der Funtion time() den Startzeitpunktes fest zugewiesen bekommt. Nach erfolgreichem Update wird diese Datei einfach wieder gelöscht. Sollte was schief laufen und die Datei ist nach 10 Minuten ab Start imm noch da, wird der Maintenance-Modus beendet und der Admin erhält im Backend einen entsprechneden Hinweis angezeigt.

Um Wordpress direkt in den Wartungsmodus zu versetzen, reicht es also, eine Datei mit folgendem Imhalt in das Wordpress-Wurzelverzeichnis zu kopieren:

<?php $upgrading = time(); ?>

Am einfachsten ist es, diese maintenance.txt-Datei per FTP in das Wordpress-Wurzelverzeichnis zu kopieren und dort in .maintenance umzubenennen.
Das war es schon, ab sofort gibt die Seite nur noch diese Meldung aus:

Die Seite ist ganz kurz nicht erreichbar. In einer Minute sollte wieder alles klappen.

Auch das Backend ist nicht erreichbar, man kann sich also nicht anmelden noch sonst etwas im Adminbereich machen.
Um den Wartungsmodus zu beenden, muß man einfach die Datei .maintenance löschen oder z.B. wieder in maintenance.txt umbenennen.

Wartungsmodus mit Adminzugriff

Nun möchte man aber vielleicht trotz Wartungsmodus auf den Adminbereich zugreifen. Dafür muß man die .maintenance-Datei dahingehend erweitern, daß überprüft wird, ob Seiten aus dem Adminberich oder die wp-login.php aufgerufen wurden. Ich habe das wie folgte realisiert:

<?php
$url_parts = parse_url( $_SERVER['REQUEST_URI'] );
$path_parts = pathinfo( $url_parts['path'] );
$dir_parts = explode( "/", $path_parts['dirname'] );
$dirname = end($dir_parts);
$filename = $path_parts['basename'];

$is_admin =	'wp-admin'==$dirname || 'wp-admin'==$filename;
$is_login =	'wp-login.php'==$filename;

if( $is_admin || $is_login )
	unset( $upgrading );
else
	$upgrading = time();
?>

Download: maintenance admin

Auch hier einfach die ZIP-Datei entpacken, die enthaltene Datei maintenance_admin.txt per FTP in das WP-Wurzelverzeichnis kopieren und in .maintenance umbenennen.

Nun wird beim Aufruf des Blogs der Wartungshinweis angezeigt, man kann sich aber im Backend anmelden und dort alles machen, was sich innerhalb des Admin-Breiches abspielt. Demzufolge funktionieren z.B. aber die Artikelvorschau und die Themevorschau nicht.

Es ist natürlich möglich, weitere Bedingungen zu prüfen und die Zugriffsmöglichkeiten zu erweitern. Man muß aber beachten, das innerhalb der .maintenance-Datei kein Zugriff auf irgendwelche Wordpress-Funktionen besteht und man weitestgehend mit dem auskommen muß, was PHP zur Verfügung stellt. So kann man nicht etwa die Anmeldung mit den Nutzerdaten überprüfen, wohl aber das vorhandensein des Anmelde-Cookies.

Wartungsmeldung anpassen

Wem die schlichte Meldung nicht gefällt, die Wordpress im Wartungsmodus ausgibt, kann auch hier selbst Hand anlegen. Dazu prüft Wordpress, ob es im wp-content-Verzeichnis eine Datei maintenance.php gibt und wenn ja, wird diese anstelle der Standarmeldung geladen und ausgeführt.

Als Beispiel habe ich den Code aus der wp-settings.php genommen und leicht angepaßt:

<?php
	$retry = 120;
	$protocol = $_SERVER["SERVER_PROTOCOL"];
	if ( 'HTTP/1.1' != $protocol && 'HTTP/1.0' != $protocol )
		$protocol = 'HTTP/1.0';
	header( "$protocol 503 Service Unavailable", true, 503 );
	header( 'Content-Type: text/html; charset=utf-8' );
	header( "Retry-After: $retry" );
?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
	<title>Wartungsarbeiten</title>
</head>
<body>
	<h1>Wartungsarbeiten</h1>
	<p>Die Seite ist für kurze Zeit nicht erreichbar. In ein paar Minute sollte wieder alles klappen.</p>
</body>
</html>

Download: maintenance.zip
Die ZIP-Datei entpacken, die enthaltene Datei maintenance.php gegebenfalls nach eigenen Wünschen anpassen und per FTP in das wp-content-Verzeichnis kopieren.

Wichtig ist das korrekte Setzen vom HTTP-Status im Antwort-Header. Für Wartungsarbeiten oder sonstige, zeitweilige Ausfälle sieht HTTP den Status 503 vor. Zudem sollte auch ein Wert für Retry-After gesetzt werden. Ich habe da jetzt 120 Sekunden genommen, es kann aber auch ein konkreter Zeitpunkt eingetragen werde, zu dem das Blog voraussichtlich wieder verfügbar ist.

Nach dem PHP-Block kann man seiner Phantasie HTML-technisch freien Lauf lassen. Aber auch hier gilt, man hat keinen Zugriff auf irgendwelche Wordpress-Funktionen.

Fazit

Seit Wordpress 2.7 ist es mit einfachen Hausmitteln ohne Plugin möglich, das Blog in einen Wartungsmodus zu versetzen, um Zugriffe während Arbeiten am System oder der Datenbank zu unterbinden. Optional kann auch der Zugriff auf das Backend (wp-admin) gewähleistet werden.

Vorteil dieser einfachen Lösung ist es, daß sie bereits greift, bevor WP selbst geladen wird und auch bevor irgendwelche Zugriffe auf die Datenbank erfolgen. Kleiner Nachteil ist, daß innerhalb der .maintenance-Datei und der optionalen Meldungsseite maintenance.php kein Zugriff auf Wordpressfunktionen besteht.

So funktionierts

Man schickt eine E-Mail an eine konfigurierte E-Mail-Adresse, Wordpress fragt diese ab und stellt neue Mails als Artikel im Blog ein. Eigentlich ganz einfach, man sollte jedoch einige Dinge beachten.

Damit nicht jeder einfach per E-Mail auf dem Blog Artikel veröffentlichen kann, sollte man eine neue, geheime E-Mail-Adresse einrichten. Diese kann dort liegen, wo auch das Blog gehostet ist, muß sie aber nicht. In jedem Fall sollte sie einen möglichst “kryptischen” Namen haben, damit dieser nicht einfach zu erraten ist. Also nicht etwa mailblog@schnurpsel.de, sondern besser SuXiy2zt8k@schnurpsel.

Konfiguration in Wordpress

Nun können die Daten für den neu erstellten E-Mail-Account bei den Einstellungen->Schreiben im Bereich “Via E-Mail schreiben” eingetragen werden:

Neben den E-Mail-Daten kann man hier auch eine Kategorie festlegen, in der die Artikel erscheinen sollen. Man könnte sich ja z.B. eine spezielle Kategorie “Unterwegs” anlegen, die dann die E-Mail-Artikel aufnimmt und vielleicht gar nicht auf der Hauptseite angezeigt wird.

Artikel per E-Mail bloggen

Jetzt kann es losgehen, einfach eine E-Mail an die konfigurierte E-Mail-Adresse schicken. Das was als Betreff (Subject) in der E-Mail steht, wird zum Titel des Artikels. Der eigentlich Inhalt der Mail wird, ja richtig, zum Inhalt des Artikels im Blog.
Da Wordpress aber von sich aus nicht merkt, daß ein neuer Artikel via E-Mail angekommen ist, muß es zum Abrufen der E-Mails aufgefordert werden. Das geht im einfachsten Fall manuell durch Aufrufen der Datei wp-mail.php im Wordpress-Wurzelverzeichnis. Bei mir wäre das also z.B. schnurpsel.de/wp-mail.php. Falls neue Artikel vorhanden waren, wird dies etwa wie folgt bestätigt:

Author: 1
Posted title: Ein Beitrag per E-Mail
Mission complete, message 1 deleted.

Wenn nichts angekommen ist, gibt es nur ein einfaches:

There doesn’t seem to be any new mail.

Das Abrufen der E-Mails durch WP kann man auch zeitgesteuert automatisieren, eine umfangreiche englische Beschreibung findet man hier: Post to your blog using email

Neu ab Wordpress 2.5

Bis zu Wordpress 2.3.x war es egal, woher die Artikel-E-Mail gekommen ist, also welche Absender-Adresse im From: steht, der Artikel erschien unmittelbar auf dem Blog.
Mit Wordpress 2.5 ist das nicht mehr so. Von der Absender-E-Mail-Adresse hängt es ab, ob der Artikel direkt veröffentlicht wird (Status: ‘publish’) oder nur als Enwurf (Status: ‘pending’) gespeichert wird.

Wordpress versucht an Hand der Absender-Adresse einen registrierten Nutzer zu finden, der dieselbe E-Mail-Adresse hat. Wird ein solcher gefunden und dieser ist zudem berechtigt, Artikel zu veröffentlichen, dann erscheint der Artikel mit dem Nutzer als Autor direkt auf dem Blog. Gibt es jedoch keinen passenden Nutzer, landet der Artikel nur im Backend und erscheint in der Artikelliste mit dem Status “Ausstehender Review”.

Damit wurde die Hürde für einen Mißbrauch der E-Mail-To-Blog-Funktion ein klein wenig höher gelegt, den der “Angreifer” muß nicht nur die kryptische WP-Blog-E-Mail-Adresse kennen, sondern zudem noch die eines befugten Autors.

Fazit

Bloggen von Unterwegs z.B. mit dem Handy ist durchaus möglich. Aus Sicherheitsgrunden sollte man aber einige Punkte beachten. Beim Unstieg auf Wordpress 2.5 von einer älteren Version sollte man das geänderte Veröffentlichungsverhalten beachten.

Zunächst wird eine neue statische Seite erstellt, die z.B. “Kontakt” heißt. Hier wird der Text und Code für den Formmailer eingegeben. Die URL der Seite lautet dann beispielsweise

http://schnurpsel.de/kontakt/

Diese wird bei den Einstellungen für den DD-Formmailer als “Contact page” eingetragen.

Dann wird eine Kopie der Datei index.php aus dem Wordpress-Wurzelverzeichnis erstellt und bearbeitet.
Originale index.php:

<?php
/* Short and sweet */
define('WP_USE_THEMES', true);
require('./wp-blog-header.php');
?>

Bearbeitete index.php:

<?php
/* Short and sweet */
define('WP_USE_THEMES', true);
require('../wp-blog-header.php');
?>

Kleine Änderung, große Wirkung, es ist nur ein Punkt beim require hinzugekommen.
Nun wird per FTP im WP-Wurzelverzeichnis ein Unterverzeichnis /kontakt/ angelegt und die geänderte index.php dort hinein kopiert.

Das wars, jetzt kann man die Kontaktseite aufrufen und Daten absenden, sofern man sonst auch alles andere beim DD-Formmailer richtig konfiguriert hat.
Man kann das auch bei mir hier testen, unter Kontakt, wo sonst? :-)

Und zum Schluß noch ein wichtiger Hinweis: Falls man im WP-Wurzelverzeichnis eine php.ini hat, muß diese ebenfalls mit in das /kontakt/-Verzeichnis kopiert werden, denn im Unterschied zur .htaccess werden die dort gemachten Einstellungen nicht auf Unterverzeichnisse “vererbt”.

Es war mir ja schon fast am Anfang meiner Strato-Zeit aufgefallen. Die Servervariable HTTP_HOST liefert immer den Hostname mit einem vorangestellten www zurück, selbst dann, wenn der Aufruf ohne www erfolgte. Eigentlich eine eigenwillige, wenn nicht gar falsche Konfiguration des Strato-Severs, denn die Variable HTTP_HOST soll eigentlich genau das enthalten, was der Browser im HTTP-Requestheader übermittelt. Wenn ich also die Seite schnurpsel.de aufrufe, dann sollte eben das da drin stehen, und nicht etwa www.schnurpsel.de. Aber genau das passiert bei Strato (PowerWeb A und S).

Problem

Bisher stellte das auch kein Problem dar, mit dem Neuen Wordpress 2.3 aber schon (deshalb war meine Seite gestern Abend auch zeitweise nicht erreichbar). Ab Wordpress 2.3 ist eine Funktion integriert, die ein sogenanntes “Canonical Redirect” ausführt. Auf das Strato-Problem bezogen bedeutet das, daß eine Weiterleitung z.B. dann stattfindet, wenn der Aufruf der Seite nicht so erfolgt, wie das in der Wordpresskonfiguration eingestellt ist.
Wenn z.B in Wordpress als Blog-Adresse (URL)

http://schnurpsel.de

eingetragen ist, jemand aber die Seite mit

http://www.schnurpsel.de

aufruft, wird er auf

http://schnurpsel.de

umgeleitet (und anders rum). An sich eine sinnvolle Sache, gerade unter SEO-Aspekten.

Was passiert nun aber bei Strato? Die funktion redirect_canonical schaut in HTTP_HOST nach, wie die Seite aufgerufen wurde, stellt fest, daß da ein www steht, aber das Blog ohne www konfiguriert ist. Also wird flux auf die Adresse ohne www weitergeleitet (diese Information bekommt der Browser zurück). Der ruft dann brav die Seite erneut ohne www auf, weil aber Strato das www wieder vorneran stellt, leitet redirect_canonical erneut um, der Browser ruft wieder brav ohne www auf usw. usw. Es ensteht also eine Weiterleitungs-Endlosschleife, die der Browser dann aber (hoffentlich) nach ein paar Versuchen mit einer Meldung beenden sollt. Beim Firefox sieht das dann so aus:

Fehler: Umleitungsfehler
Die aufgerufene Website leitet die Anfrage so um, dass sie nie beendet werden kann.

Das alles tritt aber nur beim Blog selber auf, der Adminbereich ist davon nicht betroffen.

Lösung

Aber auch hier gibt es mit einem bißchen Basteln Abhilfe. Glücklicherweise gibt es in den Servervariablen einen Eintrag, der die tatsächlich aufgerufene Adresse enthält, nämlich SCRIPT_URI. Dieser enthält die vollständigen Aufrufadresse mit http und gegebenfalls Verzeichnis und Dateiname, z.B.

http://schnurpsel.de

Hier kann man einfach den echten Hostanamen extrahieren und der Variable HTTP_HOST zuweisen. Und schon ist die Welt wieder in Ordnung :-)

Also Wordpress-Plugin sehen die paar Zeilen PHP-Code dann so aus:

<?php
/*
Plugin Name: 123 True HTTP Host
Plugin URI: http://schnurpsel.de/wordpress-23-problem-ohne-www-bei-strato-65/
Description: Setzt den wahren HTTP_HOST aus dem Request. Bei Strato wird immer www davor geschrieben.
Author: Ingo Henze
Version: 0.10
Author URI: http://putzlowitsch.de/
*/
$plw123thh = parse_url( $_SERVER['SCRIPT_URI'] );
if( isset( $plw123thh['host'] ) && ($plw123thh['host']!=$_SERVER['HTTP_HOST']) )
  $_SERVER['HTTP_HOST'] = $plw123thh['host'];
?>

Mann kann den Quelltext hier einfach rauskopieren, in einer Datei speichern,auf den Server in das Pluginverzeichnis kopieren und aktivieren. Oder man nimmt das fertige Plugin als ZIP-Datei.

Download: 123 True HTTP Host 0.10

Im Übrigen tritt das Problem mit der Weiterleitungs-Endlosschleife bei einer Konfiguration mit www nicht auf, allerdings funktioniert dann das redirect_canonical auch nicht, weil die Seiten ja scheinbar immer korrekt mit www aufgerufen werde.

Generell kann ich die Lektüre der Permalink-Codex-Seite wärmstens empfehlen. Da bekommt man einen guten Überblick, was Permalinks sind, wie sie funktionieren und was man alles damit machen kann (und was nicht). Die Seite sollte auch mal auf Deutsch bei Wordpress-Deutschland aufgenommen werden, viele Fragen im WPD-Forum drehen sich um Permalinks und wären sicher mit dieser Seite einfach beantwortet.

Das muß aber nicht bei der index.php-Variante bleiben, denn das Problem ist ein ähnliches wie bei den Strato-PowerWeb-Paketen, bei denen zwar ein Apache mit mod_rewrite läuft, dieses aber vom Kunden nicht genutzt werden kann. Wenn man es doch versucht, wird das knallhart mit einem 500er Fehler bestraft. Wie man es bei Strato doch hinbekommt, habe ich hier beschrieben.

Für den IIS ist der Ansatz ganz ähnlich. Es wird ein benutzerdefiniertes Fehlerdokument für den Fehler ‘404 Not Found’ “mißbraucht” und dieses ist einfach die ‘index.php’ im Wordpress-Wurzelverzeichnis. Was anderes macht die RewriteEngine praktisch auch nicht, bis auf einen kleinen, aber wichtigen Unterschied. Beim Fehlerdokument wird der Status auf 404 gesetzt, so das der normale Nutzer im Browser zwar keinen Unterschiede sehen würde, denn er bekommt die Seite ganz normal angezeigt. Ein Suchmaschinen-Robot würde die Seite aber wie einen “Not Found”-Fehler behandeln und nicht weiter beachten. Deshalb ist das in der Beschreibung genannte Plugin erforderlich, welches den Status wieder ordentlich zurechtbiegt.

Etwas anders liegt die Sache beim IIS. Wenn eine benutzerdefinierte Fehlerseite als URL aufgerufen wird, wird vom Webserver der Status auf ‘200 OK’ gesetzte und der Fehlerseite als Parameter der Fehlerstatus und die aufgerufene Seite mitgegeben. Hier ist dann die Fehlerseite dafür zuständig, den Status entsprechend korrekt zu setzen. Eine sehr schöne Vereinfachung gegenüber den Verrenkungen, die bei der Stratolösung nötig sind.
Die einzig wirkliche Aufgabe besteht darin, aus dem übergebenen Parameter die eigenlich aufgerufene URL dem Wordpress als REQUEST_URI unterzujubeln, da daraus dann mit den Permalinkregeln die anzuzeigende Seite ermittlet wird.

Lange Rede, kurzer Sinn, genau das macht mein neues Plugin “123 IIS Permalink“. Es ermöglich also auch unter IIS die schönen Permalinks ohne dem /index.php/… Vorspann :-)

(  ) Deine letzten Beitäge
(•) Eine statische Seite (unten auswählen)
        • Startseite: [Start      [▼]]
        • Beitragsseite: [Blog      [▼]]

Das ist weitestgehend selbsterklärend. Mit ‘Eine statische Seite’ aktiviert man die statische Startseite, obwohl die durchaus auch eine gewisse Dynamik haben kann, wie ich das hier beschrieben habe. Bei ‘Startseite’ wählt man, ja genau, die künftige Startseite aus den bisher erstellten statischen Seiten aus.

Nun möchte man aber bestimmt den Lesern auch die Blogbeiträge in der gewohnten Form präsentieren, und nicht nur auf das Archiv, den Kalender oder die Kategorien verweisen. Genau hier kommt die zweite Auswahlmöglichkeit ‘Beitragsseite’ ins Spiel. Am besten man erstellt sich eine weitere Seite und gibt ihr z.B. den Titel “Blog”. Diese kann man nun für ‘Beitragsseite’ auswählen und fortan wird das Blog wie sonst auf der Startseite auf eben dieser Seite angezeigt, inklusive der Möglichkeit, seitenweise vor- und zurückzublättern.

Ja, feine Sache würde ich sagen, an der Stelle mal ein Lob an die WP-Entwickler. Bin schon auf die Version 2.3 gespannt…

Zunächst wird eine Kopie der Datei ’single.php’ erstellt und z.B. ’start_page.php’ genannt. In diese wird ganz oben, noch vor “<?php get_header(); ?>” Folgender Quelltext eingefügt:

<?php
/*
Template Name: Startseite
*/
?>

Damit haben wir diese Seite zum Seiten-Template ernannt.
Nun sind noch einige, weitere Änderungen erforderlich. Damit auf der Startseite auch die Sidebar ordentlich dargestellt werden kann, ändern wir gleich nach dem “<?php get_header(); ?>” das

<div id="content" class="widecolumn">

in

<div id="content" class="narrowcolumn">

und fügen direkt danach noch folgendes ein:

<?php
  query_posts('showposts=1');
?>

Falls wir den in der erstellten Startseite enthaltenen Text z.B. als Willkommenstext ausgeben wollen, kann dazwischen noch folgendes eingefügt werden:

<div class="post" id="willkommen">
	<div class="entry">
		<?php the_post(); the_content(''); rewind_posts(); ?>
	</div>
</div>

Über die ID “willkommen” kann dann dieser Text in der style.css noch individuell formatiert werden. Der Klassenname des inneren DIV sollte dem bei den normalen Beiträgen entsprechen. So hat man schonmal eine brauchbare Grundformatierung.

Somit sieht sieht der Anfang unserer ’start_page.php’ dann etwa so aus:

<?php
/*
Template Name: Startseite
*/
?>
<?php get_header(); ?>

	<div id="content" class="narrowcolumn">
		<div class="post" id="willkommen">
			<div class="entry">
				<?php the_post(); the_content(''); rewind_posts(); ?>
			</div>
		</div>

<?php
  query_posts('showposts=1');
?>
  <?php if (have_posts()) : while (have_posts()) : the_post(); ?>

		<div class="navigation">

Damit die Sidebar auch tatsächlich angezeigt wird, müssen wir den entsprechenden Code get_sidebar() fast ganz am Ende direkt vor get_footer() einfügen. Das sieht dann etwas so aus:

<?php get_sidebar(); ?>

<?php get_footer(); ?>

Nun die Datei speichern und in des Theme-Verzeichnis auf dem Server übertragen.

Jetzt erstellen wir über ‘Schreiben’->’Seite schreiben’ eine neue statische Seite. Der geben wir als Titel zum Beispiel “Start”. Der Inhalt darf leer bleiben, den bekomen wir eh nie zu sehen, dafür soll ja der letzte Artikel angezeigt werden kann z.B. einen Willkommenstext enthalten, der vor dem eigentlichen Artikel ausgegeben wird. Wichtig ist, das wir rechts unter ‘Template der Seite’ das gerade erstellte Template “Start” auswählen. Nun kann die Seite gespeichert werden und wir wechseln in den Einstellungen-Bereich.

Unter ‘Einstellungen’->’Lesen’ klicken wir bei ‘Startseite’ für ‘Anzeige’ die Option

(•) Eine statische Seite (unten auswählen)

an und wählen die Seite “Start” als Startseite aus:

Startseite: [Start     [▼]]

Nun die [Einstellungen aktualisieren] und falls ich nichts vergessen hab, ist der aktuelle Beitrag nun die Startseite

Mal gucken, ob es geklappt hat…

Nachtrag: Ja, scheint zu funktionieren :-) Große Freude!