Userabhängige Toolbar im CK-Editor in Pimcore

Pimcore verwendet als WYSIWYG-Editor den CK-Editor, ein in JavaScript implementierter Editor der sehr viele Möglichkeiten bietet, einen Text direkt im Browser zu bearbeiten.
Da es oft keine gute Idee ist, den User einen Text mit allen Möglichkeiten bearbeiten zu lassen, bietet der Editor die Möglichkeit, die Toolbar selbst zu definieren.

Mit ein wenig Geschick lässt sich dies sogar Userabhängig bewerkstelligen, so daß beispielsweise ein Admin-User die vollständige Toolbar sieht, ein normaler User aber nur eine eingeschränkte.
Die Information, welcher User gerade eingeloggt ist, lässt sich dem pimcore.globalmanager mit der Methode get(“user”) entlocken.

Ein kleines Script, dass die Konfiguration dann Userabhängig gestaltet, könnte dann so aussehen:

CKEDITOR.editorConfig = function( config ) {
  var user = pimcore.globalmanager.get("user");

  if (!user.admin) {
    config.toolbar = [
      [ 'Source', '-', 'NewPage', 'Preview', '-', 'Templates' ],
      [ 'Cut', 'Copy', 'Paste', 'PasteText', 'PasteFromWord', '-', 'Undo', 'Redo' ],
      '/',
      [ 'Bold', 'Italic' ]
    ];
  }
};

Dieses Stück Code kann man zum Beispiel in pimcore/static/js/lib/ckeditor/config.js ablegen.

Objekte erzeugen in Pimcore beschleunigen

Wer in Pimcore schon in der Situation war, viele User-Objekte erzeugen zu müssen (zum Beispiel bei Datenabgleichen mit anderen System) wird festgestellt haben, dass dies eher gemächlich vonstatten geht.

Mit zwei einfachen Maßnahmen kann man dem Prozess gehörig auf die Sprünge helfen.

Den Cache aktivieren

Ist in Pimcore kein Cache konfiguriert, wird per Default der Zend_File_Cache verwendet.
Das ist zwar besser wie nichts, aber immer noch sehr langsam.

Der Cache wird nur dann deaktiviert, wenn man dies explizit mit

Pimcore_Model_Cache::disable();

so setzt.

Es empfiehlt sich daher, den Cache auf eine schnelle Variante wie Memcached oder die MongoDB zu konfigurieren.

Memcache

Memcache ist ultraschnell, da er ausschliesslich im Speicher läuft, hat aber einen Nachteil – alles, was da reingestopft wird, ist global für jeden mit Zugriff auf den Daemon verfügbar. Um hier abgrenzen zu können, setzt Pimcore eine Zwischenschicht zum Taggen ein, und jene Tags werden wiederum in der normalen SQL-Datenbank abgelegt – dieser Umstand macht also den Memcache für Pimcore nicht zu ersten Wahl.

MongoDB

Die MongoDB ist die schnellere Alternative zum Memcache – obwohl sie im Prinzip eigentlich die langsamere wäre, es fehlt aber das Tagging-Handicap.
Die Installation der Datenbank sollte einfach zu bewerkstelligen sein, die meisten Distributionen enthalten sie.

Die Konfiguration in Pimcore erfolgt über die Datei website/var/config/cache.xml. Eine Beispiel-Datei existiert schon in dem Verzeichnis.

Eine funktionierende Version der cache.xml für die MongoDB würde Beispielsweise so aussehen:


    
    
        Core
        
            pricelist_
            99999
            true
        
    
    
        Pimcore_Cache_Backend_Mongodb
        true
        
            pimcore_cache
        
    

Die Datei wird bei jedem Request an Pimcore gesucht, sobald sie vorhanden ist, ist der Cache aktiv.

Den Cache nutzen um Zend_Db_Table zu beschleunigen

Beim Anlegen von vielen Objekten zeigt sich eine kleine, ich will nicht sagen, Unzulänglichkeit, von Zend_Db_Table:

