Hallo Zusammen, ich versuche gerade folgende Anforderung umzusetzen: Wenn jemand über einen speziellen Link auf ein Produkt kommt, wird ein zufälliger Rabat (5-30%) für dieses Produkt generiert. Dieser Rabatt soll dann in der Session gespeichert werden und diesem einen Kunden für dieses eine Produkt zur Verfügung stehen. Ohne Cache funktioniert alles wunderbar, ist der Cache aktiv nicht 
Beispiel: Kunde A geht auf das Produkt mein-shop.tld/product-a wodurch die Seite im Cache gespeichert wird. Kunde B geht auf das selbe Produkt, aber über mein-shop.tld/product-a?preis=zufall und kriegt einen Rabatt von 20%. Mein Plugin verhindert das die Seite im Cache gespeichert wird, vermerkt den Rabatt aber in der Session. Nachdem Kunde B etwas im Shop unterwegs war, möchte er das Produkt nun kaufen. Er navigiert also im Shop zu mein-shop.tld/product-a und erhält die Seite aus dem Cache, die für Kunde A generiert wurde, ohne den Rabatt. Wenn es nur um die Detailseite gehen würde, könnte man dort einen {action}-Tag einfügen. Aber in allen Slider, im Listing und in den Einkaufswelten soll ebenfalls der reduzierte Preis verwendet werden. Kann ich den Cache irgendwie nur für Kunde B deaktivieren?
Hi, ist nicht ganz einfach, weil du ja anscheinend auf allen Seiten die Preise nutzerabhängig ändern möchtest aber gleichzeitig den HTTP-Cache benutzen willst. Erfahrungsgemäß geht sowas am besten, wenn du es schaffst, das in JavaScript auszulagern. Das ist unabhängig vom Cache und könnte bspw. die Preise abhängig von dem Prozentrabatt in einem Cookie modifizieren. Mit einem sinnvollen Hash im Cookie kann man darüber hinaus Modifikationen durch den Besucher ausschließen. Wen es unbedingt sein muss, kann man den Cache auch feingranularer aufbauen - etwa pro Rabatt, den man bekommen kann. Möglich wird das durch folgenden Eintrag in der config.php: 'httpcache' =\> ['cache\_cookies' =\> [ 'my\_plugin' =\> 'test'] ] Dadurch wird Shopware in Zukunft beim Aufbau des Cache-Keys (das ist quasi die Sammlung aller eindeutigen Identifier einer Seite, e.g. ShopID, Währung und URL der Seite) auch den Inhalt des Cookies “test” berücksichtigen. Sprich: Es gibt dann separate Caches für den Rabatt “10%”, “5%” und was auch immer im Cookie steht. Die Cache-Hit-Rate sinkt dadurch. Eine andere (und vermutlich einfachere Möglichkeit) ist das Setzen des Price-Tags (https://developers.shopware.com/blog/20 … cache-tags). Dann kommen bestimmte Controller, die du im Backend konfigurieren kannst, live, wenn das “price”-Tag gesetzt ist. Wenn ich so drüber nachdenke, vll. genau das, was du brauchst. Ich lasse das andere aber trotzdem mal stehen 
Daniel
Hallo Daniel, die Price-Tags klingen gut, wie genau setze ich diese? $response-\>setCookie('nocache', 'price'); ? Javascript klingt auch gut. Der Schutz per Hash sollte ja gar nicht notwendig sein, da ich im Checkout nochmal alles überprüfen kann, oder? Performance mäßig sollte das auch besser sein, da die Seite weiterhin aus dem Cache kommen kann und das Javascript per ESI passend ausgeliefert werden kann oder unterschätze ich hier den zusätzlichen “Widget-Request”? Gruß Dirk
Hi, am besten du nutzt die fertige Methode \Shopware_Plugins_Core_HttpCache_Bootstrap::setNoCacheTag über Shopware()->Plugins()->Core()->HttpCache() solltest du Zugriff darauf bekommen. Bei der JS-Variante gibt es keine ESI-Tags, da machst du einfach einen Ajax-Call auf einen eigenen Controller (ob der in Frontend oder Widgets liegt ist egal) - der würde im Standard nicht gecacht werden. Vom Prinzip her ist alles, was am Cache vorbei geht natürlich etwas mehr Last auf dem Server - aber immernoch besser, als den Cache komplett zu deaktivieren. Validierung ist insofern tatsächlich nicht nötig, als dass im WK alle Preise neu berechnet werden. Das hängt aber natürlich letztlich davon ab, wie du deinen Rabatt in SW einbringst. Wenn das einfach ein Warenkorbrabatt ist, der über den Cookie getriggerd wird, wäre etwas Validierung schon nötig, da SW ja nicht weiß, ob dein Rabatt noch gültig ist, oder nicht. Versuche mal die Price-Tag-Geschichte, ich denke, die sollte passen. Daniel