Неужели это решение для кешей против печенья может привести меня к неприятностям?

Я придумал временное решение для не совсем распространенной, но далеко не беспрецедентной проблемы взаимодействия популярных решений для кэширования WP с файлами cookie, в данном случае стандартными файлами cookie комментариев WP. Мое решение также опирается на редко четко определенное исключение «известных пользователей» для обслуживания кэшированных файлов. Подходит ли это для использования или нет, я полагаю, что объяснение этого и, возможно, выяснение, почему это плохая идея, может быть в целом поучительным.

Я протестировал свой метод с использованием WP Super Cache, W3 Total Cache и Comet Cache. При изучении этой проблемы я подробно остановился на WP Super Cache (далее «WPSC»), поэтому я буду использовать его в качестве основного примера.

ЗАДНИЙ ПЛАН

Когда стандартная ветка комментариев WP настроена так, чтобы посетители могли комментировать, куки-файлы комментариев устанавливаются для любого комментатора, который не является зарегистрированным пользователем и вошел в систему, с фактическими правами на комментирование, подлежащими дальнейшей проверке. В том, что я считаю наиболее распространенной конфигурацией, комментатор должен предоставить только имя и адрес электронной почты. Они хранятся в двух куки браузера, как правило comment_author_ . COOKIEHASH, и comment_author_email_ . COOKIEHASH. COOKIEHASHопределяется в соответствии с параметрами пользователя.

Если установлено, чтобы доставлять только что сгенерированные файлы «известным пользователям», WPSC определяет, следует ли обслуживать кэшированный файл, на основе нескольких проверок: вошедшие в систему пользователи получают свежие файлы, и посетители - «кто может комментировать». Последние в основном идентифицируются по наличию в их браузерах comment_author_файлов cookie, которые конкретно или однозначно не идентифицируются для конкретного пользователя COOKIEHASH(обычно, но не всегда, в кодировке MD5 версии «siteurl», записанной в опциях сайта).

То, что является ключевой частью кода WPSC, из wp-cache-phase1.php LL371-383, использует шаблон RegEx для получения строки, циклически перебирающей файлы cookie:

$regex = "/^wp-postpass|^comment_author_";
if ( defined( 'LOGGED_IN_COOKIE' ) )
    $regex .= "|^" . preg_quote( constant( 'LOGGED_IN_COOKIE' ) );
else
    $regex .= "|^wordpress_logged_in_";
$regex .= "/";
while ($key = key($_COOKIE)) {
    if ( preg_match( $regex, $key ) ) {
        wp_cache_debug( "wp_cache_get_cookies_values: $regex Cookie detected: $key", 5 );
        $string .= $_COOKIE[ $key ] . ",";
    }
    next($_COOKIE);
}

Теперь, если бы я работал строго на PHP, я мог бы заново создать или подключиться к основным функциям WP, и получить нормальный comment_author_ . COOKIEHASHнабор с помощью шаблона комментариев, но я работаю в jQuery с помощью подключаемого модуля jQuery Cookie. Однако, как вы можете видеть, если вы посмотрите на RegEx, функция WPSC не заботится о COOKIEHASH: Она удовлетворена, если встретится comment_author_.

МОЕ ТЕНТАТИВНОЕ РЕШЕНИЕ

$.cookie( 'comment_author_proxyhash', 'proxy_author', { path: '/' } );

Для тех, кто не знаком с jQuery Cookie: вышеприведенное устанавливает простой сессионный cookie с ключом = comment_author_proxyhashи значением = proxy_author, который подходит для всего сайта. (Кроме того, для тех, кто использует jQuery Cookie и WP, в дополнение к предварительной замене привычного jQuery $для WP jQuery, я также уже установил $.cookie.raw = true;.)

Я добавил строку в свой скрипт jQuery и, вуаля! WPSC, W3 Total Cache и Comet Cache ведут себя так, как я хочу. После того, как я использую скрипт и перезагружаюсь, я получаю свежие страницы. Если мне удастся разместить реальный комментарий, то будут установлены нормальный файл comment_author_и comment_author_email_файлы cookie, и, похоже, с сосуществованием проблем не возникнет.

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

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

Если нет, есть ли веская причина НЕ выдвигать это или что-то похожее на вселенную в плагине?

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

Проблема здесь заключается в том, что функциональность кэширования страниц - это то, что действительно нужно веб-сайтам, и часто кэширование страниц настраивается именно потому, что производительности WordPress недостаточно, и она может даже вывести сервер из строя в часы пик. Это зависит от характера контента сайта, но владельцы сайта иногда просто не могут оплатить оборудование, необходимое для обработки всего через код PHP / WP. Другими словами, как можно больше трафика должно обслуживаться из кэша страниц, когда это возможно. Из практики я могу сказать, что нам часто приходится идентифицировать и отключать плагины, делающие исключения из кеша.

Конечно, это не всегда возможно, но старайтесь по возможности работать с кэшированной страницей. Например, вы можете скрыть divтеги с комментариями, которые хотите игнорировать, с помощью javascript или целого блока комментариев ajax-ify.

В любом случае вам не нужно помечать посетителя как комментатор, но прекратить кэширование по причинам, связанным с вашей пользовательской логикой. Поэтому лучше использовать уникальный cookie и сделать его сигналом исключения из кэша. W3 Total Cache имеет опцию «Отклонить куки» для этого, но не другие плагины из вашего списка, поэтому вам понадобится взломать, как тот, который вы предложили.