Shopware Migrationen für eigene Deployments “nutzen”

Laravel Migrations

Ich stehe ja tierisch auf die Datenbank-Migrationen von Laravel. Ein PHP-Prozess der durch einen Ordner iteriert und weiß, welchen Dateien er schon importiert hat und welche nicht. Damit aber nicht genug: Mit dabei kommt eine Konsolen-Anwendung, die uns im Release-Fall bei Migrationen unterstützt und Migrationen auch wieder resetten kann.  So mag ich das. Der Prozess ist robust und an Feinheiten wie eine konfliktfreie Namenskonvention oder an eine Boilerplatte zur Klassenerstellung wurde auch gedacht.

Shopware Migrations

Einen ähnlichen Prozess finden wir auch im “internen” Entwickler-Deployment von Shopware. Die build/ApplyDeltas.php durchläuft den Ordner _sql/migrations und wendet alle gefundenen Migrations auf die Datenbank an. Die Reihenfolge wird von dem numerischen Präfix im Dateinamen der jeweiligen Klasse bestimmt, wie z.B. “101-add-extended-editor-field.php“. Dieses Präfix wird dann wiederum auch als ID in der Datenbank-Tabelle s_schema_version gespeichert, welche als “Historie” der Migrationen dient.

“Probleme” und Lösung

Gerne würde ich diesen Mechanismus auch für meine eigenen Datenbank-Deployments verwenden, aber leider “traue” ich mich das nicht. ;) Ja, Shopware fängt zwar erst bei ID 101 an, aber trotzdem kann ich nicht 100%-konfliktsicher eine eigene Migration-Klasse  mit entsprechender ID einfügen, da ich nicht weiß, ob diese von Shopware selbst belegt wird. (Hier hätte ich mir eine flexiblere Namenskonvention gewünscht) Einen eigenen Ordner und entsprechende Datenbank-Historie kann ich aber leider beim Shopware\Components\Migrations\Manager auch nicht angeben.

Als Lösung dieses Dilemmas habe ich die Shopware-Struktur entsprechend abgeleitet und euch unter https://github.com/b3nl/sw-migrations und als “Composer-Katalog”-Eintrag bereitgestellt. Die Struktur ist im Prinzip die Selbe wie beim Shopware-Original, nur dass Ihr als Konsolenparameter zusätzlich noch einen eigenen Migrationsordner und eine eigene Versionshistorie (per Tabellen-Suffix) angeben könnt – den Shopware-Basis-Ordner müsst Ihr in dem Fall aber leider angeben, da Ihr meine Komponente ja auch außerhalb von Shopware installieren könntet.

(Über Remote Inclusions braucht Ihr euch da eigentlich keine Sorgen machen, da der Pfad eigentlich nur per Konsole gesetzt werden kann. Bei Bedenken trotzdem bitte melden!)

Viel Spaß damit!

Shopware-Sessions über Redis

Hallo zusammen, da mich OXID eShop aktuell weniger reizt, bin ich sehr aktiv bei Shopware unterwegs. Bei Shopware fehlen mir leider einige Dinge in der Community Edition, die ich angefangen habe selbst nachzurüsten. Als erstes bin ich eine “fehlende” Session-Replikation über Redis angegangen. Da wir bei Shopware über einen Service-Container und entsprechende Strukturen verfügen, ist es leicht das Thema in Shopware umzusetzen. Shopware (5) selbst speichert Sessions über Zend_DB in der Datenbank. In verteilten Umgebungen könnte mir das eigentlich schon genug sein, aber da ich Schreibzugriffe auf der Datenbank eigentlich verhinden möchte, ist das für mich keine Lösung. Also zack, n Redis für die Session angedockt und ran an die Arbeit.

(mehr …)

Promises in AngularJS ab Version 1.2

Ich habe gerade eine etwas ältere SAP von uns getestet und mir ist leider schmerzlich aufgefallen, dass manche asynchronen Logiken für AJAX-Requests und Web SQL-Callbacks nicht mehr richtig funktionieren. Ich fand die Art und Weise wie man damals mit Angular asynchrone Logiken in eigentlich synchrone Logiken einfügen konnte richtig bombe, um nicht zu sagen +1.
Im Tutorial für eigene AJAX/REST-Aufrufe wird dieser Eindruck immer noch impliziert. Um es kurz zu machen, anstatt das man irgendwelche Callbacks registriert, weist man einfach das Ergebnis von einem Promise einer Variablen zu und Angular macht den Rest, ohne den eigentlichen Programmierablauf durch einen Callback zu “unterbrechen”.

