Magento-Marktanteil in 2015

Entwicklung seit 2012

Update von der Meet Magento 2015

Auf der diesjährigen Meet Magento hat uns Thomas Goletz (Vorstand der Netresearch App Factory AG) gab es einige Updates zu den Statistiken rund um die Magento-Infrastruktur:

  • Mehr als 240.000 Installationen
  • Mehr als 7.500 bekannte Erweiterungen
  • Über 7 Jahre erfolgreiches Magento 1.x

Marktanteile von Magento nach Wappalyzer

Nach Wappalyzer (ein Browser-Plug-In, der die auf der Webseite verwendete Software basierend auf dem Quellcode u. a. Merkmalen erkennt) ist der Marktanteil von Magento auf 19% weiter gesunken:

Absolute Zahlen der Top 10 Online-Shop-Systeme:

Die Spalte “Detections” zeigt indirekt die Besucherzahlen und damit die Popularität einzelner Shops, die das jeweilige System verwenden.

Zum Vergleich: 2012 hat Wappalyzer bei 25% aller untersuchten Online-Shops Magento erkannt. 2014 waren es 22%, und heute noch 19%.

Nach dieser Quelle ist WooCommerce (WordPress-basierte Shops) der deutliche Gewinner mit einem Anstieg von 15% im Vergleich zum Vorjahr. Ob WooCommerce eine niedrige Einstiegshürde bietet und sich deshalb gut verbreitet oder ob Wappalyzer seine Erkennungsalgoritmen verbessert und die Statistik damit verzerrt, hat kann man nur vermuten.

Magento-Marktanteile nach Google Trends, Search Insights

Das Suchvolumen weltweit zeigt Magento als klaren Sieger mit stabiler Nachfrage:

In Deutschland gewinnt Magento mit deutlichem Abstand:

Während in den USA Shopify Magento überholt hat:

Veröffentlicht unter Marketing | Hinterlasse einen Kommentar

Anwenderdokumentation von Magento

Seit kurzem gibt es etwas, was seit Jahren gefehlt hat und den Grund für die Existenz solcher Blogs wie dieser geliefert hatte:

Veröffentlicht unter Tutorials | Hinterlasse einen Kommentar

Up-Selling-Produkte werden nicht gespeichert

Fehlerbeschreibung

Nach der Auwahl von Up-Sell-Produkten im Backend wird nach dem Speichern des Hauptprodukts die Liste zurückgesetzt.

Fehlerursache

Der Fehler tritt auf, wenn die Erweiterung BL_CustomGrid (Enhanced Admin Grid auf Magento Connect und GitHub).

Fehlerbehebung

Der Fehler kann dadurch behoben werden, dass die Erweiterung speziell für die Tabelle der Up-Sell-Produkte deaktiviert wird. Die Erweiterung stellt dazu selbst die entsprechende Mittel zur Verfügung.

In Grid Anpassung > Grid Infos zur Up-Sell-Tabelle kann der Blocktyp herausgefunden werden:

In System > Konfiguration > Enhanced Admin Grids: Konfiguration Basis wird der Blocktyp adminhtml/catalog_product_edit_tab_upsell als Ausnahme hinzugefügt:

Danach kann zwar die Tabelle für Up-Sell-Produkte nicht mehr angepasst werden, doch das Speichern der Auwahl funktioniert.

Veröffentlicht unter Fehlerbehebung | Hinterlasse einen Kommentar

Magento 1.9.1 sendet keine E-Mails

Seit Magento 1.9.1 wurden bei den Transaktions-E-Mails zwei wichtige Änderungen eingeführt: Responsive E-Mail-Vorlagen und E-Mail-Warteschlange (E-Mail-Queue). Mit dem ersten Shop auf Basis von Magento 1.9.1, wird man sich zunächst wundern, dass die Bestellbestätigung nicht sofort oder gar nicht nach Abschluss der Bestellung versendet wird, zumindest bis der Cron-Skript von Magento aufgerufen wurde.

Hinweis: Ein weiterer Grund, dass eine E-Mail nicht versendet wird könnte ein fehlendes E-Mail-Template oder ein Fehler im verwendeten Template sein.

