cms

What’s New in WordPress 2.0? · Asymptomatic - even though I will soon be leaving WordPress, it's always interesting to see what's going on there. Besides, at least the Metaeule will certainly continue to run with WordPress.

A Few More Pictures ...

... there is in my CMS Testbed(yes, I'm knitting on my own content management software again). And when I look at how little trouble my own software gives me and how much trouble Wordpress always causes (for example, today I couldn't upload any pictures without being able to find any reason - nothing in the log files, no error message, just the refusal to upload), then the switch could be getting closer and closer ...

Virtual Hosts with WordPress

The Vhost Plugin is my current favorite of the entries for the WordPress Plugin Competition. With this plugin, you can bind categories to virtual hosts - when this host is accessed, the appropriate category is automatically displayed and optionally, a different template can be applied to this combination.

I can think of a whole range of ideas spontaneously - for example, I could put my Bananenrepublik under it and present my rants as more independent content. Or I could finally run my photographic entries under one of my photo domains again. I think I'll play around with the plugin soon.

Another funny feature - but rather uninteresting for me - is the possibility to restrict a user to a VHost (and thus to a category) and set up a multi-blog platform on a WordPress installation. Could be quite funny for family blogs, for example.

Unfortunately, the installation is a bit tricky - you have to patch a few functions because there are bugs in the standard installation. With WP 1.5.1, this should hopefully be better.

PIXELPOST - Small Photoblog Software - looks quite nice, as do the demos. Fun is the small strip calendar in the demo - I think I'll do something like that for WordPress, it takes up significantly less space in the sidebar than the classic calendar. For someone who just wants to photoblog, PixelPost looks quite nice.

Neues Spiel, neues Glück: b2evolution

Heute hab ich mir mal b2evolution angeguckt (wie üblich nur ein kurzer oberflächlicher Testflug). Das ist ja mit WordPress verwandt und alleine deshalb schon interessant - mal gucken was andere aus dem gleichen Basiscode gemacht haben. Also das Zeug geholt, das Kubrick Skin geholt (hey, ich mag Kubrick mitlerweile ) und losgelegt.

Was mir sofort auffällt: b2evolution legt wesentlich mehr Wert auf multi-allesmögliche. Multi-Blog (es werden gleich 4 Blogs vorinstalliert mitgeliefert, wovon eines ein "alle Blogs" Blog ist und eines ein Linkblog), Multi-User (mit Berechtigungen für Blogs etc. - also als Bloggerplattform für kleinere Usergruppen geeignet) und Multi-Language (nett: man kann an jedem Posting die Sprache festlegen, Sprachen pro Blog festlegen). Das gefällt schon mal. Das Backend ist leidlich gut zu bedienen und man findet das meiste recht fix wieder.

Aber dann die Dokumentation. Ok, ja, das wichtigste ist dokumentiert und auffindbar. Aber sobald man in die Tiefe geht, ist nahezu nichts selbsterklärend oder dokumentiert. Ok, ich gebs zu, ich hätte mir nicht gleich auf die Fahnen schreiben sollen die URIs auf die komplizierteste Form zu bringen - nämlich über sogenannte Stub-Dateien. Das sind alternative PHP-Files über die alles gezogen wird um darüber spezielle Einstellungen vorzubelegen. Angeblich soll man damit auch eine URI-Struktur wie bei Wordpress hinkriegen - der b2evolution-Standard ist nämlich so, das in der URI immer das index.php vorkommt und die zusätzlichen Elemente hinten drangehängt sind. Das ist hässlich. Das will ich nicht. Das zu ändern geht scheinbar nur mit Apache-Mitteln in Handarbeit (nein, nicht wie bei WordPress die nette und freundliche Unterstützung der automatisch generierten .htaccess Datei) und dann entsprechenden Einstellungen in b2evolution. Ok, kann man machen - ich kenne Apache gut genug. Aber wieso so umständlich, wenns auch einfacher geht?

