Worum es bei dieser Konferenz geht und wie ihr zu weiteren Informationen kommt, erfahrt ihr in meinem Blog-Posting auf unserer Agentur-Seite von LimeSoda.

Daher führen wir bei LimeSoda in Wien ständig eigene Analysen zum österreichischen Browsermarkt durch. Wir aggregieren die Besucherstatistiken von über 100 verschiedenen Websites aus unserem Portfolio und bilden so ein Mittel aus Webshops, Blogs und Websites mit Content-Management-Systemen im B2B- und B2C-Bereich.

Was hat sich gegenüber dem letzten Jahr verändert?

Nicht so viel, wie man vielleicht meinen möchte. Der Internet Explorer liegt weiterhin knapp vor Mozilla Firefox. Beide haben Marktanteile verloren. An dritter Stelle findet man Safari von Apple, während Google Chrome erst auf Platz vier folgt.

Bei den Browserversionen hat sich der Markt stark aufgesplittet. Vor allem Firefox leidet unter einer Fragmentierung aufgrund der verkürzten Releasezyklen. Chrome zeigt, wie man das besser macht. Die vielen neuen Versionen führen zu einem Kuriosum: der Internet Explorer 8 hat sich den Spitzenplatz für die meistverbreitete Einzelversion zurück erkämpft.

Neugierig geworden? Alle Details gibt es in meinem LimeSoda-Blog-Posting “Webbrowser-Nutzung in Österreich: Edition März 2012“.

Eine Erweiterung möchte ich noch vorstellen: das neue DHL-Versandmethoden-Modul.  Bei uns verwendet zwar gerade gar kein Kunde DHL (schätze, in Österreich sind andere Versender beliebter?), weswegen ich das Modul nicht selbst testen kann, aber da es scheinbar ziemlich umfangreich ist, zahlt sich ein Blick darauf sicher aus.

Einstellungsmöglichkeiten

Im Backend findet man die Versandmethoden wie gewohnt unter System > Configuration > Sales > Shipping Methods. Der bisherige DHL-Versand findet sich nun unter “DHL (Deprecated)”, während das neue Modul unter “DHL” findet.

Hier ohne weitere Umschweife der Konfigurationsbereich:

Selbst mit diesem langen Formular sind aber noch nicht einmal alle Möglichkeiten aufgedeckt.

Wählt man bei der Größe (Size) statt “Regular” den Wert “Specific” aus, dann können die Ausmaße der Packung angegeben werden:

Im ersten Screenshot wird nur ein Teil der verfügbaren Versandmethoden aufgeführt. Hier ist der zweite Teil der Liste:

Nicht zuletzt (ok, doch zuletzt) kann eine kostenlose Versandmethode ab einem beliebigen Bestellwert definiert werden. Auch hier möchte ich euch die Auswahlmöglichkeiten nicht vorenthalten:

Fazit

Dieses Mal muss mein Fazit kurz ausfallen, denn wie gesagt: mit DHL-Modulen hatte ich bisher wenig zu tun. Falls das Modul gut und fehlerfrei umgesetzt ist, scheint es mir aber eine echte Bereicherung zu sein. Wenn ihr Erfahrungen damit sammeln konntet, freue ich mich über eure Erfahrungsberichte in den Kommentaren.

Für den Fall, dass jemand mit dem Begriff nichts anfangen kann: CAPTCHA steht für “Completely Automated Public Turing test to tell Computers and Humans Apart”. In 99 Prozent der Fälle sind das verschnörkelte Buchstaben, die man auf Websites eintippen muss.

Admin-Backend

Wer die CAPTCHA-Funktion für das Magento-Backend aktivieren möchte, klickt sich zum Menüpunkt System > Configuration > Advanced > Admin > CAPTCHA durch. Nachdem die Option “Enable CAPTCHA in Admin” auf “Yes” gestellt wurde, kommen neue Einstellungsmöglichkeiten zum Vorschein (siehe Screenshot):

Gehen wir die Punkte durch:

• Font
  Die Schriftart, die für die Erzeugung der CAPTCHAs verwendet wird. Aktuell ist nur LinLibertine verfügbar.
• Forms
  Hier wird festgelegt, welche Formulare mit CAPTCHAs versehen werden. Von den Backend-Formularen stehen das Login-Formular und das Passwort-Vergessen-Formular zur Auswahl. Zweiteres ist standardmäßig aktiviert. Wird “Admin Login” ausgewählt, wird man nach dem Speichern ausgeloggt und muss das CAPTCHA eingebn.
