Web / Entwicklung

Während des diesjährigen Magento Developer Paradise auf Ibiza wurde an einem Abend ein Hackathon veranstaltet, bei dem Teams innerhalb von 4 Stunden kleine Magento Projekte umsetzen konnten.

Zusammen mit Karsten haben wir als Team 2Boys1Shop die Extension Twoboysoneshop_Configr realisiert. Dabei handelt es sich um eine Übersicht über die Konfigurationen aller Stores einer Installation, um diese dann einfach miteinander vergleichen zu können.

Gerade bei Installationen mit 5 oder mehr Websites/StoreViews ist es nahezu unmöglich den Überblick zu behalten, wie welcher Shop konfiguriert ist, vor allem wenn für diese unterschiedliche Sprachen, Währungen, Ländern, Zahlungsarten etc eingestellt sind. Zudem hat der Kunde oftmals die Möglichkeit direkt auf dem Produktionssystem die Konfiguration zu verändern und bei der Fehleranalyse ist es dann hilfreich sofort die getätigten Änderungen identifizieren zu können.

Die Extension bietet bislang folgende Features:

Übersicht:
- alle Werte aller Stores anzeigen
- Stores auswählen, die man miteinander vergleichen möchte
- farbliche Hervorhebung der überschriebenen Werte (konfigurierbar)
- Suche nach Config Keys
- Tooltips für die Werte aller Scopes
- Optionale Berechtigungsprüfung, um nur erlaubte Configbereiche anzuzeigen

Verlauf:
- Konfigurationsänderungen aufzeichnen
- Alle Änderungen in einer Übersicht anzeigen (wer hat wann welchen Werte worauf geändert)

Das Feedback nach der Vorstellung unseres Projektes auf der Konferenz hat gezeigt, dass viele Agenturen Interesse an solch einer Extension haben, was uns ermutigt diese weiter auszubauen.

Link zur Extension auf Github: Twoboysoneshop_Configr

Wir hatten kürzlich das Problem, dass wir einen Magento Shop so konfigurieren sollten, dass sich der Steueranteil abhängig vom Steuersatz des Lieferlandes ändern soll.

Wenn man die Produktpreise als Netto im Admin pflegt ist dies kein Problem (wie z.B. in den USA), aber wenn man Wert auf ordentliche Preiswerte legt, sollte man diese in Brutto anlegen. Im Warenkorb sollen ebenfalls ausschließlich Bruttopreise angezeigt werden, wie dies in Deutschland üblich ist.

Problem

Wenn man nun für die diversen Zielländer eigene Steuersätze definiert macht Magento folgendes:
1. Vom Bruttopreis des Produktes den Steuersatz des als Steuer-Ursprung des Shops definierten Landes (hier Deutschland, also 19%) abziehen um den Nettopreis zu erhalten
2. Den Steuersatz des Ziellandes aufrechnen (z.B. 21% für Belgien)

Daraus ergibt sich beispielsweise für einen vorherigen Bruttopreis von 24€ nach der Umrechnung ein Bruttopreis von 24,40€ für Belgien.
Dies ist natürlich völlig korrekt, wenn man den gleichen Nettopreis beibehalten möchte, so dass für alle Lieferländer der Umsatz nach Steuerabzug gleich bleibt.

In unserem Fall aber sollte der Bruttopreis immer gleich bleiben und nur der enthaltene Steueranteil sollte dem Lieferland angepasst werden, ungeachtet der Tatsache, dass sich dadurch der Nettopreis und damit auch der Umsatz ändern kann.

Lösung

Um dies zu erreichen muss Magento dazu gezwungen werden (im o.g. Schritt 1.) statt dem Prozentsatz des Steuer-Ursprungs den Prozentsatz des Ziellandes für die Nettoberechnung zu verwenden, damit beim anschließenden Aufrechnen des neuen Steuersatzes wieder der ursprüngliche Bruttobetrag herauskommt.

Um dies zu erreichen kann man die Methode Mage_Tax_Model_Calculation::getStoreRate() wiefolgt überschreiben:



