Как включить динамический блок на страницу продукта с полным кэшированием страниц?

Question

Мы хотели бы добавить динамический блок на страницу продукта.Проблема в том, что страница продукта имеет полное кэширование страниц (и мы не можем отключить его из-за проблем со скоростью).Мы хотим отображать различную информацию на каждой странице продукта в зависимости от учетной записи пользователя, вошедшего в систему, и она варьируется от продукта к продукту.

Я создал отдельный блок с собственным кэшированием, но при этом отображается тот же блок изпредыдущая страница продукта.Я пытаюсь изменить метод кэширования, чтобы он не сохранял кэш с предыдущей страницы продукта.

Он работает первые несколько раз, когда я захожу на страницы продукта, но затем неожиданно начинает отображаться ошибка Magento.страница, на которой написано: «Веб-сайт обнаружил ошибку при получении http://www.mycompany.com/productpage.html.
Возможно, он недоступен для обслуживания или неправильно настроен».

Вот что я сделал до сих пор.

Я создал app/code/local/MyCompany/MyModule/PageCache/etc/config.xml для добавления MyCompany_PageCache_Model.

Затем я создал файл, управляющий кэшированием, в app/code/local/MyCompany/MyModule/PageCache/Model/Container/MyFile.php
с этими функциями:

protected function _getCacheId()
{
    return 'CONSTANT_CACHE' . md5($this->_placeholder->getAttribute('cache_id'));
}

protected function _saveCache($data, $id, $tags = array(), $lifetime = null)
{
    return false;
}

protected function _renderBlock()
{
    $blockClass = $this->_placeholder->getAttribute('block');
    $template = $this->_placeholder->getAttribute('template');

    $block = new $blockClass;
    $block->setTemplate($template);
    $block->setLayout(Mage::app()->getLayout());
    return $block->toHtml();
}

Я также создал cache.xml в Каталог / etc с моим заполнителем для CONSTANT_CACHE.

Неверный синтаксис или есть более простой способ сделать это?

Answer 1

Обзор

Чтобы ответить, мне нужно сначала немного объяснить.Процесс Magento FPC знает четыре состояния.

1. Страница в кеше, без динамических блоков
2. Страница в кеше, динамические блоки кэшированы
3. Страница в кеше, динамические блоки не кэшированы
4. Страницане в кеше

Состояния 1 и 2 обрабатываются без полной инициализации приложения Magento.Состояния 3 и 4 требуют инициализации приложения и обработки маршрутизации.По этой причине стремитесь обслуживать запросы из состояний 1 и 2, если это возможно, в противном случае вы теряете большую часть возможных улучшений FPC.

Состояние 1

Состояние 1 является скучным изс точки зрения разработчика, ничего не делать, поэтому давайте перейдем к ...

Состояние 2

В состоянии 2 страница содержит динамические блоки. В данный момент Magento не полностью инициализирован .
Процессор FPC загружает кэшированную страницу и находит в ней заполнитель для динамического блока.
Анализируя заполнитель, процессор можетопределить класс контейнера для динамического блока, создать его экземпляр и вызвать applyWithoutApp($content) для него.(Название метода относится к тому факту, что приложение Magento до сих пор не инициализировано).Затем контейнер пытается загрузить содержимое динамического блока из кеша блока, используя ключ кеша, возвращаемый методом $this->_getCacheId().
Если возвращается ключ кеша и может быть загружена запись в кеш, класс контейнера заменяет заполнительв $content с выводом кэшированного блока и выполнением FPC.
Пока не было получено слишком много служебных данных.

Состояние 3

Так что applyWithoutApp($content) в состоянии 2 былоневозможно получить и доставить содержимое динамического блока, поэтому необходимо создать содержимое блока, даже если остальная часть страницы найдена в FPC.
Для этой цели модуль FPC устанавливает запрос на pagecache/request/process,и за ним следует обычная инициализация и маршрутизация приложения Magento.
Это означает, что при состоянии 2 создается намного больше накладных расходов, чем при обычной загрузке страницы без FPC, потому что, например, перезапись URL
Наконец, передний контроллер и стандартный маршрутизатор делегируют запрос методу RequestController::processAction()d.
Метод извлекает ранее созданный экземпляр класса контейнера для динамического блока и вызывает для него applyInApp($content).
Этот метод запускает $this->_renderBlock(), чтобы создать экземпляр класса реального блока и вернуть его выходные данные.Вы уже реализовали этот метод в соответствии с вашим вопросом.FPC теперь может заменить заполнитель содержимым блока и доставить страницу.
Следует помнить, что - это не обычный запрос страницы сведений о продукте, поэтому, например, Mage::registry('current_product') неимеется в наличии!В зависимости от реализации вашего блока это может повлиять на кэширование на уровне блоков или генерацию содержимого динамического блока.Я подозреваю, что это может быть из-за вашей проблемы, но я найду возможный обходной путь чуть ниже.

