Codestelle hinzufügen zum Warenkorb

[webald]

Hi Leute,

helft bitte mal einem Blindfuchs. Ich will von einer externen Webseite eine Artikel in den Warenkorb legen. Da gibt es ja verschiedene GET Befehle (add_product, buy_now, add_a_quickie).

Aber wo zur Hölle wird das in die Session geschrieben und in der Tabelle session abgelegt?

Ich sehe es gerade einfach nicht.

Linkback: https://www.modified-shop.org/forum/index.php?topic=32908.0

[Matt]

includes/cart_actions.php

[webald]

DANKE!

Statt den vorhandenen Code nutzen zu können darf ich jetzt die ganze Warenkorb-Arie neu schreiben, da in diesem Zusammenhang fleissig mit redirects um sich geworfen wurde. API und redirect vertragen sich nicht so gut. Es wird Workflow und Datenlogik vermischt.

Wenn die Aufgabe heißt "Füll den Warenkorb per Code", dann geht das meiner Meinung nach derzeit nicht.
Aktuell:
Artikel in Warenkorb -> Artikel ist in die Session-Variable geschrieben, aber noch nicht gespeichert -> Funktion xtc_redirect -> und erst jetzt erfolgt ein session_write_close.

Das session_write_close müßte vor dem redirect erfolgen und für eine API müßte man auf den redirect beim Hinzufügen in den Warenkorb auf redirects verzichten. In meinen Augen werden da 2 Schritte (Warenkorb ändern und Userführung) in einem Schritt erledigt. Wenn andere der gleichen Meinung sind wäre das etwas für modified 3.0

[hendrik]

Jetzt setz dich erstmal und atme tief durch.

Schau in die Tabelle customers_basket. Die ist selbsterklärend. Dort hinein lässt du deine api Einträge setzen. Beim nächsten Login des betreffenden hat er die gesetzten Artikel im Warenkorb.

Gruß
Hen

[webald]

Hi Hendrik,

die Tabellen kann ich inzwischen fast auswendig.

Aber...
Customers_basket wird nur einmalig gelesen, weitere Änderungen am Warenkorb gehen nur in sessions. Siehe hierzu mein Ticket. Ronald sagt wontfix.

Außerdem geht customers_basket nur bei bestehenden Kunden. Ohne Login oder als Gast geht das nicht.

[hendrik]

Ach so.
Du hast irgendwie ein unabhängiges System was dem User Sachen in den Warenkorb legen können soll?!

Dann geh das Problem in umgekehrter Richtung an. Nicht das externe System manipuliert den WK sondern das Shopsystem prüft ob externe Änderunganforderungen vorliegen (Waren in WK, plus oder minus).

Das externe System schreibt die Anforderungen in einen unabhängigen Speicher, z.b. DB-Tabelle. Der Shop prüft bei jedem Seitenaufruf ob Anforderungen vorliegen und führt sie aus. Vergleichbar den POST-Requests und deren Auswertung in cart_actions. Die Codevorlagen findest du dort.

Anstatt IF $_POST['artikeldaten'] und dann Warenkorb ändern
Nun IF API-Anforderung dann einlesen und WK ändern

gruß
hen

[webald]

Das "unabhängige System" kennst Du. Ist der modified-Shop, der über eine Erweiterung im Admin bei einem anderen Shop einkaufen/runterladen soll.

[hendrik]

Ein Shop soll beim anderen einkaufen?!

Dann schreib doch ne Routine die eine Bestellung generiert. Du übergibst alle relvanten Daten (User ID, Warenliste, ggf. Lieferadressen und so, .. ). Das Programm generiert Bestellung in die Datenbank. So als sei die Bestellung klassisch im Fontend geschehen. Ist das dein Problem? Dann sollte die Fragestellung lauten. Wie programmiere ich eine Funktion die Bestellungen generiert.

Wenn das wieder falsch ist solltest du mal ausführlich dein Problem beschreiben.

gruß
hen

[webald]

