Mit der Shadowbox treten Probleme beim verwenden in Eingabefeldern (input Tags) und Textfelder (textarea Tags) auf. Die Leertaste sowie die links und rechts Tasten werden beim tippen in Textfelder nicht eingefügt bzw. das Textfeld reagiert nicht.
Die Ursache ist das Shadowbox.js, unsere Highlight-Box, die Tastensignale als Steuersignale für das Weiterschalten und der gleichen verwendet. Abhilfe schafft das Initialisieren der Shadowbox mit dem Parameter enableKeys: false. Beispiel Code:
Shadowbox.init({ handleOversize: 'drag', modal: true, enableKeys: false });
Version: xt:commerce 4.0.12 (höhere Versionen nicht getestet)
Ein kleiner Bugix für einen nervigen Fehler in der Artikelansicht nach Herstellern (manufacturer view). Der Fehler macht sich nach dem Klick auf die Hersteller Auswahl im Frontend bemerkbar. Anstatt eine gefilterte Artikelansicht nach Herstellern zu sehen bekommen werden alle Artikel aus dem Shop angezeigt.
Einen Dowload des Bugfix in Plugin Form geht es hier: xt:commerce Veyton Hersteller Manufacturer Ansicht / Filter Bugfix Download
Zur Installation des Bugfixes muss der Ordner “ld_manufacturer_bugfix” in den xt:commerce Veyton Plugin Ordner kopiert werden.
In Eigenregie kann der Bugfix in der Datei xtFramework/classes/class.products_list.php eingefügt werden. Es reicht die Zeilen 62 und 63 der Datei auskommentieren. (Methode getProductListing der Klasse products_list)
function getProductListing () { ## ## ... some code ## if (empty($current_manufacturer_id)) { $this->sql_products->setPosition('product_listing'); if ($this->current_categorey_id == 0) $this->sql_products->setFilter('Startpage'); $this->sql_products->setFilter('Categorie', $this->current_categorey_id); if (is_data($_GET['filter_id'])) $this->sql_products->setFilter('Manufacturer', (int)$_GET['filter_id']); } else { ## quick manufacturer view / filter bugfix $this->sql_products->F_Manufacturer($current_manufacturer_id); # $this->sql_products->setPosition('product_manufacturer_listing'); # $this->sql_products->setFilter('Manufacturer', (int)$current_manufacturer_id); if (is_int($current_category_id)) $this->sql_products->setFilter('Categorie', $current_category_id); } if (is_data($_GET['sorting'])) { $this->sql_products->setFilter('Sorting', $_GET['sorting']); } else { ## ## ... more code ##
Nach dem korrigieren des Quellcodes oder installieren des Manufacturer Bugfixes für Veyton sollte alles wie erwartet funktionieren. Es sei denn du hattest erwartet das Veyton diesen Bug hatte. 
Version: Magento 1.5 & 1.5.1
Themen spezifische Übersetzungen werden in Magento üblicherweise in der Datei /app/design/frontend/***BASE ODER DEFAULT***/***DEIN TEMPLATE***/locale/de_DE/tanslate.csv hinterlegt. Dabei muss das Format “***STRING IN TEMPLATE***”,”***ÜBERSETZTER TEXT***” eingehalten werden. Teilweise sind auch Variablen wie %s enthalten. Die sind am Prozent Zeichen zu erkennen.
Die translate.csv im Template Ordner erhält, beim generieren der Übersetzungen, eine niedrigere Priorität als die standard Übersetzungen. Das nimmt der Möglichkeit Übersetzungstexte mit dem Template zu liefern die bereits in der standard Übersetzungstexten enthalten sind.
Um das zu ändern kann quick and dirty die Datei app/code/core/Mage/Core/Model/Translate.php in Zeile 558 folgendermaßen editiert werden:
/** * Return translated string from text. * * @param string $text * @param string $code * @return string */ protected function _getTranslatedString($text, $code) { $translated = ''; if (array_key_exists($text, $this->getData())) { $translated = $this->_data[$text]; } elseif (array_key_exists($code, $this->getData())) { $translated = $this->_data[$code]; } else { $translated = $text; } return $translated; }
Am einfachsten ist es die Methode _getTranslatedString() komplett zu ersetzen. 
Alternativ kann hier ein fertiger Magento 1.5.X Translate Bugfix heruntergeladen werden. Der Fix muss gemäß der im Archiv enthaltenen Ordnerstruktur in das Magento root Verzeichnis kopiert werden.
Version: Magento 1.5 & 1.5.1
Das Magento Kontaktformular versendet, nach einer frischen Installation, grundsätzlich schon E-Mails. Zumindest solange darauf geachtet wird den URL Rewrite der Seite auf der sich das Kontaktformular befindet nicht zu verändern. Das bedeutet das Blöcke in denen das Kontaktformular auf anderen Seiten integriert ist ebenfalls nicht funktionieren.
Um den Fehler zu beheben lasse ich den Pfad zur Not (wenn der Pfad leer ist) statisch ausgeben. Dabei verwende ich folgenden form-Tag im Template ***Theme Pfad***/contacts/form.phtml:
<form action="<?php $action = $this->getFormAction(); if (!empty($action)) { echo $action; } else { echo Mage::getBaseUrl().'contacts/index/post/'; } ?>" id="contactForm" method="post">
Der Fehler entsteht, weil die Methode $this->getFormAction() ein leeres Ergebnis zurück liefert, wenn man sich beim Formular Absenden nicht auf der Seite mit dem Rewrite /contacts/ befindet.
Ein Manko dieser Lösung ist die automatische Weiterleitung auf die Kontaktformular Seite nach dem Absenden des Kontakformulars auch wenn das Formular als Block in eine andere Seite eingesetzt wurde.
Alle Schritte beachtet und das Formular will noch nicht? Hast du deine E-Mail Adresse auch für das Magento Kontakformular hinterlegt? Falls nicht, du findest das Feld zum Eintragen der E-Mail Adresse im Magento Backend unter:
System -> Konfiguration -> Allgemein -> Kontakte
Erwähne das, weil ich nach dem lesen des Bugfixes zusätzlich noch die passende Mail Adresse vergessen hätte. 
Version: xt:Commerce v3.0.X
Am 18.02.2011 wurde auf xtc-load.de über einen Patch für einen kritischen Fehler in xt:Commerce v3.0.4SP2.1 berichtet.
Der SQL Injection Bugfix von xtc-load.de behebt NICHT alle Fehler.
Download xt:Commerce v3.0.4SP2.1 incl. eregi (Nullbyte Injection) SQL Injection Bugfix
Angepasste Dateien: inc/xtc_validate_email.inc.php, password_double_opt.php
Fix für den Fix
Der auf xtc-load.de oder anderen Seiten angebotene Patch löst das Problem mit der SQL Injection sicher, jedoch nicht die Nullbyte Injection in der Funktion xtc_validate_email() (inc/xtc_validate_email.inc.php). Der Patch (xtc-load.de) enthält in dieser Datei folgenden Codeschnippsel der zum verhindern der Nullbyte Injection verwendet werden soll:
// sql injection fix 16.02.2011 if (strpos($email,"\0")!==false) {return false;}
Hierbei wird auf das “\0″ geprüft. Jedoch nicht auf die ebenfalls gültigen “\x00″, “\u0000″ und “\000″ Nullbytes. Ein Fix für den Fix (eine bereits gegen die Nullbyte / SQL Injection gefixte Version) ist das ersetzen des oben erwähnten Codeschnippsels mit folgendem:
## Bugfix for nullbyte injection. More: http://www.monkey-business.biz/1586/xtcommerce-v3-0-x-eregi-nullbyte-injection-sql-injection/ str_replace(array("\0", "\x00", "\u0000", "\000"), '', $email, $count); if ($count > 0) return false;
Der Codeschnippsel hat den selben Sinn wie der bereits enthaltene, er prüft jedoch zusätzlich noch auf die ebenfalls gültigen Nullbytes. In die Variable $count wird von der Funktion str_replace() die Anzahl der ersetzten Nullbytes im E-Mail String hinterlegt. Danach wird geprüft ob ein Nullbyte ersetzt werden musste. Ist dies der Fall wird die Funktion beendet und die E-Mail für ungültig erklärt und nicht in die Datenbank geschrieben.
Details zur Sicherheitslücke
Das Vorgehen ist denkbar einfach. Nach der erfolgreichen Anmeldung im xt:commerce Shop muss der in der E-Mail Adresse injizierte SQL Code (via account_edit.php) über die xt:commerce “Passwort vergessen” Funktion ausgeführt werden nachdem die Passwort vergessen E-Mail angefordert wurde. Die E-Mail Adresse die beim Ausführen von password_double_opt.php aus der “Passwort vergessen” E-Mail heraus zur Injektion verwendet wird kann beispielsweise folgenden String enthalten:
yourmail@example.com \x00' OR customers_email_address = 'shopadmin@example.com
Dies bewirkt die Übermittlung des Strings an den MySQL Server:
UPDATE customers SET customers_password = '7e716d0e702df0505fc72e2b89467910' WHERE customers_email_address = 'yourmail@example.com \x00' OR customers_email_address = 'shopadmin@example.com'
Im weiteren Ablauf des password_double_opt.php wird das Passwort für shopadmin@example.com, in diesem Beispiel Shop Administrator, an yourmail@example.com gesendet.
Was hat das mit dem Nullbyte zu tun?
Die PHP Funktion eregi() die in der xtc_validate_email() Funktion in der Datei inc/xtc_validate_email.inc.php in xt:commerce verwendet wird nutzt die darunter liegende C-Lib um den String zu lesen. Diese Lib erkennt ein Nullbyte (\0, \x00, \u0000, \000) als String Ende. Bei der Überprüfung mit eregi() wird also das Nullbyte von der Funktion als vorzeitiges String Ende angesehen und nur der Teil des Strings bis zum Nullbyte überprüft. Das heißt nach einem Nullbyte können beliebige Zeichen eingeschleußt werden. Es handelt sich hierbei also um keinen Fehler den xt:commerce Shopsystems.
Ob die Nullbyte und SQL Injection von Erfolg gekrönt ist hängt von den php.ini Einstellungen ab. Optionen die \ in Eingaben über $_POST oder $_GET filtern verhindern oder verändern unter Umständen den nötigen Injection String.
Nach dem Update auf WordPress 3.1 war in meinem Theme auf dieser Seite ein weißer Streifen am oberen Rand (on top) des Browserfensters mit 28px Höhe zu sehen. Dieser Streifen entpuppte sich nicht als Element sondern als Style Anweisung html { margin-top: 28px !important; }.
Der Fehler entsteht durch ein neues Freature in WordPress und ist nur im angemeldetem Zustand mit entsprechenden Rechten sichtbar. Kurz: Nach dem Update sehen euere Leser nicht den weißen balken, keine Sorge.
Beheben lässt sich der Fehler durch das Einfügen der wp_footer() Funktion innerhalb des body Tags in euer Theme / Template.
Nach dem Einfügen des wp_footer() Funktionsaufrufs bekommt ihr, nach dem aktuallisieren der Browser Ansicht, die neue WordPress Frontend Toolbar zu sehen.
Not a bug, It’s a feature
