THM-404-Manager

Aus THM-Wiki
Wechseln zu: Navigation, Suche


iCampus-Projekt
Arbeitstitel THM 404-Manager
Kurs Web Programming Weeks
Betreuer Prof. Dr. Kneisel
Projektbeginn SS 13
Mitarbeiter Steven Sänger, Christian Schröder, Till Albert, Ilyas Yildiz
Programmiersprache PHP
Framework Joomla!

Features

Ablaufdiagramm
Ansicht com_redirect

Der THM-404 Manager ist ein Plugin zur Beseitigung fehlerhafter bzw. veralteter URLs auf der MNI Seite. Wird auf der MNI Website eine 404 Page aufgerufen, wird vor dem automatischen Eintrag in die Komponente "com_redirect" das Plugin getriggert.

  • Legt bei Aufruf einer ungültigen URL eine Umleitung an
  • Ermittelt durch Reduzieren der ungültigen URL eine gültige bei Aufruf einer veralteten Domain (fh-giessen.de) wird die Umleitung auf eine aktuelle (z.B. www.mni.thm.de) gelegt
  • Angabe von Domains im Backend zur Ersetzung
  • Option Redirects ohne individuelles Aktivieren freizuschalten
  • nicht abhängig vom Core-Plugin ‘redirect’
  • (Erweiterte Filterungsmöglichkeiten und verbesserte grafische Darstellung von com_redirect)(Nicht realisiert)
  • (Möglichkeit für autorisierte Nutzer fehlerhafte Umleitungen im Frontend zu korrigieren)(Nicht realisiert)

Gruppe

