Am 11. April 2017 wurde Joomla! 3.7 RC 2 herausgegeben, die Veröffentlichung der finalen Version Joomla! 3.7 ist für den 25. April 2017 geplant. In Joomla! 3.7 wurden neben den Bugfixes 41 neue Funktionen gepackt, von denen ich mir für dieses Preview die „major features“ genauer angesehen habe.
Wie immer vorab der obligatorische Hinweis, dass Alpha-, Beta- und RC-Versionen nur in abgesicherten Testumgebungen und ausschließlich zum Testen installiert werden sollten. Wer das Upgrade der eigenen Website testen will, sollte folgende Dinge beherzigen:
Zuerst ein Backup der kompletten Website anlegen und sie dann auf den aktuellen Stand Joomla! 3.6.5 bringen sowie alle installierten Erweiterungen aktualisieren. Die Kopie dieser Website in einer Testumgebung installieren und über den Installationsmanger auf Joomla! 3.7 RC 2 updaten.
In Joomla! 3.7 sollte das Backend nur mit dem Template „Isis“ genutzt werden, da „Hathor“ nicht für die neuen Funktionen optimiert wurde. Die empfohlene PHP-Version ist 7.0 oder 7.1 allein schon aufgrund des Performance-Gewinns, aber es sollte auch unter PHP 5.6 und 5.3.10 (minimun) laufen. Die weiteren Systemvoraussetzungen sind hier zu finden.
Die „major features“
Die Funktionen, die nachfolgend näher erklärt werden, sind: Custom Fields (individuelle Felder), Multilingual Associations Component (zentrales UI für Übersetzungen), Improved Workflow (verbesserter Workflow beim Erstellen von Inhalten), Backend Menu Manager (Administrator-Menü des Backends ändern oder neue anlegen), TinyMCE (Verbesserungen und Erweiterungen), Easier Extension Maintenance (Absicherung bei der Deinstallation), User Experience (Verbesserungen der UX).
Neue Router-Funktion
Die noch bis zur Joomla!-Version 3.7 Beta 3 enthaltene neue Router-Funktion wurde wieder entfernt. Es ist geplant, den neuen Router in zwei bis drei Monaten in die Joomla!-Version 3.8 zu integrieren. Über die Gründe informiert diese offizielle Ankündigung. Wer sich für die Hintergründe interessiert, findet in diesem Post die Details dazu. Wer nicht bis Joomla! 3.8 warten und den Router sofort nutzen will, findet dort auch den Hinweis/Link auf den Router als Plug-in, das schon jetzt unter Joomla! 3.6.5 installiert werden kann.
Easier Extension Maintenance
Die vereinfachte Wartung von Erweiterungen soll bei der administrativen Arbeit davor schützen, noch benötigte Elemente eines Paketes zu deinstallieren. Oder vice versa: Entweder werden alle Elemente deinstalliert (zum Beispiel neben den Plug-ins oder/und Modulen auch die dazugehörige Komponente) oder gar nichts.
User Experience
Kleine eingearbeitete Änderungen, die den Unterschied ausmachen: Verbesserungen in der Anzeige der Globalen Einstellungen, ein flacheres Backend-Template und die Möglichkeit, Sessions zwischen Apps zu teilen. Mehr Informationen über das Session-Sharing sind hier zu finden.
Erweiterter TinyMCE
Der Editor TinyMCE erhält mit Joomla! 3.7 die drei neuen Buttons Als Text einfügen, Datum/Uhrzeit einfügen und Formatierung entfernen sowie zusätzlich die drei neuen Plug-in-Erweiterungen: Menü, Kontakt und Field.
Im nachfolgenden Screenshot, der den TinyMCE-Editor in Joomla! 3.7 komplett anzeigt, sind die Neuerungen rot umrandet und alle Plug-in-Erweiterungen (alte und neue) zusätzlich grün hinterlegt.
Zum Vergleich dazu, ein Screenshot des TinyMCE-Editors aus Joomla! 3.6.5 (auch komplett).
Die Plug-in-Erweiterungen sind erreichbar über Erweiterungen -> Plugins -> Klick auf Suchwerkzeuge -> -Typ wählen editors-xtd und werden darüber (de-)aktiviert und konfiguriert. Die anderen Buttons werden über die Einstellungen des TinyMCE-Editors gesetzt, erreichbar wie folgt: Erweiterungen -> Plugins -> Klick auf Suchwerkzeuge -> -Typ wählen editors -> Editor – TinyMCE.
Die neue Funktion Drag & Drop über die sich verschiedene Sets zusammenstellen und unterschiedlichen Benutzergruppen zuordnen lassen, wird nachfolgend gezeigt (dafür bitte auf das Bild klicken).
Improved Workflow
Damit können direkt beim Anlegen eines Menüpunktes ein Beitrag, eine Kategorieliste, ein Kategorieblog oder ein Kontakt erstellt werden. Wie genau das funktioniert zeigt das Video.
Video ansehen
Backend Menu Manager
Also ganz ehrlich? Ich habe hin und her überlegt, gedreht und gewendet, der Sinn dieser Funktion will sich mir einfach nicht erschließen. Wenn man in Joomla! 3.7 ein neues Menü erstellt, hat man nun unten einen Button, der einem die Wahl lässt zwischen Site und Administrator. Das Menü lässt sich somit über „Administrator“ für das Backend erstellen. So weit, so gut.
Ich lege eine neue Benutzergruppe an -> „Testgruppe“, ebenso eine neue Zugriffsebene -> „Testebene“, der ich als einzige Benutzergruppe die „Testgruppe“ zuweise. Zu guter Letzt erstelle ich einen neuen Benutzer „Test“, den ich nur der Benutzergruppe „Testgruppe“ zuweise.
Im Kontrollzentrum unter Konfiguration -> Global erteile ich „Testgruppe“ das Recht Administrationsanmeldung. Testgruppe darf sich im Adminbereich anmelden. Das klappt auch und man findet ein nahezu leeres Backend vor.
Ab hier nimmt man am besten 2 Browser, meldet sich in einem mit der Benutzergruppe „Super Users“ (also als Superadmin kurz Admin) und in dem anderen mit der Benutzergruppe „Testgruppe“ an. Ich navigiere als Admin nun zu Komponenten -> Banner und klicke auf Optionen, dann auf Berechtigungen -> Testgruppe und setzte Administrationszugriff auf Erlaubt. Jetzt lade ich im zweiten Browser das Fenster neu und die Testgruppe sieht – immer noch nichts.
Das liegt an der Zugriffsebene für das Modul Administrationsmenü (des Backends), die standardmäßig auf „Special“ gesetzt ist.
Also weise ich als Admin über den Navigationsweg „Benutzer“ -> „Zugriffsebenen“ der Ebene „Special“ noch die Benutzergruppe „Testgruppe“ zu. Wenn ich nun das Browserfenster der Testgruppe neu lade, sehe ich oben im Menü den Punkt „Komponenten“ und darin nur „Banner“. Und so lässt sich das mit jedem weiteren Administrationszugriff fortführen.
Kompliziert wird die Sache, wenn man die neue Funktion nutzt und weitere Admin-Menüs erstellt. Es ist umständlich. Damit Testgruppe nicht auf das Standard-Modul „Administrationsmenü“ Zugriff hat, muss das Modul eine andere Zugriffsebene als „Special“ erhalten. Für Testgruppe wird jetzt ein neues Menü für das Backend (Button Administrator) erstellt und diesem ein Modul mit der Zugriffsebene „Testebene“ auf der Position „Isis“ -> „menu“ zugewiesen.
In diesem zweiten/neuen Adminmenü können Menüpunkte angelegt werden. Testgruppe wird diese aber erst sehen, wenn ihr auch für die verlinkte Komponente der Administrationszugriff zugewiesen wurde (s. Beispiel Banner). Im Grunde genommen erhält man also dasselbe Ergebnis.
Es mag gut sein, dass ich irgendetwas übersehen habe und es tatsächlich Bereiche gibt, die nur von der neuen Funktion abgedeckt werden (über eine Korrektur-E-Mail würde ich mich jedenfalls freuen). Nachtrag: Ich habe mittlerweile eine Rückmeldung dazu erhalten, siehe Fazit unten.
Multilingual Associations Manager
Eine neue Schnittstelle erleichtert die Übersetzung und den Abgleich zwischen den Sprachen. Dabei kann ein existierender Beitrag, Menüpunkt, Kontakt, Newsfeed oder eine Kategorie als Referenz genommen und in die Zielsprache kopiert werden. Wie das genau funktioniert, habe ich in einem Video aufgenommen und darin auch erläutert, wie eine weitere Sprache installiert und eingerichtet wird.
Custom Fields
Insgesamt 15 Feldtypen bringt das neue Feature, die hier beschrieben werden. Diese benutzerdefinierten Felder können für Beiträge, Benutzer und Kontakte genutzt werden. der Workflow ist dabei immer gleich: Erst zentral ein oder mehrere Felder definieren, unter Benutzer -> Felder oder unter Inhalt -> Felder oder unter Komponenten -> Kontakte -> Kontakte -> Felder. Über Feldgruppen lassen sich diese Felder zu Gruppen zusammenfassen. Felder können über Kategorien zugeordnet werden. Kategorie des Feldes = Kategorie des Beitrags = Anzeige im TinyMCE-Editor.
Erst wenn mindestens ein Feld definiert und per Kategorie zugeordnet wurde, erscheinen die entsprechenden Buttons oder Menülinks im TinyMCE-Editor.
Existieren Felder außerhalb einer Feldgruppe und sind sie ebenfalls zugeordnet, zeigt der TinyMCE oben 2 Menülinks an (s. Screenshot Punkte 1 und 2). Andernfalls wird entweder nur Punkt 1 oder Punkt 2 angezeigt. Klickt man darauf, erscheinen die Eingabefelder. Der Button unten (Punkt 3) fügt den Wert eines Feldes (das man aus den vorhandenen Feldern auswählen kann) in den Inhalt ein.
Bei meinem Test wurden Felder als Definition Description (HTML-TAG dd) ohne umgebende Definition List (HTML-TAG dl) eingefügt. Erstens nicht valide und zweitens nicht inline sondern als Blockelement. Das wurde aber heute geändert. In einem anderen Ticket wurden heute readonly und disabled aus den Feld-Parametern entfernt. Kurzum: Es ist einfach noch zu früh, um ausführlicher auf die Custom Fields einzugehen.
Ich habe während meines Tests keine Möglichkeit gefunden, ein Override für die Ausgabe der Felder zu erstellen (Datei render.php), hatte aber einen Workaround (if, ifelse, else-Abfrage) basierend auf der Render-Class geschrieben, mit der ein Feld entweder als dd, als span oder raw ausgegeben wurde. Mangels Override allerdings ein Core-Hack, aber nun auch schon wieder obsolet, da die Class in der render.php entfernt wurde (was gut ist).
Nicht gut hingegen finde ich die vordefinierten umgebenden HTML-Tags bei der Ausgabe eines Feldes, auch wenn das jetzt inline-Elemente sind. Als purer Hex-Wert könnte man zum Beispiel den Farbwert im Text-Modus (Code) des Editors verwenden.
Das URL-Feld kann auch nicht als Link innerhalb eines Anchor- oder SRC-TAGs, etc. genutzt werden. Das Media-Feld hat keinerlei Vorgaben, was Größen und Abmessungen von Bildern betrifft. Im Verzeichnis Images gibt es null Restriktionen, jeder Ordner ist zugänglich. Die Mime-Types werden nur global über die Globale Konfiguration definiert. Userfeld und Benutzergruppen-Felder ergeben für mich keinen wirklichen Mehrwert.
Das Einfügen sämtlicher Felder in den Inhalt per Button macht meiner Meinung nach keinen Sinn. Man gibt den Wert oben im Menülink (s. Screenshot Punkt 1 oder/und Punkt 2) ein und fügt das dann unten per Button (Punkt 3) in den Artikel ein?
Die Felder können zusätzlich, oder ausschließlich (ist einstellbar), über oder/und unter dem Beitrag angezeigt. Sortieren ließen sie sich in meinen Tests nicht, die Anordnung war willkürlich.
Einen Mehrwert sehe ich allerdings, wenn Felder in raw-Ausgabe (also ohne umgebende HTML-TAGS) in TinyMCE-Templates integriert werden. Felder werden per ID angesprochen und können mit geschweifter Klammer, zum Beispiel {field 1} in solche Templates eingetragen werden.
Fazit
Joomla! 3.7 wird ein ganzes Bollwerk an neuen Features bringen (alle 41 neuen Funktionen können hier nachgelesen werden). Besonders gut gefallen mir die TinyMCE-Sets, der Improved Workflow sowie die Multilingual Asscociations Component. Das Session-Sharing und die Extension Maintenance habe ich nicht getestet und kann dazu auch nichts sagen.
Der Backend Menu Manager hat mir reichlich Kopfzerbrechen bereitet, aber der Sinn der „neuen“ Funktion erschließt sich mir dennoch nicht. Nachtrag: Ich habe mittlerweile eine Erklärung dazu erhalten, vielen Dank an dieser Stelle! Zitat: „Die Backend Menü Sache ist in erster Linie dafür gedacht, dass man das Backend mit mehreren Punkten statt nur ‚Komponenten‘ strukturieren kann und es damit übersichtlicher wird.“
Die Custom Fields benötigen noch einiges an Optimierung und ihre Praxistauglichkeit muss sich erst beweisen.
Bis auf Kleinigkeiten lief Joomla! 3.7 RC 2 in meinen Tests fehlerfrei und stabil. Es steckt enorm viel Arbeit in Joomla! 3.7 und kann – bis auf ein paar Dinge, die mit der Zeit sicher besser werden – durchaus als gelungen und innovativ bezeichnet werden.
