Ważne jest, aby zrozumieć, dlaczego nie chcesz buforować bloku. Jeśli ma to na celu pokazanie niektórych informacji specyficznych dla sesji, powinieneś przyjrzeć się temu
Jedną niezalecaną opcją może być również niestandardowy kontroler, który zwraca niektóre dane przez wywołanie ajax (z metodą POST, aby nie był buforowany).
(!) cacheable = „false” nie może być użyte. Oto, dlaczego nie:
Blok z cacheable = "false" spowoduje, że cała strona nie będzie buforowana. Nie służy do dziurkowania w pamięci podręcznej. Mówi to również następująca strona ( aby utworzyć stronę nieuleczalną , zaznacz dowolny blok na tej stronie jako nieuleczalny w układzie, używając cacheable = "false" ):
Działa to tak, że moduły Varnish / Fastly będą wysyłane, ponieważ ta wartość atrybutu zawsze nie nadaje się do buforowania nagłówków.
Kiedy włączymy cachable = "false" i podczas używania Varnish / Fastly, wysyłane są następujące nagłówki:
X-Magento-Cache-Debug:MISS
X-Magento-Cache-Control:max-age=0, must-revalidate, no-cache, no-store
Age: 0
W tym celu można debugować kod buforowania stron Magento
vendor/magento/module-page-cache/Model/Layout/LayoutPlugin.php::afterGenerateXml
vendor/magento/module-page-cache/Model/Layout/LayoutPlugin.php::afterGetOutput
gdzie pierwszy powinien wysłać publiczną kontrolę pamięci podręcznej z TTL, a drugi - X-Magento-Tags dla Varnish / Fastly.
Oba używają sprawdzania isCacheable (), gdzie zawsze zwraca FAŁSZ z powodu następującego sprawdzenia (sprawdź, czy w bieżącym układzie są jakieś atrybuty: cacheable = "false"):
$cacheableXml = !(bool)count($this->getXml()->xpath('//' . Element::TYPE_BLOCK . '[@cacheable="false"]'));
Kiedy usuwamy cacheable = "false", wtedy zaczynamy sprawdzać isCacheable () jako PRAWDA, a także poprawnie otrzymywać nagłówki na stronach start- / category- / product.
X-Magento-Cache-Control:max-age=86400, public, s-maxage=86400
X-Magento-Cache-Debug:HIT
X-Magento-Cache-Hits:1
Age:32