Pimcore Tutorial Teil 1b: Installation via Composer

Heute beschreibe ich eine alternative Installation von Pimcore, nämlich mit Composer.

 

Für Ubuntu geht ihr hier folgendermaßen vor:

Installation von Composer

Schritt 1:

Ihr aktualisiert den Paket-Manager:

Anschließend installiert ihr mit apt-get install folgende Pakete:

Je nach verwendeter PHP Version kann die Zeile auch folgendermaßen aussehen, wobei die statt der 7.2 dort auch 7.1 oder irgendeine andere 7er Versionsnummer stehen kann:

Jetzt habt ihr Voraussetzungen erfüllt, um Composer auf eurem System zu installieren, daher können wir nun mit Schritt 2 fortfahren.

Schritt 2: 

Ihr wechselt in euer Home-Verzeichnis und installiert anschließend Composer mit folgenden zwei Befehlen:

Anschließend könnt ihr die Installation mit einem kleinen Script in der Kommandozeile (Bash) überprüfen, wobei ihr den aktuellen SHA-384 Wert (Installer Signature) von der Composer Seite verwenden und entsprechend im folgenden Skript austauschen solltet:

In der Regel bekommt ihr eine Erfolgsmeldung zurück.

Installer verified 

Ihr könnt Composer auch global auf dem System installieren. Dazu gebt ihr in die Shell folgendes ein:

Das installiert Composer für alle Benutzer auf eurem System unter /usr/local/bin. Ihr erhaltet in etwa folgende Ausgabe nach der Installation:

Jetzt könnt ihr eure Composer Installation testen:

Danach erhaltet ihr folgende Ausgabe:

Nun könnt ihr Composer auf eurem System einsetzen.

Pimcore Tutorial Teil 1a: Installation

Ich überlege schon seit längerem, ein mehrteiliges Pimcore Tutorial zu schreiben. Und jetzt ergibt sich vielleicht der passende Zeitrahmen.

Pimcore ist ein CMS, Rapid Development Tool, Asset Management, PIM und noch einiges mehr, basierend auf PHP. In älteren Versionen (bis Pimcore 4) basierte es noch auf dem Zend Framework (ZF Version 1.x). Seit Pimcore 5 bildet Symfony 2 die Basis, wobei es einen Backport für alte ZF basierte Module bietet. Pimcore wurde ursprünglich von der österreichischen Agentur Elements.at entwickelt. Für die weitere Entwicklung wurde das aber in ein eigenes Unternehmen ausgelagert, die Pimcore GmbH, welche ebenfalls in Salzburg, Österreich ansäßig ist.

Nun aber zum eigentlichen Thema, der Erstellung eines Projekts mit Pimcore (Version 5).

Wie bei jedem neuen Projekt steht zuerst die Installation, und darum soll es heute gehen.

Pimcore benötigt neben einem PHP-fähigen Webspace noch eine MySQL Datenbank (oder MariaDB). Die Datenbank muss das Charset utf8mb4 haben.

Pimcore bietet mehrere Möglichkeiten zur Installation. Zum einen kann man es über die Kommandozeile installieren, sofern man über einen SSH-Zugang verfügt. Dann kann man im entsprechenden Ordner, z. B. /var/www/projekt/web, das Paket herunterladen und entpacken.

Falls man als root angemeldet ist, sollte man, bevor man irgendetwas installiert, zum User mit entsprechenden Zugriffsrechten für das Webverzeichnis wechseln, z. B. www-data.

Wechsel ins Installationsverzeichnis:

Anschließend wird Pimcore herunter geladen und im Verzeichnis entpackt:

Das Pimcore-Archiv kann nun wieder entfernt werden. Es wird nicht länger benötigt.

Falls der Shell-Zugriff nicht ohne weiteres möglich ist, ist es alternativ natürlich auch möglich, sich das Pimcore-Paket unter https://pimcore.com/en/download herunterzuladen, lokal zu entpacken und via FTP auf den Server zu kopieren (beim lokalen Arbeiten natürlich in das Verzeichnis des Webservers). Hierbei ist lediglich zu achten, dass Pimcore außerhalb des Webroot installiert werden darf, da der web Ordner im Pimcore-Paket das eigentliche Webroot-Verzeichnis wird.

Jetzt hat man einige neue Ordner und Dateien in seinem Installationsverzeichnis. Der document root des vhost sollte auf den neu erstellten Ordner web im Installationsverzeichnis zeigen.

Pimcore InstallationsformularJetzt könnt ihr die Seite unter der konfigurieren URL aufrufen, z. B. localhost. Abschließend müsst ihr die Angaben zur Datenbank machen und der Pimcore Installer erledigt den Rest. Ihr könnt bei der Installation noch zwischen verschiedenen Profilen wählen, einem fertigen System mit Beispiel-Daten zu Objekten und Templates (mit oder ohne Twig) oder einem komplett leeren Pimcore-Projekt.

Danach könnt ihr euch unter der URL http://localhost/admin/login mit eurem gewählten Passwort in das Backend einloggen und euch mit den verschiedenen Optionen vertraut machen.

Im nächsten Beitrag beschreibe ich eine alternative Installations-Methode über Composer, da das mittlerweile bei größeren Projekten zum Standard geworden ist.

 

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.