Die 1.06 rev4642 läuft mit UTF-8.
Es gibt soweit ich bislang analysiert habe ein kleines Problem, die Fehlermeldungen auf der checkout_payment-Seite die aus der URL mit GET-Parametern geholt werden.
Grundsätzlich, ja ... aber wenn man wirklich konsequent UTF-8 mit der aktuellen Version nutzen will, muss man zig Dateien anfassen. Um nicht zu sagen: alle!
Denn konsequentes UTF-8 bedeutet eben auch, dass die Quellcodefiles als solche kodiert sind und insbesondere in den Sprachfiles nicht mir HTML-Kodierungen gearbeitet wird (denn die können sich unter Umständen auch mal ändern oder werden als veraltet deklariert).
Wer mal eine IDE hernimmt, die eben mit der nötigen Konsequenz meldet, wenn UTF-8 Kodierungen falsch sind, bekommt bei beinahe JEDER Datei des Shops eine entsprechende Meldung (ich empfehle dazu einfach mal NuSphere PhpEd auf UTF-8 als Standardkodierung zu stellen!).
@xeron
Was soll der neue Shop besser können als der jetzige?
Nur mal so aus dem Handgelenk geschüttelt:
- Konsequentes UTF-8
- InnoDB (geht jetzt auch, wenn man die Installroutinen entsprechend ändert und beim Contentmanager einen Index verbiegt ... aber dazu muss man wissen WAS man macht, WIE man es macht und WO es gemacht werden muss ... und: WANN es gemacht werden muss)
- stimmiges SSL-Konzept (setz mal deinen Shop auf erzwungenes SSL via Serverconfig und ändere beispielsweise mal im Contentmanager einen Text ...)
- konfigurierbares Rabattsystem - ich meine eine Variable in der Conf, die mich zwischen prozentualen und absoluten Rabatten wechseln lässt ... ganz easy eigentlich
- konsistente Nutzung der Artikelstammdaten (Stichwort Artikelgewicht)
- konfigurierbare Versand- und Zahlungsmodule (Stichwort selfpickup und hart codierte Ausschlüsse von Zahlungsmethoden)
- ...
Ich habe hier auf einem Schmierzettel eine Liste von fast 80 Fehlern (und das meine ich wörtlich!), die ich während des Aufsetzens eines Shops für einen Freund behoben habe oder wo ich komplett umstricken musste, damit der Shop
a) unter Sicherheitsaspekten konsistent läuft
b) bei Änderungen der Anforderungen keine Eingriffe in den Core nötig sind oder weitestgehend vermieden werden (der Shop meines Freundes hat etliche neue Config-Vars, die an zig Stellen als switches im Core genutzt werden)
c) unnütze SQL-Anweisungen vermeidet, damit nicht auf der DB rumgehämmert werden muss
d) "ungeschickt" gesetzte Konfigurationsparamter zu keinen SQL-Fehlern ausufern lässt (man kann mittels Konfiguration das Überprüfen von Nutzergruppenberechtigungen komplett abschiessen, weil im Core NULL Überprüfung auf kritische Paramterkombinationen implementiert sind und folglich auch keine fallback-Lösungen!)
e) bei abgefangenen bzw. aufgetretenen Fehlern diese meldet und sich nicht mit einer weissen Seite oder mit undefinierbaren (und im gemeinten Fall sogar konsequent falschen!) Fehlermeldungen verabschiedet (Stichwort Fehlerbehandlung der SMTP-Routinen)
f) nicht mehr mit solchen Meldungen wie "Die Versandkosten können zur Zeit nicht ermittelt werden" die Kunden verprellt (wieder komplett fehlendes fallback-Management)
und einiges mehr, was sich sicherlich erst im Laufe der Zeit herausstellen wird.
Fazit: die neue Version wird vieles besser machen
müssen, als die jetzige! Nicht mal unbedingt im Bereich der Funktionalität aber unter der Haube ist meiner Meinung nach massiver Handlungsbedarf vorhanden!
Nur mal so ein Ding, wo ich Pickel im Gesicht hatte: die Versandmodule testen ihre "Aktivierung" mittels einer Variable aus der DB. Hier wird im Code hart auf "True" oder "False" (Strings, wohlgemerkt!!) abgetestet. Wer bitte macht sowas? Da klappen jedem Programmierer die Fußnägel hoch!
Und mal ganz davon ab, dass an etlichen Stellen im Code auch auf echte Booleans falsch getestet wird und hier einfach die "Gutmütigkeit" von PHP im Bezug auf eine gewisse Notationsunschärfe "ausgenutzt" wird - sollte sich das mal ändern, platzt der Shop an etlichen Stellen!
Variablen werden doppelt belegt und verlieren in bestimmten Konstellationen einfach mal ihren Wert und werfen "weiter hinten im Code" vollkommen unerwartete Ergebnisse.
Und und und ...
