wellrad-Shop 1.3 (cmb)

[frase]

Hi,
Christoph war so großartig und hat den wellrad-Shop PHP 7 und XH 1.7 kompatibel gemacht.

https://cmsimpleforum.com/viewtopic.php ... =20#p60526

Ich bin gerade dabei, das Outfit des Shops etwas zu "modernisieren". U.A. möchte ich das FA-Plugin nutzen, und das Frontend evtl. responsive(r) gestalten. Das wird alles noch ziemlich lange dauern, hat (momentan) noch keine Priorität.

Während der Bearbeitung des Shops (Adminmodus, Warenkorb 1. Schritt) meldet der Debug-Modus:

NOTICE: A non well formed numeric value encountered
..\plugins\wellrad\classes\app\wrs_view.php:188

Das ist kein Fehler, noch nicht mal 'ne Warnung. Aber: Bei Verwendung des fhs_adminmenu blinkt der Käfer ständig.
Könnte man abstellen, wenn man den Debug-Level auf 5 (?) setzt - will ich aber nicht.

Warum hier nicht einfach mal fragen, ob sich das "leicht" abstellen lässt?
Könnte man den numerischen Wert nicht "besser bilden/formen"?

[cmb]

Während der Bearbeitung des Shops (Adminmodus, Warenkorb 1. Schritt) meldet der Debug-Modus:

NOTICE: A non well formed numeric value encountered
..\plugins\wellrad\classes\app\wrs_view.php:188

Das liegt wohl am MIndestbestellwert; der ist per Default auf 20,00 eingestellt, was aber 20.00 sein müsste (da 20,00 für PHP eben kein numerischer Wert ist). Oder eleganter, weil das wohl an anderen Stellen des Shops auch so ist, müsste die 20,00 eben intern in 20.00 gewandelt werden. Das gleiche Problem schlägt bei Schritt 3 des Warenkorbs dann auch wieder zu, weil die Mehrwertsteuer ebenfalls als Kommazahl angegeben ist.

[frase]

Na, da hat sich die Fragerei schon wieder gelohnt.
Danke!

Gibt man die Werte mit Dezimalpunkt ein, ist die Notiz weg - verständlich.
Angezeigt werden sie allerdings später wieder mit Komma.

Ich glaube auch, irgendwo im Code eine Funktion gesehen zu haben, die diese Umwandlung vornimmt.
Offensichtlich tut sie das "zu häufig" bzw. an den falschen Stellen.

Na ja, ich schau' mal weiter.

[cmb]

Oder eleganter, weil das wohl an anderen Stellen des Shops auch so ist, müsste die 20,00 eben intern in 20.00 gewandelt werden.

Okay, hab's mir mal ein bisschen näher angeschaut. Der Produktpreis wird in Product::setPrice() korrigiert, indem einfach alle vorhanden Kommas in Punkte geändert werden. Das ist natürlich nicht ohne bzgl. der Tausendertrennzeichen. Gibt man z.B. 9.999,99 ein, hat man nach dem Speichern 10,00. Okay, sieht man gleich, und Tausendertrennzeichen sind wohl auch beim Wellradshop wenig relevant. Ergo könnte man das str_replace() auch auf entsprechende Werte in WRS_Backend_Controller::saveSettings() anwenden.

Allerdings wäre es vielleicht auch sinnvoll, <input type="number"> zu verwenden, was allerdings nicht die Notwendigkeit einer eventuellen serverseitigen Korrektur nimmt. Aber es macht die Eingabe zumindest auf Smartphones einfacher, wenn numerische Inputs unterstützt werden.

[frase]

<input type="number">

Danke für den Tipp.

[Tata]

Kleine Bemerkungen:
1. Gebe es z.B. Waren gekauft, Einkauf unterbrochen und öffnet man eine der Seiten, fast die gesammte Contentfläche mit dem Inhalt von Einkaufkorb okupiert ist. Es wäre schön, wenn in diesem Fall der Einkaufkorbsinhalt versteckt bleiben würde evt. (ausser Welradseiten) aufklapbar.
z.B.:

shopping-cart-wellrad.jpg

shopping-cart.jpg

2. Wie wäre es mit CSV export/import? Ich weiss, dass die Bilder derart nicht zu Frage kommen, aber Name, Menge, Gewicht, Preis usw. könnten schon einige Vorbereitungen im z.B. Excel einfacher gemacht werden als im Backend.

[frase]

