Das System von Magento ermöglicht es Entwickler, Daten die oft abgerufen werden im Cache zwischenzuspeichern. Angefangen von Config-Dateien über Layout Updates, aber natürlich auch der HTML Code der Templates kann aus dem Cache abgerufen werden. Die Verwendung ist denkbar einfach, hat aber auch Tücken, die zu Einbußen in der Usability führen können.

Die einzelnen Varianten des Cache möchte ich hier nicht bescheiben, aber generell wird dazu das Model von Zend_Cache verwendet. Flimmit verwendet momentan noch die Basis Einstellung von Magento – den filebasierten Cache im Verzeichnis “/var/cache/”. Hier ist sicher noch ein Geschwindigkeits-Vorteil rauszuholen, wenn man die Memcached Variante verwendet.

Die allgemeine Einstellung von Magento hat Caching im Bereich der HTML-Blöcke sehr restriktiv eingestellt. Hier kann die Ladezeit noch erhöht werden,  indem für Produktseiten bzw. Katalogseiten das Frontend Caching (“Blocks HTML output”) aktiviert. Generell kann für jeden Block ein CacheKey und mehrer CacheTags definiert werden. Meist passiert dies gleich im Konstrutor des Blocks:

$this->addData(array(
‘cache_lifetime’=> false,
‘cache_key’=>’12345′
‘cache_tags’    => array(Mage_Core_Model_Store::CACHE_TAG, Mage_Cms_Model_Block::CACHE_TAG)
));

Das Caching greift aber erst, wenn der Wert von ‘cache_lifetime’ vorhanden ist. Wenn dieser auf “false” gesetzt wird, bedeutet dies nur, dass der Cache ewig gültig ist (gerade passend für Bereiche, die sich selten ändern). Der CacheKey ist der eindeutige Identifier, der Zugriff auf das Cachefile erlaubt bzw. über den ein speielles Cachefile gelöscht werden kann. Mit den CacheTags kann über ein oder mehrere Tags der Cache später über diese Tags gelöscht werden. Gerade das ist eine wichtige Info, auf die bei der Verwendung von Block-Cache geachtet werden sollte.

Die Definition des Zend_Cache für Filebasierten Cache bietet mehrere Parameter. Interessant ist für Magento die Verwendung von ‘hashed_directory_level’, sozusagen der Tiefe der Ordnerstruktur. Je mehr Cachefiles man erwartet, desto größer sollte der Wert sein. Sonst könnten die Zugriffszeiten auf die Cachefiles etwas länger werden.
Hier haben wir die Attribute noch erweitert, da die Maskierung der Dateien mit dem Standardwert 0700 belegt werden. Da aber in manchen Fällen z.B. ein Cronjob als andere User ausgeführt wird, kann es bei der Erneuerung des Caches zu Zugriffsproblemen kommen.

Bei der ersten Verwendung des Caches lag die Herausforderung von flimmit bei der unterschiedlichen Darstellung der Kaufoptionen für User aus verschiedenen Ländern. Da manche unserer Filme territorial eingegrenzt werden müssen, müsste theoretisch für die Produktseite für jeden Ländercode ein eigenes Cachefile erstellt werden. Bei hunderten Filmen und hunderten Ländern würde sich das bald potenzieren. Trotzdem ist die Frontend-Ebene für Caching die schnellste Variante, da nur mehr HTML-Code ausgegeben und kein PHP Code mehr innerhalb der Templates verarbeitet werden muss. Das beste Verhältnis zwischen Felxibilität und Performance muss jeder selber herausfinden.

Ein wichtiger Punkt in Zusammenhang mit dem Cache ist die Bearbeitung von Produktinformationen im Admin-Bereich. Ein wesentlicher Punkt in der Speicherung von Produktinformationen ist die Methode “cleanCache” im File “/app/code/core/Mage/Catalog/Model/Product.php”:

public function cleanCache()
{
Mage::app()->cleanCache(‘catalog_product_’.$this->getId());
return $this;
}

Hier wird der Cache anhand des Tags “‘catalog_product_’.$this->getId()” durchsucht und alle relevanten Files gelöscht. Für die Usability und Aktualität von Daten unumgänglich und notwendig. Hier 2 Tips:

1. Damit auch das Frontend nach jeder Produktänderung aktuell bleibt, sollte auch der Blockoutput (sofern hier das Caching angewendet wird) mit diesem Tag versehen werden. Dadurch ist garantiert, dass auch das Frontend immer die aktuellen Daten anzeigt.
2. Lassen Sie den Cache nie zu groß werden. Bei vielen tausend Files kann ein solcher Vorgang sogar mehr als eine Minute dauern. Und beim Speichern von einem Produkt wird die Methode “cleanCache” vor uns nach dem Speichern verwendet!
   Dazu bietet Zend_Cache eine Option, um “alte” (also abgelaufene) Cachefiles zu löschen.

