Web Programming Weeks SS16

Aus THM-Wiki
Wechseln zu: Navigation, Suche
Kurs
Kursname Web Programming Weeks SS 16
Kurstyp Projektkurs
Dozent Priefer, Rost, Dalmulder
Semester SS 16
Studiengang Bachelor, Master Informatik


Diese Seite dokumentiert die Ergebnisse der Gruppenprojekte.


Gruppe 1

Das Team

Name GitHub-Account
Maximilian Kamp mxkmp29
Florian Platte florian1995
Kevin Scheithauer kevinscheithauer
Lukas Schmitt schmidie64

Gemeinsames GitHub-Repository

Aufgaben

#8039 - email cloaking kills email value of input field

Problem

Issue #5080

Das Emailcloaking-Plugin zerstört HTML Attribute und Tags, die ein Attribut mit einer Email-Adresse als Wert haben (Problembeispiel ist ein Input-Feld mit dem value einer Email-Adresse was komplett zerstört wird). PR #8039 löst scheinbar das Problem aber ein anderer User bemerkt ein Problem, das HTML-Tags zwischen dem Tag mit der Adresse zerstört werden (Ein Beispiel wäre: <a href="mailto:myname@gmail.com"><img src="images/sampledata/fruitshop/bananas_2.jpg" alt="" /></a> was einfach in Klartext dargestellt wird und kein Bild anzeigt, wie man es erwarten würde). Nachdem ich versucht habe eine Lösung zu finden entdecke ich, dass das Problem auch im regulären staging branch besteht und nicht mit dem PR zusammenhängt. Ich finde auch heraus, dass PR #11353 das ursprüngliche Problem bereits behebt, aber auch das zweite Problem hat. PR #8039 wird geschlossen, da er obsolet ist.

Lösung

Also versuche ich nun das Problem mit dem HTML-Tags herauszufinden und finde auch schon den scheinbaren Grund für das Problem (die Tags werden in normalen Text dargestellt da sie im Helper dekodiert werden) also veruschte ich den Aufruf der enkodier-Methode auszukommentieren was auch das Problem behebte. Ich habe trotzdem probiert eine bessere Lösung zu finden, da man sich bestimmt etwas bei dem Aufruf gedacht hatte und ich keine unerwarteten Probleme verursachen wollte. Aber bevor ich zu einer geeigneteren Lösung kam wurde das Problem von #11460 gelöst.


#9943 - New feature: Add username check , Issue #9867

Es sollte dem Adminstrator die Möglichkeit gegeben werden im Backend die Länge der Usernamen einzustellen und eine Beschränkung von Zeichensätzen einer Sprache z.B. Englisch.

Der Pullrequest wurde daraufhin bearbeitet und erfüllte die Anforderungen. Es wurde im Backend die Möglichkeit eingeräumt:

  • Buchstaben verbieten
  • Buchstaben erlauben
  • Usernamen mit regulären Ausdrücken zu definieren
  • alphanumerische Zeichen
  • Latin Zeichen
  • Unicode Security
  • Ob ein Username eine Email ist

Neue Anforderungen um den bestehenden Request zu verbessern war eine Domain-Blacklist hinzuzufügen und einen Ajax-Check für den Usernamen im Registrierungsformular einzufügen.

Fehler beim Erstellen des Vorschaubildes: Datei fehlt
Backend Options

Durchführung

Problemlösung: Ajax Für einen Ajax Request wird auf der Serverseite eine PHP Funktion benötigt die innerhalb der Componente auf die Datenbank der Users zugreift und checkt ob der Username schon existiert und darauf ein JSON Array mit den Informationen zurückgibt. In meinem Fall ein JSON String mit einem „success“ und einer „Message“, die bei einem Fehlschlagen mitgegeben wird.

Auf der Clientseite dagegen wird ein einfacher Handler für den Usernamen benötigt, der checkt ob sich etwas auf in dem Textfeld ändert und nach einer Änderung den Ajax Request an die PHP Funktion auf der Server Seite schickt, die Rückgabe auswertet und bei einem Fehler ein Meldung über Joomla ausgibt.

Joomla spezifische Lösung: Um einen Ajax-Request innerhalb der Registrierung der User-Komponente im JSON-Format zu handlen wird eine PHP Datei benötigt, die das JSON Format unterstützt. Das Format wird über einen Parameter vor der Endung gesteuert, d.h. die Datei muss für die register.php den Namen register.json.php heißen. Die Implementierung war ein simpler Datenbankzugriff und das Ergebnis konnte leicht mit Hilfe der PHP Funktion JResponseJson zurück geliefert werden. Die Errormessage wird mit Hilfe der Joomla PHP Bibliothek aus der aktuell gültigen Bibliothek gezogen und in einem JSON String zurückgeliefert. D.h. die Errormessages sind immer auf die beliebige Sprache angepasst. Mithilfe des Javascripts wird die Überprüfung durchgeführt und bei einem Error wird mit Hilfe der Joomla Bibliothek ein Error oberhalb des Registrierungsfeldes ausgegeben.

