Blokuj z Cachable = false nie renderowane na stronie widoku produktu


21

Używam magento2-1.0.0-beta4

Skopiowałem checkout.rootblok z app/code/Magento/Checkout/view/frontend/layout/checkout_index_index.xmlna stronę produktu.

Wszystko działa dobrze, dopóki nie włączę page_cache. Ten blok ma cacheable="false"w Layout XML.

Teraz, gdy otwieram stronę produktu, blok w ogóle się nie renderuje.

Jeśli poprawnie zrozumiałem pamięć podręczną strony, powinna ona ładować takie bloki za pomocą wywołania AJAX. Ale wydaje się, że nie zdarza się takie wywołanie AJAX, ponieważ mój punkt przerwania \Magento\PageCache\Controller\Block\Render::executenigdy nie został osiągnięty.

Podczas otwierania /checkout/lub /checkout/cart/wszystko działa. Ale wydaje się również, że nie doszło do wywołania AJAX. Zamiast tego cała strona nie jest renderowana z pamięci podręcznej, co ma sens dla koszyka.

Czy powinienem więc po prostu wykluczyć stronę widoku produktu z page_cache? Ale nie znalazłem sposobu, aby to zrobić?

Odpowiedzi:


15

Ten problem jest nadal powtarzalny w Magento 2.0.0 Stabilny.

W obsłudze wyjątków Magento 2 jest funkcja, która zapobiega renderowaniu uszkodzonych bloków, podczas gdy wszystkie inne bloki są nadal renderowane. W trybie programisty jest wyłączony, a wszystkie wyjątki są wyświetlane bezpośrednio w przeglądarce. Jeśli w trybach domyślnym i produkcyjnym wystąpi wyjątek podczas renderowania bloku, blok zostanie po prostu usunięty z wyjścia (odpowiedni wyjątek jest nadal rejestrowany w pliku var / log / system.log ). Zobaczyć \Magento\Framework\View\Layout::renderNonCachedElement().

Następujący wyjątek występuje podczas zamawiania renderowania bloku na stronie produktu i dlatego ten blok brakuje: main.CRITICAL: No such entity with customerId = [] [].

Powodem tego wyjątku jest to, że dane klienta w pamięci sesji są niespójne ( customerLoggedIn == truea danych klienta brakuje) po \Magento\PageCache\Model\Layout\DepersonalizePlugin::afterGenerateXml()wykonaniu. Ta wtyczka zamyka bieżącą sesję PHP i tym samym usuwa dane klientów z pamięci sesji. Dzieje się tak tylko wtedy, gdy strona jest w pełni buforowalna (a tak naprawdę jest).

Strona jest uznawana za buforowalną przez moduł pamięci podręcznej strony tylko wtedy, gdy jej układ nie zawiera bloków z cacheable="false". Dodanie tego atrybutu nie spowoduje załadowania tego bloku przez Ajax (zgodnie z założeniem w pytaniu). Aby Ajax ładował jakiś blok, ten blok powinien mieć zadeklarowaną właściwość, _isScopePrivatektóra jest ustawiona na true, ponadto, na stronie nie powinno być żadnych bloków cacheable="false". Zobacz \Magento\PageCache\Observer\ProcessLayoutRenderElement::execute()i mage.pageCache._replacePlaceholder()w Magento / PageCache / view / frontend / web / js / page-cache.js . Sprawdź także dokumenty wysokiego poziomu w pliku Readme modułu pamięci podręcznej strony

Strona produktu nie powinna być buforowalna, ponieważ cacheable="false"jest ustawiona na blok kasy, jednak tak jest ze względu na znany problem . Nie buforowane bloki są buforowane . Do czasu rozwiązania tego problemu można zastosować następujące obejście (nie pytaj mnie, dlaczego to działa, to długa historia):

  1. Iść do \Magento\Framework\Pricing\Render\Layout::__construct
  2. Zmień ['cacheable' => $generalLayout->isCacheable()]na['cacheable' => false]

Nie powinno to zaszkodzić, ponieważ strony produktu i tak nie będą buforowane po dodaniu bloku kasy

Kolejne pytanie brzmi: czy naprawdę chcesz, aby strony produktów nie były buforowane przez wbudowaną pamięć podręczną stron lub Lakier?


1
Wszelkie aktualizacje tego problemu dotyczące najnowszej wersji magento2? @Alex
Keyur Shah

Alex, chcę tylko jeden plik phtml usunąć z pamięci podręcznej. i to wywołanie pliku HTML do kontenera nagłówka. każdy pomysł daj mi znać
Camit1dk
Korzystając z naszej strony potwierdzasz, że przeczytałeś(-aś) i rozumiesz nasze zasady używania plików cookie i zasady ochrony prywatności.
Licensed under cc by-sa 3.0 with attribution required.