PHP 8.x ਅੱਪਡੇਟ ਤੋਂ ਬਾਅਦ WordPress ਪਲੱਗਇਨ ਅਸੰਗਤੀ ਦੀਆਂ ਗਲਤੀਆਂ ਨੂੰ ਸੁਧਾਰਨਾ

PHP 8.x ਅੱਪਡੇਟ ਤੋਂ ਬਾਅਦ WordPress ਪਲੱਗਇਨ ਅਸੰਗਤੀ ਦੀਆਂ ਗਲਤੀਆਂ ਨੂੰ ਸੁਧਾਰਨਾ ਦੀ ਪ੍ਰਕਿਰਿਆ ਵਿੱਚ ਗਲਤੀ ਨੂੰ ਦਿਖਾਉਣਾ, ਬੈਕਅਪ ਲੈਣਾ, ਪਲੱਗਇਨਾਂ ਨੂੰ ਇਕ-ਇੱਕ ਕਰਕੇ ਪਰਖਣਾ, ਅਸੰਗਤ ਪਲੱਗਇਨ ਨੂੰ ਅੱਪਡੇਟ ਕਰਨਾ ਜਾਂ ਵਿਕਲਪ ਨਾਲ ਬਦਲਣਾ, ਜੇ ਲੋੜ ਹੋਵੇ ਤਾਂ PHP ਦੇ ਵਰਜਨ ਨੂੰ ਅਸਥਾਈ ਤੌਰ 'ਤੇ ਵਾਪਸ ਲੈਣਾ ਸ਼ਾਮਲ ਹੈ। ਸਫੇਦ ਸਕ੍ਰੀਨ, ਸੰਕਟ ਗਲਤੀ, 500 ਗਲਤੀ, ਫੇਟਲ ਗਲਤੀ, Deprecated ਚੇਤਾਵਣੀਆਂ ਜਾਂ ਪ੍ਰਬੰਧਨ ਪੈਨਲ ਵਿੱਚ ਪਹੁੰਚ ਨਾ ਹੋਣ ਵਰਗੀਆਂ ਸਮੱਸਿਆਵਾਂ ਵਿੱਚ ਸਭ ਤੋਂ ਸੁਰੱਖਿਅਤ ਢੰਗ ਇਹ ਹੈ ਕਿ ਸਿੱਧੇ ਤੌਰ 'ਤੇ ਜੀਵੰਤ ਸਾਈਟ 'ਤੇ ਦਖਲ ਦੇਣ ਦੇ ਬਜਾਏ ਸਟੇਜਿੰਗ ਮਾਹੌਲ ਵਿੱਚ ਪਰਖ ਕਰਨਾ, ਗਲਤੀ ਦੀਆਂ ਡਾਇਰੀਆਂ ਨੂੰ ਜਾਂਚਣਾ ਅਤੇ ਬਦਲਾਵਾਂ ਨੂੰ ਕੰਟਰੋਲ ਕੀਤੇ ਤਰੀਕੇ ਨਾਲ ਲਾਗੂ ਕਰਨਾ ਹੈ।

PHP 8.x, WordPress ਸਾਈਟਾਂ ਲਈ ਗੰਭੀਰ ਪ੍ਰਦਰਸ਼ਨ ਅਤੇ ਸੁਰੱਖਿਆ ਦੇ ਫਾਇਦੇ ਪ੍ਰਦਾਨ ਕਰਦਾ ਹੈ; ਪਰ ਇਹ ਪੁਰਾਣੇ ਕੋਡਿੰਗ ਮਿਆਰਾਂ ਨਾਲ ਲਿਖੇ ਥੀਮ ਜਾਂ ਪਲੱਗਇਨਾਂ ਵਿੱਚ ਅਸੰਗਤੀਆਂ ਨੂੰ ਵੀ ਦਿਖਾਉਂਦਾ ਹੈ। ਖਾਸ ਤੌਰ 'ਤੇ PHP 7.4 ਅਤੇ ਇਸ ਤੋਂ ਪਹਿਲਾਂ ਸਿਰਫ ਚੇਤਾਵਣੀਆਂ ਦੇਣ ਵਾਲੇ ਕੁਝ ਕੋਡ PHP 8.x ਨਾਲ ਮੌਤ ਦਾ ਗਲਤੀ ਬਣ ਸਕਦੇ ਹਨ। ਇਸ ਲਈ PHP ਦੇ ਉੱਚਵੇਲੇ ਨੂੰ ਸਿਰਫ ਇੱਕ ਵਰਜਨ ਬਦਲਣਾ ਨਹੀਂ ਬਲਕਿ ਤੁਹਾਡੇ WordPress ਈਕੋਸਿਸਟਮ ਦੀ ਗੁਣਵੱਤਾ ਨਿਯੰਤਰਣ ਪ੍ਰਕਿਰਿਆ ਵੀ ਹੈ।

ਇਸ ਗਾਈਡ ਵਿੱਚ, ਅਸੀਂ Hostragons ਬਲੌਗ ਦੇ ਪਾਠਕਾਂ ਲਈ ਹਕੀਕਤੀ ਜੀਵਨ ਵਿੱਚ ਸਭ ਤੋਂ ਆਮ ਦਰਸ਼ਨਾਂ ਦੇ ਆਧਾਰ 'ਤੇ ਲਾਗੂ ਕਰਨ ਯੋਗ ਹੱਲ ਦਾ ਇੱਕ ਪ੍ਰਵਾਹ ਤਿਆਰ ਕੀਤਾ ਹੈ। ਉਦੇਸ਼ ਸਿਰਫ ਸਾਈਟ ਨੂੰ ਮੁੜ ਖੋਲ੍ਹਣਾ ਨਹੀਂ ਹੈ; ਇਸੇ ਗਲਤੀ ਦੇ ਬਾਅਦ ਦੇ PHP, WordPress ਜਾਂ ਪਲੱਗਇਨ ਅੱਪਡੇਟਾਂ ਵਿੱਚ ਮੁੜ ਨਾ ਹੋਣ ਦਾ ਇੱਕ ਟਿਕਾਊ ਸੰਭਾਲ ਪ੍ਰਣਾਲੀ ਬਣਾਉਣਾ ਹੈ। ਇੱਕ ਯੋਗ WordPress ਹੋਸਟਿੰਗ ਢਾਂਚਾ ਚੁਣਨਾ, PHP ਦੇ ਵਰਜਨਾਂ ਨੂੰ ਪ੍ਰਬੰਧਿਤ ਕਰਨਾ ਅਤੇ ਨਿਯਮਤ ਬੈਕਅਪ ਲੈਣਾ ਇਸ ਪ੍ਰਕਿਰਿਆ ਦਾ ਮੂਲ ਹੈ। ਇਸ ਮੋੜ 'ਤੇ WordPress ਹੋਸਟਿੰਗ ਪੈਕੇਜ ਅਤੇ ਵੈਬ ਹੋਸਟਿੰਗ ਸੇਵਾਵਾਂ ਜਿਹੇ ਸਰੋਤ ਫੈਸਲੇ ਦੇ ਪੜਾਅ ਵਿੱਚ ਮਦਦਗਾਰ ਹੋ ਸਕਦੇ ਹਨ।

PHP 8.x ਦੇ ਬਾਅਦ WordPress ਪਲੱਗਇਨ ਅਸੰਗਤੀ ਕਿਉਂ ਹੁੰਦੀ ਹੈ?

PHP 8.0, 8.1, 8.2 ਅਤੇ 8.3 ਵਰਜਨ; ਟਾਈਪ ਚੈੱਕਿੰਗ, ਗਲਤੀ ਫੜਨ ਵਾਲਾ ਵਿਵਹਾਰ, ਬੇਵਜ੍ਹਾ ਫੰਕਸ਼ਨਾਂ ਨੂੰ ਹਟਾਉਣਾ ਅਤੇ ਪ੍ਰਦਰਸ਼ਨ ਸੁਧਾਰਾਂ ਦੇ ਮਾਮਲੇ ਵਿੱਚ ਪਿਛਲੇ ਵਰਜਨਾਂ ਨਾਲੋਂ ਜ਼ਿਆਦਾ ਕਠੋਰ ਹਨ। WordPress ਕੋਰ ਨੂੰ ਆਧੁਨਿਕ PHP ਵਰਜਨਾਂ ਨਾਲ ਅਨੁਕੂਲ ਬਣਾਉਣ ਲਈ ਲਗਾਤਾਰ ਵਿਕਸਤ ਕੀਤਾ ਜਾ ਰਿਹਾ ਹੈ, ਪਰ ਸਾਰੇ ਪਲੱਗਇਨ ਅਤੇ ਥੀਮਾਂ ਇੱਕੇ ਸਮੇਂ 'ਤੇ ਅੱਪਡੇਟ ਨਹੀਂ ਹੁੰਦੀਆਂ। ਸਮੱਸਿਆ ਆਮ ਤੌਰ 'ਤੇ WordPress ਕੋਰ ਤੋਂ ਨਹੀਂ, ਬਲਕਿ ਲੰਬੇ ਸਮੇਂ ਤੱਕ ਮੁਰੰਮਤ ਨਾ ਕੀਤੇ ਜਾਂਦੇ ਜਾਂ ਪੁਰਾਣੇ PHP ਆਦਤਾਂ ਨਾਲ ਲਿਖੇ ਤੀਜੀ ਪੱਖ ਦੇ ਭਾਗਾਂ ਤੋਂ ਆਉਂਦੀ ਹੈ।

