Beiträge von msprint

Hi.
Danke für die ausführliche Info.
Also wirds wohl doch am Provider und dem Erzeugen der SEO Url's liegen. Natürlich war der Provider dann der falsche Anlaufpunkt, da die mir wohl kaum sagen werden, dass es an der Verarbeitung der .htaccess von Seiten des Servers und der Generierung der SEO-Url's liegen wird. Naja....ich denke ich werde den Shop mal bei einem anderen Provider spiegeln. Mal sehen was passiert.

@siekiera

Ich kann dich durchaus verstehen. Undank ist der Welten Lohn.
Ich persönlich habe einfach nur bemerkt, dass der Shop (produktiv) mit der Zeit immer langsamer wurde.
Habe beim Provider nachgefragt, woran es liegen kann.

Irgendwann wurde mir dann der Cache als (potentielle) Quelle genannt. Daraufhin den Cache ausgeschaltet und gelöscht.
Ergebnis: Etwas schneller als zuvor. (Subjektiver Eindruck)

Jedoch war der Cache (trotz "0") bald wieder voll.
Darauf habe ich meine "zugegeben" doofe Frage gestellt, für was der Cache gut ist.
Eigentlich dachte ich immer, dass der Cache dazu dient, den Shop schneller zu machen.

Daher habe ich das Miniprogrämmchen geschrieben, der den Cache auf Knopfdruck löscht...

Daher meine Frage: Dient der Cache dazu, den Shop schneller zu machen ?

Gruß Sven

...wohl nen schlechten Tag erwischt, oder ? :-))

Zitat von Flexus

kann ich jetzt nicht nachvollziehen, was da wie zerschossen wird. müsste ich mir schon anschauen.

Probiere es einfach einmal aus. Ist wirklich so. Auch im Testshop bei der 2.07 Version.

Zitat von Flexus

Flasche Darstellung der Umlaute kann viele Ursachen habe, z.B. falsche
Kollation der Datenbank (ist oft latin1_swedish_ci sollte aber utf8_unicode_ci sein)
man kann sich auch anders helfen, indem man in der entsprechenden
Datei (z.B. checkout.php) die Daten encodiert. Z.B. an der stelle vo die
Daten den Smarty-Tags zugeordnet werden, in diesem Beispiel die AGB
anstatt:

Code

$smarty->assign( 'AGB', $checkout->getAGB('text') );

das hier:

Code

$smarty->assign( 'AGB', utf8_encode($checkout->getAGB('text')) );

Aber am besten gleich den richtigen Zeichensatz in Datenbank, Tabellen
und Feldern anlegen, dann spart man sich das.

Alles anzeigen

Hast Du das bereits getestet ?
Weil es geht im Grunde um die Änderung der Lieferadresse und Rechnungsadresse.

Wenn sich ein Kunde anmeldet läuft das über die create_account.php --> da passt ja alles (utf8-konform)

Nur: Verwendet man die checkout.php (1-Klick-Checkout) als Bestellprozess, dann werden neu hinzugefügte Adressen jeglicher Art zerschossen.
Dafür suche (ich speziell) jetzt eine Lösung.

Könntest Du deinen Ansatz kurz diesbezüglich erläutern.

Großartigen Dank voraus.

Ja, genau.

Klappt es denn ?

Zitat von siekiera

Mir? Mehr gibt es nämlich nicht... Hab's mittlerweile mitgelesen. Da muss ich wohl mal gucken an was es hängt.

Das wär klasse. :-))

Das 1-Klick-Checkout ist im Grunde eine tolle Sache...aber wohl nicht utf8 konform.

Zitat von mbdesign

auf jeden Fall noch in der boxes.php im Tempate folgendes auskommentieren bzw. ändern in

#define('FORCE_CACHE',true);
define('FORCE_CACHE',false);
....

Ach ja.......vielen Dank für deine Hilfe !!!!

Gruß Sven

Mal ne (sau-)blöde Frage

Für was ist der Cache eigentlich gut ?

Hab ein Miniprogramm zum manuellen Löschen des "cache" Ordners im root geschrieben.

Ist wirklich nix besonderes und mit Sicherheit ausbaufähig...

Aus Zeitgründen habe ich aber nur das Nötigste gemacht...wer Interesse hat, bitte einfach PN.

Gruß Sven