Zunächst wird standardmäßig der Steuersatz des Steuer-Ursprungs ermittelt.

Wenn nun
1. für den Store die Steuerberechnung anhand des Versandlandes konfiguriert ist
2. eine Versandadresse und damit ein Zielland vorhanden ist
3. die Preise für den Store in Brutto gepflegt werden
4. der vorher ermittelte Steuersatz nicht 0% ist
wird der Steuersatz des Ziellandes ermittelt um diesen für die Berechnung des Nettopreises zu verwenden.

Die 4. Bedingung hat den Grund, dass bei Ländern oder Bedingungen, wo keine Umsatzsteuer ausgewiesen wird (z.B. bei der Schweiz oder B2B Bestellungen) weiterhin der Steuersatz des Steuer-Ursprungs für die Nettoberechnung verwendet werden soll.

Wie handhabt ihr solche Besonderheiten bei der Steuerberechnung?

Einer der großen Schwachpunkte von Magento ist, dass es trotz damaliger Ankündigung offensichtlich nicht Unit-getestet ist.
Wer bereits das Vergnügen hatte sich etwas länger mit dem Code von Magento zu befassen wird feststellen, dass es äußerst unwahrscheinlich ist, dass Varien (bzw. Magento Inc.) wenigstens intern über eine Testsuite verfügt. Die Masse an Bugs und die Softwarearchitektur lassen zumindest nicht darauf schließen.

Nun möchte man aber durchaus selbstgeschriebene Module durch UnitTests abdecken, die exzessive Verwendung von Singletons macht dies allerdings weitestgehend unmöglich.

Da die Businesslogik der Applikation meist ordentlich in Models oder Helper gekapselt ist, möchte man diese z.B. durch vorkonfigurierte Objekte oder MockObjects ersetzen um diverse Szenarien abzubilden und automatisiert zu testen.

Hierfür habe ich kürzlich das Nutwerk_MageTestable Modul auf github veröffentlicht, welches schlichtweg gepatchte Mage.php Klassen für verschiedene Magento Versionen bereitstellt, mit denen UnitTests zumindest ermöglicht werden.

Um die Rundungsfehler zu beheben, die vor allem dann auftreten, wenn man einen Shop mit Bruttopreisen konfiguriert und im Warenkorb oder zusätzlich einen Gutschein einlöst, muss man einfach nur die Rundungsgenauigkeit erhöhen.

Da alle Datenbankfelder, die Preise speichern, ohnehin als Decimal(12,4) angelegt sind, kann man dies auch nutzen und die standardmäßig eingestellte Rundungsgenauigkeit von "2" auf "4" erhöhen. Bei nur zwei Nachkommastellen kommen recht schnell Rundungsfehler zustande wenn mit mehreren gerundeten Werte gerechnet wird, wie man sich leicht vorstellen kann.

Lösung:
In der Klasse Mage_Core_Model_Store den zweiten Parameter verändern:

public function roundPrice($price)
{
//return round($price, 2);
return round($price, 4);
}


Im Frontend werden ohnehin alle Preisangaben durch den formatPrice() Filter auf zwei Nachkommastellen gerundet, so dass der Kunde nichts davon mitbekommt. Das einzige, was eventuell problematisch sein kann ist, dass Preise, die direkt aus der Datenbank oder über das Model exportiert und an Schnittstellen übergeben werden Fehler verursachen, wenn nun plötzlich vier Stellen nach dem Komma ausgegeben werden.
Allerdings sind mir bis jetzt keine Fehler diesbezüglich in den gängigen Extensions oder Zahlungsschnittstellen begegnet.

Dies ist lediglich eine Notiz an mich, falls es mal wieder partout nicht funktioniert sich in der lokalen Entwicklungsumgebung im Adminbereich einzuloggen.

Das Problem tritt meistens auf, wenn man Magento in einem Unterverzeichnis des Document Roots betreibt. Auf Grund der Cookie Domain ist es dann unter Umständen nicht möglich sich einzuloggen. Man erkennt es daran, dass man keine Fehlermeldung erhält und einfach wieder auf das Loginformular zurückgeleitet wird.

