Joomla – pfeff.eroni.de

Pfeff mit neuem Pepp? Neustart im neuen Gewand!

Posted on 31. August 2016Leave a comment

Rückblickend hab ich in den letzten Jahren ja immer weniger gebloggt, letztes Jahr waren es sogar nur 2 oder 3 Blogpost …

Ich will das Bloggen aber nicht aufgeben und wieder beleben.

Erster Schritt: Redesign

Das alte Layout meines Blogs fand ich persönlich immer recht schlank und funktional, aber irgendwann hab ich mich daran satt gesehen gehabt und es kam mir altbacken (und zu rosa, obwohl die Grundfarbe eigentlich Dunkelrot ist) vor. Ein paar Mal hatte ich schon den Bleistift in der Hand und hab ein neues Design skizziert, aber so wirklich kam ich nicht auf einen grünen Zweig.

Gleichzeitig schrie mein Joomla schon seit geraumer Zeit nach einem Upgrade. Bei jedem Login lächelte mich der nette Hinweis an, dass der Support für meine Version schon 2014 abgelaufen sei. Angesichts dessen, dass mein Blog schon mehrfach Hacks ausgesetzt war, bei dem Sicherheitslücken ausgenutzt wurden, war also auch hier Handlungsbedarf angezeigt. Ein Schaden ist dabei in der Regel nicht passiert, da es „nur“ Defacements waren, aber der Ärger und die Arbeit waren dennoch da.
Von einem Upgrade war ich allerdings von vorn herein abgeschreckt, da damit bisher immer eine umfangreiche Anpassung des Templates sowie die Suche nach aktualisierten oder neuen Plugins einherging. Der Aufwand mit Joomla einen Blog nachzubauen (ohne Komponenten wie K2) ist doch recht umfangreich und bisweilen nervenaufreibend. Darauf hatte ich keine Lust.

Also das ganze Thema vorerst auf Halde gelegt.

Zweiter Schritt: Kein Redesign, Plattformwechsel

Vor Kurzem (im Februar) stand die Gestaltung meiner neuen Webseite für mein Fotografie-Projekt an. In Gedanken hab ich mich auch bei diesem Projekt schon gegen das Designen und Programmieren eines Templates gesträubt, insbesondere, da mittlerweile HTML5 der Stand der Technik ist und ich wahrlich nicht am Ball geblieben bin. Ich hab kurzerhand beschlossen, mich nach einem fertigen Template umzuschauen und nachdem ich mittlerweile mit diversen Content Management Systemen gearbeitet habe, war mir auch recht schnell klar, dass ich WordPress für dieses Fotografie-Projekt nutzen will. Das lag unter anderem daran, dass die geplante Webseite sehr einfach strukturiert und ohne viel Firlefanz sein sollte.

Gesagt, getan. Ich habe recht schnell ein Theme gefunden, in dem mir mein Foto-Projekt auf Anhieb gefallen hat. Es sollte ein One-Page-Layout sein, dass auf allen Geräten (PC, Tablet, Mac) gut aussieht – ein sogenanntes responsives Design. Mit Hilfe eines Video-Tutorials hab ich auch recht schnell die Systematik dieses Themes verstanden und innerhalb kürzester Zeit stand die Webseite.
Allein die Grundinstallation des Themes hat mich schon begeistert, da sie mit einem Klick aus dem Administrationsbereich von WordPress heraus machbar ist, genauso wie die Installation von Plugins. Es war deutlich einfacher als in Joomla 2.5 (zu 3.x kann ich nichts sagen).
Die Webseite hat übrigens auch einen Blogbereich zum Thema Fotografie erhalten und hier fiel mir direkt auf, dass WordPress quasi ab Werk alle möglichen Blog-Tools als Widgets bereit hält, die ich bei Joomla mühsam zusammensuchen und anpassen musste. Logisch: WordPress ist ein Blog-System, während Joomla mehr ist und deutlich mehr Möglichkeiten gerade für größere, komplexere Seiten bietet. Meine eigenen Webseiten benötigen diese Komplexität aber gar nicht. Bei der Webseite eines Vereins, die ich ehrenamtlich betreut habe, sieht das schon wieder anders aus – aber anderes Thema. Mit anderen Worten:

Joomla war mit Kanonen auf Spatzen geschossen.

WordPress passt viel besser zu meinem Blog.

Aber ein komplett neuer Blog? Die alten Blogpost würde ich gern behalten, nicht aber den alten Blog parallel laufen lassen – das wäre auf Dauer bzw. ist bereits jetzt ein Sicherheitsrisiko. Tante Google wusste natürlich ein Lösung und tatsächlich: Es gibt ein Plugin, dass Artikel, Kategorien, Medien, … aus der Joomla-Installation nach WordPress migriert und sogar interne Links korrigiert: FG Joomla to WordPress. Theoretisch kann das Plugin bzw. ein damit verwandtes Plugin sogar die Kommentare des von mir genutzten Kommentar-Moduls (JComments) aus Joomla migrieren. Diese Funktion kostet aber nicht wenig Geld (zumindest für den Maßstab „privater Blog“), so dass ich mich gegen die automatisierte Migration der Kommentare entschieden habe. Dazu weiter unten mehr.

Sämtliche Artikel waren also recht schnell migriert und der Blog wäre grundsätzlich startbereit gewesen.

Dritter Schritt: Neues Design

Redesign möchte ich diesen Schritt eigentlich gar nicht mehr nennen, da das neue Design schon etwas grundlegend Neues ist. Die Funktionalitäten dieses neuen Blogs sind die Gleichen, die Aufteilung der Seite weicht aber in meinen Augen deutlich vom klassischen Blog-Design, wie ich es bisher hatte, ab. Das ist auch Absicht.

