Die Woche auf StackExchange #36/2016

Hier sind wieder einige Posts auf Magento StackExchange der letzten Woche, die ich gerne festhalten möchte:

Magento 2

Magento 1

PHP: class_alias verwenden um Klassen rückwärtskompatibel zu verschieben/umzubenennen

Manchmal möchte man eine Klasse umbenennen oder sie in einen anderen Namespace verschieben. Aber sobald sie irgendwo außerhalb des Packages verwendet wurde, ist das eine nicht abwärtskompatible Änderung und sollte nicht leichtfertig vorgenommen werden.

Zum Glück gibt es in PHP eine Möglichkeit, beide Klassen gleichzeitig zu nutzen, die alte und die neue, um die alte als “deprecated” zu markieren aber weiterhin nutzen zu können: class_alias().

Wie man class_alias() nutzt, ohne Probleme mit dem Autoloading zu bekommen

Sagen wir, die alte Klasse ist OldClass und wir wollen sie zu NewClass umbenennen.

Als erstes benennen wir die Klasse um und schieben sie von OldClass.php in eine neue Datei NewClass.php.
Continue reading “PHP: class_alias verwenden um Klassen rückwärtskompatibel zu verschieben/umzubenennen”

Die Woche auf StackExchange #35/2016

Ich bin etwas spät dran aber ich war in letzter Zeit recht akiv auf Magento StackExchange, also hier sind die besten Posts von letzter Woche!

Magento 1 Antworten

PHPUnit

Neue Magento 2 Fragen

Magento 2 Integration Tests: @magentoConfigFixture

Ich konnte keine gute Dokumentation zur @magentoConfigFixture Annotation in Magento 2 Integrationstests finden, also halte ich hier mal meine Zusammenfassung fest, nachdem ich den Core Code inspiziert habe (Magento 2.1.0, Magento\TestFramework\Annotation\ConfigFixture)

Wie man @magentoConfigFixture nutzt

Standardwert 42 für Konfigurationspfad x/y/z:

/**
 * @magentoConfigFixture default/x/y/z 42
 */

Store-spezifischer Wert 42 für Konfigurationspfad x/y/z im Store mit Code store1

/**
 * @magentoConfigFixture store1_store x/y/z 42
 */

Store-spezifischer Wert 42 für Konfigurationspfad x/y/z in aktuellem Store (also Standard-Store)

/**
 * @magentoConfigFixture current_store x/y/z 42
 */

Das sind alle möglichen Formate. Der erste Parameter muss mit _store enden oder weggelassen werden. Wenn er weggelassen wird, muss der Pfad mit default/ beginnen, sonst wird er ignoriert.

Implikationen

  • Konfigurationswerte können nicht auf Website-Ebene gesetzt werden
  • Man sollte nicht “current” als echten Store Code verwenden, sonst kann für diesen Store keine Konfigurations-Fixture genutzt werden

EcomDev PHPUnit Tipp #14

Seit Jahren ist das Test-Framework EcomDev_PHPUnit quasi-Standard für Magento Unit Tests. Die aktuelle Version ist 0.3.7 und der letzte Stand der offiziellen Dokumentation ist Version 0.2.0 – seitdem hat sich viel getan, was man leider im Code und GitHub Issues selbst zusammensuchen muss. Diese Serie soll praktische Tipps zur Verwendung sammeln.

Tipp #14: Registry Fixtures

Wie bereits in Tipp #1 erklärt, können Helpers, Singletons und Registry Werte pro Test zurückgesetzt werden. Die problematischen Singletons etc. zu finden war für mich oft der schwierigste Teil beim Schreiben von Integrationstests mit EcomDev, also habe ich angefangen, sie zentral in einer fixtures/registry.yaml Datei für alle Tests zu sammeln 1. Lieber eins zu viel zurückgesetzt als eins zu wenig.

Die Datei ist aufgebaut wie folgt:
Continue reading “EcomDev PHPUnit Tipp #14”

Notes:

  1. Siehe auch YAML Directory Fallback

Die Wochen auf StackExchange #33-34 / 2016

Kurz und schmerzlos: StackExchange Posts der letzten zwei Wochen.

Magento 1

Magento 2

Die Wochen auf StackExchange #30-32 / 2016

Ich war wieder aktiv auf Magento StackExchange und ein paar interessante Fragen und Antworten sind in den letzten drei Wochen zusammengekommen:

Magento 1

Magento 2

Magento Architektur

Gute Frage zum Verständnis von “MVC” in Magento: Why does Magento need blocks?. Hier gab es schon mal eine ähnlich gelagerte Frage: Where’s The V in Magento’s MVC? And is there better name?