mgBlog

(AdWz; Auf dem Weg zum) WP-Plugin 9 – 500 Internal Server Error

Der HTTP-Status-Code wird in Abhängigkeit der Anfrage auf 200 OK geändert. Wird keine Seite geschrieben und auch nicht die Einstellungen der Permalinks geändert läuft das Plugin ohne Probleme. Denn diese Aktionen der Administration verändern die .htaccess-Datei. WordPress wird nicht mehr funktionieren, alle Anfragen werden mit 500 Internal Server Error beantwortet.

Die nächste Erweiterung soll die von WordPress erzeugten mod_rewrite-Einträge in die .htaccess-Datei verhindern.

Damit die Permalinklösung über die Fehlerbehandlung funktioniert, sind die folgende manuellen Schritte erforderlich.

• .htaccess-Datei anpassen
• WordPress RewriteRules entfernen
• ErrorDocument 404 $INSTALLATIONSVERZEICHNIS/index.php eintragen
• schreibender Zugriff durch CHMOD 444 .htaccess unterbinden

Ohne diese Anpassungen würde WordPress nach Änderung der Permalinkstruktur oder Erstellung einer Seite folgende Fehlerseite anzeigen.

Internal Server Error
The server encountered an internal error or misconfiguration and was unable to complete your request. Please contact the server administrator, service@webmailer.de and inform them of the time the error occurred, and anything you might have done that may have caused the error.

More information about this error may be available in the server error log.

Gegenüber den meisten anderen WordPress-Plugins ein manueller Installationsaufwand, der nicht unbedingt notwendig ist. Auch die nicht technisch begabten Blogger sollen dieses Plugin ohne viel Computerwissen – gibst die? :-) – installieren können.

Im folgenden wird das Plugin um diese Funktionalitäten erweitert.

(weiterlesen…)

(AdWz; Auf dem Weg zum) WP-Plugin 8 – Plugin 4 All

Das Plugin in der Version 0.2 überschreibt in Abhängigkeit der Anfrage den HTTP-Status-Code, damit Permalinks durch das Workaround über eine benutzerdefinierte Fehlerseite funktionieren. Abgesehen von dem noch manuellen Installationsaufwand reicht es aus, um der Allgemeinheit das Plugin zur Verfügung zu stellen.

(weiterlesen…)

(AdWz; Auf dem Weg zum) WP-Plugin 7 – 404 Not Found

Der “Hack” über die “index.php” (siehe WordPress NoRewrite & 404) und das Plugin “mg404Rewrite” (siehe AdWz WP-Plugin 5 – 200 OK) überschreibt den HTTP-Header immer mit dem erfolgreichem HTTP-Code 200 OK. Nicht wirklich gut für die Robots der Suchmaschinen.

Sollte unter der Domäne entfernte Seiten vorhanden gewesen sein, sind diese unter Umständen noch im Index der Suchmaschinen enthalten. Die Robots werden auch bei älteren Links zu nicht mehr vorhandenen Seiten keinen HTTP-Code 404 erhalten. Diese Referenzen werden aus dem Index der Suchmaschine nicht entfernt.

Das Plugin soll in der nächsten Version exklusiv HTTP-Code 200 OK ausliefern, wenn die Seite vorhanden ist.

(weiterlesen…)

(AdWz; Auf dem Weg zum) WP-Plugin 6 – OpenSourcePerle muCommander

Die Dateien (WordPress-Plugin o.ä.) vom lokalen zum entfernten Rechner zu übertragen, ist mit dem vom Betriebssystem zur Verfügung gestellten Möglichkeiten (u.a. ftp) meistens mit viel Aufwand verbunden. Auf der Suche nach einem Tool konnte ich muCommander finden.

muCommander läuft – geschrieben in Java – auf so gut wie jedem Betriebssystem und unterstützt nicht nur die notwendigen Protokolle zur Dateiübertragung. Viel Spass beim spielen a la Norton Commander. :-)

(AdWz; Auf dem Weg zum) WP-Plugin 5 – 200 OK

Zurück zum eigentlich Ziel, ein Plugin um über eine eigene Fehlerseite das Modul “mod_rewrite” umgehen zu können.