• Displaying Mode
  Eine sehr sinnvolle Funktion: soll das Captcha immer oder erst nach x fehlgeschlagenen Versuchen angezeigt werden? Wer sich für “After number of attempts to login” entscheidet, kann die Anzahl im darauf folgenden Feld “Number of Unsuccessful Attempts to Login” einstellen.
• CAPTCHA Timeout (minutes)
  Für wie viele Minuten ist das CAPTCHA gültig?
• Number of Symbols
  Bestimmt, wie viele Buchstaben angezeigt werden. Es kann auch ein von-bis-Wert angegeben werden (z.B. 6 bis 8 Zeichen).
• Symbols Used in CAPTCHA
  Hier wird definiert, welche Zeichen im CAPTCHA vorkommen dürfen. Dieses Feature ist sehr sinnvoll, schließlich besteht bei einigen Zeichen (1 vs. I, 0 vs. O) je nach Schriftart akute Verwechslungsgefahr.
  Erlaubt sind nur alphanumerische Zeichen (A-Z, a-z, 0-9). Sonderzeichen (!, ?, …) sind nicht gestattet.
• Case Sensitive
  Soll die Groß-/Kleinschreibung beachtet werden?

So sieht die CAPTCHA-Abfrage beim Login-Formular aus:

Kunden-Frontend

CAPTCHAs können nicht nur im Backend, sondern auch im Webshop-Frontend eingesetzt werden. Dazu ruft man den Menüpunkt System > Configuration > Customers > Customer Configuration > CAPTCHA auf.

Die weiteren Einstellungen werden wie oben nach Zustimmung zur Frage “Enable CAPTCHA on Frontend” freigeschalten. Hier gleicht alles bis auf die Formularauswahl der Backend-Konfiguration:

Im Webshop können 5 Formulare mittels CAPTCHA geschützt werden:

• Registrierung
• Login
• Passwort-Vergessen-Funktion
• Bestellen als Gast (Checkout)
• Registrierung während des Bestellvorgangs

Hier sehen wir als Beispiel das Registrierungsformular:

Fazit

Für die Nutzung dieses Features gibt es einige Pro- und Kontra-Argumente. Schön ist meiner Meinung nach, dass eine getrennte Konfiguration möglich ist und somit für den Administrationsbereich und den Kundenbereich unterschiedliche Sicherheitsstufen festlegbar sind. Zudem ist das Modul recht gut konfigurierbar. Wer mit groben Spam-Problemen zu kämpfen hat, könnte hier Verbesserungen feststellen.

Auf der anderen Seite muss man sich fragen, ob man dann am richtigen Hebel ansetzt. Tendenziell sollte man für möglichst geringe Eintrittshürden im Webshop sorgen. Da ist es oft besser, man riskiert Spam-Mails und setzt lieber einen guten Spam-Filter ein. Wie immer hängt es hier vom Einsatzzweck ab: werden die Formulardaten z.B. automatisiert in Datenbanktabellen geschrieben oder an anderen Stellen verarbeitet, wo ein Spam-Filtering nicht möglich ist, dann ist ein CAPTCHA vielleicht schon wieder gerechtfertigt.

Was auf jeden Fall noch fehlt ist die Option, das CAPTCHA auf der Kontaktseite und z.B. beim Rezensionen-Formular einzubinden. Gerade die eigenen sich nämlich auch für Spam.

• Einen Namen überlegt. Hallo MageSpawner.
• Die Konfiguration in eine extra Datei verlagert, ein paar grundlegende Überprüfungen eingebaut und eine kleine Dokumentation angelegt.
• MageSpawner auf Github veröffentlicht.

Für wen ist MageSpawner gedacht?

Für Magento-Entwickler, die wissen, was sie tun. Normalen Magento-Endanwendern empfehle ich den Einsatz von MageSpawner ausdrücklich nicht.

Was macht MageSpawner?

MageSpawner erstellt eine Magento-Test-Installation, mit der man sofort los starten kann. Es

• lädt die gewünschte Magento-Version herunter (7 Versionen von 1.5.0.1 bis 1.7.0.0 beta1 sind verfügbar),
• entpackt das Archiv und setzt die Rechte,
• erstellt die Datenbank,
• führt das Magento-Install-Skript aus (siehe dazu auch Fabrizios jüngsten Hinweis),
• führt eine Reindizierung der Inhalte aus und
• setzt noch einmal Dateirechte.

Wer die VirtualDocumentRoot-Direktive von Apache verwendet, muss maximal noch einen Eintrag in seine hosts-Datei einfügen und kann die neue Magento-Installation in Betrieb nehmen.

