Optimal ist die Lösung mit der Systemprüfung nicht, aber zumindest für Version 1.0 würde ich es auch aus Zeitgründen lieber so belassen. Der Shopbetreiber muss halt beim XH-Shop-Plugin dort immer wieder mal nachschauen.Hartmut wrote:Die Systemprüfung (XHShop-About) zeigt dies (Dezimalkomma in der Versandstaffelung) als Fehler an, allerdings ist die Systemprüfung für den Anwender bei der Installation interessant und nicht (so sehr) im lfd. Betrieb wenn die eigentliche Installation abgeschlossen ist und wird deswegen leicht übersehen.
Die Versandkosten werden beim jedem Schritt des Checkout berechnet, sobald der Käufer das Land angegeben hat. Der Wert wird dann in der Session gespeichert. Es könnte schon sein, dass die Neu-Berechnung an einer Stelle aber nicht erfolgt (wäre natürlich ein Bug).Hartmut wrote:Wann werden die Versandkosten berechnet? Beim verlassen des Einkaufskorbes oder wenn die Bestellübersicht aufgerufen wird? Werden die Werte eventuell zwischengespeichert, die dann eine mögliche Änderung in der Shopkonfig nicht mitbekommen?
Denkbar, aber wie kommt der Wert dorthin. Wellrad 1.2.1 hat das "Gewicht" als float gespeichert (also ohne Anführungszeichen), und würde es ['weight']=0,10 heißen, käme es beim Einlesen von catalog.php zu einem fatalen Fehler.frase wrote:Die genannte Debug-Meldung kommt nämlich nur, wenn in der catalog.php irgendetwas falsch steht. In diesem Fall wohl: ['weight'] = '0,10';
Da kommt nämlich eine leidige Eigenart von PHP ins Spiel, nämlich das bei der Wandlung von Fließkommazahlen in Zeichenketten das aktive Locale berücksichtigt wird (aber nicht im umgekehrten Fall).
Code: Select all
setlocale(LC_ALL, 'German_Germany.1252'); // Windows
var_dump((string) 0.1); // => string(3) "0,1"
var_dump((float) (string) 0.1); // => double(0)
Auf jeden Fall aber sollten bei der manuellen Bearbeitung von catalog.php unbedingt alle Preise und Gewichte als Zeichenketten (also in Anführungszeichen) und mit Dezimalpunkt eingegeben werden.
Na ja, normalerweise schon. Aber z.B. bei einem mehrsprachigen Shop (de/en) wird man für en einen Dezimalpunkt wählen, aber die Eingaben erwarten ein Dezimalkomma.frase wrote:Aber eigentlich auch nicht ganz. Man wird wohl eine Einstellung nehmen, die dem Gebietsschema entspricht, und dann stimmt es wieder.
Auf jeden Fall nicht auszuschließen. Mit einem zu heftig eingestellten OPcache dürfte es Probleme geben, da Änderungen an den Produktinformationen nicht unbedingt übernommen werden. Da sollten wir analog zur Behandlung von Konfigurationsdateien nachbessern. Ich glaube aber eher nicht, dass das bei Hartmut das Problem ist.frase wrote:Könnte ein Proxy-(Cache ) irgendeine Rolle spielen?