Ich wollte keinen Standard-Aufbau, wie ich ihn bisher hatte. Ich wollte ein klares, übersichtliches Design, dass sich zunächst auf das Wesentliche konzentriert: Den Inhalt. Das von mir gewählte Theme Seasonal hat mich sofort angesprochen. Auf der einen Seite ein Foto mit Menü als festes Element, daneben die Kurztexte der einzelnen Blogposts. Das Wesentliche ist auf einen Blick zu sehen. Die vielen kleinen Helferlein (Kategorien, Blog-Kalender, letzte Kommentare, …) stören den ersten Eindruck nicht, sondern sind dezent an des Seitenende gewandert und nehmen auf den ersten Blick keinen Platz weg. Das Ganze wird abgerundet durch eine dezente, stimmige Farbpalette und Typographie. Sogar das Probebild, der Kolkrabe auf Fuerteventura, gefällt mir in dem Design so gut, dass ich ihn voerst dort belassen werde … Ein Bezug zu meinem Namen ist ja gegeben 😉

Dieses Theme ist übrigens auch responsiv, aber leider kommt der Kolkrabe auf Tablet und Smartphone nicht wirklich zur Geltung.

Vierter Schritt: Korrekturen

Das ist wohl der zeitintensivste Schritt, der durchaus Potenzial hat, den Spaß an der Freude zu verderben und mich dann doch fast ein halbes Jahr Arbeit gekostet hat (peu à peu auf 6 Monate verteilt – ich hab ja nebenbei auch noch andere Dinge zu tun). Aber gut: Die eierlegende Wollmichsau darf ich nicht erwarten. Das Problem, vor dem ich stand, war, dass Anpassen der Bilder in den einzelnen Blogposts. In Joomla hab ich die Bilder anfangs manuell skaliert, zwischendurch mit einem Plugin automatisch angepasst. Grundsätzlich wurden alle Bilder, die nicht in einer Galerie waren, zu WordPress migriert. Das erste Bild eines Blogpost wurde als Beitragsbild definiert, was ich für die Anschaulichkeit mittlerweile unerlässlich finde. Das hatte nun allerdings zur Folge, dass dieses Bild doppelt im Beitrag ist: Einmal als Beitragsbild und einmal als positioniertes Bild im Beitrag. Das sah mehr als bescheiden aus. Ich habe hierfür ein Plugin installiert, das die Anzeige des Beitragsbildes im Blogpost selbst unterdrückt. Das Bild ist also nur im Kurztext auf der Hauptseite zu sehen und an der von mir definierten Position im Text mit entsprechender Skalierung.

Diese Option „Hide Featured Image“ muss ich allerdings manuell in jedem Blogpost (es sind etwa 250) aktivieren, wenn ich es nicht direkt in der Datenbank machen will. Bei Letzterem bin ich bei so komplexen Datenbanken aber mittlerweile vorsichtig, da ich Seiteneffekte nicht abschätzen kann. Das ist aber auch nur halb so schlimm, denn aufgrund dessen, dass ich in jedem Blogpost die Skalierung der Bilder überprüfen und ggf. anpassen muss (soll ja schick aussehen), muss ich eh in jeden Post rein.

Darüber hinaus gibt es noch ein bisschen Feinschliff zu machen, damit das Look’n’Feel stimmt. Dazu gehöre zum Beispiel die Galerien, die ich hauptsächlich für meine Pinseleien im Einsatz hatte. Hier habe ich mich für das Huge-IT Portfolio entschieden, dass in seiner Non-Premium-Ausführung vollkommen ausreichend ist für meine Zwecke.

Fünfter Schritt: Relaunch

Zu guter Letzt blieb nun nur noch die Domain auf die WordPress-Installation umzubiegen und vorher die Site-URL in WordPress anzupassen (Arbeitsumgebung war natürlich nicht die Live-Domain), wäre da nicht die Sache mit den Permalinks, die mich gedanklich und arbeitstechnisch dann doch länger beschäftigt hat:

Ich wollte zwischenzeitlich die Premium-Version des oben genannten Migrations-Plugins kaufen (ca. 35 Euro). In der Premium-Version werden automatisch u.a. die alten Joomla-Links umgebogen bzw. die WordPress-Permalinks so eingerichtet, dass zu mir führende Links von anderen Seiten auch zukünftig den richtigen Weg finden. Nach einigem Hin und Her sowie Probieren habe ich aber beschlossen auch dies manuell zu machen.
Dazu habe ich das Permalink-Schema von WordPress dem von Joomla angepasst und die Aliase der Kategorien entsprechend korrigiert, was der einfache Teil war.

www.beispiel.de/%category%/%title%

Der aufwändigere Teil war, die Aliase der Artikel anzupassen. Joomla hat die Aliase aus dem Titel des Artikel generiert sowie es WordPress grundsätzlich auch tut. Zusätzlich hat Joomla aber vor jeden Alias die Artikel-ID gemäß Datenbank gesetzt. Die IDs sind bei WordPress aber andere, insbesondere da WordPress auch alle Revisionen in der Artikel-Tabelle der Datenbank speichert und mit einer einmaligen ID versieht – in dieser Datenbank sind bereits über 1000 IDs vergeben, da ich ständig an den Artikeln korrigiert habe, was zu eigenen Revisionen geführt hat.
Ich habe daher sämtliche Aliase um die alte Joomla-ID ergänzt, so dass die Links nun stimmen. Bei über 250 Artikeln war das ein Aufwand von ca. 2 Stunden – noch überschaubar. Den Aufwand hab ich in erster Linie deshalb betrieben, da einige meiner Artikel insbesondere aus der Kategorie „Reiterstübchen“ doch recht große Verbreitung gefunden haben und regelmäßig in Blogs, Foren und sozialen Medien referenziert werden. Sollte ich trotz aller Sorgfalt einen Link übersehen oder mich vertippt haben, gebt mir einfach Bescheid.

