Joomla und Erweiterungen (Templates, Komponenten, Plugins, Module)
Wissenswertes, Anleitungen, Workarounds, Bugfixes zu Joomla und Joomla-Erweiterungen
- 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
- Details
Zielstellung
In einer kurzen Anleitung soll beschrieben werden, wie man ein Joomla-2.5.x-Projekt zu Joomla 3.x migriert oder upgradet, was dabei zu beachten ist, und wie evtl. Stolperfallen umgangen werden können.
Grundwissen
Zunächst ist wichtig zu wissen, dass man eigentlich erstmals von einer Migration gar nicht reden kann. Denn üblicherweise ist eine Migration sehr viel aufwändiger und nicht mit einfachen Installationen erledigt. Meist sind spezielle Nacharbeiten notw. Jedoch haben uns die Joomla-Entwickler diese Migration so leicht gemacht, dass man eigentlich von einem Upgrade sprechen kann. Wer sein Joomla-Projekt schon bisher immer regelmäßig per Updates aktuell gehalten hat, kennt die Arbeit mit dem Joomla-Installer. Genau der kann auch für das Upgrade auf 3.x verwendet werden.
- Details
Zielstellung
Für gewerbliche Kunden innerhalb der EU (vorsteuerabzugsberechtigt) ist es erforderlich auf den Rechnungen die Umsatzsteuer-Identifikationsnummer (USt-IdNr.) anzugeben. Diese muss geprüft sein. Dafür gibt es unter http://ec.europa.eu/taxation_customs/vies/checkVatService.wsdl eine SOAP-Dienst an den die EU-VAT-ID übergeben werden kann. Man erhält einen Validitationsstatus als Ergebnis. Wer die Spezifikation erfahren will kann einfach auf diesen Link klicken und erhält diese als beschreibendes XML-Schema.
Die meisten Shop-Script, so auch in VM machen per JavaScript eine Plausibilitätsprüfung, ob die Eingabe für das gewählte Land dem typischen Muster der VAT-ID entspricht. Besser ist es natürlich direkt die Existenz der Eingabe-VAT über den VIES-Server zu prüfen. Mit dem nachfolgenden Script habe ich das mal für ein Projekt, noch unter VM 1.1.x laufend umgesetzt.
Prüfscript
Das Script Es enthält zwei Klassen
vatLiveCheck() macht eine einfache Prüfung über die SAOP-Methode checkVat(). Hier wird die VAT aufgesplittet in den Länderkode und die VAT-Nummer und als Parameter übergeben. Es wird das Prüfegebnis valid ausgewertet und evtl. Fehler.
Weiterlesen: Prüfung der USt-IdNr. (EU-VAT-ID) in Joomla/VirtueMart per VIES-Server (SOAP)
- Details
Zielstellung - Regelkonformes Override von Joomla-Templates
Seit Gantry in der Version 4.1 ist das Handling von Templates-Overrides erweitert worden und deshalb noch mal etwas komplexer geworden. Der Grund für die Erweiterung ist, dass man nun für die verschiedenen Joomla-Versionen unterschiedliche Templates ablegen kann. Damit sind Projekt z.B. noch einfacher migrierbar.
Das Verwirrende ist, dass es nun noch mehr Positionen im Joomla-Projekt-Pfad gibt an denen Template-Dateien liegen und man nur schwer sieht für welche Collection sich Joomla beim Durchsuchen der möglichen Plätze entscheidet. Deshalb hier kurz eine Beschreibung was sich abspielt und welche Auswirkungen dies hat, wenn man eigenen Template-Overrides erstellen möchte ohne dabei Core-Scripte zu modifizieren.
Ich setze voraus, dass Gantry als Template-Framework eingesetzt wird und z.B. eine auf Gantry basierendes eigenes Template eingesetzt wird. Das eigene Template kann auch ein fremdbezogenes Template auf Gantry-Basis sein, wie z.B. die von RocketTheme.
Grundlegendes zum Verständnis und Override-Pfad-Kollektion
Alle Joomla-Original-Templates liegen in den jeweiligen Komponenten-Verzeichnissen. Am Beispiel der Content-Kategorie-Templates blog.php und blog-item_php wäre das z.B. dieser Pfad: components/com_content/view/templ/category/.
- Mit RokCandy im Joomla-Gantry-Template eine Modulposition mit Cover-Background-Image füllen
- Aufbau und Pflege Mehrsprachiges Projekt unter Joomla 2.5/3.x mit jDiction
- Joomla 1.5.x - Spam-Bot-Registrierungen verhindern
- Teilweiser Transfer von Daten zu einem anderen Joomla-Projekt mittels Akeeba Backup