Joomla

  • Problembeschreibung

    Die Formularkomponente BreezingForms für Joomla meldet an den Seitenbenutzer diverse Informationen, so z.B. wenn Pflichtfelder nicht ausgefüllt wurden oder das Formular erfolgreich gesendet wurde. Da Webseiten heutzutage wg. der mobilen Geräte häufig sehr lang sind, oder Formulare sehr viele Felder haben können, kann es passieren, dass diese Meldungen, die bei BreezingForms oberhalb des Formulars eingeblendet werden oder auf einer Feedbackseite ausgegeben werden nicht im sichtbaren Bereich liegen. Der Seitenbesucher sieht diese Meldungen nicht, und ist verwundert oder gar genervt darüber nicht zu erfahren, was jetzt nach dem Klick auf dem Absendebutton genau passiert ist.

    Beide oben genannten Grundprobleme - also die Feedbackmeldung nach dem erfolgreichen Senden und die Fehlermeldungen bei Fehleingaben oder nicht gefüllten Feldern, sind jedoch vom Verhalten etwas unterschiedlich.

  • 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:

     

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

  • Know-How-Sammlung für die Anpassung des Layoutes und der inhaltlichen Ausgaben von Rechnungen nach eigenen Bedürfnissen in Virtuemart 3.x.

    Die Templates

    Sämtliche Templates/Vorlagen für die Erstellung der Rechnungen liegen im Ordner components/com_virtuemart/views/invoice/tmpl/. Von hieraus können Scripte hergenommen und als Overrides in das eigene Template-Verzeichnis abgelegt werden, um nicht die Virtuemart-Core-Scripte modifizieren zu müssen, denn hier bestünde bekanntlich immer die Gefahr, dass dort vorgenommene Anpassungen bei nächsten Updates überschrieben werden würden.

    Im o.g. Ordner befinden sich 3 Datei-Hauptgruppen von Vorlagen, die jeweils einen unterschiedlichen Präfix haben:

    • ohne Präfix sind die Templates die für die PDF-Erzeugungen relevant sind
    • der Präfix mail_html erzeugt die html-Mails
    • der Präfix raw_html erzeugt die RAW-Texte-Inhalte in der Mail, die man in der Regel kaum zu Gesicht bekommt und deshalb bei Anpassungen gern vergessen werden.

    Dann gibt es jeweils diverse Sub-Template wie z.B. order, items, vendor etc. Diese Sub-Templates können jeweils durch Unteraufrufen eingebunden werden. Wenn man sich z.B. im PDF-invoice-Template befindet (invoice.php) kann mit $this->loadTemplate('items') das Templatescript invoice_items.php eingebunden werden. Auf gleiche Weise kann man sich seine eigenen Schnippsel erstellen und inkludieren.

    Ab und zu muss man bei der Templatebezeichnung aufpassen, denn diese sind zwischen den o.g. Templategruppen nicht immer identisch. Während z.B. die Produktzeilen beim PDF invoice_items.php heißt, wird bei den HTML-Mails der Dateiname mail_html_pricelist.php verwendet. Nicht ganz konsequent.