Bu Önbellek ve Çerezler Belada Beni Alacaklar mı?


23

Popüler WP önbelleğe alma çözümlerinin çerezlerle etkileşimi ile ilgili benzeri olmayan bir sorun için geçici bir çözüm buldum, bu durumda standart WP yorum çerezleri. Benim çözümüm ayrıca, önbelleğe alınmış dosyalara sunulan nadiren iyi bilinen "bilinen kullanıcılar" istisnasına da dayanıyor. Kullanılabilir olsun veya olmasın, açıklamanın ve muhtemelen neden kötü bir fikir olduğunu öğrenmenin genellikle öğretici olabileceğini düşünüyorum.

Yöntemimi WP Süper Önbellek, W3 Toplam Önbellek ve Comet Önbellek ile test ettim. Bu sorunu incelerken kendim için detaylı olarak ayrıldığım kişi WP Süper Önbellek (bundan sonra "WPSC") idi, bu yüzden ana örneğim olarak kullanacağım.

ARKA FON

Bir WP standart yorum dizisi, ziyaretçilerin yorum yapmasına izin verecek şekilde ayarlandığında, kayıtlı çerezler olmayan ve giriş yapan herhangi bir yorumcu için yorum çerezleri ayarlanır ve daha sonra kontrollere tabi olan gerçek yorum yapma ayrıcalıkları bulunur. En yaygın yapılandırma olduğuna inanıyorum, bir yorumcunun yalnızca bir ad ve bir e-posta adresi sağlaması gerekiyor. Bunlar, genellikle comment_author_ . COOKIEHASHve iki tarayıcı çerezinde saklanır comment_author_email_ . COOKIEHASH. COOKIEHASHkullanıcı seçeneklerine göre tanımlanır.

Yeni oluşturulan dosyaları "bilinen kullanıcılara" sunacak şekilde ayarlanmışsa, WPSC önbelleklenmiş bir dosyanın birkaç denetime dayanarak sunulup sunulmayacağını belirler: Giriş yapan kullanıcılar yeni dosyalar alır ve ziyaretçiler "yorum yapabilenler" yapar. Sonuncusu, comment_author_çerez tarayıcılarında , belirli bir kullanıcı için özel olarak veya benzersiz bir şekilde tanımlanmayan tanımlama bilgilerinin varlığıyla tanımlanır COOKIEHASH(genellikle, ancak site seçeneklerinde kaydedilmiş olan "siteurl" un her zaman MD5 kodlu bir versiyonu).

WPSC kodunun anahtar parçası olarak görünen, wp-cache-phase1.php LL371-383'ten bir dizge almak için çerezler arasında dolaşmak için bir RegEx modeli kullanır:

$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);
}

Şimdi, eğer kesinlikle PHP'de çalışıyor olsaydım, WP çekirdek işlevlerini yeniden üretebilir ya da bağlayabilir comment_author_ . COOKIEHASHve yorum şablonuyla normal olarak ayarlayabilirdim, ancak jQuery Cookie eklentisini kullanarak jQuery'de çalışıyorum. Ancak, RegEx'e bakarsanız görebileceğiniz gibi, WPSC işlevi aşağıdakilerle ilgilenmez COOKIEHASH: Karşılaşırsa memnun olur comment_author_.

TENTATİF ÇÖZÜM

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

JQuery Cookie ile aşina olmayanlar için: Yukarıdaki, key = comment_author_proxyhashve value = proxy_authorolan tüm siteye uygun basit bir oturum çerezi kurar . (Ayrıca, jQuery Cookie ve WP kullananlar $için, WP'nin tanıdık jQuery'lerini önceden ikame etmenin yanı sıra jQuery, ben de hazırladım $.cookie.raw = true;.)

Satırı jQuery scriptime ekledim ve voila! , WPSC, W3 Toplam Önbellek ve Comet Önbellek istediğim gibi hareket ediyor. Komut dosyasını kullanıp yeniden yükledikten sonra yeni sayfalar alıyorum. Gerçek bir yorum yaparsam, normal comment_author_ve comment_author_email_çerezler ayarlanır ve birlikte yaşamaya dair herhangi bir sorun yok gibi görünüyor.

Belki de bir kusur, "proxyhash" çerezinin, oturumu açık tuttuğu sürece, kullanıcıyla birlikte seyahat edeceği, ancak bu beni büyük bir sorun - veya hatta bir uyarıya değecek kadar önemli değil -. Kesinlikle normal çerezlerden biriyle böyle bir şeyden şikayetçi olan birini duymadım.

Ama belki de özlediğim bir şey var ve belki de benim düzenlememe rağmen, sıkıntımla ilgili çok şey keşfetmek üzereyim. Veya belki de COOKIEHASHjQuery'de kopyalamam için , alternatif kullanım durumlarını da kapsayan ... ya da başka yollarla aynı son etkiyi elde etmem için nispeten basit, en iyi pratik bir yol var ... ya da önbellekleme eklentilerini ziyaretçiyi tedavi etmek için kandırmanın başka yolları yorumcu olarak ...

Eğer değilse, bir eklentide bunu ya da ona yakın bir şeyi evrene itmemek için herhangi bir sebep var mı?


3
İyi araştırılmış ve belgelenmiş bir soru için destek. Bununla birlikte, sorunun doğasının bunu kesin bir cevabın aksine bir tartışmaya daha fazla açabileceğini hissediyorum (konu dışı: öncelikle görüşe dayalı). FWIW bence burada yanlış bir şey görmüyorum - sonuçta kişisel verileri olmayan tek, genel bir çerez ayarlıyorsunuz.
TheDeadMedic