Standardmäßig fragt Zend_Db_Table_Abstract die darunterliegende Datenbank für die Metadaten der Tabelle ab immer wenn diese diese Daten benötigt werden um Tabellenoperationen durchzuführen. Das Tableobjekt holt die Metadaten der Tabelle von der Datenbank indem es die describeTable() Methode des Adapters verwendet.
[...]
In einigen Fällen, speziell wenn viele Table Objekte auf der gleichen Datenbanktabelle instanziert werden kann das Abfragen der Datenbank nach den Metadaten der Tabelle für jede Instanz unerwünscht sein wegen der Geschwindigkeit. In solchen Fällen, können Benutzer davon profitieren das die Metadaten der Tabelle, die von der Datenbank empfangen werden, gecached werden.

Die Kurzfassung: bei jedem Erzeugen eines Daten-Objekts wird die Datenbank gefragt, wie die Daten denn auszusehen haben.
Dieser Vorgang kostet enorm viel Zeit und kann gecached werden mit Zend_Db_Table_Abstract::setDefaultMetadataCache()

Dieser statischen Methode muss einfach nur ein Cache übergeben werden – und einen solchen stellt Pimcore, wie weiter oben beschrieben, zur Verfügung.

Folgende beiden Zeilen aktivieren daher den Metadaten-Cache für Zend_Db_Table:

$cache = Pimcore_Model_Cache::getInstance();
Zend_Db_Table_Abstract::setDefaultMetadataCache($cache);

Die Praxis

Bei einem Kunden war es notwendig, ca 3500 Objekte (mit Assets, es finden also auch Kopiervorgänge auf der Platte statt) zu importieren.
Ohne Cache dauerte dies ca 2 Stunden, mit Cache 15 Minuten, und mit dem Metadaten-Cache nur noch fünf Minuten.

In der Praxis haben diese beiden Maßnahmen uns also enorme Geschwindigkeitssteigerungen gebracht!

EDIT:
Wir haben diese Verbesserung als Issue bei Elements eingereicht: Activate caching Zend table metadata by default.
Die zwei Zeilen sind angemommen worden, ab Version 1.4.10 ist der Cache daher nun im Core von vornherein mit drin :)

Pimcore in Version 1.4.9 erschienen

Es gibt einen neuen Release von Pimcore, diesmal in Version 1.4.9

Neben zahlreichen Bugfixes gibt es auch ein paar Verbesserungen.
Am interessantesten finde ich dabei den Update des CKEditors auf Version 4 und die neue Bounce Mail Inbox.

REST

Was auch neu ist, in den Release Notes aber nicht auftaucht: die REST API, mittels welcher man RESTful mit Pimcore „sprechen“ kann.

Folgende Aktionen lassen sich zum gegenwärtigen Stand damit ausführen:

  • Get Object By ID
  • Delete Object By ID
  • Create a new object
  • Update existing object
  • Get Object Metadata
  • Get Class By ID
  • Get Field Collection Definition By Key
  • Object Brick Definition By Key
  • Get Asset By ID
  • Delete Asset By ID
  • Create New Asset
  • Update Existing Asset
  • Get Document By ID
  • Delete Document By ID
  • Create New Document
  • Update Existing Document
  • Search Assets
  • Search Documents
  • Search Objects
  • Get Asset Count
  • Get Document Count
  • Get Object Count
  • Get User
  • Get KeyValue Definition
  • Get Server Info
  • Override HTTP Method

Die Release Notes