Variante1:
In der Methode Mage_Core_Model_Session_Abstract_Varien::start() ein paar Cookie Parameter leeren

// session cookie params
$cookieParams = array(
'lifetime' => $cookie->getLifetime(),
'path' => $cookie->getPath(),
'domain' => '', //$cookie->getConfigDomain(),
'secure' => '', //$cookie->isSecure(),
'httponly' => '', //$cookie->getHttponly()
);


Variante2:
In der Datenbanktabelle core_config_data die entsprechenden Werte setzen

path: web/cookie/cookie_domain | value: -leer-
path: web/cookie/cookie_httponly | value: -leer-


Nachdem ich meine fast einjährige, ungeplante Blogpause vor kurzem mit einem Artikel zu Magento beendet habe, war es nun an der Zeit endlich das Blog-Theme umzugestalten.
Somit sollte jetzt alles etwas übersichtlicher und besser lesbar sein, wobei neben neuem Layout auch einige unnötige Elemente entfernt wurden. Mal schauen inwieweit mich das motiviert ab und zu etwas zu bloggen, was im Gegensatz zum twittern und facebooken heutzutage ja doch etwas mehr Aufwand bedarf

Möchte man in Magento eine Warenkorbregel im Stile von "Versand ist kostenfrei, wenn der Bestellwert größer als 50€ ist" einzurichten, gibt es ein paar Dinge zu beachten.

Die gleiche Aufgabe hatte ich kürzlich und es wollte einfach nicht funktionieren. Die Regel anfürsich schien korrekt zu sein, jedoch wurden immer die konfigurierten Table-Rates als Versandkosten verwendet statt dem kostenfreien Versand.

In den vergangenen Tagen habe ich mich mit der Implementierung eines ersten Prototyps beschäftigt.

Versuchsaufbau

Das Szenario ist zunächst so trivial wie möglich, zeigt jedoch bereits an welchen Stellen Probleme auftreten werden, so dass man diese schon frühzeitig bei der Architekturüberlegung berücksichtigen kann.

Im Prinzip sieht das Szenario wie folgt aus:

• Sender schickt Message an Middleware Server
  
• Server nimmt Message entgegen und legt sie in eine Queue
  
• Engine holt Message aus Queue und schickt sie an Empfänger
  
• Empfänger nimmt Message entgegen und speichert sie im Filesystem
  

Dieser einfache Aufbau beschränkt sich also erst einmal auf die asynchrone Verarbeitung von Testnachrichten vom Sender über die Middleware bis zum Empfänger.
Die verwendeten Komponenten werden im Folgenden näher beschrieben:

Bei meinem früheren Arbeitgeber hatte ich die Gelegenheit Projekte mittels SAP Exchange Infrastructure zu realisieren.
Bei dem Produkt handelt es sich um eine in Java und ABAP implementierte Message-orientierte Middleware, die es ermöglicht eingehende Nachrichten der verschiedensten Formate in andere Formate zu transformieren und an beliebige Empfänger zu verteilen, also ideal zun Datenaustausch in einer heterogenen Umgebung.

Da ich von den Möglichkeiten dieser Software ziemlich beeindruckt war, es jedoch nicht realistisch ist, sich so ein Teil zu lizensieren, schaute ich mich nach ähnlichen Lösungen um. Da gäbe es zum Beispiel IBM WebSphere, welches für den privaten Gebrauch aber ebenso ausscheidet.

Nachdem fukami beim letzten Bonner WebMontag erläutert hatte was CSRF ist und was man alles damit anrichten kann, war mir zunächst nicht ganz klar, wie so etwas in der Praxis ausgenutzt wird und welche Schutzmaßnahmen man dagegen implementieren kann.