Nunja, aber der echte Pferdefuss für mich kommt noch: b2evolution kann nur Blogs. Jedenfalls in der Standardausstattung. Genau - nur Listen von Postings die zeitlich geordnet sind. Langweilig. Nicht mal einfache statische Pages - sorry, aber wo pack ich das Impressum hin? Von Hand erstellte Files, die man daneben packt? Möglich, klar. Aber nicht gerade anwenderfreundlich.

Antispam-Mittel gibts auch einige, zum Beispiel eine zentral gepflegte Sperrwortliste (naja, Sperrwortlisten halte ich persönlich nicht für so geeignet) und Benutzerregistrierung. Nicht viel, aber erstmal ausreichend. Mehr kann man sicherlich über Plugins machen. Beim Stichwort Plugins ist eine sehr nette Eigenschaft zu nennen: man kann am Posting unterschiedliche Filter aktiviert haben. Je nach Posting immer wieder neu. Sehr nett - WordPress hat da ein echtes Defizit, die aktivierten Filter gelten für alles über alles - eine Änderung und alte Postings werden plötzlich falsch formatiert (wenn es ein Output-Filter ist).

Ebenfalls nett: die hierarchischen Kategorien verhalten sich wirklich hierarchisch - bei WordPress sind die ja nur hierarchisch gruppiert, aber z.B. wird mit der Hierarchie nicht viel gemacht. Bei b2evolution wandern Postings einer Kategorie automatisch an die übergeordnete, wenn eine Kategorie gelöscht wird. Ausserdem kann man durch die Multiblog-Eigenschaft an einem Posting Kategorien verschiedener Blogs aktivieren und damit sozusagen crossposten - wenn es denn in den Settings erlaubt ist.

Layoutanpassungen gehen über Templates und Skins. Templates sind vergleichbar zum WordPress 1.2 Modus und Skins eher zum WordPress 1.5 Modus. Also bei Templates wird alles durch ein PHP-File gezogen und bei Skins werden mehrere Vorlagen zusammengefasst und dann daraus das Blog gebaut. Spezialanpassungen kann man dann über eigene Stubdateien machen (die gleichen die auch für die hübscheren URIs genommen werden sollen) und darüber z.B. feste Layouts aufbauen mit denen man dann zum Beispiel statische Seiten simulieren könnte.

Alles in allem das Ergebnis des Kurzfluges: nettes System (trotz der etwas barocken Ecken in der URI-Erstellung und der recht spartanischen Dokumentation) für Hacker und Leute die sich in den Code reinwühlen mögen. So zum direkt losstarten finde ich es weniger geeignet - da ist WordPress wesentlich einfacher zu verstehen und zu starten. Und um mit Drupal zu konkurrieren ist b2evolution in den Features zu mager - einfach zu stark auf Blogs ausgerichtet. Man kann es zwar in die passende Richtung verbiegen - aber warum sollte man das machen wollen, wenn man auch was fertiges nehmen kann, das all das schon kann?

Hmm. Klingt relativ ähnlich zu dem was ich vor fast einem Jahr über b2evolution geschrieben habe. Viel Entwicklung hat es dort irgendwie nicht gegeben in der Zwischenzeit.

phpOpenTracker ist ein Live-Access-Auswerter für Webseiten. Er kann direkt in PHP-Anwendungen integriert werden oder über Webbugs (kleine unsichtbare Grafiken) aus statischen Webseiten gesammelt werden. Man kann damit ziemlich viel über das Benutzerverhalten in den Webseiten erkennen. Und bei Asymptomatic wird gerade an einem WP-Plugin dafür gestrickt, mit dem man die entsprechenden Auswertungen im WP-Backend zu sehen bekommt ...

Etomite Content Management System

Das Etomite Content Management System(gefunden via Netbib) ist eine recht interessante Angelegenheit. Was mir an dem CMS nicht so gut gefällt: das Standardtheme. Sorry, aber das ist bunt und sieht für mich aus wie Windows . Ausserdem benutzt es ein Tabellenlayout, was mir auch nicht so gut gefällt. Aber ansonsten muss ich schon sagen, das Teil hat was. Das Backend vor allem ist sehr interessant - es benutzt massiv JavaScript und DHTML, was natürlich erstmal nicht so gut ist wenn man JavaScript nicht mag. Aber es bietet darüber eine ganze Menge interaktiver Features die sehr nett sind - zum Beispiel Feedback über die laufende Aktion, automatische Aktualisierung der diversen Oberflächenelemente und insgesamt eine recht runde Bedienung.

