D3 Modul-Connector 500 Internal Server Error

Hallo liebe Community,

ich weiß, dass es schon viele Einträge zu dem Thema 500 Internal Server Error gibt, aber leider keinen der zu meinem Problem passt.

Mein Problem:
Nach der Installation von D3 Modul-Connector wurde nur noch eine weiße Seite angezeigt. Nach Aufforderung des D3 Supports habe ich die Ordner des Moduls gelöscht. Jetzt wird folgender Fehler angezeigt:

Internal Server Error

The server encountered an internal error or misconfiguration and was unable to complete your request.
Please contact the server administrator to inform of the time the error occurred and of anything you might have done that may have caused the error.

More information about this error may be available in the server error log.

Leider wird in der Log-Datei kein Fehler dokumentiert. Auch folgende Anleitungen haben keine Fehlerdatei erzeugt:

Möchten Sie den Fehler untersuchen gibt es diese zwei Möglichkeiten:

1)Abarbeitung folgender Liste:
Ich erhalte im Shop eine weiße Seite, was nun? – Helpcenter
ab “Wird dort nichts angezeigt, geht es zu Fuß weiter:”

  1. Kurzfristige Einfügung folgender Zeilen in der Datei config.inc.php:

ini_set(‘log_errors’, 1);
ini_set(‘error_log’, ‘/PATH/log/phperror_’.date(“Y-m-d”).‘.log’);
ini_set(‘error_reporting’, E_ALL);
ini_set(‘display_errors’, 0);

Der Pfad(PATH) sollt hier entsprechend ersetzt werden. Hier können Sie jedoch den Wert aus " $this->sShopDir" verwenden.
Anschließend sollte im Verzeichnis /log eine Datei phperror_x.log vorhanden sein.

Das sind zwei Möglichkeiten um Fehlermeldungen zu protokollieren bzw. auszugeben. Erstellen Sie gegebenenfalls ein Backup der angepassten Dateien.

Gibt es doch andere Möglichkeiten den Fehler zu identifizieren?
Kann ich die Ordner auf dem Server einfach per FTP gegen die Backupdateien überschreiben? Könnte das meinen Fehler beheben? :confused:

Vielen Dank für eure Hilfe.

Hast Du eine Lösung gefunden? Bei uns ist es ähnlich, denn nur das Löschen der Dateien und Moduleinträge bringt dann noch was.

[QUOTE=tvtotal;148701]Hast Du eine Lösung gefunden? Bei uns ist es ähnlich, denn nur das Löschen der Dateien und Moduleinträge bringt dann noch was.[/QUOTE]

Hallo tvtotal,

habt ihr die Tipps aus dem FAQ-Eintrag mal ausgeführt? Auf Basis einer weißen Seite läßt sich leider überhaupt keine Einschätzung treffen, was die Ursache sein könnte.

Das Problem ist, dass man direkt nach dem Klick auf Aktivieren nichts mehr machen kann. Der Shop ist tot. Backend und Frontend sind weiss. Es gibt keine Fehlermeldung. Nirgendwo!. Nur das Löschen aller Module und danach jedes Modul wieder aktivieren bringt den Shop wieder ans Licht.

Keine Hilfe ist auch eine Hilfe. Dann bleibt das Modul halt draußen.

salut,

wer soll dir helfen?

Das Forum ist für uns kein Supportkanal(siehe Signatur).
Die Hinweise die wir hier geben genügen bei den meisten Fällen solcher Art bzw. geben damit Aufschluss über die Ursache.
Alles andere lässt sich nur durch individuelle Untersuchungen klären, die wiederum über unseren Support([email protected]) abgewickelt werden.

ceau

[QUOTE=tvtotal;148811]Keine Hilfe ist auch eine Hilfe. Dann bleibt das Modul halt draußen.[/QUOTE]

Hallo,

