Warenkorb-Funktion mit PHP

[Ingo Siemon]

Hallo

Ich habe nun meinen ersten PHP-Anfängerkurs bei der
Volkshochschole Münster hinter mir.
War aber eben nur ein Anfängerkurs.

Ich habe nun folgendes anliegen und bitte Euch um Rat.

Ich möchte für einen Online-Shop eine ganz einfache
Warenkorbfunktion per PHP realisieren.
Dabei geht es mir erstmal noch nicht um das genaue "Wie?",
sondern um was Ggrundsätzliches.

Bisher habe ich es mit Javascript clientseitig gelöst.
Aber nun möchte ich es eben serverseitig machen,
so dass es auch bei allen Usern mit abschaltetem Javascrift bzw. cookies funktioniert.

Der User soll, wenn er sich auf einer statischen
Produkt-html-Seite befindet, einen Link "in den Warenkorb" vorfinden.
Diese Produkt-Seiten sind tatsächlich auf dem Server vorliegende
HTML-Seiten, also keine dynamische Datenbankgeschichte oder so.

Und mit diesem Klick auf den "in den Warenkorb"-Link soll nun
eben auf dem Server sozusagen irgendwo "festgehalten" werden,
dass dieser User diesen Artikel in den Warenkob geschmissen hat.
Das soll dann natürlich auch mit weiteren Artikeln passieren,
die dieser User (hoeffentlich) kaufen will.

Meine Frage an Euch ist nun, wie man das möglichst einfach lösen kann.
Der User/Kunde soll sich natürlich nicht vorher extra anmelden müssen oder so.

Wie gesagt, mir geht es hier erstmal um das grundsätzliche Verständnis
meinerseits, wie man sowas löst.
Von Sessions in PHP und Session-Cookoes usw. habe ich schon
mal gehört, aber in dem PHP-Kurs hatten wir das leider nicht.
Und so richtig begriffen, wie das abgeht, habe ich natürlich auch noch nicht.

Nun denn, ich würde mich riesig freuen, wenn Ihr mir da
weiterhelfen könntet.

Gruß aus Münster
Ingo Siemon

[ShiNtoKu]

Hallo,

mit Sessions bist du jedenfalls schonmal auf dem richtigen Weg. Als Einstieg würd ich dir auf jeden Fall mal den entsprechenden Abschnitt im PHP Manual empfehlen. Weiterführende Tutorials gibts wie Sand am Meer - evtl. einfach mal googlen ;)

Viele Grüße
Patrick

[Ingo Siemon]

Lieber Patrick

mit Sessions bist du jedenfalls schonmal auf dem richtigen Weg. Als Einstieg würd ich dir auf jeden Fall mal den entsprechenden Abschnitt im PHP Manual empfehlen ...

OK, ich habe mir das schon mal grob durchgelesen.
Es übersteigt aber noch etwas meine PHP-Fähigkeiten.
Aber trotzdem vielen Dank für Deinen Tipp.

Weiterführende Tutorials gibts wie Sand am Meer - evtl. einfach mal googlen ;)

OK, werde ich machen.

Gruß
Ingo

[Auge]

Hallo

Um einen Warenkorb zu befüllen, musst du nicht nur die Daten auf dem Server (zwischen)speichern, du musst sie auch dem einzelnen Besucher zuordnen können. Das für Websites benutzte Protokoll HTTP ist dazu aber nicht geeignet. Es ist zustandslos, das heißt, die Ressource wird angefordert (z.B. Link oder Eingabe der Adresse), ausgeliefert und dann ist Schluss. Der Webserver kann nicht erkennen, dass die vielleicht eine Minute später erfolgende Anfrage vom gleichen Benutzer kommt, wie die vorhergehende.

Genau da kommt die Session ins Spiel. Sie ermöglicht, dass sich der Benutzer durch eine ID wiedererkennen lässt. Die ID wird entweder als Cookie auf dem Rechner des Benutzers gespeichert, oder sie wird als Parameter an jeden Link angehängt und so bei jedem Aufruf an den Server übermittelt.

Der User soll, wenn er sich auf einer statischen
Produkt-html-Seite befindet, einen Link "in den Warenkorb" vorfinden.
Diese Produkt-Seiten sind tatsächlich auf dem Server vorliegende
HTML-Seiten, also keine dynamische Datenbankgeschichte oder so.

Wie du mit diesem System die Informationen zu Preisen etc. lagern willst, ohne auf eine, wie auch immer geartete, Datenbank zurückzugreifen, ist mir allerdings schleierhaft. Du wirst ja nicht bei jedem Produkt im Warenkorblink eine ewig lange Kette von Parametern nach folgendem Schema übermitteln wollen.

http://example.com/shop/produkt_2455.html?produkt=2455&preis=25&farbe=schwarz

Die Nachkommastellen beim Preis habe ich jetzt mal weggelassen, weil ich aus dem Stehgreif nicht weiß, wie der Punkt zu maskieren wäre. :-)

Mit diesem System wären Fälschungen Tür und Tor geöffnet. Jeder könnte den Preis nach eigenem Gusto festlegen. Damit das nicht passiert, müssen solche Informationen auf dem Server vorgehalten werden und nur für die verarbeitenden Skripte zugänglich sein.

Du wirst also nicht um eine Datenbank herumkommen, denn im Warenkorb musst du rechnen können. Ein Kunde könnte mehrere Stück eines Produktes oder verschiedene Produkte mit einem mal kaufen wollen/sollen. Also brauchst du die jeweiligen Preise zur Berechnung des Gesamtpreises.

zu speichern wären für jedes Produkt mindestens:

• eine Produktnummer (eine ID)
• Produktname
• Einzelpreis
• falls erforderlich: Eigenschaften (Farben, Größen u.s.w.)

Du kannst auch Beschreibungen, Pfade zu Bildern des Produkts etc. in der DB speichern, um mit diesen Informationen die Seite des Produkts zu befüllen.

