TranslationHints 0.2 für Magento veröffentlicht

Screenshot: Translation Hint

Ich habe Version 0.2 meiner Magento Extension SSE_TranslationHints veröffentlicht, einem Entwickler-Werkzeug, das die Quelle von Übersetzungen zusammen mit alternativen, überschriebenen Übersetzungen für den selben Text direkt im Frontend anzeigt.

Die Konfiguration ist wie gehabt analog zu den Template Hints:

Screenshots: Translation Hints Configuration

News

Zusammen mit der Quelle der Übersetzung sieht man jetzt auch alternative Übersetzungen, die von der genutzten Quelle überschrieben wurden und einige zusätzliche Informationen.

Im folgendem Beispiel sieht man den Geltungsbereich (Scope) der Übersetzung (Mage_Customer), die Übersetzung für diesen Scope, sowie die Übersetzung, die im globalen Scope verwendet würde, das heißt wenn es keine Scope-spezifische Übersetzung gäbe. Der CACHED Tag sagt uns, dass die Übersetzungen us dem Translation Cache geladen wurden:

Screenshot: Translation Hint

Continue reading “TranslationHints 0.2 für Magento veröffentlicht”

Admin Session mocken mit EcomDev_PHPUnit in Magento Enterprise

In Integrationstests mit EcomDev_PHPUnit_Test_Case_Controller gibt es eine praktische Helper-Methode adminSession(), um Requests im Magento Backend zu testen. Mit Magento Enterprise kann es da allerdings zu dieser Fehlermeldung kommen:

Exception: Warning: in_array() expects parameter 2 to be array, null given in /home/vagrant/mwdental/www/app/code/core/Enterprise/AdminGws/Model/Role.php on line 83

So gesehen in Magento EE 1.14.1.

Ohne Details zu den Enterprise-Modulen preiszugeben, hier eine Lösung in der der schuldige Observer gemockt wird:

$adminObserverMock = $this->getModelMock(
    'enterprise_admingws/observer',
    array('adminControllerPredispatch'));
$adminObserverMock->expects($this->any())
    ->method('adminControllerPredispatch')
    ->will($this->returnSelf());
$this->replaceByMock('singleton', 'enterprise_admingws/observer',
    $adminObserverMock);
$this->adminSession();

Magento: Block-Inhalt verschwindet nach core_block_to_html_after Event

Vorsicht mit Mage_Core_Block_Abstract::toHtml() innerhalb eines Observers für core_block_to_html_after! Ich habe die Methode genutzt, um HTML aus einem Block in einen existierenden Block zu injizieren, mit dem Ergebnis dass alles außer diesem neuen Block von der Ausgabe entfernt wurde.

Beim Debugging im Core habe ich die Ursache darin gefunden, wie das Event dispatched wird:

        /**
         * Use single transport object instance for all blocks
         */
        if (self::$_transportObject === null) {
            self::$_transportObject = new Varien_Object;
        }
        self::$_transportObject->setHtml($html);
        Mage::dispatchEvent('core_block_abstract_to_html_after',
            array('block' => $this, 'transport' => self::$_transportObject));
        $html = self::$_transportObject->getHtml();

Wie man sieht, ist das Transport-Objekt, das genutzt wird um Änderungen am HTML in Observern zu ermöglichen, eine Klassenvariable von Mage_Core_Block_Abstract, und verhält sich ähnlich wie ein Singleton. Ich kann mir keinen guten Grund dafür denken aber es riecht verdächtig nach premature optimization.

Was nun passiert ist, dass während das Event verarbeitet wird, der neue Block seine eigene Ausgabe in seinem eigenen toHtml() Aufruf dem selben Transport-Objekt zuweist und die ursprüngliche Ausgabe verloren geht, wenn man sie nicht vorher gesichert hat.

Die Lösung für mein konkretes Problem war, den Block an anderer Stelle zu erstellen und vorzurendern, aber wenn das nicht getan wird, muss die Ausgabe direkt zu Beginn im Observer in eine neue Variable kopiert werden:

$html = $observer->getTransport()->getHtml(); // should be the first statement

// now you can do what you want, create other blocks, modifiy $html ...

$observer->getTransport()->setHtml($html); // should be the last statement

Magento-Entwicklung mit Vagrant – Teil 4: Puppet – Provisioning für Fortgeschrittene