Hier ein Beispiel, wie man eine Methode (ev. über einen Cronjob) periodisch den alten Cache löschen lassen kann:

public function cleanOldCache()
{
// clean only outdated
Mage::app()->getCache()->clean(Zend_Cache::CLEANING_MODE_OLD);
}

Somit ist unterm Strich die Verwendung von Zend_Cache im Rahmen von Magento ein tolle Sache, kann aber durch oben besagte Punkte auch zu ärger führen.

Ein kurzer Überblick zum Caching direkt bei Magentocommerce gibt es hier:
Magento Cache Management

Also, “happy e-commerce”
Walter

Wir haben uns gut überlegt, welches System wir für die Realisation von flimmit.com verwenden wollen. Im Grunde war die Anforderung, ein e-commerce System zu finden mit dem man virtuelle Produkte verkaufen kann. Doch wir wollten mehr…

Die Entscheidung in der Gründerzeit von flimmit lag vorerst zwischen osCommerce oder xt:Commerce – klar war für uns, dass es ein kostenloses und offenes System sein muss. Erst als einer unserer Entwickler das “neue” System von Magento (www.magentocommerce.com) zum Thema machte, war die Entscheidung schwer: setzt man auf ein neues Pferd, dass noch komplett im Aufbau ist (Magento war damals noch in der Entwicklung und das erste vollwertige Release noch nicht in Aussicht!)? Nach den ersten Tests mit Alpha und Beta-Versionen war aber bald klar, dass in Magento die Zukunft von flimmit.com liegt!

Aber was war ausschlaggebend dafür, alteingesessene und funktionierende Systeme wie osCommerce und xt:Commerce den Laufpass zu geben!? Wahrscheinlich der neue Wind, den Magento mit all seine Facetten mit sich brachte. Hier ein paar Punkte, die uns bis dato überzeugen:

• Das System ist modular aufgebaut, was alle Möglichkeiten für Eigenentwicklungen offen lässt
• Aufbau auf dem Zend Framework (framework.zend.com), das viele Features für die Kommunikation mit diversen anderen Plattformen mit sich bringt (Amazon, Twitter, YouTube, etc.)
• Eine stetig wachsende Community und entsprechender Support bei diversen Modulen mit einfacher Installation über Magento Connect (www.magentocommerce.com/magento-connect)
• Mehrsprachigkeit: gerade bei den Übersetzungen für den Shop gibt es bereits über 60 Packages in verschiedenen Sprachen
• Starker Support bei Updates und dem Versionieren von eigenem Quellcode -> durch die Trennung von Core-Code und eigenem Code lassen sich Updates einfacher einspielen bzw. neue Server mit bestehendem Code aufsetzen
• Der Multi-Shop Support macht es uns möglich, selber unter verschiedenen Domains einzelne Shop zu launchen. Beispielsweise lässt sich hier ein eigener Shop für eine eigene Auswahl an Filmen erstellen, um diese getrennt zu bewerben.
• Modulare Skinning Features machen es weiters möglich, dass wir ein eigenes Layout für TV-Geräte erstellen, welche das Surfen mit der Fernbedienung ermöglich, oder die Darstellung auf mobilen Endgeräten optimiert.
• API Features für die Kommunikation mit externen Partnern mit der Möglichkeit, eigene Schnittstellen zu entwickeln.
• Umfassen Payment Anbieter Support für viele Bezahlvarianten (Kreditkarten, PayPayl, CashTicket, Click & Buy, etc)
• Nette AJAX Features, die dem User ein angenehmes Shoppen auf flimmit.com ermöglichen
• In der Basis gute Unterstützung bei SEO Features

Das sind nur ein paar Gründe, die uns die Entscheidung erleichtert und mittlerweile immer wieder bestätigt haben: ein Magento Shop hat Zukunft!

Natürlich war es ein großes Stück Arbeit die Besonderheiten von flimmit als Video-on-Demand Shop einzubauen bzw. anzupassen – aber die Arbeit hat sich gelohnt. Die Verwendung eines Open Source System lässt uns viel Spielraum, eigene Ideen einzubringen, die wir bei Bedarf in Form eines Moduls auch der Magento Community wieder bereit stellen können. Es macht Spaß jeden Tag neue Features zu implementieren oder neue Module zu integrieren.

Also: “happy e-commerce!”