ਉਦਾਹਰਣ ਲਈ, PHP 7.4 'ਤੇ ਕੰਮ ਕਰਨ ਵਾਲੇ ਇੱਕ ਪਲੱਗਇਨ ਵਿੱਚ ਗਲਤ ਪੈਰਾਮੀਟਰ ਕ੍ਰਮ ਸਿਰਫ ਚੇਤਾਵਣੀ ਦੇ ਤੌਰ 'ਤੇ ਲੌਗ ਫਾਇਲ ਵਿੱਚ ਮਿਲਦਾ ਹੈ, ਜਦਕਿ PHP 8.1 'ਤੇ ਉਸੇ ਲਾਈਨ ਨੇ ਫੇਟਲ ਗਲਤੀ ਦਾ ਉਤਪਾਦਨ ਕੀਤਾ। ਇਸੇ ਤਰ੍ਹਾਂ ਪੁਰਾਣੇ ਵਰਜਨਾਂ ਵਿੱਚ ਬਰਦਾਸ਼ਤ ਕੀਤੇ ਗਏ ਨਲ ਮੁੱਲ ਦੀ ਵਰਤੋਂ, PHP 8.x ਨਾਲ TypeError ਗਲਤੀ ਵਿੱਚ ਬਦਲ ਸਕਦੀ ਹੈ। WooCommerce ਭੁਗਤਾਨ ਪਲੱਗਇਨ, ਫਾਰਮ ਪਲੱਗਇਨ, ਪੇਜ ਬਿਲਡਰ, ਸੁਰੱਖਿਆ ਪਲੱਗਇਨ ਅਤੇ ਪੁਰਾਣੇ ਛੋਟੇ ਕੋਡ ਪਲੱਗਇਨਾਂ ਨੂੰ ਇਸ ਸਥਿਤੀ ਤੋਂ ਸਭ ਤੋਂ ਜ਼ਿਆਦਾ ਪ੍ਰਭਾਵਿਤ ਹੋਣ ਵਾਲੀਆਂ ਗਰੁੱਪਾਂ ਵਿੱਚ ਸ਼ਾਮਲ ਕੀਤਾ ਗਿਆ ਹੈ।

ਅਸੰਗਤੀਆਂ ਆਮ ਤੌਰ 'ਤੇ ਹੇਠਾਂ ਦਿੱਤੇ ਕਾਰਨਾਂ ਕਰਕੇ ਉੱਪਜਦੀਆਂ ਹਨ:

• ਪਲੱਗਇਨ ਦੀ ਆਖਰੀ ਅੱਪਡੇਟ 12 ਮਹੀਨਿਆਂ ਤੋਂ ਵੱਧ ਹੋ ਜਾਣਾ ਅਤੇ ਸੁਰੱਖਿਅਤ ਮੁਰੰਮਤ ਨਾ ਹੋਣਾ।
• ਪਲੱਗਇਨ ਦੇ PHP 8.x ਅਨੁਕੂਲਤਾ ਜਾਣਕਾਰੀ WordPress ਪਲੱਗਇਨ ਪੰਨੇ 'ਤੇ ਦਰਸਾਈ ਨਹੀਂ ਗਈ।
• ਥੀਮ ਅਤੇ ਪਲੱਗਇਨ ਵੱਖਰੇ ਤਰੀਕੇ ਨਾਲ ਇਕੋ ਫੰਕਸ਼ਨਾਂ ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਹਨ।
• ਖਾਸ ਤੌਰ 'ਤੇ ਲਿਖੇ functions.php ਕੋਡਾਂ ਵਿੱਚ ਪੁਰਾਣਾ PHP ਸਿੰਟੈਕਸ ਸ਼ਾਮਲ ਹੁੰਦਾ ਹੈ।
• ਸਰਵਰ 'ਤੇ ਸਰਗਰਮ PHP ਪਲੱਗਇਨਾਂ, ਜਿਵੇਂ ਕਿ ionCube, mbstring ਜਾਂ imagick ਮੋਡੀਊਲ ਦੀ ਕਮੀ ਹੋਣਾ।
• ਕੈਸ਼, ਸੁਰੱਖਿਆ ਦੀਆਂ ਕੰਨੈਕਸ਼ਨ ਜਾਂ ਅਪਟਿਮਾਈਜ਼ੇਸ਼ਨ ਪਲੱਗਇਨਾਂ ਦੇ ਪੁਰਾਣੇ ਸੈਟਿੰਗਾਂ ਨਾਲ ਟਕਰਾਉਣਾ।

ਲੱਛਣਾਂ ਦੇ ਆਧਾਰ 'ਤੇ ਤੇਜ਼ ਪਛਾਣ ਦੀ ਟੇਬਲ

ਹੇਠਾਂ ਦਿੱਤੀ ਟੇਬਲ, PHP 8.x ਅੱਪਡੇਟ ਦੇ ਬਾਅਦ ਦੇਖੀਆਂ ਜਾਣ ਵਾਲੀਆਂ ਆਮ WordPress ਪਲੱਗਇਨ ਗਲਤੀਆਂ ਨੂੰ ਤੇਜ਼ੀ ਨਾਲ ਵਰਗਬੱਧ ਕਰਨ ਵਿੱਚ ਮਦਦ ਕਰਦੀ ਹੈ। ਇਹ ਟੇਬਲ ਨਿਸ਼ਚਿਤ ਪਛਾਣ ਬਦਲਣ ਦੇ ਬਜਾਏ ਪਹਿਲੀ ਦਿਸ਼ਾ ਦੇ ਤੌਰ 'ਤੇ ਕੰਮ ਕਰਦੀ ਹੈ; ਅੰਤਿਮ ਫੈਸਲੇ ਲਈ ਗਲਤੀ ਦੀਆਂ ਡਾਇਰੀਆਂ ਦੀ ਜਾਂਚ ਕਰਨਾ ਜ਼ਰੂਰੀ ਹੈ।

ਸਮਾਧਾਨ ਦੀ ਸ਼ੁਰੂਆਤ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਸੁਰੱਖਿਅਤ ਤਿਆਰੀ ਕਰੋ

1. ਪੂਰਾ ਬੈਕਅਪ ਲਓ

ਪਹਿਲਾ ਨਿਯਮ ਸਾਦਾ ਹੈ: ਬੈਕਅਪ ਲਈ ਬਿਨਾਂ ਕੰਮ ਨਾ ਕਰੋ। ਫਾਇਲਾਂ, ਡੇਟਾਬੇਸ, wp-content ਫੋਲਡਰ, uploads ਡਾਇਰੈਕਟਰੀ ਅਤੇ .htaccess ਫਾਇਲ ਸਮੇਤ ਪੂਰਾ ਬੈਕਅਪ ਲਿਆ ਜਾਣਾ ਚਾਹੀਦਾ ਹੈ। ਵਿਸ਼ੇਸ਼ ਤੌਰ 'ਤੇ ਈ-ਵਪਾਰ ਸਾਈਟਾਂ ਵਿੱਚ ਆਰਡਰ, ਸਟਾਕ ਅਤੇ ਗਾਹਕ ਡੇਟਾ ਕੁਝ ਮਿੰਟਾਂ ਵਿੱਚ ਬਦਲ ਸਕਦੇ ਹਨ, ਇਸ ਲਈ ਬੈਕਅਪ ਸਮੇਂ ਨੂੰ ਨੋਟ ਕਰਨਾ ਮਹੱਤਵਪੂਰਣ ਹੈ। ਜੇਕਰ ਤੁਸੀਂ ਇੱਕ ਮੈਂਬਰਸ਼ਿਪ ਜਾਂ WooCommerce ਸਾਈਟ ਨੂੰ ਪ੍ਰਬੰਧਿਤ ਕਰ ਰਹੇ ਹੋ ਤਾਂ ਹੱਲ ਦੌਰਾਨ ਨਵੇਂ ਆਰਡਰ ਨੂੰ ਅਸਥਾਈ ਮੁਰੰਮਤ ਮੋਡ ਵਿੱਚ ਲੈ ਜਾਣਾ ਡੇਟਾ ਦੀ ਸਥਿਰਤਾ ਦੇ ਨਜ਼ਰੋਂ ਜ਼ਿਆਦਾ ਸੁਰੱਖਿਅਤ ਹੈ।

