ESI-Tag auf "externe" URL -oder- lightweight Shopware-Controller

Hi,

über einen ESI-Tag ist das mMn nicht so ohne Weiteres möglich, da gibt es ja drei verschiedene Szenarien, die berücksichtigt werden müssen:

  • Kein Cache: Shopware löst Action-Tags über einen internen Dispatch auf - keine Instanz löst ESI-Tags auf
  • Symfony-Cache: ESI-Tags werden über eine Abkürzung im Kernel ebenfalls über den internen Dispatch-Loop aufgelöst
  • Varnish: ESI-Tags werden extern an den Shopware-Kernel übergeben und wie eigene Requests gehandhabt

Hinzu kommt das Problem, dass ESI-Tags ja in der Regel auch synchron aufgelöst werden, d.h. die Seite wird dadurch ja per se nicht schneller. Meines Wissens ist nur Varnish in der Pro-Version in der Lage, ESI-Tags asynchron aufzulösen. Selbst wenn du es also über ESI-Tags implementieren könntest, hättest du dadurch in den meisten Fällen keinen Geschwindigkeitsvorteil. Das habe ich hier mal zusammengefasst: On action tags vgl. dazu auch diese Animation:

Wenn es dir nur um generelle Adblock-Regeln geht, wäre es ja eigentlich schon zielführend, wenn du einfach einen Shopware-Controller mit unverfänglichem Namen implementierst und darin dann serverseitig den Tracking-Service aufrufst. Nutzer könnten dann zwar weiterhin individuell diesen Ajax-Call blocken - aber es ist ja relativ unwahrscheinlich, dass diese konkrete URL deines Shops Einzug in eine Adblock-Liste erhält, oder? Alternativ könntest du dich auch an einen Standard-Ajax-Call von SW hängen, „refreshStatistics“ beispielsweise.

„lightweight Controller“ gibt es in der Form nicht - der „widget“ Namespace hat in der Hinsicht ein paar Besonderheiten und war mal so angedacht - aber unterm Strich ist der Stack dort nicht nennenswert kleiner, als der Stack bei den anderen Controller-Namespaces. 

Eine ganz generelle Lösung ohne Ajax und Iframe und ohne Manipulationen an der shopware.php fällt mir da also so auf die Schnelle nicht ein.

Besten Gruß

Daniel

1 „Gefällt mir“