Hier die Releasenotes für Version 1.4.9:
Bug

  • maintenance.php: PHP Warning: Error while sending STMT_CLOSE packet. PID=23365 in Unknown on line 0
  • overwrite hasChilds() in hardlink wrappers respecting children setting in hardlinks
  • outdated classloader map
  • Front end translation not working after clean install
  • Renaming a class results on unknown behavior
  • Not possible to add object named “Service”
  • Cannot create documents in Plugin (There is already an active transaction)
  • 1.4.8: Sql request problem when saving an object with multiple multihref fields
  • RTE RichText Wysiwyg Editor in FieldCollections stops working after reordering
  • Can edit object in “Search, Edit and Export Tab”, but the role is not allow
  • Colon (:) as path separator in /pimcore/cli/classmap_generator.php
  • Assets: Download as zip does not work for root folder
  • Classes can create invalid PHP Files
  • Document_List not autoloading because of bug in function getDocuments()
  • CSV import with cell containing carriage return does not work properly
  • postupdate Script for revision 2209 fails
  • Video-incompatibilities caused by a comma
  • Modal dialog “Please wait” stays there forever if Import Asset from URL is attempted with invalid URL
  • Data in structured table is truncated after 50 characters
  • Ext.form.ComboBox items can not be selected in IE
  • Spelling Mistake – The desired element is currently opend by an other person:
  • Session Error (see Screenshot)
  • Geographical Polygon Selection Editor doesn’t load if polygon present
  • 1.4.8, isValidKey in class Pimcore_Tool doesn’t allow the preset key on fresh installation
  • Deletion of user-/rolefolders containing users/roles doesn’t remove the content.
  • Can’t drop additional editables into areablock after certain number of elements is already added
  • Asset->setParent() and Document->setParent() does not work
  • Deleting cache cleans whole folder inclusive .dummy
  • Implement webservice API for keyvalue data type
  • Document_Service::render() not overwriting passed $params on sucessive calls
  • Drop Locks Table on Install
  • YUICompressor and curilyc
  • Image cropping doesn’t work when no thumbnail config is defined
  • mongodb persist option throws exception (persist parameter is outdated)
  • Do not allow “admin”, “webservice”, “install” and “plugin” as name for documents in the first level (system routes)
  • Reload after plugin uninstall
  • PHP5.4 Bugging
  • rename in document tree breaks path

Verbesserung

  • Option for caching images directly after upload should be present somewhere
  • Thumbnails are resizing gradually in Editmode
  • HTML 5 Video: Automatically add microdata for search engines (poster thumnail, …)
  • In folder view rename buton “Delete” to “Delete folder”
  • Allow to turn off opening the last open tabs in backend on user level
  • Editables: Add “Show in Tree” in contextmenu where items are assigend
  • Pimcore_View parameter is forced to HTTP request rather than abstract
  • Plugin initialisation array index not defined warnings
  • Prepare datatypes for better preview and diff view
  • CKEditor Update (Version 4)
  • Thumbnails: Support for progressive JPEGs
  • Custom metadata on pages
  • Make root nodes in sidebar (“home”) translatable
  • Site-specific robots.txt
  • Site-specific routes: allow same name for routes of different sites
  • new Asset_* should have the type predefined
  • Additional SOAP API Functionality
  • New style editor should be optional
  • Add async attribute to minified JS in JavascriptMinify.php
  • Update Cache after updating Website settings
  • Tag-Manager: Allow to restrict to sites
  • Disabling versions doesn’t work
  • Asset_Image creation very slow because of low-performant $this->clearThumbnails() function

Neue Funktion

  • Bounce Mail Inbox
  • Option to switch between old and new ckeditor
  • Add the ability to recursively create Object/Asset folders
  • Previews for pages (document)

Pimcore Dynamic Dropdown Module in neuer Version

Eines unser Plugins für Pimcore ist in einer neuen Version erschienen.

Es handelt sich hierbei um das Dynamic Dropdown Plugin, das in Objekten ein Dropdown-Eingabeelement zur Verfügung stellt, dessen Inhalte wiederum aus anderen Objekten bzw deren Feldern bestimmt werden.

Was ist neu?

Das Plugin kann nun rekursiv verarbeiten und das Ergebnis sortieren.

Das Plugin kann nun rekursiv verarbeiten und das Ergebnis sortieren.

  • Die Reihenfolge der Elemente kann nun entweder nach ihrer ID oder ihrem Wert sortiert werden, dies ist in der Konfiguration des Eingabelements einstellbar.
  • Die Ordner, in denen die Elemente liegen müssen, können nun rekursiv durchsucht werden. Auch dies ist in der Konfiguration (de-)aktivierbar.
  • Der Bug, der dazu führte daß die Methodennamen erst nach einem Reload der Seite zur Verfügung standen, ist behoben.
  • Das Feld kann nun in der Grid-Ansicht der Objektliste angezeigt werden. Zu beachten ist dabei, daß es sich beim Dynamic Dropdown intern um ein Href handelt, es kann daher nicht nach dieser Spalte sortiert werden.
  • Die eingestellte Breite wird nun berücksichtigt.