Blacklisted Domains: Im Backend eine einfaches Textfeld unter den Optionen der Usernamen einbinden. Innerhalb der libraries/form/rule/email.php diese Einträge abfragen und mit Hilfe eines Regexes die Mail überprüfen.

Zusätzliche Ideen: Zusätzlich zu den Username Check implementierte ich einen Email Check und 2 einfache Handler, die überprüfen ob die Email- und Passwortfelder übereinstimmen. Für die Email benutzte ich die selbe Funktion wie für den Username, prüfte nur auf andere übergebene Parameter und konnte durch geringfügige Änderungen eine Funktion für die beiden Fälle nutzen.


PullRequest

PullReqest #11516

Fehler beim Erstellen des Vorschaubildes: Datei fehlt
Frontend: Ajax Check

Probleme: Es gestaltete sich am Anfang schwierig ohne Vorkentnisse die richtige URL für den AJAX-Call zu erstellen und das große Problem war das ich keine register.json.php Datei definiert hatte, deshalb kam keine Fehlermeldung und der Call ging ins nichts. Die größten Probleme kamen nicht innerhalb der Implementierung, mehr mit den Namenskonventionen und dem fehlenden Wissen der eigentlichen Joomla Bibliothek (PHP sowie Javascript), wie ich etwas geschickt in das bereits vorhandene System einbinden kann.

Stand vor dem Pullrequest:

  • Ajax Calls implementiert
  • Domain Blackliste hinzugefügt.
  • Equals Checks für Email und Passwort

Probleme während dem Pullrequest: Anstatt 11 geänderter Dateien wurden 54 Dateien angezeigt. Es musste mit Hilfe von Roland alles nochmal gerebased und neu zusammen gemerged werden.

Änderung während des Pullrequests:

  • Javascript wurde in ein eigenes File ausgelagert.
  • Der Script und Style Teil wurde aus der view.html.php in die default.php ausgelagert.
  • Es wurde eine Überprüfung der Sessiontokens auf der Serverseite hinzugefügt, die im AJAX Call mitgeliefert werden.
  • Laufzeitverbesserungen
  • Errormessage verbesserungen
  • Die Validierung wurde flexible für alle Userkomponenten gestaltet, da sie davor nur auf 'com_users' ausgelegt war.

Fehlermeldung: Es wurden 2 Nachrichten ausgegeben, weil bei einem false von der test() Funktion, die die Eingaben validiert, eine Standardnachrichtung aus der spezfischen XML ausgegeben wird und durch die Funktionen meines Vorgängers die Errornachrichten in die Messagequeue eingereiht werden -> 2 Nachrichten in der Queue die eingeblendet werden.

Der erste Gedanke war, die Standardnachricht aus der config.xml zu löschen, jedoch erscheint dann invalid Field: Feldname. Das ist so wie Joomla momentan arbeitet nicht möglich. Die Arbeit würde den Rahmen sprengen.


Ebenfalls wurde im Backend bemängelt, dass nicht die selbe spezifische Nachricht ausgegeben wird wie im Frontend. Im Backend findet die Validierung der User-Felder mithilfe von Javascript statt. Javascript hat jedoch keinen Zugriff auf die in einem XML für Joomla definierten Sprachkonstanten. Deshalb müsste ebenfalls die gesamte Validierung der Felder angepasst werden. Dies würde in der kurzen Zeit auch den Rahmen sprengen.


#5474 - Filter on multiple Access Levels, Authors, Categories, and Tags

Stand vorher
Fehler beim Erstellen des Vorschaubildes: Datei fehlt
Vor dem Patch

Der Patch soll es möglich machen im Backend bei Articles, Categories und Featured Articles Multiple Filter einstellen zu können. Und zwar soll es möglich sein nach Tags, Access Levels, Categories und Author zu Filtern, was bereits möglich war, aber zum Beispiel mehrere Tags zum Filtern auszuwählen und nicht nur einen. Das Ganze war bereits komplett umgesetzt, jedoch aktualisierte sich die Liste der Ergebnisse nicht, wenn man z.B. den letzten Tag aus dem Filter gelöscht hatte. Außerdem musste das Ganze noch auf verschiedenen Datenbanken getestet werden.

