Das Plugin mg404rewrite konnte ich erfolgreich entfernt in der Umgebung des Providers testen, Zeit das Plugin zu aktualisieren.

Die neue Version ist auf der Plugin-Seite und im WordPress Plugin Directory.

Die letzten vier Teile der AdWz-Serie haben die Erweiterungen für das Plugin mg404rewrite zur Umsetzung der Idee aus AdWz WP-Plugin 14 – Post beschrieben.

Der HTTP-Response wird kurz vor dem Senden durch das Plugin ausgewertet und in allen Formularen mit der Methode Post wird eine auflösbare URL (Nicht-Permalink) gesetzt.

Im letzten Schritt muss diese auflösbare URL durch ein weiteres Skript (PostProxy) verarbeitet werden.

PostProxy

Das Unbekannte – ein Formular mit der Methode Post an eine Permalink-URL – muss mit übertragenen Daten die ursprüngliche Permalink-Anfrage simulieren.

1
2
3
4
5
6
7
8
9
10
11

<?php
	if (isset($_POST["mg404_posturl"]) && isset($_POST["mg404_level"])) {
		$url =  parse_url($_POST["mg404_posturl"]);
		$_SERVER["REQUEST_URI"] = $url["path"];
		for ($i=0; $i<$_POST["mg404_level"]; $i++) 
			$chdir .= "../";
		chdir($chdir);
		if (is_file("index.php"))
			include("index.php");
	}
?>

Abgesichert durch die Abfragen in Zeile zwei und acht werden zur Simulation der ursprünglichen Permalink-Anfrage die Umgebungsvariable REQUEST_URI überschrieben (Zeile 4) und die Datei index.php von WordPress eingebettet (Zeile 9).

REQUEST_URI wird durch WordPress ausgewertet und sollte wie eine normale mod_rewrite Permalink-Anfrage verarbeitet werden.

weiter …

Das Plugin funktioniert mit der letzten Erweiterung in der lokalen Entwicklungsumgebung. Bevor die neue Version 0.7 auf der Plugin-Seite und im Plugin-Verzeichnis von WordPress.org aktualisiert wird, müssen die Änderungen noch entfernt in der vorgegebenen Umgebung des Providers getestet werden.

Erst einmal eine AdWz-Pause und dann demnächst auch die neue Version …

Im diesen Teil der AdWz-Serie werden die regulären Ausdrücke aus AdWz WP-Plugin 17 – Regex im Plugin mg404rewrite eingesetzt.

mg404_PostProxy

1
2
3
4
5

function mg404_PostProxy($content) {
	$formregex = "/" . get_option('mg404_postproxy_formregex') . "/i";
	$content = preg_replace_callback($formregex,'mg404_FormProcessor',$content);
	return $content;
}

In der für den Ausgabepuffer angemeldeten Funktion (Zeile 1) wird der reguläre Ausdruck (Zeile 2) aus der Konfiguration gelesen und für die Suche aufbereitet. In PHP werden reguläre Ausdrücke am Anfang und Ende durch ein / gekennzeichnet. Das Zeichen i führt diesen Ausdruck unabhängig der Groß- / Kleinschreibung aus.

Die Funktion preg_replace_callback (Zeile 3) meldet für diesen regulären Ausdruck eine Funktion an. Sollte im Ausgabepuffer eine Form mit der Methode Post vorhanden sein, wird die angemeldete Funktion (mg404_FormProcessor) zur Auswertung ausgeführt.

mixed preg_replace_callback  ( mixed $pattern  , callback $callback  , mixed $subject  [, int $limit  [, int &$count  ]] )

Jeder Treffer wird der Funktion übergeben und ausgewertet zurück gegeben. Am Ende wird der modifizierte Ausgabepuffer überschrieben und gesendet.

mg404_FormProcessor

1
2
3
4
5
6
7
8
9
10
11
12
13