pfeff.eroni.de wird daher auch pfeff.eroni.de bleiben auch wenn der Blog nun deutlich mehr Pepp hat 😉 Vielleicht richte ich eine alternative Sub-Domain pepp.eroni.de ein.

PS: Der finale Feinschliff

Absolute Links auf Bilder korrigieren

Das Umbiegen auf diese Domain hatte leider noch einen kleinen, unschönen Nebeneffekt, für den ich aber schnell eine Lösung gefunden habe. Die Bilder im Blog werden in WordPress mit absoluten Links verdrahtet. Die Änderung der Basis-URL hatte also zur Folge, dass die Verweise auf die Bilder sowohl in den Artikeln als auch im Theme ins Leere liefen. Mit relativen Links würde es dieses Problem nicht geben.

Für die Anpassung der Links in den Artikeln hab ich folgenden SQL-Befehl auf Geekpub gefunden:

UPDATE wp_posts SET post_content = replace(post_content, ‚alte Domain‘, ’neue Domain‘);

Da hätte ich natürlich auch selbst drauf kommen können. Andererseits lebt das Internet ja auch irgendwie vom Teilen des Wissens. Danke hierfür.
Für das zweite Bild-Problem, nämlich dem Hintergrundbild im Theme bin ich in die Datenbank gegangen. In der Tabelle wp_options gibt es für das Seasonal-Theme die Zeile theme_mods_seasonal, in der recht kryptisch die Einstellungen des Themes gespeichert sind – so auch der Link zum Hintergrundbild. Die entsprechende Option heißt nun:

s:61:“http://pfeff.eroni.de/wp-content/uploads/2016/02/kolkrabe.jpg“;

wobei s:61 die Länge des darauf folgenden Wertes angibt – in diesem Fall die Zeichenanzahl des Links. Dieser Kontrollwert muss angepasst werden, da das Theme andernfalls die Default-Einstellungen verwendet. Das Ganze hätte ich natürlich auch im Dashboard anpassen können, allerdings erscheint bei mir derzeit nur einen weiße Seite beim Versuch, den entsprechenden Menüpunkt aufzurufen, was wiederum auf einen Skriptfehler bzw. nicht nachgeladene Skripte hinweist.

Kommentare übernehmen

Auch die Kommentare der Joomla-Instanz habe ich nun vollständig übernommen – manuell – 202 Kommentare. Geiz ist geil.

Zu diesem Zweck habe ich zunächst die entsprechende SQL-Tabelle der Joomla-Instanz nach Excel exportiert. In der Tabelle sind einige Spalten, die man ausblenden kann. Für mich wichtig waren die Spalten für Kommentar-ID, übergeordnete Kommentar-ID (bei Antwort-Kommentaren), ID des zugehörigen Artikels, der Autor, Email, Webseite, der Kommentar selbst und das Datum. Die IP-Adresse hab ich nicht überführt, denn wir sind hier ja nicht bei der Stasi.

Als Admin angemeldet, habe ich nun Artikel für Artikel jeden Kommentar unter Beachtung der Schachtelung verfasst und abgeschickt. Da ich vorab ja jeden Permalink mit der Joomla-ID versehen hab, hab ich ich michr echt gut mit der Artikel-ID meiner Excel-Tabelle durchhangeln können, den der Titel des Artikels steht sinnvollerweise nicht in der Tabelle (hat was mit Veränderungsanomalien und Normalformen von Datenbanken zu tun 😉 ). Anschließend ging es daran im Backend jeden einzelnen Kommentar anzupacken und den Autoren sowie das ursprüngliche Datum anzupassen. Zu guter Letzt habe ich in der Datenbank (Tabelle wp_comments) für alle Kommentare, die nicht von mir waren, die User-ID auf 0 gesetzt. Ohne diese Korrektur stünde zwar bei jedem Kommentar der manuell korrigierte Name, aber intern wäre er dennoch mit meinem Account verknüpft, was auch dazu führt, dass bei jedem Kommentar mein Gravatar angezeigt wurde. Die 0 steht quasi für den unbekannten/unregestrierten Benutzer und der Gravatar wird – sofern vorhanden – entsprechend der hinterlegten Email-Adresse geladen.

UPDATE `wp_comments` SET `user_id` = ‚0‘ WHERE `wp_comments`.`comment_author` != ‚mein verwendeter Nickname‘;

Das PHP-Skript, dass ich hier gefunden hab, habe ich übrigens nicht ausprobiert, da es schon etwas älter ist und WP seit dem schon einige Updates durchlebt hat.

Zugegeben: Dieser Teil des Feinschliffs war schon recht zeitintensiv (ca. 5-6 Stunden Arbeit) und friemelig, aber der Aufwand war es mir auch wert. Immerhin sind es viele schöne, nette, liebe, hilfreiche Worte und bei manch einem Kommentar musste ich schmunzeln (zum Beispiel Freitagstexter 1 & 2).

Joomla Plugins: BK Multithumb und SIGE im Parallelbetrieb

Posted on 7. Oktober 2014Leave a comment

Seitdem ich notgedrungen (und dringend notwendig) auf Joomla 2.5 ein Upgrade durchgeführt habe, hatte ich so meine lieben Probleme mit der Darstellung von Bildern. Ich hatte bei Joomla 1.6 zwei Plugins installiert, die sich nun in Joomla 2.5 behakt haben.

