Kategorie: Uncategorized

  • Rapslis World – Fast Gallery

    Leider hatte ich in den letzten Wochen nicht so viel (bzw. gar keine Zeit), um Blogposts zu schreiben, da ich eifrig damit beschäftigt war, Fast Gallery für Drupal 7 bereit zu machen. Die neue Architektur ist super flexibel und bietet eine "noch kleine" API für Entwickler, um eine komplette eigene Storageengine zu schreiben.

    Die Alpha 2 Version sollte eigentlich sogar ziemlich stabil laufen. Es gibt noch ein paar komische Dinge mit dem AJAX und auch mit der DB gibt es sicher noch Verbesserungspotential, aber sonst ist es eigentlich ziemlich stabil.

    Ich würde mich auf jeden Fall über ein paar Tester freuen. Und neue Features werden in der 7er Version nur langsam eingebaut werden. Stabilität ist das Motto dieser Version. Spezielle Features werden dann über Plugins hinzugefügt.

  • Warum es kaum guten fertigen Drupalthemes gibt

    Drupal ist nicht gerade bekann dafür, dass es viele hübsche Vorlagen gibt. Dies hat meiner Meinung den Grund, dass die Struktur und das Design stark voneinander getrennt sind. In einem Theme werden eigentlich lediglich die folgenden Dinge definiert bezüglich Struktur:

    • page.tpl.php -> Wo sind Blöcke, wo ist der Content bereich
    • node.tpl.php -> Wie sieht ein Node aus (Titel, Author, Text usw.)
    • Evtl. Blöcke entsprechend Themen

    Das führt dann halt eben meist zu den etwas steiffen Themes, welche überall zu finden sind. Die ganz schlechten sind viereckig mit einer Headergrafik, links und rechts platz für Blöcke und in der Mitte Platz für Content. Die etwas besseren sind nicht mehr viereckig, sondern haben noch ein zwei schöne Grafiken drin, welche die gleiche Struktur ein wenig aufpeppen.

    Was macht in meinen Augen ein gutes Theme aus? Mehrspaltigkeit und Bilder im Inhalt, welche als Teaser angezeigt werden. Nur liegt hier genau das "Problem" oder eigentlich der Vorteil: CCK und Views (oder Panels). Mittels CCK lassen sich Inhaltstypen definieren, z.B. einen Artikel mit einem Teaserbild und einem Lead bereichern. Mit Views kann jetzt eine schöne 2-Spaltige Übersicht gemacht werden, welche unter Umständen durch Panels noch weiter angereichert werden kann. ABER. Dies kann im Theme nicht berücksichtigt werden! Es können zwar gewisse Annahmen getroffen werden, aber schlussendlich ist der Verwender des Themes dafür verantwortlich, wie er den Inhalt im Theme zur Geltung kommen lässt.

    Daher: Ein Fixfertiges Theme zu finden, welches dann gleich super cool ausschaut ist meiner Meinung nach unmöglich.
    Dafür: Lassen sich mittels Drupal extrem gute/ansprechende Themes machen, welche perfekt an den Inhalt angepasst sind, wobei es jedoch ein Zusammenspiel Design/Programmierung/Konfiguration ist.

    In einem nächsten Blogpost werde ich versuchen, dieses Zusammenspiel Entwickler – Designer zu beschreiben.

  • Komischer Fehler beim Portieren ein Drupal Installation

    Da habe ich mal wieder 2 h meines Lebens vertrödelt. Hier die Voraussetzungen:

    Eine Drupal Installation. Diese habe ich von einem System auf ein andere kopiert. Datenbankdump erstellt und importiert, Files kopiert und settings.php angepasst. Alles kein Problem, doch beim Verbinden ist dann irgendwie ein Problem aufgetreten. Es kam eine Fehlermeldung, als hätte er die Verbindung verloren?! In Chrome sieht die wie folgt aus: "Fehler 101 (net::ERR_CONNECTION_RESET): Unbekannter Fehler."

    • Cache leeren -> nichts genützt
    • update.php ausführen -> konnte ich erreichen, aber hat auch nichts genützt
    • Theme auf Garland wechseln -> auch nichts gebracht.

    Jetzt bin ich schon fast ein wenig verzweifelt, da in index.php eigentlich alles geladen wird, lediglich dort wo dann die Funktion theme('page'…) aufgerufen wird, da "verliert er die Verbindung". Grosses Fragezeichen.

    Verzweiflung. Nichts.

    Die Lösung ist so einfach. CSS Aggregation abschalten und schon hats funktioniert. Ich habe das jetzt zwei Mal erlebt. CSS Aggregation kann auch direkt in der variable Tabelle umgeändert werden.

  • Fast Gallery architecture for the next version

    The current fast gallery module has become pretty big and hard to maintain. For the next version I've been thinking about a new and more flexible way. I've come up with the following system:

    There is a storage engine that can be accessed over an interface. Default will be the plain DB (which corresponds to the current storage system of fast gallery). The user can decide which mode he wants to use for building up the gallery. The interface allows other people to write storage engines for fast gallery, maybe someone wants to store the data as xml? or maybe no storing at all, but everything on the fly? … everything will be possible, as long as the interface will be implemented.

    Main principle will though still be the same: Fast gallery is watching a file folder and updates the gallery by cron job or manually.

    There is going to be the controller -> which will mainly be the Drupal integration and the Theming part which is going to be more flexible too using tpl files.

    Goal of this will be:

    • More flexibility
    • Better modulization
    • Easier to maintain
    • Easier to use for the enduser

    The base version is going to loose a lot of the functionality used in previous versions (for example, exif support, different sorting options). These are going to be optional plugins.

    I'm always open for inputs and ideas. This is open-source, so please help getting fast gallery to the next level.

  • Drupal Coding Standards – Warum sich Einhalten lohnt

    Klint irgendwie ein wenig wie die Games Conventions 😉 … Ich muss ehrlich gestehen, dass ich mich bis vor einigen Tagen noch nicht wirklich darum gekümmert habe. Coding Conventions gingen mir am A** vorbei, weil ich bereits meine eigenen hatte. Bisher ist das auch ziemlich gut gegangen, bis vor einigen Tagen.

    In der Issue Queue meines Exif Moduls, gab es einige Patches, welche schon seit geraumer Zeit aufs Committen warteten. Vor zwei Wochen habe ich damit angefangen. 1. Patch ging bestens. Der zweite Patch ging dann nicht mehr so gut, weil ja der Code verändert wurde, sprich dieser Patch musste neu erstellt werden, bzw. manuell eingepflegt werden. Meinem Aufruf in der Issue Queue, ob denn jemand den Patch neu erstellen würde, wurde sogleich auch folge geleistet, allerdings unter der Bedingung, die Drupal Coding Conventions zuerst hergestellt würden. So habe ich das mal gemacht.

    Also, warum lohnt es sich?

    Ich finde folgende Gründe:

    • Einheitlich, alle machen es gleich -> einfacher und übersichtlicher, wenn man ein fremdes Modul weiterpflegen will.
    • Patches erstellen. In vielen Editoren (z.B. auch Eclipse) hat man die Möglichkeit zum Autoformatieren. In meinem Eclipse hatte ich immer zum Einrücken Tabs verwendet (was nicht dem Drupal Standard entspricht). Wenn jetzt jedoch jemand kommt, den Code verändert/erweitert, seinen Autoformatter laufen lässt (welcher Leerschläge zum Einrücken verwendet) und dann einen Patch daraus macht, dann wird dieser Patch recht gigantisch aussehen, da ja die ganzen Leerzeichen auch veärndert wurde.
    • Gibt es noch mehr?

    Die wichtigsten Coding Conventions:

    <?php function meine_funktion($var) { //Abstand vor geschweifter Klammer if (1 == 1) { //Abstand nach if und vor geschweifter Klammer $text = $var .' hallo welt'; //Abstand zwischen Variable und Punkt, kein Abstand zwischen .' } $ar = array(1, 2, 4); //Abstand nach Kommas } ?>

    Eclipse einstellen

    Es ist eigentlich sehr einfach: Window > Preferences. Dann dort: General > Editors > Text Editors Display tab width: 2 Insert spaces for tabs: True Wer PDT installiert hat, kann es auch nur für PHP Files machen: Window > Preferences, Dann dort: PHP > Code Style > Formatter

    Links

  • Foto Galerie mit Drupal – Teil 2

    Pause war leider ein wenig länger als geplant… lag daran, dass der vorbereitete Blogeintrag plötzlich irgendwie verschwunden war. Jetzt geht es aber weiter. Im Teil eins haben wir mittels CCK die Bildererfassung gemacht. Dieser Teil ist für den Besucher der Galerie eigentlich noch nicht relevant. Im zweiten Teil werden wir die Galerie entsprechend darstellen. Dazu brauchen wir die folgenden Module:

    • Views
    • Lightbox

    Nachdem die Module installiert sind, fügen wir zuerst einmal eine neue Ansicht (views) hinzu.

    Wir geben der Views einen entsprechenden Namen "galerie" und eine kleine Beschreibung. Besonders, wenn man viele Views hat, kann diese noch recht nützlich sein. Zusätzlich können wir die Views taggen -> ist wiederum nützlich, wenn man viele Views hat.

    Jetzt kommen wir auf den Views Builder. Views ist eigentlich lediglich ein Tool, um SQL Abfragen zu bauen, sozusagen SQL für Jedermann (und Frau). Es gibt diverse Bereiche und Einstellungsmöglichkeiten. Für uns relevant ist lediglich "Fields" und "Filter". In Fields können wir angeben, welche Felder des Nodes dargestellt werden sollen. Diese Felder haben wir ja vorher mittels CCK angelegt. Beim Filter geben wir an, welche Nodes rausgefiltert werden.

    Wir fügen also ein Feld zum Anzeigen hinzu -> logischerweise wollen wir ja das Bild anzeigen. Wir wählen also field_bild aus. Beim Weiterklicken haben wir noch ein paar Konfigurationsmöglichkeiten, nämlich wie das Bild dargestellt werden soll.

    Da wir ja Lightbox aktiviert haben, gibt es noch ein paar zusätzliche Möglichkeiten. Wir wählen also hier einfach die entsprechende Option aus -> alles hier kann auch wieder geändert werden.

    Jetzt müssen wir noch einen Filter angeben, da wir ja nur die Nodes anzeigen wollen, welche auch ein Bild enthalten.

    So, jetzt haben wir unsere Standardabfrage gebaut. Die ist wie gesagt nur Standard. Jetzt müssen wir noch definieren, wie die Views angezeigt werden soll, als Seite, als Block oder gar in einem Panels. Wir klicken also auf "add Display".

    Jetzt hat aber unsere Seite noch keinen Pfad. Wir definieren also noch einen Pfad unter welcher unsere Galerie erreichbar sein soll.

    Und zuletzt, aber am Wichtigsten: Das ganze Speichern. Es kommt immer wieder vor, dass dieser Schritt vergessen wird. Ist einfach ein wenig eine gewohnheitssache. Aber vom Office sollte man das ja eigentlich kennen, dass man fleissig speichern sollte.

    Jetzt haben wir eigentlich bereits eine hübsche Galerie. Die Anforderung war jedoch, dass sie nach Datum gruppiert werden soll. Kein Problem. Dafür fügen wir noch ein weiteres Feld hinzu, nämlich das Post Date (Beitragsdatum). Wir wollen das Feld jedoch nicht anzeigen, daher setzen wir die Checkbox "Exclude from display" und geben aber trotzdem das Format an, wie es dargestellt werden sollte.

    Fast geschafft. Noch ein letzter Schritt. Beim Style klicken wir auf das kleine Zahnrad für die Einstellungen und geben an, dass wir unsere Nodes nach dem Post date gruppieren wollen. That's it.

    Jetzt haben wir eigentlich eine ziemlich hübsche Galerie. Sie sieht zwar in Garland noch nicht ganz so elegant aus, aber das lässt sich eigentlich relativ einfach mit ein wenig CSS nachbessern und aufhübschen.

  • Advanced Theming in Drupal

    Drupal ist ja bekanntlich sehr flexibel. Die Flexibilität hat jedoch auch ihren Preis. Will man fortgeschrittene Theme Arbeiten machen, wird man nicht um PHP kommen. Wenigstens die Fähigkeit PHP zu lesen ist ein Muss. Wie funktioniert das Drupal Theme System? Und wie geht man vor? In einem Drupal Modul werden Theme Funktionen meistens wie folgt aufgerufen:

    theme('image','sites/default/files/myimage.jpg');

    Diese Funktion hat als Rückgabewert <img src='sites/default/files/myimage.jpg' />. Was soll jetzt daran besser sein, als gerade direkt den img Tag zu schreiben, was unter Umständen einfacher und schneller wäre? Ganz einfach: Ich kann in meinem Template die Themefunktion theme_image überschreiben. Warum möchte ich das machen? Weil ich z.B. allen Bildern automatisch eine Klasse mitgeben möchte. Theme_image Funktion überschreiben Wenn ich nach http://api.drupal.org gehe und dort nach theme_image suche, dann bekomme ich die Funktion zurück. Die Funktion sieht wie folgt aus:

    function theme_image($path, $alt = '', $title = '', $attributes = NULL, $getsize = TRUE) {
    if (!$getsize || (is_file($path) && (list($width, $height, $type, $image_attributes) = @getimagesize($path)))) {
    $attributes = drupal_attributes($attributes);
    $url = (url($path) == $path) ? $path : (base_path() . $path);
    return ''. check_plain($alt) .'';
    }
    }

    Jedes Bild, das generiert wird, wird also über diese Funktion erstellt (sofern die Module richtig programmiert sind). Wenn ich jetzt also jedem img Tag eine spezielle Klasse hinzufügen möchte, dann könnte ich:

    1. Die Theme_image Funktion aufbohren und die Sachen gleich dort reinschreiben. HALT! Nein. Dann müsste ich das, wenn ich das nächste Mal Drupal aktualisiere wieder machen, also Finger weg.
    2. Ich überschreibe diese Theme Funktion in meinem template.php File im Theme.

    Das Vorgehen für das Überschreiben ist eigentlich denkbar einfach: Einfach die Originalfunktion kopieren und in das eigene template.php einfügen und dazu die Funktion von theme_image in myTheme_image (wobei myTheme der Name des eigenen Themes ist) umbenennen und dann in dieser Funktion die entsprechenden Änderungen vornehmen:

    <!–?php
    function myTheme_image($path, $alt = '', $title = '', $attributes = NULL, $getsize = TRUE) {
    if (!$getsize || (is_file($path) && (list($width, $height, $type, $image_attributes) = @getimagesize($path)))) {
    $attributes['class'] .= ' myClass'; //hier wird die Klasse jedem Bild angefügt.
    $attributes = drupal_attributes($attributes);
    $url = (url($path) == $path) ? $path : (base_path() . $path);
    return ''. check_plain($alt) .'';
    }
    }
    ?>

    Es stellt sich dann halt einfach die Frage, welche Theme Funktionen aufgerufen werden. Dazu ist der Theme Developper extrem nützlich!! Folgende Theme Funktionen werden häufig verwendet:

    • theme_image – Bilder
    • theme_item_list – Listen
    • theme_table – Tabellen
    • theme_breadcrumb

    Es gibt noch seeeeehr viel mehr solcher Funktionen.

  • Multisite mit Drupal aufsetzen

    Was ist überhaupt eine Multisite? Dafür müssen wir kurz den Aufbau einer Drupalseite anschauen:

    1. Es gibt Code. Dazu gehört Drupal Core, die Themes, die Module und die Dateien. Diese Dateien sind für alle Drupalsites identisch.
    2. Es gibt die Datenbank. Dort sind die ganzen Informationen bezüglich Inhalt und Konfiguration drin. Diese Daten sind für jede Drupalsite unterschiedlich.

    Wenn eine Seite aktualisiert wird, dann werden dazu die neuen Dateien auf den Server geladen und dann auf der Drupalsite update.php ausgeführt. Falls updates vorhanden sind, dann werden die entsprechenden Veränderungen an der Datenbank vorgenommen. Hat man also 3 Drupalsites und führt diese eigenständig, dann hat man eine grosse Redundanz, denn die Codebasis ist überall vollkommen identisch. Daher die Multisite:
    Viele Drupalsites greifen auf die gleiche Codebasis zurück, haben jedoch jede eine eigene Datenbank und ein eigenes Files Verzeichnis. Dadurch ist die Wartung einfacher.

    Voraussetzungen für eine Multisite
    Damit eine Multisite überhaupt erst möglich ist, müssen gewisse Voraussetzungen vorhanden sein:

    • Es muss möglich sein, mehrere Domains auf das gleiche Verzeichnis zeigen zu lassen. Das heisst: www.site1.ch und www.site2.ch zeigen auf die gleichen Dateien. Das kann z.B. über VirtualHosts gelöst werden. Eine Weiterleitung reicht nicht aus! Nicht alle Hoster bieten diese Möglichkeit an. Bei Hostorama musste ich explizit nachfragen, danach hatte ich jedoch die Option 🙂
    • Das ist es dann eigentlich auch schon.

    Multisite installieren

    1. Vor dem Installieren sind ein paar kleine Schritte notwendig:
    2. Den Ordner sites/site1.ch erstellen
    3. Den Ordner sites/site1.ch/files erstellen
    4. im Ordner sites/default gibt es ein File (default.settings.php), dieses in den Ordner sites/sites1.ch kopieren und in settings.php umbenennen.
    5. site1.ch besuchen und Drupal installieren.
    6. Auf site1.ch, unter settings > filesystem den Pfad entsprechend einstellen, so dass er nicht mehr auf default… zeigt sondern auf sites/site1.ch/files zeigt.
    7. Für die zweite Seite (und jede weitere) kann jetzt genau gleich vorgegangen werden.

    Spezialitäten einer Multisite
    Eine Multisite hat einige kleine Spezialitäten:

    • Module, welche unter sites/all/modules sind, sind für alle Sites sichtbar. Das heisst, hier kommen die Module hin, welche für alle Sites verwendet werden. Analog dazu sites/all/themes
    • Module und Themes aus sites/site1.ch/modules sind ausschliesslich für die site1 sichtbar
    • Beim update zu beachten!!! Auf jeder Site der Multisite MUSS update.php ausgeführt werden, ansonsten kann es unter Umständen manchmal zu kuriosen Fehlermeldungen kommen.

    That's it. Ist eigentlich also trivial, vorausgesetzt, eine Multisite ist überhaupt möglich.

  • Lehren aus einem Drupalprojekt

    Ich bin wohl noch verhältnismässig Jung in der ganzen Projektwelt. Seit Mai 2009 bin ich jetzt bei der Previon als Drupal Software Engineer tätig. Und habe so einige Erfahrungen gesammelt, besonders im Rückblick auf das jüngste (fast abgeschlossene Projekt). Hier eine kleine Sammlung mit Erfahrungen, welche ich gemahct habe, die ich im nächsten Projekt garantiert NICHT mehr so machen werde:

    • E-mail Verkehr. Es gibt einfach schlauere Sachen, als E-mail. Change Requests per E-mail führen -> extrem schlecht!! Nachträgliche Nachvollziehbarkeit ist praktisch nicht möglich. ZWINGEND von Anfang an dem Kunden ein Tool aufzwingen, an welches er sich halten muss (irgend ein Bugtracker oder irgend sonst ein System), welches für beide Parteien einsehbar ist und welches immer klar darlegt, was noch offen ist (ist einfacher gesagt als getan in der Praxis).
    • Datenmigration: Diese ist definitiv nicht zu unterschätzen! Frühzeitig durchführen, damit der Kunde diese prüfen kann und gegebenfalls Fehler finden kann, damit das Script verbessert werden kann. Mit Drupal und seiner node_save Methode ist es relativ einfach, aber diese Migrationssachen haben halt einfach ihre Tücken.
    • Kunden zu Meilensteinen verpflichten. Vom Entwickler wird eigentlich immer erwartet, dass alles Termingerecht fertig ist, der Kunde kann ruhig mal ein paar Tage Verspätung haben -> nein! Nur wie verpflichtet man den Kunden dazu… klaro, für den Endtermin ist das einfach, aber für "kleine" Zwischenmeilensteine ist es nicht ganz so einfach. Wahrscheinlich müsste man visuell irgendwo festhalten, wann Meilensteine erreicht wurden, damit der Kunde auch sieht, wenn er einen verpasst hat und dadurch der Entwickler einen anderen Meilenstein nicht mehr einhalten kann.
    • Grosszügig schätzen. Es ist und bleibt oftmals eine sehr vage Schätzung, aber es gibt einfach Dinge, welche ein Drupalprojekt komplexer und somit aufwändiger gestalten, dazu gehören unter anderem:

      • Mehrsprachigkeit
      • Shopfunktionen
      • Multsites/Single Sign-on
    • Jeder einzelne dieser Punkte erhöht die Kosten pauschal um einen gewissen Prozentsatz, da sie einfach von Natur aus Probleme mit sich bringen: Mehrsprachigkeit: Fehlende Übersetzungen und Module, welche nicht mit der Mehrsprachigkeit zurechtkommen usw.

    Würde ich wieder machen
    Natürlich gibt es auch einige gute Dinge, welche ich beim nächsten Projekt wiederholen werde:

    • Sehr früh den Kunden bereits auf einen Prototypen loslassen und anhand des Prototypen weitere Funktionen entwickeln. Spekulationen im luftleeren Raum bringen nichts.
    • Drupal für Projekte einsetzen
    • Den Kunden regelmässig über Budget informieren. Optimal wäre natürlich, wenn dies gleich in den Bugtracker/ die Todoliste integriert wäre, damit zu jederzeit klar ist, wieviel Geld verbraucht wurde, und was es noch zu machen gibt.

    Ehrlich gesagt… so online Projekte sind nicht ganz trivial und von der Uni aus lernt man es eigentlich anders, aber der Zeitdruck ist enorm gross und daher ist es auch nicht ganz so einfach hier den "Lehrbuchweg" zu finden. Das war ja hoffentlich nicht mein letztes Projekt und so bleibt doch noch ein wenig Zeit zur Verbesserung 🙂

  • Nicht alles ist Gold was glänzt in Drupal

    Open Source mag sehr viele Vorteile haben, aber es gibt halt manchmal auch ein paar Nachteile. So habe ich in den letzten Tagen eine Multisite aufgesetzt. Diese ist insofern ein wenig speziell, als dass alle Sites einen gemeinsamen Benutzerstamm haben. Das lässt sich in Drupal sehr einfach machen, führt jedoch dazu, dass die Datenbank ziemlich aufgebläht wird (520 Tabellen in einer Datenbank). Zusätzliche Schwierigkeiten (eigentlich war das Vorherige keine wirkliche Schwierigkeit) war die Mehrsprachigkeit. Viele Modul werden von Amerikanern geschrieben… Mehrsprachigkeit ist dort nicht so entscheidend, wie dies hier in der Schweiz der Fall ist, daher gibt es immer wieder Konflikte mit Modulen, welche nicht für Mehrsprachigkeit ausgelegt sind.

    Single Sign-on – Mit Tücken
    Für das Szenario (gemeinsame Usertabelle) gibt es eigentlich ein hübsches kleines Modul, welches als stabile Version vorhanden ist. Single Sign-on bedeutet, dass sich der User auf einer Site einloggen kann und dann automatisch auf allen anderen Sites eingeloggt bleibt… eigentlich ziemlich praktisch aber funktioniert leider nicht ohne weiteres, da Drupal jeweils ein Cookie für den Login anlegen muss und dies dann natürlich für alle Domains angelegt werden muss.

    Modul installiert, … schaut eigentlich alles gut aus. Doch dann: Etwas scheint nicht zu klappen. Und es klappt definitiv nicht. Cache 100x leeren, cron laufen lassen… alles mögliche, aber nichts scheint zu klappen 🙁
    Ein Blick in die Issue Queue des Moduls… scheint aktiv zu sein, aber wird leider nicht gepflegt. Immerhin 1000+ Installationen und eine stabile Version, man könnte meinen, dass das Modul sicher funktionieren sollte… tut es aber definitiv nicht. Ich finde einen ersten fix in der Issue Queue… scheint eigentlich genau das Problem zu beheben, tut es aber nicht 🙁 Verzweiflung pur. Wie weiter? Ein eigenes Modul entwickeln? Nach einer richtigen Single Sign-on Lösung umsehen? Vielleicht gibts einen Konflikt mit einem anderen Modul? Fragen über Fragen… und vor allem Ratlosigkeit.

    Nach 2-3 Stunden wahlloser Fehlersuche reisse ich mich nochmals zusammen und fange von vorne an mit Debuggen und installiere mir dazu eine lokale Multisite mit gemeinsamer Usertabelle. Single sign-on funktioniert wunderbar. Kein Problem, keine Fehler. Debugge mit xDebug, um die Logik zu verstehen, welche relativ kompliziert ist! Debugger hilft nicht wirklich weiter.

    Zu guter letzt! Debuggen auf die traditionalle Art: print $vars. Langsam arbeite ich mich vor. Das geht, das geht, in diese Schleife geht er auch rein, hier auch gut…. o? Was ist hier los?

    <!–?php
    $op = isset($_POST['op']) ? $_POST['op'] : '';
    if (function_exists('t') ? $op == t('Log in') : $op == 'Log in') {
    // User is in the middle of logging in. Can't do the master/slave
    // checking yet because the login process happens after this module
    // called. Set a flag telling us to do the master/slave checking
    // once the login process is done.
    $_SESSION['singlesignon_just_loggged_in'] = true;
    return;
    }
    ?>
    Scheint eigentlich auf den ersten Anblick alles ok zu sein, ist es aber nicht. Die Funktion t kann gar nicht aufgerufen werden, da diese noch gar nicht geladen ist. Daher wird einfach $op mit 'Log in' vergleichen (das ist der default Value des Login Knopfes). Aber was passiert bei einer Multisite??? Ha. Ja genau, dort ist natürlich der Login Knopf Einloggen oder etwas ähnliches. Tja, das war es dann auch schon gewesen. Diesen Fehler behoben, Cookies gelöscht und schon funktioniert es einwandfrei 🙂

    Fazit
    Was lernen wir daraus? Vieles:

    • Wenn auf drupal.org ein Modul als stable markiert ist, heisst das noch lange nicht, dass es auch einfach so ohne nichts funktioniert! Es mag immer noch Situationen geben, die vom Maintainer nie ausprobiert wurden. Zudem kann ein Modul Maintainer jederzeit eine Version erstellen. Es gibt keine Qualitätskontrolle in dem Sinn, bzw. Qualitätskontrolle passiert durch die Community, aber das kann halt manchmal dauern… Entweder man setzt das Modul nicht ein, oder man muss halt selber ran an den Speck.
    • Mehrsprachigkeit erhöht die Komplexität und dadurch den Aufwand massiv! Es gibt wahrscheinlich immer irgendwo ein unerwartetes Problem, bzw. eine Herausforderung 😉

    Zum Glück konnte das Problem noch behoben werden, bevor ich schlafen gegangen bin… ich hätte glaube ich sonst noch Alpträume gehabt und die ganze Zeit nach einer Lösung gesucht. Ich habe wirklich schon an mir gezweifelt… aber, es lebe Drupal. Man lernt schlussendlich jeden Tag ein paar neue Sachen und Lernen ist ja nicht gratis… leider.