function mg404_FormProcessor($match) {
	$formtag = $match[0];
	$urlregex = "/" . get_option('mg404_postproxy_urlregex') . "/i";
	preg_match($urlregex,$formtag,$actionurl);
	$linkregex = "/" . get_option('mg404_postproxy_linkregex') . "/i";
	if (preg_match($linkregex,$actionurl[1]))
		return $formtag;
	$postproxyurl = get_option('siteurl') . "/" . get_option('mg404_postproxy_url');
	$formtag = str_replace($actionurl[1],$postproxyurl,$formtag);
	$formtag .= "<input type='hidden' name='mg404_posturl' value='" . $actionurl[1] . "'/>";
	$formtag .= "<input type='hidden' name='mg404_level' value='" . substr_count(get_option('mg404_postproxy_url'),'/') . "'/>";
	return $formtag;
}

In der für den regulären Ausdruck angemeldeten Funktion (Zeile 1) wird der Treffer als Array übergeben. Mehrere Treffer würden im Array durch Gruppierung (Klammerung) im regulären Ausdruck übergeben, da in diesem Fall nur ein Treffer vorhanden sein kann wird der erste Index (0) in der Variable formtag (Zeile 2) abgelegt. Die URL der Aktion wird extrahiert (Zeile 4) und in actionurl zur weiteren Verarbeitung abgelegt. actionurl wird überprüft (Zeile 6) und bei einem nicht vorhandenen Permalink wird die Funktion vorzeitig ohne Veränderung verlassen (Zeile 7). Im anderen Fall wird das Form-Tag überarbeitet und zusätzlich der ursprünglichen URL der Aktion zurück gegeben (Zeile 9-12).

weiter …

Der Ausgabepuffer wird der Konfiguration entsprechend ausgewertet. Zu guter Letzt muss PostProxy zur Simulation die angefragte URI überschreiben und die Datei index.php von WordPress einbetten. Ein weiteres Skript wird demnächst im nächsten Teil der AdWz-Serie erstellt.

Regex; regular expressions (reguläre Ausdrücke) – in den 1960ern von Ken Thompson für die Entwicklung von qed und grep zuerst benutzt – sind Suchmuster, um eine definierte Menge aus einer Zeichenkette zu extrahieren. Vom Suchen, Ersetzen bis Prüfen können in vielen Editoren, mit Tools wie z.B. grep und in so gut wie allen Programmiersprachen reguläre Ausdrücke verwendet werden.

Beispiel eines regulären Ausdrucks zur Überprüfung einer E-mail-Adresse in richtiger Schreibweise (Syntax).

^([a-zA-Z0-9]((\.|\-)?[a-zA-Z0-9])*)@([a-zA-Z]((\.|\-)?[a-zA-Z0-9])*)\.([a-zA-Z]{2,8})$

Auf den ersten Blick kompliziert, aber angefreundet mit der Syntax kann schnell mit diesem mächtigen Tool viel Arbeit gespart werden.

Ohne weiter auf das o.a. Beispiel einzugehen werden für die Erweiterung des Plugins zur Verarbeitung der Post-Forms an Permalinks einige reguläre Ausdrücke verwendet.

mg404rewrite

Im ersten Schritt werden alle Formulare mit der Methode Post gesucht. Die URL der Aktion wird extrahiert und zur weiteren Verarbeitung überprüft.

Varianten

Folgende Varianten – bestimmt nicht vollständig – müssen durch reguläre Ausdrücke gefunden und ausgewertet werden.

1
2
3
4
5
6
7

... <form method="post" action="mypermalinkurl"> ...
... <form method='post' action='mypermalinkurl'> ...
... <form method=post action=mypermalinkurl> ...
... <form action="mypermalinkurl" method="post"> ...
... <form action='mypermalinkurl' method='post'> ...
... <form action=mypermalinkurl method=post> ...
... <form method="post" action="mypermalinkurl"> <input ...>myinputfield</input> ...

