Joomla und Erweiterungen (Templates, Komponenten, Plugins, Module)

Wissenswertes, Anleitungen, Workarounds, Bugfixes zu Joomla und Joomla-Erweiterungen

Bewertung: 0 / 5

Stern inaktivStern inaktivStern inaktivStern inaktivStern inaktiv

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);.

Anhänge:
Diese Datei herunterladen (plg-unloadscripts.zip)Joomla-Plugin unloadScripts[Mit diesem Plugin können durch Komponenten unnötig geladene Scripte (wie z.B. das Mootools-Framework) wieder aus dem Siteheader entfernt werden, bevor die Seite gerendert wird.]3 kB

Bewertung: 5 / 5

Stern aktivStern aktivStern aktivStern aktivStern aktiv

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 googleapis.com 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:

 

Bewertung: 5 / 5

Stern aktivStern aktivStern aktivStern aktivStern aktiv

 

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.

Anhänge:
Diese Datei herunterladen (de-AT.com_virtuemart_mD.SK.zip)de-AT.com_virtuemart_mD.SK.zip[VirtueMart 3 Sprachpaket für Österreich (de-AT) ]86 kB
Diese Datei herunterladen (de-AT_joomla_lang_full_3.4.8v1_mD.SK.zip)de-AT_joomla_lang_full_3.4.8v1_mD.SK.zip[Joomla 3.x Sprachpaket Österreich de-AT]313 kB

Bewertung: 5 / 5

Stern aktivStern aktivStern aktivStern aktivStern aktiv

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.

Bewertung: 5 / 5

Stern aktivStern aktivStern aktivStern aktivStern aktiv

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.