Eine Warnung vorab: jede(r) verwendet das Skript auf eigene Gefahr. Bei mir hat es nichts kaputt gemacht, aber ich kann keine Garantie übernehmen. Das betrifft besonders das Remove-Skript.

Der Code unterliegt der Apache-Lizenz. Weitere Informationen gibt es bei Github.

Was ist der Status von MageSpawner?

Man kann bestenfalls von einer Alpha sprechen. Genauer gesagt ist das hier keine offizielle Veröffentlichung – die kann es erst geben, wenn irgend jemand außer mir das Skript erfolgreich eingesetzt hat.

Das Skript lebt bisher nur in meiner Test-VM und wird nur von mir verwendet. Es unterstützt nur die wichtigsten Features, die ich benötige, um etwas in einer Magento-Installation auszuprobieren und diese gleich danach wieder zu vernichten.

Weitere Pläne für MageSpawner?

Das liegt ganz an euch, den Magento-Entwicklern. Ihr seid dazu eingeladen, MageSpawner auszuprobieren, Fehler zu berichten und neue Features zu implementieren. Einfach bei Github forken und los geht es.

Funktionalitäten, um die man MageSpawner zum Beispiel erweitern könnte:

• Stärkere Flexibilisierung des Skripts (= weitere Parameter konfigurierbar machen)
• Optionale Angabe von Kommandozeilenparametern, um Schritte zu überspringen oder das Skript komplett automatisierbar zu machen
• Deaktivieren des Cachings
• Backend-Hinweise “als gelesen markieren”
• Optionale Installation von Extensions
• Optionale Installation von Sample-Daten (vorgeschlagen von Fabrizio Branca)
• Setzen von Magento-Konfigurationswerten
• Einbindung in / Überführung des Codes in Build-Skripte (wobei der Vorteil von MageSpawner ist, dass eben keine Build-Tools vorhanden sein müssen)

Feedback?

Total toll? Funktioniert nicht? Ist Mist, weil es bereits Open-Source-Skripte gibt, die das alles noch viel besser erledigen? Ich freue mich wie immer über Feedback.

• Die Umsatzsteuer-Identifikationsnummer (UID bzw. UST-IdNr.) kann automatisch überprüft werden.
• Je nach Ausgang der UID-Prüfung kann eine automatische Kundengruppenzuordnung des Kunden erfolgen.

Für die Validierung kommt die offizielle Schnittstelle der Europäischen Union (VIES VAT number validation) zum Einsatz.

Hinweis: Dieser Artikel entstand während der Entwicklung von Magento 1.7 (Version alpha1). Es ist daher möglich, dass sich in der stabilen Version Änderungen ergeben.

Konfiguration

Um die automatische Überprüfung zu aktivieren, meldet man sich im Magento-Backend an und navigiert zum Menüpunkt System > Configuration > Customer > Customer Configuration > Create New Account Options (siehe Screenshot).

Wenn man die unscheinbare Option “Enable Automatic Assignment to Customer Group” auf “Yes” setzt, erscheinen die Konfigurationsmöglichkeiten:

Wir können nun die Optionen Schritt für Schritt durchgehen:

• Enable Automatic Assignment to Customer Group
  Aktiviert die automatische Überprüfung der Umsatzsteuer-Identifikationsnummer und die automatische Zuordnung zu Kundengruppen.
• Default Group
  Die Kundengruppe, der neue Kunden standardmäßig zugeordnet werden.
• Group for Valid VAT ID – Domestic
  Die Kundengruppe, der inländische Kunden mit gültiger UID zugeordnet werden.
• Group for Valid VAT ID – Intra-Union
  Die Kundengruppe, der Kunden innerhalb der EU mit gültiger UID zugeordnet werden.
• Group for Invalid VAT ID
  Die Kundengruppe, der Kunden ohne gültige UID zugeordnet werden.
• Validation Error Group
  Die Kundengruppe, der Kunden zugeordnet werden, wenn keine Validierung vorgenommen werden konnte (z.B. weil das Validierungsservice nicht erreichbar ist.)
• Validate on Each Transaction
  Legt fest, ob die Gültigkeit der UID bei jeder Bestellung überprüft werden soll.
  
• Disable Automatic Group Changes Based on VAT ID Default Value
  Soll die Option “Disable automatic group change”  bei der Anlage neuer Kunden im Backend standardmäßig angehakt sein? (Siehe weiter unten für eine Erklärung dieser Funktion.)
  

Funktionsweise & Details

