MySQL-InnoDB-Speicher automatisch freigeben

Bei der Entwicklung mit Magento ist der Magento-Cache oft deaktiviert. Damit die Testumgebung trotzdem möglichst schnell bleibt, lohnt es sich diese in einer RAM-Disk oder zumindest auf einer SSD-Festplatte laufen zu lassen. Doch bei schnellem Speicher ist jeder Gigabyte immer noch sehr kostbar!

Magento verwendet die InnoDB-Engine. Diese Engine bringt viele Vorteile mit sich gegenüber der MyISAM-Engine, aber auch einen Nachteil: Durch Löschen einer InnoDB-Tabelle oder einer ganzen Datenbankschema mit InnoDB-Tabellen wird der Speicher innerhalb des Tabellenraums zwar teilweise freigegeben, aber die Größe der Tabellenraum-Datei (typischer Speicherort: mysql/data/ibdata1) nicht automatisch reduziert. Der Speicher auf der Festplatte bleibt belegt.

Durch mehrfache Widerherstellungen von Datenbanken, Importe, Tabellen für Abfragetests und sonstige Experimente wächst der InnoDB-Tabellenraum auf der Festplatte immer weiter, sodass irgendwann der Speicher einer RAM-Disk aufgebraucht ist und kein vernünftiges Arbeiten mehr möglich wird. Eine Defragmentierung des InnoDB-Tabellenraums ist nicht vorgesehen. Um den Speicher auf der Festplatte freizugeben, muss der Tabellenraum komplett neu angelegt werden:

  1. Alle Datenbanken werden exportiert (z.B. mit mysqldump),
  2. alle Datenbankschemata mit InnoDB-Tabellen gelöscht (DROP SCHEMA …),
  3. der Datenbankserver wird heruntergefahren,
  4. Tabellenraumdateien werden gelöscht (in der Standardkonfiguration sind das die Dateien drei Dateien ibdata1, ib_logfile0, ib_logfile1 im Verzeichnis mysql/data)
  5. der Datenbankserver gestartet,
  6. alle gelöschten Datenbankschemata angelegt (CREATE SCHEMA …),
  7. Tabellenstrukturen und Daten von Exports wiederhergestellt.

Damit in Zukunft der Festplattenspeicher bereits beim Löschen von InnoDB-Tabellen freigegeben wird, müssen die Tabellendaten in jeweils eigenem Tabellenraum gespeichert sein. Hierzu kann vor dem Start des Datenbankservers der Parameter innodb_file_per_table in die my.ini bzw. my.cnf im mysqld-Block eingetragen werden:

[mysqld]
...
innodb_file_per_table
...

Die Datei ibdata1 wird u. a. für diverse Verwaltungsdaten weiterhin benötigt. Die eigentlichen Nutzdaten und Indizes werden nun aber in *.ibd-Dateien im jeweiligen Schema-Verzeichnis abgelegt (z.B. catalog_category_product.ibd).

Weitere Informationen zum Per-Table Tablespace in MySQL-Reference Manual.

Veröffentlicht unter Tipps und Tricks | Hinterlasse einen Kommentar

Leere Seite (Blank Page) oder HTTP-Fehler 500 beim Speichern von PayPal-Einstellungen im Backend von Magento

Beispielfehlermeldung

Der Fehler äußert sich darin, dass beim Versuch PayPal-Einstellungen im Backend zu speichern, in FireFox eine leere Seite angezeigt wird; auch der Quellcode der Seite ist leer. In Chrome wird auf den “HTTP-Fehler 500 (Internal Server Error)” hingewiesen:

Leere Seite (Blank Page) beim Speichern von PayPal-Einstellungen

Auch im Internet Explorer wird “HTTP 500 Internet Serverfehler” unauffällig in der Tab-Überschrift angezeigt, sonst aber die Meldung: “Die Website kann diese Seite nicht anzeigen.” ausgegeben.

In FireFox ist der Fehler im FireBug sichtbar:

Rückkehr zu den Einstellungen ist über die Zurück-Schaltfläche des Browsers möglich: die PayPal-Einstellungen wurden nicht gespeichert.

Grundsätzlich ist aber das Speichern von Einstellungen im Backend möglich und der Shop funktioniert auch sonst einwandfrei (u. a. Kunden können sich registrieren, Checkout funktioniert, Bestellungen können abgegeben werden).

Ursache

