2014-12-11 2 views
2

Я использую W3 Total cache plugin, устанавливая страницу с использованием модуля APC. Дело в том, что, поскольку я включил файлы cookie кеша страниц, которые я установил в своем заголовке темы, перестает быть установленным, а также чтение существующего файла cookie и перенаправление его значением перестает работать.Кэш обходной страницы, созданный W3 Total Cache

Я почти на 100% уверен, что это вызывает кэш страниц, и я не могу найти правильное программное решение для перехвата кеша страницы и установки необходимых файлов cookie до кэша страниц W3TC. Также простая отладка показывает, что PHP-скрипт читается, но setCookie не устанавливает файлы cookie. Кроме того, очистка кеша страницы с помощью wordpress admin и очистка кеша лака позволяет устанавливать куки, хотя и только один раз, так как остальные вызовы на страницу будут кэшироваться (304 ответа).

Я консультировался с PHP инструкцией относительно setcookie и убедился, что мой печенье установлен перед любым HTML/пробельные

Я проверил файл .htaccess и не кэш страниц не установлен там, поэтому преодоление этого проблема с использованием PHP должна быть возможной.

Я не хочу отключать кеш страниц и терять время отклика сервера, которое он предлагает.

Любые идеи, как преодолеть эту проблему?

ответ

2

Это, скорее всего, проблема с лаком. Вы можете отключить его от кеширования своих файлов cookie при обращении к внутреннему контенту вашего сайта WP и очистить кэш Varnish после внесения изменений в вашу тему, чтобы он кэшировал новый «вид» вашего сайта.

Я использовал ваше решение W3TC + 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; 
    } 
} 

Затем добавить в продувке блока, так что 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' 
    } 
} 
2

Я прочитал «Лак» в вашем посте и получил небольшой опыт в этом (хотя только из проектов Drupal, а не WP). Лак i - обратный прокси-сервер, который служит анонимным данным. Cookies не анонимны. Разве это не проблема сама по себе?

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

Когда мне нужны быстрые WP-сайты, я использую hhvm + nginx, может быть, это альтернатива для вас.

И, да, я знаю, что это не ответ на ваш вопрос, но я не уверен, что есть PHP-решение, как вы заявляете в своем сообщении, учитывая объяснение настройки сервера. Надеюсь, ты простишь меня за это.

+0

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

+1

Отлично. Возможно, решение PHP для проблемы заключается в отправке заголовка заголовка HTTP без кэша («Cache-Control: no-cache, must-revalidate»); 'всякий раз, когда вам нужно« setcookie (...) ». С другой стороны, это может серьезно повредить производительность. gl hf :) – Johan