Legt der Kunde ein Produkt in den Warenkorb, kann mit der ID des Produkts, eventuellen Eigenschaften, der zu bestellenden Menge, die in der Session gespeichert werden, und dem Einzelpreis aus der DB immer der Gesamtpreis der Bestellung (zzgl. Versandkosten) errechnet werden.

Zum Auslösen der Bestellung brauchts dann noch persönlicher Daten wie Name und (Liefer)anschrift.

Die Daten (der Datensatz) der Bestellung (Produkte, Mengen, persönliche Daten des Bestellers) landen wohl per Email bei dir. Aber auch hier ist eine Speicherung in einer DB (mehr als nur) sinnvoll. Einerseits kann die Email auf sich warten lassen, du hast also bei Zugriff auf die Daten in der DB eine Rückfallebene, andererseits kannst du dem Kunden, bei entsprechender Pflege der Datenbestände, einen Mehrwert z.B. in Form eines Auslieferungsstatus (Bestellung eigegangen, Lieferung zusammengestellt, verschickt) geben.

Wirklich simpel ist das Ganze also nicht. Zumal meine Beschreibung bestimmt nicht allumfassend ist.

Tschö, Auge

[at]

Hallo.

Der User soll, wenn er sich auf einer statischen
Produkt-html-Seite befindet, einen Link "in den Warenkorb" vorfinden.
Diese Produkt-Seiten sind tatsächlich auf dem Server vorliegende
HTML-Seiten, also keine dynamische Datenbankgeschichte oder so.

Wie du mit diesem System die Informationen zu Preisen etc. lagern willst, ohne auf eine, wie auch immer geartete, Datenbank zurückzugreifen, ist mir allerdings schleierhaft. Du wirst ja nicht bei jedem Produkt im Warenkorblink eine ewig lange Kette von Parametern nach folgendem Schema übermitteln wollen.

http://example.com/shop/produkt_2455.html?produkt=2455&preis=25&farbe=schwarz

Wozu auch, wenn doch http://example.com/shop/produkt_2455.html genügt, sofern diese Ressource die notwendigen Informationen enthält.

Mit diesem System wären Fälschungen Tür und Tor geöffnet. Jeder könnte den Preis nach eigenem Gusto festlegen.

Die Nicht-Notwendigkeit deiner Schreibweise nimmt diesem Szenario aber schon den Großteil seines Schreckens.

Damit das nicht passiert, müssen solche Informationen auf dem Server vorgehalten werden und nur für die verarbeitenden Skripte zugänglich sein.

Aber nicht zwangsläufig für die eizelnen Seiten. Die können durchaus statisch sein, wenn sich die Artikel nicht zu häufig ändern und keine große Gefahr des Ausverkaufs besteht.
MfG, at

[Ingo Siemon]

Hallo

Auch Dir natürlich erstmal vielen Dank für Deine Mühe.

Wozu auch, wenn doch http://example.com/shop/produkt_2455.html genügt, sofern diese Ressource die notwendigen Informationen enthält.

Aber diese Ressource entält doch nun eigentlich nur eine ID
zu einem Produkt. Oder meinst Du sozusagen, dass die anderen
dazugehörigen Produktdaten dann auch in einer Datenbank liegen?

Die Nicht-Notwendigkeit deiner Schreibweise nimmt diesem Szenario aber schon den Großteil seines Schreckens.

Meinst Du, weil eben in der URL nicht die Daten, wie z.B.
Preis usw. sichtbar übergenen werden?

Aber nicht zwangsläufig für die eizelnen Seiten. Die können durchaus statisch sein, wenn sich die Artikel nicht zu häufig ändern und keine große Gefahr des Ausverkaufs besteht.

Nein, die Produktdaten eines Produktes werden einmal angelegt,
wenn das Produkt neu in den Shop kommt. Und dann ändern sie
sich nicht mehr.
Und wenn das Produkt ausverkauft ist, wird einfach die entsprechenden
Produkt HTML-Seite von mir gelöscht.
Im Grunde alles ganz sympel und "manuell".

Sorry, wenn ich mich mit meinen Fragen hier vielleicht noch etwas
dämlich anstelle, aber ich bin bei diesem Gedankengut eben noch sehr neu :)

Gruß
Ingo

[at]

Hallo.
Ich hatte vermutet, dass du genau das meintest, und mit meiner Antwort darlegen wollen, dass ich den Vorschlag, auf den ich geantwortet habe, für eine künstliche Verkomplizierung und im Gegensatz dazu deine Herangehensweise für sehr sympathisch halte.
MfG, at

[Ingo Siemon]

Hallo nochmal

Ich hatte vermutet, dass du genau das meintest, und mit meiner Antwort darlegen wollen, dass ich den Vorschlag, auf den ich geantwortet habe, für eine künstliche Verkomplizierung und im Gegensatz dazu deine Herangehensweise für sehr sympathisch halte.

Bitte entschuldige, wenn ich mich vielleicht doch blöd anstelle,
aber so ganz verstanden hab ichs immer noch nicht.

Wolltest Du denn nun auch sagen, dass es ohne Datenbank eher nicht sinnvoll ist.
Oder meinst Du, dass eben genau diese ganze Datenbank-Geschichte
die Verkomplizierung darstellt?

Gruß
Ingo

[at]

Hallo.

Wolltest Du denn nun auch sagen, dass es ohne Datenbank eher nicht sinnvoll ist.

Ganz ohne Datenbank oder eine entsprechend geartete Textddatei müsste das Skript, welches die Gesamtsumme errechnet, ja bei jeder Auswahl die statischen Seiten nach Preisen durchsuchen. Insofern ist eine Datenbank sicher mehr als sinnvoll.

Oder meinst Du, dass eben genau diese ganze Datenbank-Geschichte
die Verkomplizierung darstellt?

Ich meine, dass die HTML-Seiten nicht dynamisch aus der Datenbank generiert werden müssen, sondern nach dem einmaligen Generieren statisch vorliegen können. Viele Redaktionssysteme arbeiten ja so.
MfG, at

[Ingo Siemon]

Tach wieder :)

Ich meine, dass die HTML-Seiten nicht dynamisch aus der Datenbank generiert werden müssen, sondern nach dem einmaligen Generieren statisch vorliegen können. Viele Redaktionssysteme arbeiten ja so.