Auch gut gefällt die Idee der Snippets - sowas wie in PyDS die Nuggets. Kleine Schnipsel von Code die man einfach in der Datenbank speichert und die dann über Tags in den Templates abgerufen werden. Sehr praktisch, da man so oft einfache kleinere Erweiterungen bauen kann, ohne extra ein grosses Rad zu drehen.

Ebenfalls recht interessant ist das automatische Caching - nichts wirklich neues, aber in diesem Fall eine nette Idee: man kann an den Elementen selber festlegen ob sie gecached werden sollen oder nicht. Und zwar für jedes Element einzeln. Deutlich besser als die üblichen Sekt-oder-Selters-Ansätze anderer CMS.

Insgesamt ist Etomite wesentlich stärker Full-CMS-orientiert als Blog-orientiert. Das stellt es funktional eher in eine Gruppe mit Drupal als z.B. WordPress. Es gibt auch schon eine Reihe von Snippets zur einfachen Erweiterung, genauso wie Themes. Auch verschiedene Sprachfiles existieren schon. Die Dokumentation existiert auch schon, ist sogar nach erstem überfliegen schon recht brauchbar für den Start.

Die Lizenz ist GPL, was schon mal gut ist. Allerdings kommt beim ersten Login ein spezieller Hinweis, der nicht entfernt werden darf - eigentlich beisst sich sowas mit der GPL, denn die GPL sagt ja gerade das ich mit dem Paket alles mögliche machen darf, sofern ich den geänderten Source zur Verfügung stelle. Ok, ich darf nicht behaupten das es von mir ist und muss ursprüngliche interne Copyright-Hinweise erhalten, aber ansonsten kann ich alles ändern. Und das umfasst normalerweise auch Hinweistexte. Zwangslinks und Zwangshinweise beissen sich nunmal mit der GPL. Entweder muss man dann die GPL explizit um diesen Hinweis erweitern - womit es eine GPL+Zusatz wird, die dann allerdings zur normalen GPL inkompatibel wird - oder man verkneift sich Zwangshinweise. Das ganze ist ein nicht unbekanntes Problem der Leute mit der GPL, aber stören kann sowas bei kommerziellem Einsatz definitiv.

Hat jemand Kubrick auf Etomite portiert? Ich bräuchte für meine Spielereien noch ein etwas hübscheres Theme als das mitgelieferte

