Service Pack 4.7.2.3 erschienen

Guten Morgen. Es war ein Browser Problem wie von Support geschrieben:
"Lösche daher einmal Cache und Cookies deines Browsers und teste die Ansicht erneut."
...gemacht und Fehler weg.

 

Ja, wenn der Server meldet, dass eine zu löschende Datei auf dem Server nicht existiert, ist das natürlich ein Browser-Problem… /i

 

Äh, nein. Die Geschichte ist zwar deutlich unterhaltsamer als die Realität. Aber ich fände es doch sinnvoller, mal bei den Fakten zu bleiben und sich entweder den Code anzuschauen oder zu sagen: Ist nur ein Schönheitsfehler, kann man ignorieren.

 

...dem stimme ich zu.
Zumal das Problem bei einem weiteren Shop mit gleichen Datenstand dieses "Problem" nicht hatte, auch ohne löschen des Browser-Caches.

 

Alles klar

 

Wundere dich über Browser Caches Dominik. Da reicht manchmal schon ein im Browser gecachtes Javascript oder ein kaputtes Cookie, vielleicht was altes von vor einem Update, schon haste den Salat. Wir erinnern uns zum Beispiel an die Diskussion um Bust Parameter... Hilkes Erklärung ist aus meiner Sicht nicht per se tot oder falsch, die konnte gut recht haben.

Und damit finde ich das unfair und nicht zuende haltbar:

Ich sehe zwar auch nicht, dass Hilke hier mit ihrem Schuss sicher recht hatte, aber eben auch nicht das Gegenteil. Und dann finde ich konnte man das nicht sagen.

 

Wieso Hilke? Günter hat den "Support" zitiert. Dieser ist ein abstraktes Wesen und kann mit bisschen Ironie schon umgehen. Aber sorry, wenn das ein Ticken zu uncharmant war.

Ich sehe halt die 3 Zeilen:

Code:

        if (file_exists($filePath)) {
            unlink($filePath);
        }

Ganz offensichtlich liefert file_exists() true, obwohl die Datei nicht (mehr) existiert. Und das ist nun mal kein Browser-Problem.

 

GProtector/cache 755 lässt kein Schreiben von Cache-Dateien zu, sofern der Ordner cache dem FTP-User gehört, was sehr wahrscheinlich der Fall ist. Setze die Rechte auf 777.

Wir werden ein clearstatcache vor dem unlink hinzufügen, was dann für den Fall hilft, dass ein parallel laufender PHP-Prozess im selben Moment löscht. Ein zweimaliges unlink kann nicht das Problem sein, da unlink automatisch ein clearstatcache ausführt und entsprechend ein file_exists darüber informiert ist, es sei denn man hat eine ungewöhnliche Serverkonfiguration. Ich habe es hier selber in einer Entwicklungsumgebung und auch bei ganz wenigen Kunden habe ich es schon gehabt, dass das Dateisystem nicht in sync mit PHP ist. Da gibt ein unlink ein true zurück und selbst nach einem clearstatcache gibt ein file_exists immer noch ein true zurück, es sei denn man wartet ziemlich lange (viele Millisekunden). Gerade wenn die Festplatte ein Netzlaufwerk ist. Aber das ist dann nicht mehr mein Fachgebiet...

Ich glaube was Hilke sagen wollte, dass der Browser-Cache der Auslöser, nicht die Ursache des Problems ist. Dass da aus dem Cache ein Aufruf kommt, der so vom Shop nicht vorgesehen ist, der dann im Shop einen nicht vorgesehenen Ablauf auslöst, der zu dem Fehler führt. Wie dem auch sei, wir bessern das nach.

 

Ja, da passieren wirklich merkwürdige Dinge. Letzte Idee in der Sache: Wenn die Datei ohnehin 2 Zeilen drunter neu erstellt bzw. befüllt wird, könnte man sich das vorherige Löschen doch auch einfach sparen...

 

Das geht schief, wenn die Datei nicht beschreibbar ist, was passiert, wenn man die Datei z. B. aus einer Dateisicherung hochgeladen hat und sie dann nicht mehr dem www-User gehört. Daher löschen wir immer vorher.

 

Das hat funktioniert.
Schade das man über das Ticket so eine korrekte Antwort nicht erhält, obwohl man für die Beseitigung solcher Fehler von Gambio auch noch bezahlt.

 

