Bei SQL-Abfragen, bei denen man mehrere Werte, z.B. via ids, aus einer Tabelle gleichzeitig abfragen will, kann man Konstrukte wie WHERE `id` IN (18,12,33,4) verwenden. Joomla 3 und 4 haben dafür eine Datenbank-Methode where() dabei. Mit J!4 kam eine weitere Methode whereIn() dazu, die sowohl das Erstellen der Queries erleichtert als auch die Sicherheit erhöht durch automatische prepared Statements.

In der Joomla-Konfiguration findet sich ein Feld "Protokollverzeichnis". Im Normalfall wurde dieser Ordnerpfad durch ein Wunderwerk bereits gefüllt. Selten schaut der "normale" Benutzer in das Verzeichnis mal rein. Man findet darin gar nichts oder eine bis mehrere PHP-Dateien, so genannte Log-Dateien, die das Joomla oder Erweiterungen befüllen; mit unterschiedlichsten Infos, Warnungen, Fehlern und mehr.

Die wichtigsten Dateien und Ordner eines joomla-konformen Templates können im so genannten Template-Editor im Backend geändert werden. Es lassen sich auch neue Verzeichnisse und Files anlegen. Das ist nicht ganz so intuitiv zu bewerkstelligen wie man es "so gewöhnt ist". Nach jedem Klick, Speichern, Löschen oder… sollte man sich versichern, dass man noch dort ist, wo man zuvor war, z.B. im Wunsch-Ordner.

Einige Accordion-Module, die Beiträge anzeigen, haben sich mit dem Erscheinen von Joomla 4 "ausgelebt". Sie verwenden veralteten PHP-Code, Mootools, unnötigerweise JQuery… Wegen einer Anfrage so eine schon mehrfach wiederbelebte Leiche für Joomla 4 zu überarbeiten, habe ich am Ende nur einen Override für das joomla-eigene Modul "Beiträge - Kategorie" gebraucht, um den Einsatzzweck "nachzubauen".

In Joomla 5 werden die Zeilen $db = Factory::getDbo(); bzw. $db = JFactory::getDbo(); für das Initialisieren eines Datenbank-Objekts (= Aufbau einer Datenbankverbindung) nicht mehr funktionieren. Deshalb werden sie schrittweise aus dem Joomla-4-Core entfernt; auch, um zahlreiche Deprecated-Meldungen (= Veraltet) aus den Joomla-Logs rauszubekommen. Die empfohlene, neue Schreibweisen-Variante geht jetzt so:

Das Joomla-Registrierungsformular zeigt die Felder (Name, Benutzername usw.) immer in einer festen Reihenfolge an. Hat man zusätzlich eigene Felder definiert, erscheinen die bei der Standardausgabe immer unten drunter. Mit einem schnellen Code-Schnipsel-Beispiel zeige ich, wie man eine andere Reihenfolge festlegen kann bzw. Joomla-Felder und eigene mischen. Kein Silbertablett-Service!

Manchmal brauche ich keinen WYSIWYG-Editor und will nur einen beliebigen Code-Schnipsel in einem Joomla-Frontend-Modul ausgeben, der ohne zusätzliches HTML-Gedöns garantiert 1:1 ausgegeben wird. Und noch öfter will ich gar nichts eingeben und nur mit schnell hingehauenen Modul-Overrides arbeiten. Dafür habe ich mir das Modul MOD_CUSTOM_BLANKGHSVS ("Benutzerdefiniertes" Modul ohne Editor) geschrieben.

Mein Bild-Optimierer-Plugin meckert unter Joomla 4 plötzlich rum, dass Einleitungsbild (image_intro) und so genanntes "Komplettes Beitragsbild" (image_fulltext) nicht existieren, wenn ich sie mit dem neuen Joomla-Medienmanager in einem Beitrag auswähle. Schuld sind "komische" Anhängsel an die Bildpfade, die Joomla jetzt automatisch mitspeichert und die in meinem Fall störend sind. Wie man sie los wird?

Bisher hat man eigene Modulstile ("Modul-Chromes") in der unhandlichen und ggf. konfliktbeladenen Templatedatei html/modules.php definiert. Seit Joomla 4 wird für jeden Stil ein eigenes Layout im Ordner html/layouts/chromes/ angelegt. Die verwenden die altbekannten JLayoutHelper-Funktionalitäten. Klingt vielleicht komplizierter als es final ist. Sein Joomla-3-Template kann man auch schon vorbereiten.

Man braucht nicht unbedingt eine zusätzliche Erweiterung, um in einen Joomla-Beitrag eigenen, dynamischen PHP-Code auszugeben, vielleicht aus der Datenbank. Das geht auch mit Joomla-Hausmitteln. Mit Modul-Overrides plus Joomla-eigenem Plugin loadmodule. Der Code kann Joomla-Klassen und -Methoden ohne weiteres Zutun nutzen und der Beitrags-Editor bleibt "clean"; ohne unübersichtliche Code-Schnipsel darin.