Die neue Version kann in der Pimcore-eigenen Pluginverwaltung aktualisiert werden.

Feedback ist, wie immer, ausdrücklich erwünscht :)

Ein Ausblick in die Zukunft

Ein Ausblick auf die neue Eingabe

Ein Ausblick auf die neue Eingabe

Einer unserer Kunden benötigt eine Erweiterung der Eingabeverarbeitung, hierbei ist die Darstellung als zwei Boxen gewünscht wobei die eine die zur Verfügung stehenden Eingaben und die andere die Gewählten darstellen soll. Der Wechsel von der einen Box in die andere soll dabei durch Doppelklick stattfinden.

Pimcore translations im Layout

Pimcore bietet mit seinem internen Übersetzer die Möglichkeit, “feststehende” Begriffe auf Webseiten zu komfortabel zu übersetzen.

Der Aufruf hierfür ist, zum Beispiel in einer View:

print $this->translate("Der zu übersetzende Begriff");

Wir die Webseite einmal aufgerufen nimmt Pimcore den Satz „Der zu übersetzende Begriff“ in die Liste mit auf. Dort kann man dann die Angaben in den gewünschten Sprachen machen, und abhängig von der im Frontend eingestellten Sprache wird dann die betreffende Übersetzung ausgegeben.

Die Sprache stellt man im Frontend ein über den Zend_Registry Eintrag “Locale”:

Zend_Registry::set("language", $language);
$locale = new Zend_Locale($language);
Zend_Registry::set("Zend_Locale", $locale);

Dies funktioniert wunderbar – mit einer Ausnahme: im Layout, bzw. Im Actioncontroller Website_Controller_Action

Alle Angaben, die hier gemacht werden, werden nicht übersetzt, weil der Translator noch nicht initialisiert ist.

Will man also beispielsweise Übersetzungen für ein Javascript bereits inline und global mitgeben:

$this->view->headScript()->captureStart(); ?>
var livesuche = "view->translate("Livesuche") ?>";
view->headScript()->captureEnd();

wird der String „Livesuche“ nicht übersetzt.

Um auch hier schon Übersetzungen zu erreichen, muss der Translator händisch initialisiert werden bevor das erste Mal die translate() Methode aufgerufen wird. Dies erreicht man mit:

      $this->initTranslation();

Pimcore: eine Page in mehreren Navigationen verwenden

Pimcore stellt eine komfortable Möglichkeit zur Verfügung, einer Webseite eine strukturierte Dokumentenhierarchie zu verleihen.
Diese Struktur kann automatisiert ausgelesen und sowohl in eine Navigation für die Webseite selbst als auch in sinnvolle und “sprechende” URLs verarbeitet werden.
So ist die URL zu einer Seite “Impressum” folgerichtig “/impressum”, und falls die Seite in einem Unterverzeichnis steckt dann “/unterverzeichnis/impressum”.

Häufiger hatten wir hier das Problem, dass auf der Webseite mehrere, voneinander getrennte Navigationen gewünscht sind. Diese kann man in Pimcore dann ganz leicht in Unterordnern zusammenfassen und jeden individuell auslesen und in eine Navigation verwandeln. Dies stellt aus Suchmaschinensicht aber nicht das Optimum dar, da mit jedem Unterpfad die Relevanz der Seite sinkt, von der “merkwüdigen” URL wie “/kopfnavigation/impressum” ganz zu schweigen.

Wir haben daher mit Hilfe der Eigenschaften, die in Pimcore jeder Seite vergeben werden können, eine Lösung entwickelt.

Folgende Ausgangssituation:

Es existieren drei Navigationen:

  1. Die Kopfnavigation
  2. Die Linke Navigation
  3. Die Hauptnavigation

Zudem gibt es im Fuß der Seite die Gesamtnavigation in der jeder mögliche Navigationspunkt nochmal aufgeführt ist:

In Pimcore sind diese Seiten in einer flachen Hierarchie untergebracht, um möglichst kurze URLs zu produzieren:

In der Umsetzung bedienen wir uns der Zend_Navigation, welche uns sehr viel Arbeit abnimmt.
Mit dem pimcoreNavigation() View Helper stellt uns Pimcore eine komfortable Möglichkeit zur Verfügung, eine fertige Zend_Navigation aus dem Dokumentenbaum zu erzeugen.
Dies erreicht man durch Aufrufen der Methode getNavigation($currentDocument, $navStartNode) des View Helpers. $currentDocument stellt dabei das Dokument dar, das in der Navigation als “aktiv” markiert werden soll. In unserem Zusammenhang ist das $this->document. Die Variable $navStartNode beschreibt das Dokument, dessen Kinder die einzelnen Links werden. In unserem Fall ist das “/home”.

      $navStartNode = Document::getById(1);
      $gesamte_nav = $this->view->pimcoreNavigation()->getNavigation($this->document, $navStartNode);

Aus dieser Navigation erzeugen wir nun die anderen, wir müssen jeder Seite nur noch die Information mitgeben, in welcher Navigation sie zusätzlich noch erscheinen soll.
Dies erreichen wir mit den Eigenschaften der Seite. Praktisch hierfür ist es, eine vorgefertige Eigenschaft zu definieren, aus der dann nur noch ausgewählt werden muß. Hier ist das eine “select” Eigenschaft mit den Werten “Kopf,Links,Haupt”:

Diese Eigenschaft kann man nun jeder Seite zuweisen:

Diese Information kann nun bequem ausgewertet werden, um die einzelnen Navigationen zu erzeugen.
Hierbei lesen wir jede Zend_Navigation_Page aus der Navigation aus und werten die Eigenschaft “navigation” des Documents der Page aus. Abhängig vom Inhalt wird eine Seite gegebenenfalls einer weiteren Navigation zugewiesen:

      $kopf_nav  = new Zend_Navigation();
      $linke_nav = new Zend_Navigation();
      $haupt_nav = new Zend_Navigation();

      foreach ($gesamte_nav as $page) {
        $newpage = clone $page;
        $nav_property = trim($page->getDocument()->getProperty("navigation"));
        if     ($nav_property == "Kopf")  $kopf_nav->addPage($newpage);
        elseif ($nav_property == "Haupt") $haupt_nav->addPage($newpage);
        elseif ($nav_property == "Links") $linke_nav->addPage($newpage);
      }

      $this->view->gesamte_nav = $gesamte_nav;
      $this->view->kopf_nav    = $kopf_nav;
      $this->view->linke_nav   = $linke_nav;
      $this->view->haupt_nav   = $haupt_nav;

Ganz wichtig hierbei ist es, $page vor der Zuweisung durch addPage() mit dem clone keywords zu kopieren (Zeile 6), da Zend_Navigation_Container der Seite beim addPage()-Vorgang ein neues Parent zuweist und damit der Gesamt-Navigation entziehen würde.

Die so erzeugten Navigationen können im Layout nun bequem ausgegeben werden:

echo $this->navigation()->menu()->renderMenu($this->kopf_nav, array("maxDepth" => 0));

Umgehung des Layouts bei Pimcore

Wer in Pimcore anstelle einer HTML-Ausgabe direkt eine Datei zum Runterladen produzieren möchte, stößt schnell auf das Problem dass einem die nützlichen Features von Pimcore – wie zum Beispiel die Erzeugung der richtigen HTTP-Header oder eines HTML-Grundgerüsts – in die Quere geraten.

So kann man beispielsweise mit PHPExcel zwar on the fly Excel-Dokumente erzeugen und abspeichern, aber nicht ohne Weiteres an den User zurückgeben z.B. mit print file_get_contents(“export.xlsx”); da zum einen ein HTML-Mimetype gesendet wird, und zum anderen – so fern vorhanden – noch HTML mit ausgegeben wird. Ein direkter Download unter dem gewünschten Filenamen findet so auch nicht statt.

