Das Rules Modul ist ja vielen Drupalern wahrscheinlich bekannt (wenn nicht, hier gibt’s die offizielle Dokumentation). Dieses tolle Modul erlaubt es Regeln zu definieren die aus Events (Ereignissen), Conditions (Bedingungen) und Actions (Aktionen) bestehen. Eine Regel wird aufgerufen sobald eines der definierten Events auftritt. Wenn dann die angegeben Conditions zutreffen werden die Actions ausgeführt. Viele Contrib-Module bieten eine Rules-Integration und stellen eigene Events / Conditions / Actions zur Verfügung. Diese Erweiterbarkeit und die große Verbreitung machen Rules zu einem der mächtigsten Drupal Module.
In diesem Tutorial möchte ich allerdings nicht näher auf die Grundfunktionalität von Rules eingehen. Denn Rules bietet zwei weitere tolle Features, die ich anfangs nicht beachtet und damit deutlich unterschätzt habe: Rules Compontents und den Rules Scheduler.
Rules Components: Wiederverwendbare Schnipsel
Die Rules Components sind wiederverwendbare “Rules-Schnipsel”, sprich Teile von Rules, ganze Rules oder gar eine Sammlung mehrerer Rules. Mithilfe dieser Components kann man z.B. häufig verwendete Abläufe auslagern und in verschiedenen Rules wiederverwenden. Die Vorteile eines solchen Verfahrens liegen dabei klar auf der Hand:
- Einfache Wartbarkeit: Änderungen an sich wiederholenden Rules-Elementen müssen nur an einer einzigen Stelle vorgenommen werden (DRY-Prinzip).
- Gute Lesbarkeit: Durch die Kapselung von Funktionalität in Components werden komplexe Rules besser lesbar (wichtig ist hierbei den Components aussagekräftige Namen zu geben!)
Components funktionieren im Prinzip wie Funktionen bzw. Methoden in der Programmierung: man bekommt Argumente übergeben, macht dann etwas damit und am Ende gibt man ein Ergebnis zurück.
Einfaches Beispiel - Node erstellen und mit Inhat befüllen
Als kleines Beispiel zum Einstieg erstellen wir ein “Action set”, welches uns einfach eine Node erstellen und die Felder mit Inhalt befüllen soll. Dazu gehen wir im Admin-Bereich zu den Rules und dort zu dem Reiter “Components”. Wenn wir dann auf “Add new component” klicken müssen wir als erstes auswählen was für einen Component Typ wir anlegen wollen. Wir wählen hierfür “Action set”, da wir lediglich eine Abfolge von Actions brauchen.
Im nächsten Schritt müssen wir einen (aussagekräftigen!) Namen für den Component angeben. Wir wollen in dem Beispiel einen Node vom Typ “Article” erstellen also nennen wir unseren Component doch einfach mal “Create Article”. Im gleichen Schritt kann man nun auch schon festlegen welche Variablen (Argumente und Rückgabewerte) es geben soll. Jede Variable hat einen Datentyp, ein Label, einen Maschinennamen und einen Verwendungstyp: also, ob es ein Argument (Parameter) oder ein Rückgabewert (Provided) ist. Für unser Beispiel definieren wir drei Argumente (siehe Screenshot), wobei Title und Body vom Typ “Text” sind und Author vom Typ “User” ist. Unser Rückgabewert wird die erstellte Node sein.
Das wäre es auch mit diesem Schritt, wir klicken auf “Continue” und kommen zum Herzstück des Components, dem Erstellen der eigentlichen Actions. Das Interface ist dabei genau so aufgebaut wie bei einer normalen Rule, mit der Ausnahme dass wir hier eben nur den “Action” Teil haben.
Dann fügen wir doch mal die erste Action hinzu, und zwar “Create a new entity”. Wir wollen hier eine Node Entity erstellen und der Content Type soll Article sein. Nun wählen wir mithilfe des Data selectors Title und Author des Article. Dafür benutzen wir die von uns zuvor angelegten Variablen, welche uns im Data selector angezeigt werden. Wichtig hierbei ist noch, sich den Namen der zurückgegebenen Variable (Provided variables) zu merken. Jetzt noch das Ganze abspeichern mit einem Klick auf “Save”.
Der “Data selector” hilft dabei, Variablen auszuwählen. Das ist wirklich sehr praktisch, da man auf diese Weise sofort sehen kann welche Variablen im aktuellen Kontext zur Verfügung stehen. Außerdem bietet der Data selector nur Variablen an, dessen Datentyp dem von Rules geforderten Datentyp entspricht. Man kann sich sogar durch komplexere Objekte hangeln indem man auf ein grau hinterlegtes Element (z.B. site:...) klickt und dann eine Liste der Unter-Eemente dieses Objektes angezeigt bekommt.
Was jetzt noch fehlt ist das Ausfüllen des Body-Felds. Dazu fügen wir die Action “Set a data value” hinzu. Dort gehen wir im Data selector dann auf die eben erstellte Node (grau hinterlegt) dann auf das Body Feld (ebenfalls grau hinterlegt) und wählen dort dann die “value” Variable aus. In dem Textfeld sollte dann so was wie “entity-created:body:value” stehen. Das bedeutet einfach, dass wir hier den Wert des Body-Felds unserer erstellten Node festlegen wollen. Dann gehen wir auf “Continue” und können nun das Body Feld befüllen. Man könnte hier jetzt manuell einen Text eingeben oder eben wieder eine Variable verwenden. Wir wollen in dem Fall unsere “Body” Variable verwenden und switchen deswegen zum Data selector, wo wir die “Body” Variable auswählen. Das ganze wieder abspeichern und fertig ist unser Component.
Den Component kann man nun in einer Rule als Action hinzufügen oder aber per “Rules Scheduler” zeitverzögert ausführen lassen. Wie der Rules Scheduler funktioniert wollen wir uns ebenfalls an einem kleinen Beispiel veranschaulichen.
“We miss you” E-Mails
Der “Rules Scheduler” bietet die Möglichkeit einen Component zeitverzögert auszuführen. Wir wollen den Scheduler nun benutzen um eine “We miss you” bzw. Reminder-Mail automatisiert zu verschicken. Das Prinzip sollte ja aus so manch einer Communtiy oder von Online-Shops bekannt sein: Wenn ein User lange nicht mehr auf einer Seite aktiv war (spich eingeloggt), bekommt er eine Mail, die ihn daran erinnert, die Seite mal wieder zu besuchen. Aber wie realisiert man das mit Rules?
Zuerst erstellen wir uns einen Component, der die E-Mail verschickt. Wir nehmen dafür ein Action Set welches als Parameter einen User erwartet (der User an den die Mail gehen soll) und bestücken es mit der “Send mail” action.
Die “Send mail” Action befüllen wir dann einfach mit Text und den Daten des Users. Fertig ist unser Component.
Jetzt kommt der eigentlich Trick bei der ganzen Sache. Wir legen einfach fest, dass die Mail X Tage nachdem sich der User eingeloggt hat verschickt wird. Das schöne bei dem Scheduler ist nun, dass man jedem “Task” (ein auszuführender Component) einen Identifier geben kann. Existiert bereits ein Task mit dem gleichen Identifier, wird dieser einfach überschrieben. Wenn wir nun z.B. die User ID als Identifier für den Task benutzen, wird dieser jedes mal überschrieben, wenn sich der User erneut einloggt und die Ausführung wird wieder X Tage ausgesetzt. Loggt er sich innerhalb von X Tagen nicht ein, wird die Mail also verschickt.
Um das Ganze nun umzusetzen legen wir eine normale Rule an, welche auf den Event “User has logged in” reagiert. Als Action fügen wir “Schedule component evaluation” hinzu und wählen den zuvor angelegten Component aus. Bei “Scheduled evaluation date” geben wir nun den Zeitraum als relatives PHP-Zeitformat an (http://de2.php.net/manual/de/datetime.formats.relative.php). Wollen wir dem User z.B. nach 30 Tagen die Mail zukommen lassen, geben wir “+30 days” ein. Als Identifier geben wir die User ID an und als User übergeben wir dem Component einfach das User Objekt “account (logged in user)”. Und fertig ist die automatische “We miss you”-Mail.
Übrigens: Wartende Tasks kann man sich im Rules-Backend unter dem “Schedule” Tab anschauen.
Wöchentliche Reports
Zum Schluss noch eine kleine Denkaufgabe um sicherzustellen, dass es auch alle verstanden haben ;-)
Nehmen wir mal an wir wollen automatisch einen wöchentlichen Report (einen beliebigen Text) per Mail verschicken. Wie würde man das mit Rules, Components und dem Scheduler umsetzen?
Lösungsvorschläge dürfen gerne in den Kommentaren abgegeben werden, meine Lösung werde ich im zweiten Teil der Rules-Serie vorstellen.
Kommentar hinzufügen