Netterweise demonstrierte mir mein Kollege Lary Strojny anhand meines Projekts todoyo.de wie so etwas genau aussieht. Er schickte mir einen unscheinbaren Link, den ich natürlich sofort öffnete und gelangte auf eine einfache Seite mit 3 Images, welche allerdings nicht richtig geladen wurden. Die Bilderpfade lauteten in etwa "http://todoyo.de/task/delete/id/1234". Wäre ich nun bei todoyo eingeloggt gewesen, wären ohne, dass ich etwas gemerkt hätte, einige meiner Aufgaben gelöscht worden. Die IDs der Aufgaben besorgte er sich aus der öffentlichen todoyo-Entwicklerliste. Glücklicherweise war ich nicht eingeloggt

Dadurch wurde mir schlagartig klar, wie CSRF Angriffe funktionieren und welchen Schaden man damit alles anrichten kann, wenn die Seite nicht entsprechend geschützt ist.

Wie sehen nun die Gegenmaßnahmen aus, um so etwas zu verhindern? Folgende Schritte habe ich unternommen:

Mittlerweile sind auch die Aufzeichnungen einiger Vorträge des WebMontags vom 7. April online:

- Christian Scholz - Data Portability
- Roland Schäfer und Nico Zorn - Produki.de
- Thomas Schindler - Cellcast.de
- Philipp Strube - myPEAK.net

Leider scheinen die Vortragenden zu den Themen "CSRF" (fukami) und "Das chinesische Web" (Oliver Ueberholz) einer Veröffentlichung nicht zugestimmt zu haben, schade.

UPDATE: Tollerweise habe ich gerade ein Video gefunden, wo Oliver quasi den gleichen Vortrag hält wie beim WebMontag

Seit ca 2 Wochen arbeite ich an einem neuen Projekt, welches ich auf den Namen "todoyo - notieren. erledigen. freigeben." bzw auf Englisch "todoyo - note. do. share" getauft habe.
Wie man am Namen erkennen kann geht es um das Thema ToDo-Listen.

Wie kam es dazu?

Vor mittlerweile genau einer Woche war ich zum ersten Mal bei einem Webmontag. Dieser fand in Bonn im Café Podcast statt. Das ist ein nettes Café, welches mit einer kleinen Bühne für Vorträge ausgestattet ist und sich somit optimal für solch eine Veranstaltung eignet.

Anwesend waren geschätzte 40-50 Leute, was die Erwartungen übertraf. Meine Kollegen Dominik, Ben und Jan Manuel waren ebenfalls am Start.

Folgende Themen/Projekte wurden in den Sessions vorgestellt: myPEAK.net, cellcast.de, produki, DataPortability Project, CSRF, Internet in China.

Am 26/27. April diesen Jahres werde ich das erste Mal das Vergnügen haben an einer Unconference teilzunehmen.
Genauer gesagt geht es mit meinem Kollegen Lars Strojny zur PHP Unconference nach Hamburg.

Nachdem ich in den letzten Jahren Entwickler-Veranstaltungen wie Multimediatreff, frOSCon und PHP Weekender besucht habe, wird dies nun meine erste Unconference sein. Ich weiß noch nicht genau was mich dort erwartet und wie das Ganze ablaufen wird, aber von der Beschreibung her scheint es ein angenehmes Zusammentreffen von Gleichgesinnten und bekannten Personen aus der PHP-Welt zu werden, wobei mehr oder weniger spontan zahlreiche Sessions zu den verschiedensten Themen rund um Softwareentwicklung gehalten werden.

Wahrscheinlich werde ich mit Lars zusammen unsere Business-Erweiterung zum Zend Framework vorstellen bzw. damit verbundene Themen. Ansonsten interessieren mich natürlich alles rund um Communities, Social Networking und das Zend Framework. Ob ich daraus selbst noch eine Session basteln könnte werden die nächsten Wochen zeigen.

Bin gespannt

Tulpe hat eine neue Version seiner netten Debug-Bebliothek veröffentlicht, zu finden unter http://www.atomar.de/debuglib/.

Das Tool ist sehr schick um alle Variablen, die während der Scriptlaufzeit gesetzt wurden, strukturiert auszugeben. Arrays und Objekte werden dabei verschachtelt dargestellt wobei einige Formatierungsoptionen zur Verfügung stehen.

Auf jeden Fall um einiges schicker als echo, var_dump oder print_r