Ich habe mir die Finger wund gegoogelt und Treffer wie diesen gefunden: http://markdalgleish.com/2013/06/using-promises-in-angularjs-views/. Die meisten Suchtreffer erklären Promises immer noch genau so, wie ich sie angewendet habe. Nach einer Iteration unterschiedlichster Keywords bin ich dann doch zum Glück noch auf einen Eintrag beim stackoverflow gestoßen, der mich auf den Changelog von angular.js hinwies, und folgenden Punkt: Promises müssen seit Angular 1.2 händisch aufgelöst werden. Wir müssen also doch wieder irgendwie Callbacks einbauen.

Also, falls Ihr auch über dies Problem stoplert, vielleicht hilft euch der folgende Gist. Gemäß Angular müssen wir nun wieder ganz normal zu “then()” greifen:

Weitere PostProcessings im Fatchip Artikel Exporter

Ich gehöre in der Regel zu den OXID-Entwicklern, die eigentlich keine verschlüsselten Module einsetzen. Meine Shops sind meistens so stark angepasst, dass ein blindes Integrieren nicht in Frage kommt. Solange der Modulanbieter keinen Mist baut, interessiert mich nicht, wie der Quellcode qualitativ aussieht oder ob ich das Modul auch selbst hätte machen können. Ich möchte aber im Voraus wissen und/oder selbst kontrollieren können, welche Seiteneffekte es mit einem Modul geben könnte, wie das Modul angepasst werden kann und/oder gemergt werden muss. Und auch wenn ich Bugs vermute, möchte ich diese vorher sauber recherchieren, um Fehler bei mir auszuschließen und dass der Modulanbieter direkt ordentlich mit der Behebung starten kann.
Daher habe ich mich besonders gefreut, dass die Fatchip GmbH alle Module seit kurzem quelloffen vertreibt.

Passend zu dieser Source-Meldung hatte ich nämlich auch eine Nachfrage zu diesem Modul, und zwar wie weiteres Feld-Post Processing hinzugefügt werden kann. Dieses Post Processing sorgt dafür, dass bei einem Artikel-Export Feldwerte nachträglich noch geändert werden können. In der Dokumentation sind dafür leider keine Infos zu finden. Ich nutze aktuell die Version 1.12.7 des Moduls und hier gibt es nur zwei Callbacks zum Post-Processing, nämlich für eine URL-Encodierung und eine nachträgliche Umwandlung in UTF-8, sollte der Feldwert noch nicht so codiert sein.

Ich benötige aber noch einen Callback, um Smarty-Tags z.B. in der Langbeschreibung zu evaluieren, denn ein Marketplace kann mit diesen internen Smarty-Tags eigentlich nichts anfangen. Ich hoffe euch mit diesem Posting Hilfestellung für eigene Post Processings geben zu können.
(mehr …)

Neues Major-Release von OXID erschienen (4.7, 5.0)

Breaking News. Nach dem OXID-Partnertag 2012 letzte Woche, bei dem wir als Aussteller vertreten waren, hat OXID das dort versprochene Release Datum für die neue große OXID-Version gehalten.

Ihr werdet wahrscheinlich noch keine offiziellen Infos zum Release erhalten haben, aber die Demo-Webs sind bereits aktualisiert. Im Backend der Community-Edition seht Ihr die neue Revision 4.7.0_51243 im Header und auch im SVN kann die neue Version heruntergeladen werden, z.B. die CE mit http://svn.oxid-esales.com/tags/CE-4.7.0-51243.

OXID hat strukturell einiges  aufgeräumt  (sich etwas an Magento angenähert), geupdatet und  ergänzt darunter z.B. die neue Cookie-Richtlinien der EU oder auch die sagenumwobene “Button-Lösung” ;)  weiter verbessert … Der Core ist immer noch nahezu identisch mit der Enterprise Edition, aber hier hat OXID einen deutlicheren Versionssprung nach oben gemacht und titelt daher mit einer neuen Hauptversionsnummer.

Die Enterprise Edition von OXID liegt jetzt in Version 5.0 vor, da man hier nun eine Hochlast-Option mit einer Datenbanklast-Verteilung der Datenbank out of the Box anbietet und außerdem den Reverse Proxy VarnishEdge Side Include“-basiert (ESI) bereits von Haus aus anbindet. OXID liefert dazu auch eine Standard-Konfiguration für euren Varnish-Server mit.

Ein komplett eingestellte Enterprise Edition sollte jetzt alles deutlich wegrocken, was Ihr bisher standardmäßig von OXID gesehen habt!

(Und davon ab, es freut mich besonders, die Unittests wurden auch geupdatet und bieten nun eine leichtere Ergänzung von z.B. Autoloadern in den Testumgebungen).

Viel Spaß damit!

Problem mit OXID-Warenkorb-Modulen und dem WBL_Autoloader gefixt

