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”

SVG Bilder in Magento Uploader erlauben

Wer die erlaubten Bilddatei-Typen für Produktbilder in Magento ändern will, wird feststellen, dass sie hart kodiert sind in Mage/Catalog/Model/Product/Attribute/Backend/Media.php und Mage/Adminhtml/controllers/Catalog/Product/GalleryController.php

Ich habe allerdings einen Observer gefunden, mit dem sie zusammen mit anderen Uploader-Konfigurationen angepasst werden können. Dieser Beitrag beschreibt, wie eine Extension für diesen Zweck erstellt werden kann, Grundlagen der Magento Extension-Programmierung werden vorausgesetzt.

Continue reading “SVG Bilder in Magento Uploader erlauben”

Zugriff auf Magento Admin Session aus Frontend

Das nächste mal, wenn ich etwas im Magento Frontend nur für Admin-User zeigen möchte, wird Alan Storms Modul Magento_CrossAreaSessions nützlich sein! Das Thema hat mir in der Vergangenheit schon Kopfschmerzen bereitet. Mehr auf Magento Quickies oder GitHub: Magento_CrossAreaSessions

Hintergrund: Magento trennt adminhtml und frontend Sessions strikt, daher ist es kein trivialer Task, auf einer Frontend-Seite auf die Backend-Session zuzugreifen.

Das Modul erlaubt das Lesen von rohen Session-Daten und Verarbeitung von ACL-Regeln, was für die meisten Fälle ausreichen sollte.

Magento-Entwicklung mit Vagrant – Teil 1: Vagrant-Einführung

Vagrant + Magento

Vagrant ist ein Tool, das portable virtuelle Entwicklungsumgebungen ermöglicht. Wenn an verschiedenen Rechnern und/oder von verschiedenen Team-Mitgliedern an einem Projekt gearbeitet wird, ist somit eine einheitliche Umgebung sichergestellt. Die Einrichtung muss nur ein einziges Mal erfolgen und kann beliebig oft reproduziert werden.

Aber es ist auch für einzelne Entwickler interessant, die an unterschiedlichen Projekten arbeiten. Häufig sind z.B. auf den Produktivsystemen unterschiedliche PHP-Versionen installiert, es werden bestimmte Extensions benötigt oder unterschiedliche Systemkonfigurationen. Gerade bei der Entwicklung mit PHP, dessen Verhalten an vielen Stellen von globaler Konfiguration abhängt, gibt es so oft Fehler aufgrund unterschiedlicher Systeme.

Mit Vagrant lässt sich die gesamte Umgebung für jedes Projekt einzeln definieren und auch versionieren (Konfigurationsdateien im Git-Repository). Auch wird das eigene System weniger „vollgemüllt“, mit Software die man für irgendein Projekt mal benötigt hat. Im Idealfall spiegelt die Umgebung das Produktivsystem 1:1 wieder.

Say goodbye to “works on my machine” bugs. – http://docs.vagrantup.com/v2/why-vagrant/

Diese Artikelserie soll insbesondere Magento-Entwickler Schritt für Schritt an Vagrant heranführen, am Ende steht ein Basis-Setup für Magento-Projekte.

Weiterlesen auf integer-net.de

Das Magento buyRequest Objekt – eine Referenz

Wer im Zusammenhang mit Bestellungen schon einmal im Magento-Quelltext oder der Datenbank gestöbert hat, dem ist vermutlich der Parameter $buyRequest in vielen Methoden bzw. die in quote items und order items gespeicherte Option info_buyRequest aufgefallen, deren Sinn nicht direkt offensichtlich ist, da scheinbar redundante Informationen enthalten sind. Es gibt dazu auch keine eigene Model-Klasse, es ist einfach ein Varien_Object bzw. in der Datenbank ein serialisiertes Array.

Beispiel:

mysql> select code,value from sales_flat_quote_item_option where option_id=2359;
+-----------------+------------------------------------------------------------------------------------------------------------+
| code            | value                                                                                                      |
+-----------------+------------------------------------------------------------------------------------------------------------+
| info_buyRequest | a:4:{s:4:"uenc";s:140:"[...],,";s:7:"product";s:4:"5000";s:15:"related_product";s:0:"";s:3:"qty";s:1:"1";} |
+-----------------+------------------------------------------------------------------------------------------------------------+