Ahhh, nun habe ich es verstanden, glaube ich :)
Das ist ja schon mal schön.
Dann kann ich also meine statischen Seiten schön behalten.

Und die Datenbank oder eine entsprechend geartete Textddatei
würde dann sozusagen den Warenkorb darstellen ... richtig.

Verstehe ich es richtig, das dann diese Datenbank bzw.
diese Textdatei eben mit der Session-Id einem bestimmten Besucher
bzw. Kunden zuzuordnen ist.
Und solange sich dieser auf meinen Seiten aufhällt,
wird alles, was er in den Warenkorb legt, eben in diese Textdatei
geschrieben.
Und die Infos, welche dann da eben reingeschriegen werden sollen,
kommen aus dem Warenkorb-Links meiner Statischen Produkt-Seiten.

Habe ich da so einigermassen richtig verstanden?
Gruß
Ingo

[at]

Hallo.

Habe ich da so einigermassen richtig verstanden?

Um ganz ehrlich zu sein, habe ich da insgesamt so meine Zweifel, da du noch sehr viel durcheinanderwirfst. Da in diesem Bereich aber jeder technische Fehler juristische und wirtschaftliche Konsequenzen haben kann, möchte ich dir an dieser Stelle nur noch raten, dich anhand entsprechender Literatur eingehend mit diesem Thema zu befassen, bevor du durch ein Missverständnis schwere Fehler machst. Für Detailfragen stehen dir dan ja hier wieder einige Spezialisten zur Verfügung.
MfG, at

[Auge]

Hallo

Ich meine, dass die HTML-Seiten nicht dynamisch aus der Datenbank generiert werden müssen, sondern nach dem einmaligen Generieren statisch vorliegen können. Viele Redaktionssysteme arbeiten ja so.

Und die Datenbank oder eine entsprechend geartete Textddatei
würde dann sozusagen den Warenkorb darstellen ... richtig.

Die DB oder Textdatei würde die Informationen zu den einzelnen Produkten aufnehmen. Diese Informationen dienen im Warenkorb zur Berechnung des Bestellwertes.

Verstehe ich es richtig, das dann diese Datenbank bzw.
diese Textdatei eben mit der Session-Id einem bestimmten Besucher
bzw. Kunden zuzuordnen ist.
Und solange sich dieser auf meinen Seiten aufhällt,
wird alles, was er in den Warenkorb legt, eben in diese Textdatei
geschrieben.
Und die Infos, welche dann da eben reingeschriegen werden sollen,
kommen aus dem Warenkorb-Links meiner Statischen Produkt-Seiten.

Nein. Für eine Session wird auf dem Server temporär und automatisch eine eigene Datei angelegt, die du per Skript mit Daten $_SESSION["irgendwas"] = $bla füllst. Mit $_SESSION["irgendwas"] greifst du später wieder auf die abgelegte Information der Session zu.

Bei dir stünden dort die bestellten Waren und ihre Stückzahl sowie die persönlichen Daten drin. Bei jeder Ausgabe des Warenkorbs kannst du nun unter Verwendung dieser Daten und der Daten aus deiner Datenbank den inhalt des Warenkorbes berechnen und anzeigen.

angenommener Fall: Im Warenkorb befinden sich 2 Packungen Butter und ein Liter Milch.

In der Sessiondatei steht:

• Produkt 1:
    - ID: 1
    - Anzahl: 2
• Produkt 2:
    - ID: 3
    - Anzahl: 1

In der DB steht:

• Produkt 1:
    - ID: 1
    - Name: Butter
    - Preis: 1 (EUR)
• Produkt 2
    - ID: 3
    - Name: Milch
    - Preis: 0.50 (EUR)

Wenn der Warenkorb angezeigt wird liest du die Daten der Sessiondatei und suchst dir die dazugehörigen Daten aus der DB. Du hast nun alle Daten da, um den Produktnamen, den Einzelpreis, über die Stückzahl den Gesamtpreis pro Posten und den Gesamtpreis für die ganze Bestellung zu berechnen und auszugeben.

Produkt 1:

• Butter
• Stückzahl: 2
• Preis: 2 EUR

Produkt 2

• Milch
• Stückzahl: 1
• Preis: 0.50 EUR

Gesamtpreis: 2.50 EUR + Versand

Tschö, Auge

[Auge]

Hallo

Oder meinst Du, dass eben genau diese ganze Datenbank-Geschichte
die Verkomplizierung darstellt?

Ich meine, dass die HTML-Seiten nicht dynamisch aus der Datenbank generiert werden müssen, sondern nach dem einmaligen Generieren statisch vorliegen können. Viele Redaktionssysteme arbeiten ja so.

Das mit dem Einfügen von Produktbeschreibung etc. in die Seite des einzelnen Angebots war auch nur ein Hinweis auf eine Möglichkeit. Bei sich nicht oder nur selten ändernden Angeboten ist eine statische Seite natürlich einfacher zu handhaben.

Tschö, Auge

[at]

Hallo.

Bei sich nicht oder nur selten ändernden Angeboten ist eine statische Seite natürlich einfacher zu handhaben.

Und verursacht weniger Last auf dem Server.
MfG, at

[Auge]

Hallo

Bei sich nicht oder nur selten ändernden Angeboten ist eine statische Seite natürlich einfacher zu handhaben.

Und verursacht weniger Last auf dem Server.

Richtig, ich vergaß. :-)

Tschö, Auge

[Ingo Siemon]

Hallo

Und verursacht weniger Last auf dem Server.

OK.
Verstehe ich Euch nun richtig, dass ich das folgendermassen machen kann:

1.
Die Produktseiten sind statische HTML-Seiten,
die nicht dynamisch auf dem Server erzeugt werden,
sondern eben tatsächlich alle einzeln auf dem Server liegen.

2.
Mit dem "in den Warenkorb"-Link wird dann eine Produkt-ID
an ein PHP-Script auf dem Server übergeben.

3.
Dieses Script schaut dann in einer Produktdatenbank auf dem
Server nach, welche Infos (Name, Preis usw.) zu dem Produkt gehören.