Im ersten Schritt soll das Plugin alle Anfragen mit dem HTTP-Code 200 OK beantworten. Der beschriebene Hack im Beitrag WordPress NoRewrite & 404 wird duch dieses Plugin nicht mehr benötigt.

Die Integration über die WordPress-Plugin-API kann über einen Filter oder Aktion erfolgen. Da die Beiträge durch dieses Plugin nicht verändert werden sollen, wird eine geeignete Aktion gesucht (siehe AdWz WP-Plugin 4 – Hooks). Viele mögliche Aktionen werden auf der Seite Liste der Aktionen aufgelistet. Für die Auswahl der richtigen Aktion müssen das Protokoll HTTP und die spätere 404-Behandlung berücksichtigt werden. Die Aktion “template_redirect” erfüllt beide Bedinungen.

(weiterlesen…)

(AdWz; Auf dem Weg zum) WP-Plugin 4 – Hooks

Das erstellte Plugin aus AdWz WP-Plugin 3 – Struktur erfüllt lediglich die Schnittstelle zur De- und Aktivierung auf der Administrationsseite der Erweiterungen. Keine Erweiterung wird durch diese Vorlage wirklich in WordPress integriert. Damit weitere Funktionalitäten durch ein Plugin angeboten werden können, muss die Ausführung der Aktion definiert werden. Die WP-Plugin-API ermöglicht die Ausführung zu definierten Zeitpunkten über sogenannte Hooks. Hooks werden in zwei Varianten – Filter und Aktionen – angeboten. Die Filter werden eingesetzt, um einen Inhalt wie z.B. der Beiträge vor der Auslieferung zu manipulieren. Aktionen werden vor einer benannten WordPress-Aktion wie z.B. “Beitrag speichern” ausgeführt. Die Implementierung eigener Erweiterungen erfolgt über selbstgeschriebene Funktionen, welche über die WordPress-API als Filter oder Aktion anzumelden ist.

(weiterlesen…)

(AdWz; Auf dem Weg zum) WP-Plugin 3 – Struktur

Die lokale Entwicklungsumgebung ist installiert, ein Editor zur Bearbeitung der Quelltexte in PHP wurde vorgestellt. Nun zum ersten Teil der Struktur eines Plugins für WordPress.

WordPress ermöglicht durch eine spezifizierte Schnittstelle (WP-Plugin API) die Integration weiterer Funktionalitäten. Die Administrationsseite “Site Admin” / “Plugins” zeigt alle aktuell installierten Plugins an. Die Plugins können aktiviert, deaktiviert und konfiguriert werden. Damit WordPress die Plugins auf dieser Seite zur Verwaltung auflisten kann müssen die Anforderungen der WP-Plugin API erfüllt werden.

(weiterlesen…)

(AdWz; Auf dem Weg zum) WP-Plugin 2 – Editor

Texte in einem vom Betriebssystem mitgeliefertem Editor zu bearbeiten ist oft umständlich. Insbesondere die Bearbeitung von Quelltexten wird zur Qual.

Editoren die Schlüsselwörter komplementieren, die Syntax hervorheben, in der Lage sind Zeilennummern anzuzeigen, Blöcke strukturiert anzeigen und und und … sind für die Entwicklung schon fast unumgänglich geworden.

Am besten Plattformunabhäng, damit nicht nur auf dem lieb gewordenen iBook der gleiche Editor wie auf anderen Betriebssystemen zur Verfügung steht.

JEdit

(weiterlesen…)

(AdWz; Auf dem Weg zum) WP-Plugin 1 – Entwicklungsumgebung

Die Entwicklung auf dem entfernten Rechner, auf welchem das eigene Blog dem weltweitem Netz zur Verfügung gestellt wird, ist nicht wirklich empfehlenswert. Abgesehen von der ständigen Aktualisierung nach jeder Änderung sind nicht funktionierende Zwischenstände unumgänglich. Zusätzlich können die auferlegten Restriktionen des Providers die Entwicklung erschweren.

Eine lokale Entwicklungsumgebung wird erforderlich. Änderungen können unmittelbar ausprobiert werden und nach erfolgreichem Test auf dem enternten Rechner – dem realen Blog – installiert werden.

Auch Updates oder Upgrades können durch die lokal geschaffene Möglichkeit vor der wirklichen Installation getestet werden.
(weiterlesen…)