Typischerweise hat der Shop einen Serverumzug hinter sich, d. h. er wurde in einer neuen Serverumgebung von einem Backup wiederhergestellt.

Der Server ist nicht vollständig für den Betrieb eines Magento-Shops eingerichtet; in den meisten Fällen fehlt der für Datenverschlüsselung zuständiger PHP-Modul mcrypt, der in vorkonfigurierten Serverumgebungen (z. B. LAMPP) oft nicht standardmäßig enthalten ist.

Fehlerbehebung

Der Fehler kann durch Installation oder Aktivierung von mcrypt behoben werden. Wenn es sich um einen Ubuntu- oder Debian-Server handelt, kann mcrypt mit dem folgenden Bash-Befehl installiert werden (Administrator-Rechte werden vorausgesetzt):

apt-get install php5-mcrypt

Weiterlesen: PayPal-Einstellungen in Magento 1.7.x

Veröffentlicht unter Fehlerbehebung | Hinterlasse einen Kommentar

Gesamte MySQL-Datenbank nach einer Zeichenkette durchsuchen

In SQL/MySQL gibt es keinen Befehl mit dem die gesamte Datenbank durchsucht werden könnte. Denkbar wäre eine Prozedur, die alle Tabellen mit Spalten relevanter Datentypen (u. a. VARCHAR, CHAR, TEXT) durchsucht.

Einfacher geht es mit dem folgenden Trick: Datenbank wird als SQL-Skript exportiert/gesichert. Danach wird die SQL-Datei in einem Texteditor geöffnet und durchsucht.

Export der Datenbank ist über die Kommandozeile möglich:

mysqldump -uBenutzername Datenbankname > /var/tmp/Dateiname.sql

Ein Editor wie EditPad und viele Hex-Editoren würden dabei auch mit großen SQL-Dateien gut zurecht kommen.

Veröffentlicht unter Tipps und Tricks | Hinterlasse einen Kommentar

Einrichtung von Währungen in Magento

In Magento gibt es eine Basiswährung in der alle Produkt- und Servicepreise im Backend angegeben werden. Der Preis in Basiswährung wird nach dem aktuellen Kurs umgerechnet und dem Kunden im Frontend angezeigt.

Verfügbare Währungen

Die Einstellung verfügbarer Währungen ist in System > Konfiguration > Allgemein: Currency Setup möglich. Die standardmäßig angezeigte Währung muss dabei auch in der Liste erlaubter Währungen aktiviert sein.

Werden mehrere Einträge in der Liste erlaubter Währungen aktiviert, wird u. a. in der Kategorieübersicht ein Währungsumschalter angezeigt, sodass der Kunde wählen kann in welcher Währung die Preise angezeigt werden.

Hinweis: Durch einen einfachen Linksklick in dieser Liste wird nur die zuletzt angeklickte Währung ausgewählt. Alle anderen Währungen (die sich außerhalb des sichtbaren Bereichs befinden) werden dabei abgewählt. Halten Sie die Steuerungstaste gedrückt, wenn Sie mehrere Währungen auswählen.

Wenn der Währungsumschalter nicht angezeigt werden soll, muss die standardmäßig angezeigte Währung als einzige in der Liste erlaubter Währungen ausgewählt werden.

Umrechnungskurse

Manueller Abgleich ist durch Klick auf die Schaltfläche Import in System > Währungen verwalten möglich. Hinter WebserviceX verbirgt sich ein kostenfreier Service, der den aktuellen Umrechnungskurs zurückgibt. Beim Abgleich der Kurse wird beispielsweise die folgende URL aufgerufen:

http://www.webservicex.net/CurrencyConvertor.asmx/ConversionRate?FromCurrency=EUR&ToCurrency=USD

Sofern in System > Konfiguration > Allgemein: Einrichten der Währung > Einstellungen für terminierten Import aktiviert, wird der Umrechnungskurs automatisch aktualisiert. Voraussetzung dafür, ist dass die cron.php im Hauptverzeichnis von Magento regelmäßig aufgerufen wird (Einrichten von Cronjobs in Magento).

Währungsumschalter deaktivieren

Sofern mehrere Währungen in einem StoreView erlaubt sind, wird standardmäßig ein Währungsumschalter in der linken Spalte angezeigt.

Sein Block ist in der folgenden Layout-Datei definiert:

frontend/base/default/layout/directory.xml