BK Multithumb – zum Vergrößern von einzelnen Bildern innerhalb eines Artikels
SIGE – Simple Image Gallery Extended – zum Darstellen von Gallerien (insbesondere bei den Pinseleien)

Entgegen manchen Foren-Beiträgen zu Konflikten der beiden Plugins zueinander kann ich sagen: Beide Plugins sind parallel einsetzbar. Wieso und weshalb und ob es sinnvoll ist, steht auf einem anderem Blatt.

Warum beide Plugins?

Beide Plugins gleichzeitig zu betreiben, ist eigentlich zu viel des Guten, denn beide Plugins können beide Funktionen. Warum ich damals (ja das ist wirklich schon eine Weile her) beide Plugins für notwendig erachtet habe, weiß ich nicht mehr. Jedenfalls ist das Blog mit den beiden parallel laufenden Plugins stetig gewachsen und das Umschwenken auf eines der beiden Plugins oder gar ein ganz anderes würde einen immensen Aufwand nach sich ziehen, zumal ich in manchen Artikeln beide Funktionen benötige.

Ein kurzer Überblick

BK Multithumb arbeitet ohne Markups. Das heißt, das Plugin prozessiert standardmäßig über alle Bilder der aufgerufenen Seite. Eingeschränkt werden kann dies durch Auswahl von Kategorien, Artikeln etc. in der Konfiguration oder dem Tag { nomultithumb } im entsprechenden Artikel/Modul. Zu dieser Blacklist-Vorgehensweise ist Alternativ auch eine Whitelist-Vorgehensweise möglich, dazu muss aber in jedem Artikel bzw. dort wo Bilder auftauchen und verkleinert werden sollen der Tag { multithumb } vorhanden sein.
Ich hab die Blacklist-Variante im gesamten Blog verwendet. Das nachträgliche Umstellen auf Whitelist bei über 200 Artikeln ist … naja … da habe ich keinen Bock drauf.

SIGE dagegen wird durch den Markup { gallery }…{ /gallery } aktiviert und prozessiert über den Ordner, der innerhalb des Tags angegeben wird. Ich habe das insbesondere für die Pinseleien und einige Bildserien als praktisch erachtet, weil ich zusammenhängende Bilder nur in einem Ordner sammeln muss, diesen angeben und die Bilder werden alphanummerisch sortiert sehr schön einheitlich dargestellt.

Das Problem war nun, …

… dass BK Multithumb sich auf den ersten Blick nicht mit SIGE verträgt. Beide ersetzen die Originalbilder in den Artikeln durch generierte Thumbnails. Während SIGE nur explizit angegebene Gallerien erstellt, prozessiert BK Multithumb über alle Bilder … auch die Thumbnails der SIGE-Gallerien und das führt zu lästigen Problemen und Fehlermeldungen.

Eine Lösung wäre nun gewesene, alle Artikel mit Gallerien auf die Blacklist zu setzen, zumal die Anzahl dieser Artikel überschaubar ist. Meinem Problemlösungsherz widerstrebt dieser Ansatz jedoch zutiefst … manuelles Nacharbeiten, wo es doch früher bei Joomla 1.6 problemlos ging? Google brachte mir im schnellen durchblättern keinen brauchbaren Hinweis. Eher waren dumme Nachfragen zu lesen „Wozu denn beide Plugins? Eins reicht doch völlig.“ oder platte Antworten „Das verträgt sich eben nicht!“ Beides ist wenig hilfreich insbesondere, da es m.E. immer begründete Fälle gibt, wo das Suchen einer praktikablen Lösung Sinn macht … meine Historie des Problems zum Beispiel.

Mögliche Fehlermeldungen

Eine der ersten Fehlermeldungen, die mir entgegensprangen, war folgende:

Fatal error: Allowed memory size of 262144 bytes exhausted 
(tried to allocate 2288 bytes) in .../plugins/content/multithumb.php 
on line 755

Wobei Anzahl der Bytes und Zeilennummer variierten. So oder so war dies ein fataler Fehler, der die Ausführung des PHP-Skriptes auf dem Server stoppte. Auf der Server-Ebene war dieses Problem für mich nicht lösbar, weil ich auf meinem Webspace keine php.ini bearbeiten kann/darf und die Manipulation der .htaccess zu anderen Server-Fehlern führte (ergo: auch nicht erlaubt). Den maximalen Speicher zu erhöhen, um den Fehler zu beheben, war also keine Option. Daher blieb mir nichts anderes als die betroffenen Bilder weiter zu verkleinern.
SIGE hatte übrigens auch Problemchen mit zu großen Dateien. Allerdings stoppt die serverseitige Kompilierung der PHP-Seiten sofort ohne Fehlermeldung (weiße Seite – mein Lieblingsproblem, wenn man keinen Zugriff auf die Error-Log-Files vom Webserver hat). Ein Hoch daher auf die Stapelverarbeitung mit GIMP … macht schnell alle Bilder kleiner …

Ein lästigeres Problem war dann die folgende Fehlermeldung – ebenfalls von BK Multithumb:

Warning: getimagesize() [function.getimagesize]: Unable to access 
/cache/preview/0348bc6c07f74493240258aabbdb82af.JPG in 
.../plugins/content/multithumb/multithumb.php on line 1546

