Being way overdue, and not only because some other projects askednagged for a release, I’m really pleased I finally had everything together last week so I could do the release of GeSHi 1.0.8.11. Besides the 18 new language files there are also two important bugfixes addressing problems in contrib scripts. (more…)
Hi guys,
I know it’s been quite a bit since the last release of GeSHi and even though there’s been some confusion about what the most recent version actually was, I’ll probably lighten up the confusion a bit and present some good news to all of you who are waiting for some of the most recently included language files. But first things first. (more…)
Nach dem letztens endlich das Packaging für die von mir etwas für aktuellere PHP-Versionen gepflegte RRDTool-Extension abgeschlossen war, dachte ich eigentlich, dass das soweit auch für PHP 5.4 funktionieren sollte. Da ich wegen dem ausstehenden Support für den Suhosin-Patch aber noch nicht upgraden wollte, gab es natürlich wenig Chancen, das selber zu überprüfen.
Vor knapp 4 Wochen habe ich mich dann aber doch hingesetzt, um meinen Server auf PHP 5.4 zu aktualisieren. Nachdem das Update selbst recht unproblematisch verlief und bis auf wenige Extensions, die einen expliziten Arschtritt zum Compilen haben wollten, alles lief, war die RRDTool-Extension dran. Und (Grüße an Murphy) es wollte nicht compilieren. Aber glücklicherweise waren das nur ein paar Kleinigkeiten, die sich im Wesentlichen darauf beschränkten, den Typ pval durch zval beim Abfragen von Parametern auszutauschen.
Sobald das durch war, funktionierte das auch mit dem Compilieren und alle Scripte mit der Extension liefen wieder wie immer.
Die neu, nun mit Support für PHP 5.4, gepackagedte Version gibt es ab sofort; nach dem ich nach einer stressigen Zeit dazu gekommen bin, das alles zusammenzupacken. Außer der oben genannten Änderung ist nix an Features hinzugekommen. Wird also PHP 5.4 nicht benötigt, reicht auch die alte Version. Die neue RRDTool-Extension für PHP 5.4 (Version 0.2) gibt unter dem genannten Link.
Nein, die Überschrift hat keinen Tippfehler; zumindest, wenn es um die Leere in den Postfächern auf dem Server geht. Ungefähr seit etwa 3 Monaten wollten nämlich sporadisch einige Mails nicht mehr ankommen. Dies war insbesondere auffällig bei Mails, die von GoogleMail aus gesendet wurden: Diese wollten nämlich einfach nicht ankommen. (more…)
Hätte ich nicht schon wieder zwei Abende damit zugebracht, die Ursache für einen Fehler bei einem Joomla-Update zu suchen, würde ich es ja unter der Kategorie „Running Gag“ verbuchen, dass die Joomla-Entwickler jedes Mal auf’s Neue sich in der Kreativität ihrer Bugs übertreffen. War es beim einem Komponenten-Update noch das Unvermögen konsistente Datenstände zu halten, so ist es in Sachen Software-Update die Abwärtskompatibilität zu seinen eigenen, früheren Versionen. (more…)
Bereits seit einiger Zeit wollten sich mein Courier-IMAP(S)-Server und die Kunden-Mailclients nicht so recht vertragen. Und auch die Fehlermeldung der Mailclients war nicht so recht schlüssig, denn der Fehler trat zuerst bei einem Update von Courier 4.4 auf 4.8 auf, war dort aber im Wesentlichen durch einen Programmierfehler bedingt. Da dieser aber eigentlich in der 4.9 bereits lang behoben sein sollte, nun ja. Blieb also als einfachster Workaround ein Hold des Paketes in der alten Software-Version. (more…)
Unter der Kategorie Kuriositäten kann man glaube folgenden GCC-Bug abhandeln, der bei mir mit folgendem Source auftrat:
// Run the job we've taken
if(cleanup_func) {
pthread_cleanup_push(cleanup_func, cleanup_arg);
}
job_func(job_arg);
if(cleanup_func) {
pthread_cleanup_pop(1);
}
Wobei job_func ein normaler Callback-Typ der Form
typedef void (* dispatch_func_t)(void *);
ist, also einen Pointer entgegen nimmt und nix zurückliefert. Nunja. Versucht man obigen Source (im Zusammenhang mit etwas mehr Source eines Thread-Pools zu compilieren, erhält man recht überraschend eine Fehlermeldung vom GCC (4.6.1-4):
gcc -g -Wall -Werror -std=c99 -I./src -O9 -o ./obj/threadpool.o -c ./src/threadpool.c ./src/threadpool.c: In Funktion »_threadpool_dowork«: ./src/threadpool.c:120:9: Fehler: expected »while« before »job_func«
Und ja: Der will da wirklich ne While-Schleife haben! Geben wir sie ihm also:
// Run the job we've taken
if(cleanup_func) {
pthread_cleanup_push(cleanup_func, cleanup_arg);
}
//GCC fails if I DON'T write a while loop here. Let's make it happy!
while(0);
job_func(job_arg);
if(cleanup_func) {
pthread_cleanup_pop(1);
}
Und der GCC ist zufrieden.
Eine der schlimmsten Krankenheiten, wenn nicht gar Geschwüre unter Programmierern ist der Satz „Aber es funktioniert doch!“, wenn man sie darauf hinweist, dass ihre Software fehlerhaft implementiert ist. Unabhängig davon, was wirklich falsch ist, oder wie groß die nötige Änderung ist. So aus Prinzip halt. (more…)
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!
Heute hatte ich wieder einmal eine recht spannende Diskussion. Anlass dieser war, dass Palemoon in Version 4 einen Bug im Updater hat, der dazu führt, dass auch vorhandene Updates nicht gefunden werden. An sich nicht weiter schlimm, könnte man meinen, denn das mit den Updatern haben schon ganz andere Leute nicht hinbekommen. Was mich an der Stelle aber etwas aufgeregt hat, war „die Lösung“ bzw. der vorgeschlagene Würgaround: „Schaltet einfach SSL ab“. Gute Nacht, Sicherheit! (more…)
Powered by WordPress