Mit dem entsprechenden Befehl in der eigenen Layout-Datei lässt sich der Währungsumschalter ausblenden:

<remove name="currency" />

Mehrere Währungen anbieten

Die Basiswährung, in der Magento alle Preise berechnet, lässt sich nur im Website-Scope festlegen. Alle Preise werden in der Basiswährung berechnet und zum Anzeigen in eine Fremdwährung umgerechnet. Dies hat gravierende Konsequenzen, die beim Planen eines Magento-Shops unbedingt berücksichtigt werden müssen!

Alle Produktpreise werden in der Basiswährung angegeben

Der Produktpreis in Fremdwährung lässt sich nicht direkt beeinflußen! Kostet ein Artikel 9,99 EUR, wird sein Preis entsprechend dem Kurs umgerechnet: 13,55 USD. Der Händler hat keine Möglichkeit den Preis in USD auf z.B. 12,99 USD zu ändern.

Zahlungsmodule übermitteln den Gesamtbetrag in Basiswährung

Zahlungsmodule übermitteln den Preis oft in Basiswährung. Kauft der Kunde für 100 USD ein (das ist der Preis, der ihm im Frontend angezeigt wurde), übermittelt der Zahlungsmodul 73,68 EUR als zu zahlender Betrag, sofern EUR als Basiswährung eingestellt ist.

Tendentiell führt ein solcher Kunde sein Konto in USD. Durch Zahlungsanbieter-eigene Umrechnungskurse kann es passieren, dass der Kunde einen abweichenden Betrag zahlen muss. So wurde ihm beispielsweise im Shop 100 USD als der Gesamtwert seines Warenkorbs inkl. Versandkosten angezeigt, könnte sein Konto mit 102 USD belastet werden. Nicht jeder Kunde hat dabei Verständnis für die technischen Herausfoderungen, die den abweichenden Betrag begründen.

Preise in verschiedenen Währungen frei gestalten

Um den genannten Problemen entgegen zu wirken, lässt sich der Shop in mehrere Websites aufteilen. So kann für jede Website eine eigene Basiswährung festgelegt werden.

Um den Preis in der jeweiligen Währung frei gestalten zu können, muss unter System > Katalog > Preis > Katalogpreis-Gültigkeit noch eingestellt werden, dass der Produktpreis nur für eine Website gültigkeit hat.

Der Händler kann dem Produkt nun zwei Preise unabhängig voneinander zuweisen: 12,99 USD und 9,99 EUR. Nun muss für jedes Produkt der Preis unabhängig voneinander in der jeweiligen Währung gepflegt werden.

Beim aktuellen Umrechnungskurs kostet das gleiche Produkt in USD in diesem Beispiel günstiger. Aufmerksame Kunden werden dies mit der Zeit herausfinden und in Foren u. a. Kanälen darüber berichten. Um dem entgegen zu wirken, könnte für die jeweilige Website die Liste der belieferten Länder entsprechend gewählt werden.

ACHTUNG: bei dieser Konfiguration ist Vorsicht geboten, denn Magento (selbst in der heute aktuellen Version 1.7.0.2) behandelt die Preise wie sonstige Produktattribute: wird für die aktuelle Webseite kein Wert hinterlegt, wird der Standardwert (intern: store_id=0) ohne Umrechnung verwendet. Wird als Produktpreis beispielsweise 9,99 EUR festgelegt, wird im US-Shop 9,99 USD als Preis verwendet, sofern USD-Preis hinterlegt wurde! Gleiche Logik gilt für Sonderpreise und Staffelpreise.

Veröffentlicht unter Tutorials | Hinterlasse einen Kommentar

Memcached und Magento: Unknown number format type ‘boolean’. Format ” must be a valid number format string.

Magento lässt sich mit Memcached – genügend Arbeitsspeicher und Administratorrechte auf dem Server vorausgesetzt – recht einfach beschleunigen.

Beispielfehlermeldung

Fehlermeldung mit der ich auf einer frischen Installation von Magento 1.7.0.2 konfrontiert wurde:

Memcached und Magento: Unknown number format type 'boolean'. Format '' must be a valid number format string.

Ursache

Die Fehlermeldung wurde beim Aufruf vom Backend, später auch im Frontend ausgegeben. Durch Abschaltung von Memcache konnte ich sichergehen, dass der Fehler damit zusammenhängt.