Diese Fehlermeldung lag darin begründet, dass BK Multithumb versucht, die Thumbnails von SIGE zu prozessieren, was nicht geht, weil die Thumbnails im Cache liegen. Die Fehlermeldung von BK Multithumb selbst (weißer Kasten mit rotem Rand) lässt sich ganz einfach mit einem entsprechenden Haken in der Konfiguration des Plugins unterdrücken, die PHP-Warnung selbst allerdings nicht. Diese ließen sich zwar durch das Herabsetzen des Error-Reporting-Levels unterdrücken, damit unterdrücke ich aber auch sämtliche anderen Warnung dieses Levels, die irgendwann mal auftreten könnten und von Interesse sein könnten. Viel besser wäre es natürlich, wenn die Warnungen erst gar nicht erscheinen würden und hier kommt ein Bord-Mittel von Joomla zum Einsatz, was wohl gerne (auch von mir) übersehen wird.

Zu einfach, um wahr zu sein

Die aktivierten Plugins werden in einer bestimmten Reihenfolge auf die Webseite angewendet. Damit BK Multithumb also die SIGE, muss BK Multithumb zwingend nach SIGE laufen. Die Reihenfolge der Plugins muss also angepasst werden.

Und das ist auch schon des Rätsels einfache Lösung.

Beide Plugins kann ich übrigens wärmstens empfehlen, da sie wirklich zahlreiche Möglichkeiten offerieren und fein abstimmbar sind. Wer ein Blog frisch aufsetzt, sollte sich allerdings direkt für ein Plugin entscheiden – beide Plugins können sowohl Einzelbilder als auch Gallerien darstellen. Nur wer Altlasten mit sich herumschleppt, muss sich mit der Plugin-Reihenfolge befassen!

Blog gehackt

Posted on 8. Dezember 20131 Kommentar

Und zack … da hatte es mein Blog erwischt.

Zunächst war ich davon ausgegangen, dass lediglich die PHP-Version auf dem Server angehoben wurde und mein altes Joomla 1.5.26 zu alt geworden ist … ist ja immerhin schon seit 2 Jahren schon abgelöst und wird nicht mehr unterstützt und seit mindestens einem Jahr wollte ich das Content Management System schon auf die aktuellste Version anheben, das Template überarbeiten …

Nachdem ich mir dieses Wochenende nun endlich Zeit nehmen konnte, den Fehlermeldungen nachzugehen, war recht schnell klar, dass das nichts mit der PHP-Version zu tun hat sondern ganz einfach ein Hack war. Mein Admin-Passwort war in der Datenbank überschrieben und dann wurde irgend etwas im Joomla-Core kaputt gemacht.

Also Joomla neu aufgesetzt, Datenbank importiert und dann hieß es „Upgrade“. Bisher hab ich da immer einen Bogen drumherum gemacht, da ich einige liebgewonnene Plugins und Module für meinen Blog nicht für Joomla 2.5 wiedergefunden habe. Nun war ich gezwungen umzustrukturieren und nach jeder Menge Fissel-Arbeit, konnte ich alle Feature mit anderen Komponenten, Modulen und Plugins nachbilden. Dann noch ein bisschen Facelift am Template und mein Blog erstrahlt in neuem Glanz.

Die einzige Komponente die nun noch fehlt ist die Kommentarfunktion, aber das kommt noch. Da die Kommentarfunktion die einzige Komponente ist, bei der Nutzerdaten gespeichert werden, kann ich leider nicht garantieren, dass Daten gestohlen wurden. Ich werde daher diese Woche, die alten Kommentare auswerten und potentiell betroffene Nutzer über den Hack informieren.

Joomla 1.5.x – Fatal Error nach anscheinenden Server-Backup

Posted on 29. Januar 20122 Kommentare

Folgendes Problem traf mich soeben vollkommen überraschend und unvorbereitet:

Im Frontend direkt:

Fatal error:  Class 'JCache' not found in
/var/www/.../html/libraries/joomla/factory.php on line 208

Im Backend vereinzelt:

Fatal error: Class 'JCache' not found in
/var/www/.../html/administrator/components/com_config
/controllers/application.php  on line 189

Das letzte, was man bei einem Beusch einer Webseite sehen will, ist „Fatal Error“ und sonst nix. Wäre es meine eigene Seite gewesen oder nur das Backend, hätte ich mir gemütlich einen Kaffee besorgt und dezent angefangen das Problem zu suchen. War es aber nicht, sondern eine Kundenseite und dementsprechend alarmiert war ich.

Aus diesem Grund hab ich mir erstmal nicht die Datei factory.php auf Zeile 208 oder die Datei application.php in Zeile 189 angeschaut, sondern direkt Google.

Ich bin im Forum von Joomlaportal.de auch sofort fündig geworden und das verwies auf einen Beitrag im englischsprachigen Forum von Joomla.org. Das Problem scheint zu sein, dass der Inhalt des Ordners /…/libaries/joomla/cache/ verloren gegangen ist. In beiden Beiträgen wurde anscheinend ein Backup der Joomla-Installation durch den Provider eingespielt, einmal aufgrund eines Hacker-Angriffs, einmal aufgrund eines Server-Ausfalls. Beide Ursachen treffen auf meinem Fall (nach meinem Wissen nicht zu), dennoch musste ich feststellen, dass der besagte Cache-Ordner leer war. Eigentlich sollte der Ordner zwei weitere Ordner und drei Dateien enthalten (s. Bild).
Ich habe daraufhin, wie im englischsprachigen Forum beschrieben, den Cache-Ordner einer anderen Joomla-1.5.x-Installation in die fehlerhafte Installtion kopiert und alles war wieder funktionsfähig. Alternativ kann man auch den Cache-Ordner einer Blanko-Installation nehmen, hauptsache diese Ordner und Dateien sind wieder an Ort und Stelle.

