Joomla Plugins: BK Multithumb und SIGE im Parallelbetrieb

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!

[?php echo „Busy: „.$busybyte; ?]

Hochkomplex (Quelle: http://fun.drno.de/)

Falls sich einer fragt, warum es hier so ruhig geworden ist:

$busybyte = 1;

Mir ist nicht etwa die Lust am Bloggen abhanden gekommen, viel mehr habe ich die Lust am Programmieren wieder entdeckt. Schon länger wollte ich mich intensiver mit PHP beschäftigen, statt nur hier und da Flickschusterei zu machen, denn dabei lernt man die Sprache bei Weitem nicht. Nachdem ich also ein Skript für eine bestimmte Anforderung im Netz gesucht habe und nur bedingt fündig geworden war, habe ich kurzerhand beschlossen, selbst ein Skript zu schreiben, was dann maßgeschneidert auf mein Problem ist. Jetzt bin ich schon seit ca. 3 Wochen am programmieren und man sollte glauben, dass das ein riesiges Stück Software wird. Wenn man nach den „Lines of Code“ geht (derzeit geschätzte 2000-2500) stimmt das fast, aber es liegt dann doch eher daran, dass mein Programmierstil mangels Übung nicht sehr sparsam ist. Sei es drum. Jedenfalls bin ich schon ein bisschen stolz, dass das ich bisher alles umsetzen konnte, was ich wollte, und wenn ich morgen früh die richtige Anzahl und Menge Emails in meinem Postfach hab, weiß ich, dass auch meine PHP-MySQL-Cronjob-Mail-Funktion tut, was ich will. Falls mein Postfach übergelaufen ist und mein Mail-Server-Admin mich anlächelt1, werd ich daran wohl noch arbeiten müssen.
So oder so, war mein kleines Programmier-Projekt bisher sehr leerreich, was das Zusammenspiel von PHP, MySQL, Javascript, CSS, Cronjobs, … betrifft und wenn ich irgendwann mal damit fertig sein sollte, werd ich das Skript wohl auch veröffentlichen, auch wenn es wahrscheinlich so speziell ist, dass es keiner gebrauchen kann.

Es geht übrigens um einen hierarchischen Terminkalender, der einerseits den Nutzer an einem beliebigen Zeitpunkt an den Termin per Email erinnert und andererseits anderen Nutzern, die in der Hierarchie höher stehen, erlaubt zu prüfen, ob der Termin eingehalten wurde. Einzelne Funktionalitäten hab ich zwar in diversen Kalendern gefunden, aber genau die Kombination, die ich brauch, war nicht darunter oder nur zu horänden Preisen käuflich zu erwerben, was mit meinen Vorgaben nicht vereinbar war. Also selbst ist die Frau.

Das Sahnehäubchen der Anwendung soll dann irgendwann einmal sein, dass ich das Skript als Joomla-Komponente umschreibe, denn das ist auch ein Gebiet mit dem ich mich mal genauer befassen will. Aber dafür muss wohl der nächste Winter herhalten, denn der Frühling steht ja vor der Tür und ich werd mich langsam vom PC wegentfernen. Entgegen manch böser Zungen ist meine Bildschirm-Bräune nicht system-bedingt!