Hier muß man also die richtigen Maßnahmen ergreifen, um aus dem HTML-Framework auszubrechen und direkt die gewünschten Fileinhalte und Header produzieren.

Headerausgabe

Pimcore benutzt das Zend_Controller_Response Objekt des Zend Frameworks, welches Inhalte und/oder Header vereinigt um sie in einem Rutsch zu versenden.
Die Header und Inhalte werden von Pimcore automatisch erzeugt, man kann diese aber auch explizit setzen.

Besonders wichtig hier ist das Headerfeld des MIME-Types “Content-Type”, welches dem Browser sagt, von welchem Typ die empfangenen Daten sind. Meist ist das HTML (was direkt dargestellt wird), bei einem Download aber muss dies entsprechend gesetzt werden. Der MIME-Type für Excel ist application/vnd.ms-excel.

Es kann, per Headerfield “Content-Disposition”, bestimmt werden, unter welchem Filenamen die heruntergeladene Datei abgespeichert werden soll. Fehlt dieser Header erzeugen die Browser für gewöhnlich einen Namen aus Bestandteilen der aufgerufenen URL.

Zu guter Letzt können auch noch Headerinformationen gesetzt werden, die das Cacheingverhalten des Browsers (und unter Umständen auch das einiger Proxys) beinflussen um so von vornherein unerwartete Probleme zu vermeiden.

Zusammengefasst als Code sieht das, hier im Controller, so aus:

        $Response = $this->getResponse();
        $Response->setHeader("Content-Type", "application/vnd.ms-excel", true);
        $Response->setHeader("Content-Disposition", "attachment; filename=".$filename.".xlsx");
        $Response->setHeader("Expires", "0");
        $Response->setHeader("Cache-Control", "must-revalidate, post-check=0,pre-check=0");
        $Response->setHeader("Pragma", "public");

Deaktivierung der Layout-Ausgaben

Nun muß man Pimcore anweisen, die sonst übliche Ausgabe des Layouts und aller hier unnötigen Inhalte zu unterlassen:

$this->disableLayout(); // Nur nötig, wenn ein Layout verwendet wird
$this->removeViewRenderer();

Ausgabe des Inhalts

Zu guter Letzt kann nun der Inhalt ausgegeben werden. Ich nehme hier als Beispiel wieder die Ausgabe meines PHPExcel-Objekts:

        $objWriter = new PHPExcel_Writer_Excel2007($ExcelExport_Category);
        $tmp_filename = PIMCORE_TEMPORARY_DIRECTORY."/xls_export_".uniqid().".xlsx";
        $objWriter->save($tmp_filename);
        print file_get_contents($tmp_filename);
        unlink($tmp_filename);

Liste von verfügbaren Sprachen in Pimcore auslesen und verarbeiten

Für ein Webformular brauchten wir wir eine Zend Framework Selectbox mit den validen Sprachen des Frontends.

Pimcore bietet auch hier wieder komfortable Möglichkeiten, die aktuell im Backend eingestellten Sprachen zu verarbeiten.

Das ganze Problem wird hierdurch wieder mal zum komfortablen Fünfzeiler wenn man weiß wo man hinfassen muss.

Pimcore liefert mit der statischen Methode Pimcore_Tool::getValidLanguages() einen Array an Kürzeln der validen Sprachen, also zB array(“de”, “en”).

Dies kann man sich nun noch vom Zend Framework übersetzen lassen, ebenfalls mit einer statischen Methode: Zend_Locale::getTranslation($kuerzel, “language”, $zielsprache).
Sinnvollerweise lässt man sich das Kürzel in die Sprache übersetzen, die es repräsentiert – ein auswählender User kann seine Sprache damit sicher identifizieren.

Der Select-Viewhelper erwartet nun noch die Werte im Format array($value => $label).

Zusammengefasst sieht das daher dann so aus:

$pimcore_languages = Pimcore_Tool::getValidLanguages();
$languages = array();
foreach ($pimcore_languages as $lang) {
  $languages[$lang] = Zend_Locale::getTranslation($lang, 'language', $lang);
}
$language = $this->createElement("select", "language");
$language->setLabel("Sprache")
         ->setMultioptions($languages);