Nun frage ich mich natürlich, wie es dazu kommen konnte. Die Webseite ist auf dem aktuellsten Release, ich habe in der nahen Vergangenheit keine Änderungen vorgenommen, nichts. Dieses Blog hier hat, bis auf einzelne Komponenten, Module und Plugins, genau dieselben Parameter wie die defekte Seite, aber sie liegt auf einem anderen Server. Aus diesem Grund nehme ich an, dass das Problem beim Server der defekten Seite zu schen ist, auf den ich natürlich keinerlei weiteren Zugriff habe. Die Beschreibungen der Foren-Beiträge lassen ja eindeutig die Schlussfolgerung zu, dass es nicht an Joomla selbst sondern an externen Umständen als Auslöser gelegen hat.
Jetzt finde ich es natürlich sehr schade, dass vom Provider keinerlei Information zu einem Server-Ausfall (oder was auch immer) gab. So bin ich eher zufällig auf das Problem gestoßen, was mich echt ärgert.

Dadurch bin ich aber auch wieder gedanklich näher an der Idee, einen eigenen Server zu betreiben. Nicht physisch in meiner Wohnung, aber zumindest gemietet in irgendeinem Rechenzentrum. Zwar kann ich damit nicht physische Ausfälle des Servers in den Griff bekommen, aber ich kann zumindest die Ursache vieler Probleme besser eingrenzen oder vielleicht sogar ganz verhindern. Mal sehen.

Joomla: Flattr-Button erzeugt XSS-Warnungen

Posted on 31. Juli 20112 Kommentare

… und aus dem Grund hab ich ihn von meiner Webseite entfernt. Da ich mich nach wie vor nicht mit der Programmierung von Joomla-Plugins, -Modulen und -Komponenten geschweige denn mit der API von Flattr beschäftigt habe, hab ich das Plugin vorerst deaktiviert. Im Firefox warnte mich NoScript permanent, dass der Button unter Umständen eine XSS-Schwachstelle sei …bla … hat mich genervt. Punkt. Aus. Weg damit.

Wenn ich mal ausführlich Zeit hab, durchforste ich mal die Extension-Sammlung von Joomla und vielleicht hat sich bis dahin ein neues, unverdächtiges und vor allem kostenloses Plugin aufgetan – eventuell sogar eines, das Twitter, Facebook, Flattr und Google+ vereint. Vielleicht gibt es das auch schon.

Aber wie gesagt … das ist erstmal aufgeschoben.

Joomla – Noix ACL: Bug im Media Manager

Posted on 21. April 2011Leave a comment

Folgendes Problem tat sich mir jüngst bei einem Joomla-Projekt auf, bei dem ich für die Rechte-Verwaltung NoixACL verwende. Ich habe die Version 2.0.6 beta installiert u.a. mit dem Adapter „access“ in der Version 1.5.4. Soweit ich es in der Version 1.5.5 sehen konnte, ist dieses Problem dort nicht behoben worden. Eventuell ist dieses Verhalten auch Absicht, aber das kann ich mir eigentlich nicht vorstellen, da ich schon an vielen Stellen im Internet diese Schilderung gefunden habe, aber leider immer ohne Erklärung oder Workaround. Deswegen tu ich hier meine Erkenntnisse kund und hoffe damit, dem ein oder anderen zu helfen.

Problem

Alle Nutzer, die keine Superadministratoren waren, konnten keine Dateien im Media Manager bzw. Bilder beim Bild-Upload in einem Artikel hochladen, obwohl unter „Manage Groups“ > „Access“ > „General“ > „Manage Media“ der Zugriff erlaubt wurde. Es fehlte schlicht das Formularfeld für den Datei-Upload, wie man auf dem Bild-Vergleich sehen kann. Die Ansicht, die Auswahl und das Löschen von Dateien funktionierte problemlos.

Links, wie es sein soll und rechts die verbuggte Variante unter noixACL

Das Problem betrifft also die Zugriffsrechte auf die Komponente „com_media“.

Lösung

Jetzt muss ich gleich vornweg sagen, dass mir die Struktur von Joomla-Komponenten und dem Joomla-Framework selbst noch nicht so geläufig ist. Es kann also durchaus sein, dass es eine elegantere Lösung gibt, aber ich meine zumindest, das Problem an der richtigen Stelle mit den richtigen Maßnahmen angegriffen zu haben. So oder so will ich hier kurz meinen „Trial & Error“-Weg skizzieren als Anhalt, wie man bei der Problemsuche vorgehen kann.

Wo liegt der Hund begraben

Also. Ein Blick in die Komponente „com_media“, genauer gesagt, die Datei, die das Upload-Formular anzeigt¹, hat mir verraten, dass das Formularfeld nur angezeigt wird, wenn der Nutzer Upload-Rechte hat, was ja logisch ist.

<?php $canUpload= ($this->user->authorize('com_media', 'upload')); ?>

Da noixACL nicht in den Joomla-Kern selber eingreift, konnte das Problem also nicht hier liegen.
Der nächste Blick wanderte daher auf die Datenbank und hier auf die Tabelle „jos_noixacl_rules“. Dort habe ich nach aco_section=’com_media‘ gefiltert und für jede Benutzergruppe, die Schreibrechte haben sollte, zwei Einträge gefunden. Einen Eintrag mit aco_value=’manage‘ und einen mit aco_value=’popup‘.

SQL-Datenbank manipulieren

Ein kleiner Test (Datensatz löschen) ergab, dass der Wert „manage“ den Zugriff auf den Media Manager erlaubt und „popup“ auf den Bild-Upload innerhalb eines Artikels. Diese Zeilen mussten also bestehen bleiben. Anhand der Überprüfung innerhalb der „com_media“-Komponente (s.o.) hab ich nun einen neuen Datensatz mit dem Wert „upload“ im Feld „aco_value“ angelegt (siehe Bild).

