Обойти кеш страниц, созданный W3 Total Cache
Я использую W3 Total cache плагин настройки страницы кеш с помощью модуля APC.
Дело в том, что, поскольку я включил файлы cookie кэша страницы, которые я установил в заголовке своей темы, перестал быть установленным, также перестали работать также существующие файлы cookie и перенаправление по значению.
Я почти на 100% уверен, что именно кеш страниц вызывает его, и я не могу найти правильного программного решения для перехвата кеша страниц и установки необходимых куки-файлов до кеша страниц W3TC.
Также простая отладка показывает, что PHP-скрипт читается, но setCookie не устанавливает куки.
Более того, очистка кеша страницы с помощью администратора WordPress и кеш очистки лака позволяет устанавливать куки, хотя и только один раз, так как остальные обращения к странице будут кэшироваться (ответ 304).
Я проконсультировался с руководством по PHP относительно SetCookie и удостоверился, что мой куки установлен перед любым HTML / пробелами
Я проверил файл .htaccess и там не установлен кеш страниц, поэтому я полагаю, что преодоление этой проблемы с помощью PHP должно быть возможным.
Я не хочу отключать кеш страниц и терять существенное улучшение времени отклика сервера.
Есть идеи, как преодолеть эту проблему?
Решение
Это, скорее всего, проблема с лаком. Возможно, вы захотите отключить кэширование ваших файлов cookie при обращении к бэк-энду своего WP-сайта и очистить кэш Varnish после внесения изменений в свою тему, чтобы он кешировал новый «вид» вашего сайта.
Я уже использовал ваше решение W3TC + Varnish, и мне нужно немного поработать, чтобы сделать это правильно. Мой совет по использованию Varnish для WP (часть конфигурации) вы можете ссылаться (а не копировать):
sub vcl_recv {
# Don't cache WordPress backend
if (req.url ~ "wp-(login|admin|comments-post.php|cron.php)" || req.url ~ "preview=true" || req.url ~ "xmlrpc.php") {
return (pass);
}
# Don't cache if WordPress cookie is present
if (req.http.cookie) {
if (req.http.cookie ~ "(wordpress_|wp-settings-)") {
return(pass);
} else {
unset req.http.cookie;
}
}
}
sub vcl_fetch {
# Don't cache WordPress backend
if (req.url ~ "wp-(login|admin|comments-post.php|cron.php)" || req.url ~ "preview=true" || req.url ~ "xmlrpc.php") {
set beresp.http.magicmarker = "1";
return (hit_for_pass);
}
if ( (!(req.url ~ "(wp-(login|admin|comments-post.php|cron.php)|login)")) || (req.request == "GET") ) {
unset beresp.http.set-cookie;
set beresp.ttl = 4h;
}
}
Затем также добавьте блок PURGE, чтобы W3TC мог очистить кеш (а не делать это вручную) после обновления сайта / темы.
acl purge {
# Only allow the server to issue PURGE requests
"127.0.0.1";
"localhost";
"162.243.151.227";
}
sub vcl_hit {
if (req.request == "PURGE") {
purge;
error 200 "HIT Purged.";
}
}
sub vcl_miss {
if (req.request == "PURGE") {
purge;
error 200 "MISS Purged.";
}
}
sub vcl_recv {
# PURGE requests
if (req.request == "PURGE") {
if (!client.ip ~ purge) {
error 401 "Not allowed.";
}
# 3 ways to refresh the cache:
# 1: force lookup
# return (lookup);
# 2: url purging: http://wordpress.stackexchange.com/questions/76037/make-w3-total-cache-empty-all-caches-function-purge-varnish
# purge_url(req.url);
# 3: ban to invalidate cache content
ban("req.url ~ ^" + req.url + "$ && req.http.host == " + req.http.host);
error 200 "RECV Purged.";
# Observe with: varnishlog -I 'VCL_error'
}
}
Другие решения
Я читаю «Varnish» в вашем посте и имею небольшой опыт в этом (хотя только из проектов Drupal, а не WP). Лак я обратный прокси, который обслуживает анонимные данные. Печенье не является анонимным. Разве это не проблема сама по себе?
Возможно, вы могли бы настроить Varnish на игнорирование страниц, кэшированных с определенным файлом cookie, но это, вероятно, не поможет ускорить вашу веб-страницу.
Когда мне нужны быстрые WP-сайты, я использую hhvm + nginx, возможно, это альтернатива для вас.
И да, я знаю, что это не ответ на ваш вопрос, но я не уверен, что есть PHP-решение, как вы заявляете в своем посте, учитывая настройки сервера, объясненные. Я надеюсь, что вы можете простить меня за это.