Pimcore – Keys generieren für Objekte

Wer in Pimcore Objekte oder Assets mit einem eigenen Import-Skript einliest, muss auch gültige Keys für die Objekte generieren.
Diese müssen einem bestimmten Schema folgen oder alles fliegt früher oder später aus der Kurve.

Pimcore stellt intern Methoden bereit um gültige Keys zu erzeugen, zum Beispiel die Methode Pimcore_File::getValidFilename()

Diese hat für unseren Sprachraum nur den Schönheitsfehler, dass Umlaute entfernt werden.
Es liegt daher nahe, die ganze Geschichte etwas aufzubohren. Der Einfachheit halber mache ich das mit einer simplen Funktion:

function makeKey($key) {
  $key = str_replace(array("ä","ü","ö","ß"), array("ae", "ue", "oe", "ss"), utf8_encode($key));
  return Pimcore_File::getValidFilename($key);
}

Dies kann man nun ganz einfach nutzen – hier ein Beispiel aus einem unserer Importer:

  $objekt = new Object_Objekt();
  $objekt->setParentId($parent_id);
  $objekt->setCreationDate(new Zend_Date($row["ModDate"], Zend_Date::TIMESTAMP));
  $objekt->setUserOwner(1);
  $objekt->setUserModification(1);
  $objekt->setPublished(true);

  $key = makeKey("Mein Objekt");
  $objekt->setKey($key); // der Identifier wie er im Baum erscheint

Pimcore in Version 1.4.7

Pimcore wurde in Version 1.4.7 veröffentlicht.
Es wurden hauptsächlich Bugs gefixt und ein paar kleine Verbesserungen vorgenommen:

Bug

  • [PIMCORE-1585] – Video preview creation in backend fails
  • [PIMCORE-1593] – JS Minifier causes external scripts not to be included
  • [PIMCORE-1596] – after Document::render() not the correct layout script is set
  • [PIMCORE-1598] – Zend_Form_Decorator_Captcha_ReCaptcha leads to JS-Error in Internet Explorer
  • [PIMCORE-1602] – Renderlet throws error: Class: Document_Folder => call to undefined method getTemplate
  • [PIMCORE-1604] – Installation of plugin can throw exception on forced reload
  • [PIMCORE-1606] – On Asset Upload Version-User is not updated
  • [PIMCORE-1611] – Wrong Debug Message in Pimcore_Model_Cache::load()
  • [PIMCORE-1618] – Static routing for Document Folder
  • [PIMCORE-1619] – Unpublished documents are shown by Pimcore_View_Helper_PimcoreNavigation_Controller
  • [PIMCORE-1624] – Alt + s problem on polish keyboard, so that people from poland can’t write their “ś” char (just like: PIMCORE-524)

Improvement

  • [PIMCORE-530] – Drop target do not accept anything in Safari/Webkit
  • [PIMCORE-1506] – Park Objects without checking for mandatory fields
  • [PIMCORE-1549] – New Redis Cache Backend Class (related to PIMCORE-1534)
  • [PIMCORE-1578] – possibility to cleanup (empty) translations (admin/website)
  • [PIMCORE-1589] – Zend Framework 1.11.12 Upgrade
  • [PIMCORE-1601] – Too many “are you sure you want to leave this page” messages when leaving
  • [PIMCORE-1603] – Document_Tag_Video only allows “autoplay” Option of YouTube API
  • [PIMCORE-1612] – Update the less compiler to the latest build (0.3.5)
  • [PIMCORE-1625] – Looping through an areablock twice causes an infinite loop
  • [PIMCORE-1629] – Google API’s: Possibility to define a deviant browser key

New Feature

  • [PIMCORE-1580] – Add feature to download Assets from an URL
  • [PIMCORE-1613] – Link to Frontend Page on Right Click on the Navigation Tree
  • [PIMCORE-1626] – Open document from URL (in “File” menu)

Task

  • [PIMCORE-1594] – Safari is not recognized as a supported browser