Mal deutlicher:
der Hen hat einen Shop und bietet dort ein Modul zur Zollabwicklung an. Der Webald will das in seinem Shop haben. Damit das ganz einfach geht, hat ein schlauer Mensch eine Funktion im Shop vom Webald eingebaut, mit der er das Modul aus dem Backend seines Shops direkt beim Hen kaufen, runterladen und installieren kann. Der webald muss dafür aber die Artikel vom Hen im Backend sehen und dann eine Bestellung und Zahlung im Shop vom Hen machen können.

Es sollen also 2 komplett getrennt verwaltete Systeme Daten austauschen und ein gesamter Bestellprozess durchlaufen werden. Meine Vorstellung ist halt möglichst viele Standardfunktionen des Shops zu nutzen statt neu zu schreiben. Das erleichtert die Wartbarkeit, da es keine logischen Funktionen (Artikel in Warenkorb) doppelt (Shop und Erweiterung) gibt und nicht die Angriffsfläche vergrößert und aus Versehen eine Sicherheitslücke eingebaut wird.

Das gleiche Problem hätte man übrigns wenn man eine Handy-App für den Shop entwickeln würde.

Klar wo ich hin will?

[noRiddle (revilonetz)]

Baust du nicht sowieso die ganze Zeit an sowas ähnlichem ?
Der Hen stellt seine Produkte per z.B. WSDL zur Verfügung, darauf greift der Webald zu, wählt aus, wird (ähnlich wie bei PayPal und anderen Implementationen dieser Art) auf Hens Seite geleitet, schließt den Kaufprozess ab, wird zurückgeleitet in seinen Shop und hat nach Bestätigung durch Hens System einen Download-Link im Backend.

Was ich nicht verstehe ist wieso du einen Artikel von einem fremden System in den eigenen Warenkorb legen willst, wieso in den eigenen, wenn du's doch von wo anders kaufen möchtest ?

Gruß,
noRiddle

[webald]

..., darauf greift der Webald zu, wählt aus, wird ....

Genau diese wählt aus ist das Problem. Ich muss diesen Artikel ja beim Hen in den Warenkorb bekommen, damit dem Hen sein Shop Paypal sagen kann was das Teil kostet. Mit den Standardfunktionen (add_product, buy_now) ist es schwierig, da dort ein redirect eingebaut ist, der z. B. alle per POST übertragenen Werte ins Nirvana schickt und mit der Weiterleitung auf eine andere Seite (buy_now => product_info.php) eine undefinierte Rückgabe an den aufrufenden webald-Shop gibt.

Nebenbei geht buy_now nicht, weil das nur für Produkte ohne Attribute geht, Download-Artikel aber mindestens eines haben, nämlich downloads.

Falls keiner mehr der Meinung ist, dass man das mit den Standardfunktionen lösen kann, dann schreib ich halt das hinzufügen zum Warenkorb und speichern in der Session-Tabelle neu.

[noRiddle (revilonetz)]

Ich habe das mal für einen Kunden der wollte, daß seine Lageristen bei Anfragen dem Kunden einfach einen Link senden können und mittels diesem die Artikel in den Warenkorb kommen so in der /includes/cart_actions.php gelöst:

Code: PHP  [Auswählen]

    case 'custom_cart':
      if(isset($_GET['p_id'])) {
        //define $goto to be sure to be in shopping cart
        $goto = FILENAME_SHOPPING_CART;
        //remove potentially exsitent products in cart
        foreach($_SESSION['cart']->contents as $key => $val){
            $_SESSION['cart']->remove($key);
        }
       
        $prod_id_arr = explode('~', $_GET['p_id']);
        foreach($prod_id_arr as $val) {
            $prod_id_and_pcs = explode('-', $val);
            $prod_id = (int)$prod_id_and_pcs[0];
            $pcs = (int)$prod_id_and_pcs[1];
            $_SESSION['cart']->add_cart($prod_id, $pcs);
        }
      }
      xtc_redirect(xtc_href_link($goto, xtc_get_all_get_params(array ('action','p_id'))));
      break;

Der Warenkorb wird sicherheitshalber vorher geleert.

Ein solcher Link sähe dann so aus (können die Lageristen im Backend per einfacher input-Felder für Artikelnummern und Stückzahlen selbst generieren):

