Joomla und Erweiterungen (Templates, Komponenten, Plugins, Module)
Wissenswertes, Anleitungen, Workarounds, Bugfixes zu Joomla und Joomla-Erweiterungen
- Details
Problembeschreibung
Manche Komponenten in Joomla nutzen MooTools, andere und mittlerweile das Joomla selbst verwenden jQuery. Es kann passieren, dass beide JavaScript-Frameworks geladen werden. Das führt jedoch häufig zu Konflikten, weil beide Frameworks den Kurzbezeichner $ verwenden um angesprochen zu werden. Grundsätzlich ist das in Joomla längst kein Problem mehr, selbst dann wenn man beide Frameworks gleichzeitig nutzen will. Zum einen ist gebräuchlich eine jQuery-Methode namen noConflict() einzubinden und zu nutzen. Zum anderene ist es notwendig diese dazu in der korrekten Reihenfolge zu laden. Dies verhindert Konflikte im gleichen Namensraum.
Aber darum muss sich nicht jede Komponente oder der Webmaster der Seite mehr selbst kümmern. Dafür hat Joomla schon diverse Methoden zur Verfügung gestellt, die das korrekte Handling sicherstellen. Wichtig ist nur, dass die Komponte, die z.B. jQuery verwenden will, zur Sicherheit diese Joomla-Methoden verwendet - zum einen das Einbinden der Frameworks über die Klasse JHtml::_(...) und zum anderen die evtl. notw. Reihenfolge und Konfliktvermeidung JHtml::_('behavior.framework', true);.
- Details
Problembeschreibung
Es gibt zwar für das Joomla-Module Fancy TagCloud viele Konfigurationsmöglichkeiten, aber leider ist darüber nicht alles vollständig konfigurierbar. Im Zuge der Umstellung von Projekten auf DSGVO-Konformität bestand ein Bemühen darin, den Zugriff des Projektes auf externe Ressourcen wir z.B. Fonts vom Google-Font-Server zu verhindern. Fancy TagCloud hat diese Einbindung von Fonts fest in Scripte verankert. Es ist nicht konfigurierbar lokale Fonts zu verwenden. Da die Style-Anweisungen auch aus PHP-Scripten kommen, ist es schwer zu verhindern, dass die Fonts von Fremdservern geladen werden. Die einzig Chance bestand darin das Theme-Script anzupassen in dem diese Fonts von e10f949fcaacdb195442bfb5062d59de-gdprlock geladen werden.
Lösung
Immerhin bietet Fancy TagCloud die Möglichkeit an im Modul wahlweise alternative Themes zu laden. Zwar wird nur ein einziges im Installationspaket mitgeliefert, aber es ist doch recht einfach daraus weitere Themes zu abzuleiten. In diesem eigenen Theme kann man dann seine gewünschten Modifikationen vornehmen ohne Angst haben zu müssen, dass durch ein Update des Modules diese Modifikationen überschrieben werden würden.
Dazu sind zwei Schritte notwendig:
Weiterlesen: Für das Joomla Fancy TagCloud-Module eigene Themes erstellen
- Details
Eines der Kriterien für eine gutes Suchmaschinenranking und eine positive Nutzererfahrung ist die Geschwindigkeit mit der Seiten geladen werden. Neben dem rein subjektiven Eindruck gibt es auch Webservices, mit denen man objektive Tests durchführen kann. Eine Seite ist z.B. der PageSpeed-Test der Google-Deverloper-Seiten. Hier werden neben einer Bewertung auch Maßnahmen zur Beschleunigung vorgeschlagen.
Für einen Seitenbetreiber eines Joomla-Projektes stellt sich nun also die Frage, wie man die eigene Seite schneller machen kann. Dazu möchte ich nachfolgend ein paar Maßnahmen ausführen.
Weiterlesen: Maßnahmen zur Beschleunigung von Joomla-Projekten
- Details
Nachfolgend finden Sie eine Anleitung, wie man aus einem Joomla de-DE-Sprachpaket ein Sprachpaket für de-AT also Österreich erzeugt. Dies kann notwendig sein, wenn man unter einer Joomla-Version unterschiedliche Sprachausgaben für Deutsche und Österreichische Seitenbesucher anbieten will, beispielsweise um spezielle Dialekte oder Sprachspezifiken wiedergeben zu können.
Gleiche Verfahrensweise könnte interessant sein, wenn man ausgeprägte regionale Sprachdialekte anbieten möchte, z.B. in Plattdeutsch, Sächsisch, Bayerisch oder Sorbisch.
Weiterlesen: Österreichisches Sprachpaket (de-AT) für Joomla 3.x erstellen
- Details
Die Schwierigkeit der Mirgration von Projekten
Häufig erhalte ich Anfragen von Bestandskunden oder von fremden möglichen Auftraggebern zur Migration von Bestandprojekten auf eine neuere Joomla-Haupt-Version, verbunden mit der Bitte einer Aufwandseinschätzung und der Abgabe eines Preisangebotes. Diese Frage ist jedoch nicht einfach zu beantworten, denn viele Faktoren spielen eine Rolle und hinzu kommen Dinge die einfach von vornherein schwer einzuschätzen sind, sondern erst ihre Probleme beim ersten Migrationsversuch offenbaren. An dieser Stelle seinen dafür ein paar lesenswerte Gründe genannt, um Verständnis für die Problematik zu vermitteln.
Dieser Beitrag bezieht sich ganz speziell auf die Arbeit mit dem OpenSource CMS Joomla!, betrifft aber auch andere CMS wie WordPress, Drupal etc.
Update vs. Migration
Zunächst sei auf den Sachverhalt hingewiesen, dass wir bei größeren Versionssprüngen üblicherweise von einer Migration ausgehen und nicht von einem Update.
Ein Update ist meist eine einfache Sache, die mit einem Knopfdruck erledigt ist. Ein Update ist nie so gravierend, dass sich Datenstrukturen maßgeblich ändern oder ganz Basistechnologien in den Corescripten verändern. Das Update ist i.d.R. mit einem "Drüberbügeln" und einer Kontrolle der Auswirkungen abgeschlossen. Selten gibt es dann noch Anpassungsaufwand.
Weiterlesen: Projekt migrieren oder besser ein neues aufsetzen