Sehen wir uns an, wie das neue Feature funktioniert und welche Details mir beim Testen aufgefallen sind.

Wie sieht eine Beispielkonfiguration aus?

Ich habe für meine Tests folgende Kundengruppen unter “Customers > Customer Groups” erstellt:

• B2C
  Die normalen Endkunden.
• Händler Österreich verifiziert
  Kunden aus Österreich, die eine gültige UID angegeben haben (B2B).
• Händler EU verifiziert
  Kunden aus der EU, die eine gültige UID angegeben haben (B2B).
• Händler UID ungültig
  Kunden, die eine ungültige UID angegeben haben.
• Händler UID nicht verifiziert
  Kunden, bei denen die UID nicht überprüft werden konnte (z.B. weil die Überprüfungsstelle nicht erreichbar war).
• NOT LOGGED IN
  Gruppe für nicht registrierte Kunden (eine Standardgruppe in Magento).

Die Konfiguration für die Kundengruppenzuordnung sieht dann folgendermaßen aus:

Wo werden die Ländereinstellungen für den Shopbetreiber und den Kunden vorgenommen?

Der Shopbetreiber stellt das Land, in dem sich der Shop befindet, im Backend unter dem Menüpunkt “System > Configuration > Configuration > General > General > Store Information > Country” ein. In unserem Fall wird hier “Österreich” ausgewählt.

Achtung: wenn die automatische Zuordnung der Kundengruppen bereits aktiviert war, muss nach einer Änderung des Landes die Option erneut aktiviert werden. Bei mir wurde sie nach der Umstellung des Shop-Landes deaktiviert.

Für den jeweiligen Kunden gilt das in der Standard-Rechnungsadresse angegebene Land.

Wo muss die UID eingegeben werden?

Für die Überprüfung wird einzig die UID der Standard-Rechnungsadresse verwendet.

Es wird zwar bereits beim ersten Registrierungsschritt ein UID-Feld eingeblendet, wenn man das im Magento-Backend so einstellt. Diese Eingabe wird aber ignoriert – unabhängig davon, ob das Feld als optionale oder als Pflichtangabe definiert wird.

Nach der Registrierung wird der Hinweis angezeigt, dass für die korrekte Preisdarstellung eine UID bei der Rechnungsadresse hinterlegt werden muss.

Wenn man die neue Adresse anlegt, erscheint im Formular ein UID-Feld. Diese Eingabe wird für die Überprüfung verwendet und auch nur dann, wenn es sich um die Standard-Rechnungsadresse handelt (z.B. bei der Anlage der ersten Adresse überhaupt oder wenn man später beim Bearbeiten / Erstellen von Adressen das entsprechende Häkchen setzt).

Welche unterschiedlichen Fälle gibt es und wie werden die Kunden informiert?

Wird eine UID angegeben, dann kann zwischen 4 Fällen unterschieden werden. Das Beispiel verwendet die oben angegebenen Beispiel-Kundengruppen:

1. Inländischer B2B-Kunde (Österreich)
   Ein österreichischer Händler gibt eine korrekte UID an.
   
   Die UID ist gültig, Steuern werden verrechnet. Der Kunde wird in die Gruppe “Händler Österreich verifiziert” verschoben.
2. Ausländischer B2B-Kunde (EU)
   Ein ausländischer Händler innerhalb der EU gibt eine korrekte UID an.
   Die UID ist gültig, Steuern werden nicht verrechnet. Der Kunde wird in die Gruppe “Händler EU verifiziert” verschoben.
3. UID-Validierungs-Service nicht erreichbar
   Die Überprüfung der UID kann nicht durchgeführt werden.
   Die UID konnte nicht verifiziert werden, Steuern werden verrechnet. Der Kunde wird in die Gruppe “Händler UID nicht verifiziert” verschoben. Eine eigene Kundengruppe für diesen Fall macht Sinn, damit man leicht sieht, um welche Kunden man sich getrennt kümmern muss (z.B. um in Kontakt zu treten, die Überprüfung manuell vorzunehmen, …).
4. UID ist ungültig
   Es wurde eine falsche UID angegeben.
   
   Die UID ist ungültig, Steuern werden verrechnet. Der Kunde wird in die Gruppe “Händler UID ungültig” verschoben.

Können einzelne Kunden von der automatischen Überprüfung ausgenommen werden?

Ja. Der Kunde wird im Backend über dem Menüpunkt “Customers > Manage Customers” bearbeitet. Im Abschnitt “Account Information” kann bei der Kundengruppenauswahl das Häkchen “Disable automatic group change” gesetzt werden.

