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

23

Я придумал временное решение для не совсем распространенной, но далеко не беспрецедентной проблемы взаимодействия популярных решений для кэширования 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, также охватывающий альтернативные варианты использования ... или для достижения того же конечного эффекта с помощью других средств - других способов заставить подключаемые модули кэширования обращаться с посетителем как комментатор ...

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

CK MacLeod
источник
3
Реквизит для хорошо изученного и задокументированного вопроса. Тем не менее, я чувствую, что природа вопроса может открыть это для большей части дискуссии, а не для окончательного ответа (не по теме: прежде всего на основе мнения). FWIW, на мой взгляд, я не вижу в этом ничего плохого - в конечном счете, вы просто устанавливаете один общий файл cookie без личных данных.
TheDeadMedic
Большое спасибо за вклад. Я был бы благодарен за такое обсуждение, и я бы отметил в качестве хороших ответов любые, которые а) указали на проблему с этим методом "универсального файла cookie", б) предоставили альтернативные средства для достижения того же эффекта, или в) предоставили полезную понимание основных технических вопросов, касающихся «известных пользователей».
CK MacLeod
Просто чтобы заметить, вы можете использовать wp_localize_scriptдля передачи хеша cookie в ваш Javascript, чтобы вы могли использовать «родной» cookie вместо прокси-хеша. В противном случае это очень интересная проблема, и ваше решение кажется надежным, хотя куки + кэш всегда настолько сложны, что трудно сказать, является ли это «правильным» решением или что-то упускается. Отличное исследование!
phatskat
Интересный вопрос - я не могу придумать ничего такого, что может привести к неприятностям, но могу ли я спросить, почему вы хотите обойти кеш таким образом? Предоставление пользователям этой способности отчасти побеждает цель иметь полный кеш страниц для начала. Кроме того, дополнительный файл cookie увеличивает размер запроса (хотя и минимально), когда тот же результат может быть достигнут с помощью общих конфигураций кэша, просто добавляя любые параметры запроса в URL, например, mysite.com?a. Просто мои $ 0,02 ...
ssnepenthe
ssnepenthe: Может быть, я должен был объяснить: плагин, который я разрабатывал, когда писал вопрос - wordpress.org/plugins/commenter-ignore-button - использует jQuery, чтобы позволить посетителям ставить выбранные комментарии «на игнорирование». Первоначальное действие применяет форматирование CSS к потоку комментариев, а затем полагается на cookie для хранения обозначения и его наличия для дублирования эффекта (через PHP) при последующих обновлениях до истечения срока действия cookie. В кэшированной версии страницы эффект не будет зарегистрирован. Так что, да, это форма преднамеренного уничтожения кэша.
CK MacLeod

Ответы:

1

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

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

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

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

WowPress.host
источник
Благодарность! Вы поднимаете ряд допустимых проблем, но я скажу, что этот код, по сути, обрабатывает любого посетителя, участвующего в потоках комментариев, достаточно, чтобы поставить кого-то "на игнорирование" или "отключить" как "известного пользователя / комментатор «. Если сайт не может обработать такое участие, то, вероятно, он также не может обрабатывать стандартный шаблон комментариев WordPress (и сообщество комментирующих)!
CK MacLeod
Думаю, что вы здесь, хотя, конечно, не можете точно знать, как ваши пользователи его используют. Кстати, многие веб-сайты с большим трафиком переносят обработку своих комментариев на отдельные запросы или даже на сторонние службы именно с целью быстрого отображения содержимого статьи и ленивой загрузки содержимого динамических комментариев позже. Примите это как идею
оффтопа