Es gibt bei OXID zwei mögliche Arten eine Klasse samt deren Module zu laden: Direkt über oxNew() oder über den Autoloader wenn man z.B. Klassenkonstanten aufruft oder “Modul-Erstellungstricks” anwendet. Also beispielsweise

  • einen neuen Backend-View anlegen
  • diesen View von *_parent erben lassen – obwohl der Backend-View kein Modul sondern eine Ursprungsklasse ist …
  • dafür dann in der Moduleinstellung aber z.B. oxadminview für diesen neuen View angeben

= und OXID einfach dynamisch den neuen Backend-View von oxAdminView erben lassen.

Und ein weiteres Beispiel sollte nicht unerwähnt bleiben, nämlich das Laden von Objekten, die (in der Session) serialisiert wurden, welches beim Autoloader Probleme macht. (mehr …)

Tracking der OXID User-ID im WBL Multitracker

Heute mal wieder ein kleines Modul-Update.  Soeben habe ich auf Github einen Callback eingecheckt, mit dem Ihr die ID des aktuellen OXID-Users mittracken könnt. Kann kein User identifiziert werden, wird “-” mitgetrackt. Dies ist z.B. hilfreich, wenn Ihr bei einem User nachhaken wollt, ob es ein Problem beim Checkout gab, sollte der User seinen Warenkorb nicht abgeschlossen haben.

Da dies datenschutztechnisch schon relativ sensibel betrachtet werden muss, ist dies kein Teil von unserem Standard-Setup des WBL_Trackers. Solltet Ihr aber z.B. Piwik auf eurem eigenen Server betreiben, sind euch die Informationen ja eigentlich sowieso bekannt, daher hier also z.B. das Beispiel, wie Ihr die ID des Users in eurem WBL_Tracker – Piwik-Setup erfassen könnt:

Happy Hacking!

Björn

Neues Freifeld für den OXID WBL Multi Tracker

Mal ein kleineres Update zum WBL_Tracker, mit dem Ihr mehrere Webtracking-Anbieter gleichzeitig in eurem OXID-Shop abbilden könnt. Im ersten Posting zu dem WBL_Tracker für OXID hatte ich euch ja bereits gezeigt, dass Ihr mit allen Trackern spezielle Werte mittracken könnt, die eigentlich nicht direkt vom Anbieter bedacht sind, wie z.B. wie viele Suchtreffer Ihr für welchen Suchbegriff im Shop hattet. Hier ein Beispiel aus dem mitgelieferten Piwik-Tracker:

Vergessen zu erwähnen hatte ich dabei, dass unser WBL_Tracker auch bereits ein Tracking für die Zahlungsart einer Bestellung mitbringt, z.B. um diese in einem Piwik-Freifeld zu speichern:

Grade eben habe ich einen weiteren Callback auf Github bereitgestellt, um auch die möglichen Zahlungsarten eines Checkouts in einem Freifeld zu speichern:

Diese Einstellungen sind natürlich bereits getroffen, wenn Ihr unser Piwik-Tracker-Modul frisch installiert.

Viel Spaß damit

Björn

 

Magento vs. OXID, Part 1, Eigene Autoloader

Mit den Postings “Magento vs. OXID” werden wir euch jetzt öfter quälen ;)

Wie man den OXID-Modulen der WBL Konzept ansehen kann, beginnt bei uns die Modularbeit meist mit dem Autoloader, denn wir laden unsere Module mit unserem eigenen Autoloader.

(mehr …)

WBL_Tracker nun auf Github, mit Piwik-Einbindung (U)

“Mal eben n Webtracker einbauen” ist eine oft gestellte Aufgabe für so kleine Agenturen wie meine. Im Endeffekt ist die Aufgabe immer irgendwie die Gleiche. Jeder Besuch, nach Möglichkeit auch alle Fehlerseiten und die verschickten Mails, sollen getrackt werden.  Aber natürlich sollen auf speziellen Seiten auch spezielle Trackings ausgespielt werden … Und die Freifelder außerhalb der Dokumentation wollen wir ja auch nicht vergessen …

Ich habe bereits Referenzimplementierungen mit riesigen (!) Switch-Case Bäumen für jeden möglichen Seitentyp gesehen und freue mich da, wenn ich Tracker, wie den Piwik-Tracker von Marmalade finde, die das schon in einer if-Kontrolle dynamisiert haben. Mir persönlich reicht das aber immer noch nicht. Ich nutze bereits seit Jahren einen komplett anderen Ansatz, den ich euch nun nach einem umfassenden Update auch unter der GPL 3 freigeben möchte.   Zusätzlich zu meiner Tracking-Umgebung liefere ich euch auch direkt einen Piwik-Adapter mit bei, an dem Ihr sehen könnt, wie der Tracker euch Arbeit abnimmt, indem Ihr mit Ihm unzählige Tracker mit einer einzigen Umgebung abbilden könnt und bereits eingebaute WBL_Tracker leicht erweitern könnt.
(mehr …)