Warning: count(): Parameter must be an array or an object that implements Countable in /var/www/virtual/benny-baumann.de/blog/htdocs/wp-includes/post-template.php on line 316

Warning: count(): Parameter must be an array or an object that implements Countable in /var/www/virtual/benny-baumann.de/blog/htdocs/wp-includes/post-template.php on line 316

BenBE's humble thoughts Thoughts the world doesn't need yet …

14.06.2011

Komponenten-Update mit sehr viel Fail

Filed under: Software — Schlagwörter: , , , — BenBE @ 01:50:56

Heute gibt es wiedermal ein Leckerli aus der Kategorie „Soviel Fail gibt’s nur bei Joomla“. Wer also schon immer über Joomla lästert, findet hier nun genau einen weiteren Punkt, wie Software nicht aussehen sollte. Aber gehen wir einmal der Reihe nach.

Für ein Projekt baue ich derzeit eine Komponente in Joomla, die eine Reihe von Erweiterungen in der Oberfläche implementiert. Die Komponente ist auch soweit fast fertig und ist im Backend wunderbar angebunden. Da im Laufe der Entwicklung noch zwei Menüpunkte zu ergänzen waren, musste diese kurzzeitig deinstalliert und wieder neuinstalliert werden, was an sich auch kein Problem darstellt, wäre da nicht … ähhhm … Joomla.

Die Komponente implementiert im Frontend nämlich die Erzeugung von SEO-freundlichen Links, die – aus einem Vorgängerprojekt stammend – auch bereits wunderbar funktionierten und im Produktiveinsatz keinerlei Probleme zeigten. Seitdem die Komponente jedoch zwischenzeitlich neu im Joomla eingebunden wurde, um die Anpassungen im Menü des Backends zu übernehmen, sah man nur die Joomla-typischen ItemId-Parameter in der Adresszeile. Die vormals funktionierenden Routen (wie die SEO-URLs im Joomla-Slang heißen) wurden nicht einmal mehr noch beachtet. Aufrufbar waren die Links dennoch. Auch ein erneutes Abspeichern der Menüeinträge, nachdem der Item-Type neu gesetzt wurde, bewegte Joomla nicht dazu, wieder SEO-URLs anzuzeigen.

Also fängt das Debugging an. Und wer jetzt als Admin nicht zumindest die Postfix-Konfiguration oder eine Einsendung zum IOCCC gewohnt ist, sollte u.U. erstmal was essen; auf nüchternen Magen verträgt man das nämlich sonst nicht. Also gut: Schauen wir zuerst einmal in die Joomla-Datenbank, um zu sehen, was Joomla bei der Komponenten-Installation so feines anstellt. Als erster Kandidat erweist sich hier die Tabelle jos_extensions. In dieser stehen alle Komponenten, Themes, Plugins und wie die Teile im Joomla-Slang wohl noch so alle heißen. U.a. findet sich hier auch ein Eintrag unserer Komponente, die nicht mehr geht. Nunja: Normal wäre ein Eintrag, seltsamer Weise hat es Joomla aber geschafft, hier mehrere Einträge draus zu machen, weshalb die Komponente zwei Mal auftaucht. Auch übrigens im Admin-Panel. Naja, passiert. Löschen wir also beide Einträge, deinstallieren die Dateien aus dem Joomla-Verzeichnis, die unsere Komponente betreffen und spielen die Update-Datei erneut ein.

Wer nun mit einer Meldung „Juhu, erfolgreich installiert“ gerechnet hat, darf bitte noch einmal das Thema dieses Posts verinnerlichen: Joomla! Stattdessen wirft einem Joomla eine Meldung „Error building admin menu“ an den Kopf. Naja, schauen wir noch mal in die Datenbank und finden da eine Tabelle jos_menu. Ja, hier handelt es sich, wie der Name vermuten lässt, um die Tabelle, in der jegliche Menüeinträge aufgeführt werden. Und wie es sich für ein unsauber konzipiertes System wie Joomla gehört, auch anwendungsübergreifend Frontend und Backend gemischt. Wer also mal so richtig sein Backend zerschießen will, darf in der jos_menu-Tabelle gerne anfangen. In besagter Tabelle fanden sich nun die von der Komponente in der XML-Datei registrierten Menü-Punkte. Jedoch nicht von der aktuellen Installation, sondern – fein säuberlich aufgehoben – von der Erstinstallation der Komponente. Also jos_menu aufräumen, die Komponente aus jos_extensions deinstallieren UND die Komponente wieder aus der Joomla-Installation entfernen.