ਇੱਕ ਵਧੀਆ ਹੋਸਟਿੰਗ ਪੈਨਲ ਵਿੱਚ ਇਕ ਕਲਿਕ ਨਾਲ ਬੈਕਅਪ, ਸਮਾਂਬੱਧ ਬੈਕਅਪ ਅਤੇ ਵਾਪਸ ਲੈਣ ਦੇ ਵਿਕਲਪ ਹੋਣੇ ਚਾਹੀਦੇ ਹਨ। ਇਹ ਵਿਸ਼ੇਸ਼ਤਾਵਾਂ ਸੰਕਟ ਗਲਤੀ ਦੇ ਸਮੇਂ ਵਿੱਚ ਘੰਟੇ ਬਚਾਉਂਦੀਆਂ ਹਨ। ਬੈਕਅਪ ਰਣਨੀਤੀ ਦੇ ਵਿਸ਼ੇ ਵਿੱਚ ਵੈਬ ਸਾਈਟ ਬੈਕਅੱਪ ਗਾਈਡ ਅਤੇ ਸੁਰੱਖਿਅਤ ਹੋਸਟਿੰਗ ਦੇ ਪਾਸੇ Hostragons ਹੋਸਟਿੰਗ ਹੱਲ ਦੀ ਜਾਂਚ ਕੀਤੀ ਜਾ ਸਕਦੀ ਹੈ।

2. ਜੀਵੰਤ ਸਾਈਟ ਦੇ ਬਜਾਏ ਸਟੇਜਿੰਗ ਮਾਹੌਲ ਦੀ ਵਰਤੋਂ ਕਰੋ

PHP 8.x ਅਨੁਕੂਲਤਾ ਟੈਸਟਾਂ ਲਈ ਸਭ ਤੋਂ ਸਹੀ ਜਗ੍ਹਾ ਸਟੇਜਿੰਗ ਮਾਹੌਲ ਹੈ। ਸਟੇਜਿੰਗ, ਤੁਹਾਡੇ ਜੀਵੰਤ ਸਾਈਟ ਦੀ ਨਕਲ 'ਤੇ ਬਿਨਾਂ ਕਿਸੇ ਜੋਖਮ ਦੇ ਟੈਸਟ ਕਰਨ ਦੀ ਆਗਿਆ ਦਿੰਦੀ ਹੈ। ਇੱਥੇ ਤੁਸੀਂ PHP 8.0, 8.1, 8.2 ਜਾਂ 8.3 ਵਰਜਨਾਂ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰ ਸਕਦੇ ਹੋ; ਪਲੱਗਇਨਾਂ ਨੂੰ ਇਕ-ਇੱਕ ਕਰਕੇ ਅੱਪਡੇਟ ਕਰ ਸਕਦੇ ਹੋ; ਭੁਗਤਾਨ, ਫਾਰਮ, ਮੈਂਬਰਸ਼ਿਪ, ਖੋਜ ਅਤੇ ਪ੍ਰਬੰਧਨ ਪੈਨਲ ਵਰਗੀਆਂ ਆਵਸ਼ਕ ਫੰਕਸ਼ਨਾਂ ਦੀ ਜਾਂਚ ਕਰ ਸਕਦੇ ਹੋ। ਜੀਵੰਤ ਸਾਈਟ 'ਤੇ ਸਿੱਧੇ ਤੌਰ 'ਤੇ ਪਲੱਗਇਨ ਬੰਦ ਕਰਨਾ ਦਰਸ਼ਕਾਂ ਦੇ ਖਰੀਦ ਜਾਂ ਸੰਪਰਕ ਪ੍ਰਕਿਰਿਆ ਨੂੰ ਰੁਕਾਵਟ ਪੈਦਾ ਕਰ ਸਕਦਾ ਹੈ।

ਇੱਕ ਪ੍ਰਯੋਗੀ ਟੈਸਟ ਯੋਜਨਾ ਬਣਾਓ: ਮੁੱਖ ਪੰਨਾ, ਸ਼੍ਰੇਣੀ ਪੰਨਾ, ਉਤਪਾਦ ਜਾਂ ਲੇਖ ਦਾ ਵਿਸਥਾਰ, ਕਾਰਟ, ਭੁਗਤਾਨ, ਸੰਪਰਕ ਫਾਰਮ, ਯੂਜ਼ਰ ਲੌਗਇਨ ਅਤੇ ਪ੍ਰਬੰਧਨ ਪੈਨਲ ਪੰਨਿਆਂ ਨੂੰ ਵੱਖਰੇ-ਵੱਖਰੇ ਜਾਂਚੋ। ਟਰੈਫਿਕ ਵਾਲੀਆਂ ਸਾਈਟਾਂ ਵਿੱਚ ਇਹ ਟੈਸਟ ਘੱਟ ਭਾਰੀ ਸਮੇਂ 'ਤੇ ਕਰਨਾ, ਸੰਭਵ ਕਟੌਤੀ ਦੇ ਪ੍ਰਭਾਵ ਨੂੰ ਘਟਾਉਂਦਾ ਹੈ।

ਕਦਮ-दਰ-ਕਦਮ PHP 8.x WordPress ਪਲੱਗਇਨ ਗਲਤੀ ਸਮਾਧਾਨ

1. WordPress ਡਿਬੱਗਿੰਗ ਮੋਡ ਚਾਲੂ ਕਰੋ

ਗਲਤੀ ਦਾ ਅਨੁਮਾਨ ਲਗਾ ਕੇ ਹੱਲ ਕਰਨ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰਨਾ ਸਮਾਂ ਬਰਬਾਦ ਕਰਦਾ ਹੈ। ਪਹਿਲਾਂ ਗਲਤੀ ਨੂੰ ਦਿਖਾਉਣਾ। ਤੁਸੀਂ wp-config.php ਫਾਇਲ ਵਿੱਚ ਡਿਬੱਗ ਸੈਟਿੰਗਾਂ ਨੂੰ ਅਸਥਾਈ ਤੌਰ 'ਤੇ ਸਮਰਥਿਤ ਕਰ ਸਕਦੇ ਹੋ। ਜੀਵੰਤ ਸਾਈਟ 'ਤੇ ਗਲਤੀਆਂ ਨੂੰ ਸਕ੍ਰੀਨ 'ਤੇ ਦਿਖਾਉਣ ਦੇ ਬਜਾਏ ਲੌਗ ਫਾਇਲ ਵਿੱਚ ਲਿਖਣਾ ਜ਼ਿਆਦਾ ਸੁਰੱਖਿਅਤ ਹੈ। ਲੋਜਿਕ ਇਹ ਹੈ: ਦਰਸ਼ਕ ਨੂੰ ਗਲਤੀ ਦਾ ਸੁਨੇਹਾ ਨਹੀਂ ਦੇਖਣਾ ਚਾਹੀਦਾ, ਪਰ ਤੁਹਾਨੂੰ ਇਹ ਜਾਣਨਾ ਚਾਹੀਦਾ ਹੈ ਕਿ ਗਲਤੀ ਕਿਸ ਫਾਇਲ ਅਤੇ ਲਾਈਨ ਤੋਂ ਆਈ ਹੈ।

ਸਿਫਾਰਸ਼ੀ ਰਵਾਇਆ ਇਹ ਹੈ ਕਿ WP_DEBUG ਕੀਮਤ ਨੂੰ true ਬਣਾਉਣਾ, WP_DEBUG_LOG ਨਾਲ ਗਲਤੀਆਂ ਨੂੰ ਰਿਕਾਰਡ ਕਰਨਾ ਅਤੇ WP_DEBUG_DISPLAY ਕੀਮਤ ਨੂੰ false ਰੱਖਣਾ। ਇਸ ਤਰ੍ਹਾਂ, ਤੁਸੀਂ wp-content/debug.log ਫਾਇਲ ਵਿੱਚ ਸੰਬੰਧਿਤ ਫੇਟਲ ਗਲਤੀ, ਚੇਤਾਵਣੀ ਜਾਂ Deprecated ਸੁਨੇਹੇ ਪੜ੍ਹ ਸਕਦੇ ਹੋ। ਕਾਰਵਾਈ ਮੁਕੰਮਲ ਹੋਣ 'ਤੇ ਡਿਬੱਗ ਮੋਡ ਨੂੰ ਬੰਦ ਕਰਨਾ ਨਾ ਭੁੱਲਣਾ; ਕਿਉਂਕਿ ਲੰਬੇ ਸਮੇਂ ਤੱਕ ਖੁੱਲੀ ਰਹਿਣ ਵਾਲੀਆਂ ਲੌਗ ਫਾਇਲਾਂ ਬੇਸਰੋਤ ਡਿਸਕ ਦੀ ਵਰਤੋਂ ਅਤੇ ਜਾਣਕਾਰੀ ਦੀ ਲੀਕ ਹੋਣ ਦਾ ਜੋਖਮ ਪੈਦਾ ਕਰ ਸਕਦੀਆਂ ਹਨ।

2. ਗਲਤੀ ਦੀਆਂ ਡਾਇਰੀਆਂ ਵਿੱਚ ਪਲੱਗਇਨ ਦਾ ਨਾਂ ਲੱਭੋ