4.
Und dieses Script sammelt dann in einer Session-Variablen
alle Artikel die der User in den Warenkorb getan hat.

5.
Usw ...

Es sollte also zu jedem Produkt eine statische HTML-Seite existieren
und eben auch der dazugehörige Datensatz in der MySQL-datenbank ...
richtig?

Gruß
Ingo

[at]

Hallo.

Es sollte also zu jedem Produkt eine statische HTML-Seite existieren
und eben auch der dazugehörige Datensatz in der MySQL-datenbank ...
richtig?

Fast. Die HTML Seiten werden einmalig aus der Datenbank heraus generiert, um Arbeit zu sparen und Inkonstitenzen zu vermeiden. Das entsprechende Skript kann dann bei einer Änderung der vorhandenen Produktdaten oder beim Löschen oder Hinzufügen eines Produktdatensatzes automatisch aufgerufen und so die statischen Seiten aktualisiert werden.
MfG, at

[Ingo Siemon]

Hallo

Fast. Die HTML Seiten werden einmalig aus der Datenbank heraus generiert, um Arbeit zu sparen und Inkonstitenzen zu vermeiden. Das entsprechende Skript kann dann bei einer Änderung der vorhandenen Produktdaten oder beim Löschen oder Hinzufügen eines Produktdatensatzes automatisch aufgerufen und so die statischen Seiten aktualisiert werden.

Aber Du hattest doch am 26. Dezember 2005 um 15:17 folgendes geschrieben:

"Ich meine, dass die HTML-Seiten nicht dynamisch aus der Datenbank generiert werden müssen, sondern nach dem einmaligen Generieren statisch vorliegen können. Viele Redaktionssysteme arbeiten ja so."

Gruß
Ingo

[Auge]

Hallo

Fast. Die HTML Seiten werden einmalig aus der Datenbank heraus generiert, um Arbeit zu sparen und Inkonstitenzen zu vermeiden. Das entsprechende Skript kann dann bei einer Änderung der vorhandenen Produktdaten oder beim Löschen oder Hinzufügen eines Produktdatensatzes automatisch aufgerufen und so die statischen Seiten aktualisiert werden.

Aber Du hattest doch am 26. Dezember 2005 um 15:17 folgendes geschrieben:

"Ich meine, dass die HTML-Seiten nicht dynamisch aus der Datenbank generiert werden müssen, sondern nach dem einmaligen Generieren statisch vorliegen können. Viele Redaktionssysteme arbeiten ja so."

Du kannst die Seiten für die Produkte natürlich offline erstellen. ats Weg, die Seite aus den, in der DB hinterlegten, Infos einmalig zu erstellen, so dass sie hernach statisch vorliegt, hat den Vorteil, dass bei einer Änderung einer oder mehrerer Eigenschaften in der DB die statische Seite wiederum nur _einmal_ überschrieben werden muss, damit die neuen Eigenschaften auch in die statischen Seite übernommen werden. Das kannst du alles mit einem Skript erledigen.

Bei einer Aktualisierung z.B. des Preises in der DB die Aktualisierung der dazugehörigen Produktseite zu vergessen (da diese, wie von dir vorgesehen, getrennt von den Infos in der DB erzeugt wurde), ist eine Inkonsistenz.

Tschö, Auge

[Ingo Siemon]

Lieber Auge

Du kannst die Seiten für die Produkte natürlich offline erstellen. ats Weg, die Seite aus den, in der DB hinterlegten, Infos einmalig zu erstellen, so dass sie hernach statisch vorliegt, hat den Vorteil, dass bei einer Änderung einer oder mehrerer Eigenschaften in der DB die statische Seite wiederum nur _einmal_ überschrieben werden muss, damit die neuen Eigenschaften auch in die statischen Seite übernommen werden. Das kannst du alles mit einem Skript erledigen.

Hmmm, langsam komme ich ganz durcheinander.
Bisher pflege ich meine Produktdaten alle in einer Excel-Tabelle.
Und daraus erzeuge ich dann mit VBA per Makro sozusagen
"auf Knopfdruck" die jeweilogen HTML-Dateien, die ich dann per FTP
aufden Server meines Providers hochlade.

Wenn ich ein neues Produkt hinzufüge, gebe ich die entsprechenden Daten
in meine Excel-Tabelle ein und "erzeuge" dann per VBA-Macro
die entsprechende HTML-Datei.
Diese lade ich dann zusammen mit den dazugehörigen Bildern hoch.
Und in die entsprechende Produktliste setze ich den Artikel
dann per Hand ein.

Wenn ich ein Produkt bei mir rauswerfe, mache ich das ganze umgekehrt.

Bei einer Aktualisierung z.B. des Preises in der DB die Aktualisierung der dazugehörigen Produktseite zu vergessen (da diese, wie von dir vorgesehen, getrennt von den Infos in der DB erzeugt wurde), ist eine Inkonsistenz.

Ja, aber damit würde ich leben können.Ich werde so etwas nicht vergessen, wenn ich an einem Produkt etwas ändere.

Gruß
Ingo

[Auge]

Hallo

Du kannst die Seiten für die Produkte natürlich offline erstellen. ats Weg, die Seite aus den, in der DB hinterlegten, Infos einmalig zu erstellen, so dass sie hernach statisch vorliegt, hat den Vorteil, dass bei einer Änderung einer oder mehrerer Eigenschaften in der DB die statische Seite wiederum nur _einmal_ überschrieben werden muss, damit die neuen Eigenschaften auch in die statischen Seite übernommen werden. Das kannst du alles mit einem Skript erledigen.

Hmmm, langsam komme ich ganz durcheinander.
Bisher pflege ich meine Produktdaten alle in einer Excel-Tabelle.
Und daraus erzeuge ich dann mit VBA per Makro sozusagen
"auf Knopfdruck" die jeweilogen HTML-Dateien, die ich dann per FTP
aufden Server meines Providers hochlade.

[...]

Wenn ich ein Produkt bei mir rauswerfe, mache ich das ganze umgekehrt.