Umsetzung

Pull Request #11517

Ich habe zum Reproduzieren und lösen des Problems folgende Hilfsmittel verwendet: PHPStorm, Xampp, XDebug, MySQL sowie PostgreSQL.

Einarbeitung: Zu Beginn habe ich mich mit der Problemstellung und der Diskussion befasst, welche doch sehr umfangreich war. Nachdem ich mir einen Überblick verschafft hatte, habe ich den bisherigen Stand in mein Repository gemerged und im Backend getestet. Es stellte sich heraus, dass sich die Liste nach entfernen des letzten Tags nicht mehr aktualisierte. Ich musste mich zuerst in den vorhandenen Code einarbeiten und versuchte den Bug zu finden, wobei mir XDebug sehr geholfen hat.

Lösung: Mit XDebug war das Problem, dass wir es in der Projektwoche zwar eingerichtet, jedoch nicht richtig aktiviert hatten und ich es bis zu den WPW wieder vergessen hatte. Somit war es am Anfang schwer zu Debuggen, bis mich Wolf Rost an XDebug erinnerte und mir geholfen hat es einzurichten. Nachdem ich eine Vermutung hatte, erinnerte ich mich an die Diskussion, in der ein User eine mögliche Lösung mit Beispielcode erwähnte, welchen ich beim ersten Mal lesen noch nicht ganz verstanden hatte. Also sah ich ihn mir genauer an, passte ihn entsprechend an und verwendete ihn schließlich um den Bug zu fixen.

Fehler beim Erstellen des Vorschaubildes: Datei fehlt
Nach dem Patch mit Fix

Das Problem war, dass sich die „Multi-Select-Filter“ Felder nach entfernen der letzten Auswahl wie eine Checkbox verhalten, also keinen Wert senden. Das heißt, dass die letzte Auswahl zwar optisch gelöscht wurde, jedoch nicht im Array und somit die Liste nicht aktualisierte. Also fügte ich ein verstecktes Feld hinzu, das überprüft ob Daten gesendet wurden. Bevor die ausgewählten Daten dann in der Variable gespeichert werden, welche zum Filtern verwendet wird, frage ich ab, ob Daten gesendet wurden. Falls dies der Fall ist, hole ich die Daten dann direkt aus dem „Multi-Select-Filter“ Feld und füge sie dann der Session Data hinzu. Vorher wurde direkt die Session Data genommen, die dementsprechend nicht richtig aktualisierte.

Testen und weiteres Vorgehen: Ich testete das ganze erst einmal in Verwendung mit MySQL und danach noch einmal mit PostgreSQL ohne Fehler. Nach dem Testen stellte ich einen Pull Request womit ich ihm der Joomla Community zum Testen bereitgestellt habe. Kurz darauf bekam ich bereits eine Antwort von einem User der den Code noch etwas optimierte. Ich fand die Änderungen gut und mergte seinen Code in meinen Branch, behob noch einige kleine Schreibfehler und wartete von dann an auf weitere Kommentare oder sogar den RTC (ready to commit) Status.

#7964 - Edit Module (Front end) Loses Module Position if Position not defined in Template XML

Problem

Issue #7964

Wenn man eine Position zuweist, die nicht in der template.xml steht, wird die erste Position im Dropdown Menu zugewiesen.

Lösung

Das Problem wird von PR #7540 gelöst.

#6541 - Join content to get attribs in a "tagged items" list

Fehler beim Erstellen des Vorschaubildes: Datei fehlt
Mit Plugin-Trigger und aktivierten Plugins möglich (Kontext zum Verständnis)
Problem

PR#6541

Der PR-Ersteller möchte in der Tag-Item View im Frontend auf zusätzliche Attribute zugreifen, welche in den Ursprungstabellen der Inhalte zu finden sind, aber nicht in der Query "selected" werden. Er hat eine Lösung präsentiert, in der er die entsprechende Query um einen join mit der content-Tabelle und einem select des gewünschten Attributes (in dem Fall die attribs Spalte in der content Tabelle) erweitert. Das problematische dabei ist, das dies überhaupt nicht generisch ist und eine Abhängigkeit zwischen dem Tags-Helper und der Content-Komponente herstellt. Es wird der Vorschlag unterbreitet einen Plugin Trigger zu entwickeln, mit dem die Query bearbeitet werden könnte. Dies versuche ich umzusetzen.

Lösung