Womit wir den nächsten Anlauf starten können. Komponenten-Package hochladen und auf die Meldung warten. Diese teilte uns diesmal (rot untermalt) mit, dass kein Fehler aufgetreten sei … bei der Ausführung einer Datenbank-Funktion. Womit wir bei vielsagenden Fehlermeldungen wären, denn in einer Fehlermeldung mitzuteilen, dass kein Fehler aufgetreten sei, ist nur bei Status-Code 0 unter Windows witzig, weil es dort zumindest der Erwartungshaltung des Anwenders entspricht. Denn wenn kein Fehler aufgetreten ist, obwohl man einen erwartet, spricht das entweder dafür, dass man sein Programm in die Tonne hauen sollte, oder etwas schief gelaufen ist, was einfach nicht bedacht wurde. Da die Fehlermeldung leider den Informationsgehalt einer Nachricht über einen umgefallenen Sack Reis in China hatte, ging der Weg erstmal zur Suchmaschine der Wahl, wo gleich der 3. Treffer aus einer Bündelung von Forendiskussionen zu dieser Fehlermeldung auf die 3. Tabelle in der Joomla-Datenbank verwies: jos_asset, die manchmal, unter nicht ganz nachvollziehbaren Umständen, noch Datenmüll beinhaltet, den Joomla selber nicht aufräumen will. Also auch hier kurz mit dem Datenbank-Tool der Wahl kurz gekehrt, die beiden anderen Tabellen wieder gereinigt und die Komponente nochmals installiert. Überraschenderweise diesmal sogar ohne Fehlermeldung.

Einzig die SEO-URLs, wegen derer ich diesen ganzen Aufriss angestellt hatte, waren immer noch nicht in Sichtweite.

Wobei, nicht ganz. Ich erwähnte ja besagte Tabelle jos_menu, in der Joomla jeglichen Datenmüll, der Menüeinträge betrifft, hinterlegt. Unter anderem finden sich hier die URL des Menüeintrags, die Art des Menüeintrags, sowie eine seltsame Zahl, die mit der Spaltenüberschrift component_id versehen ist. Wie jetzt? Sagt euch nix? Naja, schauen wir mal, ob sich da was finden lässt?

Ein Ansatzpunkt für die Lösung des Rätsels stellte – nahezu offensichtlich, wenn man sich die Werte anguckte – die Tabelle jos_extensions dar. Ja, DIE Tabelle jos_extensions, in der wir vorhin angefangen haben. Und nein, wir haben vorhin auch nicht die falsche der doppelten Komponenten-Registrierungen gelöscht, wie man zuerst vermuten könnte. Das ließ sich nämlich recht einfach anhand der – richtig – component_id feststellen, die es zum Ausgangszeitpunkt nämlich auch schon nicht (mehr) gab.

Was passiert war, ist an sich nämlich recht einfach – und genauso hirnrissig so zu implementieren; aber wir reden ja grad über Joomla, die tun sowas einfach: Menüeinträge sind statt auf den component_name (also ‚com_foo‘) auf die (installationsabhängige) component_id fixiert. Diese wird jedoch nicht aktualisiert, wenn eine Komponente nicht über den Upgrade-Mechanismus aktualisiert werden kann. Stattdessen zeigt diese dann ins Leere, obwohl anhand der URL die Beziehung zur zuständigen Komponente wieder hergestellt werden kann. Auch ein erneutes Speichern des Menüeintrags sorgt bei Joomla nicht dafür, dass dieser offensichtliche Integritätsfehler korrigiert wird. Wenn Joomla also die SEO-URL für diese URL erzeugen soll, beachtet es ein Feld, dessen Integrität offensichtlich defekt ist, statt die im Router eh ausgewertete Information zur Komponente heranzuziehen. Ändert man manuell für alle Menüeinträge, die noch auf eine alte, ungültige component_id zeigen, diese auf die aktuelle Kennung, so geht es. Ach ja: Wer Spaß haben will, darf das Routing übrigens auch sein Template machen lassen; man muss nur die richtigen IDs in die DB und Dateien auf die Platte schreiben.

Was immer die bei Joomla rauchen: Das Zeug muss gut sein!

Flattr this!

1 Kommentar »

  1. 1000 Dank. Ich sitze gerade auch an einer Extension für Joomla. Und hatte ein ähnliches Problem. Dieses jos_assets, hatte bei mir immer nen Fehler produziert.

    Also Vielen Dank

    Grüße

    Kommentar von Michael Raeck — 04.10.2011 @ 14:46:43

RSS feed for comments on this post. TrackBack URL

Leave a comment

Powered by WordPress