Du machst das also schon automatisiert. Dann wäre es doch auch möglich, den Datenbankteil auf diese Art und Weise zu erstellen. Mit dem Export der notwendigen Spalten in eine csv-Datei (z.B. Komma-, Semikolon-, oder Pipe-getrennt) hältst du auch die DB aktuell.

Das ist eine Textdatei, in der die Werte eines Datensatzes in einer Zeile stehen und durch ein definiertes Zeichen die Unterteilung in Spalten vorgenommen wird.

Beispiel (Schema: ID, Name, Preis; Trennzeichen: "|"):
1|Wilfried|24.99
2|Bernhardiner|12.49

Wenn du das Schema kennst, kannst du dein Skript zum Auslesen der DB, an die Gegebenheiten angepasst, erstellen.

• DB-Datei mit file einlesen
• mit explode die einzelnen Zeilen in einer Schleife auftrennen
• den/die benötigten Datensatz/Datensätze ermitteln und mit ihnen arbeiten

Bei einer Aktualisierung z.B. des Preises in der DB die Aktualisierung der dazugehörigen Produktseite zu vergessen (da diese, wie von dir vorgesehen, getrennt von den Infos in der DB erzeugt wurde), ist eine Inkonsistenz.

... Ich werde so etwas nicht vergessen, wenn ich an einem Produkt etwas ändere.

Dein Wort in Gottes Gehörgang. ;-)

Tschö, Auge

[Ingo Siemon]

Tach Auge

Erstmal möchte ich Dir sehr für Dein ausführliches Posting danken.

Um einen Warenkorb zu befüllen, musst du nicht nur die Daten auf dem Server (zwischen)speichern, du musst sie auch dem einzelnen Besucher zuordnen können.
Genau da kommt die Session ins Spiel. Sie ermöglicht, dass sich der Benutzer durch eine ID wiedererkennen lässt.

OK, das habe ich erstmal soweit verstanden.

Die ID wird entweder als Cookie auf dem Rechner des Benutzers gespeichert ...

Funktioniert das denn auch, wenn der User in seinem Browser das Speichern
von cookies deaktiviert hat?
Ich habe mal irgendwi aufgeschnappt, dass dann solche
PHP-Session-Cookies trotzdem funktionieren sollen.
Stimmt das?

oder sie wird als Parameter an jeden Link angehängt und so bei jedem Aufruf an den Server übermittelt.

OK, verstehe.

Wie du mit diesem System die Informationen zu Preisen etc. lagern willst, ohne auf eine, wie auch immer geartete, Datenbank zurückzugreifen, ist mir allerdings schleierhaft. Du wirst ja nicht bei jedem Produkt im Warenkorblink eine ewig lange Kette von Parametern nach folgendem Schema übermitteln wollen.

http://example.com/shop/produkt_2455.html?produkt=2455&preis=25&farbe=schwarz

Bei meine Produkten wären es im Grunde nur 3 Parameter:
1. Eine Bestellnummer (würde ja sozusagen einer ID entsprechen)
2. Ein Produktname
3. Preis

Die Nachkommastellen beim Preis habe ich jetzt mal weggelassen, weil ich aus dem Stehgreif nicht weiß, wie der Punkt zu maskieren wäre. :-)

Meine Preis sind alle ohne Nachkommastellen und sollen es auch bleiben.
Ich hasse dieses 99 cent Zeugs, aber das ist eine andere Geschichte :-)

Mit diesem System wären Fälschungen Tür und Tor geöffnet. Jeder könnte den Preis nach eigenem Gusto festlegen. Damit das nicht passiert, müssen solche Informationen auf dem Server vorgehalten werden und nur für die verarbeitenden Skripte zugänglich sein.

Du meinst, es könnte jemand also dann sozusagen einfach selber die
entsprechende URL mit seinen eignen Parametern in den Browser
schreiben und somit den Warenkorb dann mit falsch auggepreisetn
Produkten füllen ... richtig?

Du wirst also nicht um eine Datenbank herumkommen, denn im Warenkorb musst du rechnen können. Ein Kunde könnte mehrere Stück eines Produktes oder verschiedene Produkte mit einem mal kaufen wollen/sollen. Also brauchst du die jeweiligen Preise zur Berechnung des Gesamtpreises.

Ich habe das bisher so gemacht.
Wenn ein Kunde ein Produkt z.B. 2 x kaufen will, muss er es einfach
2x in den Warenkorb schmeissen. Es gibt bei mir also bisher
keine Anzahl eines Produktes im Warenmkorb.
Bei meinen Produkten, die ja recht teuer sind, kommt es auch
sehr selten vor, dass Kunden einen Artikel mehrmals bestellen.
Aber klar, schöner wäre es natürlich schon, wenn der Kunde
die gewünschte Anzahl im Warenkob noch anpassen könnte.

Und ie Zusammenrechnerrei des Gesamtbetrages läuft bei mir
zur Zeit noch mit Javascript clienet-seitig.
Aber das will ich ja eben in Zukunft nicht mehr machen.

Legt der Kunde ein Produkt in den Warenkorb, kann mit der ID des Produkts, eventuellen Eigenschaften, der zu bestellenden Menge, die in der Session gespeichert werden, und dem Einzelpreis aus der DB immer der Gesamtpreis der Bestellung (zzgl. Versandkosten) errechnet werden.

OK, wenn z.B. nun die Session-ID nicht per Parameter weitergegeben wird,
sondern eben in einem Session-Cookie beim User gespeichert wird,
würde man doch da auch die zur Bestellung gehörenden Produtdaten
(Bestellnummer, Produktname, Preis) mit speichern, oder nicht?
So wären sie nicht in der URL lesbar und auch nicht so leicht zu fälschen.

Die Daten (der Datensatz) der Bestellung (Produkte, Mengen, persönliche Daten des Bestellers) landen wohl per Email bei dir.

Ja, genau, die werden vom Script dann letztendlich per E-Mail zu mir geschickt.

Aber auch hier ist eine Speicherung in einer DB (mehr als nur) sinnvoll. Einerseits kann die Email auf sich warten lassen, du hast also bei Zugriff auf die Daten in der DB eine Rückfallebene ...