Wie in den vorigen Teilen der Serie angedeutet, ist der nächste Schritt, ein Provisionierungs-Tool zu nutzen, also ein Tool zur Automatisierung von Infrastruktur, mit dem z.B. Entwicklungs-, Test- und Produktiv-Umgebungen synchron konfiguriert werden können. Dieses ersetzt weitestgehend die Shell-Skripte zur Einrichtung der VM durch eine deklarative Sprache zur Definition des gewünschten Zustands der Systeme. Dieser Unterschied ist entscheidend: wir definieren nicht länger eine Abfolge von Befehlen (also, WIE der Zustand erreicht werden soll), sondern den Zustand selbst, und Puppet kümmert sich um die jeweils notwendige Ausführung.

Populäre Alternativen zu Puppet sind Chef und Ansible (beide in Python geschrieben). Ich habe mich für Puppet entschieden, aus folgenden Gründen:

  1. es läuft auf Ruby, genau wie Vagrant, also eine zusätzliche Technologie weniger
  2. es ist für alle gängigen Plattformen verfügbar, läuft also auch unter Windows
  3. das GUI Tool PuPHPet ermöglicht das Konfigurieren von Vagrant Boxen für PHP Anwendungen (und mittlerweile auch Ruby, Python, NodeJS) in kürzester Zeit und ohne die Syntax der Puppet DSL kennen zu müssen.

Use PuPHPet for Magento

Weiterlesen auf integer-net.de

Magento Tutorial: Wie man Increment Models nutzt, um IDs zu generieren (oder SKUs)

Hast du dich je gefragt, wie Magento die increment_id Werte für Bestellungen, Rechnungen etc. generiert und wie man diesen Mechnismus nutzen oder erweitern kann? Vielleicht hast du die eav_entity_store Tabelle entdeckt, die die jeweils letzte increment id pro Entity-Typ und Store enthält, wobei je Store ggf. ein unterschiedlicher Präfix verwendet wird:

mysql> select * from eav_entity_store;
+-----------------+----------------+----------+------------------+-------------------+
| entity_store_id | entity_type_id | store_id | increment_prefix | increment_last_id |
+-----------------+----------------+----------+------------------+-------------------+
|               1 |              5 |        1 | 1                | 100000090         |
|               2 |              6 |        1 | 1                | 100000050         |
|               3 |              8 |        1 | 1                | 100000027         |
|               4 |              7 |        1 | 1                | 100000005         |
|               5 |              1 |        0 | 0                | 000000011         |
|               6 |              5 |        2 | 2                | 200000001         |
|               7 |              5 |        3 | 3                | 300000002         |
|               8 |              8 |        3 | 3                | 300000001         |
|               9 |              6 |        3 | 3                | 300000001         |
+-----------------+----------------+----------+------------------+-------------------+
9 rows in set (0.00 sec)

In diesem Artikel erkläre ich, wie dieses System für andere Entities genutzt werden kann.

Zunächst mal, die Standard-Methode funktioniert nur mit EAV Entities, nur mit einem Attribut pro Entity und dessen Name muss increment_id sein. Ich erkläre gleich aber noch, wie diese Beschränkungen umgangen werden können.

Continue reading “Magento Tutorial: Wie man Increment Models nutzt, um IDs zu generieren (oder SKUs)”

Mage Unconference 2015 – 7.-8. März – Berlin

Mage Unconference 2015

Vom 7. bis 8. März veranstaltet FireGento die erste Mage Unconference für Kunden, Händler, Anbieter, Agenturen, Provider – und natürlich – auch Entwickler. Der Inhalt der Unconference wird ganz alleine von Dir und den anderen Teilnehmern festgelegt.

>>> Mach mit und sei Teil der Community vom 7. bis 8. März 2015 in Berlin! <<<

Ich bin dabei und hoffe auf regen Austausch. Wer Interesse hat, sollte nicht zu lange zögern, bevor die Veranstaltung wegen zu weniger verkaufter Tickets abgeblasen wird!

Magento-Entwicklung mit Vagrant – Teil 3: Projektstrukturen für Magento

Im ersten Teil der Artikelserie zu Magento mit Vagrant habe ich Vagrant und die automatische Synchronisation mit Rsync vorgestellt, im zweiten Teil ein einfaches Basis-Setup der Vagrantbox für Magento. In diesem Teil soll es nun um die Projektstrukturierung gehen.

Mögliche Strukturen, aufbauend auf dem Basis-Vagrant-Setup:

Eigener Code separiert von Core und Extensions in src/

Das meiner Meinung nach ideale Setup habe ich im letzten Beitrag bereits beschrieben:

Die hier vorgestellte Struktur empfehle ich für neu entwickelte Shops. Mögliche Alternativen werden in einem separaten Beitrag erläutert. Der Quellcode verteilt sich auf folgende Verzeichnisse:

Verzeichnis Inhalt
/.modman Magento-Extensions
/src Projektspezifischer Code (inkl. gekaufter Extensions)
/vendor Nicht-Magento-spezifische Bibliotheken
/www Magento-Core

Durch Modman werden auf der Vagrantbox zusätzlich Symlinks in .modman (nach src) und www (nach .modman) erstellt.

In /www/ gibt es also keinerlei custom code, alles kommt mit Composer und Modman entweder aus /vendor bzw. /.modman (für fremden Code und eigene, projektübergreifende Module) oder aus /src (für eigenen, shop-spezifischen Code).

Weiterlesen auf integer-net.de

Magento-Entwicklung mit Vagrant – Teil 2: Beispiel-Setup mit Shell-Skripten

Vagrant + Magento

Im ersten Teil der Artikelserie zu Magento mit Vagrant habe ich Vagrant und die automatische Synchronisation mit Rsync vorgestellt. Nun kommen wir zu einem konkreten Setup der Vagrantbox für Magento.

Für das Provisionieren (also automatisches aufsetzen) der Box nutzen wir Shell-Skripte. Für Fortgeschrittene komme ich im letzten Teil der Serie zu einem anspruchsvolleres Setup mit Puppet und werde auch eine einsatzfertige Magento-Box veröffentlichen.

Zum Einstieg in Vagrant empfehle ich allerdings die hier vorgestellte Variante zu übernehmen und ein wenig mit der Konfiguration zu experimentieren. Sie steht vollständig auf Github zur Verfügung. Auch wenn das GUI Tool PuPHPet die Puppet-Konfiguration kinderleicht macht und man die Puppet DSL (Domain specific language) so nicht kennen muss, holt man sich zusätzliche Komplexität ins Haus, was im Fehlerfall einige Stunden und Frustration kosten kann.

Weiterlesen auf integer-net.de

Magento: Secure Base URL für eigene Controller verwenden

Die Frage tauchte auf Magento.SE auf und es sollte bekannter sein, wie kinderleicht dies eigentlich ist.

Schaut man sich core/Mage/Checkout/etc/config.xml an, kann man sehen, wie Magento für den Checkout definiert, dass die “Secure Base URL” genutzt wird, also HTTPS:

<frontend>
    <secure_url>
        <checkout_onepage>/checkout/onepage</checkout_onepage>
        <checkout_multishipping>/checkout/multishipping</checkout_multishipping>
    </secure_url>
</frontend>

Das ist auch schon alles. Auf die selbe Weise können eigene Controller konfiguriert werden, die sichere Basis-URL zu verwenden. Anschließend wird Mage::getUrl() die sichere URL für die konfigurierten Routen zurückgeben und Requests auf die ungesicherten URLs werden weitergeleitet.

Magento Bündelprodukte: Staffelpreise der einfachen Produkte nutzen

Mage_Bundle_Model_Product_Price.php

Ein Magento-Bug, der seit Jahren immer wieder im Magento-Forum und auf StackOverflow kursiert, ist, dass Staffelpreise mit Bündelprodukten nicht sauber zusammen funktionieren. Mit der Zeit gab es einige Verbesserungen, aber Stand heute (Magento CE 1.9) funktioniert folgendes immer noch nicht:

  • Einzelprodukte mit Staffelpreisen und Qty > 1 im Bündel
  • “Preis wie konfiguriert”-Anzeige in Bündelprodukten mit Staffelpreisen

Es gibt einige Vorschläge im Netz aber mehr Fragen als Antworten, also haben ich eine (hoffentlich) vollständige Lösung erstellt, die ohne Core-Hacks und nur mit einem minimal-invasiven Class Rewrite auskommt. Bis Magento es also selbst in den Griff bekommen hat, kann dieses Modul verwendet werden, um Bundles mit Staffelpreisen zu ermöglichen:

SGH_BundleTierPrices (getestet in Magento CE 1.8 und Magento CE 1.9)

Continue reading “Magento Bündelprodukte: Staffelpreise der einfachen Produkte nutzen”