Neuen Datensatz unter PHPMyAdmin anlegen

Dabei muss das Feld „id“ leer bleiben, da es automatisch inkrementiert wird. Im Feld „aro_value“ wird der Gruppenname so angegeben, wie er auch in der Gruppenliste angezeigt wird (also bsp. ‚Administrator‘). Alternativ kann man auch eine SQL-Anweisung schreiben statt der bequemen PHPMyAdmin-Variante:

INSERT INTO jos_noixacl_rules VALUES (NULL,'com_media','upload','users','Gruppenname','','')

Und siehe da, das Upload-Formular ist sichtbar und funktioniert sowohl im Media Manager als auch im Bild-Upload innerhalb eines Artikels.

Quelltext des Adapters anpassen

Dieser manuelle Eingriff in die Datenbank ist natürlich unschön. Schöner ist es, wenn beim Anlegen/Bearbeiten einer Gruppe die richtigen Datenbankeinträge gesetzt werden.

Dazu muss man in den Adapter „access“ gehen, der den Zugriff auf Komponenten steuert. Die gesuchte php-Datei ist

../administrator/components/com_noixacl/adapters/access/aeccess.php

In der Methode „save“ werden systematisch die Zugriffsregeln vorbereitet, welche dann als Datensatz in die Datenbank geschrieben werden. Da man für den Zugriff auf den Media Manager aber nur ein Haken gesetzt wird, aber mindestens 2 Regeln benötigt werden (für die zusätzlichen Bild-Upload innerhalb eines Artikels) wird ab der Zeile 48 in einer switch-Anweisung die zusätzliche Regel mit dem Wert „popup“ erzeugt.

switch($aco_section) {
  case 'com_media':                            
    if ($aco_value='manage') {
      $arrRule = array(
        "aco_section" => $aco_section,
        "aco_value" => 'popup',
        "aro_section" => "users",
        "aro_value" => $groupName,
        "axo_section" => $axo_section,
        "axo_value" => $axo_value
      );
      $this->insertRule($arrRule);
    }
}

Hier muss man innerhalb der if-Anweisung nun noch eine Regel ergänzen, die statt dem Wert ‚popup‘ den Wert ‚upload‘ enthält.

switch($aco_section) {
  case 'com_media':                            
    if ($aco_value='manage') {
      $arrRule = array(
        "aco_section" => $aco_section,
        "aco_value" => 'popup',
        "aro_section" => "users",
        "aro_value" => $groupName,
        "axo_section" => $axo_section,
        "axo_value" => $axo_value
      );
      $this->insertRule($arrRule);
      $arrRule = array(
        "aco_section" => $aco_section,
        "aco_value" => 'upload',
        "aro_section" => "users",
        "aro_value" => $groupName,
        "axo_section" => $axo_section,
        "axo_value" => $axo_value
      );
      $this->insertRule($arrRule);
    }
}

Also nochmal zusammenfassend, wofür welche Regel da ist:

manage – Zugriff auf den Media Manager
popup – Zugriff auf den Bild-Upload innerhalb eines Beitrags
upload – Anzeige der Formular-Felder für den Datei-Upload

Alle diese drei Regeln müssen für eine Gruppe in der Datenbank vorhanden sein.

Wie eingangs erwähnt, habe ich „noch“ die Version 1.5.4 des Access-Adapters für noixACL installiert. Mittlerweile gibt es die Version 1.5.5, in welcher – wenn ich mich nicht verguckt habe – dieses Problem aber nicht behoben wurde. Wenn man nach diesem Eingriff in den Quellcode also eine neue Version installiert, muss man den Quellcode erneut bearbeiten.

Für bestehende Gruppen kann man die Rechte nachträglich ändern, indem man entweder jede Gruppe im Backend betrachtet und den Haken bei „Manage Media“ einmal entfernt und wieder setzt oder man erzeugt mit einem Schlag für jede Gruppe einen neuen Datensatz mit einem SQL-Statement (wie oben).

Die Sache abrunden (delete-Methode)

Um Datenbankleichen und ggf. Fehlfunktionen aus dem Weg zu gehen, wenn man eine Gruppe löscht, muss in derselben Datei in der Methode „delete“ ca. bei Zeile 95 der Befehl

$this->deleteRules("com_media","upload",$groupName);

ergänzt werden.

1) Genau handelt es sich um die Datei ../administrator/components/com_media/views/media/tmpl/default.php

Joomla: Version 1.6 steht kurz vorm Stapellauf

Posted on 10. Januar 2011Leave a comment

Ich hab mittlerweile eine Handvoll von Projekten inklusive meinem Blog hier mit Joomla realisiert. Im Rahmen eines anderen Projektes stieß ich auf die Problematik, dass die Rechteverwaltung von Joomla 1.5.x eher rudimentär ist und für komplexere Strukturen nur mithilfe von noch komplexeren Erweiterungen anpassbar ist. Ich hab mit einigen ACL-Erweiterungen rumgespielt und entweder wurden meine Anforderungen nicht erfüllt oder die Erweiterung war kompliziert handhabbar mit komischen Seiteneffekten.

Auf der Suche nach einer passenden ACL-Erweiterung bin ich schnell auf die Meldung gestoßen, dass Joomla in der Version 1.6 weiterentwickelt werden wird und unter Anderem die Rechteverwaltung novelliert wird.
Nach 15 Beta-Versionen und einem Release Candidate soll es morgen nun so weit sein, dass das Open Source Projekt Joomla in der Version 1.6 als produktiv nutzbare Version veröffentlicht wird. Joomla 1.6 basiert auf dem Framework der Version 1.5, wodurch die Migration auf die neue Version unkompliziert ablaufen soll.