Du meinst also eine Sicherung der Bestellung, falls einer der
E-Mails mal nicht bei mir ankommt?

andererseits kannst du dem Kunden, bei entsprechender Pflege der Datenbestände, einen Mehrwert z.B. in Form eines Auslieferungsstatus (Bestellung eigegangen, Lieferung zusammengestellt, verschickt) geben.

Das mache ich bisher sozusagen von Hand.
Und das kann auch in Zukunft von mir aus ruhig so bleiben.

Ich habe für die meisten Dinge, die so anfallen vom Erstellen der Artikeldaten
bis zum Paketversand an den Kunden schon gute Lösungen parat.
Das muss also nicht alles von der Shop-Software erledigt werden.

Im Grunde muss diese PHP-Geschichte nur den Warenkob befüllen
und dann am Ende die Bestellung an mich per E-Mail senden können.

Gruß
Ingo

[Længlich]

Ciao!

Legt der Kunde ein Produkt in den Warenkorb, kann mit der ID des Produkts, eventuellen Eigenschaften, der zu bestellenden Menge, die in der Session gespeichert werden, und dem Einzelpreis aus der DB immer der Gesamtpreis der Bestellung (zzgl. Versandkosten) errechnet werden.

OK, wenn z.B. nun die Session-ID nicht per Parameter weitergegeben wird,
sondern eben in einem Session-Cookie beim User gespeichert wird,
würde man doch da auch die zur Bestellung gehörenden Produtdaten
(Bestellnummer, Produktname, Preis) mit speichern, oder nicht?
So wären sie nicht in der URL lesbar und auch nicht so leicht zu fälschen.

Wenn Du sie beim Client ablagerst, sind sie immer mehr oder weniger leicht zu fälschen. Das ist aber auch gar nicht notwendig - der Client muß ja nur dem Server sagen können, welches Produkt er haben will, und das ergibt sich ganz einfach daraus, in welcher HTML-Datei der User auf "In den Warenkorb" geklickt hat.
Den Rest macht der Server dann alleine: Er schaut in seiner Datenbank, ob das Produkt existiert, wie es heißt, was es kostet usw., berechnet daraus alles, was Du wissen mußt, und schickt dem Client wieder eine HTML-Seite, nämlich die mit der Übersicht, was alles im Warenkorb drin ist.
Im Cookie muß (sollte) also nix weiter stehen als das, was der Server braucht, um den Client wiederzuerkennen, also die Session-ID.

Ich schließe mich übrigens at und Auge an, daß Du eine Datenbank verwenden solltest. Das bedeutet zwar beim anfänglichen Programmieren einen geringfügigen Mehraufwand, erspart Dir später aber einiges. Eine Datenbankanbindung mit PHP ist auch nicht soo schwer... ;-) (Bei mir mit MySQL fünf Zeilen für die Verbindung plus die Anfragen.)

Viele Grüße vom Længlich

[Ingo Siemon]

Lieber Længlich

Wenn Du sie beim Client ablagerst, sind sie immer mehr oder weniger leicht zu fälschen.

OK, klar, das leuchtet ein.

Das ist aber auch gar nicht notwendig - der Client muß ja nur dem Server sagen können, welches Produkt er haben will, und das ergibt sich ganz einfach daraus, in welcher HTML-Datei der User auf "In den Warenkorb" geklickt hat.

Ok, hab ich auch verstanden.

Den Rest macht der Server dann alleine: Er schaut in seiner Datenbank, ob das Produkt existiert, wie es heißt, was es kostet usw., berechnet daraus alles, was Du wissen mußt, und schickt dem Client wieder eine HTML-Seite, nämlich die mit der Übersicht, was alles im Warenkorb drin ist.
Im Cookie muß (sollte) also nix weiter stehen als das, was der Server braucht, um den Client wiederzuerkennen, also die Session-ID.

Das setzt aber doch dann wieder vorraus, das auf dem Server eben
eine Produktdatenbank existiert ... oder?

Ich schließe mich übrigens at und Auge an, daß Du eine Datenbank verwenden solltest. Das bedeutet zwar beim anfänglichen Programmieren einen geringfügigen Mehraufwand, erspart Dir später aber einiges. Eine Datenbankanbindung mit PHP ist auch nicht soo schwer... ;-) (Bei mir mit MySQL fünf Zeilen für die Verbindung plus die Anfragen.)

Ok, ich werde mir das natürlich überlegen.

Mich interessiert aber auch, ob das überhaupt ohne eine Produktdatenbank
auf dem Server möglich ist.

Also, dass der User auf den "in den Warenkob"-Link klickt.
Und mit diesem Link werden dann die entsprechenden Produktdaten
an der Server übermittelt.
Dieser notiert sich diese dann sozusagen irgendwie in einer Textdatei oder so.
Und wenn der User dann auf Warenkob klickt, wird eben eine Seite ausgegeben,
wo letztendlich der Inhalt dieser Textdatei
wieder ausgegeben wird.

Ist denn dieses herangehen an die Sache nicht auch möglich.
Oder mache ich da immer noch einen Denkfehler?

Gruß
Ingo

[at]

Hallo.

Ist denn dieses herangehen an die Sache nicht auch möglich.
Oder mache ich da immer noch einen Denkfehler?

Sogar noch immer den gleichen: Wenn der Preis nicht auf dem Server liegt, sondern vom Client an den Server gesendet wird, besteht die Möglichkeit, den Preis zu manipulieren. Der Server müsste also zumindest die statischen HTML-Dateien auslesen, um den Original-Preis zu kennen.
Und genau das meinte ich damit, dich an geeigneter Stele mit den technischen Grundlagen der Programmierung von Webshops zu informieren, bevor du Techniken verwendest, deren Tragweite du nicht im Ansatz überblickst.
MfG, at

[Ingo Siemon]

Hallo

Sogar noch immer den gleichen: Wenn der Preis nicht auf dem Server liegt, sondern vom Client an den Server gesendet wird, besteht die Möglichkeit, den Preis zu manipulieren.