Kann die UID des Kunden direkt über das Backend manuell überprüft werden?

Soweit ich gesehen habe: im Moment nicht. Allerdings gibt es eine Überprüfungsmöglichkeit für die eigene UID unter “System > Configuration > General > General > Store Information”, die zweckentfremdet werden könnte.

Kann für das eigene Unternehmen eine UID angegeben werden?

Ja, es kann für den Shop eine UID unter “System > Configuration > General > General > Store Information” definiert werden. Dort ist auch eine Überprüfung der UID möglich.

Achtung: wenn der Validierungsservice nicht erreichbar ist, wird die Meldung “VAT Number is invalid” angzeigt. Falls man sicher ist, dass die Nummer richtig eingegeben wurde, könnte die Meldung also auch dadurch zustande kommen.

Fazit

Das neue Feature kann Shop-Betreibern mit vielen B2B-Kunden einiges an Arbeit abnehmen. Ein paar kleine Funktionen (manuelle Überprüfung der UID direkt beim Kundenmanagement möglich, leichtere Editierbarkeit der Erfolgs-/Fehlermeldungen, …) wären wünschenswert, doch vielleicht kommen diese Features noch dazu.

Alle Informationen zu der Veranstaltung findet ihr auf der Website Magento Hackathon @ mixxt.

Die wichtigsten Fragen und Antworten:

Was?

Laut Agenda gibt es am Freitag (30.03.) am Abend für alle bereits Anwesenden ein “Get Together” im Barschwein.

Am Samstag beginnt der Hackathon mit Vorträgen. Die Sprecher sind Vinai Kopp, Bastian Ike und Ivan Chepurnyi. Danach werden Coding-Teams zusammen gestellt und Programmierprojekte in Angriff genommen. In der Liste der potentiellen Projekte sind viele spannende Themen dabei, zum Beispiel ein Magento-2-Code-Review, das Testen von Layout-XML und Simulieren externer Services oder Verbesserungen der Performance durch Einsatz von NoSQL bei Bestelltransaktionen.

Aus dem Magento Hackathon soll eine Serie von Konferenzen entstehen. Daher haben die Organisatoren ganz ordentlich in einen Logo-Wettbewerb investiert. Die Abstimmung ist noch nicht gelaufen. Ihr könnt also mit bestimmen, welches Logo die Hackathons zieren soll.

Wann & Wo?

Der Hackathon findet am 31.03.2012 bis 01.04.2012 in München, genauer gesagt in der Leopoldstraße 62 (Jarlssen GmbH) statt. Laut Google Maps ist das in Nähe des Münchener Hauptbahnhofs.

Wer?

Für das Event haben sich bereits viele bekannte Gesichter der Magento-Community angemeldet. Einzelne Namen will ich da gar nicht heraus greifen, seht am besten in der Teilnehmerliste nach. Da ich die meisten davon noch nicht persönlich kennen gelernt habe, wäre ich gerne dabei. Ob es sich terminlich ausgeht, weiß ich allerdings noch nicht. Ich könnte wohl irgendwann am 31.03. dazu stoßen.

Wie viel?

Das Ticket für die Teilnahme kostet € 31,84. Der Preis spielt dabei also sicher keine Rolle. Die Anzahl der Teilnehmer ist begrenzt. Passt auf, dass ihr euch rechtzeitig einen Platz sichert.

Weitere Fragen?

Falls ihr noch etwas wissen wollt, wendet euch am besten an Damian Luszczymak (mixxt, Website, Twitter). Huch, ich habe ihn gar nicht gefragt, ob er das will. Auf jeden Fall engagiert er sich sehr dafür, also weiß er auch sehr gut Bescheid.

Backups in Magento 1.6

Rufen wir uns zuerst in Erinnerung, wie die Backup-Funktionalität bis inklusive Magento 1.6 aussieht:

Ein Klick auf “Create Backup” erstellt eine komprimierte SQL-Datei. Sie kann bei Bedarf über die Kommandozeile oder andere Tools wieder eingespielt werden.

Backups und Rollbacks in Magento 1.7

In Magento 1.7 wird dieses Feature ausgebaut. Man erreicht die Funktion wie bisher über das Navigationsmenü unter dem Punkt “System” > “Tools”  > “Backups”. Ein Screenshot verrät einige Neuerungen:

Anstelle eines simplen “Create Backup”-Buttons sind drei unterschiedliche Sicherungen möglich:

• System Backup: dieses Backup sichert (fast) alle Dateien der Magento-Installation. Wir kommen gleich zu den Details.
• Database and Media Backup: in dieser Datei werden Inhalte des Ordners “media” und ein Datenbank-Backup vorgehalten.
• Database Backup: hier wird wie gewohnt ausschließlich die Datenbank gesichert.

Über die Tabellenspalte “Action” kann ein Rollback durchgeführt, die Sicherung also wieder in das System eingespielt werden. Das Löschen von Backups ist über das Actions-Dropdown weiterhin möglich.

System-Backup

Klickt man auf den Button “System Backup”, wird eine Warnmeldung angezeigt:

Wie man sich gut vorstellen kann, dauert es mitunter lange Zeit, ein vollständiges System zu sichern. Daher muss diese Operation explizit bestätigt werden. Zugleich hat man die Möglichkeit, den Shop in der Zwischenzeit in den Wartungsmodus zu versetzen.

In meinem virtuellen Testsystem benötigte das Backup eines frisch installierten Shops 45 Sekunden. Man erhält eine tgz-Datei im Verzeichnis var/backups. Die Datei wird mit einem Timestamp versehen. Sie heißt z.B. snapshot-20111231101644.tgz

Gesichert wird im Prinzip die komplette Magento-Installation ausgehend vom Magento-Root-Verzeichnis. Einige Dateien und Verzeichnisse sind davon ausgenommen:

• .svn
• maintenance.flag
• var/cache
• var/full_page_cache
• var/locks
• var/log
• var/report
• var/session

Diese Liste wird in Mage_Backup_Helper_Data::getBackupIgnorePaths() definiert. Zusätzlich zu den “normalen” Dateien wird ein Datenbank-Backup erzeugt und in var/ abgelegt. Nach dem Backup wird der DB-Dump wieder gelöscht.

Datenbank- und Media-Backup

Vor der Ausführung des “Database and Media Backup” erscheint dieselbe Warnmeldung wie beim System-Backup. Zumindest in einem leeren System geht diese Operation allerdings natürlich schneller von der Hand. Im Testsystem war nach 7 Sekunden alles erledigt.

Hier werden ausschließlich die Verzeichnisse media/ und var/ in eine tgz-Datei gepackt. Der Dateiname ist wiederum mit dem Zeitpunkt der Sicherung versehen, z.B. media-20111231101820.tgz.

In media/ befinden sich die Files aus der Magento-Installation inklusive der catalog/product/cache-Dateien. Das var-Verzeichnis enthält den komprimierten Datenbankexport im SQL-Format.

Datenbank-Backup

Hierzu gibt es nicht viel zu sagen. Das von Magento erstellte .gz-Archiv (Dateiname z.B. db-20111231101839.sql.gz) enthält einen SQL-Dump-File.

Rollbacks (Wiedereinspielen von Backups)

Will man einen alten Stand wiederherstellen, so öffnet sich nach dem Klick auf den Rollback-Link folgendes Warnfenster:

Diese Meldung erscheint (zumindest in der Alpha 1) unabhängig davon, welche Art von Backup eingespielt wird. Hat man bestätigt, dass man fortfahren will, muss man zur Sicherheit das Passwort des Admin-Accounts eingeben:

Diese Maßnahme ist sinnvoll, damit kein Unbefugter Unsinn anstellen kann, wenn er durch Zufall gerade an einem PC mit angemeldetem Admin-User vorbei kommt. Außerdem kann man sich noch einmal überlegen, ob man das Rollback durchführen will.

Auch hier kann der Shop in den Wartungsmodus versetzt werden. Zusätzlich kann festgelegt werden, ob man zum Einspielen des Backups eine FTP-Verbindung verwenden will. Das ist unter Umständen wegen der Größe des Backups oder der Dateirechte nötig (schließlich muss der Linux-User das Recht haben, die Dateien und Verzeichnisse zu löschen/schreiben).

Führt man ein Rollback mittels eines System-Backups durch, sind auch beim Rollback einige Dateien und Verzeichnisse ausgenommen:

• .svn
• maintenance.flag
• /index.php
• /app/Mage.php
• /errors
• /var/locks
• /var/log
• /var/report
• /var/session

Diese Liste wird in Mage_Backup_Helper_Data::getRollbackIgnorePaths() definiert. Wie gleich auffällt, bestehen Unterschiede zu den beim Backup ignorierten Dateien. Meinem Gefühl nach ist das nicht besonders sinnvoll – vielleicht kann das jemand von euch in den Kommentaren logisch erklären.