Code: [Auswählen]

DOMAIN?action=custom_cart&p_id=PRODUKT_ID1-2~PRODUKT_ID2-4~PRODUKT_ID3-6Attribute sind mit meiner einfachen Lösung nicht möglich.
Hinter dem Bindestrich steht die Stückzahl.

Was dich an dem Redirect stört verstehe ich nicht.
Man landet im Warenkorb des Empfänger-Shops mit den zu bestellenden Artikeln.
Diese sind in der $_SESSION['cart'] gepeichert und loggt man sich ein dann auch in der von hendrik zitierten DB-Tabelle customers_basket.
Da du die Bestellung ja dann in Hens Shop abschließt ist danach alles in den Tabellen orders, orders_products, usw. vorhanden.

Wenn es keine Attribute gibt (oder nicht für unter 18 freigeschaltete Artikel) wird übrigens auch bei case 'buy_now': oder case 'add_a_quickie': nicht auf die product_info umgeleitet.
Bei case 'cust_order': kann man nur einen Artikel in den Warenkorb legen und es wird auch nicht der WK geleert vor der Aktion.
Deshalb habe ich mir da selbst eine kurze Routine geschrieben.

Wenn jemand Artikel seines Shops auf diese Weise verkaufen möchte kann er ja außerdem DISPLAY_CART auf 'true' stellen (habe ich aber in meinem code abgefangen mittles der Definition von $goto).

Gruß,
noRiddle

*NACHTRAG*
Ich würde einfach den case 'cust_order': umschreiben. Der macht so wie er momentan ist ohnehin wenig Sinn. Damit wärst du immer noch nahe am Original-Code und hättest lediglich eine Verbesserung eingebaut.

[webald]

Was dich an dem Redirect stört verstehe ich nicht.
Man landet im Warenkorb des Empfänger-Shops mit den zu bestellenden Artikeln.

Spinn mal ein bißchen weiter: Ein Kunde hat eine WAWI/ERP und möchte direkt aus der Wawi in Deinem Shop bestellen. Alles was der Mitarbeiter angezeigt bekommen soll ist die WAWI. Wenn Du da einen Redirect im Shop einbaust kann das nur zu einem Fehler führen. Mein Ideal-Ergebnis in 2 Jahren Quasi Shopsteuerung ohne GUI.

Ich würde einfach den case 'cust_order': umschreiben.

Schau ich mir an.

[noRiddle (revilonetz)]

Ich sage nochmals: Die Redirects gehen doch eigtl. alle auf den Warenkorb selbst (siehe Definition von $goto). Wenn Attribute vorhanden sind oder Artikel mit FSK18 muß ja erstmal auf die product_info geleitet werden.
Wie immer du's auch machst:

• sind die Redirects ja steuerbar da man ja
  - DISPLAY_CART auf 'true' stellen kann
  - keine Attribute haben muß
  - keine FSK18 Artikel haben muß
• auch nach Redirect nach Auswahl beispielsweise einer Option eines Attributes der Artikel ja in den WK gelegt und eine Bestellung generiert wird.
  Danach sind alle wichtigen Daten in den Tabelen orders(_*) vorhanden und eine Rückmeldung an den Initiator-Shop ist problemlos machbar mit diesen Daten.

Was verstehe ich nicht an dem was dich stört ?

Gruß,
noRiddle

[webald]

Webservice und redirect schließen sich aus. Wie soll ein Service etwas zurückgeben, wenn ich statt JSON zu erzeugen im Warenkorb lande?

Und Download-Artikel (und um die geht es mir ja in erster Linie) haben halt Attribute, weil das Shop-Design eben so ist. Dass das mit den Attributen im Shop (etwa Bestandsführung) nicht optimal ist brauch ich Dir ja nicht zu sagen.

Ziel ist es ja auch, Produkte mit Attributen dem Warenkorb hinzuzufügen ohne über die product_info gehen zu müssen. Wenn ich Gastbestellungen ignorieren würde bzw. sicher sein könnte, dass der Kunde sich angemeldet hat, dann könnte man direkt in customers_basket schreiben.