Regex Form-Tag

Regulärer Ausdruck wird auf dem übergebenen Ausgabepuffer angewendet.

Kurz notiert von links nach rechts.

<form

Findet genau die angegebene Zeichenketten.

<form.+method=

Das Ergebnis wird auf viele Zeichen bis zum Ende der Zeichenkette method= erweitert. . für ein beliebiges Zeichen und + (Wiederholungsfaktor: min. 1) für mindestens eins oder mehrere des vorhergenden regulären Ausdrucks (beliebiges Zeichen, der Punkt .).

<form.+method=["']?post

Der Ausdruck wird durch die Zeichen in eckigen Klammern und ? (Wiederholungsfaktor: optional) zusätzlich der Zeichenkette post um optional ein “ oder ein ‘ erweitert, um die unterschiedlichen Notationen abzudecken (siehe Varianten Bsp. Unterschiede Zeile 1 “, 2 ‘ und 3).

<form.+method=["']?post.*?>

Das Form-Tag – nicht mehr und nicht weniger – wird benötigt. Durch die letzte Erweiterung beliebiges Zeichen . in beliebiger Anzahl * (Wiederholungsfaktor: eins, viele oder keins) bis zum abschließenden Zeichen >, wird das Tag Form im ganzen gefunden.

Nicht mehr durch das letzte ? (non-greedy). Ohne das Fragezeichen hinter dem Wiederholungsfaktor würde das Ergebnis bis zur letzten > des Ausgabepuffers reichen – etwas viel (siehe Bsp. Variante Zeile 7).

Die Wiederholungsfaktoren sind erst einmal “gierig” (greedy) – bis zum letzten und durch die zusätzliche Angabe ? wird der Ausdruck “genügsam” (non-greedy) – bis zum ersten aufgelöst.

Regex Action-URL

Regulärer Ausdruck wird auf das Ergebnis von Regex Form-Tag angewendet.

.*action=["'](.*?)["' >]

Referenzierung auf die URL durch die Klammerung. Die URL wird im zweiten Schritt ausgewertet, da die Reihenfolge der Attribute im Form-Tag nicht bekannt ist (siehe Bsp. Variante Zeile 1-3 und 4-6).

Gut, mit Look-around assertions hätte man bestimmt in einem Schritt auch die URL ermitteln können, aber wollen ja auch nicht übertreiben.

Regex Non-Permalink

Regulärer Ausdruck wird auf das Ergebnis von Regex Action-URL angewendet.

Wie der Webserver eingehende Anfragen auswertet, kann außerhalb der Umgebung nicht für alle Fälle vorhergesagt werden.

Der folgende Ausdruck soll die URL zur weitere Verarbeitung auswerten. Endet die URL auf .php ist die Zieladresse bestimmt kein Permalink und das Formular muss nicht berücksichtigt werden.

.*\.php$

$ kennzeichnet das Ende der Zeichenkette und \ hebt die Metabedeutung des nächsten Zeichens . auf.

weiter …

Die Konfigurationswerte für die regulären Ausdrücken können im Administrationsbereich auf der Seite Einstellungen / Verschiedenes abgelegt werden.

Apropos Konfiguration: Bin gleich über einen Fehler gestolpert. Die Werte wurden nicht richtig dargestellt. Das Zeichen ” hatte den Wert der Eigenschaft value vorzeitig beendet. Die in der Form darzustellenden Werte einfach zuvor mit der WordPress-Funktion attribute_escape() anpassen.

Soviel erst einmal zu den regulären Ausdrücken. Das Plugin muss nur noch erweitert werden, damit alle Post-Forms an Permalinks verarbeitet werden können. Dazu ein anderes mal mehr … :-)

Wieso jetzt auf einmal Konfiguration?

Die Erweiterung zur Verarbeitung gesendeter Daten mit der Methode Post an eine Permalink-URL wird jede Antwort auswerten müssen. Durch diese Auswertung wird jede Anfrage zusätzlich Last erzeugen. Die Erweiterung sollte mindestens de-aktivierbar sein, da nicht jeder Formulare in dieser Variante einsetzt.

Zusätzlich werden Daten für reguläre Ausdrücke, Erkennungskriterien für Permalinks und die PostProxy-URL in der Konfiguration abgelegt, damit nicht bei jeder kleinen Änderung das Plugin angepasst werden muss.

WordPress & Konfiguration

Konfigurationen werden in der Datenbanktabelle wp_options verwaltet. Eine nicht verlinkte WordPress-Seite http://[meinblog]/wp-admin/options.php zeigt alle vorhandenen Optionen auf einer Seite an. Seit WordPress 2.7 wurde eine Settings API hinzugefügt, um Einstellungen leicht über die Administration verwalten zu können.

Das Plugin wird dann nur noch ab Version 2.7 funktionieren, aber was solls – WordPress sollte so und so auf dem aktuellsten Stand gehostet werden.

Settings API

Im ersten Schritt muss die Konfiguration über die Aktion “admin_init” initialisiert werden.

add_action('admin_init','mg404_settings_api_init');

In der angemeldeten Funktion zur Initialisierung werden Administrationsbereich, Felder und Callback-Funktionen definiert.

function mg404_settings_api_init() {
	add_settings_section('mg404_setting_section', 'mg404rewrite', 'mg404_setting_section_callback', 'misc');
	add_settings_field('mg404_postproxy_enable', 'Activate PostProxy', 'mg404_postproxy_enable_callback', 'misc', 'mg404_setting_section');
	register_setting('misc', 'mg404_postproxy_enable');
}

Hatte versucht die Felder passend dem Administrationsbereich “Permalink” zuzuordnen. Leider – warum auch immer – funktioniert die Settings API nicht auf dieser Konfigurationsseite? Die Bereiche media, reading, writing und misc konnte ich erfolgreich testen. WP-Bug? mg404rewrite Einstellungen werden jetzt erst einmal misc “Verschiedene Einstellungen” zugeordnet.

add_settings_section

Die Funktion add_settings_section ordnet die Optionen einem Bereich in der Administration zu.

add_settings_section($id, $title, $callback, $page)

• $id – Bezeichner zur späteren Referenzierung (im o.a. Bsp.: mg404_setting_section).
• $title – Titel wird als Überschrift im (Unter-)Bereich ausgegeben (im o.a. Bsp.: mg404rewrite).
• $callback – Callback-Funktion, um u.a. eine Beschreibung auszugeben (im o.a. Bsp.: mg404_setting_section_callback).
• $page – Namen der Konfigurationsseite (general, reading, writing, media etc.). Bereich wird am Ende dieser Seite hinzugefügt (im o.a. Bsp.: misc).

add_settings_field

Die Funktion add_settings_field fügt ein Feld auf der Konfigurationsseite hinzu.

add_settings_field($id, $title, $callback, $page, $section = 'default', ...)

• $id – Eindeutiger Bezeichner für das anzulegende Konfigurationsfeld (im o.a. Bsp.: mg404_postproxy_enable).
• $title – Titel wird als Kurzbeschreibung links vom Feld ausgegeben (im o.a. Bsp.: Activate PostProxy).
• $callback – Callback-Funktion, um die Form zur Verwaltung auszugeben (im o.a. Bsp.: mg404_postproxy_enable_callback).
• $page – Namen der Konfigurationsseite (general, reading, writing, media etc.). Muss mit dem angegebenen Wert $page in add_settings_section übereinstimmen (im o.a. Bsp.: misc).
• $section – Muss mit dem angegebenen Wert $section in add_settings_section übereinstimmen (im o.a. Bsp.: mg404_setting_section).
• …

register_setting

Die Funktion register_setting meldet ein Feld zur Verwaltung durch WordPress an.

register_setting($option_group, $option_name, ...)

• $option_group – ? (im o.a. Bsp.: misc).
• $option_name – Muss mit der $id aus add_settings_field übereinstimmen (im o.a. Bsp.: mg404_postproxy_enable).
• …

Callback-Funktionen

Die Funktion mg404_setting_section_callback gibt lediglich eine Beschreibung für den zuvor definierten Konfigurationsbereich aus.

function mg404_setting_section_callback() {
	echo "<p>Intro text for our settings section</p>";
}

mg404_postproxy_enable_callback muss zur Verwaltung die Felder mit der dazugehörigen ID für die Form ausgeben und zusätlich muss der Wert über get_option($id) richtig gesetzt werden.

function mg404_postproxy_enable_callback() {
	$checked = get_option('mg404_postproxy_enable');
	if ($checked) 
		$checked = " checked='checked' ";
	echo "<input {$checked} name='mg404_postproxy_enable' id='mg404_postproxy_enable' type='checkbox' value='1' class='regular-text code'>";
}

Fertig?

Mit einigen zusätzlichen Feldern sollte das Formular wie folgt aussehen.

weiter …

Der Einstiegspunkt wurde in AdWz WP-Plugin 15 – HTTP-Response gefunden und eine Möglichkeit, das Plugin zu konfigurieren, hier beschrieben. Demnächst etwas über reguläre Ausdrücke, damit auch die richtigen POST-Forms gefunden werden … :-)

Im ersten Schritt zur Umsetzung der Idee aus
AdWz WP-Plugin 14 – Post muss die Seite vor der Auslieferung (HTTP-Response) angepasst werden. In der Antwort müssen alle enthaltenen Formulare mit der Methode Post gefunden werden. Wann oder wo Formulare eingebaut werden ist zuvor nicht bekannt. Die Verarbeitung muss kurz vor der Auslieferung erfolgen, damit alle aktivierten Plugins und andere WordPress Anpassungen die Anfrage vor dem Plugin mg404rewrite ausgewertet haben.

Vergeblich auf der Suche nach einem guten Einstiegspunkt (Hook) in der WP-API habe ich die PHP-Funktion ob_start – Ausgabepufferung aktivieren – gefunden.

ob_start – Ausgabepufferung

Die Funktion ob_start aktiviert die Ausgabepufferung. Durch die Pufferung werden die Interpreterausgaben nicht direkt an den Anfrangenden (Client) gesendet sondern intern gesammelt. Dieser Funktion kann optional ein Parameter zur Nachbearbeitung des Pufferinhalts übergeben werden. Der übergebene Parameter wird aufgerufen wenn der Pufferinhalt am Ende der Ausführung ausgegeben wird (Callback). Der Ausgabepuffer wird der Funktion übergeben und eine Zeichenkette kann als neue Ausgabe zurück gegeben werden.

bool ob_start  ([ callback $output_callback  [, int $chunk_size  [, bool $erase  ]]] )

Ein guter Einstiegspunkt, um alle möglichen Formulare kurz vor der Response zu finden.

Auch WordPress benutzt ob_start. Die Suche im Verzeichnis $WP_HOME/wp-include zeigt die folgenden vier Treffer.

$ grep ob_start *
functions.php:			ob_start();
general-template.php:	ob_start();
theme.php:	ob_start( 'preview_theme_ob_filter' );
widgets.php:		ob_start();

WordPress & ob_start

Der erste Test, den HTTP-Response zu verändern, könnte mit diesen Informationen schon durchgeführt. Aber im wordpress.org-Forum habe ich noch folgenden Hinweis gefunden.

In mindestens einer Konfiguration wird der Response komprimiert gesendet. Mit der verdichteten Antwort kann in der Callback-Funktion nicht viel angefangen werden. Die Ausführung muss vor der WordPress-ob_start gesetzt werden. Ein kleiner Workaround …

function mg404_ob_start() {
	ob_start('mg404_PostProxy');
}
 
add_action('template_redirect', 'mg404_ob_start');

Die Aktion “template_redirect” wird durch WordPress kurz vor der Auslieferung aufgerufen und die eigene Funktion mg404_ob_start() meldet die Funktion mg404_PostProxy über ob_start zum Rückaufruf durch die Ausgabepufferung an.

Test

Der folgende Test stellt durch die CallbackAusgabepufferungFunktion jeder Seite “MyCallBack” voran.

function mg404_PostProxy ($content) {
	return "MyCallBack" . $content;
}

weiter …

Die erste Voraussetzung ist erfüllt, bevor die nächsten Schritte in der Funktion mg404_PostProxy getestet werden, wird im nächsten Schritt erst einmal eine leichte Konfigurationsmöglichkeit angesehen.

Die Entwicklung des Plugins mg404rewrite hatte ich eigentlich mit der mod_rewrite Aktivierung bei Strato eingestellt, aber das Plugin wurde mittlerweile bei wordpress.org um die 300 mal heruntergeladen und eine mögliche Lösung für die Verarbeitung übermittelter Formulardaten durch die Variante Post ist mir schon vor einiger Zeit eingefallen.

Problem

Der Workaround, Permalinks durch eine benutzerdefinierte Fehlerseite auflösen zu können, funktioniert nicht für übertragene Daten mit der Methode Post.

Eine Lösungsmöglichkeit für eine oder wenige Seiten mit Formularen beschreibt Ingo Henze in “Es geht doch, Kontaktformular mit POST und Permalinks“.

Aber für viele Seiten wird die manuelle Lösung schnell unübersichtlich und mit etwas Dynamik wie z.B. durch ein Plugin auf mehr oder weniger allen Seiten unmöglich.

Wie könnte eine allgemeine Lösung durch ein Plugin aussehen?

Idee

Die mit der Methode Post versendeten Formulardaten müssen durch eine auflösbare URL verarbeitet werden und der ursprünglichen Permalink-URL übergeben werden.

Ein Filter wird die auszuliefernde Seite nach Formularen mit der Methode Post durchsuchen. Sollte die Action-URL eine Permalinkstruktur haben wird diese durch eine eigene URL (PostProxy) ausgetauscht und die ursprüngliche URL zur weiteren Verarbeitung im Formular hinzugefügt. Die Daten werden zur auflösbaren URL (PostProxy) gesendet und müssen wie bei einer Permalink-Anfrage verarbeitet werden. PostProxy wird zur Simulation die angefragte URI überschreiben und die Datei index.php von WordPress einbetten. WordPress sollte wie bei einer regulären Anfrage den Rest übernehmen.

Lösung?

Lokal konnte ich die Idee erfolgreich mit einem Plugin – welches Daten via Post an Permalinks versendet – testen. Demnächst dann auch eine erste mg404rewrite-Beta … :-)