Die E-Mail-Queue beschleundigt den Bestellvorgang, da die Bestellbestätigung im separaten Prozess versendet wird, und nicht wie in Vorgängerversionen, als Teilvorgang der Aufnahme einer neuen Bestellung. Dies ist Performance Optimierung, die sich besonders für Shops mit vielen Bestellabschlüssen lohnt. Mit der Magento-Erweiterung AOE_Scheduler lässt sich der Magento-interne Cron-Job der E-Mail-Queue gut veranschaulichen:

Die letzte Version dieser Erweiterung auf Magento Connect ist 0.3.2 und offiziell bis Magento 1.7 freigegeben, funktioniert jedoch mit Magento 1.9.1 ebenfalls einwandfrei. Die aktuelle Version 0.4.3 kann auf GitHub heruntergeladen werden.

Die Vorschaufunktion für E-Mail-Vorlagen ist in Magento ohnehin unbrauchbar, da sie die Vorschau ohne Kunden- oder Beispieldaten anzeigt, sodass das Endergebnis erst mit einer Testbestellung kontrolliert werden kann:

Bei der Einrichtung von E-Mail-Templates in einem neuen Shop wird die E-Mail-Queue die Arbeit allerdings erschweren, da die Email nicht sofort nach Abschluss einer Testbestellung ankommt, sodass bei der Kontrolle einer jeden Anpassung neben dem Aufwand einer Testbestellung noch eine zusätzliche Wartezeit entsteht.

Eine Abhilfe hierbei schafft die Magento-Erweiterung Modulwerft_EmailManager, die eine sofortige Vorschau bzw. Anzeige einer jeden von Magento vorbereiteten oder sofort versendeten E-Mail direkt im Backend ermöglicht.

Im Kommentarverlauf einer Bestellung kann die Bestellbestätigung, die an den Kunden versendet wurde oder wird, sofort augerufen werden:

An der Anzeige Versand ausstehend ist sofort erkennbar, dass die E-Mail noch nicht an den Kunden versendet wurde, sondern sich in der E-Mail-Warteschlange befindet. Der Klick auf den gelb hinterlegten Bereich zeigt die vorbereitete E-Mail so wie sie beim Kunden ankommen wird:

Neben der praktischen Anzeigefunktion der noch nicht versendeten E-Mails in Magento 1.9.1 überwacht und speichert der E-Mail-Manager alle E-Mails, die von Magento generiert und versendet wurden oder werden.

Dem Kundendienst wird diese Erweiterung helfen schnell nachzuvollziehen, welche E-Mails an den Kunden versendet wurden. Bei registrierten Kunden können die E-Mails in Kundendetails angezeigt und absteigend nach der Zeit sortiert werden:

In System > E-Mail-Log bekommt man die Übersicht über alle von Magento versendeten E-Mails und kann sie nach Typ (z. B. Bestellbestätigung, Rechnung, Lieferschein) Empfänger, Betreff und einigen weiteren Kriterien filtern. Nach dem Empfänger gefiltert können auch für Gastkunden alle versendeten E-Mails gefunden werden.

Veröffentlicht unter Entwicklung, Fehlerbehebung | Hinterlasse einen Kommentar

DHL-Label-Drucker und Etiketten-Format

DHL-Versand-Etiketten können entweder mit einem beliebigen Drucker gedruckt werden, der auch Papier im A5-Format bedrucken kann, oder mit einem Thermodrucker.

Etiketten-Drucker für DHL-Intraship

Von DHL wird der B-EV4T-G von Toshiba TEC empfohlen (vollständige Modellbezeichnung: B-EV4T-GS14-QM-R):

Der Anschaffungspreis beträgt inkl. MwSt. ca. 250,- EUR. Die passenden Thermo-Etiketten werden von DHL dem Kunden kostenfrei zugeschickt.

Der Drucker kann sowohl mit einer Etikettenrolle als auch mit gestapelten Etiketten verwendet werden, wie sie von DHL geliefert werden. Die Etiketten bleiben dann außerhalb des Druckers im Karton liegen und werden durch den hinteren Schlitz eingezogen. Da die Thermo-Etiketten von DHL die schwarze Druckfarbe bereits im Papier enthalten, wird das teuere Thermotransfer-Farbband nicht benötigt.