Nach dem Einspielen der Dateien wird die Datenbank ebenfalls zurück gespielt. Ist der Vorgang abgeschlossen (bei mir ging es erfreulich schnell und dauerte ca. 30 bis 40 Sekunden), dann wird man zum Admin-Login-Formular zurück geleitet und kann wieder auf das alte System zugreifen. Neuere Backups dürften übrigens bestehenbleiben, was recht praktisch sein kann.

Fazit

Mit dem Ausbau der Backup- und Rollbackfunktionalität bietet Magento CE 1.7.0.0 vor allem für jene Shopbetreiber eine sehr nützliche Funktionalität, die ihren Shop nicht innerhalb eines größer angelegten Backup-/Deployment-/Rollback-Plans betreiben. Das trifft ohne Zweifel auf viele Händler zu. Magento hilft dieser Zielgruppe somit sehr, regelmäßig die Daten zu sichern und die Risiken beim Testen von Änderungen im Shop zu reduzieren.

Der bisherige Weg mit Magento 1.6 und älter

Wer bereits mit Magento arbeitet, fragt sich vielleicht: was soll da neu sein? Magento bietet bereits lange die Möglichkeit, Staffelpreise für Kundengruppen festzulegen. Da man einen Staffelpreis bereits für 1 Stück eingeben kann, kann man diese Funktion “missbrauchen”, um unterschiedliche Basispreise für verschiedene Kundengruppen einzupflegen.

Gehen wir im Beispiel von der folgenden Preisgestaltung aus (über den ökonomischen Sinn wollen wir hier nicht diskutieren ):

• Nicht angemeldete Kunden zahlen € 9,99 pro Stück.
• Angemeldete Kunden zahlen € 8,99 pro Stück.
• Einzelhändler zahlen € 6,79 pro Stück.
• Großhändler zahlen € 6,49 pro Stück.
• Einzelhändler zahlen ab 10 Stück nur noch € 6,59 pro Stück.
• Großhändler zahlen ab 10 Stück nur noch € 6,39 pro Stück.
• Großhändler zahlen ab 50 Stück gar nur noch € 6,19 pro Stück.
• Wenn irgend jemand tatsächlich mindestens 500 Stück bestellt, kommt er mit € 5,99 pro Stück davon.

In der Eingabemaske des Webshop-Backends sieht das so aus:

Jetzt wechseln wir in den Webshop und begutachten das Produkt als nicht angemeldeter Kunde.

Das Problem fällt schnell auf: der Basispreis des Produkts beträgt € 14,99. Ich bin in der Kundengruppe “NOT LOGGED IN” und muss für 1 Stück nur € 9,99 zahlen. Auf der Kategorieseite und an der auffälligsten Stelle der Produktseite wird jedoch nur der Basispreis € 14,99 angezeigt. Dass mich das Produkt nur € 9,99 kostet, fällt nur bei genauem Hinsehen auf.

Um diese Darstellung zu korrigieren und den Einzelpreis für die Kundengruppe auffälliger zu gestalten, muss in die Logik von Magento eingegriffen werden. Damit entsteht eine Erweiterung, die bei der Installation von Aktualisierungen und anderen Erweiterungen getestet und gewartet werden muss.

Basispreise in Magento 1.7

An dieser Stelle kommt die neue Magento-Version ins Spiel. Hier können neben dem Basispreis und den Staffelpreisen weitere Basispreise für Kundengruppen hinterlegt werden.

Wir nehmen dieselben Preisregeln wie im vorigen Beispiel an und werfen einen Blick auf das Backend in Magento 1.7:

Die Kundengruppen-Basispreise werden im neuen Punkt “Group Price” definiert.

Jetzt wechseln wir wieder in den Webshop und sehen uns die Anzeige für einen nicht angemeldeten Kunden an:

Die Darstellung gefällt uns schon besser. Man sieht sowohl auf der Kategorie- als auch auf der Produktseite, welchen Preis man als nicht angemeldeter Kunde erhält. Der Gruppenpreis wird sogar als Aktionspreis ausgelobt. Ob man das in seinen Shop haben will oder nicht, ist Geschmackssache. Eeinerseits handelt es sich dabei um einen Kaufanreiz, andererseits wird so mancher jeder Kundengruppe nur den eigenen Preis anzeigen wollen.

Basispreis, Gruppenpreis und Aktionspreis

Damit noch nicht genug der Preise: in Magento kann man zusätzlich zum Basispreis einen (zeitlich begrenzten oder dauerhaften) Aktionspreis angeben. Da wir gerade beobachtet haben, dass der Gruppenpreis als Aktionspreis gekennzeichnet wird, ist es interessant zu wissen, wo der Aktionspreis seinen Platz zwischen Basispreis und Gruppenpreis findet.

