Kategorie: Uncategorized

Bisher war mir nicht genau klar, was die Option Relations (Beziehungen) eigentlich genau macht, da ich es auch nie wirklich gebraucht habe, aber irgendeinmal da braucht man es einfach. Nun, was macht Relations eigentlich?

Kurz gesagt, es macht einfach einen Join. Was ist ein Join 😉 ? Sagen wir mal wir gehen nach folgenden Schritten vor:

1. Neue View erstellen. Als Viewtyp wählen wir "Node" aus. Das sagt soviel, dass die Tabelle node als Grundlage genommen wird. Wird der Viewtype Users gewählt, so würde die users Tabelle als Grundlage dienen.
2. Wir erstellen ganz normal eine View, fügen das Feld name und Datum hinzu und vielleicht noch einen Filter. Soweit so gut. Es funktioniert alles.
3. Die Views listet alle Dateien auf. Was jedoch wenn diese Dateien von verschiedenen Benutzern verändert werden können. Es würde nicht viel Sinn machen, wenn wir immer den original Benutzer auflisten würden. Es würde viel mehr Sinn machen, wenn dazu der Name des Benutzers, welcher die Revision erstellt hat, angezeigt werden wird. Aber wie?? -> Beziehungen!
4. Die Information welche dazu benötigt wird, befindet sich in der Tabelle node_revisions. Über Beziehungen sagen wir jetzt also, dass er nicht nur die Tabelle node, sondern auch noch die Tabelle node_revisions als Informationsquelle anzapfen soll. Schwups die Wups und schon ist es nicht mehr der Name des Ursprünglichen Autors, sondern der Name des Revisionserstellers. Die uid, welche in der node_revisions abgelegt ist, überschreibt also die uid aus der node Tabelle für diese Ausgabe.

Ist eigentlich ziemlich einfach. Einige Joins sind z.T. bereits vorhanden, eben, dass man vom node auf die Benutzerinformationen zugreiffen kann. Aber für komplexere Sachen braucht man dann eben die Beziehungen.

Hoffe, es hilft mal jemandem.

Der hook_user kann einem ziemlich viel Bauchweh machen. Eigentlich ist es ja ziemlich trivial, aber anscheinend doch nicht ganz 😉

Der hook_user wird vom Modul user aufgerufen. Er ermöglicht es einem anderen Modul das global $user Objekt zu verändern. Es gibt jedoch dabei ein paar … naja Probleme:

• Der hook_user() wird zu spät aufgerufen. Zwar wird der Benutzer und seine originalen Daten relativ früh geladen (dazu gehören uid, time und alles war auch sonst noch in der users Tabelle zu finden ist). Über den hook_user werden dann weitere Informationen hinzugefügt. Dies passiert jedoch manchmal zu spät!

Dazu habe ich eigentlich zwei Lösungsansätze gefunden:

1. In der users Tabelle gibt es eine Spalte data. In dieser lassen sich beliebige Informationen speichern. Dass lässt sich relativ einfach machen: user_save. Das Problem hier ist jedoch, dass die Daten dann halt eben serialisiert werden und wenn man etwas damit machen will, so ist das nicht ganz so einfach.
2. Als zweite Möglichkeit wäre dann halt eben den hook_user zu verwenden. Dann lassen sich die Daten in einer beliebigen Datenstruktur abspeichern. Über hook_user können sie dem $user objekt hinzugefügt werden und falls man die Daten ein wenig früher laden will, muss man den hook einfach manuell aufrufen. Mit einer if Abfrage schaue ich, ob die Daten geladen sind und falls nicht dann rufe ich hook_user auf.

Das Ganze mag vielleicht nicht sehr logisch erscheinen… aber wer sich mal intensiv mit dem hook System befasst wird auf solche Probleme stossen. Ich bin immer noch auf der Suche nach einer guten Dokumentation, welche genau beschreibt, wie und wann welche Hooks aufgerufen werden.

Imagecache und Imagefield wurden in den letzten paar wochen sehr vernachlässigt! Dabei zählen diese Module (und besonders imagecache) zu fast-core-modulen. Imagecache ist auf auf gut 5000 Drupal 6 Sites installiert und dabei ist es gerade mal eine Betaversion! Noch schlimmer mit Imagefield. Dort gibt es erst eine Alphaversion.

