Im offiziellen Joomla-Forum wurde er mit seinen - von mir sehr geschätzten und klugen - Anmerkungen oft genug nicht ernst genommen oder niedergeschrien, weil die Community dort Kritik (auch wenn sie fundiert und konstruktiv ist) nicht so gerne hört.

Jetzt bringt Joe alias eyezberg es einmal auf den Punkt und stellt die Joomla-Frage aus der Sicht eines Anwenders, der ein CMS benötigt und sich für Joomla interessiert. Das Resultat ist etwas ernüchternd, aber mehr als nachvollziehbar.

Joe ist seit bald drei Jahren aus der Community nicht mehr wegzudenken und einer der engagiertesten Mitstreiter noch aus den alten Mambo-Tagen. Ein unbequemer Kopf, der sich denselben schon oft zerbrochen hat, um qualitativ exzellente Verbesserungsvorschläge zu machen. Einer, der einfach nicht verstehen mag, warum das Core-Team total versagt, wenn es darum geht, sich simpelste Kommunikationsregeln zu eigen zu machen.

Ein Frust-Blogeintrag? Sicherlich. Aber ein fundierter und lesenswerter. Solidarische Grüße nach Paris, Joe.

Manche von Euch kennen vielleicht TravelPak, die von mir betriebene Reise-Website. Sie begann vor vier Jahren als kleine Reiseseite (damals noch mit dem Nuke-Derivat phpWebsite - kennt das noch jemand?), war dann im Jahr 2003 eine der ersten deutschen Websites, die unter Mambo 4.0.x liefen, und - ich muss es zu meiner Schande gestehen - bis vorgestern war immer noch das mittlerweile fossile Mambo 4.0.14 der Motor hinter der Seite.

In den letzten Tagen gab es eine massive Angriffswelle auf Mambo- und Joomla-Sites. Ziel waren dabei Lücken in Drittkomponenten, die schlampig programmiert waren. (Für das Kernsystem Joomla 1.0.10 gibt es im Moment hingegen keine bekannten Sicherheitslücken.)

Im Forum auf joomla.org hat man schnell reagiert und - zusätzlich zur bestehenden Rubrik für Sicherheitsfragen zu Joomla selbst - eine neue Rubrik für Sicherheitsprobleme bei Drittkomponenten eingerichtet.

Eigentlich betreibe ich hier keine reine News-Seite, aber diese Information halte ich für wichtig: Anwender der Komponenten SimpleBoard bis Version 1.1.0 und ExtCalendar sehen sich zur Zeit massiven Cracking-Attacken ausgesetzt, die hauptsächlich aus IP-Ranges der Türk Telecom kommen.

Beide Komponenten weisen eklatante Sicherheitslücken auf, die bereits in großem Stil automatisiert aufgespürt und für Defacements ausgenutzt werden.

Andrew Eddie hatte das Projekt Mambo nach dem Rücktritt des früheren Projektleiters Robert Castley übernommen und dann im letzten Jahr mit seinem Entwicklerteam durch den schweren Konflikt mit Miro gesteuert. Das Ergebnis war schließlich die Mambo-Weiterentwicklung Joomla, die derzeit in der Version 1.0.10 vorliegt. Parallel zum 1.0.x-Zweig wird seit längerem an der Version 1.5 gearbeitet. Am vergangenen Wochenende wurde diese für "feature complete" erklärt.

Just zu diesem Zeitpunkt wurde auf www.joomla.org ein Statement veröffentlicht, das Andrews Rücktritt von der Projektleitung bekanntgibt. Wer im zugehörigen Forum weiterliest, stellt fest, dass neben Andrew auch Mitch Pirtle und Arno Zijlstra sich zurückziehen. 

Wer Projekte wie ein Linkverzeichnis, eine Wissensdatenbank oder ähnliches mit Joomla aufbauen möchte, hat die Qual der Wahl. Da gibt es das sehr leistungsfähige und bewährte Mosets Tree, Phil Taylor's MosDirectory (beide kostenpflichtig), das für meine Begriffe sehr überladene Bookmarks und noch ein paar andere Komponenten.

Eine besondere Perle in dieser Kategorie ist die OpenSource-Komponente AlphaContent. Sie greift auf die Sections und Categories von Joomla zu und benutzt diese Struktur, um verzeichnisartige Übersichten anzuzeigen. Zusätzlich können Artikel über einen Buchstabenindex angesteuert werden.