Das Plugin mg404rewrite läuft seit einigen Monaten stabil in diesem Blog und wurde in der einen oder anderen WordPress-Installation mit aufgenommen. Grund genug sich die ToDo-Liste anzusehen. “Conditional Gets” und “HTTP-Post” werden durch das Plugin noch nicht verarbeitet. Dieser Teil der Artikelserie “AdWz …” setzt sich mit dem Thema “Conditonal Gets” auseinander.

“Conditional Gets” werden u.a. für sogenannte Feeds benötigt. WordPress, andere Blogs und viele Quellen im weltweitem Netz bieten einen Newsfeed an.

Feed oder Newsfeed (RSS oder Atom) ist ein elektronisches Nachrichtenformat, das dem Nutzer ermöglicht, über Inhalte einer Website, Änderungen daran oder Nachrichten in gegebenenfalls zusammengefasster Form auf dem Laufenden zu bleiben.

Dazu werden sie als sogenannte RSS-Feeds abonniert. RSS ist ein Service, der ähnlich einem Nachrichtenticker die Überschriften mit einem kurzen Textanriss und einen Link zur Originalseite enthält. Der Abonnent des RSS-Feed kann direkt den angebotenen Links folgen und dort die vollständige Meldung lesen. Zum Lesen eines RSS-Feeds dienen herkömmliche Webbrowser oder spezielle Programme, die auf die Ähnlichkeit zum Nachrichtenticker angepasst sind. Letztere nennt man (synonym) RSS-Aggregatoren, RSS-Reader oder Feedreader.