Weiteres zu Drupal

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

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.

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

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.

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_obtain theme info, 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 phptemplate extra templates 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_theme data (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 system obtain theme info - 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 ...

Manche Projekte wollen mich in den Wahnsinn treiben

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

Weg mit Trackback

Isotopp grübelt anlässlich des Spamtags über Trackback Spam und stellt mehrere Ansätze vor. Einer davon arbeitet mit einer Gegenprüfung der Trackback-URL gegen die IP des einsendenden Rechners - wenn der Rechner eine andere IP hat als der im Trackback beworbene Server, dann wäre das warscheinlich Spam. Ich hab mal meine eigenen Kommentare dazu zusammengeschrieben - und begründet, warum ich Trackback lieber heute als morgen los wäre. Komplett. Und ja, das ist eine komlette 180-Grad Wendung meinerseits zum Thema Trackback.

Der IP-Test-Ansatz kommt mal wieder aus der Sicht der reinen servererstellten Blogs. Es gibt aber dummerweise einen grossen Haufen Trackback-fähiger Softwareinstallationen die nicht auf dem Server laufen müssen (oft auch nicht laufen) auf dem die Blogseiten liegen - alle Tools die statischen Output produzieren zum Beispiel. Grosse Installationen sind Radio Userland Blogs. Kleinere PyDS Blogs. Oder auch Blosxom-Varianten im offline-Modus (sofern es da mitlerweile trackbackfähige Versionen gibt - aber das es typische Hackertools sind, gibts das mit Sicherheit).

Dann gibts noch die diversen Tools die nicht Trackback-fähig sind, wo die User dann einen externen Trackback-Agent benutzen um die Trackbacks abzusetzen.

Und last but not least kommen auch noch die diversen Blogger/MetaWeblogAPI-Clients hinzu, die selber den Trackback absetzen weil z.B. nur MoveableType im MetaWeblogAPI das Triggern von Trackbacks erlaubt, aber andere APIs nicht.

Von daher ist der Ansatz mit der IP entweder nur als ein Filter zu sehen der einen Teil der Trackbacks durchwinkt, oder aber eine Verhinderung von Trackbacks von den oben genannten Usern. Und letzteres wäre ausgesprochen unschön.

Eigentlich ist das Problem ganz einfach: Trackback ist ein krankes Protokoll das mit der heissen Nadel gestrickt wurde, ohne das sich der Entwickler auch nur einen Hauch von Gedanken zu dem ganzen Thema gemacht hat. Und gehört daher IMO auf den Müllhaufen der API-Geschichte. Das ich es hier unterstütze liegt einfach nur daran, das WordPress es standardmäßig implementiert hat. Sobald der manuelle Moderationsaufwand zu hoch wird, fliegt Trackback hier ganz raus.

Sorry, aber in dem Punkt Trackback haben die MoveableType-Macher wirklich Nähe zu Microsoft-Verhalten gezeigt: einen völlig unzureichenden Pseudo-Standard durch Marktdominanz durchgedrückt - ohne sich überhaupt mal über die Sicherheitsimplikationen Gedanken zu machen. Warum wohl bei RFCs immer ein entsprechender Absatz über Sicherheitsprobleme zwingend ist? Leider haben die ganzen Blogentwickler alle fleissig mitgezogen (ja, ich auch - bei Python Desktop Server) und wir haben dieses alberne Protokoll am Hals. Und seine - völlig erwartbaren - Probleme.

Besser jetzt eine bessere Alternative entwickeln und forcieren - z.B. PingBack. Bei PingBack ist definiert, das die Seite die einen PingBack auf eine andere Seite ausführen will auch wirklich diesen Link dort exakt so enthalten muss - im API werden immer zwei URLs übertragen, die eigene und die fremde URL. Die eigene URL muss im Source auf die fremde URL zeigen, nur dann wird der fremde Server den PingBack annehmen.

Für Spammer ist das ziemlich absurd zu handhaben - sie müssten vor jedem Spam die Seite umschiessen oder über entsprechende Servermechanismen dafür sorgen, das die gespammten Weblogs dann beim Test entsprechend eine Seite vorgegaukelt bekommen, in der dieser Link drin ist. Natürlich ist das durchaus machbar - aber der Aufwand ist deutlich höher und durch die nötige Servertechnik ist das nicht mehr mit fremden offenen Proxies und/oder Dialup-Zugang machbar.

Von daher wäre der richtige Weg einfach der Wechsel des Linkprotokolls. Weg mit Trackback. Das Trackback-Loch kann man nicht stopfen. PS: wer sich mal meinen Trackback in Isotopps Posting anguckt sieht gleich das zweite Problem von Trackback: abgesehen vom riesigen Sicherheitsproblem ist nämlich die Zeichensatzunterstützung von Trackbacks schlichtweg ein totales Debakel. Auch hier hat der ursprüngliche Autor des Pseudo-Standards keine Minute über mögliche Probleme nachgedacht. Und dann wundern sich noch manche Leute wenn TypeKey von den Moveable-Type-Leuten nicht so richtig akzeptiert wird - sorry, aber Leute die so bescheidene Standards machen werde ich auch noch gerade die Loginverwaltung übertragen ...

WordPress Related Entries plugin

わさび » Archives » WordPress Related Entries plugin - ein sehr nettes kleines Plugin das mittels des Volltextindex von MySQL verwandte Artikel sucht. Klar, das ist nur ein ziemlich einfacher Algorithmus und die Trefferqualität ist noch lange nicht so wie bei Google, aber ich habs trotzdem mal eingebaut. Wenn man auf die Detailseite eines Beitrags geht (z.B. durch Klick auf den Titel) wird eine Liste von bis zu 5 passenden anderen Artikeln angezeigt.

Ausserdem verspreche ich mir davon auch eine etwas bessere Positionierung von diversen älteren Beiträgen - ohne das ich immer dran denken muss da einen Link hin zu setzen (hey, meistens hab ich selber die schon wieder vergessen!). Und vielleicht hilft es auch den Leuten die über Suchmaschinen kommen etwas weiter.

Ausserdem ist es cool, und cool ist gut

Caching für PHP Systeme

Es gibt ja grundsätzlich zwei Wege wie man in einem PHP-basierten System caching betreiben kann. Ok, es gibt viel mehr, aber zwei Hauptwege sind deutlich erkennbar. Ich hab mal zusammengeschrieben was in dem Zusammenhang interessant ist - gerade weil im Moment ein paar Kollegen unter hoher Serverlast zu leiden haben. Das ganze ist allgemein gehalten, betrachtet aber aus begreiflichen Gründen auch die speziellen Folgen für WordPress.

• Caching von vorkompilierten PHP Seiten
• Caching von Seitenoutput

Zu beiden Hauptwegen gibt es eine ganze Reihe von Varianten. Die PHP Seiten selber liegen bei Webservern ja als Source vor - unverarbeitet und nicht irgendwie optimiert für den Ladeprozess. Hat man komplexe PHP Systeme laufen, fällt also bei jedem PHP-File das parsen und kompilieren in den internen Code an. Das kann bei Systemen mit vielen Includs und vielen Klassenbibliotheken durchaus beachtlich sein. An diesem Punkt setzt die erste Hauptrichtung des Cachings an: der erzeugte Zwischencode wird einfach weggespeichert. Entweder in shared Memory (Speicherblöcke die vielen Prozessen eines Systems gemeinsam zur Verfügung stehen) oder auf die Festplatte. Hier gibt es eine Reihe von Lösungen - ich selber setze turck-mmcache ein. Der Grund ist hauptsächlich das es nicht im shared Memory cached, sondern auf der Platte (was aber meines Wissens die anderen ähnlichen Lösungen auch tun) und das es für turck-mmcache ein Debian-Paket gibt. Und das ich bisher relativ wenig negative Erfahrungen damit gemacht habe (jedenfalls bei Debian stable - bei Debian testing sieht das anders aus, da fliegt einem die PHP Anwendung um die Ohren). Da WordPress auf einer grösseren Menge von Bibliotheksmodulen mit recht grossem Sourceinhalt basiert, bringt ein solcher Cache eine ganze Menge um die Grundlast von WordPress zu mindern. Da diese Caches in der Regel vollkommen transparent - ohne sichtbare Auswirkungen ausser der Beschleunigung - sind, kann man einen solchen Cache auch generell aktivieren.

Die Zweite Hauptrichtung für das Caching ist das Zwischenspeichern von Seiteninhalten. Hier kommt als Spezialität hinzu, das Seiten ja oft dynamisch abhängig von Parametern erstellt werden - und daher eine Seite nicht immer den gleichen Output erzeugt. Man denke nur an so banale Sachen wie die Anzeige des Benutzernamens wenn ein Benutzer angemeldet ist (und einen Cookie dafür gespeichert ist). Auch aufgrund von HTTP Basic Authentication (die Anmeldetechnik bei der das Popup-Fensterchen für Benutzer und Passwort kommt) können Seiteninhalte unterschiedlich sein. Und POST-Requests (Formulare die ihre Inhalte nicht über die URL mitschicken) produzieren auch wieder Output der von diesen Daten abhängig ist.

Grundsätzlich muss also ein Output-Cache diese ganzen Eingangsparameter berücksichtigen. Eine gute Strategie ist oft die POST-Ergebnisse garnicht zu cachen - denn dort würden auch Fehlermeldungen etc. auftauchen, die abhängig von externen Quellen (Datenbanken) sind und daher sogar bei identischen Eingabewerten unterschiedliche Ausgaben produzieren könnten. Man kann also eigentlich nur GET-Anfragen (URLS mit Parametern direkt in der URL) sinnvoll cachen. Hierbei muss man aber sowohl die gesendeten Cookies als auch die gesendeten Parameter in der URL berücksichtigen. Sofern das eigene System mit basic-Authentication arbeitet, muss auch das mit einfliessen in den Cache-Begriff.

Ein zweites Problem ist, das Seiten selten rein statisch sind - auch statische Seiten enthalten durchaus Elemente die man eigentlich lieber dynamisch haben möchte. Hier muss man also eine wesentliche Entscheidung treffen: reicht rein statischer Output, oder muss ein Mix kommen? Desweiteren muss man noch die Entscheidung treffen, wie sich Seitenaktualisierungen auswirken sollen - wie merkt der Cache, das etwas geändert wurde?

Ein Ansatz den man verfolgen kann ist ein sogenannter reverse-Proxy. Man packt einfach einen normalen Web-Proxy so vor den Webserver, das jeglicher Zugriff auf den Webserver selber technisch durch diesen Webproxy gezogen wird. Der Proxy steht direkt vor dem Webserver und ist somit für alle Benutzer verbindlich. Da Webproxies das Problem der Benutzerauthentifizierung, der Parameter und der POST/GET-Unterscheidung schon gut beherrschen sollten (in der normalen Anwendungssituation für Proxies sind die Probleme ja die gleichen), ist das eine sehr pragmatische Lösung. Auch die Aktualisierung wird von solchen Proxies meist recht gut gelöst - und im Notfall kann der Benutzer durch einen erzwungenen Reload den Proxy ja überreden die Inhalte neu zu ziehen. Leider geht diese Lösung nur dann, wenn man den Server selber unter Kontrolle hat - und der Proxy zieht noch weitere Resourcen, weshalb unter Umständen dafür kein Platz auf dem Server ist. Auch ist es stark von der Anwendung abhängig wie gut sie mit Proxies klar kommt - wobei Probleme zwischen Proxy und Anwendung auch bei normalen Benutzern aufstossen würden und deshalb sowieso gelöst werden müssen.

Der zweite Ansatz ist die Software selber - letzten Endes kann die Software ja genau wissen wann Inhalte neu erstellt werden und was für das Caching berücksichtig werden muss. Hier gibt es wieder zwei Richtungen der Implementierung. MoveableType, PyDS, Radio Userland, Frontier - diese erzeugen alle statische HTML Seiten und haben deshalb das Problem mit der Serverlast bei Seitenzugriffen nicht. Der Nachteil liegt auf der Hand: Datenänderungen erzwingen ein Neuerstellen der Seiten, was bei grossen Sites nervig werden kann (und dazu geführt hat das ich von PyDS auf WordPress gewechselt habe).

Die zweite Richtung ist das Caching aus der dynamischen Anwendung selber: beim ersten Zugriff wird der Output unter einem Cache-Key gespeichert. Beim nächsten Zugriff auf den Cache-Key wird einfach geguckt ob der Output schon vorliegt, wenn ja wird er ausgeliefert. Der Cache-Key setzt sich aus den GET-Parametern und den Cookies zusammen. Wenn Datenbankinhalte geändert werden, werden die entsprechenden Einträge im Cache gelöscht und damit die Seiten beim nächsten Zugriff neu erstellt.

WordPress selber hat mit Staticize ein sehr praktisches Plugin für diesen Einsatzzweck. In der aktuellen Beta ist es schon im Standardumfang mit drin. Dieses Plugin erzeugt wie oben beschrieben für Seiten einen Cache-Eintrag. Und berücksichtigt dabei die Parameter und Cookies - basic Authentication wird bei WordPress ja nicht benutzt. Der Clou ist aber, das Staticize die Seiten als PHP speichert. Die Cache-Seiten sind also selber wieder dynamisch. Diese Dynamik kann jetzt dazu benutzt werden um Teile der Seite mit speziellen Kommentaren zu markieren - wodurch für diese Teile der Seite dann wieder dynamische Funktionsaufrufe eingesetzt werden. Der Vorteil liegt auf der Hand: wärend die grossen Aufwände für die Seitenerstellung wie das Zuladen der diversen Bibliotheksmodule und das Lesen der Datenbank komplett erledigt sind können einzelne Teilbereiche der Site weiterhin dynamisch bleiben. Natürlich müssen die Funktionen dafür dann so aufgebaut sein das sie nicht das ganze Bibliothekswerk von WordPress brauchen - aber zum Beispiel dynamische Counter oder Anzeigen der gerade aktiven Benutzer oder ähnliche Spielereien lassen sich auch in den Cacheseiten somit weiter dynamisch halten. Matt Mullenweg benutzt es zum Beispiel um auch auf Seiten aus dem Cache ein Zufallsbild aus seiner Bibliothek anzuzeigen. Staticize löscht bei Erstellung oder Änderung eines Beitrags einfach den ganzen Cache - sehr primitiv und bei vielen Files im Cache kann das dann schon mal etwas länger dauern, aber dafür sehr wirksam und pragmatisch.

Welche Caches setzt man sinvollerweise jetzt wie ein? Ich würde bei komplexeren Systemen immer gucken ob ich nicht einen PHP Codecache einsetzen kann - also turck mMCache oder Zend Optimizer oder phpAccelerator oder was es sonst noch so gibt.

Den Anwendungscache selber würde ich persönlich nur dann aktivieren wenn er auch wirklich nötig wird durch die Last - bei WordPress kann man ja ein Plugin vorhalten und nur bei Bedarf aktivieren. Denn Caches mit statischer Seitenerstellung haben nunmal so ihre Probleme - Layoutänderungen sind erst nach Löschung des Cache aktiv etc.

Wenn man einen Reverse-Proxy einsetzen kann und die Resourcen auf der Maschine dafür auch ausreichen ist er sicherlich immer zu empfehlen. Alleine schon weil man so selber die Probleme mitbekommt, die in der eigenen Anwendung eventuell bezüglich Proxies drin sind - und die jedem Benutzer hinter einem Webproxy auch Ärger machen würden. Gerade wenn man zum Beispiel Zope benutzt gibt es sehr gute Möglichkeiten in Zope die Kommunikation mit dem Reverse Proxy zu verbessern - dazu ist ein Cache Manager in Zope verfügbar. Auch andere Systeme bieten dafür gute Grundlagen - aber im Endeffekt sollte jedes System das saubere ETag und Last-modified Header produziert und korrekt conditional GET (bedingte Zugriffe die mitschicken welche Version lokal schon vorliegt und dann nur aktualisierte Inhalte sehen wollen) behandeln geeignet sein.

hobix&you!! feel yeah!!

hobix&you!! feel yeah!! ist eine Weblogsoftware in Ruby geschrieben. Sie stammt vom Autor des Why's (Poignant) Guide to Ruby und die Homepage des Projektes ist dementsprechend durchgeknallt. Eines muss man ihm lassen: entweder er ist völlig neben der Spur oder er ist ein Genie. Irgendwas dazwischen passt definitiv nicht (gefunden bei but she's a girl)

