WordPress ਦਾ wptexturize ਫਿਲਟਰ ਚੁੱਪਚਾਪ ਇਨਲਾਈਨ JavaScript ਨੂੰ ਵਿਗਾੜ ਰਿਹਾ ਹੈ, ਜਿਸ ਨਾਲ ਲੌਜੀਕਲ && ਆਪਰੇਟਰ HTML ਐਂਟਿਟੀ && ਵਿੱਚ ਬਦਲ ਰਿਹਾ ਹੈ ਅਤੇ ਸ਼ਾਰਟਕੋਡਾਂ ਦੇ ਅੰਦਰ ਚੱਲਣ ਵਾਲੀਆਂ ਸਕ੍ਰਿਪਟਾਂ ਨੂੰ ਤੋੜ ਰਿਹਾ ਹੈ।
ਇਹ ਸਮੱਸਿਆ ਇੱਕ ਅਜਿਹੇ ਡਿਵੈਲਪਰ ਲਈ ਸਾਹਮਣੇ ਆਈ ਜੋ ਕੈਲਕੁਲੇਟਰ ਸ਼ਾਰਟਕੋਡਾਂ ਦਾ ਇੱਕ ਸੈੱਟ ਮੇਨਟੇਨ ਕਰਦਾ ਹੈ। ਹਫ਼ਤਿਆਂ ਤੱਕ ਬਿਨਾਂ ਕਿਸੇ ਨੁਕਸ ਦੇ ਚੱਲਣ ਤੋਂ ਬਾਅਦ, ਸਬਮਿਟ ਬਟਨਾਂ ਨੇ ਕੰਮ ਕਰਨਾ ਬੰਦ ਕਰ ਦਿੱਤਾ। ਕੋਈ PHP ਵਾਰਨਿੰਗ ਨਹੀਂ, ਕੋਈ ਕੰਸੋਲ ਐਰਰ ਨਹੀਂ, ਅਤੇ HTML ਇੰਸਪੈਕਟ ਕਰਨ 'ਤੇ ਸਭ ਕੁਝ ਸਾਫ਼ ਸੀ—ਜਦੋਂ ਤੱਕ ਰੈਂਡਰਡ ਸੋਰਸ (rendered source) ਵਿੱਚ if (!isNaN(bf) && bf > 0) ਨਹੀਂ ਦਿਖਿਆ। ਸਿੰਗਲ ਸਿੰਟੈਕਸ ਐਰਰ ਨੇ ਪੂਰੇ ਸਕ੍ਰਿਪਟ ਬਲਾਕ ਨੂੰ ਚੱਲਣ ਤੋਂ ਰੋਕ ਦਿੱਤਾ।
ਫਿਲਟਰ ਕਿਉਂ ਮਹੱਤਵਪੂਰਨ ਹੈ
WordPress ਬ੍ਰਾਊਜ਼ਰ ਤੱਕ ਪਹੁੰਚਣ ਤੋਂ ਪਹਿਲਾਂ ਪੋਸਟ ਕੰਟੈਂਟ ਨੂੰ ਫਿਲਟਰਾਂ ਦੀ ਇੱਕ ਲੜੀ ਰਾਹੀਂ ਪ੍ਰੋਸੈਸ ਕਰਦਾ ਹੈ। wptexturize ਉਹਨਾਂ ਫਿਲਟਰਾਂ ਵਿੱਚੋਂ ਪਹਿਲਾ ਹੈ; ਇਹ ਸਿੱਧੇ ਕੋਟਸ (straight quotes) ਨੂੰ ਟਾਈਪੋਗ੍ਰਾਫਿਕ ਕਰਲੀ ਕੋਟਸ (curly quotes) ਵਿੱਚ ਬਦਲਦਾ ਹੈ, ਕਈ ਹਾਈਫਨਾਂ ਨੂੰ em-dashes ਨਾਲ ਬਦਲਦਾ ਹੈ, ਅਤੇ ਐਂਪਰਸੈਂਡਸ (ampersands) ਨੂੰ ਸਾਫ਼ ਕਰਦਾ ਹੈ। ਇਹ ਫਿਲਟਰ ਇਹ ਮੰਨ ਕੇ ਚੱਲਦਾ ਹੈ ਕਿ ਇਹ ਗੱਲਬਾਤ (prose) ਨਾਲ ਨਜਿੱਠ ਰਿਹਾ ਹੈ, ਕੋਡ ਨਾਲ ਨਹੀਂ। ਜਦੋਂ ਕੋਈ ਸ਼ਾਰਟਕੋਡ ਇਨਲਾਈਨ <script> ਟੈਗ ਇੰਜੈਕਟ ਕਰਦਾ ਹੈ, ਤਾਂ ਫਿਲਟਰ ਫਿਰ ਵੀ ਚੱਲਦਾ ਹੈ, ਅਤੇ JavaScript ਨੂੰ ਆਮ ਟੈਕਸਟ ਵਾਂਗ ਮੰਨ ਲੈਂਦਾ ਹੈ। ਇਸ ਲਈ && ਵਿੱਚ ਐਂਪਰਸੈਂਡ & ਵਜੋਂ ਐਸਕੇਪ (escape) ਹੋ ਜਾਂਦਾ ਹੈ, ਜਿਸ ਨੂੰ ਬ੍ਰਾਊਜ਼ਰ ਲੌਜੀਕਲ AND ਆਪਰੇਟਰ ਦੀ ਬਜਾਏ ਇੱਕ ਲਿਟਰਲ ਸਟ੍ਰਿੰਗ ਵਜੋਂ ਇੰਟਰਪ੍ਰੇਟ ਕਰਦਾ ਹੈ।
ਉਹ ਡਿਵੈਲਪਰ ਜੋ ਪੋਸਟ ਕੰਟੈਂਟ ਵਿੱਚ ਸਿੱਧੇ ਤੌਰ 'ਤੇ ਕੋਈ ਵੀ JavaScript ਇਨਬੈਡ ਕਰਦੇ ਹਨ—ਜਿਵੇਂ ਕੈਲਕੁਲੇਟਰ, ਫਾਰਮ ਵੈਲੀਡੇਟਰ, ਇੰਟਰਐਕਟਿਵ ਵਿਜੇਟ—ਉਹ ਖਤਰੇ ਵਿੱਚ ਹਨ। ਇਹ ਸਮੱਸਿਆ ਸਿਰਫ਼ ਕੈਲਕੁਲੇਟਰਾਂ ਤੱਕ ਸੀਮਤ ਨਹੀਂ ਹੈ; ਕੋਈ ਵੀ ਇਨਲਾਈਨ ਸਕ੍ਰਿਪਟ ਜੋ &&, &, ਜਾਂ ਇਸ ਤਰ੍ਹਾਂ ਦੇ ਚਰਿੱਤਰਾਂ ਦੀ ਵਰਤੋਂ ਕਰਦੀ ਹੈ, ਖਰਾਬ ਹੋ ਸਕਦੀ ਹੈ। ਕਿਉਂਕਿ ਇਹ ਤਬਦੀਲੀ ਸਰਵਰ-ਸਾਈਡ 'ਤੇ ਹੁੰਦੀ ਹੈ, ਬ੍ਰਾਊਜ਼ਰ ਕਦੇ ਵੀ ਅਸਲ ਕੋਡ ਨਹੀਂ ਦੇਖਦਾ, ਅਤੇ ਇਹ ਐਰਰ ਕਿਸੇ ਆਮ JavaScript ਐਕਸੈਪਸ਼ਨ ਵਜੋਂ ਸਾਹਮਣੇ ਨਹੀਂ ਆਉਂਦਾ।
ਕੌਣ ਪ੍ਰਭਾਵਿਤ ਹੁੰਦਾ ਹੈ ਅਤੇ ਉਹ ਕੀ ਗੁਆਉਂਦੇ ਹਨ
- Site owners: ਇੱਕ ਟੁੱਟਿਆ ਹੋਇਆ ਕੈਲਕੁਲੇਟਰ ਜਾਂ ਫਾਰਮ ਵਿਜ਼ਿਟਰਾਂ ਨੂੰ ਨਿਰਾਸ਼ ਕਰ ਸਕਦਾ ਹੈ, ਬਾਊਂਸ ਰੇਟ ਵਧਾ ਸਕਦਾ ਹੈ, ਅਤੇ ਭਰੋਸਾ ਘਟਾ ਸਕਦਾ ਹੈ।
- Developers: ਉਹ ਘੰਟੇ ਜੋ "ਗੋਸਟ" (ghost) ਬੱਗਾਂ ਨੂੰ ਲੱਭਣ ਵਿੱਚ ਬੀਤਦੇ ਹਨ ਜੋ ਲੌਗਸ ਜਾਂ ਕੰਸੋਲ ਆਉਟਪੁੱਟ ਵਿੱਚ ਕੋਈ ਨਿਸ਼ਾਨ ਨਹੀਂ ਛੱਡਦੇ।
- Content editors: ਸ਼ਾਰਟਕੋਡਾਂ ਵਾਲੇ ਪੇਜਾਂ ਨੂੰ ਐਡਿਟ ਕਰਦੇ ਸਮੇਂ ਅਣਜਾਣੇ ਵਿੱਚ ਫੰਕਸ਼ਨੈਲਿਟੀ ਨੂੰ ਖਰਾਬ ਕਰ ਸਕਦੇ ਹਨ।
ਇਸਦੀ ਕੀਮਤ ਸਿਰਫ਼ ਸਮਾਂ ਨਹੀਂ ਹੈ; ਇਹ ਕਨਵਰਸ਼ਨਾਂ ਦੇ ਨੁਕਸਾਨ ਵਿੱਚ ਬਦਲ ਸਕਦੀ ਹੈ, ਖਾਸ ਕਰਕੇ ਉਹਨਾਂ ਸਾਈਟਾਂ 'ਤੇ ਜੋ ਕੀਮਤਾਂ, ਲੋਨ ਅਨੁਮਾਨਾਂ, ਜਾਂ ਸਿਹਤ ਮੁਲਾਂਕਣਾਂ ਲਈ ਕਸਟਮ ਕੈਲਕੁਲੇਟਰਾਂ 'ਤੇ ਨਿਰਭਰ ਕਰਦੀਆਂ ਹਨ।
ਫਿਲਟਰ ਕੀ ਕਰਦਾ ਹੈ, ਸਰਲ ਸ਼ਬਦਾਂ ਵਿੱਚ
- ਸਿੱਧੇ ਕੋਟਸ ਦੀ ਪਛਾਣ ਕਰਦਾ ਹੈ –
'ਅਤੇ"ਨੂੰ 'ਸਮਾਰਟ' ਟਾਈਪੋਗ੍ਰਾਫਿਕ ਵਰਜ਼ਨਾਂ ਨਾਲ ਬਦਲਦਾ ਹੈ। - ਐਂਪਰਸੈਂਡਸ ਨੂੰ ਸਾਫ਼ ਕਰਦਾ ਹੈ –
&ਨੂੰ&ਵਿੱਚ ਬਦਲਦਾ ਹੈ, ਜਦੋਂ ਤੱਕ ਕਿ ਇਹ ਪਹਿਲਾਂ ਹੀ ਇੱਕ ਵੈਧ 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 ਨੂੰ ਇਸ ਤਰ੍ਹਾਂ ਰੀਫੈਕਟਰ (refactor) ਕਰੋ ਕਿ ਲੌਜੀਕਲ AND ਆਪਰੇਟਰ ਦੀ ਲੋੜ ਨਾ ਪਵੇ:
// Original
if (a && b) { … }
// Refactored
var ok = a;
if (ok) { ok = b; }
if (ok) { … }
ਹਾਲਾਂਕਿ ਇਹ ਕੁਝ ਵਾਧੂ ਲਾਈਨਾਂ ਜੋੜਦਾ ਹੈ, ਪਰ ਇਹ ਉਸ ਐਂਪਰਸੈਂਡ ਨੂੰ ਖਤਮ ਕਰ ਦਿੰਦਾ ਹੈ ਜੋ ਫਿਲਟਰ ਨੂੰ ਟ੍ਰਿਗਰ ਕਰਦਾ ਹੈ। ਇਹ ਪਹੁੰਚ ਸਧਾਰਨ ਸ਼ਰਤਾਂ ਲਈ ਕੰਮ ਕਰਦੀ ਹੈ ਪਰ ਗੁੰਝਲਦਾਰ ਐਕਸਪ੍ਰੈਸ਼ਨਾਂ ਲਈ ਮੁਸ਼ਕਲ ਹੋ ਸਕਦੀ ਹੈ।
3. ਸਾਰੀਆਂ ਸਕ੍ਰਿਪਟਾਂ ਨੂੰ ਬਾਹਰੀ (Externalise) ਕਰੋ
ਸਭ ਤੋਂ ਮਜ਼ਬੂਤ ਹੱਲ ਕੋਡ ਨੂੰ ਇਨਲਾਈਨ ਇਨਬੈਡ ਕਰਨ ਦੀ ਬਜਾਏ JavaScript ਫਾਈਲਾਂ ਨੂੰ ਇਨਕਿਊ (enqueue) ਕਰਨਾ ਹੈ:
wp_enqueue_script( 'my-calculator', get_template_directory_uri() . '/js/calculator.js', [], null, true );
ਇਨਕਿਊ ਕੀਤੀਆਂ ਸਕ੍ਰਿਪਟਾਂ the_content ਫਿਲਟਰਾਂ ਨੂੰ ਪੂਰੀ ਤਰ੍ਹਾਂ ਬਾਈਪਾਸ ਕਰ ਦਿੰਦੀਆਂ ਹਨ। ਉਹਨਾਂ ਨੂੰ ਬ੍ਰਾਊਜ਼ਰ ਕੈਸ਼ਿੰਗ ਦਾ ਵੀ ਲਾਭ ਮਿਲਦਾ ਹੈ ਅਤੇ ਉਹਨਾਂ ਨੂੰ ਹੋਰ ਐਸੇਟਸ ਦੇ ਨਾਲ ਮਿਨੀਫਾਈ (minify) ਜਾਂ ਬੰਡਲ ਕੀਤਾ ਜਾ ਸਕਦਾ ਹੈ।
ਅਸਲ ਵਰਤੋਂ ਵਿੱਚ ਸਮੱਸਿਆ ਦੀ ਪਛਾਣ ਕਰਨਾ
ਜਦੋਂ ਕੋਈ ਸਕ੍ਰਿਪਟ ਬਿਨਾਂ ਕਿਸੇ ਸਪੱਸ਼ਟ ਐਰਰ ਦੇ ਚੱਲਣੀ ਬੰਦ ਹੋ ਜਾਂਦੀ ਹੈ, ਤਾਂ ਪੇਜ ਸੋਰਸ (DOM ਇੰਸਪੈਕਟਰ ਨਹੀਂ) ਦੇਖੋ ਅਤੇ & ਲਈ ਸਰਚ ਕਰੋ। ਜੇਕਰ ਤੁਹਾਨੂੰ ਇਹ <script> ਬਲਾਕ ਦੇ ਅੰਦਰ ਮਿਲਦਾ ਹੈ, ਤਾਂ ਫਿਲਟਰ ਹੀ ਦੋਸ਼ੀ ਹੈ। ਇਹ ਸਮੱਸਿਆ ਕੰਸੋਲ ਵਿੱਚ ਦਿਖਾਈ ਨਹੀਂ ਦੇਵੇਗੀ ਕਿਉਂਕਿ ਬ੍ਰਾਊਜ਼ਰ ਨੂੰ ਪਾਰਸ (parse) ਕਰਨ ਲਈ ਕਦੇ ਵੀ ਸਿੰਟੈਕਟਿਕਲੀ ਵੈਧ ਸਕ੍ਰਿਪਟ ਨਹੀਂ ਮਿਲਦੀ।
ਵਿਰੋਧੀ ਪੱਖ: wptexturize ਨੂੰ ਕਿਉਂ ਰੱਖਿਆ ਜਾਵੇ?
wptexturize ਫਰੰਟ ਐਂਡ 'ਤੇ ਪੜ੍ਹਨਯੋਗਤਾ (readability) ਵਿੱਚ ਸੁਧਾਰ ਕਰਦਾ ਹੈ। ਕਰਲੀ ਕੋਟਸ ਅਤੇ ਸਹੀ ਡੈਸ਼ ਚਰਿੱਤਰ ਗੱਲਬਾਤ ਨੂੰ ਇੱਕ ਪਾਲਿਸ਼ਡ ਲੁੱਕ ਦਿੰਦੇ ਹਨ, ਅਤੇ ਬਹੁਤ ਸਾਰੇ ਸਾਈਟ ਮਾਲਕ ਇਸਨੂੰ ਇੱਕ ਗੈਰ-ਗੱਲਬਾਤਯੋਗ (non-negotiable) ਸੁੰਦਰਤਾ ਵਿਸ਼ੇਸ਼ਤਾ ਮੰਨਦੇ ਹਨ। ਫਿਲਟਰ ਨੂੰ ਵਿਸ਼ਵਵਿਆਪੀ (globally) ਤੌਰ 'ਤੇ ਹਟਾਉਣ ਨਾਲ ਟੈਕਸਟ ਆਪਣੀ ਕੱਚੀ, ਟਾਈਪੋਗ੍ਰਾਫਿਕਲੀ ਸਾਦੀ ਅਵਸਥਾ ਵਿੱਚ ਵਾਪਸ ਆ ਜਾਵੇਗਾ।
The compromise is selective disabling: turn the filter off only where code lives, or use a custom shortcode that explicitly marks its output as safe from texturizing. WordPress already provides wp_kses_post and other sanitisation helpers; developers can combine those with remove_filter calls to keep the best of both worlds.
What to watch next
WordPress core has not announced a change to wptexturize that would automatically exempt <script> tags. Until such a change lands, developers must guard their inline code manually. Keep an eye on the core development tracker for any proposals to make the filter context-aware. In the meantime, audit any shortcode or page builder element that injects JavaScript and apply one of the three fixes above.
Bottom line: if your WordPress site runs inline JavaScript, verify that wptexturize isn’t silently rewriting it. A single escaped ampersand can render an entire feature inert, and the fix is usually a few lines of PHP or a shift to external scripts.