Der Vollständigkeit halber soll noch der große und ca. 700,- € (inkl. MwSt.) teuere Drucker B-EX4D2 von Toshiba erwähnt werden, der von der DHL bei 10.000 Sendungen pro Tag empfohlen wird. Der “kleine” B-EV4T-G wird für viele Shop-Betreiber schnell genug sein: Für den Druck eines Etiketts (Format: s. u.) braucht er nur 2 Sekunden!

Installation des B-EV4T-G

Obwohl der Drucker einen Netzwerk-Anschluss hat und offiziell das Drucken über LAN unterstützen soll, haben wir es nicht geschafft ihn mit einem Windows-Rechner über LAN anzusprechen und betreiben ihn deshalb über USB.

In der eigenen Installationsanleitung schlägt DHL einen abgewandelten Druckertreiber vor: http://www.toshibatec-eu.de/IPD-PUBLIC/EasyLog/Treiber.zip

Dieser funktioniert einwandfrei, genau wie der offizielle Drucker-Treiber von Toshiba, jedoch wird das richtige DHL-Etikettenformat bereits vorinstalliert:

Die Testseite kann in den Druckereinstellungen gedruckt werden:

Gleich nach der Installation, ohne weitere Einstellungen, müsste der Drucker die Testseite erfolgreich ausgeben und dabei genau auf der Perforationslinie des nächsten Etiketts anhalten.

DHL-Etiketten-Format und DHL-Intraship in Magento

Wenn der offizielle Treiber von Toshiba bereits installiert wurde, kann das DHL-Etikettenformat (101,6 mm x 199,0 mm) manuell eingegeben werden:

In den Format-Einstellungen der Magento-Erweiterung DHL Intraship (die o. W. direkt mit dem neuen “DHL Versenden” funktioniert) wird das passende Etiketten-Format nicht angeboten.

Für die Ränder können negative Abstände angegeben werden, um das perfekte Druckergebnis zu erzielen:

  • Papierformat der Etiketten: A5
  • Linker Rand: -53 mm
  • Oberer Rand: -49 mm

Eingaben der Abstände ohne Einheit in System > Konfiguration > Verkäufe: DHL > Etiketten-Einstellungen:

Das Ergebnis als PDF-Ausgabe liefert ein im linken oberen Rand des A5-Formats positionierten DHL-Etikett, der dann perfekt mittig aus dem Thermodrucker (B-EV4T-G) kommt:

Veröffentlicht unter Tutorials | Verschlagwortet mit , , , , , | 2 Kommentare

SQL-Fehler in Magento debuggen: Vollständige SQL-Abfrage im Stack Trace anzeigen

Bei einem SQL-Fehler kann der Stack Trace von Magento in der Fehlerausgabe wie folgt aussehen:

#0 lib/Zend/Db/Statement/Pdo.php(228): PDOStatement->execute(Array)
#1 lib/Varien/Db/Statement/Pdo/Mysql.php(110): Zend_Db_Statement_Pdo->_execute(Array)
#2 lib/Zend/Db/Statement.php(300): Varien_Db_Statement_Pdo_Mysql->_execute(Array)
#3 lib/Zend/Db/Adapter/Abstract.php(479): Zend_Db_Statement->execute(Array)
#4 lib/Zend/Db/Adapter/Pdo/Abstract.php(238): Zend_Db_Adapter_Abstract->query('SELECT `a`.* FR...', Array)
#5 lib/Varien/Db/Adapter/Pdo/Mysql.php(419): Zend_Db_Adapter_Pdo_Abstract->query('SELECT `a`.* FR...', Array)
#6 lib/Zend/Db/Adapter/Abstract.php(825): Varien_Db_Adapter_Pdo_Mysql->query(Object(Varien_Db_Select), Array)

Die Information ist begrenzt hilfreich, da die Abfrage “SELECT `a`.* FR…”, die zu dem Fehler geführt hat, nicht ausgeschrieben wird.

Um die fehlerhafte Abfrage analysieren zu können, kann der Debug-Modus aktiviert werden, in dem die Variable $_debug in Varien_Db_Adapter_Pdo_Mysql auf true gesetzt wird. Die SQL-Abfrage wird dann in $_debugFile = ‘var/debug/pdo_mysql.log’ gespeichert und kann weiter analysiert werden.