Ian Bickings Wiki - Interessantes Wiki in Python und Webware auf Basis von reStructuredText

Rhizome - Interessantes Wiki mit Fokus auf semantische Inhalte - Seitenbezüge werden semantisch definiert

New image gallery plugin - needs testers - Wordpress Plugin für Bilder an Postings

WordPress Support %u203A Static "like" pages - Diskussion über die Erstellung pseudostatischer Seiten (z.B. Impressum) in WordPress

drupal.org

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.

Releases | drupal.org - Download page for Drupal modules

Daring Fireball: Markdown Syntax Documentation - Interessante Textumsetzung nach XHTML für PHP und Perl - ähnlich zu reStructured Text

b2evolution: Home

b2evolution macht auch vom Papier her eine gute Form. Erstaunlich wie weit die ganzen Blogprogramme gekommen sind, wärend man mal nicht hinguckt

Auf jeden Fall macht b2evolution eine sehr gute Figur, was Antispam und Security angeht. Und es scheint auch eine gute XHTML-Unterstützung und Plugin-Architektur zu haben. Die Plugins sind nach Anwendungszweck (Edit-Plugins und Toolbar-Plugins) geteilt. Ich glaube die etwas einfachere Form der Plugins in WordPress wird für viele leichter zu verstehen sein, aber Programmierer sind warscheinlich von b2evolution eher angetan.