Состояние 4

В этом состоянии FPC не нашел запись кэша для запрошенной страницы, поэтому Magento генерирует страницу как обычно, например, вывод сведений о продукте создается с помощью Mage_Catalog_ProductController::viewAction().
Все блоки, настроенные как динамические, согласно cache.xml, обернуты в теги-заполнители.
Теги-заполнители содержат аргументы, которые позже передаются объекту-контейнеру для шагов 2 и 3Единственные аргументы, которые всегда установлены, - это контейнер и имена классов блоков.Но почти всегда задаются cache_id и template.
В классе контейнера к этим значениям можно получить доступ с помощью $this->_placeholder->getAttribute('cache_id') (как вы это делали в методе _getCacheId () вашего контейнера).

Даже если вы замаскировали большую часть этого длинного ответа, это может быть вам интересно. Если вам нужны дополнительные значения для генерации идентификатора кэша блоков или вывода блока (например, идентификатора продукта или идентификатора клиента), вы можете установить их в качестве аргументов для заполнителя .

Для этого вам нужно установить их в массиве, возвращаемом методом block getCacheKeyInfo() со строкой в качестве ключа массива . Если вы используете числовой индекс массива, они не будут установлены в качестве аргументов для заполнителя.

public function getCacheKeyInfo() {
    $info = parent::getCacheKeyInfo();
    $info['current_product_id'] = Mage::registry('current_product')->getId();
    $info['customer_id'] = Mage::getSingleton('customer/session')->getCustomerId();
    return $info;
}

Эти значения теперь доступны в классе контейнера, используя $this->_placeholder->getAttribute('current_product_id').

Заключение

Вы, вероятно, не хотите переопределять _saveCache() в своем классе контейнера для возврата false. Вместо этого включите идентификатор клиента и идентификатор продукта в строку, возвращаемую _getCacheId(). Таким образом, каждый клиент получает свою собственную запись в кеш. Некоторые накладные расходы будут уменьшены, поскольку applyWithoutApp() может сохранять и загружать динамический блок из кэша (если страница просматривается дважды одним и тем же пользователем).

В _renderBlock() установите дополнительные значения, которые вам нужны, чтобы блок мог генерировать на нем свое содержимое, например,

$block->setProductId($this->_placeholder->getAttribute('current_product_id'));

На стороне блока, включая идентификатор продукта и идентификатор клиента в массиве данных кэша, будет гарантировано, что каждый клиент получит правильный вывод для запрошенной страницы, даже когда блок кэшируется.

Я не могу знать наверняка, (вы не предоставили код блока), но я подозреваю, что используемый вами идентификатор кэша не содержит всех аргументов, необходимых для однозначного сопоставления записи кэша для блока. правильный продукт.

Используя эти шаги и зная, как передавать аргументы в контейнер динамических блоков, можно сохранить большую часть выигрыша в производительности FPC даже при создании пользовательских динамических блоков. Я надеюсь, что этой информации достаточно для того, чтобы вы смогли отследить описанную проблему и исправить ее.

Answer 2

В целом, есть два подхода, которые вы можете использовать, если хотите персонализировать страницу, предназначенную для хранения в кеше полной страницы.

1. Если ваш обратный прокси-сервер поддерживает это, вы можетеиспользуйте ESI (Edge Side Includes) и разметьте свой шаблон соответствующим образом.ESI позволяет вам вставить маркер в ваш сгенерированный HTML, куда должен идти персонализированный контент, тогда ваш прокси-сервер будет запрашивать только персонализированный контент с соответствующего пути контроллера вашего сервера приложений, когда это необходимо.Если вы используете Varnish , ESI доступен для использования .Расширение Lightspeed для Magento имеет функцию под названием " Hole Punching" , которая выполняет аналогичные действия.
2. Если ESI или Hole Punching вам недоступны, тодругой вариант - разрешить кэширование главной страницы в вашем полностраничном кэше и использовать немного javascript для создания отдельного запроса Ajax и получения необходимой информации.

Answer 3

Нет необходимости:

  $info['current_product_id'] = Mage::registry('current_product')->getId();

Вы можете использовать этот метод:

$this->_getProductId()

реализовано в Enterprise_PageCache_Model_Container_Abstract

Answer 4

Я действительно ценю ответ Vinai. Кроме того, я бы предложил расширение FPC от Гордона Лести, которое поддерживает пробивание отверстий. Вы можете получить это здесь

Для получения инструкций о том, как перфорация работает с этим расширением, я предлагаю вам посетить эту страницу

Надеюсь, это поможет кому-то, кто не очень знаком с понятиями.