Durch Eingabe der Adresse des Feeds im entsprechenden Feedreader wird dieser „abonniert“. Neu veröffentlichte Inhalte werden dann vom Feedreader selbsttätig in regelmäßigen, vom Empfänger festgelegten Abständen auf die Endgeräte – PCs oder auch Mobiltelefone, PDAs oder mobile Spieleplattformen – der Abonnenten geladen. Dadurch erhalten diese die aktuellen Informationen automatisch. Es ist nicht mehr notwendig, selbst die Webseiten zu besuchen, um nach Änderungen zu schauen. Das vereinfacht insbesondere die Beobachtung einer großen Menge von Quellen wie z. B. Blogs, in denen es nicht unbedingt regelmäßig zu Änderungen kommt, deren Aktualisierung man aber nicht verpassen möchte. Im Unterschied zur Benachrichtigung per E-Mail geht die Initiative bei RSS vom Empfänger aus, der den Feed abonniert hat.

Die bedingten Anfragen (“Conditional Gets”) ermöglichen die Anfrage der Aktualität der Nachrichten, bevor der gesamte Feed geladen werden muss. Dadurch wird der Datenverkehr zwischen entferntem Server und dem Empfänger reduziert. Zusätzlich wird der Webserver entlastet, da der Feed nur generiert werden muss, wenn der Empfänger aktuellere Nachrichten anfordert.

