rfc1437.de: new entries tagged with Drupal

Weiteres zu Drupal

Thu, 10 Feb 2005 12:50:45 +0100

Was mir bei meinen Spielereien mit Drupal noch aufgefallen ist: im Unterschied zu WordPress ist das Datenbankmodell recht komplex. WordPress ist ziemlich stumpf - einfach ein paar Tabellen mit Daten drin, das meiste recht straight forward. Wenn man was ändern will kann man jederzeit auf SQL Ebene damit rumwurschteln und z.B. Importscripte, Reparaturscripte etc. schreiben. Alles wird immer on the fly ermittelt - Zähler, Listen etc.

Drupal hingegen benutzt recht aufwändige Caching-Mechanismen in der Datenbank. Auch Sachen aus dem Filesystem werden gecached. Dadurch hat man mit kleinen Scripten höheren Aufwand, da man wesentlich mehr Stellen berücksichtigen muss - mindestens den Cache beseitigen, damit er rekonstruiert wird. Auch ist das Datenmodell wesentlich stärker ausnormalisiert. Das ist natürlich gut vom Design her - aber für kleine Scripte natürlich aufwändiger, da man an mehr Stellen anpacken muss.

Das ist jetzt keine Wertung, nur eine Beobachtung - beides hat Vor- und Nachteile. Die Vorteile des Drupal-Ansatzes scheinen sich in der Performance zu zeigen, die nicht nur wegen der etwas aufgeräumteren PHP-Struktur etwas besser als die von WordPress scheint (wobei ich da keine harten Zahlen habe - erst brauche ich ein brauchbares Import-Script für meine Postings um mit gleichen Ansätzen zu arbeiten).

Was mir noch aufgefallen ist: die PostgreSQL-Unterstützung (ja, ich habs jetzt endlich laufen!) in Drupal ist definitiv hinter der von MySQL zurück. Zum Teil gibts mit PostgreSQL Fehlermeldungen die mit MySQL nicht auftreten. Zum Beispiel beim Passwort-Wechsel gabs Probleme weil ein nicht existentes Feld angesprochen wurde. Oder bei der Übersicht der im Newsreader abonnierten Quellen gabs ne Meldung weil ein nicht-aggregiertes Feld eines komplexen SELECTs nicht als Gruppierungsfeld aufgeführt wurde. Oder beim ersten Zugriff, wo für das Feld uid in der Tabelle sessions kein Wert angegeben wurde, obwohl es als NOT NULL deklariert ist. PostgreSQL ist halt deutlich pingeliger als der Karteikasten. Mit PostgreSQL wird man definitiv Hand an den PHP-Code legen müssen. Mal schauen, wenn ich fertig bin mache ich vielleicht mal einen Patch fertig, der diese Probleme behebt. Bis jetzt sinds nur Kleinigkeiten, die aber für Nicht-Programmierer durchaus eine Hürde darstellen können. Zum Teil basieren die aber sicherlich auch auf den etwas älteren Versionen aus der Debian Stable (z.B. ist das PgSQL API in PHP in neueren Versionen deutlich anders benannt als in der 4.1.2).

Wordpress to Drupal Migration Script

Thu, 10 Feb 2005 00:26:09 +0100

Wordpress to Drupal Migration Script - kann aber im Moment wohl nur von Karteikasten nach Karteikasten migrieren - eine richtige Datenbank als Ziel muss man ihm unter Umständen erst beipulen.

Update: naja, das Script macht wirklich nur die Übertragung der Postings. Keine Post-Slugs (also kein Erhalt der URLs), keine Kategorien, nix. Kann man vielleicht benutzen wenn man nur ein sehr einfaches WP-Blog hatte, aber ansonsten ist es doch arg mager. Und bei grossen Blogs fliegt es einem nach einer Weile mit einem Fehler um die Ohren - der erlaubte Speicher ist erschöpft. Denn PHP benutzt von der Kommandozeile die Einstellungen für das CGI - und auch da ist der Speicherbedarf begrenzt. Dazu kommt dann noch, das es keinerlei Duplikateerkennung hat und deshalb lustig beim zweiten Lauf alles nochmal importiert.

Klingt so als ob ich mir da wohl doch was eigenes schreiben müsste, wenn ich das ganze mal ernsthaft ausprobieren wollte.

Jupp, Drupal will mich in den Wahnsinn treiben

Tue, 8 Feb 2005 23:28:48 +0100

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

Don't reset existing password on request, prevent DoS password reset abuse | drupal.org

Tue, 8 Feb 2005 13:21:16 +0100