Mir persönlich ist die Admin-Umgebung ein bischen zu verspielt - ich habs mir allerdings nur in der Online-Demo angeguckt. Auch das Standardtemplate wirkt nicht so sauber und aufgeräumt wie das von WordPress - ich glaube mit letzterem hat man einen einfacheren Start sein eigenes Layout überzustülpen. Schick ist auf jeden Fall die Wahl des Input-Parsers bei Postings - sowas habe ich im Python Desktop Server ja auch gemacht, eben weil man manche Plugins nicht immer aktiv haben will. Ansonsten ist es natürlich WordPress sehr ähnlich - es ist ja auch ein b2-Nachkomme. WordPress hat aber wohl die bessere Unterstützung für Bilder, da es automatisch Thumbnails erstellen kann. Ausserdem fehlt b2evolution das metaWeblogAPI. Wiederum schön ist die Integration von Referrern und Suchmaschinen in das Blog direkt - ähnlich der Auswertung die der Python Community Server bei mir macht. D Useability-Design von b2evolution wirkt stellenweise etwas wirr: Permanlinks an Beiträgen sind kleine Kettensymbole, Permalinks an Kommentaren sind kleine Dokumentensymbole. Auch an anderen Stellen ist es etwas inkonsistent.

Fazit? Sofern ich überhaupt nach dem Mini-Test einen ziehen kann würde ich sagen das b2evolution für mich bei den meisten Features genau das eine kleine Häkchen, Schalterchen oder Optiönchen zu viel implementiert. Daher würde ich persönlich eher zu WordPress tendieren - ich kann mir vorstellen das der Code etwas einfacher strukturiert ist und daher eigene Hacks leichter integriert werden können.