Die Analyse habe ich mit dynamische Lesezeichen im Firefox und der Firefox-Erweiterung “Live HTTP Headers” durchgeführt.

1. Dynamisches Lesezeichen “Kommentare fuer mgBlog” angelegt.

http://mgsimon.de/comments/feed/
 
GET /comments/feed/ HTTP/1.1
Host: blog.mgsimon.de
...
HTTP/1.x 200 OK
...

2. Dynamisches Lesezeichen aktualisieren.

http://mgsimon.de/comments/feed/
 
GET /comments/feed/ HTTP/1.1
Host: blog.mgsimon.de
...
If-Modified-Since: Fri, 15 Feb 2008 12:24:59 GMT
If-None-Match: "54d9a49f036b8357cf01ac034fa84c2d"
...
HTTP/1.x 304 Not Modified
...

3. Kommentar erstellen und dynamische Lesezeichen aktualisieren.

http://mgsimon.de/comments/feed/
 
GET /comments/feed/ HTTP/1.1
Host: blog.mgsimon.de
...
If-Modified-Since: Fri, 15 Feb 2008 12:24:59 GMT
If-None-Match: "54d9a49f036b8357cf01ac034fa84c2d"
...
HTTP/1.x 200 OK
Date: Fri, 15 Feb 2008 17:09:58 GMT
...