ਲੌਗ ਫਾਇਲ ਵਿੱਚ ਆਮ ਤੌਰ 'ਤੇ ਸਮੱਸਿਆ ਵਾਲੇ ਪਲੱਗਇਨ ਦਾ ਫੋਲਡਰ ਨਾਮ ਸਾਫ਼ ਦਿਖਾਈ ਦਿੰਦਾ ਹੈ। ਉਦਾਹਰਨ ਵਜੋਂ, ਜੇ ਗਲਤੀ ਦੀ ਲਾਈਨ ਵਿੱਚ wp-content/plugins/ਪੁਰਾਣਾ-ਫਾਰਮ-ਪਲੱਗਇਨ/includes/class-handler.php ਵਰਗਾ ਮਾਰਗ ਹੈ ਤਾਂ ਪਹਿਲਾ ਸ਼ੱਕੀ ਸੰਬੰਧਿਤ ਪਲੱਗਇਨ ਹੈ। ਫੇਟਲ ਗਲਤੀ, Uncaught TypeError, Undefined function ਨੂੰ ਕਾਲ ਕਰਨਾ, null ਤੇ ਪ੍ਰਾਪਤੀ ਪੜ੍ਹਨ ਦੀ ਕੋਸ਼ਿਸ਼ ਅਤੇ ਡਾਇਨਾਮਿਕ ਪ੍ਰੋਪਰਟੀ ਦਾ ਸਿਰਜਣਾ ਵਰਗੀਆਂ ਵਿਆਖਿਆਵਾਂ PHP 8.x ਬਦਲਾਅ ਵਿੱਚ ਆਮ ਹਨ।

ਜੇਕਰ ਬਹੁਤ ਸਾਰੀਆਂ ਗਲਤੀਆਂ ਹਨ ਤਾਂ ਸਭ ਤੋਂ ਉੱਪਰਲੇ ਪਹਿਲੇ ਫੇਟਲ ਗਲਤੀ ਦੀ ਲਾਈਨ 'ਤੇ ਧਿਆਨ ਕੇਂਦ੍ਰਿਤ ਕਰੋ। ਹੇਠਾਂ ਦੀਆਂ ਲਾਈਨਾਂ ਵਿੱਚ ਆਉਣ ਵਾਲੀਆਂ ਗਲਤੀਆਂ ਬਹੁਤ ਵਾਰ ਮੁੱਖ ਗਲਤੀ ਦਾ ਨਤੀਜਾ ਹੁੰਦੀਆਂ ਹਨ। ਗਲਤੀ ਦੇ ਸਮੇਂ ਦੀ ਵੀ ਜਾਂਚ ਕਰੋ। PHP ਦੇ ਉੱਚਵੇਲੇ ਤੋਂ ਤੁਰੰਤ ਬਾਅਦ ਸ਼ੁਰੂ ਹੋਣ ਵਾਲੀਆਂ ਲਿਖਤਾਂ ਅਸੰਗਤੀ ਦੇ ਸਬੂਤ ਨੂੰ ਮਜ਼ਬੂਤ ਕਰਦੀਆਂ ਹਨ।

3. ਪਲੱਗਇਨਾਂ ਨੂੰ ਕੰਟਰੋਲ ਕੀਤੇ ਤਰੀਕੇ ਨਾਲ ਬੰਦ ਕਰੋ

ਜੇਕਰ ਤੁਸੀਂ ਪ੍ਰਬੰਧਨ ਪੈਨਲ ਤੱਕ ਪਹੁੰਚ ਸਕਦੇ ਹੋ ਤਾਂ Plugins ਪੰਨੇ ਤੋਂ ਸਾਰੇ ਪਲੱਗਇਨਾਂ ਨੂੰ ਬੰਦ ਕਰੋ ਅਤੇ ਇਕ-ਇਕ ਕਰਕੇ ਸਜ਼ਾ ਦਿਓ। ਹਰ ਸਜ਼ਾ ਦੇ ਬਾਅਦ ਸਾਈਟ ਅਤੇ ਪ੍ਰਬੰਧਨ ਪੈਨਲ ਦੀ ਜਾਂਚ ਕਰੋ। ਜਦੋਂ ਸਮੱਸਿਆ ਮੁੜ ਉੱਪਜਦੀ ਹੈ ਤਾਂ ਆਖਰੀ ਸਜ਼ਾ ਦਿੱਤਾ ਗਿਆ ਪਲੱਗਇਨ ਸੰਭਾਵਿਤ ਸਰੋਤ ਹੁੰਦਾ ਹੈ।

ਜੇਕਰ ਤੁਸੀਂ ਪ੍ਰਬੰਧਨ ਪੈਨਲ ਤੱਕ ਪਹੁੰਚ ਨਹੀਂ ਕਰ ਸਕਦੇ ਤਾਂ FTP ਜਾਂ ਫਾਇਲ ਮੈਨੇਜਰ ਰਾਹੀਂ wp-content/plugins ਫੋਲਡਰ ਦੇ ਨਾਮ ਨੂੰ plugins-disabled ਵਰਗੇ ਬਦਲੋ। ਇਹ ਕਾਰਵਾਈ ਸਾਰੇ ਪਲੱਗਇਨਾਂ ਨੂੰ ਬੰਦ ਕਰ ਦੇਵੇਗੀ। ਫਿਰ ਫੋਲਡਰ ਦੇ ਨਾਮ ਨੂੰ ਮੁੜ plugins ਕਰਕੇ ਅਤੇ ਪਲੱਗਇਨ ਫੋਲਡਰਾਂ ਦਾ ਇਕ-ਇਕ ਕਰਕੇ ਨਾਂ ਬਦਲ ਕੇ ਟੈਸਟ ਕੀਤਾ ਜਾ ਸਕਦਾ ਹੈ। ਇਹ ਤਰੀਕਾ ਖਾਸ ਤੌਰ 'ਤੇ ਸਫੇਦ ਸਕ੍ਰੀਨ ਅਤੇ ਸੰਕਟ ਗਲਤੀ ਦੇ ਹਾਲਤਾਂ ਵਿੱਚ ਤੇਜ਼ ਨਤੀਜੇ ਦਿੰਦਾ ਹੈ।

4. WordPress, ਥੀਮ ਅਤੇ ਪਲੱਗਇਨ ਦੇ ਵਰਜਨ ਅੱਪਡੇਟ ਕਰੋ

ਅਸੰਗਤੀਆਂ ਦਾ ਵੱਡੀ ਭਾਗ ਨਵੇਂ ਵਰਜਨਾਂ ਨਾਲ ਹੱਲ ਕੀਤਾ ਜਾਂਦਾ ਹੈ। ਪਰ ਅੱਪਡੇਟ ਕਰਨ ਵੇਲੇ ਕ੍ਰਮ ਮਹੱਤਵਪੂਰਣ ਹੈ। ਪਹਿਲਾਂ ਪੂਰਾ ਬੈਕਅਪ ਲਓ, ਫਿਰ WordPress ਕੋਰ, ਸਰਗਰਮ ਥੀਮ ਅਤੇ ਪਲੱਗਇਨਾਂ ਨੂੰ ਅੱਪਡੇਟ ਕਰੋ। ਵੱਡੇ ਵਰਜਨ ਬਦਲਾਅ ਵਿੱਚ ਇੱਕ ਵਾਰੀ ਵਿੱਚ 20 ਪਲੱਗਇਨਾਂ ਨੂੰ ਅੱਪਡੇਟ ਕਰਨ ਦੇ ਬਜਾਏ ਆਵਸ਼ਕ ਪਲੱਗਇਨਾਂ ਨੂੰ ਗਰੁੱਪਾਂ ਵਿੱਚ ਵੰਡਣਾ ਜ਼ਿਆਦਾ ਸੁਰੱਖਿਅਤ ਹੈ। ਉਦਾਹਰਨ ਵਜੋਂ, ਪਹਿਲਾਂ ਸੁਰੱਖਿਆ ਅਤੇ SEO ਪਲੱਗਇਨਾਂ ਨੂੰ, ਫਿਰ ਫਾਰਮ ਅਤੇ ਕੈਸ਼ ਪਲੱਗਇਨਾਂ ਨੂੰ, ਅਤੇ ਆਖਰ ਵਿੱਚ ਭੁਗਤਾਨ ਅਤੇ ਮੈਂਬਰਸ਼ਿਪ ਪਲੱਗਇਨਾਂ ਨੂੰ ਅੱਪਡੇਟ ਕੀਤਾ ਜਾ ਸਕਦਾ ਹੈ।

ਪਲੱਗਇਨ ਪੰਨੇ 'ਤੇ ਆਖਰੀ ਅੱਪਡੇਟ ਦੀ ਤਾਰੀਖ, ਸਰਗਰਮ ਇੰਸਟਾਲੇਸ਼ਨ ਦੀ ਸੰਖਿਆ, ਸਹਾਇਤਾ ਫੋਰਮ ਦੇ ਜਵਾਬ ਅਤੇ ਜਾਂਚ ਕੀਤੇ WordPress ਵਰਜਨ ਦੀ ਜਾਂਚ ਕੀਤੀ ਜਾਣੀ ਚਾਹੀਦੀ ਹੈ। ਆਖਰੀ ਅੱਪਡੇਟ 2 ਸਾਲ ਤੋਂ ਪੁਰਾਣੀ, ਸਹਾਇਤਾ ਦੇ ਬੇਨਤੀ ਨੂੰ ਜਵਾਬ ਨਾ ਦੇਣ ਵਾਲੀ ਅਤੇ PHP 8.x ਅਨੁਕੂਲਤਾ ਦਾ ਜ਼ਿਕਰ ਨਾ ਕਰਨ ਵਾਲੇ ਪਲੱਗਇਨ ਲੰਬੇ ਸਮੇਂ ਵਿੱਚ ਖਤਰਾ ਪੈਦਾ ਕਰਦੇ ਹਨ।

