Wer meinen n98-magerun Vortrag, den ich auf der MeetMagento 2013 gehalten habe, noch nicht gesehen hat, der kann dies nun tun. Alle MeetMagento Vorträge kann man bequem über YouTube schauen.
Die komplette Playlist ist hier zu finden: https://www.youtube.com/playlist?list=PLVWAe0v2UNB5u8c8MnrsbItnVgkpwPfJH
Viel Spaß!
Der von Magento veröffentlichte Sicherheitspatch letzte Woche hat leider eine kleine Nebenwirkung. Wird das Media-Verzeichnis über einen Symlink eingebunden, was bei größeren Shop-Installationen durchaus üblich ist, dann funktioniert der Dateibrowser im Wysiwyg-Editor nicht mehr.
Das Problem kann einfach über folgenden Befehl nachgestellt werden:
mv media media_shared && ln -s media_shared media
Da wir bei meinem Arbeitgeber netz98 alle Kundeninstallationen entsprechend zeitnah mit dem Patch aufgrund der Sicherheitslücke aktualisiert haben ist dies natürlich schnell aufgefallen.
Wer tiefer in die Magento Entwicklung einsteigt wird unweigerlich irgendwann an den Punkt kommen bei dem das Caching ins Spiel kommt.
Wer dann eine Ganze Serverlandschaft für einen Magento-Shop aufsetzt muss sich zwangsläufig Gedanken über die Performance und Skalierbarkeit von Cache Backends machen. In der Magento Community gibt es einige Leute die hierbei bereits Pionierarbeit geleistet haben. Da fällt mir z.B. Fabrizio ein, der sich schon sehr Lange mit dem Thema Performance auseinander setzt und hierzu bereits einige Vorträge (z.B. auf der Meet Magento) gehalten hat.
Nach der Veröffentlichung der neuen Ubuntu Version (ich nutze Kubuntu) habe ich meinen Arbeitsrechner zuhause auf die neue Version aktualisiert.
Leider liefen meine Magento Shops in der lokalen Umgebung nicht mehr durch. Dies liegt vor allem ein zwei Dingen…
Die Funktionen json_encode und json_decode werden nicht mehr mit PHP gebündelt. Dies liegt an einer Lizenzproblematik auf die ich jetzt nicht weiter eingehen möchte.
Mcrypt wurde nicht mehr geladen.
Wird ein Produkt in den Warenkorb gelegt, erscheint die folgende Meldung:
Es ist wieder soweit. Magento (Ebay) hat einen neuen Release der Community Edition 2 Version veröffentlicht. Ein ausgewählter Kreis von Partnern hatte bereits das Vergnügen ein paar Tage vorher in Chicago exklusiv einen Einblick in die neuen Funktionen zu erlangen und seine Meinung dazu zu äußern. Ich persönlich finde das sehr unschön. Gerade in Deutschland gibt es viele Entwickler die sicherlich gerne etwas mehr in die Entwicklung involviert wären. Nicht, dass in der Vergangenheit Varien (Magento) mehr Wert auf den aktiven Austausch mit der Community wert gelegt hätte… Schade, hier hat Ebay mal wieder eine Change vertan.
Lange ist es her, dass ich mir Magento 2 im Adminbereich angeschaut habe. Das letzte Update liegt schon einige Monate zurück. Die Changelogs habe ich mir zwar schon angeschaut, allerdings hatten ich und andere, einige Problem sich in den Adminbereich einzuloggen. Das Problem war, dass man wohl immer noch mit der uralten PHP 5.3 Version unterwegs sein musste und die Magento 2 Version noch nicht kompatibel mit PHP 5.3 war (obwohl PHP 5.5 schon als Beta-Version vorhanden war). Da ich auf meinem Entwicklungsrechner schon einige Zeit keine PHP 5.3 mehr laufne habe da diese mit den aktuellen Betriebssystemupdates auch nicht mehr ohne weiteres ausgeliefert wurden habe ich auf den zeitweisen Genuss verzichtet. Das gute vorweg… mit der neuen Magento 2 Version konnte ich mich endlich einloggen. Ein klick auf das Menü zeigte mir aber nur eine nicht vollständige Seite an. Der Grund war, dass irgendwo das Rendering beendet wurde. Ein Blick in das Exception Log, sowie das Apache Error Log brachten keine Bahnbrechenden Erkenntnisse. Meine Vermutung viel dann wie bei Magento 1 auf das PHP Memory Limit. Und siehe da! Magento 2 liefert ebenfalls eine .htaccess Datei mit die mit knappen 256MB Memory Limit voreingestellt ist. Also schnell das Limit auf “sparsame” 1024MB hochgeschraubt da ich natürlich jetzt auch mal was sehen wollte. Und schwupps läuft der Shop und zeigt ein vollständigen Adminbereich an.
Vor einiger Zeit hatte ich das Vergnügen auf dem Barcamp in Mainz von Stefan Husch, der selbst seit einigen Jahren in Ruby entwickelt und meinem ehemaligen Kollegen Mattias Gutjahr eine tolle Einführung in das Thema Puppet und Vagrant bekommen zu haben. Seit dem befasse ich mich immer mal wieder mit dem gesamten Thema “DevOps” und versuch Dinge die ich immer wieder machen muss zu automatisieren. Stefan ist mir hier ein gutes Stück vorraus. Er provisioniert seine Server schon seit Jahren mit Puppet und stellt damit z.B. Instanzen seines CMS oder z.B. Redmine per Knopfdruck bereit. Da mich das Thema damals direkt in Verbindung mit Magento interessiert hatte, stellte ich meine ersten Erfahrungen über ein Github Projekt der Öffentlichkeit zur Vergfügung. Das ganze habe ich damals auch im Rahmen einer kleinen Vorstellung bei unserer PHPUG gezeigt. Wie bereits geschrieben, enthielt das Projekt meine ersten Erfahrungen mit Puppet und Vagrant. Es wunder mich aber immer mal wieder jemand das Projekt forked obwohl die Scripte alles andere als optimal sind. Einige Forks (z.B. https://github.com/matthewsplant/magento-vagrant-puppet) haben das Projekt um einiges vorangetrieben. Das freut mich natürlich.
Seit Version 1.72.0 gibt es die Möglichkeit Kommandos oder Konfigurationen als Modul zu veröffentlichen. Module bieten eine einfache Möglichkeit Konfiguration und Kommandos direkt in einem Projekt oder einem Entwickler-Team zu teilen ohne, dass zuerst eine Konfiguration angepasst werden muss.
Ein Modul besteht in seiner einfachsten Form aus einem Verzeichnis und einer Konfigurationsdatei mit dem Namen n98-magerun.yaml. Die Konfigurationsdatei muss direkt im Modulverzeichnis liegen. Innerhalb der Konfigurationsdatei könnt ihr bestehende Konfigurationen ändern, oder neue hinzufügen. Also eigentlich nichts neues. Der Vorteil der Module ist aber, dass n98-magerun innerhalb von definierten Modul-Basisverzeichnissen nach den entsprechenden Modulen sucht.
Gerade getestet und für gut befunden. PhpStorm kann ohne fremde Hilfe nicht einfach für jedes Framework Fabrikmethoden auswerten.
Bei Magento sind das z.B. Funktionen wie Mage::getModel('catalog/product') die im Hinterund die Klasse anhand einer XML Struktur ermitteln.
Seit dem letzten Build (129.196) kann man nun selbst über ein alleinstehendes PHP Script die Auflösung in die Hand nehmen.
Das sieht dann z.B. so aus:
namespace PHPSTORM_META {
/** @noinspection PhpUnusedLocalVariableInspection */
/** @noinspection PhpIllegalArrayKeyTypeInspection */
$STATIC_METHOD_TYPES = [
\Mage::helper('') => [
'core/string' instanceof \Mage_Core_Helper_String,
],
\Mage::getSingleton('') => [
'core/resource' instanceof \Mage_Core_Model_Resource,
],
\Mage::getModel('') => [
'catalog/product' instanceof \Mage_Catalog_Model_Product,
'rating/rating' instanceof \Mage_Rating_Model_Rating,
],
];
}
Empfohlen wird die Datei .phpstorm.meta.php zu nennen. Die Datei kann aber auch anders benannt werden. Ich habe mich in diesem Fall an den Standard gehalten. Es wäre schöne, wenn das jeder macht um die Datei in einem fremden Projekt nicht suchen zu müssen.
Wer nicht so viel Geld ausgeben will, kann auf eine der vielen GIT Verwaltungstools zurückgreifen. Sehr beliebt sind hier gitolite oder gitosis Letzteres setzen wir bei netz98 seit Jahren erfolgreich ein.
Leider bietet gitosis z.B. keine Weboberfläche zur Administration an. Das ist erst mal nicht weiter schlimm, wenn man nur wenige Repositories verwaltet. Doch mit wachsender Anzahl verliert man schnell die Übersicht. Das kann auch unter Umständen zu Sicherheitslücken führen. Verlässt ein Mitarbeiter das Unternehmen sollte man auch die Berechtigungen in den einzelnen Gruppen entziehen. Ist die Datei aber unübersichtlich vergisst man vielleicht an der einen oder anderen Stelle etwas anzupassen.