Jump to content
xt:Commerce Community Forum

Nach Update 4.0.13 Schleife beim Checkout!


gabbi

Recommended Posts

Ich habe das Update auf 4.0.13 nach Anleitung korrekt vollzogen.

Aber: Nachdem man Artikel in den Warenkorb gelegt hat und dann den Button "Zur Kasse" betätigt, erhält man immer wieder die gleiche Seite "www.shopname.de/index.php?page=cart"!?

Der Link auf dem Button "Zur Kasse" lautet jedoch eigentlich "https://ssl.webpack.de/shopname.de/index.php?page=checkout&page_action=shipping&xa0a26=l6fbgu90266jtkn2j6dv3ihlm7" (Verwendung von SSL Proxy!)

Und wenn ich direkt auf "Warenkorb" klicke, bekomme ich den Hinweis "Sie haben noch keine Artikel in Ihrem Warenkorb."

Ich nutze ein angepasstes Template, habe aber auch bereits erfolglos mit dem aus dem aktuellen Update überschriebenen "xt_default" getestet.

Das hat bei 4.0.12 alles einwandfrei funktioniert.

Woran mag das liegen?

Edit: Habe gerade festgestellt, dass der Shop alle Produkte im Warenkorb verliert, sobald man eine SSL verschlüsselte Seite aufruft. Sobald man eine nicht verschlüsselte Seite anwählt, befinden sich die Produkte wieder im Warenkorb - es lässt sich aufgrund dieses Problems wie oben beschrieben jedoch keine Bestellung ausführen! Das hat wohl etwas mit SSL / htaccess zu tun?

Link to comment
Share on other sites

Hat niemand sonst ein Problem damit? Mittlerweile habe ich noch einmal alle Dateien im FTP Verzeichnis durch die neuen aus der 4.0.13 ersetzt (außer die in der Anleitung beschriebenen), zusätzlich mit Standard Template getestet, das Problem besteht leider weiterhin.

Es kann also nur sein, dass der DB Updater dahingehend etwas falsch aktualisiert hat (obwohl dieser "Erfolg" gemeldet hat) oder im Code der neuen Dateien ist ein Bug, da ich ja sonst keinerlei Änderungen vorgenommen habe und zuvor in der 4.0.12 der gesamte Bestellprozess einwandfrei funktioniert hat!?

Die "htacess"-Dateien habe ich auch alle noch einmal aus dem Update auf den Server gespielt.

Irgendwas hat das Update gründlich zerschossen. Glücklicherweise ist der Shop noch nicht online, dies sollte aber zeitnah erfolgen. So gibt das aber leider nichts...never change a running system!

Edit: Das Kontaktformular funktioniert auch nicht mehr!! Beim erstmaligen Versuch, dieses abzuschicken, erscheint kein Captcha Code. Dieser wird jedoch angemeckert beim Absenden. Danach erscheint ein Code und wiederum beim Absenden der Hinweis, dass dieser falsch sei!?

Link to comment
Share on other sites

Hallo,

hast du alle cache ordner leer gemacht.

Plugin_cache

template_cache

cache

LG

Ja, alle Caches geleert inkl. Browser Cache usw.

Ich habe momentan keine Erklärung für dieses Verhalten und komme nicht weiter. Der Shop läuft auf einem neuen und aktuellen Virtual Server bei Hosteurope, auf dem die 4.0.12 einwandfrei lief!

Ich habe auch schon alle Dateien vom Server gelöscht und die 4.0.13 Dateien komplett neu hochgespielt. Keine Änderung. Ich weiß nicht, ob es an der Datenbank liegt, aber dazu gab es ja den Updater. Es ist wohl eindeutig ein Fehler der neuen Veyton Version!?

Link to comment
Share on other sites

Danke für den Hinweis. Damit funktioniert es leider auch nicht.

Mittlerweile auf dem Testsystem noch einmal die neuste Version eingespielt und die besagte Datei "database_handler.php" ersetzt etc.

Jetzt kommt man aber gar nicht mehr zum SSL Bereich beim Checkout!? Sobald man einen Artikel in den Warenkorb legen möchte (Button "Warenkorb" direkt beim Produkt), erhält man eine weiße Seite mit folgender URL:

"http://www.domain.de/shop_dev/index.php?page=cart"

Bei Klick direkt auf den globalen "Warenkorb"-Button wird zwar eine SSL URL ausgegeben:

"https://ssl.webpack.de/domain.de/shop_dev/cart?x09b85=aorjnm8ekjp69foub5vvj9b0i6"

Aber es erscheint gleichfalls nur eine weiße Seite.

Es geht also nicht weiter...

Das Kontaktformular wird jedoch einwandfrei per SSL aufgerufen.

Wie gesagt läuft auf dem gleichen Server eine Veyton Version 4.0.12 einwandfrei, ebenfalls mit SSL Proxy usw. Bestellungen und alles andere funktionieren problemlos.

Dafür muss es doch eine Erklärung geben!? Meines Erachtens kann dies nur an einer Änderung innerhalb einer Datei oder einer Tabelle in der Datenbank der neuen 4.0.13 liegen, die sich mit der Serverkonfiguration nicht verträgt. Diese läuft aber wie gesagt problemlos mit 4.0.12 und da es sich um einen stets aktuellen Managed Server handelt, ist es mehr als unverständlich, warum eine neue Shopversion damit nun wieder nicht funktioniert.

Die Fehlersuche gestaltet sich viel zu aufwändig und meiner Meinung nach sollte ein solches Update vor der Freigabe genauer geprüft werden.

Link to comment
Share on other sites

Das update ist auch bei Hosteurope geprüft worden.

Solche fehler (weisse seiten) können ansich nur auftreten wenn ein Update nicht vollständig durchgeführt wurde, und zb nicht alle Shopdatein korrekt überschrieben wurden.

Alle Probleme mit weißen Seiten bisher, waren auf Fehler welche bei Update gemacht wurden zurückzuführen.

Link to comment
Share on other sites

Ok, danke. Eigentlich hatte ich das bereits getan. Ich werde dann jetzt noch einmal zuerst alle Dateien aus dem Webspace löschen und erneut alles hochspielen. Falls es dann immer noch nicht funktioniert, wird wohl irgendeine Datei nicht korrekt übertragen, was aber auch recht unwahrscheinlich ist.

Ich poste das Ergebnis...

Link to comment
Share on other sites

Funktioniert definitiv nicht!