Fehlerbehebung

Durch einfügen der Zeile prefix mit dem frei gewählten alphanumerischen Wert shop1 in der Konfiguration von Memcache, wurde der Fehler in meinem Fall behoben:

<cache>
   <prefix>shop1</prefix>
   <backend>memcached</backend>
   <memcached>
        <servers>
            <server>
                <host><![CDATA[127.0.0.1]]></host>
                <port><![CDATA[11211]]></port>
                <persistent><![CDATA[1]]></persistent>
            </server>
        </servers>
        <compression><![CDATA[0]]></compression>
        <cache_dir><![CDATA[]]></cache_dir>
        <hashed_directory_level><![CDATA[]]></hashed_directory_level>
        <hashed_directory_umask><![CDATA[]]></hashed_directory_umask>
        <file_name_prefix><![CDATA[]]></file_name_prefix>
    </memcached>
</cache>

Hintergrundinformationen

Memcached verwendet die Prefix-Einstellung bei der identifikation von gecachten Daten. Wenn auf dem gleichen Server mehrere Magento-Shops laufen, ist es wichtig durch verschiedene Prefix-Werte sicherzustellen, dass sie nicht auf gecachte Daten des jeweils anderen Shops zugreifen.

Memcached-Konfiguration des zweiten Shops:

<cache>
   ...
   <prefix>shop2</prefix>
   ...
</cache>
Veröffentlicht unter Fehlerbehebung | Hinterlasse einen Kommentar

Kategorien in Magento importieren, Kategorien programmatisch erstellen

Von Haus aus bietet Magento keinen Import oder Export von Kategorien. Mit dieser kostenfreien Erweiterung ist der Import von Kategorien aus einer CSV-Datei möglich.

Doch weder diese noch andere Erweiterungen auf Connect bieten alle nötigen Freiheiten. So habe ich keine Extension gefunden, bei der die interne Nummer einer Kategorie angegeben werden kann. Dies ist wichtig, um bei einer automatischen Synchronisierung mit einem externen System bei der Zuweisung von Produkten zu einer Kategorie direkt die externen Kategorienummern zu verwenden (und sich die zusätzlichen Joins und Zuweisungstabellen zu ersparen).

Dabei ist programmatische Erstellung einer Kategorie in Magento recht einfach und übersichtlich:

$objCategory = Mage::getModel('catalog/category');
$objCategory->setStoreId(0);

$aryCategory = array(
    'entity_id' => $entity_id,
    'path' => $path.'/'.$entity_id,
    'name' => 'Bezeichnung',
    'is_active' => 1,
    'include_in_menu' => 1,
    'url_key' => 'bezeichnung',
    'is_anchor'  => 0,
    'position'  => 1,
    'display_mode' => 'PRODUCTS_AND_PAGE',
    'created_at' => date("Y-m-d H:i:s", time()),
    'level' => $level = count(explode('/', $path))
);

$objCategory->addData($aryCategory);

try {
    $category->save();
} catch (Exception $e) {
    print $e->getMessage();
}

Es lohnt sich die Tabelle catalog_category_entity zu analysieren, um zu verstehen wie Magento die Kategorien auf der Datenbankebene verwaltet. Einige der Attribute, die in dem o. g. Beispiel gesetzt werden, findet man direkt in dieser Tabelle als Spalten wieder.

In einigen Quellen stellte ich fest, dass die Spalte level (Ebenentiefe) keinen Wert bekommt. Dieser wird von Magento leider nicht automatisch gesetzt! Wird die Ebenentiefe nicht angegeben, können tiefere Ebenen im Backend im Produkteditor nicht aufgeklappt werden.

Der Bau des eigenen Pfads path ist sehr komfortabel, wenn man zum Importieren von Kategorien auf verschiedenen Ebenen eine rekursive (selbst aufrufende) Funktion als Lösung wählt.

Veröffentlicht unter Tipps und Tricks | Hinterlasse einen Kommentar

Fixed Gross Price Extension: Gleiche Bruttopreise für alle Kunden

Magento arbeitet mit fixierten Nettopreisen, sodass der Händler stets den gleichen Nettopreis bekommt. Kommt ein Kunde aus einem Land, in dem die Mehrwertsteuer höher ist als die im eigenen Land, muss er einen höheren Bruttopreis zahlen, sofern im Shop der korrekte Mehrwertsteuersatz eingestellt wurde.