Diese Komponente war genau das, was ich für eine in Entwicklung befindliche Microsite brauchte. Nur eines fehlte mir bislang: Eine echte Integration mit OpenSEF, die den Suchmaschinen zuliebe auch die komponenten-interne Navigation mit lesbaren URLs umsetzt.

Eine kurze, freundliche Anfrage beim Entwickler Bernard Gilly führte tatsächlich dazu, dass dieser sich an die Arbeit machte, eine sef_ext.php für seine Komponente zu schreiben, die für die Benutzung mit SEF Advance und OpenSEF durchgängig logische, lesbare URLs erzeugt. Bernard und ich testeten das einige Tage lang, und nun ist soeben AlphaContent in der Version 2.1.9 freigegeben worden. Ein neuer Reiter namens "SEF" in der Administration ermöglicht es, das Verhalten von AlphaContent in bezug auf Suchmaschinenfreundlichkeit schön abzustimmen.

AlphaContent ist für mich ein Musterbeispiel für eine qualitativ hochwertige und äußerst nützliche Komponente. Dass Bernard Gilly sein Produkt unter die GNU GPL gestellt hat, macht es darüber hinaus zu einer echten Community-Perle.

Anschauen lohnt sich! Und wenn AlphaContent gefällt, so freut sich Bernard sehr über eine kleine Spende, die man ihm über den Paypal-Button auf seiner Website zukommen lassen kann.

Wohl jeder, der eine einigermaßen gut besuchte Seite betreibt und ab und zu einen Blick in seine Logfile-Statistiken wirft, kennt das Phänomen: Irgendwann kommen die Spammer und hinterlassen in den Logfiles rätselhafte Referer von zwielichtigen Porno-, Casino- und Viagra-Seiten.

Diese Referer sind natürlich allesamt gefälscht. Sie dienen nur einem Zweck: Für die Suchmaschinen sollen möglichst viele Verweise auf die betreffenden Seiten gestreut werden, um deren Page Rank zu heben.

Ähnliches kennen wir bereits zur Genüge aus nicht abgesicherten Gästebüchern oder Foren. Die hektische Einführung des Tags rel="nofollow" hat die Spammer gerade mal gar nicht interessiert - warum auch, es kostet sie ja nichts, ihren Müll weiterhin flächendeckend abzusetzen.

Warum nun diese Verschmutzung von Logfiles? Sie sind doch in der Regel nicht öffentlich einsehbar, wie können sie da der Verbreitung solcher Links dienen?

Die Antwort ist: Keine noch so kleine Gelegenheit wird von den Spammern ausgelassen. Und: Viele Hobby-Webmaster schützen ihre Statistiken leider nicht vor öffentlichem Zugriff. Dadurch können sie von Suchmaschinen erfasst werden.

Zu diesem Übel trägt weiterhin bei, dass für viele Blog- und Portalsysteme Module existieren, die die letzten Referer auflisten. Warum jemand so etwas komplett Überflüssiges installiert, entzieht sich meinem Horizont. Aus Sicht des Spammers sind solche Tools jedoch ein echter Treffer ins Schwarze: Der gefakete Referer ist sofort und ohne weiteres Zutun auf einer öffentlichen Seite sichtbar, hurra!

Was ist also zu tun, um das Übel in den Griff zu bekommen?

• Keine Referer-Module installieren. Sie dienen nur der Selbstverliebtheit und tragen dazu bei, die Seuche Spam weiterzuverbreiten.
• Webstatistiken grundsätzlich vor öffentlichem Zugriff abschotten. Das funktioniert bei Apache-Servern wunderbar mit einer .htaccess-Datei.
• Fake-Referer von vornherein unterbinden. Mittlerweile finden sich einige fertige Blacklists, die man direkt verwenden kann. Beispielsweise können Referer, die den Begriff "poker" oder "prescription" enthalten, komplett geblockt werden. Auch dies geschieht zweckmäßigerweise über die .htaccess-Datei. Eine ausgezeichnete Quelle findet sich hier.

Mit diesen Maßnahmen hat man zumindest für die eigene Seite Ruhe vor dieser Art der Spamverbreitung.