Development Update, 2008-01

CMS Allgemein : Dies ist die Übersetzung des ersten Development Update im Jahr 2008 und auch das erste nach fast einem Jahr Unterbrechung, weswegen auch die Übersetzung evtl. nicht so gut ist, da ich komplett aus der Übung bin. In diesem Update werde ich euch zeigen, was sich in der Entwicklung von PostNuke nach dem RC3 alles getan hat. Viel Spaß beim Lesen.

In diesem Bericht:
.8 Final: der nächste Schritt nach RC3
Multi-Kategorisierung
DOM Erweiterungen
PosNuke Upgrade Distribution
Core Veränderungen und und Erweiterungen im .9 Stamm
GetText und Standard DB Zeichensatz
Cachen oder nicht Cachen, das ist hier die Frage

.8 Final: der nächste Schritt nach RC3

Seit der Veröffentlichung von RC3 sind bereits viele Bugfixes in das Repository eingeflossen. Alle Entwickler sind damit einverstanden, das neue Features nur noch im .9 Zweig einfließen, wo zwei große Veränderungen (UTF8 und GetText, siehe unten) bereits aktiv entwickelt werden. Dies sollte in viel kürzeren Veröffentlichungszyklen enden und Modulentwicklern eine klarere Aussage darüber geben, was sie ändern müssen, damit ihr Modul im nächsten Major Release weiterhin funktioniert. Sollte es benötigt werden, wird außerdem noch ein Finales Bugfixing Wochenende veranstaltet, um .8 herauszubringen.
Das Update von .764-Installationen wurde auf einigen Systemen verbessert indem das Speicherlimit auf 64M angehoben wurde, was allerdings nur ab der PHP Version 5.2.1. funktioniert.
Das Updaten zu .8 mit verschiedenen .3rd Party Modulen kann sich als schwierig erweisen, wenn der Upgradeprozess der einzelnen Module nicht ausfallsicher für .8 ist oder die Updatefunktion des Modules Core-Funktionen verwendet, die zu dem Zeitpunkt nicht verfügbar sind.
Im allgemeinen können Probleme mit dem Updaten von 3rd Party Modulen dadurch vermieden werden, dass man einer Whitelist von Coremodulen folgt, die aktualisiert werden, während die restlichen Module anschliessend manuell behandelt werden müssen

Der größte Teil der Templates kann mittlerweile überschrieben werden, indem man die /config und /themes Verzeichnisse verwendet.

Das Multisites Modul benötigt aber noch weitere Überarbeitungen, um mehrere Seiten über eine Installation auszuliefern.

Eine Methode um verschiedene, nicht zusammenhängende Seiten, aus einer Installation zu erstellen, wäre die Verzeichnisse nach /config/seite1 und config/seite2 aufzuteilen, dies wird bis zum nächsten Release angepeilt.
Das Tour-Modul ist mittlerweile in einem Status, in dem es bereit ist, in andere Sprachen übersetzt zu werden.
Übersetzt einfach die Templates und schiebt sie in ein Unterverzeichnis des pntemplates Verzeichnisses mit der entsprechenden Abkürzung der jeweiligen Sprache als Name.

Einführung und Probleme mit Multi Kategorisierung

Wie früher schon angekündigt wurde die Unterstützung der Multikategorisierung zum Core kurz vor dem Realease des RC3 hinzugefügt. Seit dieser Veränderung wurde noch mehrere Fixes nötig, um volle Rückwärtskompatibilität zu gewährleisten.
Für mehr Informationen zur Multikategorisierung schaut am besten im Forum vorbei

DOM Erweiterungen um die korrekten Pfade in javascript zu benutzen

Einige Javascripts wie z.B. die Lightbox müssen den Pfad zum System und dem Entrypoint (zur Zeit üblicherweise index.php) wissen (welcher in den Einstellungen eingestellt werden kann), ansonsten kann es zu Fehlern kommen wenn die ShortUrls aktiviert sind .
Da die dynamische Javascript-Erstellung ein Performanceproblem darstellen kann wurden einige Inline-JavaScripts hinzugefügt, um das DOM (Document Object Model) zu erweitern:
- document.location.entrypoint: stellt den gesetzteE entrypoint dar
- document.location.pnbaseURL: zeigt zum Ergebnis von pnGetBaseURL();
Jegliche Ideen um das ganze unauffälliger zu machen sind sehr willkommen!