Das nachfolgende Diagramm zeigt den Rechenweg von Magento zur Bestimmung des Bruttopreises. Unter jedem Block ist ein Beispielwert zur besseren Erklärung angegeben:

Ab einer bestimmten Lieferschwelle ist der Händler verpflichtet dem Kunden die Mehrwertsteuer seines Landes auszuweisen. Die neue Extension Fixed Gross Price fixiert den Bruttopreis, sodass alle Kunden den gleichen Preis zahlen und dabei die korrekte Mehrwertsteuer ausgewiesen bekommen.

Die Berechnung des Bruttopreises in Magento und das Funktionsprinzip der Fixed Gross Price Extension ist in diesem Artikkel ausführlich dokumentiert.

Veröffentlicht unter Empfehlungen | Hinterlasse einen Kommentar

SSL-Sicherheitswarnung im Magento-Warenkorb: Informationen werden über eine unverschlüsselte Verbindung gesendet

Nach dem ich die Verschlüsselung im Frontend aktiviert habe, wird der Warenkorb über https:// geladen. Klicke ich dort z. B. auf die Schaltfläche “Warenkorb aktualisieren”, bekomme ich in FireFox die folgende Fehlermeldung:


Deutsche Version:

Obwohl diese Seite verschlüsselt ist, werden die von Ihnen eingegebenen Informationen über eine unverschlüsselte Verbindung gesendet und können leicht von Dritten gelesen werden.

Sollen diese Informationen wirklich gesendet werden?

Englische Version:

Although this page is encrypted, the information you have entered is to be sent over an unencrypted connection and could easily be read by a third party.

Are you sure you want to continue sending this information?

Abgesehen davon, dass diese Warnung beim Kunden Mißtrauen erweckt, wird man nach dem Klick auf “Fortsetzen” auf die Startseite des Shops weitergeleitet!

Problembehebung

Der Warenkorb in Magento, erreichbar unter der URL /checkout/cart/, ist nicht zum Laden über verschlüsselte Verbindung vorgesehen.

Eine benutzerdefinierte Warenkorb-Schaltfläche hat den Warenkorb aber mit dem folgenden Link aufgerufen und Verschlüsselung erzwungen:

echo Mage::getUrl('checkout/cart', array('_secure'=>true));

Da die unsichere Basis-URL keine Verschlüsselung verwendet, haben alle Unterformulare des Warenkorbs (Warenkorb leeren, Warenkorb aktualisieren, Gutschein-Code, Versandkosten) eine unverschlüsselten Action-URL, die die o. g. Warnung verursacht.

Durch Anpassung des Warenkorb-Links wurde das Problem in diesem Fall behoben:

echo Mage::getUrl('checkout/cart');
Veröffentlicht unter Fehlerbehebung | Hinterlasse einen Kommentar

German Setup: inkl. MwSt. anpassen, zzgl. Versand wird nicht angezeigt, Code existiert bereits

German Setup ist eine großartige Erweiterung für deutsche Shops. Im Gegensatz zu Market Ready Germany installiert sie keine unnötige Zusatzerweiterungen und führt Anpassungen rücksichtsvoll und erst auf Anfrage durch, wobei diese im Vorfeld in System > German Setup > Setup konfiguriert werden können.

In German Setup empfohlene Erweiterungen

Im Menü System > German Setup > Empfohlene Erweiterungen gibt es eine kleine Liste von empfohlenen Erweiterungen, die allerdings für Magento ab Version 1.7.0.0 reduziert werden darf:

  • Zahlung per Vorkasse ist in Magento 1.7 bereits enthalten. Für die Bankverbindung und Hinweise steht ein mehrzeiliges Textfeld zur Verfügung, der auch HTML-Tags aufnehmen kann. Die Information kann somit beliebig gestaltet werden.
  • Die Regionauswahl kann für bestimmte Länder in System > Konfiguration > Allgemein: Allgemein > Bundesland Optionen ausgeschaltet werden. Die Erweiterungen wie No Region werden damit überflüssig, zumal eine landabhängige Abschaltung der Regionauswahl damit gar nicht möglich wäre.

zzgl. Versand wird nicht angezeigt

Nach der Einrichtung von GermanSetup werden zwei CMS-Seiten für Versand- und Zahlungsinformationen angelegt.