Das Projekt wurde von den Studenten des Fachbereichs MNI Ilyas Yildiz(Scrum Master), Christian Schröder und Till Albert nach dem Vorgehensmodell “Scrum” entwickelt. Steven Sänger fungierte dabei als Product Owner. Das Projekt ist auf [Redmine|https://scm.thm.de/redmine] und im [Gitorious der THM|https://scm.thm.de/+wpw13-thm-404-manager] zu finden.

IST-Zustand

Auf der Seite des Fachbereichs MNI der THM werden jedes Semester viele Beiträge veröffentlicht, welche jedoch meist nur für ein Semester verfügbar sein sollen und anschließend archiviert werden. Oft passiert es jedoch, dass in noch bestehenden Beiträgen auf archivierte Beiträge verlinkt wird. Sobald dieser Link aufgerufen wird, entsteht ein 404-Fehler, welcher im Backend der MNI-Seite in der Joomla Komponente com_redirect aufgeführt wird. Jeder dieser Einträge muss nun eigenhändig geprüft und mit einem neuen Link angepasst werden. Zur Lösung des Problems mithilfe einer Joomla-Entwicklung stehen keinerlei Ansätze oder Hilfen zur Verfügung.

SOLL-Zustand

Dem THM Mitarbeiter, welcher die Einträge in com_redirect verwaltet wird viel Arbeit abgenommen. Alle Einträge sollen automatisch vorgenommen und vom Mitarbeiter ggf. nur noch überprüft werden.

Analyse der Links

Beschreibung der Analyse-Methoden

  • Phrasensuche im Browser

Phrase search.png

  • Analyse der Datenbank-Tabelle der Links durch SQL-Anfragen

Sql statement.png
Durch die Auswertung der vorhandenen Links können die URLs zum Umleiten identifiziert, klassifiziert und (massen-)verarbeitet werden.

Ergebnisse der Analyse Datei:Statistik.pdf

Mögliche Ursachen für 404 Fehler:

  • Veraltete Lesezeichen
  • Suchmaschinen verfügen über veralteten Indexe der Website
  • Falsch eingegebene Adressen
  • Fehlende Zugriffsrechte
  • gelöschte, deaktivierte oder archivierte Inhalte(Beiträge, Kategorien), Menüs, ....
  • Änderung der Pfade
  • Migration von Joomla! Versionen
  • ...

Mögliche Ursachen für fehlenden Eintrag "Bezugnehmende Seite":

  • Wenn eine falsche URL direkt im Browser eingegeben wird.
  • Durch Verwendung der übermittelten Variable $_SERVER["HTTP_REFERER"]
Ein leerer Eintrag kann enstehen, wenn der Browser das übermitteln der Variable nicht unterstützt/blockiert.
Siehe php.net $_SERVER Dokumentation

Tippfehler am Ende einer URI: Liegt am Ende einer URI eine ID zum Beitrag, so ist es egal, ob im Name des Beitrags anschließen Tippfehler vorkommen. Der Beitrag wird dennoch ohne Fehler geladen. Beispiel:

Der normale richtige Link:

http://www.mni.thm.de/index.php/startseite/alle-praktika-thesis-jobs/informatik-allg/3430-abschlussarbeit

Url mit Tippfehler am Ende, dennoch ein gültiger Link:

http://www.mni.thm.de/index.php/startseite/alle-praktika-thesis-jobs/informatik-allg/3430-abschlussarbeawa

Aufbau und Funktionsweise

Der 404-Manager ist in mehrere Bereiche aufgeteilt. Die Grundfunktionalität beinhaltet das 404-Manager-Plugin welches beim Aufruf einer 404-Seite getriggert wird. Dieses trägt in die veränderte com_redirect Komponente die neue URL ein, welche durch einen speziellen Algorithmus ermittelt wird.

Optional und nicht umgesetzt:

Optional kann beim Aufruf einer 404-Seite ein Dialog im Frontend angezeigt werden, welches erscheint, wenn der Benutzer die nötigen Rechte hat. Dort kann er eine neue URL eintragen, ohne umständlich ins Backend zu wechseln. Falls der Benutzer nicht die Rechte hat oder keine Eingabe getätigt hat, erfolgt der normale Ablauf des 404-Manager-Plugin.

Zusammenspiel Core Plugin und THM 404-Manager

Beim Aufruf einer veralteten URL wird zuerst das System Plugin "Redirect" ausgeführt, welches einen Datenbankeintrag mit der veralteten URL und weiterein Informationen macht. Anschliessend wird das Plugin "THM-404-Manager" aufgerufen, welches die veraltete URL bearbeitet und ggf. weitere Konfigurationen wie das Auto-Publishing der neuen URL übernimmt.

404-Manager-Plugin

Auszug aus error.php

Das entwickelte Plugin soll das Core-Plugin 'redirect' sowie indirekt die Komponente com_redirect unterstützen. Dabei werden die Links analysiert, bearbeitet und in die Datenbank eingetragen, auf welche die Komponente zugreift. Das Plugin besitzt 3 Funktionalitäten, die chronolgisch abgearbeitet werden.

Mapper

Prüfen ob veraltete Domain vorhanden, und ggf. ersetzen durch neue.

Validator

Prüft ob die vorliegende URL zu einem 404-Fehler führt.

Dem Validator wird zu Beginn die zu überprüfende URL übergeben und mit dieser eine cURL Session aufgebaut. Gleichzeitig wird in der Datenbanktabelle #_redirect_links in der entsprechenden Zeile ein Flag (im Commentfeld) gesetzt.
Die cURL Session löst den 404-Manager wieder auf, also wird überprüft ob eine Session mit dem übergebenen Link wieder auf der 404 Seite enden wird.
Ist dies der Fall wird das Flag neu gesetzt, die cURL Session beendet und anhand dieses Flags letztendlich entschieden ob die Prüfung erfolgreich bzw. nicht erfolgreich war. Das Flag wird am Ende des Algorithmus wieder aus der Datenbank entfernt.

Reduzierer

Reduziert die URL um eine Instanz

Wird die aktuelle URL vom Validator als invalide gekennzeichnet, entfernt der Reduzierer die letzte Instanz der URL und lässt den Validator erneut prüfen

Beispiel für den Ablauf des Algorithmus

1. Eingabe URL. mni.fh-giessen.de/studium/käse (ungültiger Link)
2. Plugin wird durch ausgelösten Trigger aufgerufen.
2.1.Aufruf Mapper: mni.fh-giessen.de ersetzen durch mni.thm.de und Migration auf aktuellen Joomla!-Linkstruktur
2.2 Aufruf Validator: mni.thm.de/studium/käse wird auf Gültigkeit geprüft und liefert false.
2.3 Aufruf Reduzierer: Entfernen der letzten Instanz: “käse”.
2.4 Aufruf Validator: mni.thm.de/studium wird auf Gültigkeit geprüft und liefert true.
>>> Falls Validator false liefert: Solange Aufruf von Reduzierer bis der Validator letzendlich true zurückgibt
3. Eintrag in com_redirect.

Optionale Funktionalität: Erweiterte Darstellungs- und Administrations-Möglichkeit (nicht realisiert)

Als Optionale Funktionalität wird die vorhandene Core-Komponente com_redirect als Basis für die Entwicklung einer neuen Komponente verwendet. Die erweiterte Komponente stellt folgende zusätzliche Funktionalitäten bereit:

  • Farbige Darstellung der vom Plugin eingetragenen URLs.
  • Rot: Noch nicht bearbeitet
  • Rot mit Warnung-Symbol: Ein Fehler auf der Referring-Page ist aufgetreten.
  • Gelb: Der Link wurde erfolgreich eingetragen und muss vom Nutzer freigegeben werden.
  • Grün: Alles in Ordnung, Link wurde vom Nutzer freigegeben.
  • Die genannten Kategorien können sortiert angezeigt werden.
  • Massenbearbeitung: Mehrere URLs können gleichzeitig freigegeben werden.
  • Sortierung der URLs anhand Klicks.

Optionale Funktionalität: Interaktive Steuerung im Frontend (nicht realisiert)

Anzeige eines Dialogs, beim ersten Aufruf einer 404-Seite. Dabei wird zwischen 2 Sichten unterschieden:

  • Eingeloggter autorisierter Nutzer:
Bekommt die Möglichkeit in einem Dialogfeld eine passende URL einzutragen.
  • Nicht eingeloggt:
Kann sich als autorisierter Nutzer einloggen. Falls er nicht autorisiert ist, wird die URL vom 404-Manager ohne Eingabe des Nutzers bearbeitet.

Umsetzung: 404-Manager-Plugin

Umsetzungsmöglichkeiten des Plugins

  • Ein Plugin, welches die Funktionalitäten des Core-Plugin "Redirect" erweitert, also den kompletten Datensatz inkl. neu ermittelter URI in die Datenbank einträgt. Dazu: Deaktivierung des Original Core-Plugin
  • PRO:
  • Zentralisierung aller Funktionen.
  • Weitergabe an die Community(direkt im Kern realisiert als fester Bestandteil)
  • CONTRA:
  • Zunächst bzw bei Ablehnung der Community muss das Core-Plugin deaktiviert werden.
  • Wartung des neuen Plugins bei wichtigen neuen Funktionen im Core-Plugin.
  • Das original Core-Plugin bleibt unverändert und aktiviert. Das neue Plugin schreibt die neu ermittelte URI in den Datensatz des Core-Plugin. Dabei wird das neue Plugin zeitlich direkt NACH dem Core-Plugin ausgeführt.(in dieser Form realisiert)
  • PRO:
  • Unabhängige Handhabung der Ermittlung der neuen URI (Verfahren jederzeit änderbar)
  • Weitergabe an die Community(als eigenes Plugin ebenfalls möglich)
  • CONTRA:
  • Ein zusätzliches Plugin, das vom Core-Plugin abhängig ist (Was passiert, wenn Core-Plugin deaktiviert?)
  • Redundanter Code in beiden Plugins (zur Ermittlung ob Eintrag in der Datenbank vorhanden).

Abfolge des Plugins:

1. Aufruf des Plugins wenn ein Link aufgerufen wird, durch SystemEvent.
2. Prüfung ob 404 Fehler. Wenn ja, dann weitere Schritte abarbeiten.
3. Aufgerufene URL an den Algorithmus als Parameter übergeben.
4. Neu ermittelter Datensatz in die Datenbank-Tabelle jos_redirect_links.
5. Darstellung der Inhalte aus jos_redirect_links in der Komponente com_redirect.

Probleme und Prämissen

Während der Umsetzung sind verschiedene Probleme aufgetreten, welche enorm viel Zeit in Anspruch genommen haben. Wir mussten einige Gegebenheiten hinnehmen und unsere Planung daran anpassen.

  • Schlechte Dokumentation der Plugin-Event Methoden.

In der Dokumentation der Plugin-Events sind lediglich die Content-Events beschrieben. Zur Speicherung der 404-Links in die Datenbank muss das Plugin aber deutlich früher aufgerufen werden. Des weiteren sind generell viele, vor allem für uns essentiell wichtige Funktionen kaum bis gar nicht dokumentiert, was sehr viel Zeit gekostet hat.

  • Keine Ermittlung der 404-Fehler durch HTTP-Header
In der Planung gingen wir davon aus, dass wir beim Aufruf unseres Plugins durch betreten einer Seite einen fehlerhaften Link anhand dem HTTP-Header erkennen können. Im Header der fehlerhaften Aufrufe steht jedoch ebenfalls "HTTP 200:OK", da die "404-Seite" der MNI Homepage aus technischer Sicht ein unpublished Beitrag ist, auf den die Funktion "redirect" (Aufruf in /templates/templatename/error.php) weiterleitet bzw. einen neuen Request an den Server stellt.
  • Abhilfe wurde dadurch geschaffen, dass der Administrator die URI zur 404-Seite, auf die weitergeleitet werden soll, im Backend des Plugins angibt. Diese URI wird anschließend mit jedem Aufruf einer Seite abgeglichen und somit bei Übereinstimmung der Algorithmus zum Bearbeiten der URL angestoßen. Nachtrag: Nicht möglich, da dadurch die ursprungs URL verloren geht.
  • System-Redirect-Plugin als Basis zur Entwicklung: Neuer Ansatz(05.09.2013)
Anstatt 404-Aufrufe selbst zu erkennen, übernehmen wir dazu den Algorithmus des Core-Plugins "Redirect".
  • System-Redirect-Plugin als Basis zur Erweiterung, das Original dabei deaktivieren: Neuer Ansatz(06.09.2013)
Ursprünglich war am 05.09.2013 geplant, dass unser Plugin direkt nach dem System-Plugin aufgerufen wird. Nach intensiven Untersuchungen haben wir vorerst keine Möglichkeit gefunden dies zu tun, ohne dabei das System-Plugin zu verändern. Denn zur Behandlung eines Fehlers (in diesem Fall 404) kann nur ein Callback-Argument angegeben werden: entweder das System-Plugin oder unser eigenes. Lösung: Das original System-Plugin deaktivieren, und dieses in einem neuen Plugin erweitern. Eventuell wird in einem späteren Sprint weiter Analysiert, ob die strikte Trennung von eigenem und System-Plugin möglich ist.
  • Probleme bei der Realisierung des Validators(09.09.2013)

Zum testen ob die reduzierte URI gültig ist muss eine cURL-Session aufgebaut werden, welche durch einen Aufruf der neuen URI deren Status ermittelt. Leider ist es nicht möglich die URI zu bekommen, auf die im Falle eines 404-Fehler weitergeleitet wird, welche wir zum ermitteln eines 404-Fehlers der neuen URI benötigen, denn im Header wird weiterhin nicht 404 zurückgegeben. Somit müssen wir uns eines Tricks bedienen und der cURL-Session einen Cookie mitgeben, der am Anfang der handleError Methode auf Existenz überprüft wird, sprich um zu checken ob die handleError-Methode durch die cURLsession ausgelöst wird bzw. der Request der neu erzeugten URI wieder einen 404 Error werfen würde.

  • Probleme bei der Realisierung des Validators mit Cookie(09.10.2013)

Nach vielen Versuchen den Validator mit einem Cookie umzusetzen, muss auch dies verworfen werden, da es mit den von cURL gegebenen Funktionen nicht möglich ist eine laufende cURL-Session aus sich selbst heraus zu beenden. Ein weiterer Ansatz ist die Umsetzung mit einem Datenbankeintrag. Dieser wird den Cookie ersetzen und somit als Kennzeichen dienen, dass die handleError-Methode durch eine cURL-Session ausgelöst wurde. Dieses Kennzeichen wird in das Comment-Feld des Datenbankeintrags geschrieben und nach beenden der Prüfung wieder auf NULL gesetzt.

Setzung der Reihenfolge des Plugins

Während der Installation des Plugins wird mit einem PHP-Skript die Reihenfolge des System-Plugins "redirect" ausgelesen, und der THM-404-Manager durch einen Datenbankeintrag dahinter gesetzt. Sobald nun ein Administrator die Pluginreihenfolge ändert, erscheint ihm ein Fehler, dass der THM-404-Manager an der falschen Stelle steht.

Installation/Benutzung

Konfigurationsmöglichkeiten
1.Plugin im Menüpunkt "Erweiterungen" installieren.
2.Unter "Erweiterungen" -> "Plugins" nach "plg_thm_404_manager" suchen und aktiveren.
3.In den Einstellungen des Plugins die Funktion "Auto Publish" ggf. anschalten. (Auto Publish sorgt für eine automatische Freigabe der neu generierten Links)
4.Domains eintragen, welche durch den Mapper durch eine neue Domain(ebenfalls eintragen) ersetzt werden.
5.Im Menü Unter "Komponenten" -> "Umleitungen" die Einträge ansehen und ggf. anpassen.

Abhängigkeiten

Das entwickelte Plugin "THM-404-Manager" arbeitet zusammen mit dem vorinstallierten System-Plugin "Redirect". Dabei nimmt das System Plugin dem "THM-404-Manager" arbeit ab. Allerdings wurde der "THM-404-Manager" so entwickelt, dass er auch eigenständig, ohne das System-Plugin funktioniert. So ist gewährleistet, dass der "THM-404-Manager" auch nach einem großen Update mit inhaltlichen Veränderungen des System-Plugins weiterhin funktioniert.