Don't reset existing password on request, prevent DoS password reset abuse - tja, genau das Problem hab ich auch bemerkt und konnte nicht fassen das tatsächlich jemand sowas in ein CMS eingebaut hat. Man kann in Drupal für einen Benutzer das Passwort wechseln - und zwar für jeden. Das neue Passwort wird dann diesem Benutzer per Mail zugeschickt. Man kann also darüber keinen illegalen Zugriff erlangen, ausser man kann die Mails des Benutzers abfangen (was in der Regel wohl hoffentlich nicht der Fall sein wird). Aber man kann einen Admin aussperren: einfach einen Job aufsetzen der minütlich das Passwort des Admins zurücksetzt. Und dann diese zwangsweise Abwesenheit des Admins dazu nutzen um das Drupal vollzuspammen zum Beispiel.

Sowas ist wirklich ein peinlicher Patzer. Wird leider viel zu gerne und viel zu häufig gemacht. Wer also Drupal betreibt, dem sei der Patch empfohlen (aufpassen, der Autor hat zwei Patches reingereicht, der erste war noch buggy). Liess sich problemlos installieren und behebt zumindestens die Aussperrung des Admins. Nervige Mails kriegt man natürlich trotzdem dabei.

Manche Projekte wollen mich in den Wahnsinn treiben

Tue, 8 Feb 2005 00:25:54 +0100

oder so könnte man zumindestens meinen. Heute im Programm: Drupal 4.5.2. Nettes Paket, gefällt mir vor allem weil es jetzt auch Kubrick als Theme für Drupal gibt und weil es recht mächtig ist und trotzdem noch einigermaßen überschaubar. Nur falle ich jedesmal wenn ich mich nach längerer Zeit wieder damit beschäftige auf die gleichen Sachen rein: zum Beispiel die Aktivierung von Übersetzungen. Ist ja toll das es Übersetzungen gibt. Aber wenn es nirgendwo auf der Website auch nur Andeutungen darauf gibt was man machen muss, dann sitzt man schon ziemlich doof da. Ok, ja, man muss nur das locale.module aktivieren. Und wo bitte steht das? In der x-ten Hierarchie im Administrationsmenü. Genauso toll: es wird eine Datenbankanbindung für PostgreSQL mitgeliefert. Dummerweise ist die aber erst ab PHP 4.3 brauchbar - ältere Versionen werden nicht unterstützt, obwohl Drupal ab 4.1 läuft. Nachdem ich alles umeditiert habe auf die alten Funktionsnamen liefs immer noch nicht: da fehlte scheinbar ein default für die Spalte uid in der Tabelle sessions. Nachdem ich das gesetzt hab, hängte sich das PHP auf beim Zugriff auf die Site. Ok, ja, ich weiss, MySQL nehmen (ich mag MySQL aber nicht ...). Fein, jetzt bin ich drin, ich hab auch Kubrick als Layout und deutsche Übersetzungen. Ok, einen Teil des Systems in Deutsch - da fehlen Berge von Strings. Also weiss ich was ich demnächst mal wieder machen werden. Toll. Genauso toll wie der Default-Wert für das Fileverzeichnis, der einfach nur "files" ist. Was nicht funktioniert wenn man Bilder upload für Benutzer erlauben will, weil dann "files" und "pictures" ohne / aneinandergehängt werden. Und nein, der / darf nicht vor "pictures" stehen, sondern muss hinter "files" stehen. Das bei Kubrick das Menü in der rechten Spalte bei der Aktivierung von Blöcken natürlich als "links" ausgewählt werden muss, brauche ich sicherlich nicht extra zu erwähnen. Und das das Handbuch alles andere als aktuell ist - sorry, aber das ist einfach lachhaft. Da wird noch von Verzeichnisstrukturen zum Teil gesprochen, die gibts garnicht mehr. Nein, die Einstellungen sind nicht in sites/default/settings.php - die sind in includes/conf.php.

Menno. Das ist so ein schönes Projekt. Und das ganze System ist wirklich leistungsfähig und stabil. Aber die Dokumentation ist wirklich ein Witz. Manchmal hab ich das Gefühl die Leute dokumentieren garnicht Drupal sondern irgendwas anderes

Schön ist es trotzdem, also will ich mal nicht zu laut meckern. Andere machens ja auch nicht wirklich besser. Trotzdem - könnte so schön sein, wenn der Hinweis auf das Online-Handbuch wirklich helfen statt verwirren würde ...

Releases | drupal.org

Wed, 19 May 2004 14:33:04 +0200

Releases | drupal.org - Download page for Drupal modules

drupal.org

Wed, 19 May 2004 14:18:08 +0200