5. ਅਸੰਗਤ ਪਲੱਗਇਨ ਦਾ ਵਿਕਲਪ ਲੱਭੋ

ਕੁਝ ਪਲੱਗਇਨ ਹੁਣ ਮੁਰੰਮਤ ਨਹੀਂ ਕੀਤੇ ਜਾ ਸਕਦੇ। ਇਸ ਸਥਿਤੀ ਵਿੱਚ, ਗਲਤੀ ਨੂੰ ਅਸਥਾਈ ਪੈਚਾਂ ਨਾਲ ਦਬਾਉਣ ਦੇ ਬਜਾਏ ਆਧੁਨਿਕ ਅਤੇ ਸਰਗਰਮ ਵਿਕਾਸਿਤ ਇੱਕ ਵਿਕਲਪ 'ਤੇ ਜਾਣਾ ਜ਼ਿਆਦਾ ਸਿਹਤਮੰਦ ਹੈ। ਉਦਾਹਰਨ ਵਜੋਂ, ਜੇ ਪੁਰਾਣੀ ਸੰਪਰਕ ਫਾਰਮ ਪਲੱਗਇਨ PHP 8.2 ਨਾਲ TypeError ਪੈਦਾ ਕਰ ਰਹੀ ਹੈ, ਤਾਂ ਨਵੇਂ ਫਾਰਮ ਪਲੱਗਇਨ 'ਤੇ ਜਾਣਾ ਸੁਰੱਖਿਆ ਅਤੇ ਵਰਤਣਯੋਗਤਾ ਦੇ ਨਜ਼ਰੋਂ ਵਧੀਆ ਨਤੀਜੇ ਦਿੰਦਾ ਹੈ।

ਵਿਕਲਪ ਚੁਣਦੇ ਸਮੇਂ ਸਿਰਫ ਤਾਰਾਂ ਦੇ ਅੰਕ 'ਤੇ ਨਾ ਦੇਖੋ। ਹੇਠਾਂ ਦਿੱਤੇ ਮਾਪਦੰਡਾਂ ਦੀ ਵਰਤੋਂ ਕਰੋ: ਨਿਯਮਤ ਅੱਪਡੇਟ ਦੀ ਆਵਤੀ, PHP 8.x ਸਹਾਇਤਾ, WordPress ਦੇ ਨਵੇਂ ਵਰਜਨ ਨਾਲ ਅਨੁਕੂਲਤਾ, ਵਿਕਾਸਕ ਦਸਤਾਵੇਜ਼, ਡੇਟਾ ਦੇਣ ਦੀ ਆਸਾਨੀ, ਪ੍ਰਦਰਸ਼ਨ ਦੇ ਪ੍ਰਭਾਵ ਅਤੇ ਸਹਾਇਤਾ ਦੀ ਗੁਣਵੱਤਾ। ਖਾਸ ਤੌਰ 'ਤੇ ਭੁਗਤਾਨ, ਰਿਜ਼ਰਵੇਸ਼ਨ ਅਤੇ ਮੈਂਬਰਸ਼ਿਪ ਵਰਗੀਆਂ ਆਮਦਨ ਪੈਦਾ ਕਰਨ ਵਾਲੀਆਂ ਫੰਕਸ਼ਨਾਂ ਵਿੱਚ ਮੁਫਤ ਪਲੱਗਇਨ ਦੇ ਬਜਾਏ ਪੇਸ਼ੇਵਰ ਸਹਾਇਤਾ ਪ੍ਰਦਾਨ ਕਰਨ ਵਾਲੇ ਹੱਲਾਂ ਨੂੰ ਤਰਜੀਹ ਦਿੱਤੀ ਜਾ ਸਕਦੀ ਹੈ।

6. PHP ਦੇ ਵਰਜਨ ਨੂੰ ਅਸਥਾਈ ਤੌਰ 'ਤੇ ਵਾਪਸ ਲੈ ਜਾਓ

ਜੇਕਰ ਜੀਵੰਤ ਸਾਈਟ ਪੂਰੀ ਤਰ੍ਹਾਂ ਬੰਦ ਹੈ ਅਤੇ ਤੇਜ਼ ਵਾਪਸੀ ਦੀ ਲੋੜ ਹੈ, ਤਾਂ PHP ਦੇ ਵਰਜਨ ਨੂੰ ਅਸਥਾਈ ਤੌਰ 'ਤੇ ਪੁਰਾਣੇ ਸਥਿਰ ਵਰਜਨ 'ਤੇ ਲੈ ਜਾਣਾ ਸਮਝਦਾਰੀ ਹੋ ਸਕਦੀ ਹੈ। ਪਰ ਇਹ ਇੱਕ ਸਥਾਈ ਹੱਲ ਨਹੀਂ ਹੈ। ਉਦਾਹਰਨ ਵਜੋਂ, ਜੇ PHP 8.2 ਤੋਂ ਬਾਅਦ ਸਾਈਟ ਖੁਲਦੀ ਨਹੀਂ ਹੈ ਅਤੇ ਪਹਿਲਾਂ PHP 8.0 ਜਾਂ 7.4 'ਤੇ ਕੰਮ ਕਰ ਰਹੀ ਸੀ, ਤਾਂ ਹੋਸਟਿੰਗ ਪੈਨਲ ਤੋਂ ਵਰਜਨ ਨੂੰ ਅਸਥਾਈ ਤੌਰ 'ਤੇ ਘਟਾ ਕੇ ਦਰਸ਼ਕਾਂ ਦੀ ਰੁਕਾਵਟ ਨੂੰ ਘਟਾਇਆ ਜਾ ਸਕਦਾ ਹੈ। ਫਿਰ ਸਟੇਜਿੰਗ ਮਾਹੌਲ ਵਿੱਚ ਅਸਲੀ ਅਨੁਕੂਲਤਾ ਕੰਮ ਕੀਤਾ ਜਾਣਾ ਚਾਹੀਦਾ ਹੈ।

ਇੱਥੇ ਧਿਆਨ ਦੇਣ ਵਾਲੀ ਗੱਲ ਸੁਰੱਖਿਆ ਹੈ। ਸਹਾਇਤਾ ਸਮੇਂ ਸਮਾਪਤ ਹੋ ਚੁੱਕੇ PHP ਵਰਜਨਾਂ ਵਿੱਚ ਲੰਬੇ ਸਮੇਂ ਤੱਕ ਰਹਿਣਾ ਤੁਹਾਡੇ ਸਾਈਟ ਨੂੰ ਸੁਰੱਖਿਆ ਖ਼ਤਰਾਂ ਦੇ ਖਿਲਾਫ਼ ਬੇਸੁਰੱਖਿਅਤ ਛੱਡ ਸਕਦਾ ਹੈ। ਇਸ ਲਈ ਵਾਪਸੀ ਦੀ ਕਾਰਵਾਈ ਆਕਸਮਿਕ ਹਾਲਤ ਦੇ ਬਰੇਕ ਦਾ ਕੰਮ ਕਰਦੀ ਹੈ; ਇਹ ਮੁਰੰਮਤ ਯੋਜਨਾ ਦਾ ਬਦਲਾ ਨਹੀਂ ਹੋ ਸਕਦੀ।

7. ਸਰਵਰ PHP ਸੈਟਿੰਗਾਂ ਦੀ ਜਾਂਚ ਕਰੋ

ਕੁਝ ਗਲਤੀਆਂ ਸਿੱਧੇ ਤੌਰ 'ਤੇ ਪਲੱਗਇਨ ਤੋਂ ਨਹੀਂ, ਬਲਕਿ ਸਰਵਰ ਦੀ ਸੰਰਚਨਾ ਤੋਂ ਆਉਂਦੀਆਂ ਹਨ। memory_limit, max_execution_time, upload_max_filesize, post_max_size ਅਤੇ max_input_vars ਦੀਆਂ ਕੀਮਤਾਂ ਖਾਸ ਤੌਰ 'ਤੇ WooCommerce, ਪੇਜ ਬਿਲਡਰ ਅਤੇ ਬਹੁਭਾਸ਼ੀ ਸਾਈਟਾਂ ਵਿੱਚ ਮਹੱਤਵਪੂਰਣ ਹਨ। ਉਦਾਹਰਨ ਵਜੋਂ, ਇੱਕ ਵੱਡੇ ਪੇਜ ਬਿਲਡਰ ਨਾਲ ਬਣਾਈ ਗਈ ਸਾਈਟ ਵਿੱਚ max_input_vars ਘੱਟ ਹੋਣ 'ਤੇ ਰਿਕਾਰਡਿੰਗ ਪ੍ਰਕਿਰਿਆ ਫਲ ਮੰਦ ਹੋ ਸਕਦੀ ਹੈ। ਜ਼ਿਆਦਾ ਉਤਪਾਦ ਵੈਰੀਏਸ਼ਨ ਵਾਲੀਆਂ WooCommerce ਸਾਈਟਾਂ ਵਿੱਚ ਯਾਦ ਸੀਮਾ ਕਮੀ ਹੋਣ 'ਤੇ 500 ਗਲਤੀ ਦਿਖਾਈ ਦੇ ਸਕਦੀ ਹੈ।

