Herzlich willkommen zur harmonischen Runde der anonymen Verzweifelten,
Wir passen gerade einen Shop an, der uns einige Kopfzerbrechen bereitet.
Es handelt sich um einen Gambio GX2, was aber imho generell nicht direkt die Ursache ist.
Ich habe den Shop auf den aktuellsten verfügbaren Stand gezogen und am Ende sogar eine komplett jungfräuliche Neu-Installation vorgenommen, da keine Verbesserung erkennbar war.
Das Problem:
Werden POST-Daten übermittelt bzw. soll dies passieren, ist $_POST immer leer!
Im Frontend kaum ein Problem, weil dort kaum was über POST läuft, außer die Suche evtl.
Das Problem wird erst im Backend prikär, da man nicht mal mehr in der Lage ist, Artikelbeschreibungen zu ändern, denn die werden mit POST übertragen.
Details
Der Shop läuft wie zwei weitere versionsgleiche auf einem Webspace, der ebenfalls identisch mit den anderen beiden ist.
PHP läuft als CGI/FastCGI, wie allerdings auch bei den anderen beiden. Der einzige Unterschied ist der, daß der betroffene Shop SSL aktiviert hat.
Nur läßt sich das SSL nicht wieder abschalten. Ich habe auch schon die komplette Konfigurationsdatei aus einem der beiden anderen Shops verwendet ( natürlich Zugänge angepasst, etc. ), aber selbst dann springt er immer wieder auf SSL. In der DB ist auch alles auf NoSSL gestellt.
Debugging
Ich habe den Quellcode analysiert, BreakPoints gesetzt und kann nicht lokalisieren, wo POST die Daten verliert.
Die Änderungen werden über ein normales Formular getätigt, das als Übertragungsmethode logischerweise POST verwendet. Javascripte auf Events gibt es keine, die den POST anfassen.
Dennoch ist am Ziel ( action ) das POST leer!
Warum frage ich euch
Ich hoffe, daß jemand von euch mir evtl. sagen kann woran das liegen könnte.
Vielleicht hat jemand das auch schonmal gehabt ( muß ja nicht mit einem Shop gewesen sein ) und gibt mir neue Erkenntnisse.
Oder vielleicht reißt mir ja sogar jemand 'nen dicken Balken vorm Kopp wech...
Wenn ich nicht ganz blöde bin, dürfte das irgendwas am Server sein, aber nicht an den Quellcodes?!
kurze Info noch: Eine absolut identische Installation habe ich dann testweise auch auf meinem Server mal durchgeführt und dort klappt alles!
Danke für Infos
Wir passen gerade einen Shop an, der uns einige Kopfzerbrechen bereitet.
Es handelt sich um einen Gambio GX2, was aber imho generell nicht direkt die Ursache ist.
Ich habe den Shop auf den aktuellsten verfügbaren Stand gezogen und am Ende sogar eine komplett jungfräuliche Neu-Installation vorgenommen, da keine Verbesserung erkennbar war.
Das Problem:
Werden POST-Daten übermittelt bzw. soll dies passieren, ist $_POST immer leer!
Im Frontend kaum ein Problem, weil dort kaum was über POST läuft, außer die Suche evtl.
Das Problem wird erst im Backend prikär, da man nicht mal mehr in der Lage ist, Artikelbeschreibungen zu ändern, denn die werden mit POST übertragen.
Details
Der Shop läuft wie zwei weitere versionsgleiche auf einem Webspace, der ebenfalls identisch mit den anderen beiden ist.
PHP läuft als CGI/FastCGI, wie allerdings auch bei den anderen beiden. Der einzige Unterschied ist der, daß der betroffene Shop SSL aktiviert hat.
Nur läßt sich das SSL nicht wieder abschalten. Ich habe auch schon die komplette Konfigurationsdatei aus einem der beiden anderen Shops verwendet ( natürlich Zugänge angepasst, etc. ), aber selbst dann springt er immer wieder auf SSL. In der DB ist auch alles auf NoSSL gestellt.
Debugging
Ich habe den Quellcode analysiert, BreakPoints gesetzt und kann nicht lokalisieren, wo POST die Daten verliert.
Die Änderungen werden über ein normales Formular getätigt, das als Übertragungsmethode logischerweise POST verwendet. Javascripte auf Events gibt es keine, die den POST anfassen.
Dennoch ist am Ziel ( action ) das POST leer!
Warum frage ich euch
Ich hoffe, daß jemand von euch mir evtl. sagen kann woran das liegen könnte.
Vielleicht hat jemand das auch schonmal gehabt ( muß ja nicht mit einem Shop gewesen sein ) und gibt mir neue Erkenntnisse.
Oder vielleicht reißt mir ja sogar jemand 'nen dicken Balken vorm Kopp wech...
Wenn ich nicht ganz blöde bin, dürfte das irgendwas am Server sein, aber nicht an den Quellcodes?!
kurze Info noch: Eine absolut identische Installation habe ich dann testweise auch auf meinem Server mal durchgeführt und dort klappt alles!
Danke für Infos
Kommentar