Pimcore Updatefehler in simplexml_load_string() von 2.x auf 3.x

Die Pimcore-Versionen vor 2.x kommen ab und an nicht mit dem Update auf 3.x klar, da einer der anzuwendenden Update-Dateien ohne Anpassungen für simple_xml zu groß ist. Mit folgender Änderungen können diese Schwierigkeiten aus dem Weg geräumt werden.

Weiterlesen

HTTPS für alle! Redirect aller Requests auf SSL ohne Veränderung.

Hier mal wieder ein Codeschnipsel, den wir immer wieder brauchen und fast genauso oft „ergooglen“ müssen. Ich verewige das daher mal in unserem Blog 😉

Bequemes Herstellen der Vertraulichkeit

Artikelbild_httpsGefragt ist hier die Weiterleitungen aller Requests an einen Apache-Webserver über http an ihre Pendants über https.
Im Zeitalter des globalen Abhörens von allem durch wohl so ziemlich alle Geheimdienste dieser Welt ist dies ein von unseren Kunden immer öfter gewünschtes Feature.
Die Benutzer einer Webseite sind sich oft nicht bewußt, dass Ihr Besuch auch über eine verschlüsselte Verbindung stattfinden könnte. Man kann sie mit dieser Lösung sanft zu ihrem Glück zwingen.
Weiterlesen

Pimcore in Version 2.0 erschienen

Pimcore LogoPimcore ist in Version 2.0 erschienen.
Weiterlesen

Pimcore 2.0 als Release Candidate erschienen

Die Webpräsenz der Multi-Channel Experience and Engagement Management Platform, wie es von elements.at bezeichnet wird, pimcore ist soeben im neuen Gewand erschienen.

Gleichzeitig wurde der Release Candidate der Version 2.0 angekündigt.

Neue Features sind, unter anderem:

  • New Admin UI
  • Targeting & Personas
  • Plugin Generator
  • Inheritance for localized fields
  • UUID support
  • Search & replace for relations
  • SQL reports & custom reports
  • Multiple dashboards
  • New Data type „Image advanced“ (Hotspots, marker & cropping)
  • PDF editable
  • XLIFF Export/import
  • Copy & paste of area bricks
  • Highres thumbnails
  • Document previews reloaded
  • Last opened elements
  • Fallback language
  • Use MySQL as default cache
  • Composer support

Pimcore Assets schützen

Assets sind unter Pimcore sämtlich völlig frei zum Download verfügbar. Erreicht wird dies dadurch, dass mod_rewrite des Webservers die Datei bei Existenz im Asset-Verzeichnis als Weiterleitung an den User ausliefert, ohne daß Pimcore hierbei involviert wird.

Von einem Kunden hatten wir die Anforderung, daß einige dieser Files schützbar und zum Teil mit einem Freigabeprozess versehbar sein könnnen müssen.

Es muss also dafür gesorgt werden, dass Pimcore den Download-Request zu Gesicht bekommt und ggfs ablehnt oder einen Freigabeprozess anstösst.
Wir zeigen hier, wie wir dieses Problem angegangen sind.

Weiterlesen

Pimcore: upload_max_filesize richtig setzen

In PHP ist die Größer der Dateien, die man als User hochladen, begrenzt, und das per default oft sehr gering.

Dieser Wert wird mit der Variable max_upload_size in der php.ini gesetzt.
Will man es dem User also ermöglichen, große Dateien hochzuladen, muss man den Wert dieser Variable erhöhen.

Schnell stellt man aber fest, daß der Upload-Dialog für Assets sich nicht geändert hat.

Woran liegt das, und wie kann man darauf reagieren?

Weiterlesen

Pimcore: Im Backend eingeloggten User herausfinden

Will man im Pimcore Backend herausfinden welcher User eingeloggt ist, ist dies einfach. Die statische Methode Pimcore_Tool_Admin::getCurrentUser() liefert ein Objekt der Klasse User.

Im Frontend, also zum Beispiel in einem Controller, liefert diese Methode aber immer Null. Warum ist das so? Und wie findet man es trotzdem heraus?
Weiterlesen

Captcha Image im Formbuilder Plugin von pimcore

Das Formbuilder Plugin von Pimcore bietet unter anderem die Möglichkeit ein Captcha Image zu integrieren.