OK, nun habe ich das endlich begriffen.
Sorry für mein Brett vorm Kopf :)

Der Server müsste also zumindest die statischen HTML-Dateien auslesen, um den Original-Preis zu kennen.

Ja, aber so könnte man das doch genau lösen.
Dieser Ansatz ist doch dann im Grunde "fälschungssicher".

Und genau das meinte ich damit, dich an geeigneter Stele mit den technischen Grundlagen der Programmierung von Webshops zu informieren, bevor du Techniken verwendest, deren Tragweite du nicht im Ansatz überblickst.

Genau, das war ja auch irgendwie der Grund meines Postings.
Ich beschäftige mich hallt zum ersten mal damit,
solche Dinge serverseitig zu machen.
Und ich möchte mich da schön langsam ransasten und das auch
begreifen.

Keine Sorge übrigens, ich werde nicht einfach loslegen,
es eilt im Grunde nicht.

Am liebsten würde ich mich mal mit einem PHP-Profi
ein paar Stunden zusammensetzen und mit dem das mal alls durchtalken.
Das ginge dann natürlich auch etwas einfacher, als über so ein Forum.

ANdererseits kann man hier bei Euch natürlich auch verschiedene
Meinungen bzw. Formulierungen dazu bekommen,
was ja auch ein echter Vorteil ist.

Nun denn, ich würde mich jedenfalls freuen, wenn Ihr mich weiter
begleitet auf meinen Weg zum Durchblick :))

Gruß
Ingo

[Længlich]

Merhaba!

Der Server müsste also zumindest die statischen HTML-Dateien auslesen, um den Original-Preis zu kennen.

Ja, aber so könnte man das doch genau lösen.
Dieser Ansatz ist doch dann im Grunde "fälschungssicher".

Theoretisch ginge das. Es wäre aber mehr Arbeit als die Datenbank, und zwar sowohl für Dich beim Programmieren als auch für den Server beim Ausführen. (Das ist genau das, was ich meinte, als ich schrieb, daß Dir die Datenbank später einiges an Aufwand ersparen wird.)

Und genau das meinte ich damit, dich an geeigneter Stele mit den technischen Grundlagen der Programmierung von Webshops zu informieren, bevor du Techniken verwendest, deren Tragweite du nicht im Ansatz überblickst.

Und ich möchte mich da schön langsam ransasten und das auch
begreifen.

Keine Sorge übrigens, ich werde nicht einfach loslegen,
es eilt im Grunde nicht.

Sehr gute Herangehensweise! :-) Es ist auf jeden Fall besser, sich etwas Zeit zu nehmen (auch wenn die Kunden dann ein wenig länger warten müssen) als etwas Halbdurchdachtes zusammenzufrickeln, dessen Probleme dann nach und nach sichtbar werden.

Viele Grüße vom Længlich

[Ingo Siemon]

Lieber Længlich

Theoretisch ginge das. Es wäre aber mehr Arbeit als die Datenbank, und zwar sowohl für Dich beim Programmieren als auch für den Server beim Ausführen. (Das ist genau das, was ich meinte, als ich schrieb, daß Dir die Datenbank später einiges an Aufwand ersparen wird.)

OK, dann werde ich mir wohl doch nochmal ernsthaft Gedanken darüber machen,
ob ich nicht doch lieber den klassischen Weg über eine
Datenbankanbindung mit MySQL gehe.

Alles andere scheint ja dann wohl doch nicht so ganz das Wahre zu sein.

Sehr gute Herangehensweise! :-)

Yep.

Gruß
Ingo

[Længlich]

Vanakkam!

Mich interessiert aber auch, ob das überhaupt ohne eine Produktdatenbank
auf dem Server möglich ist.

Also, dass der User auf den "in den Warenkob"-Link klickt.
Und mit diesem Link werden dann die entsprechenden Produktdaten
an der Server übermittelt.
Dieser notiert sich diese dann sozusagen irgendwie in einer Textdatei oder so.
Und wenn der User dann auf Warenkob klickt, wird eben eine Seite ausgegeben,
wo letztendlich der Inhalt dieser Textdatei
wieder ausgegeben wird.

Ist denn dieses herangehen an die Sache nicht auch möglich.
Oder mache ich da immer noch einen Denkfehler?

Naja, die eindeutige Zuordnung Bestellnummer <--> Name <--> Preis muß schon irgendwie gegeben sein. Da man diese drei Dinge bestimmt nicht mathematisch voneinander herleiten kann (bzw. das viel zu kompliziert wäre, wenn man es könnte), müssen sie irgendwo in Form einer Tabelle gespeichert sein.
Und dieses "irgendwo" ist per definitionem eine Datenbank:
"Eine Datenbank (DB) ist eine strukturierte und logisch organisierte Sammlung (formatierter) Daten, die dauerhaft und weitgehend redundanzfrei gespeichert wird." (aus dem Script von Prof. Dr. Georg Winterstein, dessen Klausur letzte Woche ich hoffentlich bestanden habe ;-) )

Jetzt kannst Du natürlich entweder ein gegebenes Datenbanksystem verwenden, z.B. MySQL, oder eines selbst machen, indem Du die Daten z.B. in eine .txt-Datei schreibst. Wenn Du ein eigenes kreierst, mußt Du aber alles selbst machen, was sonst schon erledigt ist: Funktionen für Zugriffe, Änderungen, Einfügen neuer Daten, Löschen etc., die ganzen Sicherheitsüberlegungen (wer darf zugreifen?, woran erkennt man denjenigen?, wie sichert man Datenkonsistenz im Falle einer fehlgeschlagenen Anfrage? usw.). Das wäre ein Riesenaufwand, und das Ergebnis wäre bestimmt auch nicht besser als die bekannten verfügbaren Systeme.