ਜਨਰਲ ਸ਼ੁਰੂਆਤੀ ਕੀਮਤਾਂ ਵਜੋਂ memory_limit ਲਈ 256M, max_execution_time ਲਈ 120 ਸਕਿੰਟ, max_input_vars ਲਈ 3000 ਅਤੇ ਇਸ ਤੋਂ ਉੱਪਰ ਬਹੁਤ ਸਾਰੀਆਂ WordPress ਸਾਈਟਾਂ ਲਈ ਜ਼ਿਆਦਾ ਸਿਹਤਮੰਦ ਹੋ ਸਕਦੀਆਂ ਹਨ। ਪਰ ਹਰ ਸਾਈਟ ਵੱਖਰੀ ਹੈ; ਬੇਕਾਰ ਉੱਚੀਆਂ ਕੀਮਤਾਂ ਦੇ ਬਜਾਏ ਵਾਸਤਵਿਕ ਜ਼ਰੂਰਤਾਂ ਦਾ ਵਿਸ਼ਲੇਸ਼ਣ ਕੀਤਾ ਜਾਣਾ ਚਾਹੀਦਾ ਹੈ। ਜੇਕਰ ਸਰਵਰ ਪੱਖ ਦੇ ਸਹਾਇਤਾ ਦੀ ਲੋੜ ਹੈ ਤਾਂ WordPress ਅਨੁਕੂਲ ਹੋਸਟਿੰਗ ਅਤੇ ਤਕਨੀਕੀ ਸਹਾਇਤਾ ਵਾਲੀਆਂ ਹੋਸਟਿੰਗ ਸੇਵਾਵਾਂ ਚੋਣਾਂ ਪ੍ਰਕਿਰਿਆ ਨੂੰ ਆਸਾਨ ਕਰ ਸਕਦੀਆਂ ਹਨ।

ਆਮ PHP 8.x ਗਲਤੀਆਂ ਅਤੇ ਪ੍ਰਯੋਗੀ ਹੱਲ

ਫੇਟਲ ਗਲਤੀ: Uncaught TypeError

ਇਹ ਗਲਤੀ ਆਮ ਤੌਰ 'ਤੇ ਇੱਕ ਫੰਕਸ਼ਨ ਨੂੰ ਉਮੀਦ ਕੀਤੀ ਕਿਸਮ ਦੇ ਡੇਟਾ ਨਹੀਂ ਭੇਜਣ 'ਤੇ ਹੁੰਦੀ ਹੈ। ਉਦਾਹਰਨ ਵਜੋਂ ਜੇ ਪਲੱਗਇਨ ਸੰਖਿਆ ਦੀ ਉਮੀਦ ਕਰਦਾ ਹੈ ਪਰ null ਮੁੱਲ ਪ੍ਰਾਪਤ ਕਰਦਾ ਹੈ ਤਾਂ PHP 8.x ਜ਼ਿਆਦਾ ਕਠੋਰ ਵਰਤਾਵ ਰੱਖਦਾ ਹੈ ਅਤੇ ਕਾਰਵਾਈ ਨੂੰ ਰੋਕ ਸਕਦਾ ਹੈ। ਹੱਲ, ਪਲੱਗਇਨ ਨੂੰ ਅੱਪਡੇਟ ਕਰਨਾ ਜਾਂ ਵਿਕਾਸਕ ਵੱਲੋਂ ਜਾਰੀ ਕੀਤਾ ਗਿਆ ਪੈਚ ਲਾਗੂ ਕਰਨਾ ਹੈ। ਵਿਸ਼ੇਸ਼ ਕੋਡਾਂ ਵਿੱਚ, ਬਦਲਣ ਵਾਲੇ ਦਾ ਵਰਤੋਂ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਖਾਲੀ ਹੋਣ ਦੀ ਜਾਂਚ ਕੀਤੀ ਜਾਣੀ ਚਾਹੀਦੀ ਹੈ।

Undefined Function ਨੂੰ ਕਾਲ ਕਰਨਾ

ਇਹ ਗਲਤੀ ਦਿਖਾਉਂਦੀ ਹੈ ਕਿ ਵਰਤੋਂ ਕੀਤੀ ਜਾ ਰਹੀ ਫੰਕਸ਼ਨ ਮੌਜੂਦਾ PHP ਵਰਜਨ, WordPress ਕੋਰ ਜਾਂ ਜਰੂਰੀ PHP ਮੋਡੀਊਲ ਵਿੱਚ ਉਪਲਬਧ ਨਹੀਂ ਹੈ। ਪਲੱਗਇਨ ਪੁਰਾਣੇ ਫੰਕਸ਼ਨ 'ਤੇ ਨਿਰਭਰ ਹੋ ਸਕਦਾ ਹੈ ਜਾਂ ਸਰਵਰ 'ਤੇ ਜਰੂਰੀ ਮੋਡੀਊਲ ਸਰਗਰਮ ਨਹੀਂ ਹੈ। ਪਹਿਲਾਂ ਪਲੱਗਇਨ ਦੇ ਦਸਤਾਵੇਜ਼ ਵਿੱਚ ਸਿਸਟਮ ਦੀਆਂ ਲੋੜਾਂ ਦੀ ਜਾਂਚ ਕਰੋ, ਫਿਰ ਹੋਸਟਿੰਗ ਪੈਨਲ ਵਿੱਚ PHP ਐਕਸਟੈਂਸ਼ਨ ਦੀ ਜਾਂਚ ਕਰੋ।

Deprecated ਅਤੇ Warning ਸੁਨੇਹੇ

Deprecated ਸੁਨੇਹੇ ਅਕਸਰ ਸਾਈਟ ਦੇ ਕੰਮ ਕਰਨ ਵਿੱਚ ਰੁਕਾਵਟ ਨਹੀਂ ਪਾਉਂਦੇ; ਪਰ ਇਹ ਇਸ ਗੱਲ ਦਾ ਸੰਕੇਤ ਹੁੰਦਾ ਹੈ ਕਿ ਭਵਿੱਖ ਵਿੱਚ ਫੇਟਲ ਗਲਤੀ ਹੋ ਸਕਦੀ ਹੈ। ਜੀਵੰਤ ਸਾਈਟ 'ਤੇ ਇਹ ਚੇਤਾਵਣੀਆਂ ਦਰਸ਼ਕ ਨੂੰ ਨਹੀਂ ਦਿਖਾਈ ਜਾਣੀਆਂ ਚਾਹੀਦੀਆਂ। ਚੇਤਾਵਣੀਆਂ ਨੂੰ ਲੌਗ ਫਾਇਲ ਵਿੱਚ ਲੈ ਕੇ ਸੰਬੰਧਿਤ ਪਲੱਗਇਨ ਨੂੰ ਅੱਪਡੇਟ ਕਰਨਾ, ਵਿਕਾਸਕ ਨੂੰ ਜਾਣੂ ਕਰਨਾ ਜਾਂ ਵਿਕਲਪ ਯੋਜਨਾ ਬਣਾਉਣਾ ਸਹੀ ਰਵਾਇਆ ਹੈ।

Allowed Memory Size Exhausted

ਇਹ ਗਲਤੀ ਯਾਦ ਸੀਮਾ ਦੇ ਪਾਰ ਹੋਣ ਦਾ ਸੰਕੇਤ ਦਿਂਦੀ ਹੈ। ਸਿਰਫ memory_limit ਨੂੰ ਵਧਾਉਣਾ ਛੋਟੇ ਸਮੇਂ ਲਈ ਹੱਲ ਹੋ ਸਕਦਾ ਹੈ; ਪਰ ਅਸਲ ਕਾਰਨ ਖਰਾਬ ਢੰਗ ਨਾਲ ਢੰਗੀ ਪਲੱਗਇਨ, ਭਾਰੀ ਕਵੈਰੀ ਜਾਂ ਗੱਦੜ ਡੇਟਾਬੇਸ ਹੋ ਸਕਦਾ ਹੈ। WooCommerce ਰਿਪੋਰਟਾਂ, ਬੈਕਅਪ ਪਲੱਗਇਨਾਂ ਅਤੇ ਵਿਜ਼ੂਅਲ ਅਪਟਿਮਾਈਜ਼ੇਸ਼ਨ ਟੂਲ ਇਸ ਗਲਤੀ ਨੂੰ ਉਤਪਾਦਨ ਦੇ ਸਕਦੇ ਹਨ। ਯਾਦ ਸੀਮਾ ਵਧਾਉਣ ਦੇ ਬਾਅਦ ਪਲੱਗਇਨ ਦੀ ਖਪਤ ਦੀ ਨਿਗਰਾਨੀ ਕਰਨੀ ਚਾਹੀਦੀ ਹੈ।

ਹੋਸਟਿੰਗ ਪਾਸੇ ਦੇਖਣ ਦੀਆਂ ਚੀਜ਼ਾਂ