Nachdem ich mich über die genaue Bedeutung des Vorschlags und der betroffenen Module informiert habe, habe ich zuallererst den Trigger-Befehl in den Helper geschrieben um dann anschließend selber einige Plugins zu schreiben, die durch diesem Trigger aufgerufen werden um die Tag-Item View mit zusätzlichen Attributen auszustatten. Hierzu habe ich zu den Core Komponenten Content, Newsfeed, Contact und Category jeweils ein Plugin geschrieben womit man bei Content die attribs (wie ursprünglich vom Ersteller gewünscht) und bei den anderen Komponenten die params aus den jeweiligen Tabellen abrufen kann. Beim Entwickeln von passenden Plugins muss man beachten, das man diese zur Gruppe "tags" hinzufügt und das diese die Methode "onTagItemListQuery" implementieren worüber sie die Query erhalten, bearbeiten und zurückgeben können. In meinen Plugins wird die Query um einen join mit der entsprechenden Tabelle und ein select des gewünschten Attributes erweitert und dann zurückgegeben. Die Plugins sind auf meinem GitHub verfügbar und können zusammen mit dem eingeführten Trigger getestet werden.

Der erstellte PR (#11555)

Erfahrungen und Einschätzung

Es war sehr interessant und eine wichtige Erfahrung einmal an einem großen Open-Source-Projekt wie Joomla zu arbeiten. Es war anfangs relativ schwer sich in die große Codebase auch für relativ spezifische und teils eigentlich simple Probleme einzuarbeiten, aber die mächtigen Debugfähigkeiten von PHPStorm und XDebug haben es doch stark vereinfacht. Auch das Wissen und Können von Roland rund um Joomla hat einem den Einstieg in die Problemstellungen relativ einfach gemacht und ohne ihn wären wahrscheinlich deutlich weniger Ergebnisse zustandegekommen. Zudem war der Einstieg mit dem Pizza, Bugs & Fun auch sehr gelungen, da er einen in die Rolle des Testers steckt, an die man bei Erstellung eines PR eben auch denken sollte. Insgesamt haben die 2 Wochen einen gut gefordert, haben aber Spaß gemacht und einen interessanten Einblick in solche Projekte und deren Mitglieder gegeben.

Gruppe 2

Das Team

Alexander Bus
GitHub: faynt0


Artjom Büchert
GitHub: abuechert


Patrick Puzik
GitHub: Curtista

Aufgaben

Refactor 2FA from FOF to Joomla core

Die Aufgabe bestand darin Abhängigkeiten der beiden 2FA-Plugins (Google Auth, Yubikey) zu FOF (Framework over Framework) aufzulösen und die benötigte Funktionalität in den Joomla Core zu integrieren.

- #11553 Refactor 2FA from FOF to Joomla Core

Ablauf der Bearbeitung

  1. Identifikation von Abhängigkeiten zu FOF in beiden Plug-ins.
  2. Code Analyse um herauszufinden ob dieselbe Funktionalität bereits im Joomla Core vorhanden ist.
  3. Innerhalb des Yubikey-Plugins konnte eine bereits vorhandene Methode eingesetzt werden, um die Abhängigkeit aufzulösen.
  4. Das Google-Auth-Plugin benötigte neben der vorhandenen Methode eine zusätzliche Klasse, die von uns implementiert werden musste.
  5. Testing wurde durchgeführt.
  6. Pull request wurde gestellt.

Refactor Post_install from FOF to Joomla core

Bei dieser Aufgabe musste die Abhängigkeit zu FOF für die Joomla Komponente com_postinstall aufgelöst werden.

- #11546 Refactor com_postinstall from FOF to Joomla Core

Ablauf der Bearbeitung

  1. Identifikation von Abhängigkeiten zu FOF.
  2. Code Analyse um herauszufinden ob dieselbe Funktionalität bereits im Joomla Core vorhanden ist.
  3. Da der Aufbau der Komponente sehr stark an FOF angelehnt war musste die Komponente mit der vorhandenen Joomla Core Funktionalität neu aufgebaut werden.
  4. Einige Methoden konnten jedoch fast eins zu eins aus der FOF-Bibliothek in den Joomla Core übernommen werden.
  5. Testing wurde durchgeführt.
  6. Pull request wurde gestellt.

Testing

Das Testen wurde bei den oben genannten Aufgaben sowohl während der Bearbeitung sowie auch nach der Fertigstellung durchgeführt. Da es sich in beiden Fällen um eine refactoring Aufgabe gehandelt hat musste sichergestellt werden das sich die bearbeitete Komponente sowie auch die beiden Plug-ins nach der Bearbeitung genauso verhalten wie sie es zuvor getan haben. In den erstellten PR's wurden zudem nochmals die erforderlichen Schritte aufgeführt um das Ergebnis jeder einzelnen Aufgabe zu testen.

Probleme

Anfangs war es für uns schwierig sich in den Codemassen zurechtzufinden. Nachdem wir dann mit Roland sprechen konnten und er uns ein paar Tipps geben konnte, wurde es für uns einfacher sich in die Thematik einzuarbeiten. Bei der Bearbeitung der Postinstall Komponente standen wir dann wieder vor einem Problem. Wir fingen an die Komponente Stück für Stück in den Joomla Core zu integrieren doch bekamen kein richtiges Feedback da die Komponente fast ausschließlich aus FOF Klassen und Methoden bestand und somit nach einer Änderung die Komponente nicht mehr richtig funktionierte. Nachdem wir dann mit Roland sprachen, gab er uns dann den Rat die Komponente von Anfang an neu aufzubauen. Das stellte sich auch im Nachhinein als beste Variante dar, denn man konnte direkt sehen, ob etwas funktioniert oder nicht.

Erfahrungen

In den zwei Wochen konnte unsere Gruppe eine ganze Menge dazulernen. Wir haben beispielsweise gelernt, wie ein Open Source-Projekt aufgebaut ist und wie man solch ein Projekt aktiv mitgestalten kann. Des Weiteren wissen wir nun auch, dass eine Open Source Community auf der einen Seite stressig sein kann und auf der anderen Seite etwas wunderbares ist, da sehr viele Kompetenzen an einem ort versammelt sind und somit Sachen erreicht werden können, die alleine niemals möglich gewesen wären. Durch die Erfahrungen, die man während der 2 Wochen sammeln konnte, hat man nun eine Grundlage geschaffen und die Scheu verloren, um an einer aktiven OpenSource Community teilzunehmen. Vorallem durch die Unterstützung eines "richtigen" Mitglieds des Projekts (Roland), war der Einstieg viel leichter.

Folgende Fertigkeiten konnten währen den WPW ebenfalls erlangt werden:

  • Ein besserer Umgang mit Git und GitHub.
  • Die richtige Verwendung von XDebug.
  • Umgang mit einer IntellyJ-IDE.
  • Kommunikation mit einer Open Source Community.

Gruppe 4

Aufgaben

Joomla für mySQL 5.7 portieren. Fehlerbeschreibung: NullValue in MySQL 5.7 für Datetime wurde von 0000-00-00 auf 1000-01-01 geändert
Multi-Page-Modules (dropped)

Issues

  • [#11530] - mySQL 5.7 nullDate compatibility fix
  • [#11527] - Wrong Table Layout
  • [#11557] - When RSS feed for COM_FINDER (...)

Schritte zur Realisierung #11530

Erstellen von verschiedenen OS-Containern

 * Debian Stable, mySQL 5.6, Apache2 mit mod-php5
 * Debian SID, mySQL 5.7, Apache 2 mit mod-php7 (using original deb packages)
 * Gentoo Linux, mySQL 5.7, lighttpd mit php5-fcgi (self compiled)
 * Debian Stable (update delivery server)

Debian Stable wurde gewählt, da es als die meist verbreitete Linux-Distribution gilt. Debian SID (Unstable) wurde unter der Annahme gewählt, dass mySQL 5.7 als Package bereits vorliegt. Tatsächlich ist jedoch selbst im SID noch mySQL 5.6 in Nutzung. Jedoch bietet Oracle für mySQL vorkompilierte Debian Pakete an. Gentoo wurde für die selbst kompilierte Version gewählt, da bereits eine fertige Gentoo Instanz vorgelegen hat und diese sich für das Rekompilieren besonders eignet. Der Update Delivery Master (erneut ein Debian Stable) ist optional.

Entwicklung des Patches

Zur Entwicklung des Patches war es notwendig die verschiedenen internen Systeme von Joomla zu verstehen und anzupassen. Das Erschaffen einer Kompatibilität erfordert das Ausführen des Patches bei einer Neuinstallation, einem Update über die GUI und einem Update über die Reparaturfunktionen. Hierbei sind sehr viele kleinere Probleme aufgetreten.


Probleme

mySQL 5.7 verhält sich, je nach Umgebung und Flags bei der Kompilierung, sehr unterschiedlich. So werden in den fertigen, von Oracle zur verfügung gestellten Paketen das Datum 0000-00-00 zum Teil unterstützt. Einige Befehle werden durchgeführt, andere führen zu SQL Fehlern, bis hin zu unbehebbaren Interlocks. Auch sind einige der Updatefunktionen von Joomla nicht für das beheben von SQL Problemen gedacht und verhindern somit das Durchführen von bestimmten SQL Befehlen.


Bugfixes

Es sind einige kleinere Fehler im Code aufgefallen, welche unabhängig von der Aufgabenstellung behoben wurden/werden sollten. Unter anderem sind in den Datenbanken teilweise falsche Feldtypes/Values gesetzt worden (timestamp statt datetime, trotzdem mit 0000-00-00 formatierung).

Testing

Das Testing galt als eines der größten Probleme, da folgende Szenarien geprüft werden mussten:

  • Neuinstallation auf mysql 5.6
  • Neuinstallation auf mysql 5.7
  • Update von mysql 5.6 zu 5.7 bei laufender installation
  • Downgrade von mysql 5.7 zu 5.6 (wurde nicht vollständig geprüft)

jedes Update im Kreuzversuch mit je:

  • Update von Joomla via FTP, via Uploadserver und via Autoupdater

Schritte zur Realisierung #11557

Aufgabe

Im RSS Feed wurde ein PHP Fehler angezeigt, sofern der Server auf einer anderen Sprache gestanden hat als Englisch. Der Ersteller des Tickets hatte bereits eine Idee angegeben, woran der Fehler liegen könnte.

Lösung

Das Problem lag daran, dass ein Datum mehrfach umgewandelt wurde. Hierbei wurde zuerst von einem Datumsstempel auf ein schriftliches Datum gewandelt, um direkt danach in ein Zeitstempel gewandelt zu werden. Dies hat bei nicht englischer Schreibweise einen PHP Fehler erzeugt. Da am Ende bei der Generierung des RSS Feed sowieso eine Umwandlung in ein schriftliches Datum vorgenommen wird konnte einfach der Zeitstempel weitergereicht werden. Es musste jedoch danach der Code überwacht werden, ob diese Änderung eine Auswirkung auf den RSS Code hätte. Tatsächlich hat die Änderung jedoch in den Sprachen Deutsch und Französisch einwandfrei funktioniert. Im RSS wurde weiterhin das lokalisierte Datum verwendet.

Gruppe 9

Das Team

Mehmet-Ali Pamukci
Github: mehmet.ali.pamukci@mni.thm.de


Eduard Ellert
Github: ed20@gmx.net


Florian Kolb
Github: toxic2302

Aufgaben

Namespaces to PSR-4

* libraries/cms and libraries/joomla --> libraries/src/cms
* Extend Classmap file to allow backward compatibility
* Joomla 4 architecture requirement
* github.com/wilsonge/joomla-cms/tree/4.0-dev
* Report of Joomla 4 architecture sprint

Requirements

  1. Repository von George Wilson klonen oder forken
  2. Neuen Branch anlegen
  3. Bei Problemen und Fehlern George Wilson kontaktieren
Fehler beim Erstellen des Vorschaubildes: Datei fehlt
PHP Header with namespace

Workflow

  1. Verschieben eines vorhandenen Ordners von libraries/cms nach libraries/src/cms
Fehler beim Erstellen des Vorschaubildes: Datei fehlt
Classmap.php
  1. Umbenennen des Ordners und aller Unterordner mit großem Anfangsbuchstaben
  2. Alle Dateien des verschobenen Ordners öffnen und den jeweiligen namespace eintragen
  3. Anpassen der nicht mehr zu erreichenden Joomla Klassen mit dem use-Import
  4. Beim Klassennamen das "J" entfernen und die Datei umbennen, sodass diese genauso heißt wie die Klasse
  5. Aktualisierung der classmap.php um eine Abwärtskompatibilität zu gewährleisten
  6. Testen der verschobenen Komponenten

Task

Ab der neuen Version von Joomla (4.0) soll ein einheitlicher Namespace für die vorhandenen libraries auf Basis des PSR-4 geschaffen werden. Alle Komponenten aus libraries/cms und libraries/joomla sollen nun in den Ordner libraries/src/cms verschoben werden. Dann soll jede php Klasse einem eindeutigen namespace zugeordnet sein, damit der Autoloader und die Classmap weiß, wo die Klassen zu finden sind. Die php Klassen sowie Ordner und Dateien müssen umbenannt werden. Bei allen Klassen wie zum Beispiel bei der Klasse JCaptcha wird das J entfernt und die php Datei bekommt den gleichen Namen wie die dazugehörige Klasse. Es soll eine Classmap aufgebaut werden, mit Hilfe dieser man eine Abwärtskompatibilität gewährleistet wird. Dementsprechend wird in dieser Datei eine Alias im System registriert und angegeben wo sich die neue Datei nun befindet.

PSR-4

PSR-0 vs. PSR-4

Issues

Am Anfang gab es das Problem sich richtig in die Aufgabe einzufinden aber nach ein paar guten Tipps seitens George Wilson und Roland lief es besser und schneller. Die größten Probleme gab es bei der Bearbeitung der Ordner Classund Html. Man konnte zum Beispiel den Namespace Joomla\Cms\Class; nicht aufbauen, sodass man den Ordner wie auch die PHP Klasse umbenannt werden muss. Bei Html war das Problem, das nach dem verschieben und anpassen des Namespace, die installierte Joomla Instanz gar nicht mehr funktioniert hat.

Ein weiteres Problem oder Hürde war es, die schon verschobenen Komponenten nachträglich zu korrigieren. Das heißt wenn man bei anderen Komponenten im Namespace noch use JHtml; benutzt hat, musste man nach dem verschieben der JHtml Komponente jedes use JHtml mit use Joomla\Cms\Html\Html; ersetzen. Das gilt auch für jede JHtml Instanz in den Klassen selber. Hier musste man lediglich das J davor entfernen. Mithilfe von PHPStorm ist dies aber problemlos machbar.

Testing

Die Tests liefen eher stupide ab. Manche Komponenten sind so wichtig für das System, das nach dem verschieben der Komponente die komplette Joomla Instanz nicht mehr funktioniert hat. Andere Komponenten musste man dann dementsprechend direkt im System testen, wie zum Beispiel der Editor oder die Toolbar im Backend.

Result

Bis zum Ende der Projektwoche habe ich es geschafft den kompletten Ordner libraries/cms, bis auf die beiden oben genannten Komponenten class und html, zu verschieben und in den neuen Namespace aufzunehmen. Diese beiden Ordner wurden mangels Erfahrung am Joomla System erst mal ausgelassen.

Der nächste Ordner libraries/joomla wurde schon angefangen und einige Komponenten auch schon verschoben und in den neuen Namespace aufgenommen. Bei manchen Dateien die sich in diesem Namespace befinden wurden auch schon die use Imports korrigiert.

Dynamische Editor-Buttons

Diese Aufgabe sieht vor, dass die Funktionalitäten innerhalb der Editoren modularisiert werden sollen. Die Problematik besteht darin, dass diese Funktionalitäten welche hauptsächlich in Form von Buttons existieren in den jeweiligen Editoren "hart-kodiert" sind. Dadurch ist es dem Joomla-Nutzer beispielsweise nicht möglich die Funktionalität des Editors zu erweitern. Ein weiterer Grund für die Notwendigkeit dieser Aufgabe könnte unter anderem auch sein, dass ein Administrator möchte, dass gewisse Funktionalitäten wie z.B. "Drag-and-Drop" nur von einer bestimmten Benutzergruppe verwendet werden soll.

Der durch diese Aufgabe entstandende Mehrwert der Editoren beinhaltet zusammenfassend folgende Vorteile:

  • Einfache Erweiterbarkeit der Funktionalitäten durch den Joomla-Benutzer
  • Konfigurierbarkeit der einzelnen Funktionalitäten
  • Einfachere Wartbarkeit

Vorgaben:

  • Die Editor-Buttons sollen als Joomla-Plugins realisiert werden
  • Die Plugins sollen zur Plugin-Gruppe "editors_buttons" gehören

Hinweis: Nachfolgend wird streng unterschieden zwischen "Joomla-Plugins" und "TinyMCE-Plugins".

Analyse

Die Buttons, also die TinyMCE-Plugins, sind in TinyMCE in dem ../JOOMLA_PATH/media/editors/tinymce/plugins Ordner enthalten und in JavaScript implementiert. An dem Konzept zur Implementierung eines Buttons soll nichts geändert werden. Die Idee ist es, die Buttons in Joomla-Plugins zu packen und somit installierbar zu machen. So sollen weiterhin in Zukunft die TinyMCE-Plugins in JavaScript implementiert und nach der Installation in den selben Pfad kopiert werden. Somit wird die Konsistenz zwischen dem Editor und dem Editor-Button gewährleistet. Die Vorgabe, Buttons als Joomla-Plugin zu realisieren macht es notwendig Anpassungen an der Implementierung von TinyMCE duchzuführen. Nur so kann der "hart-kodierte"-Teil der Implementierung aufgelöst und die Editor-Buttons dynamisch gemacht werden.

Die Nachfolgende Abbildung zeigt das Modell einer möglichen Realisierung nach Auswertung der Analyse:

VorherNachherDragDrop.png

Realisierung

Im Folgenden wird gezeigt wie diese Modularisierung für TinyMCE realisiert werden kann für die Drag and Drop Funktionalität. Da wie bereits erwähnt Anpassungen an der Implementierung von TinyMCE vorgenommen werden müssen, geht es an dieser Stelle los. Die zu bearbeitende Datei befindet sich in : ../JOOMLA_PATH/plugins/editors/tinymce/tinymce.php

Anpassung TinyMCE-Editor

1. Laden der Plugins
Der erste Schritt besteht darin, die Plugins aus der neu erstellten Plugin-Gruppe "editors_buttons" zu laden und mit Hilfe des EventDispatchers die selbst definierte Methode onLoadTiynmcePlugin() zu triggern und das Ergebnis der Variable extraButtons zuzuweisen.


PluginsLaden.png

2. Erstellung der Buttons
Der TinyMCE-Editor hat drei verschiedene Modi. Diese sind der "Simple mode","Advanced mode" und "Extended mode". Standardmäßig ist der "Advanced mode" vorkonfiguriert. So wird an dieser Stelle nur dieser Modus behandelt. Die anderen Modi sind Analog dazu anzupassen. Die nachfolgende Abbildung zeigt, dass die Ergebnisse in $extraButtons zur Liste in der Variable $toolbar1 und zur Liste in den $scriptOption['plugins'] hinzugefügt werden. Hierdurch werden die Buttons dynamisch. Was soviel bedeutet wie, wenn ein Plugin nicht installiert ist, gibt es keine zu triggernde Methode und somit existiert auch kein Button.
Tinymceadvanced.png

Erstellung des JDragDrop-Plugins

Nachdem die Anpassungen an dem Editor vorgenommen worden sind, kann mit der Entwicklung des Joomla-Plugins begonnen werden. Der Großteil der Arbeit hierfür liegt nicht in der PHP-Datei des Plugins wie man erwarten würde, sondern in der XML-Datei. In der Regel muss man nur in der onLoadTinymcePlugin() den Plugin-Namen zurückgeben. Jedoch ist JDragDrop ein Sonderfall da es zur Core-Funktionalität von Joomla gehört. Da die Joomla-Plugins für die Editor-Buttons zur Gruppe "editors_buttons" gehören sollen, geht es direkt mit der Manifest-Datei los, in der man innerhalb des Extension-Tags die Gruppe definiert.

<extension version="3.1" type="plugin" group="editors_buttons" method="upgrade">

Der nächste Schritt besteht darin, dass angegeben werden muss, wohin die Button-Funktionalität (TinyMCE-Plugin) welche sich innerhalb des Joomla-Plugins befindet, kopiert werden soll. Dies geschieht mit Hilfe des Media-Tags in dem man den zu kopierenden Ordnernamen (folder) des Buttons angeben muss (in dem Fall jdragdrop) sowie den Pfad wohin kopiert werden soll. Zugleich müssen alle Dateien innerhalb des Ordners angegeben werden die kopiert werden sollen (File-Tag).

   <media folder="jdragdrop" destination="editors/tinymce/plugins/jdragdrop">
       <file>plugin.js</file>
       <file>plugin.min.js</file>
   </media>

Erstellung der Plugin-Klasse
Der Klassenname zur Erstellung eines Editors-Buttons-Plugin setzt sich zusammen aus:

Plg<Editors_Buttons><NameDesPlugins>
also: class PlgEditors_ButtonsJdragdrop extends JPlugin

Abschließend muss man nur noch die onLoadTinymcePlugin()-Methode definieren und den Plugin-Namen zurückgeben. Da es sich bei JDragDrop um einen Sonderfall wird an dieser Stelle der "überflüssige" Code weggelassen.

class PlgEditors_ButtonsJdragdrop extends JPlugin
 {
  public function onLoadTinymcePlugin()
  {
  ....//Some authentification stuff, settings for upload etc.
  return 'jdragdrop';}
 }
Erstellung des Youtube-Plugins

1. Download des Youtube TinyMCE-Plugins
Das TinyMCE Youtube-Plugin kann hier heruntergeladen werden:

https://github.com/gtraxx/tinymce-plugin-youtube.git

Es existieren auch weitere Youtube-Plugins für TinyMCE die eingesetzt werden können. Das hier genutzte Plugin dient nur zu Demonstrationszwecken.

2. Erstellung des YouTube-Plugins Für die Erstellung eines Youtube-Plugins müssen lediglich die einzelnen Schritte wie bei JDragDrop wiederholt werden. Grob zusammengefasst:

  • Youtube-TinyMCE-Plugin in den Joomla-Plugin-Ordern einfügen
  • XML-Datei anpassen und dabei alle Dateien innerhalb des TinyMCE-Plugins angeben
  • Klasse erstellen
  • Methode onLoadTinyMCEPlugin() definieren und Pluginnamen zurückgeben.