für unseren Kunden nutzen wir einen eigens programmierten Preis-Importer. Da die Preise direkt per “plain” SQL aktualisiert werden und nicht über Doctrine, würde ich den Cache gerne über
Wir lassen den Preisimporter per Cronjob laufen und scheinbar funktioniert das Cache invalidieren nicht über CLI kann das sein?
Ich lande im HttpCache Plugin in der Methode invalidateWithBANRequest() wobei als url die Base-URL vom Shop genommen wird und die cacheId dem Artikel entspricht, der einen neuen Preis erhalten hat (z.B. a14023).
Darauf wird ja ein BAN-Request losgeschickt, der Status-Code des Response ist “200”, also alles in Butter.
Die Artikel-Detailseite kommt jedoch dennoch aus dem Cache. Wenn ich den Artikelpreis im Backend ändere, funktioniert das Invalidieren einwandfrei und die Detailseite wird neu gecached.
Hat hier jemand eine Idee, woran das liegt? Ist es über CLI irgendwie möglich, gezielt einzelne gecachte Seiten zu invalidieren?
Habe es jetzt so gelöst, dass ich einen neuen Frontend-Controller angelegt habe, in dem Shopware_Plugins_HttpCache_InvalidateCacheId Event gefeuert wird. Der Controller wird dann aus dem Cronjob heraus über CLI aufgerufen.
Ich bin da jetzt nicht so tief im Thema drin - du könntest aber auch einfach wie es bspw. über das Backend gemacht wird, einen BAN-Request per Konsole abschicken:
Ich bin da jetzt nicht so tief im Thema drin - du könntest aber auch einfach wie es bspw. über das Backend gemacht wird, einen BAN-Request per Konsole abschicken:
Das habe ich mal eben schnell getestet, dass funktioniert so auch.
Ah okay, danke für den Hinweis, das sieht auch vielversprechend aus. Werde das bestehende Skript jetzt nicht mehr anpassen, aber für die Zukunft gut zu wissen.
beim Invalidieren über die Konsole musst du bedenken, dass Shopware nicht Purge-Header von beliebigen Hosts akzeptiert - sonst könnte ja jeder einfach den Cache von deinem Shop leeren. Die erlaubten IPs kannst du in den „httpcache“ Optionen in deiner config.php mit dem Schlüssel „purge_allowed_ips“ eingeben - im Normalfall sind da nur diese Werte gesetzt:
array('127.0.0.1', '::1')
Keine Ahnung, ob es in deinem Fall daran liegt - aber das sollte man auf jeden Fall im Hinterkopf behalten, wenn man von fremden Rechnern aus den Cache leeren möchte.
War die Webserverumgebung damals nginx oder Apache/varnish? bei nginx gibt es eine Unzulänglichkeit hinsichtlich der Method, wofür ich einen Lösungsvorschlag gemacht habe. Sollte es sich tatsächlich um nginx handeln, liest sich die Beschreibung so, als würde in der Config auf die BAN Method ein „return 200;“ stehen - dass der Return Status richtig ist, aber dann nichts passiert.
Ich bin da jetzt nicht so tief im Thema drin - du könntest aber auch einfach wie es bspw. über das Backend gemacht wird, einen BAN-Request per Konsole abschicken:
Das habe ich mal eben schnell getestet, dass funktioniert so auch.
Hallo, ich habe das nun auch so gemacht und es funktioniert, jedoch dauert es schon eine Weile bei größeren Artikelmengen, ca. 1000 / min, kann man das auch irgendwie parallelisieren? Also anstatt