Wer sich vom Deutschen Händlerbund e. V. beraten lässt, bekommt den Vorschlag diese zwei Seiten zu einer zu kombinieren. Die neue Seite hat beispielsweise den URL-Bezeichnier zahlung-und-versand:

GermanSetup bemerkt die Löschung der Seite mit Versandinformationen und blendet den Link aus dem Mehrwertsteuer-Hinweis aus.

Erst wenn unter System > Konfiguration > Katalog: Katalog > Preis: CMS-Seite für Versandkosten eine CMS-Seite gewählt wurde, wird der Hinweis: “zzgl. Versandkosten” wieder eingeblendet.

Nach dieser Anpassung muss noch der Konfigurationscache aktualisiert werden: System > Cache-Verwaltung > Cache-Art: Konfiguration.

Anzeige von “Inkl. MwSt.” anpassen

German Setup zeigt Prozente abhängig von der Steuerklasse, die einem Produkt zugewiesen ist und dem für den StoreView eingestelltem Standard-Zielland einstellbar in System > Konfiguration > Verkäufer: Steuer > Standard Ursprung für Steuerberechnung. Die deutsche Übersetzung des Block-Titels ist ziemlich mißverständlich:

Die korrekte Mehrwertsteuer bekommt der Kunde spätestens im letzten Schritt im Checkout angezeigt abhängig von seiner Rechnungsanschrift als Voreinstellung. Ist die MwSt. des Ziellandes höher, muss der Kunde einen höheren Produktpreis zahlen, denn Magento arbeitet mit festen Netto-Preisen.

Möchte man die Prozentzahl ausblenden, ist die Bearbeitung der Übersetzung am einfachsten. In der Übersetzung wurde jeweils der erste Platzhalter %s in den Wert des Dummy-Attributs des Link-Tags verschoben:

"Incl. Tax, plus <a href=""%s"">Shipping Cost</a>","Inkl. MwSt., zzgl. <a dummy=""%s"" href=""%s"">Versand</a>"
"Incl. %s Tax, plus <a href=""%s"">Shipping Cost</a>","Inkl. MwSt., zzgl. <a dummy=""%s"" href=""%s"">Versand</a>"
"Excl. %s Tax, plus <a href=""%s"">Shipping Cost</a>","Zzgl. MwSt., zzgl. <a dummy=""%s"" href=""%s"">Versand</a>"
"Incl. Tax","Inkl. MwSt."
"Incl. %s Tax","Inkl. MwSt."
"Excl. %s Tax","Zzgl. MwSt."

Der Platzhalter darf nicht entfernt werden, da die Prozentzahl sonst als URL zu der Versandkostenseite eingefügt werden würde.

Diese Zeilen können in locale/de_DE/translate.csv im eigenen Theme-Verzeichnis gespeichert werden. Die Originalzeilen sind in der folgenden Datei zu finden:

app/locale/de_DE/FireGento_GermanSetup.csv

Wer nach einer flexibleren Lösung sucht, kann die folgende Template-Datei modifizieren:

app/design/frontend/base/default/template/germansetup/price_info.phtml

Code existiert bereits.

German Setup erstellt jeweils drei Steuerregeln in Steuer > Steuerregeln verwalten für Endkungen und Unternehmen:

  • Produkte mit 19% MwSt.
  • Produkte mit 7% MwSt.
  • Versand mit 19% MwSt.

Möchte man ein neues Land einführen (z. B. Norwegen), muss man nach dem Anlegen in Steuer > Steuerzonen und -sätze zwangsläufig auch die Steuerregeln bearbeiten. Doch beim Speichern einer Steuerregel kommt die Fehlermeldung:

Fehlermeldung: Code existiert bereits.

Der Grund dafür ist dass die Regel mit dem gleichen Namen “Produkte mit 19% MwSt.” bereits für Unternehmen existiert. Beim programmatischen Erstellen von Steuerregeln werden offenbar gleiche Namen zugelassen, nicht aber beim Bearbeiten im Backend.

Die einfache Lösung: die Regeln sollen verschiedene Namen bekommen. Statt “Produkte mit 19% MwSt.” wird z. B. “Produkte mit 19% MwSt. (Endkunden)” eingetragen.

Email-Templates

German Setup richtet auch Email-Templates ein, die den rechtlichen Anforderungen in Deutschland entsprechen. Unter anderem wird beispielsweise in der Bestellbestätigung AGB, Widerrufsrecht und Impressum angezeigt.

