मैं बिल्कुल सामान्य नहीं है, लेकिन कुकीज़ के साथ लोकप्रिय WP कैशिंग समाधान की बातचीत के साथ अभूतपूर्व समस्या से दूर के लिए एक अनंतिम समाधान के साथ आया हूं, इस मामले में मानक WP टिप्पणी कुकीज़। मेरा समाधान भी शायद ही कभी परिभाषित "ज्ञात उपयोगकर्ताओं" पर निर्भर करता है ताकि कैश्ड फ़ाइलों की सेवा की जा सके। यह प्रयोग करने योग्य है या नहीं, मुझे लगता है कि इसे समझाने और संभवतः यह जानने के लिए कि यह एक बुरा विचार क्यों है, आमतौर पर शिक्षाप्रद हो सकता है।
मैंने WP Super Cache, W3 Total Cache, और Comet Cache के साथ अपने तरीके का परीक्षण किया है। इस समस्या का अध्ययन करते समय मैंने अपने बारे में जो विस्तार से बताया, वह था WP सुपर कैश (इसके बाद "डब्ल्यूपीएससी"), इसलिए मैं इसे अपने मुख्य उदाहरण के रूप में उपयोग करूंगा।
पृष्ठभूमि
जब एक WP मानक टिप्पणी धागा आगंतुकों को टिप्पणी करने की अनुमति देने के लिए सेट किया जाता है, तो टिप्पणियाँ कुकीज़ किसी भी टिप्पणीकार के लिए सेट की जाती हैं जो एक पंजीकृत उपयोगकर्ता नहीं है और लॉग इन किया है, वास्तविक टिप्पणी विशेषाधिकारों के आगे जांच के अधीन है। मेरा मानना है कि सबसे आम विन्यास है, एक टिप्पणीकार को केवल एक नाम और एक ईमेल पते की आपूर्ति करने की आवश्यकता है। ये आमतौर पर comment_author_ . COOKIEHASH
और , दो ब्राउज़र कुकीज़ के भीतर संग्रहीत होते हैं comment_author_email_ . COOKIEHASH
। COOKIEHASH
उपयोगकर्ता विकल्पों के अनुसार परिभाषित किया गया है।
यदि "ज्ञात उपयोगकर्ताओं को ताज़ा जेनरेट की गई फ़ाइलों को वितरित करने के लिए सेट किया जाता है," WPSC यह निर्धारित करता है कि कई जाँचों के आधार पर कैश्ड फ़ाइल की सेवा दी जाए या नहीं: लॉग-इन उपयोगकर्ताओं को ताज़ा फ़ाइलें मिलती हैं, और इसलिए आगंतुक "जो टिप्पणी कर सकते हैं।" उत्तरार्द्ध मुख्य रूप से comment_author_
कुकीज़ के अपने ब्राउज़र में उपस्थिति से पहचाने जाते हैं जो विशेष रूप से उपयोगकर्ता के लिए विशेष रूप से या विशिष्ट रूप से पहचाने नहीं जाते हैं COOKIEHASH
(आमतौर पर साइट विकल्पों में दर्ज "साइटर्ल" का एमडी 5-एन्कोडेड संस्करण नहीं)।
डब्ल्यूपीसी-कोड -1. डब्ल्यूपी-एलएल 371-383 से डब्ल्यूपीसीसी कोड का प्रमुख हिस्सा क्या प्रतीत होता है, कुकीज़ प्राप्त करने के लिए एक स्ट्रिंग, साइकिल चलाने के लिए एक RegEx पैटर्न का उपयोग करता है:
$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 कुकी प्लग-इन का उपयोग करके काम कर रहा हूं। हालाँकि, जैसा कि आप देख सकते हैं कि यदि आप RegEx को देखते हैं, तो WPSC फ़ंक्शन को इसकी परवाह नहीं है COOKIEHASH
: यदि यह सामना करता है तो यह संतुष्ट है comment_author_
।
मेरा तम्बू समाधान
$.cookie( 'comment_author_proxyhash', 'proxy_author', { path: '/' } );
JQuery कुकी से अपरिचित लोगों के लिए: उपरोक्त कुंजी = comment_author_proxyhash
और मान = के साथ एक साधारण सत्र कुकी सेट करता है proxy_author
, जो पूरी साइट के लिए अच्छा है। (इसके अलावा, जो लोग jQuery कुकी और WP का उपयोग करें, इसके अलावा में पूर्व प्रतिस्थापन परिचित jQuery के लिए $
WP के लिए jQuery
, मैं भी पहले से ही निर्धारित किया है $.cookie.raw = true;
।)
मैंने अपने jQuery स्क्रिप्ट और, वॉइला में लाइन जोड़ी ! , WPSC, W3 कुल कैश, और धूमकेतु कैश सभी अभिनय कर रहे हैं जैसे मैं उन्हें चाहता हूं। जब मैं स्क्रिप्ट का उपयोग करता हूं, और फिर से लोड करता हूं, तो मुझे नए पृष्ठ मिलते हैं। अगर मैं एक वास्तविक टिप्पणी करने के लिए होता हूं, तो सामान्य comment_author_
और comment_author_email_
कुकीज़ सेट होते हैं, और सह-अस्तित्व के साथ कोई समस्या नहीं लगती है।
शायद एक दोष यह होगा कि "प्रॉक्सी" कुकी उपयोगकर्ता के साथ यात्रा करेगी जब तक कि वह सत्र को खुला रखती है, लेकिन यह मुझे एक बड़ी समस्या के रूप में हड़ताल नहीं करता है - या यहां तक कि चेतावनी के लायक भी। मैंने निश्चित रूप से किसी को नियमित कुकीज़ में से किसी के साथ होने वाली शिकायत के बारे में नहीं सुना है।
लेकिन शायद कुछ ऐसा है जो मुझे याद आ रहा है, और मेरे शोक के बारे में बहुत कुछ पता करने के लिए, यदि संभवतः मेरे संपादन के लिए भी। या शायद मेरे लिए COOKIEHASH
jQuery में दोहराने के लिए एक अपेक्षाकृत सरल सबसे अच्छा तरीका है , वैकल्पिक उपयोग के मामलों को भी कवर करना ... या अन्य तरीकों से एक ही अंतिम प्रभाव को प्राप्त करना - आगंतुक को इलाज करने में कैशिंग प्लग-इन को धोखा देने के अन्य तरीके। एक टिप्पणीकार के रूप में ...
यदि नहीं, तो क्या यह कोई अच्छा कारण नहीं है कि इस या कुछ और को प्लग-इन में ब्रह्मांड के बाहर धकेल दिया जाए?
wp_localize_script
कुकी हैश को अपनी जावास्क्रिप्ट में पास करने के लिए उपयोग कर सकते हैं ताकि आप छद्म के बजाय "देशी" कुकी का उपयोग कर सकें। अन्यथा, यह एक बहुत ही दिलचस्प मुद्दा है और आपका समाधान ठोस प्रतीत होता है, हालांकि कुकीज़ + कैश हमेशा इतना जटिल होता है कि यह कहना मुश्किल है कि यह "सही" समाधान है या यदि कुछ याद किया जा रहा है। महान शोध!