Giriş için çok teşekkürler. Böyle bir tartışma için minnettar olurum ve iyi cevaplar olarak işaretlerdim: a) bu "genel çerez" yöntemiyle ilgili bir sorunu işaret etti, b) aynı etkiyi elde etmek için alternatif araçlar sağladı veya c) faydalı sağlandıysa “bilinen kullanıcılar” ile ilgili temel teknik sorulara ilişkin içgörü.
CK MacLeod

Sadece not etmek gerekirse wp_localize_script, çerez karma'sını Javascript'inize aktarmak için kullanabilirsiniz, böylece proxyhash yerine "yerel" çerezini kullanabilirsiniz. Aksi halde, bu çok ilginç bir konudur ve çözümünüz sağlam gibi görünse de, çerezler + önbellek her zaman çok karmaşık olsa da, "doğru" bir çözüm olup olmadığını veya kaçırılan bir şey olup olmadığını söylemek zor. Harika araştırma!
phatskat

İlginç soru - Bu konuda sizi sıkıntıya sokacak hiçbir şey düşünemiyorum, ama neden önbelleği bu şekilde atlamak istediğinizi sorabilir miyim? Kullanıcılara bu yeteneği vermek, tam sayfa önbelleği ile başlamak amacını yitirir. Dahası, fazladan bir çerez (en azından de olsa) istek boyutuna eklenir, aynı sonuç URL'ye herhangi bir sorgu paragrafı ekleyerek, ortak önbellek yapılandırmalarıyla elde edilebilir, örneğin mysite.com?a. Sadece $ 0,02 ...
17'de

ssnepenthe: Belki de açıklamalıydım: Ben soruyu yazarken geliştirdiğim bir eklenti - wordpress.org/plugins/commenter-ignore-button - ziyaretçilerin "yorum yapmama" üzerine seçmen yorumlarını koymalarına izin vermek için jQuery kullanıyor. İlk eylem, yorum dizisine CSS biçimlendirmesi uygular ve daha sonra tanımlama bilgisi sona erinceye kadar izleyen yenilemelerde etkiyi (PHP yoluyla) çoğaltmak için atamasını ve varlığını depolamak için bir çereze dayanır. Sayfanın önbelleğe alınmış bir sürümünde, efekt kaydedilmez. Yani, evet, kasıtlı yerelleştirilmiş önbellek bozma şekli.
CK MacLeod

Yanıtlar:


1

Comment_author_proxyhash çerezi ile çözümünüz elbette teknik olarak işe yarayacak - bildiğim tüm önbellekleme eklentileri karma değerini analiz etmiyor ve önbelleğe alınmış içeriğin comment_author_ * çerez sunumuna dayanarak yayınlanmasını durduracak.

Buradaki sorun, sayfa önbelleğe alma işlevselliğinin web sitelerinin gerçekten ihtiyaç duyduğu bir şeydir ve genellikle sayfa önbelleği tam olarak yapılandırılmıştır çünkü çıplak WordPress performansı yeterli değildir ve en yoğun zamanlarda sunucuyu çökertebilir. Bu, web sitesi içeriğinin içeriğine bağlıdır, ancak site sahipleri bazen PHP / WP kodu aracılığıyla her şeyi işlemek için gereken donanım için ödeme yapamazlar. Diğer bir deyişle mümkün olduğunca trafik, sayfa önbelleğinden mümkün olduğunda sunulmalıdır. Uygulamadan, önbellek istisnaları yapan eklentileri tanımlamamız ve devre dışı bırakmamız gerektiğini söyleyebilirim.

Elbette her zaman mümkün değildir, ancak mümkün olduğunda önbelleklenmiş sayfa ile çalışmayı deneyin. Örneğin div, javascript veya ajax-ify bütün yorum bloğu yoluyla yoksaymak istediğiniz yorumlarla etiketleri gizleyebilirsiniz .

Her durumda ziyaretçiyi yorumcu olarak işaretlemeniz gerekmez, ancak özel mantık nedenleriniz nedeniyle önbelleğe almayı durdurun. Bu nedenle, benzersiz bir çerez kullanmak ve onu bir önbellek istisna sinyali yapmak daha iyidir. W3 Toplam Önbellekte bunun için "Çerezleri Reddet" seçeneği var, ancak listenizdeki diğer eklentiler yok, bu yüzden önerdiğiniz bir kesmeye ihtiyacınız olacak.


Teşekkürler! Bir dizi geçerli sorun ortaya çıkarıyorsunuz, ancak bu kodun yaptığı şeyin, esas olarak, yorum konularına katılan herhangi bir ziyaretçiyi birisini "yoksaymaya" veya "sessiz" bir kullanıcı olarak bilinen bir kullanıcı olarak kabul etmeye yeterli olduğunu söyleyeceğim / Yorumcu." Bir site bu tür bir katılımı kaldıramazsa, muhtemelen standart bir WordPress yorum şablonunu (ve yorum yapan topluluğu) da idare edemez!
CK MacLeod,

Burada olduğunuzu düşünün, elbette, kullanıcılarınızın onu nasıl kullandığını kesin olarak bilemezsiniz. BTW, yüksek trafikli web sitelerinin yorum işlemlerini, daha sonra hızlı ve tembel yükleme dinamik yorumlar içeriğini görüntülemek amacıyla tam olarak ayrı bir isteklere hatta üçüncü taraf hizmetine indirgiyor. Eklentinizin belki de daha ileri sürümleri için offtopik bir fikir olarak kabul edin :)
WowPress.host 29:18
Sitemizi kullandığınızda şunları okuyup anladığınızı kabul etmiş olursunuz: Çerez Politikası ve Gizlilik Politikası.
Licensed under cc by-sa 3.0 with attribution required.