Alle Dateien aus dem Webspace des Testsystems gelöscht und danach die Dateien der 4.0.13 komplett neu hochgespielt (inkl. der neuen "database_handler.php). "config.php" angepasst.

Beim Versuch, einen Artikel in den Warenkorb zu legen, erscheint eine weiße Seite, genau wie vorher bereits beschrieben!?

Link to comment
Share on other sites

Ich habe für diesen Test kein angepasstes Template verwendet, lediglich das "xt_default".

Die Servereinstellungen müssten ok sein, da 4.0.12 funktioniert und die Einstellungen der Anleitung folgen bzw. bei der Installationsroutine auch alles grün abgehakt ist.

Link to comment
Share on other sites

  • 2 weeks later...

Danke für den Hinweis. Damit funktioniert es leider auch nicht.

Wenn auf Kasse oder Ihr Konto gelickt wird erscheint diese Meldung.

Fehler: Gesicherte Verbindung fehlgeschlagen

Ein Fehler ist während einer Verbindung mit Liermann Gastronomiebedarf aufgetreten.

SSL hat einen Eintrag erhalten, der die maximal erlaubte Länge überschritten hat.

(Fehlercode: ssl_error_rx_record_too_long)

Link to comment
Share on other sites

funktioniert es mit einem unveränderten 4.0.13 template ?

ansonsten bitte zugangsdaten an den support senden, dieser sieht sich das an.

kann an dieser stelle aber nur ein serverseitiges problem oder fehleinstellungen sein.

Hatte ich getan, seit 10 Tagen leider noch keine Antwort. Jetzt geht erst einmal die alte Version online...

Link to comment
Share on other sites

Hallo,

gibt es für das SSL Proxy Problem schon eine Lösung. Wir sind bei Allinkl und wollen erstmal den SSL Proxy verwenden.

Leider gibt es hier auch ähnliche Probleme:

Ware in den Warenkorb legen geht noch da nicht ssl Verschlüsselt.

Sobald man sich aber auf "Kasse" drückt springt er auf die Anmeldeseite --> hier kann ich mich nicht anmelden da er versucht die SSL Verbindung über den Proxi aufzurufen (customer?page_action=login&x09b85=f14040c9bca71e905fc97e863f23699e) aber immer wieder zurückleitet.

Was kann hier das Problem sein?

Update auf 13 wurde besten Gewissens durchgeführt und alle Caches geleert.

Herzlichen Dank,

Amelie

Link to comment
Share on other sites

Mein Problem ist trotz Supportanfrage auch immer noch nicht gelöst. Ich nutze daher die 4.0.13 nicht in einer produktiven Umgebung, solange sie fehlerbehaftet ist!

4.0.12 läuft bisher einwandfrei und es es ist ohne tiefergreifendes Wissen über die Änderungen zu 4.0.13 nicht nachvollziehbar, warum die neue Version nicht mehr genauso funktioniert. Dort wurde etwas geändert, was unter bestimmten Bedingungen das korrekte Funktionieren der Weiterleitung auf den Warenkorb definitiv verhindert.

Link to comment
Share on other sites

  • 1 month later...

Hmmm also der Support meinte bei mir es liegt an einer Weiterleitung eventuell in der .htaccess Datei. Da ich mich leider hiermit überhaupt nicht auskenne würde ich mich über Hilfe sehr freuen:

Inhalt unserer .htaccess:

RewriteEngine on

RewriteBase /

RewriteCond %{REQUEST_URI} !^/media/

RewriteCond %{REQUEST_URI} !^/extAdmin/

RewriteCond %{REQUEST_URI} !^/skin/

RewriteCond %{REQUEST_URI} !^/js/

RewriteCond %{REQUEST_FILENAME} !-f

RewriteCond %{REQUEST_FILENAME} !-d

RewriteCond %{REQUEST_FILENAME} !-l

RewriteRule .* index.php

RewriteCond %{HTTP_HOST} ^[^.]*\.[^.]*$

RewriteRule ^ http://www.%{HTTP_HOST}%{REQUEST_URI} [R=301,L]

Herzlichen Dank,

Amelie

Link to comment
Share on other sites

Also bei mir läuft das neue System mit den importierten Bestandsdaten und Einstellungen mittlerweile in der Testumgebung mit 4.0.13. Allerdings nicht, wie in der Anleitung beschrieben (Update Vorgang mit manuellem Überschreiben von vorhandenen Dateien). Schon gar nicht, wenn man ein Drittanbieter-Template verwendet.

Ich habe das komplette FTP Verzeichnis gelöscht mit den 4.0.12 Dateien, danach die komplette 4.0.13 Version neu hochgespielt und anschließend einen SQL Import der alten Datenbank gemacht. Bestellen kann man nun und alles andere scheint auch zu funktionieren. Nur habe ich noch ein Problem, was aber wohl an meinem speziellen Template liegt: bei 2 Kategorien (und nur diejenigen, die Unterkategorien haben) bekomme ich nur die Überschrift und die Links zu den Unterkatgeorien, sonst bleibt alles weiß, d.h. kein Content, keine CSS Formatierung etc.

Never change a running system, und wenn, dann vorher auf einer Testinstallation ausprobieren :-)

Link to comment
Share on other sites

Ja leider ist der Support hier sehr verschwiegen :-(

Ich bin jetzt draufgekommen das diese Zeile:

RewriteRule ^ http://www.%{HTTP_HOST}%{REQUEST_URI} [R=301,L]

Also die Weiterleitung der Domain wenn Sie ohne www. eingegeben auf mit www. (was aus Suchmaschinensicht ja unverzichtbar ist da sons DC) das Problem mit dem Proxi SSL verursacht... ohne gehts.

Ist aber für uns keine Lösung!

Leider werden jetzt auf einmal wieder wie wild bei fast jedem Klick im Shop Session IDs an die URLs angehangen... erstens ist dies nicht schön, produziert doppelten und dreifachen Content und zerschießt jegliche statistische Auswertung im Shop...

Ich könnte langsam heulen mit Veyton :-(

Link to comment
Share on other sites

Archived

This topic is now archived and is closed to further replies.

×
  • Create New...