Während Magento in der Voreinstellung Email-Vorlagen aus dem Verzeichnis app\locale verwendet (z.B. app\locale\de_DE\template\email), speichert German Setup die Vorlagen in der Datenbank ab. Sie können dann unter System > Transaktions-E-Mails verwaltet werden. Zu beachten hier ist dass Verwaltung mehrsprachiger Vorlagen über die Datenbank sich sehr umständlich gestaltet, da Magento hier keinen StoreView-Filter bietet. Leider verknüpft German Setup die Vorlagen aus der Datenbank in der Standardeinstellung, sodass diese für anderssprachige StoreViews manuell aufgelöst und auf Vorlagen aus dem Locale-Ordner verwiesen werden müssen.

Überprüfung einzelner Templates und ihrer Verknüpfungen lohnt sich, denn bei den vielen Vorlagen geht den Autoren das eine oder andere Detail verloren. So wurde in der zum Zeitpunkt des Artikels aktuellen Version die Vorlage für “Neue Rechnung” an Stelle von “Neue Bestellung” unter System > Konfiguration > Verkäufe: Verkaufs-E-Mails eingetragen.

Und in der Vorlage für “Neues Konto” wird der Kunde mit “herzlich willkommen in unserem Shop zum Thema Geld- und Energiesparen.” begrüßt, statt den Platzhalter zu verwenden: “herzlich willkommen bei {{var store.getFrontendName()}}.”, wie es in anderen Vorlagen der Fall ist.

Veröffentlicht unter Empfehlungen, Tipps und Tricks | Hinterlasse einen Kommentar

Nach Eingabe der Versandadresse geht es im Checkout nicht weiter: Bug in DHL Intraship

Für den Versand mit DHL Intraship gibt es eine kostenfreie Extension, die die Versandabwicklung automatisiert (Ausführlicher Artikel zur Versandautomatisierung über DHL Intraship).

Im Download-Manager wird für DHL Intraship die Version 12.09.10 (stable) angezeigt. Zum aktuellen Zeitpunkt (22.11.2012) ist das die neueste Version:

Dieser Bugreport basiert auf Erfahrung mit Magento 1.7.0.0 Community Edition mit dem Base-Theme. Außer DHL Intraship sind keine Erweiterungen installiert, die Checkout modifizieren.

In dieser Version von DHL Intraship gibt es einen recht versteckten Bug, der den Kunden daran hindert, seine Bestellung abzuschließen!

Bugreport

Möchte ein registrierter Kunde an eine von der Rechnungsanschrift abweichende Adresse versenden, wird er im nächsten Schritt Versandinformationen eingeben müssen. Hier integriert die DHL Intraship Extension seit kurzem die Option zum Versand an eine Packstation.

Ist diese Option deaktiviert, sieht das Formular wie gewohnt aus. Hat sich der Kunde eingeloggt und Aktiviert “Versand an Packstation” im Schritt “Versandinformationen” bekommt er die Liste von Packstationen in der Nähe seiner Anschrift:

Geht der Kunde als Gast zur Kasse und möchte an eine von der Rechnungsanschrift abweichende Adresse versenden, funktioniert “Versand an Packstation” nicht: die oben gezeigte Auswahlliste wird nicht eingeblendet, wenn die Option aktiviert wird.

Unabhängig davon, ob “Versand an Packstation” aktiviert ist oder nicht, bringt der Klick auf “Fortsetzen” den Kunden nicht zum nächsten Schritt. Beim Klick passiert gar nichts: keine Ladeanzeige, keine Fehlermeldungen:

 

Abhilfe

DHL Intraship ist ein Paket bestehend aus zwei Extensions (siehe app/etc/modules):

  • Dhl_Intraship.xml
  • Dhl_Account.xml

Die Extension Dhl_Intraship.xml implementiert die Versandautomatisierung über das Backend von Magento.

Die Extension Dhl_Account.xml integriert u. a. die Option “Versand an Packstation” in Checkout. Deaktivieren Sie die Extension Dhl_Account.xml, um das Problem im Checkout zu beheben. (Artikel: Extensions in Magento deaktivieren)

Die Option “Versand an Packstation” verschwindet aus dem Checkout, aber damit auch die Blockierung des Schritts “Versandinformationen”.

Veröffentlicht unter Fehlerbehebung | 2 Kommentare