Programmierung

Wenn "partialCached" Zeit spart und Nerven kostet

20. November 2025 · Programmierung · andreas · Kein Kommentar

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:

baseof.html
... {{- partialCached "page-footer.html" . -}} ...

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.


GNOME-Extension während der Entwicklung testen

06. Juni 2025 · Programmierung · andreas · Kein Kommentar

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”.

Nested GNOME-Shell

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

$ dbus-run-session -- gnome-shell --nested --wayland

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.

export MUTTER_DEBUG_DUMMY_MODE_SPECS=1400x900

Portable Perl-Skripte unter Windows

15. Dezember 2024 · Programmierung · andreas · Kein Kommentar

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.

pp -o test.exe --gui --addfile=test.ini --addfile=test.ico test.pl -T test

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:

perl -e "use Win32::Exe; $exe = Win32::Exe->new('test.exe'); $exe->set_single_group_icon('test.ico'); $exe->write;"

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

..\perl.exe -I lib script\test.pl

Erweiterungen von Joomla! 3 zu Joomla! 4 migrieren

25. April 2024 · Programmierung · andreas · Kein Kommentar

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


The URL is not DAV enabled or not accessible

03. Oktober 2023 · Programmierung · andreas · Kein Kommentar

Nach dem Wechsel des Reverse-Proxys war ein mit HTTP::DAV arbeitendes Perl-Skript nicht mehr in der Lage, Daten abzurufen. Die Fehlermeldung war alles andere als aussagekräftig:

The URL "..." is not DAV enabled or not accessible.

Auch eine Erhöhung des DebugLevels von 0 (“off”) auf 3 (“noisy”) brachte keine weiteren Erkenntnisse, so daß manuelle Fehlersuche angesagt war. Da weder am Server noch am Skript Änderungen vorgenommen wurden, konzentrierte sich die Suche auf den Reverse-Proxy

Letztendlich lag der Fehler an einem fehlenden Intermediate-Zertifikat des Trustcenters auf dem Reverse-Proxy. Nach dem Hinzufügen des fehlenden Zertifikats funktionierten die Zugriffe wieder wie erwartet.