WordPress चा wptexturize फिल्टर इनलाइन JavaScript ला न कळत बिघडवत आहे, ज्यामुळे लॉजिकल && ऑपरेटरचे रूपांतर HTML एंटिटी && मध्ये होत आहे आणि शॉर्टकोडमध्ये चालणारे स्क्रिप्ट्स निकामी होत आहेत.
ही समस्या एका डेव्हलपरला जाणवली जो कॅल्क्युलेटर शॉर्टकोडचा संच मेंटेन करतो. अनेक आठवडे सुरळीत चालल्यानंतर, सबमिट बटणे प्रतिसाद देणे थांबले. कोणताही PHP वॉर्निंग किंवा कन्सोल एरर नव्हता, आणि इन्स्पेक्ट केलेला HTML देखील व्यवस्थित दिसत होता—जोपर्यंत रेंडर केलेल्या सोर्समध्ये if (!isNaN(bf) && bf > 0) असे दिसून आले नाही. या एका सिंटॅक्स एररमुळे संपूर्ण स्क्रिप्ट ब्लॉक कार्यान्वित होण्यास अडथळा निर्माण झाला.
हा फिल्टर का महत्त्वाचा आहे
ब्राउझरपर्यंत पोहोचण्यापूर्वी WordPress पोस्ट कंटेंटवर विविध फिल्टर्स प्रक्रिया करते. wptexturize हा त्यातील पहिला फिल्टर आहे; तो सरळ अवतरण चिन्हांचे (straight quotes) रूपांतर टायपोग्राफिक वक्र अवतरण चिन्हांमध्ये (curly quotes) करतो, अनेक हायफनच्या जागी em-dashes वापरतो आणि अँपर्संड्स (ampersands) सॅनिटाइज करतो. हा फिल्टर असे गृहीत धरतो की तो गद्य (prose) हाताळत आहे, कोड नाही. जेव्हा एखादा शॉर्टकोड इनलाइन <script> टॅग समाविष्ट करतो, तेव्हा हा फिल्टर अजूनही चालतो आणि JavaScript ला सामान्य मजकूर समजतो. त्यामुळे && मधील अँपर्संड & मध्ये बदलला जातो, ज्याचा ब्राउझर लॉजिकल AND ऑपरेटरऐवजी एक सामान्य स्ट्रिंग म्हणून अर्थ लावतो.
जे डेव्हलपर्स पोस्ट कंटेंटमध्ये थेट JavaScript एम्बेड करतात—जसे की कॅल्क्युलेटर, फॉर्म व्हॅलिडेटर्स, इंटरअॅक्टिव्ह विजेट्स—ते याला बळी पडू शकतात. ही समस्या केवळ कॅल्क्युलेटरपुरती मर्यादित नाही; &&, & किंवा तत्सम चिन्हे वापरणारे कोणतेही इनलाइन स्क्रिप्ट खराब होऊ शकतात. ही प्रक्रिया सर्व्हर-साइडवर होत असल्याने, ब्राउझरला मूळ कोड कधीच दिसत नाही आणि ही त्रुटी सामान्य JavaScript एक्सेप्शन (exception) म्हणून समोर येत नाही.
कोणावर परिणाम होतो आणि त्यांचे काय नुकसान होते
- साइट मालक (Site owners): खराब झालेले कॅल्क्युलेटर किंवा फॉर्ममुळे अभ्यागतांना त्रास होऊ शकतो, बाऊन्स रेट वाढू शकतो आणि विश्वास कमी होऊ शकतो.
- डेव्हलपर्स (Developers): लॉग्स किंवा कन्सोल आउटपुटमध्ये कोणताही मागमूस न सोडणाऱ्या “घोस्ट” (ghost) बग्सचा शोध घेण्यात तासनतास वाया जातात.
- कंटेंट एडिटर्स (Content editors): शॉर्टकोड असलेल्या पेजेसचे संपादन करताना नकळत कार्यक्षमता बिघडू शकते.
याचे नुकसान केवळ वेळेचे नाही; विशेषतः किंमत, कर्जाचा अंदाज किंवा आरोग्य तपासणीसाठी कस्टम कॅल्क्युलेटरवर अवलंबून असलेल्या साइट्सवर यामुळे कन्वर्जन (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) { … }
जरी यामुळे काही अतिरिक्त ओळी वाढल्या तरी, यामुळे फिल्टर ट्रिगर करणारा अँपर्संड निघून जातो. हा दृष्टिकोन साध्या अटींसाठी (conditions) उपयुक्त आहे परंतु जटिल अभिव्यक्तींसाठी (complex expressions) तो कठीण होऊ शकतो.
3. सर्व स्क्रिप्ट्स एक्सटर्नलाईज करा
सर्वात प्रभावी उपाय म्हणजे कोड इनलाइन एम्बेड करण्याऐवजी JavaScript फाइल्स एनक्यू (enqueue) करणे:
wp_enqueue_script( 'my-calculator', get_template_directory_uri() . '/js/calculator.js', [], null, true );
एनक्यू केलेल्या स्क्रिप्ट्स the_content फिल्टर्सना पूर्णपणे बायपास करतात. त्यांना ब्राउझर कॅशिंगचाही फायदा होतो आणि त्यांना मिनिफाय (minify) किंवा इतर मालमत्तांसोबत बंडल देखील केले जाऊ शकते.
प्रत्यक्ष परिस्थितीत समस्या कशी ओळखायची
जेव्हा एखादी स्क्रिप्ट स्पष्ट त्रुटींशिवाय चालणे थांबते, तेव्हा पेज सोर्स पहा (DOM इन्स्पेक्टर नाही) आणि & शोधा. जर तुम्हाला ते <script> ब्लॉकच्या आत आढळले, तर हा फिल्टरच दोषी आहे. ही समस्या कन्सोलमध्ये दिसणार नाही कारण ब्राउझरला पार्स करण्यासाठी कधीच सिंटॅक्टिकली वैध (syntactically valid) स्क्रिप्ट मिळत नाही.
प्रतिवाद: wptexturize का ठेवावे?
wptexturize फ्रंट एंडवरील वाचनीयता सुधारते. वक्र अवतरण चिन्हे आणि योग्य डॅश कॅरेक्टर्स गद्याला एक पॉलिश लूक देतात, आणि अनेक साइट मालक याला एक अनिवार्य सौंदर्यात्मक वैशिष्ट्य मानतात. फिल्टर जागतिक स्तरावर (globally) काढून टाकल्यास मजकूर त्याच्या मूळ, टायपोग्राफिकदृष्ट्या साध्या स्थितीत परत येईल.
तडजोड म्हणजे निवडकपणे अक्षम करणे (selective disabling): जिथे कोड आहे तिथेच फिल्टर बंद करा, किंवा असा कस्टम शॉर्टकोड वापरा जो त्याचे आउटपुट 'texturizing' पासून सुरक्षित असल्याचे स्पष्टपणे दर्शवेल. WordPress मध्ये आधीच wp_kses_post आणि इतर सॅनिटायझेशन हेल्पर्स उपलब्ध आहेत; दोन्ही बाजूंचे फायदे मिळवण्यासाठी डेव्हलपर्स ते remove_filter कॉल्ससोबत वापरू शकतात.
पुढे काय पाहावे
WordPress core ने wptexturize मध्ये असा कोणताही बदल जाहीर केलेला नाही ज्यामुळे <script> टॅग्सना आपोआप सूट मिळेल. जोपर्यंत असा बदल येत नाही, तोपर्यंत डेव्हलपर्सना त्यांचा इनलाइन कोड मॅन्युअली सुरक्षित ठेवावा लागेल. फिल्टरला 'context-aware' बनवण्यासाठी काही प्रस्ताव आहेत का, यासाठी कोअर डेव्हलपमेंट ट्रॅकरवर लक्ष ठेवा. तोपर्यंत, JavaScript इंजेक्ट करणाऱ्या कोणत्याही शॉर्टकोड किंवा पेज बिल्डर एलिमेंटची तपासणी (audit) करा आणि वरील तीनपैकी एक उपाय लागू करा.
थोडक्यात सांगायचे तर: जर तुमच्या WordPress साइटवर इनलाइन JavaScript चालत असेल, तर wptexturize ते गुपचूप पुन्हा लिहित नाहीये ना, याची खात्री करा. एक सिंगल एस्केप केलेला अँपर्संड (escaped ampersand) संपूर्ण फीचर निकामी करू शकतो, आणि याचे निराकरण सहसा काही ओळींचा PHP कोड किंवा एक्सटर्नल स्क्रिप्ट्सकडे वळणे हे असते.