Im Dezember haben wir über eine Erweiterung des MUSeo-Moduls im Hinblick auf vielfältigere SEO-Konfigurierbarkeit berichtet. Mittlerweile liegt nun, dank intensiver Unterstützung durch Gabriel Freinbichler, eine Vorabversion von MUSeo 2.0.0 vor, welche wir erfolgreich bei einem Kunden integriert haben.
Wie bereits im ersten Artikel beschrieben, basiert diese Erweiterung im Wesentlichen auf einem SEO-Plugin für WordPress. Wir haben allerdings einige Funktionen weggelassen oder verändert, um die Funktionalität besser an Zikula anzupassen, da dort unterschiedliche Aspekte dynamischer gelöst oder bereits im Core gehandhabt werden.
Das Modul MUSeo von Michael Ueberschaer ist eine ModuleStudio-basierte Lösung zum Erfassen von suchmaschinenrelevanten Metatags für beliebige Einzelseiten einer Zikula-Präsenz. Aktuell laufen die ersten Schritte für die Version 2.0.0 mit erweitertem Funktionsumfang.
Neben einigen neuen Feldern und Angaben, z. B. für Social Media Funktionen, soll die kommende Hauptversion im Wesentlichen zwei neue Funktionen mitbringen:
Erstens soll es möglich sein, direkt eine Vorschau der voraussichtlichen Darstellung des Eintrags der Seite in Google-Ergebnislisten einzusehen.
Wer seine Projekte regelmäßig mit einem Build-Server prüfen und testen lässt, erstellt oftmals auch eine API-Dokumentation. Dafür gibt es auch im PHP-Bereich eine Vielzahl unterschiedlicher Werkzeuge, beispielsweise PHPXref oder ApiGen. Dieser Beitrag stellt das Tool phpDox vor und gibt Einblick in das interessante Feature der Enricher.
Eine API-Dokumentation stellt in der Regel eine navigierbare Übersicht der in einem Projekt vorhandenen Klassen, Schnittstellen, Methoden usw. bereit. Damit können Entwickler, die diese Artefakte in ihrem eigenen Code nutzen wollen, Informationen über die benötigten Methoden einsehen und so beispielsweise herausfinden, welche Argumente eine bestimmte Funktion erfordert.
Dieser Beitrag gibt eine kurze Einführung in die Verwendung von Modulvariablen. Diese können dazu verwendet werden, bestimmte Parameter in einem Modul einstellbar zu machen. Typische Beispiel hierfür sind etwa Grenzwerte oder API-Keys für Drittdienste.
Nutzung im Code Die wichtigsten Grundfunktionen werden von Zikula durch die ModUtil-Klasse bereitgestellt.
1 2 3 4 5 ModUtil::hasVar($modname, $name) ModUtil::getVar($modname, $name = '', $default = false) ModUtil::setVar($modname, $name, $value = '') ModUtil::setVars($modname, array $vars) ModUtil::delVar($modname, $name = '') Innerhalb von Klassen, die von Zikula_AbstractBase erben, zum Beispiel in Controller- und API-Klassen, gibt es außerdem Convenience-Methoden, die auf die oben genannten ModUtil-Methoden verweisen.
Wenn mehrere Zikula-Module zusammen arbeiten, wird dies in der Regel durch Modulabhängigkeiten ausgedrückt. Damit lässt sich festlegen, dass ein Modul A ein anderes Modul B entweder zwingenderweise voraussetzt oder optional empfiehlt. In größeren Systemen, die aus mehreren Modulen bestehen, reicht dies ab einem gewissen Punkt nicht mehr aus.
Austauschbarkeit von Modulen gewährleisten Früher gab es in der Modultabelle von Zikula Flags für bestimmte Funktionen, zum Beispiel isProfile für Profilmodule und isMessaging für Module, die private Nachrichten verwalten können.
Dieser Blog wird hauptsächlich über die Anpassung von Modulen für das Zikula-Framework berichten. Dabei werden zahlreiche Technologien verwendet, unter anderem Symfony, Twig, Doctrine, Bootstrap und jQuery. Eine Besonderheit ist, dass die Zikula-Module auf modellgetriebenem Wege realisiert werden.
Modellieren – generieren – anpassen Meistens wird es in diesem Blog um Zikula-Module gehen, die mit dem MDSD-Werkzeug ModuleStudio modelliert und generiert wurden. Manchmal werden kleinere Tipps und Tricks vorgestellt, manchmal vielleicht etwas längere Tutorials und HowTos, die zeigen, wie wir bestimmte Anforderungen umgesetzt haben.