... fast die gesammte Contentfläche mit dem Inhalt von Einkaufkorb okupiert ist ...

Das stimmt.
Ich überlege, ob nur der Button "zum Warenkorb", oder der "Button + Artikelanzahl" im Korb, oder "Button + Gesamtwert" angezeigt werden soll.

Ich bitte um Verständnis:
Es gibt zurzeit keinen Entwickler für den Wellrad-Shop!
Christoph hat bisher nur die Funktionalität unter XH 1.7 hergestellt.
Ich glaube nicht, dass er den Shop weiter entwickeln will bzw. (zeitlich) kann.

Ich selbst arbeite auch nur an der Kosmetik! Mehr kann ich gar nicht.
Es wird dann also eine (cmb)Version 1.3(a) oder so ähnlich geben.

Wenn ich denn irgendwann einmal ein Ergebnis vorlegen kann, dann können wir hier über Wünsche, Fehler und alles Weitere reden.
Möglicherweise findet sich zu diesem Zeitpunkt ein PHP-Experte, der diese Wünsche umsetzt !?

[cmb]

Es wäre schön, wenn in diesem Fall der Einkaufkorbsinhalt versteckt bleiben würde evt. (ausser Welradseiten) aufklapbar.

Schau mal in plugins/wellrad/templates/frontend/cartPreview.tpl. Das sollte eigentlich entsprechend anpassbar sein.

Wie wäre es mit CSV export/import? Ich weiss, dass die Bilder derart nicht zu Frage kommen, aber Name, Menge, Gewicht, Preis usw. könnten schon einige Vorbereitungen im z.B. Excel einfacher gemacht werden als im Backend.

Die Daten werden in plugins/wellrad/data/catalog.php gespeichert. Schaue ich mir diese Datei an, dann können die Produktinformationen nicht unbedingt gut als CSV dargestellt werden; v.a. variants und categories könnten problematisch sein.

[frase]

Die Daten werden in plugins/wellrad/data/catalog.php gespeichert. Schaue ich mir diese Datei an, dann können die Produktinformationen nicht unbedingt gut als CSV dargestellt werden; v.a. variants und categories könnten problematisch sein.

Shop -> Hilfe -> What 's new? -> erster Absatz:

Könnte aus der "catalogue.inc" eher was gebastelt werden?

[cmb]

Shop -> Hilfe -> What 's new? -> erster Absatz:

Interessant. Danke!

Könnte aus der "catalogue.inc" eher was gebastelt werden?

Ob nun als PHP-Array oder -Serialisierung gespeichert wird, ist eigentlich irrelevant. Das Problem liegt eher darin, dass CSV-Dateien eigenlich nur "flache" Datensätze enthalten, hier aber "verschachtelte" Datensätze vorliegen. So gibt es diverse Angaben in en und de (und vielleicht noch anderen Sprachen); ändern sich die Sprachen nicht, dann kann man natürlich jeweils 2 (oder mehr) Spalten im CSV verwenden. Aber was ist mit den Variants, zum Beispiel? Die werden als Array gespeichert, aber wie soll das sauber auf CSV abgebildet werden? In einer relationalen Datenbank würde man diese in einer zusätzlichen Tabelle speichern, und das wäre eben bei CSV auch möglich (eigentlich entspricht eine CSV-Datei im Prinzip einer relationalen Tabelle) — aber das lässt sich dann nicht mehr gut bearbeiten.

Dazu kommt, dass PHPs CSV-Funktionen (fgetcsv() und fputcsv()) so einige "Besonderheiten" haben, die u.U. Probleme bereiten können, vor allem wenn man es mit komplexerem CSV zu tun hat. Einfaches CSV lese und schreibe ich daher lieber "manuell", und zumindest das Lesen von komplexem CSV versuche ich zu meiden.

Ich hab mir nun die Varianten und Kategorien noch mal etwas genauer angeschaut. Beides sind wohl nur einfache Listen, so dass man diese in einem CSV-Feld zusammen fassen könnte (z.B. durch ein anderes Trennzeichen getrennt, als die CSV-Felder). Vielleicht doch praktikabel machbar; ich schau's mir mal an.

Übrigens ist es keine gute Idee, catalogue.inc ungeschütz im data/ Ordner des Plugins zu haben. Den kompletten Inhalt kann sich ohne weitere Vorkehrungen jeder per HTTP anschauen. Bei catalog.php sieht man wenigstens keine Informationen.