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.

Weiterlesen

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:

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.

Nachdem mit Hilfe des XUM 1541-Adapters die Originalmedien als D64-Images auf dem PC gesichert wurden, steht als nächstes das Auslesen der auf den Disketten befindlichen Dateien an. Es gibt hierzu eine ganze Reihe von Programmen, mit am einfachsten ist wohl das mit dem VICE-Emulator mitgelieferte Kommandozeilenprogramm “c1541”, welches die Aufgabe in einer Zeile erledigt:

Der Spaß am C64 war aber schon immer das Basteln und so war es naheliegend, selbst ein Programm zum Auslesen zu schreiben, dabei etwas Retro-Luft zu schnuppern und längst verblasstes Halbwissen aufzufrischen.

Weiterlesen

Eine selbsterstellte Erweiterung für die GNOME Shell funktionierte zwar einwandfrei, allerdings beschwerte sich der Dconf-Editor, daß die Konfigurations-Schlüssel trotz vorhandenener “schema”-Datei im Erweiterungsordner nicht von einem Schema definiert würden.

Beim Klick auf einen Schlüssel wurde zusätzlich eine erweiterte Fehlermeldung angezeigt:

Kein Schema verfügbar. Ein Schema beschreibt die Verwendung eines Schlüssels und Dconf-Editor kann kein Schema finden, das diesem Schlüssel zugeordnet ist.

Zur Lösung des Problems half ein Blick in die Dateiliste einer mit Debian mitgelieferten Erweiterung wie z.B. “Dash to Dock”

Offensichtlich müssen die “schema”-Dateien in einem gesonderten Verzeichnis gespeichert werden. Für eine im Benutzerkontext installierte Erweiterung ist dies der Ordner “~/.local/share/glib-2.0/schemas” statt dem Systemordner “/usr/share/glib-2.0/schemas”

Nach dem Anlegen des Ordners und dem Kopieren der Schema-Datei (wahlweise funktioniert auch das Setzen eines symbolischen Links) muß die Schema-Datei noch kompiliert werden, dann ist auch der Dconf-Editor zufrieden.

RTFM hätte hier auch ohne den Umweg über eine andere Erweiterung geholfen, denn die Hilfeseite zu “glib-compile-schemas” verrät bereits:

The usual location to install schema files is /usr/share/glib-2.0/schemas.

Werden z.B. innerhalb einer Schleife verschiedene Elemente mit Hilfe eines regulären Ausdrucks ausgewertet, so werden im Falle eines Nicht-Treffers die Treffer-Variablen nicht zurückgesetzt.

Auf den ersten Blick wäre zu erwarten, daß lediglich eine Zeile als Ergebnis ausgegeben wird, tatsächlich sind dies aber zwei:

Die Ursache liegt in der überhaupt nicht durchgeführten Überprüfung des Ergebnisses des regulären Ausdrucks, die korrekt so aussehen muss:

Dann erscheint auch - wie ursprünglich erwartet - als Ergebnis nur eine Zeile:

Notiz an mich selbst: eine korrekte Behandlung von Abfrageergebnissen erspart eine aufwendige Fehlersuche.