Ein Code-Schnipsel zwischendrin. Registry-Objekte sind eine feine Joomla-Sache und können viele eigene Zeilen Code einsparen. Wie bei "normalen" PHP-Objekten kan man key-value-Paare reintun und mehrere Registry-Objekte ähnlich dem bekannten array_merge in ein einzelnes zusammenfassen. Ist einer der values allerdings ein stdClass Object, wird daraus beim unachtsamen mergen unerwünscht ein array.

Joomla 4 baut auf Namespaces beim Finden seiner Klassen bzw. Dateien sowie auf Importe/Verfügbarmachung derselben mit use-Zeilen. Eigene Erweiterungen können Namensräume automatisiert registrieren lassen. An einem kurzen Beispiel für eine Erweiterung möchte ich zeigen wie ein Modul aufgebaut sein kann, um es sowohl in Version 3 als auch 4 "genamespacet" zu verwenden. Es soll für beide kompatibel sein.

JHtml-Helper-Methoden haben Tradition in Joomla. Sie ersparen es dem Programmierer oftmals viele Zeilen Code immer wieder selbst einsetzen zu müssen, nötige Klassen zu laden und so Kram. Wenn man Joomla 3 nach dem Konstrukt JHtml::_( durchsucht, finden sich zahlreiche Anwendungs-Beispiele. In Joomla 4 jedoch nicht mehr. Da sind es jetzt Stellen mit HTMLHelper::_(. Nicht nur eine Namensänderung.

Die Stärke der Venobox, einer JavaScript-Lightbox für Bild-Pop-Ups, ist, dass sie die Bildgröße nur an die Breite des Viewports anpasst. Wenn das Bild höher als der Darstellungsbereich ist, kann man es vertikal scrollen. Die Simple Image Gallery Extended von Kubik Rubik verwendet sie zum Beispiel. Mein Plugin hat einen anderen Ansatz. Es hilft, die Venobox in eigenem Joomla-Code zu nutzen/konfigurieren.

Will man wissen, welchen Browser und Version (und weitere Infos) ein Besucher nutzt und vielleicht Browser-Weichen in den PHP-Code einprogrammieren, dann kann Joomla helfen. Die Detektion ist längst nicht perfekt (Vivaldi wird beispielsweise als Chrome erkannt), jedoch vollkommen ausreichend für Grobes und Alltägliches. Wer mehr will, muss halt so was integrieren und verwenden: hisorange / browser-detect

Syntax-Hervorhebung oder -Highlighting meint, bestimmte Wörter und Variablen-Arten eines Programm-Codes je nach Bedeutung in verschiedenen Farben lesbarer darzustellen. Viele Editoren, die Programmierer nutzen, unterstützen Code-Hervorhebung und variieren die Darstellung je nach Programmier-Sprache. Das Plugin SyntaxHighlighterGhsvs hilft beim Anzeigen von "gehighlightetem Code" in Joomla-Beiträgen.

Eine Kundin liebt Blocksatz. Das sieht schön gleichmäßig aus so lange die Bildschirmbreite mitspielt. Ab irgendeinem Punkt stören Riesenabstände zwischen Worten oder verwaiste Worte den Lesefluss. Da hilft es Silbentrennung per CSS3-Eigenschaft hyphens zu aktivieren, was jedoch nicht alle Browser unterstützen. Das Plugin HyphenateGhsvs schafft Abhilfe.

Seit Joomla Version 3.6.0 hat sich beim Speichern eines Menüeintrags vom Typ Menüeintrags-Alias die Art und Weise geändert wie der automatisch erstellte Alias des Menüpunktes gebaut wird. Früher war der Alias ein Zeitstempel der Art 2016-08-01-16-33-01. Jetzt generiert Joomla, wie in allen andern Situationen auch, den Alias aus der Eingabe im Feld Titel. Der Eine find's gut, ein Anderer ist genervt.

In Joomla kann man eigene Formularfelder programmieren und mittels addfieldpath in JForm-XML-Dateien bekannt machen. Alternativ geht das in PHP mit JForm::addFieldPath(…). Was aber, wenn man für das eigene Feld einen Namen (Typ, type) verwendet, den Joomla schon verwendet oder eine andere zuinstallierte Erweiterung? Joomla wird das Formularfeld anzeigen, das es zuerst findet. Vielleicht das falsche.

Für Touchscreens sollte man Menüpunkte nicht verlinken, die ein Dropdown mit Untermenüs öffnen. Beim Tippen öffnet sich sonst der getippte Link statt des Dropdownmenüs, wenn man keine unhandlichen Maßnahmen getroffen hat. In Joomla verwendet man dafür unverlinkte Menüeintragstypen Menüüberschrift oder Trennzeichen. Leider bekommen die aber keine active-CSS-Klasse, wenn Untermenüpunkte aktiv/geöffnet sind.