Es wird Zeit, dass dort mal jemand die Zügel in die Hand nimmt. Freiwillige vor!

Lullabot bekommt Konkurrenz. Bisher war Lullabot das einzige Podcast, welches sich ausschliesslich mit Drupal befasst hat. Neu dazu kommt Drupalnews. Mal gespannt, wie lange, das auf dem Markt sein wird…

Lullabot Podcast 65 ist sehr empfehlenswert. Es ist ein Interview mit Dries. Dieser spricht über Acquia, Mollom und Drupal 7. Dries meinte dort zudem, dass pro Tag 500 Drupal 6 Sites online gehen. Wau. Das wären also pro Woche 3500 neue Sites!

Drupal hat bald die Weltherrschaft und für Drupalentwickler gibt es noch viel Arbeit 🙂

Was es nicht alles gibt. Ein Dienst, welcher Photoshop PSD Dateien in ein Drupal Theme umwandelt. Ich habe es noch nicht ausprobiert, da ich hier an der Uni kein Fotoshop zur Hand habe. Würde mich interessieren, wie der Code ausschaut und vor allem, wie komplexe Sachen man machen kann.

Wäre auf jeden Fall ein sehr interessanter Anfang, um ein Theme zu erstellen.

Hier gehts zum Dienst.

Ich arbeite immer noch fleissig an meiner Masterarbeit. Dafür entsteht ein Co-Browsing System. Grundlage dafür ist, dass ein unangemeldeter Gast und ein registrierter Agent zusammen in einer Session arbeiten können.

1. Versuch

War mittels $_SESSION und dann das ganze in 2 Tabellen führen:

• cobrowser_session
• cobrowser_users

Dem Endbenutzer muss dann schlussendlich auf der Seite klar gemacht werden, dass er in einer Session ist. Denkste mit der $_SESSION! Absolut katastrophal. Ich weiss nicht, ob das am Drupal lag oder einfach so, aber das lief manchmal und manchmal auch nicht. Mein Fazit: $_SESSION nicht verwenden!

2. Versuch

Alles über die Datenbank steuern und jedes mal, wenn ein Request gemacht wird mit der browser_session (session_id()) vergleichen. Läuft viel stabilder, aber irgendwie ist das viel Overhead.

3. Versuch

Endlich die erläuchtung: Einen temporären Benutzer erstellen. Über hook_user einfach die zusätzlichen Informationen ans Userobjekt anhängen und schon kann man wie gewohtn auf $user zugreifen, auch wenn der Benutzer nicht angemeldet ist. Der Benutzer wird dann nach einer gewissen Zeit automatisch wieder gelöscht.

Es kann so einfach sein und ich kann auch mal getrost fast die Hälfte von meinem Code wieder löschen. Tja, manchmal muss man einfach durch diesen Prozess gehen, um etwas Gutes zu lernen.

Fazit

Drupal rocks!

Es scheint gerade voll inn zu sein. Wieder mal eine Vergleichsliste, Drupal, Joomla, WordPress, welche als PDF vorhanden ist. Ich hoffe doch, dass damit die unzähligen Fragen "Welches CMS ist für mich am Besten geeignet?" wirklich beantwortet werden kann.

Für noch mehr Artikel zu dem Thema einfach mal hier im Blog unter "Similar Entries" schauen. Da gibt es jede Menge dazu.

Sind 16 h Drupal zu viel für einen Tag? 6 h bis 22 h… vielleicht nicht etwas für jeden Tag, aber da ich im Moment an zu vielen Projekten gleichzeit arbeite ist das die logische Folge.

Wenn man die .tpl Dateien bearbeitet ist nicht immer klar, was für Variablen man zur Verfügung hat. PHP stellt hier eine sehr nützliche Funktion zur Verfügung: get_defined_vars() Im Code würde das dann konkret so aussehen:

<!–?php
dsm(get_defined_vars());
?>

Setzt natürlich voraus, dass das Devel Modul eingeschalten ist. Jetzt kommt eine schöne Liste mit allen Variablen, sehr nützlich 😉 -> Auch für Themer!