Jupp, Drupal will mich in den Wahnsinn treiben

Ganz eindeutig. Ich weiss nicht was es gegen mich hat, aber es hasst mich heute. Ganz massiv.

Ich hab mir das kubrick-Theme einfach unter einen eigenen Namen kopiert, damit ich es anpassen kann ohne das Kubrick-Theme selber zu ändern. Witzigerweise benutzt es jetzt aber nicht mehr die phptemplate-Engine. Oder genauer: der Eintrag in der Tabelle system (type='theme' und dann für das page.tpl.php) zeigt nicht auf phptemplate.engine, sondern auf phptemplate - das .engine fehlt. Wenn ich es per Update anhänge, funktioniert das genau ein mal. Danach wird dieser Eintrag in der Tabelle system überschrieben und .engine ist futsch und das Template kaputt. Mit Kubrick tuts das natürlich alles. Und natürlich findet man nirgendwo eine Info wo verflixt nochmal das Theme sagt welche Template-Engine benutzt werden soll - und wie dieser Eintrag in der Tabelle system entsteht. Nein, so einfach nach phptemplate.engine grepen bringt nix.

Ok, mir ist jetzt klar das die Engine die Einträge erzeugt - jedenfalls nachdem ich mir den Source zur Engine mal näher angeguckt habe. Da wird nach page.tpl.php gesucht und wenn das gefunden wird, wird mit der phptemplate.engine verbunden. Aber warum sollte die Engine ihren eigenen Namen falsch eintragen? Zumal sie es bei Kubrick ja richtig macht. Das hab ich ja auch einfach nur ausgepackt in das themes-Verzeichnis.

Jut, also weiter forschen. Ein grep -r auf INSERT in Kombination mit system findet dann im system.module die Funktion system_obtainthemeinfo, in der diese Sätze geschrieben werden. Aber wie und wo genau da jetzt was damit gemacht wird - sorry, aber das findet man nicht raus ohne längeres Studium. Irgendwie wird das description Attribut mit einem Wert gefüllt der beim Kubrick-Theme mit .engine endet und bei allen anderen nicht. Kubrick referenziert die Theme-Engine exakt und korrekt, aber eine beliebig benamste Kopie von Kubrick mit identischem Inhalt referenziert eine Theme-Engine ohne .engine im Namen und tuts nicht. Toll. Aber Kubrick umbenennen funktioniert. Hä?

Ok, nächster Ansatz. Mein Template umbenennen in was anderes und Kubrick umbenennen in meinen eigentlich gewünschten Namen. Verwirrung komplett: mein Template tut nicht, aber das jetzt kubrick heissende und vorher nicht funktionierende tut jetzt auch nicht. Äh .. Also das Kubrick in was anderes umbenannt. Und mal mein zwischengelagertes ausprobiert. Das tuts jetzt. Unter einem Namen der nicht Kubrick ist. Hä? Hütchenspiel? Benenne jetzt die Themes so lange um bis ich irgendwann unter dem von mir gewünschten Namen ein funktionierendes habe und dann ist gut?

Also mal versucht das Hütchenspiel aufzulösen. Computer sind doch deterministische Kisten, das muss doch gehen. Ok, beide Templates (originales Kubrick und mein Hugo) umbenannt. In aa und bb. Und welches funktioniert? Das was bb heisst. Nochmal das ganze, nur jetzt die Rollen vertauscht. aa wird bbb und bb wird aaa. Welches funktionert jetzt? Das was "bbb" heisst. Wenn zwei phptemplate.engine basierte Themes im System installiert sind, funktioniert nur das zuletzt im System gefundene zum Zeitpunkt wo nach den Themes gesucht wird. Die anderen gehen kaputt.

Also muss ich jetzt erstmal rauskriegen was eigentlich mit den alten Themes los ist, warum die nicht zum Funktionieren zu kriegen sind. Erster Ansatz: einen Dump der Datenbank machen und mit grep gucken wo überall meine Freunde auftauchen. Dabei hab ich dann gleich gefunden was mit dem ominösen phptemplate ohne .engine ist: die entsprechenden Einträge enthalten statt des Punktes einen chr(0). Ascii-Null. Wird von MySQL zwar gespeichert, aber von PHP wohl abgeschnitten beim Zugriff. Und für die ganzen alten Templates sind diese ganzen kaputten Einträge da. Ausserdem hat sich noch die engine im Eintrag phptemplateextratemplates in der Tabelle variable gemerkt welche Themes sie schon gesehen hat.

Noch mal ein clean room Test: die Einträge in der Tabelle system mit type='theme' und description like 'themes/engine/phptemplate%' rauswerfen. Dann weiss er nix mehr von den Themes und ihren Namen. Dann nur mein gewünschtes Template haben und dieses dann aktivieren. Und siehe da, es funktioniert auf Anhieb. Dann mal kubrick ausgepackt. Und es funktioniert. Danach tuts aber mein eigenes Theme nicht mehr. Wie erwartet - kubrick kommt im Alphabet nach hugo. Kubrick wieder löschen und schon tuts mein eigenes Theme wieder - nach entsprechendem Refresh.

Also nachforschen wo zum Kuckuck diese Geschichte passiert und wieso. Es passiert ja nur mit den phptemplate.engine Themes. Die xtemplate.engine Themes tuns ja problemlos. Wobei sich herausstellt das die es trotz des Bugs tun - er betrifft sie auch. Denn im system.module in system_themedata (wie ich das rausgefunden habe erspare ich den Lesern mal - es war einfach sukzessives Einsetzen von echo Befehlen um zu gucken wann wo was kaputt geht) wird im letzten Schritt - im Aufruf von systemobtainthemeinfo - an den Files das description-Element zerstört. Und das ist es, das in die Systemtabelle gespeichert wird um auf die Theme-Engine zu referenzieren. Nur das letzte Theme einer Engine behält den korrekten Eintrag, alle anderen sind kaputt.

Hmm. Der basename-Aufruf in Zeile 336 ist der einzige Kandidat - er liefert eigentlich nur die Theme-Engine ohne das .engine hinten dran raus. Aber er sollte das eigentliche Feld nicht verändern, deshalb hatte ich ihn vorher nicht sonderlich beachtet - die PHP-Doku sagt nix über Seiteneffekte dieser Funktion. Aber wenn ich den Eintrag auskommentiere, funktinioniert mein Theme und Kubrick auch - gleichzeitig. Im PHP Handbuch steht aber nix davon, das basename den ursprünglichen String verändert.

Also ein kleines Testscript geschrieben, das nur einen basename-Aufruf macht. Örks. Ja, das ist es - basename verändert den Ursprungsstring, und zwar haut es einen chr(0) anstelle des Punktes rein. Und siehe da, es gibt einen Bugreport aus 2002 dazu - ja, ich hab ne alte PHP 4.1.2 Version laufen, da Debian Stable. Beim Bugreport steht eine brauchbare Lösung für mein Problem - einfach die Variable in "" setzen und so mit String-Interpolation arbeiten. Und siehe da, Problem gelöst. Und Knoten ins Ohr machen: bei 4.1.2 macht basename die Quellvariable kaputt.

Und mit so einem Scheiss (damit mein ich den Bug, nicht Drupal) beschäftigt sich ein Programmierer beim Debugging

Ich hätte auch einen anständigen Job erlernen können. Whisky-Fass-Bewacher bei Jack-Daniels zum Beispiel ...

tags: CMS, Drupal, Sysadmin