Начиная с версии Limb 2.2+, для разработчиков доступно полностраничное кеширование, которое позволяет кешировать определенные страницы на основе относительно гибкой системы правил.

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

Самая главная проблема с кешами - это определить его валидность, то есть устарел он или нет. Иногда это очень сложная задача. В настоящее время в Limb применено самое простое решение - мы вообще не проверяем кеш на устаревание. Кеш необходимо удалять вручную через панель управления (/root/admin/cache_manager) или же посредством cron job. Нас пока такая ситуация устраивает на 100%.

Для того, чтобы настроить полностраничное кеширование, необходимо подредактировать файл PROJECT_DIR/core/settings/full_page_cache.ini. Если такого файла нет, то посмотрите здесь: LIMB_DIR/core/settings/full_page_cache.ini. Ну уж если и там нет - то создавайте новый по пути PROJECT_DIR/core/settings/full_page_cache.ini

Рассмотрим небольшой пример содержимого такого файла:

[rule-name1]
  path_regex = |^/root/documents.*$|

  groups[] = visitors
  groups[] = members

  required[] = parameter3
  required[] = parameter4
  
  optional[] = parameter1
  optional[] = parameter2
      
  type = allow
  
[rule-name2]
  path_regex = |^.*$|
  groups[] = admins
  type = deny

Файл состоит из определенных секций с некоторыми аттрибутами. Каждая секция - это одно правило. Имя секции, которая является правилом, должно начинаться с ключевого слова rule. Таким образом «rule-name1» и «rule-name2» - валидные имена правил, а «not-valid-rule» - уже нет. Это позволяет легко отключать ненужные правила на время, добавляя произвольный символ в начало имени правила.

Как же эти правила применяются?

Снача разберем последовательность работы класса full_page_cache_manager, который лежит по пути LIMB_DIR/core/cache/full_page_cache_manager.class.php и класса full_page_cache_filter:

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

Итак, правила влияют на шаги 2 и 3.

Внимание! Последовательность правил имеет большое значение. Менеджер идет именно сверху вниз и будет использовать первое правило, которое окажется валидным для текущего uri.

'path_regex' - этот параметр определяет регулярное выражение, по которому будет проверяться, подходит ли данное правило для uri или нет.

Например, если значение будет равноo |^/root/documents.*$|, то это правило будет подходить для адресов вида http://yourdomain.com/root/documents/123, но не будет подходить для http://yourdomain.com/root/archive.

Также важно знать, что только path часть запроса будет сравниваться с регулярным выражением. Другие части строки запроса, например, порт, параметры и т.д. - игнорируются.

path_regex является обязательным параметром.

Если регулярное выражение не дает результата, то менеджер переходит к следующему правилу.

'type' - указывает на тип правила, то есть разрешающее это правило или запрещающее.

В качестве значения этого правила можно указать:

• 'allow' - разрешающее,
• 'deny' - запрещающее.

Этот параметр является необязательным, а правила считаются разрешающими по умолчанию.

Если правило со значением данного правила как 'deny' является валидным для текущего uri, тогда считается, что данную страницу кешировать нельзя.

groups - определяет группы пользователей, для которых данное правило должно применяться. Для заполнения данного массива используется значок [], например так:

  optional[] = admins
  optional[] = managers

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

Неавторизированные пользователи входят в группу visitors.

Данный параметр является необязательным. Если его нет, то проверка на вхождение в определенные группы пользоватей не производится.

Если пользователь не входит ни в одну из указанных для правила групп, менеджер переходит к следующему правилу.

required - данный параметр указывает на обязательные параметры, которые должны быть в uri, чтобы правило было подходящим. Как уже указывалось path_regex применяется только для части path запроса. required аттрибут правила позволяет расширить проверку на определенные параметры запроса. Лучше всего это показать на примере:

Допустим, что был запрос по адресу http://yourdomain.com/path?pager=1&offset=2. То есть у нас есть 2 дополнительных параметра запроса 'pager' и 'offset'.

Учтите, что мы пока не используем значения параметров запроса. Они применяются только на этапе определения, существует ли кеш или нет. См. ниже параметр optional

Итак, если у нас есть правило с такими параметрами:

  required[] = pager
  required[] = offset

… или такими:

  required[] = pager

… тогда правило будет подходить под запрос http://yourdomain.com/path?pager=1&offset=2.

Но

  required[] = pager
  required[] = limit

… уже не будет. (параметр limit не найден в строке запроса).

Все это значит, что поля, определенные в 'required' параметрах правила, должны иметь место в запросе. Если какого-либо такого обязательно поля в запросе нет - правили считается неподходящим, и менеджер переходит к следующему.

Данный параметр является необязательным.

optional - этот параметр не играет никакой роли в определении того, является ли uri кешируемым или нет (в отличие от параметра 'required'). Данный параметр используется (совместно с 'required') для определения, есть ли кеш для данного запроса или нет. Здесь нужно более подробное описание.

Итак, предположим, что нам пришел запрос http://yourdomain.com/path?pager=1&offset=2, какое-то правило подошло, и настало время определить, если ли статический файл с результатом данного запроса или нет. Файл с кешом должен иметь уникальный идентификатор для каждого запроса. Теперь необходимо решить насчет того, каким образом мы будет формировать этот уникальный идентификатор. Наиболее простым способом будет использование path части запроса плюс сериализованные дополнительные значения запроса в криптованном виде. То есть для нашего примера это будет md5('path' . serialize(array('pager' ⇒ 1, 'offset' ⇒ 2)))).

Однако все параметры запроса использовать для вычисления уникального идентификатора запроса было бы неправильно. В нем пожет присутствовать номер сессии, случайные параметры и т.д. Например, такой запрос http://yourdomain.com/path?pager=1&offset=2&//rn=1000//

Для того, чтобы описывать какие, кроме «required» параметры запроса учитывать при вычислении уникального идентификатора запроса, и введен аттрибут правила 'optional'.

Естественно данный параметр является опциональным.