Ich spiele im Moment auch mal ein bischen mit drupal herum. Erster Eindruck: wow! Extrem leistungsfähig, extrem viele Features. Allerdings unter Umständen viel zu viele Features. Was mir aber auf Anhieb gefällt ist die sehr aufgeräumte Oberfläche mit recht logischer Menüstruktur, und das alle Erweiterungen sich automatisch in diese Menüs einklinken. Auch gefällt mir die Lösung mit den Templates und Themes: Themes können in Templates oder Stylesheets aufgegliedert werden. Dadurch kann man das generelle System umstellen, aber auch nur Varianten eines Systems wählen. Das Default-Theme ist tabellenbasiert, aber es gibt ein weiteres CSS basiertes zur Auswahl. Wie es mit der XHTML-Kompatibilität aussieht kann ich im Moment noch nicht so sagen. Gut auch die Unterstützung von MySQL und PostgreSQL - ich ziehe normalerweise letzteres vor. Weblogs kann man damit auch machen, genauso wie statische Artikel, ganze Bücher, Stories mit Diskussionsforen ähnlich wie Slashdot oder Kuro5hin und vieles mehr. Allerdings fällt auf Anhieb auf, das die Werkzeuge in den einzelnen Contentbereichen etwas mager sind - Werkzeuge die explizit auf Weblogs abzielen wirken oft vollständiger. Speziell Sachen wie Trackback, Pingback, Update-Pings oder ähnliches müssen nachinstalliert oder zumindestens nachkonfiguriert werden - der Standard pingt nur drupal.org selber für den verteilten Anmeldemechanismus. Auch so elementare Sachen wie einfache Kategorien (komplexere Kategorien - sogar hierarchisch - gibt es durchaus, aber an anderer Stelle) für Blogeinträge sucht man erstmal eine Weile. RSS Feeds werden zwar automatisch erstellt, die müssen aber auf manchen Seiten (zum Beispiel der Homepage) erst verlinkt werden (in User-Blogs ist aber der Link automatisch da). Ansonsten sind sie nur als alternate Link enthalten, aber nicht unbedingt für User sichtbar. Überhaupt zielt das ganze System eindeutig darauf ab, ganze Websites mit ganzen Gruppen von Benutzern zu gestalten und aufzubauen.Der verteilte Anmeldemechanismus ist aber oberkühl: die Benutzer von teilnehmenden Systemen können sich bei anderen teilnehmenden Systemen mit user@host anmelden und die Anmeldung wird automatisch an das Heimatsystem weitergegeben. Anmeldung mit immer dem gleichen Passwort, aber mit verteilter Authorisierung. Sehr nett! Überhaupt wird auf die Benutzerverwaltung viel Wert gelegt - die hat fast schon Zope-Ausmaße mit ihren Rechtegruppen und der Möglichkeit für einzelne Aktivitäten symbolische Rechtegruppen anzulegen. Weniger kühl sind die vielen fehlenden Metadaten. Eigentlich gibt es kaum Metadaten an Content. Autor, Datum, Status - aber das wars mehr oder weniger auch schon (natürlich neben Titel und Text, die sind selbstverständlich da). Auch die Content-Organisation bleibt dem Benutzer selber überlassen - da gibt es allerdings Hilfswerkzeuge, die zum Beispiel die Navigation leichter erstellbar machen. Allerdings lassen sich wohl viele Metadatenthemen (wie zum Beispiel die Kategorien) mittels Taxonomien lösen - das sind Gruppierungen von Content. Hier ist die Beschreibung etwas unintuitiv, das Thema ist recht komplex. Den Taxonomien sind Gruppierungen von Stichwörtern zu einem Thema. Ich ordne also nicht Beiträge zu Kategorien zu, sondern ich ordne Stichwörter zu Beiträgen zu und ordne die Stichwörter dann in Kategorien. Das liefert zwar Berge von Metadaten, ist aber weitaus komplexer als die normalen Blog-Kategorien die man so gewohnt ist.

Klasse wiederum sind aber die ganzen Content-Status und Content-Versioning Funktionalitäten. Alle Änderungen werden gelogged. Alle Änderungen an Content sind versioniert. Man kann auf älteren Content zurück und damit zum Beispiel Fehler beheben (oder Mist von amoklaufenden Benutzern beseitigen).

Das ganze System ist erweiterbar, aber ich vermute (geprüft habe ich es noch nicht, aber bei der Funktionsvielfalt liegt die Vermutung nahe) das die Erstellung von Plugins und Filtern doch aufwändiger ist als bei kleinen Lösungen wie WordPress. Das liegt aber in der Natur der Sache.

Ein weiterer potentieller Nachteil ist die Nicht-Verfügbarkeit einer fertigen deutschen Übersetzung. Auch finden sich zwar weitere Sites die mit drupal auf Deutsch arbeiten, aber scheinbar gibt keiner die kompletten Übersetzungstabellen frei zum Download - zumindestens habe ich da nichts gefunden, weder bei drupal.org selber noch bei google.

Wo würde ich drupal am ehesten einordnen? Ganz klar in die Kategorie CMS - also da wo Typo3, Mambo Open Source, Plone und ähnliche Systeme sich austoben. Diskussionsorientierte CMSe wie Scoop oder Squishdot schlägt es allerdings um Längen - genauso wie einfache Blog-CMSe. Für ein einfaches Blogsystem ist es eindeutig overkill. Für eine komplette Site wirkt es sehr brauchbar.

Hier gibts den Originalartikel.