WordPress کا wptexturize فلٹر خاموشی سے ان لائن JavaScript کو خراب کر رہا ہے، جس سے منطقی && آپریٹر HTML اینٹیٹی && میں تبدیل ہو جاتا ہے اور شارٹ کوڈز کے اندر چلنے والے اسکرپٹس کام کرنا چھوڑ دیتے ہیں۔
یہ مسئلہ ایک ایسے ڈویلپر کے سامنے آیا جو کیلکولیٹر شارٹ کوڈز کا ایک سیٹ برقرار رکھتا ہے۔ ہفتوں تک بہترین کام کرنے کے بعد، سبمٹ بٹنوں نے جواب دینا بند کر دیا۔ کوئی PHP وارننگ نہیں، کوئی کنسول ایرر نہیں، اور HTML کا معائنہ کرنے پر سب کچھ ٹھیک نظر آیا—جب تک کہ رینڈر شدہ سورس (rendered source) میں if (!isNaN(bf) && bf > 0) ظاہر نہیں ہوا۔ صرف ایک سنٹیکس ایرر نے پورے اسکرپٹ بلاک کو چلنے سے روک دیا۔
یہ فلٹر کیوں اہم ہے
WordPress براؤزر تک پہنچنے سے پہلے پوسٹ کے مواد کو فلٹرز کے ایک سلسلے کے ذریعے پروسیس کرتا ہے۔ wptexturize ان فلٹرز میں سے پہلا ہے؛ یہ سیدھے کوٹس (straight quotes) کو ٹائپوگرافک کرلی کوٹس (typographic curly quotes) میں تبدیل کرتا ہے، متعدد ہائفنز کو ایم-ڈیشز (em-dashes) سے بدلتا ہے، اور ایمپرسینڈز (ampersands) کو صاف کرتا ہے۔ یہ فلٹر یہ فرض کرتا ہے کہ وہ نثر (prose) کے ساتھ نمٹ رہا ہے، کوڈ کے ساتھ نہیں۔ جب کوئی شارٹ کوڈ ان لائن <script> ٹیگ شامل کرتا ہے، تو فلٹر پھر بھی چلتا ہے، اور JavaScript کو عام متن سمجھتا ہے۔ اس لیے && میں موجود ایمپرسینڈ کو & میں تبدیل کر دیا جاتا ہے، جسے براؤزر منطقی AND آپریٹر کے بجائے ایک لفظی اسٹرنگ (literal string) کے طور پر سمجھتا ہے۔
وہ ڈویلپرز جو پوسٹ کے مواد میں براہ راست کوئی بھی JavaScript شامل کرتے ہیں—جیسے کیلکولیٹرز، فارم ویلیڈیٹرز، انٹرایکٹو ویجٹس—وہ اس خطرے میں ہیں۔ یہ مسئلہ صرف کیلکولیٹرز تک محدود نہیں ہے؛ کوئی بھی ان لائن اسکرپٹ جو &&، & یا اسی طرح کے کردار استعمال کرتا ہے، خراب ہو سکتا ہے۔ چونکہ یہ تبدیلی سرور سائیڈ پر ہوتی ہے، اس لیے براؤزر کبھی اصل کوڈ نہیں دیکھ پاتا، اور یہ غلطی عام JavaScript exception کے طور پر سامنے نہیں آتی۔
کون متاثر ہوتا ہے اور انہیں کیا نقصان ہوتا ہے
- سائٹ کے مالکان: ایک خراب کیلکولیٹر یا فارم وزٹرز کو پریشان کر سکتا ہے، باؤنس ریٹ (bounce rates) بڑھا سکتا ہے، اور اعتماد کو کم کر سکتا ہے۔
- ڈویلپرز: "گھوسٹ" (ghost) بگز کی تلاش میں گزرے ہوئے گھنٹوں، جو لاگز یا کنسول آؤٹ پٹ میں کوئی نشان نہیں چھوڑتے۔
- کنٹینٹ ایڈیٹرز: شارٹ کوڈز پر مشتمل صفحات کی ایڈیٹنگ کے دوران نادانستہ طور پر فنکشنلٹی کو خراب کر سکتے ہیں۔
اس کی قیمت صرف وقت نہیں ہے؛ یہ کم ہونے والی کنورژنز (conversions) میں بھی بدل سکتی ہے، خاص طور پر ان سائٹس پر جو قیمتوں، قرض کے تخمینوں، یا صحت کے جائزے کے لیے کسٹم کیلکولیٹرز پر انحصار کرتی ہیں۔
یہ فلٹر کیا کرتا ہے، سادہ الفاظ میں
- سیدھے کوٹس کی شناخت کرتا ہے –
'اور"کو 'اسمارٹ' ٹائپوگرافک ورژنز سے بدل دیتا ہے۔ - ایمپرسینڈز کو صاف کرتا ہے –
&کو&میں تبدیل کرتا ہے جب تک کہ وہ پہلے سے ہی ایک درست HTML اینٹیٹی نہ ہو۔ - پورے مواد کی اسٹرنگ پر لاگو ہوتا ہے – بشمول شارٹ کوڈز کے ذریعے تیار کردہ
<script>ٹیگز کے اندر موجود ہر چیز۔
جب فلٹر کو && ملتا ہے، تو وہ دو ایمپرسینڈز دیکھتا ہے جو کسی موجودہ HTML اینٹیٹی کا حصہ نہیں ہوتے، اس لیے وہ ہر ایک کو انفرادی طور پر اسکیپ (escape) کر دیتا ہے، جس کے نتیجے میں && بن جاتا ہے۔
خرابی کو کیسے روکیں
1. ان صفحات کے لیے فلٹر بند کریں جن میں کوڈ موجود ہو
add_action( 'template_redirect', function () {
if ( is_page() ) {
remove_filter( 'the_content', 'wptexturize' );
remove_filter( 'widget_text_content', 'wptexturize' );
}
} );
یہ اسنیپٹ صرف پیج ٹیمپلیٹس پر wptexturize کو غیر فعال کرتا ہے، پوسٹس اور دیگر مواد کی اقسام کے لیے ٹائپوگرافک بہتری کو برقرار رکھتا ہے۔ یہ ویجٹ ٹیکسٹ سے بھی فلٹر کو ہٹا دیتا ہے، جو ان لائن اسکرپٹس کا ثانوی ذریعہ ہو سکتا ہے۔
2. && سے بچنے کے لیے لاجک کو دوبارہ لکھیں
اگر فلٹر کو ہٹانا مناسب نہ ہو، تو JavaScript کو اس طرح ری فیکٹر (refactor) کریں کہ منطقی AND آپریٹر کی ضرورت نہ رہے:
// Original
if (a && b) { … }
// Refactored
var ok = a;
if (ok) { ok = b; }
if (ok) { … }
اگرچہ اس سے چند اضافی لائنیں بڑھ جاتی ہیں، لیکن یہ اس ایمپرسینڈ کو ختم کر دیتا ہے جو فلٹر کو ٹرگر کرتا ہے۔ یہ طریقہ سادہ شرائط کے لیے تو کام کرتا ہے لیکن پیچیدہ ایکسپریشنز (expressions) کے لیے مشکل ہو سکتا ہے۔
3. تمام اسکرپٹس کو بیرونی (externalise) بنائیں
سب سے مضبوط حل کوڈ کو ان لائن شامل کرنے کے بجائے JavaScript فائلوں کو انکیو (enqueue) کرنا ہے:
wp_enqueue_script( 'my-calculator', get_template_directory_uri() . '/js/calculator.js', [], null, true );
انکیو شدہ اسکرپٹس the_content فلٹرز کو مکمل طور پر نظر انداز کر دیتے ہیں۔ انہیں براؤزر کیشنگ کا بھی فائدہ ملتا ہے اور انہیں دیگر اثاثوں (assets) کے ساتھ منٹیفائی (minify) یا بنڈل بھی کیا جا سکتا ہے۔
مسئلے کی نشاندہی کیسے کریں
جب کوئی اسکرپٹ واضح غلطیوں کے بغیر چلنا بند ہو جائے، تو پیج سورس (DOM انسپکٹر کے بجائے) دیکھیں اور & تلاش کریں۔ اگر آپ اسے <script> بلاک کے اندر پاتے ہیں، تو فلٹر ہی اس کا ذمہ دار ہے۔ یہ مسئلہ کنسول میں ظاہر نہیں ہوگا کیونکہ براؤزر کو پرز (parse) کرنے کے لیے کبھی بھی سنٹیکس کے لحاظ سے درست اسکرپٹ نہیں ملتا۔
دوسرا پہلو: wptexturize کو کیوں برقرار رکھیں؟
wptexturize فرنٹ اینڈ پر پڑھنے کی صلاحیت (readability) کو بہتر بناتا ہے۔ کرلی کوٹس اور مناسب ڈیش کے کردار نثر کو ایک نکھرا ہوا لک دیتے ہیں، اور بہت سے سائٹ کے مالکان اسے ایک لازمی جمالیاتی خصوصیت سمجھتے ہیں۔ فلٹر کو عالمی سطح پر (globally) ہٹانے سے متن اپنی خام اور ٹائپوگرافک طور پر سادہ حالت میں واپس آ جائے گا۔
سمجھوتہ منتخب طریقے سے غیر فعال کرنے میں ہے: فلٹر کو صرف وہیں بند کریں جہاں کوڈ موجود ہو، یا ایک ایسا کسٹم شارٹ کوڈ استعمال کریں جو واضح طور پر اس کے آؤٹ پٹ کو ٹیکسٹورائزنگ سے محفوظ قرار دے۔ WordPress پہلے سے ہی wp_kses_post اور دیگر سینٹائزیشن ہیلپرز فراہم کرتا ہے؛ ڈویلپرز دونوں فوائد حاصل کرنے کے لیے انہیں remove_filter کالز کے ساتھ ملا سکتے ہیں۔
آگے کیا نظر رکھنا ہے
WordPress کور نے wptexturize میں ایسی کسی تبدیلی کا اعلان نہیں کیا ہے جو خود بخود <script> ٹیگز کو مستثنیٰ قرار دے دے۔ جب تک ایسی تبدیلی نہیں آتی، ڈویلپرز کو اپنے ان لائن کوڈ کی حفاظت دستی طور پر کرنی ہوگی۔ فلٹر کو کانٹیکسٹ کے مطابق (context-aware) بنانے کی کسی بھی تجویز کے لیے کور ڈویلپمنٹ ٹریکر پر نظر رکھیں۔ اس دوران، کسی بھی ایسے شارٹ کوڈ یا پیج بلڈر ایلیمنٹ کا آڈٹ کریں جو JavaScript شامل کرتا ہے اور اوپر دیے گئے تینوں حلوں میں سے کوئی ایک لاگو کریں۔
بنیادی بات: اگر آپ کی WordPress سائٹ ان لائن JavaScript چلاتی ہے، تو اس بات کی تصدیق کریں کہ wptexturize خاموشی سے اسے دوبارہ نہیں لکھ رہا۔ ایک واحد ایسکیپڈ (escaped) ایمپرسینڈ (ampersand) پورے فیچر کو غیر فعال کر سکتا ہے، اور اس کا حل عام طور پر PHP کی چند لائنیں یا بیرونی اسکرپٹس کی طرف منتقلی ہے۔