Um nicht lange probieren zu müssen – hier ein Screenshot welche Werte man dafür im Formbuilder Plugin eintragen muss.

Ich habe im /static/fonts Ordner die Datei arial.ttf hochgeladen und einen neuen Ordner /static/img/captcha angelegt. Bitte darauf achten, dass der captcha Ordner auch mit den richtigen Rechten versehen ist (0777).

Captcha Image Formbuilder Plugin

Contentblock in Pimcore „ferngesteuert“ anzeigen

Artikelbild Blöcke fernsteuern Die Eingabeelemente eines Dokumentes lassen sich in Pimcore ähnlich leicht auslesen, wie es bei Objekten der Fall ist.
Dies kann man brauchen zum Beispiel zur Darstellung von Teaserseiten.

Hierfür existiert die Methode Document_PageSnippet::getElement(), wovon sich Document_Page ableitet.

Eine besondere Situation entsteht bei Elementen in einem Contentblock. Da sich auf einer Seite mehrere Instanzen befinden können, muss man genau wissen, wie man diese anspricht.
Hier daher ein Beispiel:

foreach ($this->children as $page) {
  foreach ($page->getElement('blockname')->indices as $i) {
    $blockelement = $page->getElement($nameofelement.$nameofblock.$i);

Man beachte, dass die Reihenfolge der Identifier hierbei ElementName->Blockname->Index ist – nicht unbedingt eine, die man intuitiv annehmen würde.

WordPress xmlrpc – wp.newPost mit Zend Framework

Wir standen letzens vor der Problemstellung, Newseinträge der alten Firmenpräsenz für einen Relaunch in ein WordPress importieren zu müssen.

Es liegt nahe, hierfür die xmlrpc-API von WordPress zu verwenden; die API ist gut dokumentiert und die Instanzen müssen nicht auf der gleichen Maschine laufen, zudem ist es mit den Mitteln des Zend Frameworks mit ein paar Handgriffen erledigt.

Leider hat die Sache einen Haken – die Dokumentation der Schnittstelle ist fehlerhaft, veraltet oder passt nicht zum Problem, jedenfalls reagierte WordPress nicht wie beschrieben.

wp.newPost – das Problem mit post_date

Im WordPress Codex wird der Parameter für das Erstellungsdatum wie folgt beschrieben:


struct terms: Taxonomy names as keys, array of term IDs as values.

Das ist etwas dürftig, es existiert aber der Hinweis:
any other fields supported by wp_insert_post.

Die verlinkte Seite spezifiziert das Feld post_date wie folgt:

‚post_date‘ => [ Y-m-d H:i:s ] //The time post was made.

Das mag für den direkten Aufruf der API-Funktion gelten, nicht aber für die Kapselung durch die XMLRPC-Schnittstelle, wie wir nach stundenlangem Herumprobieren und schliesslich Debugging im Source der Schnittstellen-Behandlung herausgefunden haben. Die Schnittstelle quittiert nämlich zu allem Überfluss, entgegen den Angaben in der Doku, jeglichen Fehler lapidar mit dem Status 403.

Die Lösung

Die XMLRPC-Schnittstelle erwartet ein Datum encodiert nach ISO.8601, dies wird im Aufruf signalisiert durch eine Kapselung des Datums in den Tags <date.iso8601>
Diese Kapselung kann man aber nicht selbst vornehmen, da das Tag selbst encoded werden würde.

Mit den Mitteln des Zend Frameworks (wenn man z.B. Zend_XmlRpc_Client verwendet) erreicht man die Encapsulation, in dem man Zend_XmlRpc_Value_DateTime als Datentyp verwendet. Das Zend Framework setzt dann beim Absetzen des Requests das Datum automatisch in die erforderlichen Tags.

Hier ein Beispiel des Codes:

Ein Codebeispiel

//  $date = "".date("Ymd\TH:i:se",  time())."";
    $date = new Zend_XmlRpc_Value_DateTime(time());
    $content = array(
      "post_type" => "post",
      "post_status" => "publish",
      "post_title" => $news_info["titel"],
      "post_author" => 3, // Die ID des WordPress-Users
      "post_content" => $news_info["text"],
      "post_date" => $date,
      "comment_status" => "closed",
      "ping_status" => "closed",
      "terms" => array("category" => array(1)) // Allgemeines
    );
    $post_id = $client->call("wp.newPost", array(0, "USER", "PASSWORT", $content));