Eine wichtige Information vorab: Vor Änderungen der Datenbankstruktur sollte immer ein Backup gemacht werden!
Magento 1.x Fatal error: Class 'Mage_Googlecheckout_Helper_Data' not found in /home/dir/public_html/guides/setup/app/Mage.php on line 547
Mit dieser Fehlermeldung kann die Konfiguration eines Magento 1.x Onlineshops nicht mehr aufgerufen werden. Das benannte Modul muss in dieser Datei mit HTML-Kommentaren deaktiviert werden. Es reicht oft nicht das Modul über false zu deaktivieren.
/app/etc/modules/Mage_All.xml
Dort sollte das Modul dann so auskommentiert und die Datei auf dem Server abgespeichert werden:
<!--<Mage_GoogleCheckout>
<active>true</active>
<codePool>core</codePool>
<depends>
<Mage_Sales/>
<Mage_Payment/>
<Mage_Usa/>
</depends>
</Mage_GoogleCheckout> //-->
Magento 1.9 Bilder werden nicht angezeigt
Wird Magento in einer CGI- bzw. FastCGI-Umgebung ausgeführt setzt Magento bei einem Dateiupload im Backend die Datei- und Verzeichnisrechte der neu erstellten Rechte so, dass die hochgeladenen Objekte im Firefox und Chrome nicht mehr dargestellt werden. Im Internet Explorer und Edge wurde dieser Effekt noch nicht beobachtet. Verantwortlich für den Dateiupload ist die Datei:
/lib/Varien/File/lib/Varien/File/Uploader.php
Diese Zeilen müssen in dem Fall wie folgt in den benannten Zeilen angepasst werden:
Zeile 219:
chmod($destinationFile, 0640);
->
chmod($destinationFile, 0644);
Zeile 541:
if (!(@is_dir($destinationFolder) || @mkdir($destinationFolder, 0750, true))) {
->
if (!(@is_dir($destinationFolder) || @mkdir($destinationFolder, 0755, true))) {
Achtung: Änderungen an Core-Dateien sind häufig wenig sinnvoll. Die Dateien sollten vor einer Anpassung gesichert werden. Bei Updates Core-Dateien erneut überschrieben werden!
Magento 1.8 & 1.9 Kundenlogin nicht mehr möglich!
Bei einem Update von einer älteren Magento Version auf Magento 1.8 oder Magento 1.9 funktioniert der Kundenlogin manchmal nicht mehr. Hier hilft dem Loginformular ein nicht sichtbares HIDDEN Formularfeld hinzufügen. Bearbeitet werden sollte diese Datei vom verwendeten Template:
app/design/frontend/TemplateName/default/template/persistent/customer/form/login.phtml und/oder
/app/design/frontend/base/default/template/persistent/customer/form/login.phtml
Diese Zeile sollte innerhalb der Formular-Tags eingefügt werden:
<input type="hidden" name="form_key" value="<?php echo Mage::getSingleton('core/session')->getFormKey(); ?>" />
Danach sollten die alten Cookies im Browser und der Magento Cache noch gelöscht werden.
Magento Fehler: Fehlerhafte Verlinkung im Frontend
Nach einem Shopumzug, einer Umstellung der Shopstruktur oder mit der Umstellung auf einen Multishop gibt in manchen Fällen das Problem, dass die Links im Frontend nicht mehr auf die richtigen URL Adressen zeigen. Eine mögliche Lösung ist die Leerung vom eventuell eingesetzten Hardware Cache wie beispielsweise Varnish. Oft hilft auch das Leeren der verwendeten Magento Datenbanktabelle core_url_rewrite und dem Neuaufbau vom Index, entweder in der Indexverwaltung vom Backend (System > Index-Verwaltung) oder über Shell.
Magento Fehler: Magento Cronjob mit cron.php funktioniert nicht
In der Regel wird der Cronjob bei Magento über die cron.sh eingebunden. Hierfür wird die Crontab-Datei bearbeitet. In manchen Umgebungen kann jedoch ausschließlich die cron.php Datei über einen Cronjob angestoßen werden. Damit dies auch in Linuxsystemen funktioniert muss eine Zeile in der Datei cron.php ergänzt werden. Gesucht werden muss an dieser Stelle diese Zeile:
$isShellDisabled = (stripos(PHP_OS, 'win') === false) ? $isShellDisabled : true;
Nach dieser Zeile ist diese Befehlszeile zu ergänzen:
$isShellDisabled = true;
Jetzt sollte der Aufruf der Datei cron.php extern und auch intern funktionieren.
Update: Mit Magento 1.9.2.2 wird der direkte Aufruf der Datei cron.php nicht mehr empfohlen und wird in der .htaccess Datei dieser Version sogar unterbunden. Ist der Aufruf vom Cronjob ausschließlich über diese Datei möglich empfiehlt es sich den Zugriff auf cron.php Datei mit aktivierten Apache Zugriffsschutz zu gestatten. Der Benutzer muss dann von Hand oder über eine Webhosting-Verwaltungssoftware gesetzt werden. Im nachfolgenden Beispiel wird die .htpasswd Datei mit den Benutzerdaten unterhalb vom Magento-Verzeichnis gesucht, was zusätzlichen Schutz bietet.
<Files cron.php>
############################################
## uncomment next lines to enable cron access with base HTTP authorization
## https://httpd.apache.org/docs/2.2/howto/auth.html
##
## Warning: .htpasswd file should be placed somewhere not accessible from the web.
## This is so that folks cannot download the password file.
## For example, if your documents are served out of /usr/local/apache/htdocs
## you might want to put the password file(s) in /usr/local/apache/.
AuthName "Cron auth"
AuthUserFile ../.htpasswd
AuthType basic
Require valid-user
############################################
# Order allow,deny
# Deny from all
</Files>
Magento Fehler: SQLSTATE[23000]: Integrity constraint violation: 1062 Duplicate entry
Dieser Fehler kann in den meisten Fällen mit dem Leeren / Deaktivieren vom Magento-Cache behoben werden. Der Cache-Ordner befindet sich standardmässig an diesem Ort: /var/cache und kann über FTP bearbeitet werden.
Diese SQL-Anweisung in in einem MySQL-Tool wie phpMyAdmin der Magento Datenbank behebt ebenfalls den Fehler:
TRUNCATE `sales_flat_quote`;
ALTER TABLE `sales_flat_quote` AUTO_INCREMENT=1;
TRUNCATE `sales_flat_quote_address`;
ALTER TABLE `sales_flat_quote_address` AUTO_INCREMENT=1;
TRUNCATE `sales_flat_quote_address_item`;
ALTER TABLE `sales_flat_quote_address_item` AUTO_INCREMENT=1;
TRUNCATE `sales_flat_quote_item`;
ALTER TABLE `sales_flat_quote_item` AUTO_INCREMENT=1;
TRUNCATE `sales_flat_quote_item_option`;
ALTER TABLE `sales_flat_quote_item_option` AUTO_INCREMENT=1;
TRUNCATE `sales_flat_quote_payment`;
ALTER TABLE `sales_flat_quote_shipping_rate` AUTO_INCREMENT=1;
TRUNCATE `log_customer`;
ALTER TABLE `log_customer` AUTO_INCREMENT=1;
TRUNCATE `log_quote`;
ALTER TABLE `log_quote` AUTO_INCREMENT=1;
TRUNCATE `log_summary`;
ALTER TABLE `log_summary` AUTO_INCREMENT=1;
TRUNCATE `log_summary_type`;
ALTER TABLE `log_summary_type` AUTO_INCREMENT=1;
TRUNCATE `log_url`;
ALTER TABLE `log_url` AUTO_INCREMENT=1;
TRUNCATE `log_url_info`;
ALTER TABLE `log_url_info` AUTO_INCREMENT=1;
TRUNCATE `log_visitor`;
ALTER TABLE `log_visitor` AUTO_INCREMENT=1;
TRUNCATE `log_visitor_info`;
ALTER TABLE `log_visitor_info` AUTO_INCREMENT=1;
TRUNCATE `report_event`;
ALTER TABLE `report_event` AUTO_INCREMENT=1;
Magento Fehler: SSL Error: Invalid or self-signed certificate while uploading image from backend
In vielen Fällen ist der Flash Uploader im Zusammenhang mit Firewall Einstellungen verantwortlich für diese Fehlermeldungen im Magento Backend bei dem Bilderupload der Shopartikel und CMS-Seiten. Diese Extension ersetzt den Flash Uploader und kann alternativ verwendet werden. Die Extension ist kompatibel zu Magento 1.7.0.x
https://www.magentocommerce.com/magento-connect/Tobias+Renger/extension/1756/no-flash-uploader
Magento Fehler: "Fatal error: Call to a member function generateDesignExceptionSub()"
Der Fehler erscheint bei dem Abspeichern vom Design im Konfigurationsmenü vom Magento wenn Varnish installiert und das kostenfreie Modul von Phoenix installiert ist. In diesem Fall sollte die benannte PHP Datei Observer.php bearbeitet werden.
Fatal error: Call to a member function generateDesignExceptionSub() on a non-object in /app/code/community/Phoenix/VarnishCache/Model/Observer.php on line 303
Die Datei enthält Codefragmente der Enterprise Version vom Modul PageCache, welche auskommentiert werden sollten. Die Zeilen 303 bis 309 sollten über die Kommentarzeichnen /* und */ auskommentiert werden. Das Abspeichern vom Design sollte nun möglich sein. Es erscheint noch eine Notice Meldung von Varnish, welche jedoch ignoriert werden kann.
Magento Fehler: Sofortüberweisung "Fatal error: Call to a member function getMethodInstance()"
Wird in Magento diese Fehlermeldung ausgegeben ist die "Offline Maintenance" Extension aktiviert.
"Fatal error: Call to a member function getMethodInstance() on a non-object in /app/code/community/Paymentnetwork/Pnsofortueberweisung/controllers/PnsofortueberweisungController.php on line 40"
Ein Deaktivieren der Komponente sollte den Fehler beseitigen.
Magento Fehler: kein Login im Adminbereich mehr möglich
Magento hat ein ausgeklügeltes Sicherheitssystem, wo es vorkommen kann, dass man selbst mit korrekten Logindaten nicht mehr das Backend betreten kann. In dem Fall erfolgt eine globale Sperre des Benutzers. Eine Anpassung folgernder Datei muss vorgenommen werden:
app/code/core/Mage/Core/Model/Session/Abstract/Varien.php
Es muss in der Zeile 80 das letzte Komma am Ende der Zeile entfernt werden und die Zeile 81, 82, 83 als Kommentar gesetzt werden:
// 'domain' => $cookie->getConfigDomain(),
// 'secure' => $cookie->isSecure(),
// 'httponly' => $cookie->getHttponly()
Nun sollte ein Login wieder möglich sein.
Magento Fehler: Konfigurationsfehler in Zeile 92
/app/code/core/Mage/Core/Model/Mysql4/Config.php on line 92
Bei einem Shopumzug kann es sein, dass die Datenbank noch an die aktuellen Einstellungen angepasst werden müssen. In dem Fall sollte folgender SQL Befehl in einem Datenbanktool wie phpMyAdmin in der Magento Datenbank ausgeführt werden. Es empfiehlt sich im Anschluss den Cache und die *log Tabellen von Magento zu leeren.
SET FOREIGN_KEY_CHECKS=0;
UPDATE `core_store` SET store_id = 0 WHERE code='admin';
UPDATE `core_store_group` SET group_id = 0 WHERE name='Default';
UPDATE `core_website` SET website_id = 0 WHERE code='admin';
UPDATE `customer_group` SET customer_group_id = 0 WHERE customer_group_code='NOT LOGGED IN';
SET FOREIGN_KEY_CHECKS=1;
Magento Fehler: Grid.php in Zeile 1622
app/code/core/Mage/Adminhtml/Block/Widget/Grid.php on line 1622
Ersetzen Sie in folgender Datei die benannten Skriptzeilen und leeren im Anschluß den Magento Cache.
app/code/core/Mage/Adminhtml/Block/Widget/Grid.php
public function getRowUrl($item) { $res = parent::getRowUrl($item); return ($res ? $res : ‘#’); } |
ersetzen durch: |
public function getRowUrl($item) { $res = parent::getUrl($item); return ($res ? $res : ‘#’); } |
Magento Fehler: Bestellungen sind im Backend nicht mehr aufrufbar
Installieren Sie das DebitPayment Modul.
https://www.magentocommerce.com/magento-connect/therouv/extension/676/bankeinzug--lastschrift-debit-payment-
Magento Fehler: Shopsuche funktioniert nicht mehr
Das Modul Market-Ready-Germany hat in verschiedenen Versionen Probleme mit der Magento internen Shopsuche. In dem Fall sollte folgende Option deaktiviert werden:
System >>> Konfiguration >>> Erweitert >>> Flagbit_FactFinder >>> Deaktivieren
Magento Fehler 500: Internal Server Error
Häufig ist ein zu niedriges Memory_Limit oder falsche Datei- und Verzeichnisrechte die Ursache für den Internal Server Error. Die Rechte können über FTP korrigiert werden, mit Shellzugriff sind diese jedoch schneller angepasst. Für PHP als CGI sollten diese Rechte mit der Kommandozeile gesetzt werden:
find . -type f -exec chmod 644 {} \; && find . -type d -exec chmod 755 {} \; && chmod o+w var var/.htaccess includes includes/config.php app/etc && chmod 550 pear && chmod -R o+w media
Magento Fehler: Backend nach Umbenennung nicht mehr erreichbar
In der Datenbank existieren in der Tabelle "core_config_data" folgende Einträge:
admin/url/use_custom
admin/url/custom
web/secure/base_url
web/unsecure/base_url
Diese Einträge sollten nach einem Backup gelöscht werden. Der Datei Cache sollte anschließend auch geleert werden.
Magento Fehler: Could not determine temp directory, please specify a cache_dir manually
Der Fehler besagt, dass das Cache Verzeichnis nicht angelegt wurde wo der Shop die Datenbankabfragen in Dateien ablegt um Magento schneller zu machen. Das Verzeichnis sollte als Unterverzeichnis vom Verzeichnis /var angelegt werden:
/var/cache Groß- und Kleinschreibung ist auf Linux-Systemen zu beachten!
Nun ist eine Anpassung in diesen Dateien notwendig:
app/code/core/Zend/Cache/Backend/File.php
protected $_options = array(
'cache_dir' => 'null',
=>
protected $_options = array(
'cache_dir' => 'var/cache/',
lib/Zend/Cache/Backend/File.php
protected $_options = array(
'cache_dir' => null,
=>
protected $_options = array(
'cache_dir' => 'var/cache/',
Magento Fehler: Artikel Import einer CSV Datei schlägt fehl
Die Erweiterung "Marked Ready Germany" installiert verschiedene Zusatzmodule, welche nicht alle Einsatzzwecke berücksichtigen. Das Anlegen von Artikeln im Backend ist möglich, der Import von Produktdaten über eine CSV Datei schlägt jedoch fehl. In dem Fall ist die Ursache für den Effekt das Unter-Modul SetMeta der Firma Symmetrics. Die Fehlermeldunng bei einem Import von Artikeln über CSV lautet wie folgt:
Integrity constraint violation: 1062 Duplicate entry 'xxx-y' for key 'IDX_STOCK_PRODUCT'
Hier sollte sowohl im Backend das Modul deaktiviert werden, als auch direkt in der folgenden Datei der Status von "active" auf "false" gesetzt werden:
app/etc/modules/Symmetrics_SetMeta.xml
Eine Leerung vom Magento Cache ist danach durchzuführen.
Tipp: In manchen Fällen hilft ein manuelles Erstellen eines konfigurierbaren und einfachen Produkts in Magento, um die Datenbankstruktur zu reparieren. Die Magento Fehlermeldung ist in dem Fall leider etwas irreführend.
Magento Fehler: Invalid entity model - Ungültiges Entitätsmodell
Der Fehler entsteht wenn das temporäre Verzeichnis vom Server nicht beschrieben werden kann. Der Magento Fehler lässt sich beheben in dem in einer bestimmten Datei das Verzeichnis manuell auf ein existierendes Verzeichnis gesetzt wird.
app/code/core/Mage/ImportExport/Model/Export/Adapter/Abstract.php
Hier muss in Zeile 60 diese Anweisung gesucht
$destination = tempnam(sys_get_temp_dir(), 'importexport_');
und mit dieser Anweisung ersetzt werden:
$destination = tempnam(Mage::getBaseDir() . '/var/tmp/' , 'importexport_');
Es empfiehlt sich jedoch immer das Änderungen an Core-Dateien updatesicher auszulagern. Im dem Fall sollte die oben genannte Datei in diesem Verzeichnis kopiert und bearbeitet werden: app/code/local/Mage/ImportExport/Model/Export/Adapter/Abstract.php
Nun muss nur noch sichergestellt werden, dass der Ordner /var/tmp im Magento Verzeichnis existiert und beschreibbar ist. Dann sollte dieser Magento Fehler nicht mehr auftreten.
Magento Connect Manager: Invalid response headers returned from server.
Können im Magento Connect Manager keine Extensions mehr installiert werden und erscheint diese Fehlermeldung "Invalid response headers returned from server.", sollte im Magento Connect Manager zum Bereich Settings gewechselt werden und hier vom Protokoll HTTP auf das Protokoll FTP gewechselt werden.
Settings > Magento Connect Channel Protocol: > Ftp
Keine Schaltfläche für den Bilderupload beim Anlegen von Artikeln
Die Lösung dafür ist recht einfach. Magento verwendet zum Upload Flash. Das Plugin muss dementsprechend im Browser aktiviert sein.
Falsche Dateirechte nach Magento Backup bei PHP FPM, PHP CGI
Magento hat mit der Version 1.7 eine eigene Backupfunktion wo ein Systembackup, Medienbackup oder die Datenbank gesichert werden kann. Im Magento Connect Manager lassen sich Datei- und Verzeichnisrechte bei Installationen für Extensions und - Updates festlegen. Leider wird die Einstellung vom Backup ignoriert.
Setting > use custom permissions > Yes
Damit bei einem Magento Backup der Shop erreichbar bleibt, muss eine Datei "von Hand" bearbeitet werden:
lib/Mage/Archive/Helper/File.php
Diese Zeile legt die Dateirechte bei einem Systembackup fest:
public function open($mode = 'w+', $chmod = 0666)
Für PHP CGI oder PHP FPM sollten die Rechte von 0666 auf 0644 korrigiert werden.
Bei einem Magento Update muss die Datei ggf. erneut bearbeitet werden.
Magento Connect Manager Fehler: Magento_Db_Adapter_Pdo_Mysql not found
Die Fehlermeldung im Magento Connect Manager "Magento_Db_Adapter_Pdo_Mysql not found" resultiert in vielen Fällen aus der Kompilierung vom Onlineshop und einer nachträglichen Anpassung. Auch die Aktualisierung der bestehenden Extensions führen zu diesem Fehler.
Es gibt 2 Möglichkeiten die Kompilierung rückgängig zu machen. In jedem Fall sollte jedoch der Cache und die Sessionverzeichnisse unter /var/cache/ und /var/session/ zuvor geleert werden. Im Verzeichnis /includes/ befindet sich die Datei config.php. Diese Datei beinhaltet die folgende Codezeile:
define(‘COMPILER_INCLUDE_PATH’, dirname(__FILE__).DIRECTORY_SEPARATOR.’src’);
Diese Codezeile muss wie folgt auskommentiert und die Datei abgespeichert werden:
// define(‘COMPILER_INCLUDE_PATH’, dirname(__FILE__).DIRECTORY_SEPARATOR.’src’);
Alternativ gibt es auch die Möglichkeit den Kompiler über die Shell-SSH-Konsole mit diesen Befehlszeilen zu deaktivieren:
Prüfen ob der Kompiler aktiviert ist: $ php -f shell/compiler.php -- state
Deaktivieren vom Kompiler: $ php -f shell/compiler.php -- disable
Löschen der kompilierten Daten: $ php -f shell/compiler.php -- clear
Alle Vorschläge und Tipps sollten nur an zuvor gesicherten Dateien, Datenbanken durchgeführt werden und erfolgen ohne Gewährleistung nur auf eigenes Risiko!