Kurz gefasst: Das $buyRequest Objekt repräsentiert die Kundenanfrage, die durch Klick auf „In den Warenkorb“ zustandekommt, alle weiteren Daten sind von diesem Objekt ableitbar. Es dient sozusagen als Generator für Quote Items. Die minimal notwendigen Daten sind also die Produkt ID (product) und Menge (qty).

Wozu wird das $buyRequest Objekt benötigt?

Es wird zum Beispiel beim hinzufügen eines Produkts zur Merkliste (Wishlist) angelegt, so dass es von dort mit der selben Konfiguration einfach in den Warenkorb gelegt werden kann. Beim „rekonfigurieren“, also dem Bearbeiten eines Items vom Warenkorb aus wird der buyRequest dem Produkt View übergeben, um alle Optionen vorauszuwählen.

Auch für Wiederkehrende Profile (recurring profile) und Nachbestellen (reorder) werden die $buyRequest Objekte „wiederverwendet“, um eine neue Bestellung zu generieren.

Anwendungsfälle

Einige Beispiele, wann man sich mit dem buyRequest beschäftigen sollte:

Continue reading “Das Magento buyRequest Objekt – eine Referenz”

Magento Layout: getChildHtml() mit leerem Ergebnis

Das Problem: Mysteriöserweise liefert getChildHtml() im Template ein leeres Ergebnis, obwohl die Kind-Blöcke offenbar erzeugt wurden.

Die Lösung: Blöcke im Magento-Layout sollten immer einen Namen haben. Ohne name-Attribut werden sie zwar angezeigt, Unter-Elemente können ihnen aber nicht zugeordnet werden und bleiben “verwaist”.

Verantwortlich ist die Methode Mage_Core_Model_Layout::_generateBlock(). Wie man sieht, wird der Parent Block nur zugewiesen, wenn er einen Namen hat:

            $parentName = $parent->getBlockName();
            if (!empty($parentName)) {
                $parentBlock = $this->getBlock($parentName);
            }

Man beachte, dass $parent hier ein XML-Knoten ist und kein Block-Objekt. Es hilft also nichts, dass Blöcke ohne Namen automatisch einen Namen wie ANONYMOUS_1 erhalten. Die Zuordnung geschieht über das name-Attribut des Knotens, so dass sie gleichermaßen für <block> wie für <reference> Knoten funktioniert.

Magento Testing: Formulare mit einem Klick ausfüllen

Wer kennt es nicht: Beim manuellen Testen von Funktionen wie dem Checkout als Gast müssen jedes Mal mühsam alle Formularfelder ausgefüllt werden. Mit Chrome Autocomplete oder “test”, Strg + C, Strg + V geht das noch einigermaßen schnell, nervt aber immer noch ein wenig. Und was, wenn die Testdaten noch einigermaßen sinnvoll sein sollen und nicht jedes Mal gleich?

Inspiriert von diesem Artikel auf css-tricks.com habe ich ein kleines Magento-Modul entwickelt, das das Ausfüllen von Magento-Formularen mit Dummy-Daten mit einem Mausklick ermöglicht. Aktuell implementiert ist es für Rechnungsadresse und Versandadresse.

Hier geht es zum Github-Repository: SSE_FormFiller

Und so sieht es aus:

Screenshot: Formulare im Checkout

Konfiguration

Continue reading “Magento Testing: Formulare mit einem Klick ausfüllen”

Formular-Probleme nach auf Magento Update auf CE 1.8.1 oder EE 1.13.1 (Login, Warenkorb)

Wenn nach einem Magento Update auf CE 1.8.1 oder EE 1.13.1 die Login-Formulare im Frontend nicht mehr funktionieren, muss das genutzte Theme aktualisiert werden. Die Formulare benötigen nun einen Form Key, fehlt dieser schlägt die Validierung im Controller fehl. Das selbe gilt für den “Warenkorb aktualisieren” Button in cart.phtml. Wie das gefixt werden kann, siehe hier:


http://blueclawecommerce.co.uk/blog/fix-customer-cannot-login-to-magento-1-8-1/

Optimal ist natürlich, wenn das Theme so wenig wie möglich an Core-Templates überschreibt und Änderungen weitestgehend mit Layout-Updates in [theme]/local.xml und CSS vornimmt.