Seit der Umstellung von WordPress läuft das Autoren-Archiv des Blogs weiterhin unter der von WordPress verwendeten “/authors”-URL.

In jedem Beitrag ist im Front Matter der Wert “author” gesetzt und dieser in der “hugo.toml” als eigene Taxonomie definiert:

Da es sich (bis auf wenige Beiträge) um ein deutschsprachiges Blog handelt und ich auch schon einige andere beim Umzug übernommene Dinge über Bord geworfen habe, sollte auch das Autoren-Archiv nach “/autor” umziehen.

Die einfachste Lösung wäre sicherlich, die Taxonomie selbst von “author” in “autor” umzubenennen, da sich aus dem Namen der Taxonomie aber auch Variablen (z.B. “.Params.Author”) ableiten, wollte ich die Verwendung eines deutschen Begriffs - und auch das Mixen von deutschen und englischen Begriffen im Front Matter - vermeiden und an dieser Stelle beim englischen “author” bleiben.

Der erste (nur teilweise funktionierende Ansatz) war das Setzen eines Permalinks für die Taxonomie in der Permalinks-Sektion der “hugo.toml”:

Nach dieser Änderung wurden die einzelnen Autorenseiten zwar wie gewünscht unter z.B. “/autor/andreas/” angelegt, die Autoren-Übersicht wurde aber weiterhin unter “/author” erzeugt.

Ein erster (funktionierender) Lösungsansatz war das Anlegen einer “_index.md”-Datei im neu erstellten Verzeichnis “/content/author/” mit folgendem Inhalt:

Dies funktioniert zwar, aber das Anlegen des zusätzlichen Verzeichnisses mitsamt Datei zum Umbiegen der URL ist irgendwie unschön und verteilt die Definition der zu erstellenden URLs auf verschiedene Stellen, was sicherlich irgendwann einmal beim Thema “Wartbarkeit” Kopfzerbrechen bereitet.

Eine elegantere Lösung fand sich im Beitrag Taxonomy terms page permalink - how to change it? des Hugo-Forums - eine getrennte Angabe des Definition eines Permalinks für den Bereich “taxonomy” und “term”:

Damit funktioniert das Erzeugen der Taxonomie-Übersicht an der richtigen Stelle, es muß keine zusätzliche Datei mitsamt Verzeichnis angelegt werden und die komplette Permalink-Konfiguration bleibt in der “hugo.toml”.

Manchmal sieht man den Wald vor lauter Bäumen nicht und so habe ich die Tage einiges an Nerven (und auch Zeit) investiert, um herauszufinden, warum das Partial, welches für die Einbindung des Footers dieser Website zuständig ist, “.IsHome” so überhaupt nicht auswerten wollte.

Alle möglichen und unmöglichen Tricks über temporäre Variablenzuweisungen führten nicht zum gewünschten Ergebnis und wie so oft half eine Pause und anschließend ein frischer Blick auf den Code:

Das Partial “page-footer.html” war mittels der Funktion “partialCached” eingebunden, da der Footer rein statisch ist und somit nicht für jede Seite neu erzeugt werden muß. Dies bewirkt “leider” auch, daß der Wert von “.IsHome” nur bei der ersten Erstellung ermittelt und der ermittelte Wert anschließend auf allen weiteren Seiten verwendet wird.

Nach der Änderung von “partialCached” zu “partial” wurde “.IsHome” auch wie erwartet ausgewertet.

Während unter X11 zum Testen einer Erweiterung die Möglichkeit bestand, mittels Alt+F2 und “r” die GNOME-Shell ohne Abmeldung neu zu starten, ist dies mit Wayland nicht mehr möglich. Es erscheint lediglich der Hinweis “Neu Starten ist unter Wayland nicht verfügbar”.

Der Getting Stared-Guide empfiehlt als Alternative eine “nested GNOME-Shell session” zu starten:

Nach Ausführen des Befehls öffnet sich ein Fenster mit einer neuen Instanz der GNOME-Shell, in der die Erweiterung getestet werden kann. Wer die Größe des sich öffnenden Fensters beeinflussen möchte, kann dies durch Setzen der Umgebungsvariable “MUTTER_DEBUG_DUMMY_MODE_SPECS” tun.

Um ein Perl-Skript portabel zu machen, muß zusammen mit dem Skript auch die Perl Laufzeitumgebung sowie die benötigten Bibliotheken ausgeliefert werden.

Befragt man die Suchmaschine der Wahl, landet man meist bei der Empfehlung, einen Perl-Packer zu nehmen, von denen es im CPAN zwei Stück gibt: PAR-Packer und perlcc, wobei von der Verwendung von perlcc im produktiven Umfeld ganz klar abgeraten wird: “Use for production purposes is strongly discouraged.”.

Mit pp gibt es ein eigenes Skript, auf Basis von PAR ausführbare Dateien erzeugt und ein Skript mitsamt aller benötigter Bibliotheken in einer einzelnen .EXE-Datei verpackt.

Das Packen ist recht flexibel und schnell erledigt, die einzelnen Optionen können in der Dokumentation nachgeschlagen werden.

Wer noch gerne ein schöne(re)s Icon für die erzeugte .EXE-Datei verwenden möchte, kann dies mit einem Einzeler hinzufügen:

Als Ergebnis wird eine Datei “test.exe” erzeugt, die dann auf ein System ohne Perl-Laufzeitumgebung kopiert und dort ausgeführt werden kann. Die Beschreibung “perlcc that works without hassle” klingt erstmal gut und die Ergebnisse funktionieren, bringen aber leider in der Anwendung einige Probleme mit sich:

Technisch gesehen wandelt pp nicht wirklich das Skript in eine .EXE-Datei, sondern erzeugt ein selbstenpackendes Archiv, dessen Inhalt nach dem Entpacken letztendlich ausgeführt wird. Das Archiv wird standardmäßig ins TEMP-Verzeichnis des ausführenden Benutzers entpackt, was spätestens dann zu Problemen führt, wenn - aus guten Grund - unprivilegierten Benutzern das Ausführen von Code innerhalb des TEMP-Verzeichnisses verboten ist.

Zum Entpacken wird ein Verzeichnis nach dem Muster “%TEMP%\par-USER\cache-GUID” angelegt, wobei USER durch eine Hex-Repräsentation des ausführenden Benutzers und GUID durch einen Hash der ausführbaren Datei ersetzt wird. Letzteres lässt sich mit Hilfe des Parameters “-T” durch einen festen Wert ersetzten, so daß der Pfad dann “%TEMP%\par-USER\cache-test” lautet.

Durch das Cachen der entpackten Dateien wird bei späteren Starts die Wartezeit deutlich verkürzt, je nach System und Anzahl der Benutzer können aber zahlreiche Dateileichen im Temp-Verzeichnis verbleiben.

Manuelle Paketierung

Abgesehen von der suboptimalen Ausführung erledigt pp das Sammeln aller benötigter Dateien sowie Erstellen des Pakets zuverlässig, so daß sich die Verwendung von pp als Zwischenschritt zum manuellen Packen anbietet.

Nach dem erstmaligen Ausführen der von pp erzeugten Datei werden folgende Inhalte des Verzeichnisses “%TEMP%\par-USER\cache-test” in ein Arbeitsverzeichnis kopiert:

• der komplette Ordner “inc” inklusive aller darin enthaltenen Unterverzeichnisse
• die Dateien “libgcc_s_seh-1.dll”, “libstdc++-6.dll”, “libwinpthread-1.dll” sowie “perl530.dll”

Anschließend kann noch etwas augeräumt werden:

• im Ordner “inc” können die Dateien “MANIFEST” sowie “META.yml” gelöscht werden
• im Ordner “inc/script” kann die Datei “main.pl” gelöscht werden

Zum Ausführen müssen aus der Perl-Installation noch zwei Dateien kopiert werden:

• die Datei “perl.exe” oder “wperl.exe” aus dem Ordner “perl/bin” ins Arbeitsverzeichnis - je nachdem, ob es sich um eine Kommandozeilen- oder GUI-Anwendung handelt
• die Datei “lib.pm” aus dem Ordner “perl/lib” in den Ordner “inc/lib”

Anschließend kann aus dem Ordner “inc” das Skript mit folgendem Aufruf gestartet werden:

Im Laufe der Jahre hat sich die Anzahl der von mir betreuten Joomla!-Installationen deutlich reduziert. Von mehreren Websites ist noch eine Intranet-Seite übriggeblieben, welche bis vor Kurzem noch mit Joomla! 3 lief.

Hauptgrund hierfür war die aus meiner Sicht nur spärlich vorhandene Dokumentation für Entwickler, welche Anpassungen an Erweiterungen bei Versionsänderungen zu machen sind. Während zum Beispiel der Wechsel zu Hugo auf Grund der guten Dokumentation in Kombination mit einem ebenso guten Forum nur wenig Frustmomente bot, war schon die Erfahrung beim Umstieg von Joomla! 1.5 auf 2.5 derart nervig, daß im Laufe der Zeit alle Websites von Joomla! zu WordPress migriert wurden, statt den Versuch zu starten, die bestehende Funktionalität unter der neuen Joomla!-Version lauffähig zu bekommen.

Nachdem inzwischen aber Joomla! 5 veröffentlicht ist, sollte auch die Intranet-Site zumindest auf Joomla! 4 migriert und somit auch die selbstentwickelten Erweiterungen angepasst werden, was sich wieder als frustrierendes Erlebnis entpuppte. Wenn es schon Zusammenstellungen wie “Potential backward compatibility issues in Joomla 4” gibt, wäre es hilfreich, wenn dort nicht als erstes ein “Content is Incomplete” ins Auge springen würde und viele der hier aufgelisteten Dinge auch dort zu finden wären.

In diesem Beitrag habe ich die verschiedenen Quellen gesammelt, mit denen ich die Erweiterungen mit Joomla! 4 lauffähig gemacht habe - am Ende des jeweiligen Abschnitts ist als Quelle die Seite angegeben, auf welcher ich als erstes auf meiner Suche nach Lösungen fündig wurde. Vieles davon ist sog. Legacy-Funktionalität, d.h. ich habe nicht nach aktueller Philosophie neu entwickelt, sondern versucht, mit minimalem Aufwand die jeweilige Erweiterung zu reparieren und wieder funktionsfähig zu bekommen.

Vollständigen Beitrag lesen