Hier drei verschiedene Fälle und die daraus resultierende Anzeige:

Fazit

Mit den Gruppenpreisen bringt die Version 1.7 eine nützliche, wenn auch nicht bahnbrechende neue Funktion. Bisher musste man selbst Hand anlegen, um die Grundpreise für verschiedene Kundengruppen vernünftig anzuzeigen. Das ist nun nicht mehr nötig.

Damit das möglich wird, müssen für die Aktion Gutscheine mit individuellem Code erzeugt werden. Bisher gab es in Magento hierfür drei Möglichkeiten:

1. Man setzt sich einen Tag lang vor den PC und legt alle Gutscheine händisch an.
2. Man erwirbt eine Erweiterung von einem Drittanbieter, welche die Funktionalität nachrüstet.
3. Man schreibt ein Skript (bzw. lässt eines programmieren), das sich um die Generierung kümmert.

Doch das ändert sich nun. Mit Magento 1.7 wird eine Funktion zur automatischen Erstellung von Coupon-Codes für Preisregeln eingeführt, sprich: Magento kann nun auf Knopfdruck beliebig viele Gutschein-Codes nach dem Zufallsprinzip generieren. Die Preisregel muss dafür nur einmal angelegt werden.

Anmerkung: ich habe diesen Artikel geschrieben, als Magento 1.7 in der Version Alpha 1 vorlag. Es kann also sein, dass es bis zur stabilen Version 1.7 noch Änderungen vorgenommen werden.

Automatisches Erstellen von Gutschein-Codes

Um die neue Funktionalität zu verwenden, meldet man sich wie gewohnt im Magento-Backend an und erstellt eine Warenkorb-Preisregel. Wenn man angibt, dass ein Gutschein-Code verwendet werden soll, wird ein Eingabefeld für den Gutschein-Code und – das ist nun neu – eine Option angezeigt, Codes automatisch zu generieren.

Man hakt die Option an und speichert die Preisregel ab. Nun kommt bei der Warenkorb-Preisregel im linken Menü ein neuer Punkt namens “Manage Coupons Codes” zum Vorschein, wie in diesem Screenshot zu sehen:

Klickt man auf dem Menüpunkt, erhält man eine leere Liste und ein Formular, um die Codes zu erstellen:

Folgende Optionen existieren für die Erstellung von Gutschein-Codes:

• Coupon Qty: Wie viele Gutschein-Codes sollen erstellt werden?
• Code Length: Aus wie vielen Zeichen besteht der Gutschein-Code?
• Code Format: Aus welchen Zeichen besteht der Gutschein-Code? Hier kann zwischen Buchstaben, Zahlen und einer Kombination von Buchstaben und Zahlen gewählt werden.
• Code Prefix: Soll dem Gutschein-Code eine fixe Zeichenkette vorangestellt werden? Zum Beispiel könnte man dem zufällig generierten Code “Ostern-2012-” voranstellen, um den Gutschein für eine Osteraktion zu branden.
• Code Suffix: Soll eine fixe Zeichenkette an das Ende des Gutschein-Codes angefügt werden?
• Dash Every X Characters: Soll der Code durch Gedankenstriche unterteilt werden? Zum Beispiel wird Kunden die Eingabe stark erleichtert, wenn die Zeichenfolge in Dreier-Gruppen unterteilt wird.

Nachdem die Parameter konfiguriert sind und man auf “Generate” klickt, werden die Codes erstellt. In meinem kleinen Testsystem mit deaktiviertem Cache dauerte die Generierung von 5.000 Codes knapp 20 Sekunden. Das Ergebnis sieht wie folgt aus:

Neben jedem Gutschein-Code ist zu sehen, wann er erstellt wurde sowie ob und wie häufig er benutzt wurde.

Fazit

In Magento 1.7 wird mit der automatischen Gutschein-Code-Generierung ein Feature eingeführt, das von Shop-Betreibern stark und häufig nachgefragt wird. Es ist somit nicht mehr zwingend nötig, eine Erweiterung eines Drittanbieters zu implementieren und diese bei Software-Aktualisierungen zu überprüfen sowie zu warten.

Man kann sich erhoffen, dass die Funktionalität in Zukunft noch weiter ausgebaut wird. Was zum Beispiel in der aktuellen Alpha-Version fehlt ist die Option, leicht verwechselbare Buchstaben (wie “1″ versus “I”) bei der Generierung nicht zu verwenden.