deine Aussage verstehe ich nicht ganz. Direkt oben wurde dir doch die Empfehlung gegeben, die einzelnen Punkte aus unserem FAQ-Eintrag zu prüfen.
Ein 500er-Fehler “kann alles sein”, da es sich dabei um einen allgemeinen Abbruchhinweis des Webservers handelt -> “Hier Webserver, ich habe das Script beendet”. Was GENAU die Ursache war, ist daraus nicht zu sehen. Vorallem wenn der Shop im produktive-Modus läuft, unterbindet er jegliche Fehlerausgaben, die der Webserver eventuell machen möchte. Aufschlüsse könnte(!) vielleicht noch das errorlog des Webservers geben.

Noch ein Tipp: Oftmals werden die php-Dateien nicht wie in unser Install-Anleitung beschrieben im Binärmodus mit dem FTP-Programm hochgeladen. Das wäre auch noch ein Ansatz.

Ich hatte übrigens genau dasselbe Problem. Es lag im Endeffekt daran, dass die Datenbank noch eine Tabelle aus einer vorherigen Version drinne hatte. Zudem befanden sich noch Leichen des alten D3 Connectors in ettlichen Verzeichnissen, die ich natürlich erst allesamt identifizieren und entfernen musste.

Vorher musste ich noch den Modulcache wie oben ebenfalls geschrieben leeren. Danach habe ich den Connector mit der Step by Step Prozedur durchlaufen lassen, wobei auch nochmal ein SQL-Fehler ausgespuckt worden ist, durch die fehlerhaften Tabellen ebenfalls identifiziert werden konnten.

Der obige Fehler liegt meiner Meinung nach nicht an D3, sondern an einem durch unsaubere Entfernung des vorherigen Moduls oder andere selbst verursachten Unstimmigkeiten am Shop ausgelösten Ursachen.

[QUOTE=coarsy;148820]Der obige Fehler liegt meiner Meinung nach nicht an D3, sondern an einem durch unsaubere Entfernung des vorherigen Moduls oder andere selbst verursachten Unstimmigkeiten am Shop ausgelösten Ursachen.[/QUOTE]

Also das halte ich für Blödsinn. Seit wann darf ein Modul einen Shop lahmlegen und ich bin schuld? Wenn es sich so in den Shop eingräbt und mit den Gegebenheiten nicht arbeiten kann, muss [B]vor[/B] der Installation eine Fehlermeldung kommen und nicht wenn alles zu spät ist.

Wenn Du das Modul oder eine Vorversion vorher nicht sauber entfernt hast, dann ist das neue Modul sicherlich nich daran schuld, sondern Du selbst. Für Blödsinn halte ich das nicht, da das Dir ja nur als Hilfestellung dienen soll und tatsächlich so bei mir eingetroffen ist und genau die selben Symptome aufgetreten sind.

Das alte Modul war noch nicht in der aktuellen Struktur. Zum Beispiel gibt es noch Leichen im Smarty Plugin Ordner. Wenn Du dort mal genau suchst, liegts teilweise an einer einzelnen Datei, die dort aus dem Ordner entfernt werden muss.

Ich glaube kaum, dass D3 eine Routine baut, die genau diese Umstände absucht. Eventuell aber eine konkrete Gebrauchsanweisung für die restlose Entfernen des alten Moduls oder aber auch ein Script, dass unabhängig von einer festen Verdrahtung im Modul prüft. Bissale selbst sollte man schon noch was tun dürfen, oder?

Ach ja, mann kann auch das Modul ganz normal Uploaden und dann sollten bereits die entsprechenden Fehler im phperror.log auftauchen, die wirklich zu sachdienlichen Hinweisen führen. Mein Shop war übrigens dadurch auch mehrere Stunden down, bis ich die Fehler gefunden hatte.

“Blödsinn” bitte nicht persönlich nehmen. Ich sehe das anders, denn bei dem Modul ist eine Prüfung dabei und diese versagt wohl bei Updates. Ist ja nicht das erste Mal, wo das hier besprochen wirdn.

