WordPress का wptexturize फ़िल्टर चुपचाप इनलाइन JavaScript को बिगाड़ रहा है, जिससे लॉजिकल && ऑपरेटर HTML एंटिटी && में बदल जाता है और शॉर्टकोड के अंदर चलने वाले स्क्रिप्ट्स टूट जाते हैं।
यह समस्या एक ऐसे डेवलपर के सामने आई जो कैलकुलेटर शॉर्टकोड का एक सेट मेंटेन करता है। हफ्तों तक बिना किसी त्रुटि के काम करने के बाद, सबमिट बटन ने काम करना बंद कर दिया। कोई PHP चेतावनी नहीं, कोई कंसोल एरर नहीं, और इंस्पेक्ट किया गया HTML भी बिल्कुल साफ था—जब तक कि रेंडर किए गए सोर्स में if (!isNaN(bf) && bf > 0) नहीं दिखा। इस एक सिंटैक्स एरर ने पूरे स्क्रिप्ट ब्लॉक को चलने से रोक दिया।
यह फ़िल्टर क्यों महत्वपूर्ण है
WordPress ब्राउज़र तक पहुँचने से पहले पोस्ट कंटेंट को फ़िल्टर की एक श्रृंखला के माध्यम से प्रोसेस करता है। wptexturize उन फ़िल्टर्स में से पहला है; यह सीधे उद्धरणों (straight quotes) को टाइपोग्राफिक कर्ली कोट्स (curly quotes) में बदल देता है, कई हाइफ़न को em-dashes से बदल देता है, और एम्परसेंड्स (&) को सैनिटाइज़ करता है। यह फ़िल्टर यह मानकर चलता है कि वह गद्य (prose) के साथ काम कर रहा है, कोड के साथ नहीं। जब कोई शॉर्टकोड एक इनलाइन <script> टैग इंजेक्ट करता है, तो फ़िल्टर फिर भी चलता है, और JavaScript को साधारण टेक्स्ट की तरह ट्रीट करता है। इसलिए && में एम्परसेंड को एस्केप करके & कर दिया जाता है, जिसे ब्राउज़र लॉजिकल AND ऑपरेटर के बजाय एक लिटरल स्ट्रिंग के रूप में इंटरप्रेट करता है।
जो डेवलपर्स पोस्ट कंटेंट में सीधे किसी भी प्रकार का JavaScript एम्बेड करते हैं—जैसे कैलकुलेटर, फॉर्म वैलिडेटर, इंटरैक्टिव विजेट—वे इसके प्रति संवेदनशील हैं। यह समस्या केवल कैलकुलेटर तक सीमित नहीं है; कोई भी इनलाइन स्क्रिप्ट जो &&, &, या इसी तरह के कैरेक्टर्स का उपयोग करती है, वह खराब हो सकती है। चूंकि यह ट्रांसफॉर्मेशन सर्वर-साइड पर होता है, ब्राउज़र कभी भी मूल कोड नहीं देख पाता, और यह त्रुटि किसी सामान्य JavaScript एक्सेप्शन के रूप में सामने नहीं आती।
कौन प्रभावित होता है और उन्हें क्या नुकसान होता है
- साइट मालिक: एक टूटा हुआ कैलकुलेटर या फॉर्म विज़िटर्स को परेशान कर सकता है, बाउंस रेट बढ़ा सकता है और भरोसे को कम कर सकता है।
- डेवलपर्स: "घोस्ट" (ghost) बग्स को खोजने में बिताए गए घंटों में, जो लॉग्स या कंसोल आउटपुट में कोई निशान नहीं छोड़ते।
- कंटेंट एडिटर्स: शॉर्टकोड वाले पेजों को एडिट करते समय अनजाने में फंक्शनलिटी को खराब कर सकते हैं।
इसकी लागत केवल समय नहीं है; यह खोए हुए कन्वर्जन्स (conversions) में बदल सकती है, खासकर उन साइटों पर जो प्राइसिंग, लोन एस्टीमेट या हेल्थ असेसमेंट के लिए कस्टम कैलकुलेटर पर निर्भर करती हैं।
सरल शब्दों में यह फ़िल्टर क्या करता है
- स्ट्रेट कोट्स का पता लगाता है –
'और"को 'स्मार्ट' टाइपोग्राफिक वर्ज़न से बदल देता है। - एम्परसेंड्स को साफ करता है –
&को&में बदल देता है, जब तक कि वह पहले से ही एक वैध HTML एंटिटी न हो। - पूरी कंटेंट स्ट्रिंग पर लागू होता है – जिसमें शॉर्टकोड द्वारा जेनरेट किए गए
<script>टैग के अंदर की कोई भी चीज़ शामिल है।
जब फ़िल्टर को && मिलता है, तो वह दो एम्परसेंड्स देखता है जो किसी मौजूदा HTML एंटिटी का हिस्सा नहीं हैं, इसलिए वह प्रत्येक को व्यक्तिगत रूप से एस्केप कर देता है, जिसके परिणामस्वरूप && प्राप्त होता है।
इस खराबी को कैसे रोकें
1. उन पेजों के लिए फ़िल्टर बंद करें जिनमें कोड है
add_action( 'template_redirect', function () {
if ( is_page() ) {
remove_filter( 'the_content', 'wptexturize' );
remove_filter( 'widget_text_content', 'wptexturize' );
}
} );
यह स्निपेट केवल पेज टेम्पलेट्स पर wptexturize को डिसेबल करता है, जिससे पोस्ट और अन्य कंटेंट प्रकारों के लिए टाइपोग्राफिक सुधार सुरक्षित रहते हैं। यह विजेट टेक्स्ट से भी फ़िल्टर को हटा देता है, जो इनलाइन स्क्रिप्ट्स का एक माध्यमिक स्रोत हो सकता है।
2. && से बचने के लिए लॉजिक को फिर से लिखें
यदि फ़िल्टर को हटाना उचित नहीं है, तो JavaScript को इस तरह रिफैक्टर करें कि लॉजिकल AND ऑपरेटर की आवश्यकता न पड़े:
// Original
if (a && b) { … }
// Refactored
var ok = a;
if (ok) { ok = b; }
if (ok) { … }
हालांकि इससे कुछ अतिरिक्त लाइनें जुड़ जाती हैं, लेकिन यह उस एम्परसेंड को खत्म कर देता है जो फ़िल्टर को ट्रिगर करता है। यह दृष्टिकोण सरल स्थितियों के लिए काम करता है लेकिन जटिल एक्सप्रेशन के लिए कठिन हो सकता है।
3. सभी स्क्रिप्ट्स को एक्सटर्नलाइज़ करें
सबसे मजबूत समाधान कोड को इनलाइन एम्बेड करने के बजाय JavaScript फाइलों को एनक्यू (enqueue) करना है:
wp_enqueue_script( 'my-calculator', get_template_directory_uri() . '/js/calculator.js', [], null, true );
एनक्यू की गई स्क्रिप्ट्स the_content फ़िल्टर्स को पूरी तरह से बायपास कर देती हैं। उन्हें ब्राउज़र कैशिंग का भी लाभ मिलता है और उन्हें अन्य एसेट्स के साथ मिनिफाई या बंडल किया जा सकता है।
वास्तविक स्थिति में समस्या का पता लगाना
जब कोई स्क्रिप्ट बिना किसी स्पष्ट त्रुटि के चलना बंद कर देती है, तो पेज सोर्स देखें (DOM इंस्पेक्ट नहीं) और & खोजें। यदि आपको यह <script> ब्लॉक के अंदर मिलता है, तो फ़िल्टर ही अपराधी है। यह समस्या कंसोल में दिखाई नहीं देगी क्योंकि ब्राउज़र को पार्स करने के लिए कभी भी सिंटैक्स के रूप में वैध स्क्रिप्ट नहीं मिलती।
दूसरा पक्ष: wptexturize को क्यों बनाए रखें?
wptexturize फ्रंट एंड पर पठनीयता (readability) में सुधार करता है। कर्ली कोट्स और उचित डैश कैरेक्टर्स गद्य को एक पॉलिश लुक देते हैं, और कई साइट मालिक इसे एक अनिवार्य सौंदर्य विशेषता (aesthetic feature) मानते हैं। फ़िल्टर को वैश्विक स्तर पर हटाने से टेक्स्ट अपनी कच्ची, टाइपोग्राफिक रूप से साधारण स्थिति में वापस आ जाएगा।
इसका समाधान चुनिंदा तरीके से अक्षम करना है: फ़िल्टर को केवल वहीं बंद करें जहाँ कोड मौजूद है, या एक कस्टम शॉर्टकोड का उपयोग करें जो स्पष्ट रूप से अपने आउटपुट को texturizing से सुरक्षित चिह्नित करता है। WordPress पहले से ही wp_kses_post और अन्य sanitisation helpers प्रदान करता है; डेवलपर्स दोनों का सर्वोत्तम लाभ उठाने के लिए उन्हें remove_filter कॉल्स के साथ मिला सकते हैं।
आगे क्या ध्यान रखें
WordPress core ने wptexturize में किसी ऐसे बदलाव की घोषणा नहीं की है जो स्वचालित रूप से <script> टैग्स को छूट दे दे। जब तक ऐसा बदलाव नहीं आता, डेवलपर्स को अपने inline code की मैन्युअल रूप से सुरक्षा करनी होगी। फ़िल्टर को context-aware बनाने के किसी भी प्रस्ताव के लिए core development tracker पर नज़र रखें। इस बीच, किसी भी शॉर्टकोड या पेज बिल्डर एलिमेंट का ऑडिट करें जो JavaScript इंजेक्ट करता है और ऊपर दिए गए तीन समाधानों में से किसी एक को लागू करें।
निष्कर्ष: यदि आपकी WordPress साइट inline JavaScript चलाती है, तो सत्यापित करें कि wptexturize चुपचाप इसे फिर से लिख (rewrite) तो नहीं रहा है। एक अकेला escaped ampersand पूरे फीचर को निष्क्रिय कर सकता है, और इसका समाधान आमतौर पर PHP की कुछ लाइनें या बाहरी स्क्रिप्ट (external scripts) पर स्विच करना होता है।