Von der Funktion her allerdings gewinnt b2evolution klar nach Punkten. Wer also eher auf viele Features steht und lieber aus dem vollen schöpft, oder wer über normale Blogs hinaus stärker in den Bereich CMS vorstossen will, wird sicherlich von b2evolution begeistert sein.

Was ich allerdings weder bei b2evolution noch WordPress verstehe: keines der beiden Projekte implementiert Stories. Also Artikelformen die nicht auf den Kalender fixiert sind. Klar, man kann das mit einer Kategorie oder mit einem eigenen Blog realisieren (bei b2evolution durch die Multiblog-Funktionalität sicherlich sehr viel leichter als der für WordPress nötige Kategorienhack), aber ich finde es unpraktisch das man nur für ein Impressum schon solche Handstände machen muss ...

Hier gibts den Originalartikel.

WordPress Wiki - Comment Moderation Plugin - Kommentarbestätigung per eMail - könnte für TIMMY interessant sein

WordPress Wiki - WP Plugins - WordPress Plugins für das neue 1.2 Plugin Interface

Mambo at the Yard - Mamblog Homepage - Weblogs für Mambo Open Source

MamboOS Documentation : Home Page - Dokumentationsserver zu Mambo Open Source

Mamboportal.com - Mambo Open Source CMS Portal - Mambo Open Source Module und Languages

MOS - Homepage von Mambo - Open Source CMS

yops.de ::: what are you waiting for? - Weitere Downloads zu Mambo Open Source (z.B. Filemanager)