Du hast per Support-Ticket Hilfe bekommen, die für dich das Problem gelöst hatte und für die du dich bedankt hattest. Nicht alle Mitarbeiter im Support sind ausgebildete Informatiker, aber wäre das Problem nochmals aufgetreten, wäre der Fall an einen Entwickler weitergegeben worden und wir hätten dir wie hier im Forum geholfen. Ich glaube da kannst du uns wirklich nicht vorwerfen keinen Leistung für das zu bekommen, wofür du bezahlst. Die Supportfälle sind viel zu unterschiedlich, als dass jeder Supporter auf alles immer sofort die 100% richtige Antwort hat, aber wenn mal was nicht auf Anhieb die richtige Antwort ist, dann findet sich bei uns schon der Experte, der den Fall löst. Es ist ja jetzt nicht so, als hätte dich jetzt ein Supporter mit einem Problem stehen gelassen.

 

Hallo,

Nachdem bis Version 4.0.0.... bald nicht mehr gesupportet wird (war eh sehr lang) hab ich mich nach ewiger Zeit aufgemacht ein Shopupdate durchzufuehren - von 4.0.0.1 auf 4.7.2.3 - schlotter ob das geht ;-)
Also einmal Hauptshop und Testshop gesichert - über 40000 (vierzigtausend) Dateien! Datenbanken gesichert.
Und dann gehts los aus dem Updatepaket nach der pdf zum Installieren vorgegangen.
Allein beim Testshop Hauptverzeichnis waren das über 11000 Dateien zum Hochladen!
Nach Hochladen aller Dateien und Lauf des Updaters (ist in der pdf gut beschrieben) Cache im Shop und Browser gelöscht und eingeloggt. Keine Fehlermeldung und Bestellung geht problemlos. Nur im Admin wurden einige Punkte mit "Seite nicht vorhanden" bemängelt.
OK - Ticket gemacht und wie meist: selber Schuld gg: Obwohl der Shop sie verlangt hatte ich keine .htaccess erzeugt/hochgeladen.
Schwupps - alles geht und die Neuerungen gefallen. Jetzt kommt bald der Hauptshop dran.

Warum das ganze Geschreibsel:
Einfach ein dickes Lob an das Team, das auch Jahre alte Shops noch aktualisiert und man bei 11000 hochgeladenen Dateien keinen Fehler entdecken kann. Und es im Team Menschen gibt, die bei etwa 25000 Dateien im Shop sich genau auskennen und sehr sehr wenige Bugs bearbeiten.
Ja - hab wieder mit Befriedigung festgestellt, dass ich vor Jahren das richtige Shopsystem gewählt habe und günstig noch dazu. Und wenn man wirklich ein Problem hat ? Rascher geht es fast nicht.

Toll und danke!
Anton

und Lauf des Updaters ergänzt

 

Guten Morgen Anton,

weil es mich einfach interessiert. Hast Du, da Du den Shop ja augenscheinlich schon lange betreibst, keine individuellen Änderungen oder Module im Shop welche dann von der 4.0er Logik in die 4.7er Logik überführt werden mussten?

Ich frage da das reine durchlaufen von Updates ja wirklich meist problemlos funktioniert. Der Hauptaufwand sind ja dann diverse Anpassungen nachzuführen oder auch mal Zahlungsmodule zu wechseln da ältere nicht mehr vorhanden sind oder zumindest nicht mehr kompatibel sind.

Viele Grüße
Walter

 

Guten Morgen,

Zu Beginn war ich froh den Shop zum Laufen zu bringen. Die vielen Möglichkeiten, welche am Anfang vielleicht irritieren, werden bald ein Segen. Für mich sind alle Erfordernisse durch den Shop abgedeckt und lediglich manche Funktionen habe ich umgemodelt mit Text anpassen etc.
In dem Sinne habe ich noch keine externen Anpassungen, alle externen Schnittstellen wie paypal oder Klarna etc. sind ja auch im Shop integriert.

Schöne Grüße,
Anton

 

Hallo Anton,

danke. Hatte mich nur interessiert und bin bestätigt. Wenn es keine Anpassungen gibt laufen die Updates recht problemlos durch.

Viele Grüße
Walter

 

Update und Testbestellung ohne Probleme. Vielen Dank.

 

Ist es eigentlich Absicht, dass unter Toolbox > Logs anzeigen > Kategorie immer die Kategorie vorausgewählt ist, bei der der letzte Eintrag am längsten zurückliegt? Mich persönlich interessiert meist der jüngste Log-Eintrag und nicht der älteste.

GXMainComponents/Controllers/HttpView/Admin/LoggingController.inc.php

Code:

                if ($mtimeA < $mtimeB) {
                    return 1;
                }
           
                if ($mtimeA > $mtimeB) {
                    return -1;
                }
           
                return 0;

Nicht nur wegen des Spaceship-Operators, sondern vor allem wegen der lästigen Auswahländerung fände ich das so cooler:

Code:

return $mtimeB <=> $mtimeA;