Wenn Joomla 1.6 dann also hoffentlich morgen vom Stapel läuft, werd ich mich gleich (oder am Wochenende) ran setzen und die ersten Migrationsversuche unternehmen. Besonders interessant wird natürlich, inwiefern meine bisher benötigten Erweiterungen noch vonnöten sind und falls dem so ist, ob sie bereits mit Joomla 1.6 laufen bzw. ob es schon Updates gibt.

Ich bin so oder so gespannt.

[UPDATE] Joomla: Sortierung der Artikel fehlerhaft mit Update auf 1.5.22

Posted on 9. November 2010Leave a comment

Zunächst war es mir gar nicht aufgefallen, aber nachdem ich die dritte Webseite auf die aktuelle Joomla-Version 1.5.22 gebracht hatte, fiel mir die fehlerhafte Sortierung im Bereichsblog auf. Egal welche Einstellung ich wählte, die Sortierung blieb scheinbar willkürlich. Ich war kurz vorm Durchdrehen, weil mir der Fehler auf meinem eigenen Blog noch gar nicht aufgefallen war und ich vermutete, es hängt mit der Rechteverwaltung auf der anderen Webseite zusammen.

Nach ein bisschen erfolgloser Google-Suche, kam mir dann der zündende Gedanke und ich hab mal nach „joomla 1.5.22 sortierung“ gesucht. Ich bin dann direkt im Sammelthread von joomlaportal.de gelandet, der auf die englische Dokumentation von Joomla verweist: Und tatsächlich hat sich im Source-Code ein kleiner aber ausschlaggebender Fehler eingeschlichen:

In der Datei „…/components/com_content/models/section.php“ muss in der Zeile 447 der Eintrag

$filter_order = 'a.ordering';

$filter_order = '';

geändert werden und die Sortierung funktioniert wieder so, wie der Nutzer es will.

Ich denke, der kleine Bug wird mit dem nächsten Sicherheitsupdate gefixed und solange hilft dieser Handgriff, den ich heute abend, dann auch auf dem Quellcode meines Blogs anwenden werde.

Update – 13.05.2011: Mit dem Patch von Version 1.5.22 auf 1.5.23 wurde das Sortierungsproblem anscheinend behoben. Jedenfalls brauchte ich nach dem Update nicht wieder in den Quellcode eingreifen.

Windows Live Writer

Posted on 6. Juli 2010Leave a comment

Als ich mein vorkonfiguriertes Notebook erhalten habe, habe ich mich schon gewundert, was denn da so drauf rumfleucht. Da war zum Beispiel der (kostenlose) Live Writer und ich dachte mir so: “Ick hab doch Office.”

Heute war ich gerade dabei, einen etwas ausführlicheren Blogpost im Backend von Joomla zu verfassen und dann passierte es: Ich rutsch mit dem Handballen auf das Touchpad und die leichte Berührung hat für einen Klick gereicht. Dummerweise war die Maus über einem Favoriten im Firefox positioniert und Schwups … mein mühsames Blogpost war weg.

Ich hab meinen Frust auf Twitter kundgetan und just kam der Hinweis vom Nerd auf den Live Writer. Mein erster Gedanke: Das funktioniert doch sicher nur mit spezieller Blogsoftware, wie WordPress oder Blogspot oder so. Aber sicher nicht mit Joomla. Ich habs trotzdem mal schnell gegoogelt und bin zu meiner eigenen Überraschung auf Anhieb fündig geworden. Es gibt ein Plugin, so dass Live Writer über die Movable Type API mit Joomla kommunizieren können soll. Ich schreib “können”, weil beim Veröffentlichen der Ursprungsversion dieses Blogpost eine Fehlermeldung erschien, dass die Kommunikation mit der API aus irgendwelchen Gründen nicht ginge.

Methode metaWeblog.newPost ist ungültig: Invalid response document returned from XmlRpc server

Die Fehlermeldung hab ich dann auch schnell gegoogelt und mit dem Zusatz “Joomla” versehen. Die Ergebnisliste war äußerst aber überschaubar aber hilfreich. Denn ein kurzer Forum-Eintrag beschrieb genau das Problem und verwies auf eine andere API – die Metaweblog API.
Die Installation ist sinngemäß die gleiche, wie hier beschrieben mit dem Unterschied, dass man während der Konfiguration von Live Writer nicht die Movable Type API sondern eben die Metaweblog API auswählt.

So sollte es funktionieren – bei mir tut es das 🙂

Webserver aufsetzen

Posted on 23. Juni 20101 Kommentar

Ich betreibe mein Blog ja auf einem fertig installierten und konfigurierten Server eines Providers. Auf solch einem Server ein Content Management System zu installieren ist ja nicht gerade die Schwierigkeit. Da ich jetzt auf Arbeit ein kleines Web-Projekt zu Testzwecken gestartet habe und somit keinen Provider hab, war ich „gezwungen“ den Server vom Betriebssystem bis zur letzten Extension selbst aufzusetzen. Ich mach das natürlich nicht zum ersten Mal, aber zu behaupten, ich mach es regelmäßig und ohne Zwischenfälle, wäre glatt gelogen. So auch diesmal – ich hab wieder fleißig Google bemüht und in diversen Foren und Blogs die notwendigen Infos zusammengetragen oder die Fehler durch Trial & Error behoben. Aus diesem Grund will ich das ganze hier (kurz) dokumentieren.