PHP 8.x ਬਦਲਾਅ ਦਾ ਸਮੱਸਿਆ ਰਹਿਤ ਹੋਣਾ ਯਕੀਨੀ ਬਣਾਉਣ ਲਈ ਹੋਸਟਿੰਗ ਢਾਂਚਾ ਅੱਪਡੇਟ, ਲਚਕੀਲਾ ਅਤੇ ਨਿਗਰਾਨੀਯੋਗ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ। ਇੱਕ ਹੋਸਟਿੰਗ ਪੈਨਲ ਵਿੱਚ PHP ਦੇ ਵਰਜਨ ਦੀ ਚੋਣ, ਐਕਸਟੈਂਸ਼ਨ ਪ੍ਰਬੰਧਨ, ਗਲਤੀ ਦੀਆਂ ਲੌਗਾਂ ਦੀ ਪਹੁੰਚ, ਬੈਕਅਪ ਵਾਪਸ ਲੈਣਾ, SSL ਪ੍ਰਬੰਧਨ ਅਤੇ ਸਰੋਤ ਦੀ ਵਰਤੋਂ ਦੀ ਨਿਗਰਾਨੀ ਹੋਣੀ ਚਾਹੀਦੀ ਹੈ। SSL ਪਾਸੇ ਦੀਆਂ ਗਲਤੀਆਂ ਸਿੱਧੇ PHP ਅਸੰਗਤੀ ਨਹੀਂ ਹੋ ਸਕਦੀਆਂ ਪਰ ਅੱਪਡੇਟ ਤੋਂ ਬਾਅਦ ਰੀਡਾਇਰੈਕਸ਼ਨ ਅਤੇ ਸੁਰੱਖਿਅਤ ਕਨੈਕਸ਼ਨ ਦੀਆਂ ਸਮੱਸਿਆਵਾਂ ਨਾਲ ਵੀ ਮਿਲ ਸਕਦੀਆਂ ਹਨ। ਇਸ ਮਾਮਲੇ ਵਿੱਚ SSL ਸਰਟੀਫਿਕੇਟ ਦੇ ਹੱਲ ਅਤੇ ਮੁਫ਼ਤ SSL ਸੰਸਥਾਪਨ ਗਾਈਡ ਲਾਭਦਾਇਕ ਹੋ ਸਕਦੇ ਹਨ।

ਉਪਰੰਤ ਡੋਮੇਨ DNS ਰੀਡਾਇਰੈਕਸ਼ਨ, CDN ਦੀ ਵਰਤੋਂ ਅਤੇ ਕੈਸ਼ ਪਰਤਾਂ ਵੀ ਟੈਸਟ ਨਤੀਜਿਆਂ 'ਤੇ ਪ੍ਰਭਾਵ ਪਾ ਸਕਦੀਆਂ ਹਨ। ਉਦਾਹਰਣ ਵਜੋਂ, ਜਦੋਂ ਤੁਸੀਂ ਸੋਚਦੇ ਹੋ ਕਿ ਤੁਸੀਂ ਪਲੱਗਇਨ ਨੂੰ ਠੀਕ ਕਰ ਦਿੱਤਾ ਹੈ, ਤਾਂ CDN ਪੁਰਾਣੇ ਗਲਤੀ ਵਾਲੇ ਪੰਨਿਆਂ ਨੂੰ ਦਿਖਾਉਣਾ ਜਾਰੀ ਰੱਖ ਸਕਦਾ ਹੈ। ਇਸ ਲਈ ਸਰਵਰ ਕੈਸ਼, ਪਲੱਗਇਨ ਕੈਸ਼, ਬ੍ਰਾਊਜ਼ਰ ਕੈਸ਼ ਅਤੇ ਜੇ ਕੋਈ CDN ਕੈਸ਼ ਹੋਵੇ ਤਾਂ ਇਹਨਾਂ ਨੂੰ ਵੱਖਰੇ ਤੌਰ 'ਤੇ ਸਾਫ਼ ਕੀਤਾ ਜਾਣਾ ਚਾਹੀਦਾ ਹੈ। ਜੇ ਤੁਸੀਂ ਨਵੀਂ ਸਾਈਟ ਦਾ ਮਾਰਗ ਜਾਂ ਡੋਮੇਨ ਨਾਂ ਦੀ ਸੰਰਚਨਾ ਕਰ ਰਹੇ ਹੋ ਤਾਂ ਡੋਮੇਨ ਪੁੱਛਤਾਛ ਅਤੇ ਰਜਿਸਟਰੇਸ਼ਨ ਅਤੇ DNS ਪ੍ਰਬੰਧਨ ਗਾਈਡ ਲਿੰਕ ਇੱਕ ਕੁਦਰਤੀ ਸ਼ੁਰੂਆਤ ਬਿੰਦੂ ਹੈ।

ਨਿਯਮਤ ਉਪਰਾਲਾ: ਅੱਪਡੇਟਾਂ ਤੋਂ ਪਹਿਲਾਂ ਅਨੁਕੂਲਤਾ ਦੀ ਰੁਟੀਨ

PHP 8.x ਅਸੰਗਤੀਆਂ ਨੂੰ ਇੱਕ ਵਾਰੀ ਹੱਲ ਕਰਨਾ ਕਾਫ਼ੀ ਨਹੀਂ ਹੈ। WordPress ਈਕੋਸਿਸਟਮ ਲਗਾਤਾਰ ਬਦਲਦਾ ਹੈ; ਇਸ ਲਈ ਨਿਯਮਤ ਮੁਰੰਮਤ ਦੀ ਰੁਟੀਨ ਬਣਾਉਣ ਦੀ ਲੋੜ ਹੈ। ਪੇਸ਼ੇਵਰ ਸਾਈਟਾਂ 'ਤੇ ਹਰ ਮਹੀਨੇ ਘੱਟੋ-ਘੱਟ ਇੱਕ ਵਾਰ ਪਲੱਗਇਨ ਅਤੇ ਥੀਮ ਦੇ ਅੱਪਡੇਟ ਦੀ ਜਾਂਚ ਕੀਤੀ ਜਾ ਸਕਦੀ ਹੈ, ਤਿੰਨ ਮਹੀਨੇ ਵਿੱਚ ਸਟੇਜਿੰਗ 'ਤੇ PHP ਅਨੁਕੂਲਤਾ ਟੈਸਟ ਕੀਤਾ ਜਾ ਸਕਦਾ ਹੈ ਅਤੇ ਆਵਸ਼ਕ ਅੱਪਡੇਟਾਂ ਨੂੰ ਜੀਵੰਤ ਵਿੱਚ ਯੋਜਨਾ ਬੰਨਿਆ ਜਾਣਾ ਚਾਹੀਦਾ ਹੈ।

ਇੱਕ ਸਧਾਰਨ ਪਰ ਪ੍ਰਭਾਵਸ਼ਾਲੀ ਨਿਗਰਾਨੀ ਸੂਚੀ ਹੇਠਾਂ ਦਿੱਤੀ ਗਈ ਹੈ:

• ਹਰ ਅੱਪਡੇਟ ਤੋਂ ਪਹਿਲਾਂ ਫਾਇਲਾਂ ਅਤੇ ਡੇਟਾਬੇਸ ਦਾ ਬੈਕਅਪ ਲਓ।
• ਪਲੱਗਇਨ ਦੇ ਬਦਲਾਅ ਦੀ ਡਾਇਰੀ ਵਿੱਚ PHP 8.x ਨੋਟਸ ਨੂੰ ਪੜ੍ਹੋ।
• ਮੁਰੰਮਤ ਨਾ ਹੋਣ ਵਾਲੇ ਪਲੱਗਇਨਾਂ ਨੂੰ ਸਾਲ ਵਿੱਚ ਘੱਟੋ-ਘੱਟ ਇੱਕ ਵਾਰ ਵਿਕਲਪਾਂ ਨਾਲ ਤੁਲਨਾ ਕਰੋ।
• ਸੁਰੱਖਿਆ, ਭੁਗਤਾਨ ਅਤੇ ਫਾਰਮ ਪਲੱਗਇਨਾਂ ਨੂੰ ਪਹਿਲਾਂ ਟੈਸਟ ਕਰੋ।
• ਸਟੇਜਿੰਗ ਮਾਹੌਲ ਵਿੱਚ ਆਵਸ਼ਕ ਯੂਜ਼ਰ ਰਾਸ਼ੀਆਂ ਦੀ ਮੈਨੀਅਲ ਟੈਸਟ ਕਰੋ।
• ਗਲਤੀ ਦੀਆਂ ਲੌਗਾਂ ਨੂੰ ਅੱਪਡੇਟ ਕਰਨ ਤੋਂ ਬਾਅਦ ਤੁਰੰਤ ਅਤੇ 24 ਘੰਟਿਆਂ ਬਾਅਦ ਦੁਬਾਰਾ ਜਾਂਚ ਕਰੋ।
• ਬੇਕਾਰ ਪਲੱਗਇਨਾਂ ਨੂੰ ਹਟਾਓ; ਸਿਰਫ ਬੰਦ ਕਰਨਾ ਕਾਫ਼ੀ ਨਹੀਂ ਹੈ।

