Pimcore Tutorials

Ich finde, es gibt derzeit immer noch viel zu wenige Tutorials zu Pimcore, welches es mittlerweile schon in Version 4 gibt. Dabei handelt es sich hierbei für mich immer noch um das eleganteste CMS auf PHP-Basis. Auch wenn das dahinter liegende Zend Framework immer noch in Version 1 dahin vegetiert, eine Portierung auf Version 2 ist einfach zu aufwendig und führt auch am Ziel vorbei, dafür wird mittlerweile für das Backend ExtJS 6 verwendet.

Ich muss mich seit einiger Zeit hauptsächlich mit Drupal und WordPress plagen. Nichts gegen diese beiden Systeme. Sie haben beide ihre Berechtigung, nur hierfür etwas zu Entwickeln macht keinen Spaß.

In letzter Zeit erhalte ich aber wieder vermehrt Anfragen für Pimcore und muss häufiger wieder Systeme hierfür aufsetzen. Und vor 2 Jahren wollte ich schon mal eine Tutorial Reihe zum Aufsetzen eines guten Basis-Systems schreiben. Und gerade juckt es mich wieder in den Fingern. Vielleicht hauche ich dem Block damit auch wieder ein wenig Leben ein.

Einen schönen Abend noch.

Double Opt-In ohne Datenbank

Wenn man von Nutzern Daten in irgendeiner Art erhebt, in der Regel via eines Online-Formulars und man Aufgrund des angestossenen Vorgangs reagieren möchte, zum Beispiel dem Versenden von Newslettern, kommt man um ein sogenanntes Double Opt-In nicht drum herum, wenn man sich nicht mit Schadensersatzansprüchen des Nutzers herumschlagen möchte, weil dieser vielleicht unerwünschte E-Mails oder Anrufe erhalten hat.

Wir haben bisher immer alle Benutzerdaten bei diesem Prozess in Datenbanken gesichert, was natürlich bedeutet, dass man den Nutzer zusätzlich auf Datenschutz-Bestimmungen hinweisen muss. Je nach Formulierungen ein weiterer juristischer Knackpunkt. Auf der technischen Seite wird man gezwungen eine Datenbank aufzusetzen, diese Daten zu pflegen und gegebenenfalls per definiertem Regelwerk den Datenbestand wieder zu bereinigen. Wie man sieht, im laufe der Zeit nicht wenig Aufwand, den man sich damit einfängt.

Ich muss zugegeben, es gibt Szenarien, wo man nicht darum herum kommt, die oben genannten Punkte alle zu berücksichtigen, aber wir hatten letztens den Fall, dass Daten via eines Bestellformulars für Probefahrten direkt an ein CRM (Customer-Relationship-Management) weitergeleitet werden sollen und wir die Datenvorhaltung lediglich für das Double Opt-In benötigen. Da kam ein ehemaliger Kollege von mir auf die Idee, doch alles via E-Mail inkl. der Daten per Get-Parameter zu übergeben. Da in diesem Fall sämtliche Daten in dem Link für das Double Opt-In innerhalb der E-Mail sind, benötigen wir hier keine weitere Instanz, um die Daten zu speichern.

Damit nicht jeder sofort erkennt, was da versendet wird, sollte man den Wert des Get-Parameters maskieren, zum Beispiel mit der PHP-Funktion base64_encode. Noch besser wäre es, das ganze zu verschlüsseln, wobei sich hier in PHP die mcrypt-Library eignet. Aus dem ganzen könnte dann folgende Klasse entstehen:

Nun braucht man einen passenden String, den man mit der oben aufgeführten Klasse verschlüsseln möchte. Ich fand einen JSON Formatierten String für diesen Zweck ideal, da man ja am Ende die Daten wieder irgendwie nach Keys und Values auflösen möchte. Hier kann man entweder mit entsprechenden Libraries einen JSON String erstellen (JSON Encode), oder, da das Format recht überschaubar ist, den String selbst erstellen.

Ich habe mich für Letzteres entschieden und am Ende sollte das dann so oder ähnlich aussehen. Das Ergebnis wird dann für das Double Opt-In via E-Mail an den User gesendet. Die Daten kommen aus einem vorher ausgefüllten Formular:

Ich habe den String vor allem selbst erstellt, um die Möglichkeit zu haben, die Key-Namen um einiges zu verkürzen, damit der String bei mehreren Feldern nicht zu lang wird. URLs sollten eine länge von ca. 2000 Zeichen nicht übersteigen und da beim Verschlüsseln, trotz des komprimierens die Länge etwas zunimmt, schadet es nicht, dort zu sparen, wo es geht und Sinn macht.

Der User erhält eine E-Mail, wenn er korrekterweise der richtige Empfänger ist, wird er auf den Link klicken und auf der Zielseite wird der verschlüsselte Wert wieder dekodiert, das JSON Objekt wieder in ein Array umgewandelt und die Daten dann weiter verarbeitet, zum Beispiel an ein externes CRM geschickt.

Wie man sieht, kommt man so um eine eigene Datenhaltung herum und spart sich eine Menge Aufwand.