Ja, da hast recht. Aber vielleicht isses ja für Dich und Andere ne Hilfe, damit Euer Shop nicht so lange offline, wie meiner ist :slight_smile:

Hallo,

also wir prüfen in unseren Installations- und Updateroutingen sogar sehr viel ab, damit z.B. Updates sauber durchlaufen. Dadurch benötigen wir keine “update.sql” o.ä. mehr, wo sich der Shopbetreiber die richtigen SQL-Befehle raussuchen muss. Trotzdem können wir sicherlich nicht jedes Szenario bei jeder denkbaren Serverkonfiguration voraussehen. Aber das soll nicht Gegenstand sein.

Die Fakten:
Es gibt einen 500er Fehler, der hier im Forum nicht näher spezifiziert werden kann, ohne das eine exakte Fehlermeldung des Webservers vorliegt. Da kann man gern mutmaßen, führt aber i.d.R. nicht weit.
Einen möglichen Lösungsvorschlag zum sichtbar machen der Meldung haben wir bereits gegeben. Weiterhin hatte ich den Hinweis mit dem Binärmodus gegeben, was gerade bei Neuinstallationen gern falsch gemacht wird. In so einem Fall können wir auf Seiten des Moduls überhaupt nichts machen, da die Moduldateien dabei gar nicht gestartet werden können.
Gern können wir uns den Fall direkt im Rahmen unseres Supports ansehen. Sollte kein Fehler am Modul vorliegen, ist dieser kostenpflichtig.

Weiterhin bieten wir für unsere Module eine kleine Pauschale an, für die wir die Installation auf dem Kundenserver ausführen. Das ist für sehr viele Shopbetreiber die bequemste Variante. Kann natürlich jeder selbst entscheiden.

Und noch ein Tipp am Ende:
Neue Module / Tests sollten nie direkt im Produktivsystem gemacht werden, sondern immer erst in einem identischen staging-System. Diese Empfehlung wird jeder andere Modulanbieter und auch OXID selbst für ihre Produkte und Updates geben.

[QUOTE=tvtotal;148830]“Blödsinn” bitte nicht persönlich nehmen. Ich sehe das anders, denn bei dem Modul ist eine Prüfung dabei und diese versagt wohl bei Updates. Ist ja nicht das erste Mal, wo das hier besprochen wirdn.[/QUOTE]

Wir haben gestern durch einen anderen Fall noch einen Bug entdeckt, der möglicherweise (!) auch die Ursache für dieses Verhalten sein kann. Lade Dir bitte die aktuelle Erstinstallation von unserer Seite (oxidmodule.com/connector) und überschreibe die darin liegenden Dateien lt. Anleitung. Eventuell hilft dies ja.

Ich möchte noch ein Wort als Autor des Connectors zu dem Thema sagen:
Der Connector ist durch seine Art sehr nah am Shopkern angesiedelt. Daher wirkt ein Fehler auch schnell mal auf den gesamten Shop. Das ist uns bekannt und wird bei der Entwicklung durch umfangreichere Tests berücksichtigt. Nun gibt es jedoch zig-tausend verschiedene Shopinstallationen. Von frisch installiert bis komplett verbastelt. Wir versuchen, durch eine Reihe Automatiken mögliche Schwierigkeiten zu erkennen und zu beheben. Für den Großteil der Installationen funktioniert dies. Leider gelingt das auch manchmal in schwierigen Konstellationen nicht. Sofern uns ein Reproduktionsszenario eines Fehlerfalls bekannt ist, stellen wir das nach und beheben dies dann kurzfristig.
Dass gerade bei Deinem Shop die Automatiken nicht funktioniert hat, ist schade. Unsere Bitte nach einer Fehlermeldung ist jedoch notwendig, dass wir das Verhalten nachstellen können. Dafür bitte ich um Verständnis.

Teste bitte das aktuelle Bugfix. Melde Dich ggf. noch einmal direkt bei uns.