Der Test zeigt eine funktionsfähige bedingte Anfrage. Im ersten Schritt wird der Feed abonniert und vollständig geladen. Anschliessend werden im zweiten Schritt aktuellere Informationen angefordert. Die Kommentare sind unverändert und die Anfrage wird richtig mit 304 Not Modified beantwortet. Der Nachrichtenkanal muss nicht geladen werden. Der letzte Versuch fragt erneugt nach aktuellere Informationen als die lokal vorhandenen an. Dieser wird mit 200 OK beantwortet, da die angeforderten Informationen neuer als die lokalen sind. Ein Kommentar wurde hinzugefügt und der Feed wird geladen.

Wie der Test zeigt verarbeitet das Plugin “mg404rewrite” bedingte Anfragen richtig. Der Punkt “Conditional Gets” funktioniert auch ohne weitere Anpassungen und kann von der ToDo-Liste gestrichen werden. :-)

In der Blogosphäre werden die Blogs untereinander vernetzt. Die erforderlichen Links werden durch Trackbacks oder Pingbacks erzeugt. Dazu werden zwischen den beteiligten Weblogs nach einem festen Protokoll Daten ausgetauscht, die die Beziehung zwischen den betreffenden Einträgen herstellen. Der Titel, Name des Blogs, die Quelladresse und ein Auszug aus dem Artikeltext werden der Zieladresse über eine HTTP-Post Anfrage übertragen.