PostNuke Upgrade Distribution

In vorherigen Artikeln und Posts wurde der Begriff '.8 Upgrade Pack' benutzt um ein komplettes .8 Package inklusive einiger 3rd Party Module darzustellen, um damit jede .764-Installation zu updaten.
Wie auch immer ist der Name 'Upgrade Pack' nicht wirklich korrekt und irreführend, da es impliziert, das es ein Upgradepack mit veränderten Dateien ist und die restlichen Dateien unverändert bleiben.
Die Umstellung von .764 zu .8 bedeutet aber einen kompletten Austausch von allen Dateien dar, so dass das 'Upgrade Pack' eine komplette Distribution darstellt.

Nun stellt sich die Frage, welche Module in einer Upgrade Distribution sein sollten um eine .764-Distribution komplett zu updaten. Dies sind derzeit Downloads 2.2, pnMessages, Polls 2.0, pn_bbcode / pn_bbsmile, Weblinks, EZComments und Multihook. Hier werden wohl noch einig Tests nötig sein, vor allem mit verschiedenen Versionen.

Core-Veränderungen und und Erweiterungen in .9

Mark hat einige API-Methoden und Aufrufe überholt. Alle Module benutzen mittlerweile die Renderer-Klasse anstatt pnRender. Außerdem wurde ein erster Schritt gemacht, alle PN* Funktionen durch die neuen Objektmethoden zu ersetzen. Zum Beispiel, pnModGetInfo wurde durch ModuleUtil::getInfo und pnSecGenAuthKey wurde durch SecurityUtil::generateAuthKey ersetzt.
Für alle die es nicht wissen: Die Datei pnCompat.php enthält immer noch die meisten oldstyle-API-Aufrufe zwecks Rückwärtskompatibilität.

GetText und Standard DB Charset

Bernd arbeitet intensiv an der Integration von GetText in den Developmentzweig, und hat po-dateien für alle Core Module hinzugefügt. Die minimale PHP-Version für .9 wurde bereits auf 5.1.6 gesetzt, außerdem unterstützt MySQL seit Version 5.0 verschiedene Zeichensätze und entsprechende Kollationsreihenfolgen. Um eine Anwendung in UTF-8 (Unicode) auszuführen, ist es nicht nur nötig den Zeichensatz von PN umzustellen, man muss außerdem die Codierung der Datenbank ebenfalls in UTF-8 umändern.
Ein User der seine Seite in verschiedenen Sprachen betreiben will, muss zum Zeitpunkt der Installation entscheiden, welchen Zeichensatz er nehmen will. Der Standard ist UTF-8, da der derzeitige, ISO-8859-1, zu sehr auf bestimmte Sprachen limitiert ist.
Die Änderung ist:
$PNConfig['DBInfo']['default']['dbcharset'] = 'UTF-8';

Cachen oder nicht Cachen, das ist hier die Frage

Außerdem wird derzeit der derzeitige und zukünftige Stand von Caching in PostNuke diskutiert. Wieso sollte irgendein Programm die gleiche Prozedur wiederholen, wenn sich von den Daten her nichts geändert hat?
Kein Caching ist praktisch, wenn man unendliche Ressourcen hat (und selbst dort sind Grenzen gesetzt). Aber in der Realität gibt es endliche Ressourcen und man muss Schritte unternehmen, um die Ressourcen so effektiv wie möglich zu nutzen.
Der Schlüssel hierfür besteht im effektiven Cache Management. Sobald das Caching der Module (Renderer) und der Themes aktiviert ist, wird es komplex und dieser Mix führt zu vielen Problemen. Dies wird noch ein paar Überarbeitungen benötigen.