Hatte vor einigen Tagen den selben Fehler. Ich habe dann im log-Ordner d3_update.log (oder so ähnlich) gelöscht und dann funktionierte der Shop wieder =D

Guten Tag,

Ich habe leider exakt das gleiche Problem. Habe mir den neuesten Conecter für meinen CE 4.9.2 heruntergeladen. Den Precheck durchgeführt, daraufhin meine Server PHP EInstellungen angepasst (der zend loader war nicht aktiviert)

Mittels binärem Transfermodus habe ich dann die einzelnen Dateien hochgeladen, die TMP daten geleert, mich in den Admin eingeloggt, dass Modul aktiviert.

Und dann, alles weiß, sowohl im Admin als auch im Frontend. Darauf hin in den log geschaut, kein Fehler zu findne.

Haben hier dann sämtliche Beiträge durchfgelesen. Letztlich habe ich noch meine config angepasst ,dass diese die php fehler ausgibt. Danach waren jedoch leider nach wie vor keine sichtbar.

Daraufhin hab ich den Tipp befolgt und nochmal die Dateien hochgeladen. Und dann wurde nun folgender Fehlercode erzeugt

[23-Dec-2014 11:48:19 Europe/Berlin] PHP Fatal error:  Incompatible file format:  The encoded file has format major ID 5, whereas the Loader expects 4 in /xxxxxx/oxid/2015/modules/_d3modcfg/modules/controllers/d3_oxshopcontrol_modcfg_extension.php on line 165
[23-Dec-2014 11:48:22 Europe/Berlin] PHP Fatal error:  Incompatible file format:  The encoded file has format major ID 5, whereas the Loader expects 4 in /uxxxxx/oxid/2015/modules/_d3modcfg/modules/controllers/d3_oxshopcontrol_modcfg_extension.php on line 165
[23-Dec-2014 11:48:48 Europe/Berlin] PHP Fatal error:  Incompatible file format:  The encoded file has format major ID 5, whereas the Loader expects 4 in /xxxxx/oxid/2015/modules/_d3modcfg/modules/controllers/d3_oxshopcontrol_modcfg_extension.php on line 165
[23-Dec-2014 11:48:50 Europe/Berlin] PHP Fatal error:  Incompatible file format:  The encoded file has format major ID 5, whereas the Loader expects 4 in /xxxxx/oxid/2015/modules/_d3modcfg/modules/controllers/d3_oxshopcontrol_modcfg_extension.php on line 165
[23-Dec-2014 11:53:53 Europe/Berlin] PHP Fatal error:  Incompatible file format:  The encoded file has format major ID 5, whereas the Loader expects 4 in /xxxxx/oxid/2015/modules/_d3modcfg/modules/controllers/d3_oxshopcontrol_modcfg_extension.php on line 165

Hallo,

die Meldung besagt, das du das falsche Paket hochgeladen hast.
Wenn in deinem Shop z.B. PHP 5.3 verwendet wird, dann hast du das Paket für PHP 5.4 hochgeladen.

Öffne bitte noch einmal den Precheck-Link. Unter den Prüfungsergebnissen gibt es einen Button für die PHPInfo. Dort findest du die im Shop verwendete PHP-Version. Überschreibe nun noch einmal die Connector-Dateien mit dem richtigen Paket. Im Namen der Connector-zip-Pakete ist die PHP-Version vermerkt.

HTH

Vielen Dank für die schnelle Reaktion.

Habe es inzwischen selbst gelöst bekommen : Mein Tipp : PHP Version 5,4 verwenden, diesen zendoptimzier aktivieren, danach die ganzen dateien hochladen, und mal sämtlichen browser cache leeren.

[QUOTE=ShishaDreams;154358] Mein Tipp : PHP Version 5,4 verwenden, diesen zendoptimzier aktivieren[/QUOTE]

Zend Optimizer geht bis PHP 5.2., für PHP 5.3 und PHP 5.4 wird der Zend Guard Loader benötigt.