Sollte ein Fehler auftreten (HTTP-Statuscode 404 Not Found) werden die Daten einer Anfrage über HTTP-Post vom Webserver nicht der Fehlerseite übergeben. Die Permalinks für Trackbacks in der Form http://mgsimon.de/sample-post/trackback werden mit der Lösung über die Fehlbehandlung nicht funktionieren.

Die HTTP-Post Anfrage kann direkt an die Adresse (http://mgsimon.de/wp-trackback.php?p=126) für Trackbaks ohne Permalinks gesendet werden. In der Ansicht eines Beitrags wird ein Trackbacklink am Ende des Artikels angeboten, welcher in Abhängigkeit der URL-Konfiguration die Trackbackadresse anzeigt.

Die WordPress Plugin API ermöglicht über den Filter ‘trackback_url’, die URL zu manipulieren.

Die folgende Funktion ändert die URL für Trackbacks in die ursprüngliche Form ohne Permalinkstruktur, damit die Daten über HTTP-Post verarbeitet werden können.

function mg404_trackback_url() {
	global $id; // ID des Beitrags
	return get_option('siteurl') . '/wp-trackback.php?p=' . $id;
}

Die folgende Zeile meldet die Funktion als Filter für ‘trackback_url’ an.

add_filter( 'trackback_url', 'mg404_trackback_url' );

Die aktuellste Version des Plugins ist auf der Plugin-Homepage zu finden.

Das Plugin mg404Rewrite überschreibt bis zur Version 0.4 bei erfolgreichen Anfragen den HTTP-Statuscode 404 Not Found durch 200 OK, damit Permalinks auch ohne das Apache-Modul mod_rewrite funktionieren.

Nicht immer wirklich richtig, denn WordPress sendet bei Trackback-Referenzen (die Dinger zur Selbstreferenzierung der Blogs untereinander) nicht den HTTP-Statuscode 200 OK. Der Code 302 Found mit der Referenz zum dazugehörigen Beitrag wird gesendet, damit anschliessend dieser angezeigt werden kann.

Version 0.5 wird diesen Sonderfall durch eine kleine Änderung berücksichtigen.

Damit bei einer nicht vorhandenen Anfrage die richtige Antworte – HTTP-Statuscode 404 not found – gesendet werden kann, wird der Header exklusiv unter der folgenden Bedinung überschrieben.

if (!is_404())
...

Die WordPress-API bietet die Möglichkeit über die Funktion is_trackback einen Trackback abzufragen. Das Blog sendet bei nicht aktivem Permalinks oder nutzbaren mod_rewrite Regeln den HTTP-Statuscode 302 Found mit einem Verweis auf den dazugehörigen Beitrag. Der Statuscode wird von WordPress in diesem Fall geändert und sollte nicht durch das Plugin auf 200 OK gesetzt werden.

Die folgende kleine Änderung ist ausreichend, um auf Trackback-URL richtig zu reagieren, denn das Plugin soll nichts machen – WordPress wird die Verarbeitung übernehmen.

if (!is_404() && !is_trackback())
...

Die aktuellste Version des Plugins ist auf der Plugin-Homepage zu finden.