Veröffentlicht unter Fehlerbehebung, Tipps und Tricks | Verschlagwortet mit , , , | Hinterlasse einen Kommentar

Rechtskonforme SEPA-Lastschrift für Magento mit Mandat-Verwaltung und SEPA-XML-Export (ISO 20022)

Seit heute steht die neue Version 2.0 der SEPA-Lastschrift-Erweiterung für Magento zur Verfügung:

Die neue Version erfüllt alle rechtlichen Vorschriften, die vom Gesetzgeber gefordert werden. Diese Anforderungen haben wir weiter unten für Sie zusammengefasst. Für die neue Version der Erweiterung stellen wir eine ausführliche Dokumentation und eine neue Live-Demo bereit.

Vielen Dank an alle Kunden und Bankmitarbeiter, die uns Verbesserungsvorschläge und rechtliche Hinweise zugeschickt haben und uns so bei der Verbesserung der SEPA-Lastschrift für Magento unterstützt haben!

Zusammenfassung der neuen Regeln für SEPA-Lastschrift

Im Zuge der Einführung der neuen SEPA-Lastschrift und der Abschaffung der nationalen Lastschrift-Verfahren, wie beispielsweise der deutschen Lastschrift, hat es Regeländerungen gegeben. Diese Regeländerungen sollten seitens des Online-Händlers unbedingt beachtet werden, da dieser sonst Gefahr läuft Lastschriften nicht regelkonform einzuziehen und damit die Frist für die Rückholung des Lastschriftbetrages seitens des Kunden zu verlängern.

Die nachfolgend aufgeführten Änderungen sind mit der Einführung der SEPA-Lastschrift in Kraft getreten. Die neue Version unserer SEPA-Lastschrift-Erweiterung für Magento unterstützt und automatisiert diese neuen Regelungen:

  • IBAN und BIC Angabe
    Die Erweiterung prüft die eingegebene IBAN und BIC auf Fehler und zeigt diese an. Die Fehlerquote bei der Eingabe des langen IBAN-Codes wird dadurch minimiert. Für bestimmte Länder kann BIC als optionale Eingabe eingestellt werden.
  • Verwaltung von SEPA-Lastschriftmandaten
    Zusätzlich zum Versenden des erteilten SEPA-Lastschriftmandats per Email werden alle Daten des Mandates und das Dokument in der Shop-Datenbank gespeichert. Registrierte Shop-Kunden können Lastschriftmandate für wiederkehrende Zahlung erteilen und sie bei nächster Bestellung nutzen ohne die Bankverbindung erneut einzugeben. Das Mandat verfällt automatisch 36 Monate nach Nichtnutzung.
  • Rechtskonforme Vorlagen für SEPA-Lastschriftmandate
    Mit der Erweiterung sind sorgfältig recherchierte Vorlagen nach Vorgaben des European Payment Council (EPC) und der Deutschen Kreditwirtschaft (DK) in deutscher und englischer Sprachen enthalten: SEPA-Lastschriftmandat für einmalige und wiederkehrende Zahlung und Vorabinformation. Auf den vom Schuldner abweichenden Kontoinhaber wird gesondern hingewiesen.
  • Vorabinformation (Pre-Notification)
    Die Erweiterung bietet die Möglichkeit den Hinweis auf Verkürzung der Frist für Vorabinformation im Checkout anzuzeigen und die Vorabinformation in der Bestellbestätigung anzuzeigen.
  • Automatischer SEPA-XML-Export nach ISO 20022
    Neben dem manuellen Export im Backend ist automatischer Export von Zahlungen im standardisierten SEPA-XML-Format möglich.

SEPA-Lastschrift für Magento auf Magento Connect
Wir laden Sie ein, die neuen Funktionen in unserer Live-Demo auszuprobieren!

Veröffentlicht unter Empfehlungen | 1 Kommentar

WSDLSOAP-ERROR: Parsing WSDL: Couldn’t load from … : failed to load external entity …

Fehlerbeschreibung

$client = new SoapClient('http://beispiel.de/index.php/api/v2_soap/?wsdl');
$sessionId = $client->login('benutzer', 'geheim');

Beim Versuch eine API-Verbindung mit Magento herzustellen, wird von SoapClient der folgende Fehler gemeldet:

WSDLSOAP-ERROR: Parsing WSDL: Couldn't load from ... : failed to load external entity ...

Mögliche Ursache

Der Server kann seinen eigenen Namen nicht auflösen. Als Bestätigung dieser Ursache, kann der Apache-Server neu gestartet werden:

/etc/init.d/apache2 restart

Wird beim (erfolgreichen) Start von Apache die nachfolgende Warnung ausgegeben, liegt die o. g. Ursache vor:

Could not reliably determine the server's fully qualified domain name

Lösung

An Stelle der Domain kann in der API-URL die IP des Servers verwendet werden:

$client = new SoapClient('http://123.45.67.89/index.php/api/v2_soap/?wsdl');
$sessionId = $client->login('benutzer', 'geheim');

Die bessere und sauberere Lösung wäre der Eintrag der Domain in der hosts-Datei auf dem Server (die Datei befindet sich unter /etc/hosts):

123.45.67.89      beispiel.de

Anschließend sollte Apache neu gestartet werden.

Weiterlesen:

Veröffentlicht unter Fehlerbehebung | Verschlagwortet mit , , | Hinterlasse einen Kommentar

SoapClient: looks like we got no XML document

Fehlerbeschreibung

Beim Versuch sich über Magento-API einzuloggen, wird folgender Fehler gemeldet:

SoapClient: looks like we got no XML document

Fehleranalyse

Die Fehlermeldung ist viel zu allgemein. Deshalb sollte die Serverantwort genauer analysiert werden, die angeblich kein (gültiges) XML-Dokument ist. Um die empfangenen Daten analyseren zu können, wird die Abfragemethode von SoapClient überschrieben:

class SoapClientDebug extends \SoapClient{

    public function __doRequest($request, $location, $action, $version = SOAP_1_1, $one_way = 0){

        $xml = explode("\r\n", parent::__doRequest($request, $location, $action, $version, $one_way = 0));

        print_r($xml);
        print '<br/><br/>'.str_repeat('#', 100).'<br/><br/>';

        if(isset($xml[5])) return $xml[5];
        return '';
    }

}

Die API-Kommunikation läuft nun über die überschriebene Klasse:

// $client = new SoapClient('http://beispiel.de/index.php/api/v2_soap/?wsdl');
$client = new SoapClientDebug('http://beispiel.de/index.php/api/v2_soap/?wsdl');

Mögliche Ursachen und Lösungen

In unserem Fall hat der Server in mehreren Fällen tatsächlich kein XML-Dokument empfangen. Die Antwort war entweder eine Fehermeldung vom Varnish-Cache-Server, oder eine Weiterleitung aufgrund einer Regel in der .htaccess. Im ersten Fall konnte der Fehler durch Abschaltung des Varnish weiter analysiert werden. Im zweiten Fall wurde die Regel in der .htaccess verbessert.

Veröffentlicht unter Fehlerbehebung | Verschlagwortet mit , , | Hinterlasse einen Kommentar

WSDLSOAP-ERROR: Parsing Schema: can’t import schema from ‘http://schemas.xmlsoap.org/soap/encoding/’

Fehlerbeschreibung

Beim Verbindungsaufbau mit Magento-API wird der nachfolgende Fehler gemeldet:

WSDLSOAP-ERROR: Parsing Schema: can't import schema from 'http://schemas.xmlsoap.org/soap/encoding/'

Mögliche Ursache

Der Aufruf der o. g. URL findet serverseitig statt. Vergewissern Sie sich, dass der Server die URL zugreifen kann:

wget http://schemas.xmlsoap.org/soap/encoding/

Wenn die Datei auf dem Server nicht heruntergeladen werden konnte, ist sie für den Server tatsächlich nicht erreichbar. Ausnahmsweise sagt die Fehlereldung tatsächlich etwas aus, was direkt mit der Ursache zu tun hat.

Lösung

Je nach Situation kann es verschiedene Lösungsansätze geben, warum der Server die URL nicht erreichen kann. In unserem Fallbeispiel lag es an einer Firewall-Einstellung.

Veröffentlicht unter Fehlerbehebung | Verschlagwortet mit , , | Hinterlasse einen Kommentar