ਇਸ ਰੁਟੀਨ ਦਾ ਸਭ ਤੋਂ ਵੱਡਾ ਫਾਇਦਾ ਹੈ, ਸੰਕਟ ਨੂੰ ਜਲਦੀ ਪਕੜਨਾ। ਉਦਾਹਰਨ ਵਜੋਂ, ਜੇਕਰ ਇੱਕ ਪਲੱਗਇਨ PHP 8.3 ਨਾਲ ਚੇਤਾਵਣੀ ਪੈਦਾ ਕਰਨਾ ਸ਼ੁਰੂ ਕਰਦਾ ਹੈ, ਤਾਂ ਤੁਸੀਂ ਸਟੇਜਿੰਗ ਮਾਹੌਲ ਵਿੱਚ ਇਸਨੂੰ ਪਤਾ ਲਗਾ ਕੇ ਜੀਵੰਤ ਸਾਈਟ 'ਤੇ ਵਿਕਰੀ ਦੇ ਨੁਕਸਾਨ ਤੋਂ ਬਚ ਸਕਦੇ ਹੋ। ਖਾਸ ਤੌਰ 'ਤੇ ਕਾਰਪੋਰੇਟ ਵੈਬਸਾਈਟਾਂ, ਈ-ਵਪਾਰ ਪ੍ਰਾਜੈਕਟਾਂ ਅਤੇ ਉੱਚ ਟਰੈਫਿਕ ਵਾਲੇ ਬਲੌਗਾਂ ਲਈ ਇਹ ਰਵਾਇਆ ਤਕਨੀਕੀ ਲਗਜ਼ ਨਹੀਂ, ਬਲਕਿ ਆਪਰੇਸ਼ਨਲ ਜ਼ਰੂਰਤ ਹੈ।

ਉਦਾਹਰਣ ਦ੍ਰਿਸ਼: ਸਫੇਦ ਸਕ੍ਰੀਨ ਤੋਂ ਕੰਮ ਕਰਨ ਵਾਲੀ ਸਾਈਟ ਤੱਕ

ਇੱਕ ਵਾਸਤਵਿਕ ਉਦਾਹਰਣ ਦੇ ਆਧਾਰ 'ਤੇ ਅੱਗੇ ਵਧੀਏ। ਇੱਕ WordPress ਸਾਈਟ ਵਿੱਚ PHP 7.4 ਵਰਜਨ ਤੋਂ PHP 8.2 ਵਰਜਨ 'ਤੇ ਜਾਣ ਦਾ ਅਨੁਮਾਨ ਲਗਾਇਆ ਗਿਆ ਹੈ। ਅੱਪਡੇਟ ਨੇ ਬਾਅਦ ਮੁੱਖ ਪੰਨਾ ਸਫੇਦ ਸਕ੍ਰੀਨ ਦਾ ਦਿਖਾਉਣਾ ਸ਼ੁਰੂ ਕੀਤਾ, ਪ੍ਰਬੰਧਨ ਪੈਨਲ ਨੇ ਸੰਕਟ ਗਲਤੀ ਸੁਨੇਹਾ ਦਿਖਾਇਆ। ਸਭ ਤੋਂ ਪਹਿਲਾਂ ਹੋਸਟਿੰਗ ਪੈਨਲ ਤੋਂ ਫਾਇਲਾਂ ਅਤੇ ਡੇਟਾਬੇਸ ਦਾ ਬੈਕਅਪ ਲੈਣਾ ਚਾਹੀਦਾ ਹੈ। ਫਿਰ wp-config.php 'ਤੇ ਡਿਬੱਗ ਲੌਗ ਚਾਲੂ ਕੀਤਾ ਜਾਂਦਾ ਹੈ। debug.log ਫਾਇਲ ਵਿੱਚ ਗਲਤੀ wp-content/plugins/ਪੁਰਾਣਾ-ਸਲਾਈਡਰ ਪਲੱਗਇਨ ਤੋਂ ਆਉਣ ਦੀ ਜਾਣਕਾਰੀ ਮਿਲਦੀ ਹੈ।

ਪ੍ਰਬੰਧਨ ਪੈਨਲ ਤੱਕ ਪਹੁੰਚ ਨਹੀਂ ਹੋ ਸਕੀ, ਇਸ ਲਈ FTP ਰਾਹੀਂ old-slider ਫੋਲਡਰ ਦਾ ਨਾਮ old-slider-disabled ਕਰ ਦਿੱਤਾ ਗਿਆ। ਸਾਈਟ ਮੁੜ ਖੁਲਦੀ ਹੈ। ਫਿਰ ਪਤਾ ਲੱਗਦਾ ਹੈ ਕਿ ਪਲੱਗਇਨ ਦੀ ਆਖਰੀ ਅੱਪਡੇਟ 3 ਸਾਲ ਪਹਿਲਾਂ ਕੀਤੀ ਗਈ ਸੀ। ਸਟੇਜਿੰਗ ਮਾਹੌਲ ਵਿੱਚ ਇੱਕ ਨਵਾਂ ਸਲਾਈਡਰ ਪਲੱਗਇਨ ਇੰਸਟਾਲ ਕੀਤਾ ਜਾਂਦਾ ਹੈ, ਪੁਰਾਣੀਆਂ ਸਲਾਈਡ ਚਿੱਤਰਾਂ ਨੂੰ ਹਟਾਇਆ ਜਾਂਦਾ ਹੈ ਅਤੇ ਪੰਨਾ ਡਿਜ਼ਾਈਨ ਦੀ ਜਾਂਚ ਕੀਤੀ ਜਾਂਦੀ ਹੈ। ਕੈਸ਼ ਸਾਫ਼ ਕੀਤਾ ਜਾਂਦਾ ਹੈ, ਮੋਬਾਈਲ ਦੇਖਣ ਦੀ ਜਾਂਚ ਕੀਤੀ ਜਾਂਦੀ ਹੈ, ਫਿਰ ਬਦਲਾਅ ਨੂੰ ਜੀਵੰਤ ਕੀਤਾ ਜਾਂਦਾ ਹੈ। ਆਖਰੀ ਕਦਮ ਦੇ ਤੌਰ 'ਤੇ PHP 8.2 ਨੂੰ ਬਚਾਇਆ ਜਾਂਦਾ ਹੈ ਅਤੇ ਪੁਰਾਣਾ ਪਲੱਗਇਨ ਪੂਰੀ ਤਰ੍ਹਾਂ ਹੱਟਾਇਆ ਜਾਂਦਾ ਹੈ। ਇਸ ਦ੍ਰਿਸ਼ ਵਿੱਚ ਸਥਾਈ ਹੱਲ PHP ਦੇ ਵਰਜਨ ਨੂੰ ਘਟਾਉਣਾ ਨਹੀਂ ਹੈ, ਬਲਕਿ ਮੁਰੰਮਤ ਨਾ ਕੀਤੀ ਗਈ ਪਲੱਗਇਨ ਨੂੰ ਬਦਲਣਾ ਹੈ।

ਕਦੋਂ ਪੇਸ਼ੇਵਰ ਸਹਾਇਤਾ ਲੈਣੀ ਚਾਹੀਦੀ ਹੈ?

ਕੁਝ ਸਥਿਤੀਆਂ ਵਿੱਚ, ਆਪਣੇ ਆਪ ਦਖਲ ਦੇਣ ਨਾਲ ਜੋਖਮ ਵਧ ਸਕਦਾ ਹੈ। ਵਿਸ਼ੇਸ਼ ਤੌਰ 'ਤੇ ਭੁਗਤਾਨ ਵਾਲੀ ਢਾਂਚਾ, ਵਿਸ਼ੇਸ਼ ਸਾਫਟਵੇਅਰ ਸਮੀਕਰਨ, ਮੈਂਬਰਸ਼ਿਪ ਸਿਸਟਮ, ਬਹੁਭਾਸ਼ੀ ਢਾਂਚਾ, ਉੱਚ ਟਰੈਫਿਕ ਵਾਲੀਆਂ ਖਬਰਾਂ ਦੀ ਸਾਈਟ ਜਾਂ ਕਾਰਪੋਰੇਟ ਪੋਰਟਲ ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਹੋਏ, ਗਲਤੀ ਨੂੰ ਬੇਤਰਤੀਬੀ ਨਾਲ ਪਲੱਗਇਨ ਬੰਦ ਕਰਕੇ ਹੱਲ ਕਰਨ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰਨ ਨਾਲ ਡੇਟਾ ਖੋਜਣ ਅਤੇ ਆਮਦਨ ਦੇ ਨੁਕਸਾਨ ਦਾ ਕਾਰਨ ਬਣ ਸਕਦਾ ਹੈ। ਜੇ ਗਲਤੀ ਦੀਆਂ ਡਾਇਰੀਆਂ ਵਿੱਚ ਵਿਸ਼ੇਸ਼ ਥੀਮ ਫਾਇਲਾਂ, API ਸਮੀਕਰਨ ਜਾਂ ਡੇਟਾਬੇਸ ਦੀਆਂ ਕਵੈਰੀਆਂ ਦਿਖਾਈ ਦਿੰਦੀਆਂ ਹਨ, ਤਾਂ ਵਿਸ਼ੇਸ਼ਗਿਆਨ ਦੀ ਸਹਾਇਤਾ ਲੈਣਾ ਜ਼ਿਆਦਾ ਸੁਰੱਖਿਅਤ ਹੈ।