Ist das Problem den Proggern vom SEO Commerce bereits bekannt ?
Es ist ja bereits das 7. Fixpack draussen und das Problem noch nicht behoben.
Will nicht meckern, sondern nur nachfragen...vielleicht ist das ja noch niemandem (oder zu wenigen Leuten) aufgefallen ?!?

Also hier nun ganz "offiziell" die Frage an die, die mit dem 1-Klick-Checkout arbeiten:
Kennt / Habt ihr das Problem bei der Lieferadressenänderungen mit den Umlauten und dem "ß" ?
Ist das vielleicht nur ein DB Problem mit utf-8 und latin oder ggf. durch Servereinstellungen der Provider bedingt ? (oder beidem...)

Würde mich über eure Antworten sehr freuen.

Danke im voraus,
Sven

...diese Frage stelle ich mir auch ständig !
Leider habe ich da auch keine Antwort drauf...

Es besteht im Checkout Modul ein massives Problem mit der Adresseiengabe.
Das wurde zwar auch in diesem Thread erwähnt, aber keine ging darauf ein...daher möchte ich das nochmals tun.

Das Problem besteht im übrigen ebenso im Testshop...nur zur Info.

Jeder sollte einmal eine Testbestellung anstoßen und dann im 1-Klick-Checkout die Lieferadresse abändern.
Einfach einmal mit eine paar Umlauten arbeiten und ihr werdet sofort sehen, was ich meine.

Ist das Problem bekannt und gibt es ggf. bereits eine Lösung dafür ?

Danke und mfg
Sven

Leider keine Antwort erhalten.
Ist der Fehler nun behoben ?

Gruß Sven

Hm - Ok - dann vielleicht so - ich habe ein Printscreen vom Testshop (http://v2ce.xt-seo.de) zur besseren Darstellung gemacht:
[Blockierte Grafik: http://www.ms-printware.de/seo_shop_fehler.jpg]

Bitte einfach mal nachrechnen - die Steuer stimmt nämlich nicht!

Danke an den/die Progger fürs Fixpack 5.
Ich finde, dass sollte auch einmal gesagt werden.

...trotzdem weiter fleißig Bugs reporten

...wird wohl noch ein bisserl dauern, da ständig neue Sachen hinzukommen.
Ich denke der Admin möchte das wohl so weit wie möglich in einem "Aufwasch" erledigen.

Ein weiteres Problem mit der checkout.php (sind wir die Einzigen, die das testen...?)

Möchte man als Kunde eine andere Versandadresse angeben, wird ein XML Error erzeugt. Dieser Fehler tritt aber nur auf, wenn der Kunde einen Umlaut im Namen oder in der Adresse verwendet. (siehe Bild im Anhang)
Zwar gibt es für das erste Problrm noch keine Lösung, jedoch ist das neue Problem wesentlich zwingender !
Ich frag mich wirklich, warum dies bisher niemandem aufgefallen ist... vielleicht liegts ja auch an unserem Server....kA ?!?

Hier das Bild: http://www.ms-printware.de/bugs/xml_error_checkout_php.gif

Gruß, Sven

Ja genau da ist das Problem

Wenn man beim Steuerklasse "Standard" eingibt werden die Versandkosten so angegeben:
Wählt man eine Zahlungsart aus und klickt auf "Speichern", werden die Versankosten unten im OT_Block plötzlich als netto angegeben. Klickt man auf "Aktualisieren", werden die Versandkosten wieder als Brutto ausgewiesen.
Wählt man wieder eine Zahlart aus, gleiches Spiel....

Wenn man beim Steuersatz "keine" eingibt werden die Versandkosten so angegeben:
jetzt werden die Versandkosten zwar immer richtig angegeben aber dafür tritt das Problem auf dass die MwSt. nicht mehr richtig berechnet werden

Hallo Käsebrot,

danke für Deine Antwort.
Ja, das stimmt dass bei Euch die Versandkosten richtig angezeigt werden aber es tritt bei Euch ein anderes Problem auf!
Die MwSt. wird bei Euch falsch berechnet. (Die MwSt. für die Versandkosten werden nicht berechnet und falsch angezeigt)

Viele Grüsse

Hallo zusammen,

tritt diese Fehler nur bei uns auf? Hat zufällig schon jemand das Modul in seinem eigenen Shop überprüft?

vielen Dank
Gruß Sven