Außerdem habe ich den Eindruck, daß hier ein bißchen aneinander vorbei geschrieben wird: Auge, at und ich meinen eine "statische" Datenbank, in der die Produkte drinstehen und die sich bei Bestellungen nicht verändert. (Sie wird nur verändert, wenn Du ein Produkt mehr oder weniger anbietest, den Preis änderst o.ä.)
Deine oben erwähnte Textdatei würde aber nur diejenigen Produkte beïnhalten, die gerade im Warenkorb sind - d.h., Du bräuchtest für jeden User (= für jede Session) eine eigene Textdatei. Wozu? Die Zuordnung der Preise usw. zu den einzelnen Bestellnummern steht sowieso in der "statischen" Datenbank, und die Zuordnung Kunde <--> bestellte Produkte ist durch die Session gegeben (vorausgesetzt, die bestellten Produkte sind in Session-Variablen gespeichert, natürlich).
Wenn der Kunde dann auf "Bestellen" klickt, liest Dein Script diese Session-Variablen aus und mailt Dir ihren Inhalt. Zusätzlich kann es die Bestellung in eine Tabelle in der Datenbank speichern, wenn das gewünscht ist (es könnte juristisch oder für eventuelle Fehlersuche sinnvoll sein, die alten Bestellungen noch irgendwo gespeichert zu haben).

Viele Grüße vom Længlich

[Ingo Siemon]

Lieber Længlich

Naja, die eindeutige Zuordnung Bestellnummer <--> Name <--> Preis muß schon irgendwie gegeben sein.

Ich dachte bisher immer daran, diese Daten beim Klick
auf den "in den Warenkob"-Link mit an das Script zu übergeben.
OK, zum Thema Fälschungssicherheit habt Ihr mir das hier ja
schon soweit klargemacht.
Darum ist dieses Vorgehen ja wohl eher nicht so gut.

Jetzt kannst Du natürlich entweder ein gegebenes Datenbanksystem verwenden, z.B. MySQL, oder eines selbst machen ...

Ne, wenn Datenbank, dann werde ich natürlich MySQL nehmen.
Da hat man sicher die besten Möglichkeiten, Hilfe und Infos
zu bekommen.
Und es gibt ja auch ne Menge Bücher dazu.
Könnt Ihr da vielleicht ein gute Buch empfehlen?
Was ich so drauf habe (bzw. was eben nicht) wisst Ihr ja sicher inzwischen.
Es müsste also ein Buch sein, was für Anfänger geeignet ist.
Ein kleines bisschen in PHP habe ich ja schon mal reingschnuppert
mit meinen VHS-Anfänger-Kurs.
Und es sollte auch spass machen, das zu lesen bzw. damit zu lernen,
nicht dass ich noch die Motivation verliere :-)

Außerdem habe ich den Eindruck, daß hier ein bißchen aneinander vorbei geschrieben wird: Auge, at und ich meinen eine "statische" Datenbank, in der die Produkte drinstehen und die sich bei Bestellungen nicht verändert. (Sie wird nur verändert, wenn Du ein Produkt mehr oder weniger anbietest, den Preis änderst o.ä.)

Doch, doch das habe ich schon gescheckt :)

Deine oben erwähnte Textdatei würde aber nur diejenigen Produkte beïnhalten, die gerade im Warenkorb sind - d.h., Du bräuchtest für jeden User (= für jede Session) eine eigene Textdatei.

Ja, genau das hatte ich auch so gemeint.

Gruß
Ingo

[ShiNtoKu]

Hallo,

Wenn du bisher kaum bis garnicht mit PHP und MySQL gearbeitet hast kann ich dir folgendes empfehlen:

PHP und MySQL, Kevin Yank, dpunkt.verlag

Wenn die Grundlagen vorhanden sind und es gerade an spezielleren Sachen wie z.B. Sessions scheitert bietet sich dies an:

PHP 5 für Fortgeschrittene, Harry Fuecks, dpunkt.verlag

Wäre auf jedenfall sinnvoll, wenn du dich in PHP einarbeiten willst, dies mit PHP 5 unter dem Aspekt der objektorientierten Programmierung zu tun.

Viele Grüße
Patrick

[Ingo Siemon]

Lieber Patrick

Wenn du bisher kaum bis garnicht mit PHP und MySQL gearbeitet hast kann ich dir folgendes empfehlen:
PHP und MySQL, Kevin Yank, dpunkt.verlag

OK, ich habe mir das Buch soeben bei amazon.de bestellt.
Drück mir die Daumen, dass ich damit klarkomme :-)

Gruß
Ingo

[Længlich]

Teanastellen!

[...]
Es müsste also ein Buch sein, was für Anfänger geeignet ist.
Ein kleines bisschen in PHP habe ich ja schon mal reingschnuppert
mit meinen VHS-Anfänger-Kurs.
Und es sollte auch spass machen, das zu lesen bzw. damit zu lernen,
nicht dass ich noch die Motivation verliere :-)

Für die Datenbankanfragen mit SQL würde ich dieses Tutorial empfehlen, wo ich selbst immer nachschaue: http://www.w3schools.com/sql/default.asp
Ist zwar nicht wirklich ein Buch, aber Du kannst es ja ausdrucken. ;-)
Es ist auch nicht vollständig, aber die schwierigeren Sachen, die da nicht erwähnt werden, wirst Du wahrscheinlich auch nicht brauchen.

[...]

Doch, doch das habe ich schon gescheckt :)

[...]

Ja, genau das hatte ich auch so gemeint.

OK, dann ist ja doch alles geklärt und es fehlt nur noch ein bißchen Programmierung... ;-)

Viele Grüße vom Længlich

[Ingo Siemon]

Lieber Længlich

Für die Datenbankanfragen mit SQL würde ich dieses Tutorial empfehlen, wo ich selbst immer nachschaue: http://www.w3schools.com/sql/default.asp

Ich hatte vergessen zu schreiben, das es unbedibgt in deutscher
Sprache sein sollte ... sorry.

OK, dann ist ja doch alles geklärt und es fehlt nur noch ein bißchen Programmierung... ;-)

Ja, wem sagst Du das :-))
Ich habe mir nun mal dieses Buch bestellt:
http://www.amazon.de/exec/obidos/ASIN/3898643166/qid=1135706711/sr=1-13/ref=sr_1_10_13/303-5713869-4179436

Gruß
Ingo