WordPress "Fatal Error" ਦਾ ਹੱਲ: ਸਾਈਟ ਦੇ ਡਿੱਗਣ ਦਾ ਕਾਰਨ ਬਣਨ ਵਾਲੇ ਪਲੱਗਇਨ ਨੂੰ ਲੱਭਣਾ

WordPress Fatal Error ਦਾ ਹੱਲ ਕਰਨ ਲਈ ਸਭ ਤੋਂ ਤੇਜ਼ ਅਤੇ ਸੁਰੱਖਿਅਤ ਤਰੀਕਾ ਹੈ ਕਿ ਪਹਿਲਾਂ ਸਾਈਟ ਨੂੰ ਪ੍ਰਵੇਸ਼ਯੋਗ ਬਣਾਉਣਾ, ਫਿਰ ਗਲਤੀ ਦਾ ਕਾਰਨ ਬਣਨ ਵਾਲੇ ਪਲੱਗਇਨ ਨੂੰ ਇਕ-ਇਕ ਕਰਕੇ ਆਈਸੋਲੇਟ ਕਰਕੇ ਲੱਭਣਾ। ਆਮਤੌਰ 'ਤੇ ਸਮੱਸਿਆ; ਗੈਰ-ਸਮਰਥਿਤ ਪਲੱਗਇਨ ਅੱਪਡੇਟ, PHP ਵਰਜਨ ਟਕਰਾਅ, ਥੀਮ ਅਤੇ ਪਲੱਗਇਨ ਵਿਚਕਾਰ ਫੰਕਸ਼ਨ ਟਕਰਾਅ ਜਾਂ ਯਾਦاشت ਸੀਮਾ ਦੀ ਘਾਟ ਤੋਂ ਹੋ ਸਕਦੀ ਹੈ। ਜੇਕਰ ਤੁਸੀਂ ਪ੍ਰਬੰਧਨ ਪੈਨਲ 'ਚ ਦਾਖਲ ਨਹੀਂ ਹੋ ਸਕਦੇ, ਤਾਂ ਤੁਸੀਂ FTP, ਫਾਈਲ ਪ੍ਰਬੰਧਕ ਜਾਂ ਹੋਸਟਿੰਗ ਕੰਟਰੋਲ ਪੈਨਲ ਦੇ ਜ਼ਰੀਏ ਪਲੱਗਇਨ ਫੋਲਡਰ ਨੂੰ ਤਾਤਕਾਲਿਕ ਤੌਰ 'ਤੇ ਅਯੋਗ ਕਰ ਸਕਦੇ ਹੋ, ਫਿਰ ਗਲਤੀ ਲੌਗਾਂ ਤੋਂ ਪਤਾ ਲਗਾ ਸਕਦੇ ਹੋ ਕਿ ਕਿਹੜਾ ਪਲੱਗਇਨ ਸਾਈਟ ਨੂੰ ਡਿੱਗਣ ਦਾ ਕਾਰਨ ਬਣਿਆ।

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

WordPress Fatal Error ਕੀ ਹੈ?

WordPress Fatal Error ਇੱਕ ਸੰਕਟ ਸਥਿਤੀ ਹੈ ਜੋ ਉਸ ਵੇਲੇ ਦਿਖਾਈ ਦਿੰਦੀ ਹੈ ਜਦੋਂ PHP ਪਾਸੇ ਐਸਾ ਗਲਤੀ ਹੁੰਦੀ ਹੈ ਕਿ ਇਸ ਦਾ ਕੰਮ ਜਾਰੀ ਨਹੀਂ ਰਹਿੰਦਾ। ਇਹ ਗਲਤੀ ਕਈ ਵਾਰੀ ਸਫੈਦ ਸਕਰੀਨ, ਕਈ ਵਾਰੀ ਸਿਰਫ਼ "ਕ੍ਰਿਟਿਕਲ ਗਲਤੀ ਹੋਈ" ਦਾ ਸੁਨੇਹਾ ਅਤੇ ਕਈ ਵਾਰੀ ਕਿਸੇ ਖਾਸ PHP ਫਾਈਲ ਨੂੰ ਦਰਸਾਉਂਦੀ ਤਕਨੀਕੀ ਗਲਤੀ ਦੇ ਨਤੀਜੇ ਵਜੋਂ ਸਾਹਮਣੇ ਆਉਂਦੀ ਹੈ। WordPress ਦਾ ਕੋਰ, ਥੀਮ ਫਾਈਲਾਂ ਅਤੇ ਪਲੱਗਇਨ PHP ਦੇ ਨਾਲ ਕੰਮ ਕਰਦੇ ਹਨ, ਇਸ ਲਈ ਇੱਕ ਹੀ ਗੈਰ-ਸਮਰਥਿਤ ਕੋਡ ਲਾਈਨ ਸਾਰੀ ਸਾਈਟ ਦੇ ਖੁਲਣ ਨੂੰ ਰੋਕ ਸਕਦੀ ਹੈ।

ਉਦਾਹਰਨ ਵਜੋਂ, ਜੇਕਰ ਇੱਕ ਪਲੱਗਇਨ PHP 8.2 ਨਾਲ ਸਮਰਥਿਤ ਨਹੀਂ ਹੈ, ਤਾਂ ਜਦੋਂ ਤੁਸੀਂ ਹੋਸਟਿੰਗ ਪਾਸੇ PHP ਵਰਜਨ ਨੂੰ ਉੱਚਾ ਕਰਦੇ ਹੋ, ਤਾਂ ਸਾਈਟ Fatal Error ਦੇ ਸਕਦੀ ਹੈ। ਇਸੇ ਤਰ੍ਹਾਂ, ਜੇਕਰ ਦੋ ਵੱਖਰੇ ਪਲੱਗਇਨ ਇੱਕੋ ਫੰਕਸ਼ਨ ਨੂੰ ਪਰਿਭਾਸ਼ਿਤ ਕਰਨ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰ ਰਹੇ ਹਨ, ਤਾਂ WordPress ਦੂਜੀ ਵਾਰੀ ਉਸ ਫੰਕਸ਼ਨ ਨੂੰ ਲੋਡ ਨਹੀਂ ਕਰ ਸਕਦੀ, ਇਸ ਲਈ ਕੰਮ ਕਰਨਾ ਰੁਕ ਸਕਦਾ ਹੈ। ਇਸ ਲਈ, ਗਲਤੀ ਦੇ ਸੁਨੇਹੇ ਵਿੱਚ ਦਿਖਾਈ ਦੇਣ ਵਾਲਾ ਫਾਈਲ ਪਾਥ ਬਹੁਤ ਮਹੱਤਵਪੂਰਣ ਹੈ। ਜੇਕਰ ਪਾਥ wp-content/plugins/ਪਲੱਗਇਨ-ਨਾਮ ਦੇ ਰੂਪ ਵਿੱਚ ਜਾਰੀ ਰਹਿੰਦਾ ਹੈ, ਤਾਂ ਸਮੱਸਿਆ ਸੰਭਵਤ: ਸੰਬੰਧਿਤ ਪਲੱਗਇਨ ਵਿੱਚ ਹੈ।

Fatal Error ਦੇ ਲੱਛਣ ਅਤੇ ਪਹਿਲੀ ਜਾਂਚ ਦੇ ਨਕਸ਼ੇ

Fatal Error ਹਮੇਸ਼ਾ ਇੱਕੋ ਹੀ ਸਕਰੀਨ 'ਤੇ ਨਹੀਂ ਦਿਖਾਈ ਦਿੰਦਾ। WordPress 5.2 ਅਤੇ ਉਸ ਤੋਂ ਬਾਅਦ ਦੇ ਵਰਜਨਾਂ ਵਿੱਚ, ਬਹੁਤ ਸਾਰੇ ਕ੍ਰਿਟਿਕਲ ਗਲਤੀਆਂ, ਸਾਈਟ ਦੇ ਪ੍ਰਬੰਧਕ ਨੂੰ ਈ-ਮੇਲ ਦੁਆਰਾ ਰੀਕਵਰੀ ਮੋਡ ਲਿੰਕ ਭੇਜ ਕੇ ਪ੍ਰਬੰਧਿਤ ਕੀਤੀ ਜਾ ਸਕਦੀ ਹੈ। ਪਰ ਜੇਕਰ ਈ-ਮੇਲ ਨਹੀਂ ਪੁੱਜਦਾ ਜਾਂ ਗਲਤੀ ਬਹੁਤ ਹੀ ਮੁੱਢਲੇ ਪੜਾਅ 'ਤੇ ਹੁੰਦੀ ਹੈ, ਤਾਂ ਹੱਥੋਂ ਦਖਲ ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ। ਹੇਠਾਂ ਦਿੱਤੇ ਲੱਛਣ, ਪਲੱਗਇਨ ਦੇ ਕਾਰਨ ਇੱਕ Fatal Error ਦੀ ਸੰਭਾਵਨਾ ਨੂੰ ਮਜ਼ਬੂਤ ਕਰਦੇ ਹਨ:

• ਸਾਈਟ ਦਾ ਮੁੱਖ ਫਰੰਟ ਪੂਰੀ ਤਰ੍ਹਾਂ ਸਫੈਦ ਸਕਰੀਨ 'ਤੇ ਰਹਿੰਦਾ ਹੈ।
• ਪ੍ਰਬੰਧਨ ਪੈਨਲ 'ਤੇ ਦਾਖਲ ਹੋਣ ਵੇਲੇ "ਕ੍ਰਿਟਿਕਲ ਗਲਤੀ ਹੋਈ" ਦਾ ਸੂਚਨਾ ਦਿਖਾਈ ਦਿੰਦੀ ਹੈ।
• ਕਿਸੇ ਖਾਸ ਪੰਨਾ, ਉਦਾਹਰਨ ਵਜੋਂ ਭੁਗਤਾਨ ਪੰਨਾ ਜਾਂ ਸੰਪਰਕ ਫਾਰਮ ਖੁਲਣ 'ਤੇ ਸਾਈਟ ਡਿੱਗਦੀ ਹੈ।
• ਆਖਰੀ ਵਾਰੀ ਕੀਤੀ ਗਈ ਪਲੱਗਇਨ ਅੱਪਡੇਟ ਦੇ ਤੁਰੰਤ ਬਾਅਦ ਗਲਤੀ ਸ਼ੁਰੂ ਹੁੰਦੀ ਹੈ।
• ਗਲਤੀ ਦੇ ਸੁਨੇਹੇ ਵਿੱਚ wp-content/plugins ਫੋਲਡਰ ਹੇਠਾਂ ਇੱਕ ਫਾਈਲ ਨਾਮ ਦਿਖਾਈ ਦਿੰਦਾ ਹੈ।
• ਸਰਵਰ ਗਲਤੀ ਲੌਗਾਂ ਵਿੱਚ PHP Fatal error ਦੀਆਂ ਲਾਈਨਾਂ ਦੁਹਰਾਈਆਂ ਜਾਂਦੀਆਂ ਹਨ।

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

ਤੀਬਰ ਪਛਾਣ ਟੇਬਲ: ਗਲਤੀ ਕਿੱਥੇ ਤੋਂ ਆ ਰਹੀ ਹੈ?

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

ਕੰਮ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਸੁਰੱਖਿਅਤ ਤਿਆਰੀ

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

• 1. ਪੂਰਾ ਬੈਕਅਪ ਲਓ: ਫਾਈਲਾਂ ਅਤੇ ਡੇਟਾਬੇਸ ਨੂੰ ਇਕੱਠੇ ਬੈਕਅਪ ਕੀਤਾ ਜਾਣਾ ਚਾਹੀਦਾ ਹੈ। ਸਿਰਫ public_html ਫੋਲਡਰ ਲੈਣਾ ਕਾਫੀ ਨਹੀਂ ਹੈ।
• 2. ਗਲਤੀ ਦੇ ਸਮੇਂ ਨੂੰ ਨੋਟ ਕਰੋ: ਸਮੱਸਿਆ ਸ਼ੁਰੂ ਹੋਣ ਦਾ ਸਮਾਂ ਸਰਵਰ ਲੌਗਾਂ ਵਿੱਚ ਸਹੀ ਲਾਈਨ ਤੱਕ ਪਹੁੰਚਣ ਵਿੱਚ ਸਹਾਇਤਾ ਕਰੇਗਾ।
• 3. ਆਖਰੀ ਬਦਲਾਵਾਂ ਨੂੰ ਸੂਚੀਬੱਧ ਕਰੋ: ਅੱਪਡੇਟ ਕੀਤੇ ਗਏ ਪਲੱਗਇਨ, PHP ਵਰਜਨ, ਥੀਮ ਬਦਲਾਅ ਅਤੇ ਨਵੀਂ ਕੋਡ ਸ਼ਾਮਲੀਆਂ ਨੂੰ ਲਿਖਿਆ ਜਾਣਾ ਚਾਹੀਦਾ ਹੈ।
• 4. ਜਿੱਥੇ ਸੰਭਵ ਹੋਵੇ, ਸਟੇਜਿੰਗ ਵਾਤਾਵਰਨ ਦੀ ਵਰਤੋਂ ਕਰੋ: ਲਾਈਵ ਸਾਈਟ ਦੀ ਥਾਂ ਕਾਪੀ ਵਾਤਾਵਰਨ ਵਿੱਚ ਟੈਸਟ ਕਰਨਾ ਜ਼ਿਆਦਾ ਸੁਰੱਖਿਅਤ ਹੈ। WordPress ਹੋਸਟਿੰਗ
• 5. ਪ੍ਰਬੰਧਕ ਪਹੁੰਚਾਂ ਦੀ ਜਾਂਚ ਕਰੋ: FTP, ਹੋਸਟਿੰਗ ਪੈਨਲ ਅਤੇ ਡੇਟਾਬੇਸ ਪਹੁੰਚ ਤੁਹਾਡੇ ਹੱਥਾਂ ਵਿੱਚ ਹੋਣੀ ਚਾਹੀਦੀ ਹੈ।

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

ਕਦਮ ਦਰ ਕਦਮ WordPress Fatal Error ਦਾ ਹੱਲ

1. WordPress ਰੀਕਵਰੀ ਮੋਡ ਈ-ਮੇਲ ਦੀ ਜਾਂਚ ਕਰੋ

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

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

2. ਜੇਕਰ ਤੁਸੀਂ ਪ੍ਰਬੰਧਨ ਪੈਨਲ 'ਤੇ ਨਹੀਂ ਜਾ ਸਕਦੇ ਤਾਂ ਸਾਰੇ ਪਲੱਗਇਨ ਨੂੰ ਅਯੋਗ ਕਰੋ

ਜੇਕਰ ਪ੍ਰਬੰਧਨ ਪੈਨਲ ਖੁਲਦਾਂ ਨਹੀਂ ਹੈ, ਤਾਂ ਸਭ ਤੋਂ ਆਸਾਨ ਤਰੀਕਾ wp-content/plugins ਫੋਲਡਰ ਦਾ ਨਾਮ ਤਾਤਕਾਲਿਕ ਤੌਰ 'ਤੇ ਬਦਲਣਾ ਹੈ। FTP ਕਲਾਇੰਟ, SSH ਜਾਂ ਹੋਸਟਿੰਗ ਫਾਈਲ ਪ੍ਰਬੰਧਕ ਦੇ ਜ਼ਰੀਏ public_html/wp-content ਫੋਲਡਰ ਵਿੱਚ ਜਾਓ। plugins ਫੋਲਡਰ ਨੂੰ plugins-pasif ਵਜੋਂ ਦੁਬਾਰਾ ਨਾਮਕਰਨ ਕਰੋ। WordPress ਇਸ ਫੋਲਡਰ ਨੂੰ ਨਹੀਂ ਲੱਭੇਗਾ, ਇਸ ਲਈ ਸਾਰੇ ਪਲੱਗਇਨ ਅਯੋਗ ਹੋ ਜਾਣਗੇ।

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

• wp-content/plugins ਫੋਲਡਰ ਨੂੰ plugins-pasif ਬਣਾਓ।
• ਸਾਈਟ ਨੂੰ ਗੁਪਤ ਟੈਬ ਵਿੱਚ ਟੈਸਟ ਕਰੋ।
• ਜੇਕਰ ਸਾਈਟ ਖੁਲ ਰਹੀ ਹੈ, ਤਾਂ ਫੋਲਡਰ ਦਾ ਨਾਮ ਮੁੜ plugins ਰੱਖੋ।
• ਪਲੱਗਇਨ ਨੂੰ ਇਕ-ਇਕ ਕਰਕੇ ਸਰਗਰਮ ਕਰੋ।
• ਜਦੋਂ ਗਲਤੀ ਮੁੜ ਆਉਂਦੀ ਹੈ, ਤਾਂ ਆਖਰੀ ਸਰਗਰਮ ਕੀਤੇ ਗਏ ਪਲੱਗਇਨ ਨੂੰ ਨੋਟ ਕਰੋ।

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

3. ਸਮੱਸਿਆ ਵਾਲੇ ਪਲੱਗਇਨ ਨੂੰ ਇਕ-ਇਕ ਕਰਕੇ ਆਈਸੋਲੇਟ ਕਰੋ

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

ਉਦਾਹਰਨ ਵਜੋਂ: ਇੱਕ ਸੁਰੱਖਿਆ ਪਲੱਗਇਨ ਅਤੇ ਕੈਸ਼ ਪਲੱਗਇਨ ਇੱਕੋ ਫਾਈਲ ਦੀ ਆਗਿਆ ਵਿੱਚ ਦਖਲ ਦੇ ਰਹੇ ਹੋ ਸਕਦੇ ਹਨ। ਜਾਂ WooCommerce ਪਲੱਗਇਨ ਅੱਪਡੇਟ ਹੋ ਗਿਆ ਹੈ, ਪਰ ਭੁਗਤਾਨ ਗੇਟਵੇ ਪਲੱਗਇਨ ਪੁਰਾਣਾ ਰਹਿ ਗਿਆ ਹੈ, ਜਿਸ ਕਾਰਨ Fatal Error ਹੋਈ ਹੈ। ਇਸ ਹਾਲਤ ਵਿੱਚ, ਗਲਤੀ WooCommerce ਦੇ ਨਾਲ ਦਿਖਾਈ ਦੇ ਸਕਦੀ ਹੈ, ਪਰ ਅਸਲ ਦੋਸ਼ੀ ਭੁਗਤਾਨ ਪਲੱਗਇਨ ਹੋ ਸਕਦੀ ਹੈ।

• ਸਭ ਤੋਂ ਪਹਿਲਾਂ ਕੋਰ ਪਲੱਗਇਨ ਨੂੰ ਸਰਗਰਮ ਕਰੋ: WooCommerce, SEO ਪਲੱਗਇਨ, ਫਾਰਮ ਪਲੱਗਇਨ ਜਿਵੇਂ ਸਾਈਟ ਦੀਆਂ ਬੁਨਿਆਦੀ ਕਾਰਜਾਂ।
• ਫਿਰ ਸਹਾਇਕ ਪਲੱਗਇਨਾਂ ਨੂੰ ਖੋਲ੍ਹੋ: ਕੈਸ਼, ਸੁਰੱਖਿਆ, ਰੀਡਾਇਰੈਕਟ, ਗੈਲਰੀ, ਸਮਾਜਿਕ ਸਾਂਝੇਦਾਰੀ।
• ਹਰ ਸਰਗਰਮੀ ਦੇ ਬਾਅਦ ਸਾਈਟ ਦੇ ਮੁੱਖ ਫਰੰਟ ਅਤੇ ਪ੍ਰਬੰਧਨ ਪੈਨਲ ਦੀ ਜਾਂਚ ਕਰੋ।
• ਭੁਗਤਾਨ, ਕਾਰਟ, ਸੰਪਰਕ ਫਾਰਮ ਅਤੇ ਮੈਂਬਰਸ਼ਿਪ ਲਾਗਇਨ ਵਰਗੀਆਂ ਕ੍ਰਿਟਿਕਲ ਪੰਨਿਆਂ ਨੂੰ ਵੀ ਬਿਨਾਂ ਕਿਸੇ ਸੰਦੇਹ ਦੇਖੋ।
• ਜਦੋਂ ਗਲਤੀ ਦੁਬਾਰਾ ਆਉਂਦੀ ਹੈ, ਤਾਂ ਆਖਰੀ ਸਰਗਰਮ ਕੀਤੇ ਗਏ ਪਲੱਗਇਨ ਅਤੇ ਗਲਤੀ ਦਾ ਸੁਨੇਹਾ ਨੋਟ ਕਰੋ।

ਇਸ ਪੜਾਅ ਦਾ ਮਕਸਦ ਸਿਰਫ਼ ਸਾਈਟ ਖੋਲ੍ਹਣਾ ਨਹੀਂ, ਸਗੋਂ ਜ根 ਕਾਰਨ ਨੂੰ ਠੀਕ ਤਰ੍ਹਾਂ ਪਛਾਣਣਾ ਹੈ। ਗਲਤ ਪਲੱਗਇਨ ਨੂੰ ਦੋਸ਼ ਦੇਣਾ, ਸਮੱਸਿਆ ਨੂੰ ਕੁਝ ਦਿਨਾਂ ਬਾਅਦ ਦੁਬਾਰਾ ਆਉਣ ਦਾ ਕਾਰਨ ਬਣ ਸਕਦਾ ਹੈ।

4. ਗਲਤੀ ਲੌਗਾਂ ਤੋਂ ਨਿਸ਼ਚਿਤ ਸਬੂਤ ਸੰਭਾਲੋ

ਸਰਵਰ ਗਲਤੀ ਲੌਗਾਂ, Fatal Error ਦੇ ਹੱਲ ਵਿੱਚ ਸਭ ਤੋਂ ਮਜ਼ਬੂਤ ਸਬੂਤ ਹੁੰਦੇ ਹਨ। ਹੋਸਟਿੰਗ ਕੰਟਰੋਲ ਪੈਨਲ ਵਿੱਚ Error Log, ਗਲਤੀ ਲੌਗਾਂ ਜਾਂ ਸਮਾਨ ਭਾਗ ਮਿਲਦਾ ਹੈ। ਇਸਦੇ ਨਾਲ, WordPress ਪਾਸੇ wp-config.php ਫਾਈਲ ਵਿੱਚ ਡਿਬੱਗ ਸੈਟਿੰਗਾਂ ਸ਼ਾਮਲ ਕਰਕੇ wp-content/debug.log ਫਾਈਲ ਬਣਾਈ ਜਾ ਸਕਦੀ ਹੈ।

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

ਲੌਗ ਲਾਈਨਾਂ ਵਿੱਚ ਖਾਸ ਕਰਕੇ ਹੇਠਾਂ ਦਿੱਤੀਆਂ ਸ਼ਬਦਾਵਲੀ ਦੀ ਖੋਜ ਕਰੋ: PHP Fatal error, Uncaught Error, require_once failed, allowed memory size exhausted, call to undefined function, cannot redeclare. ਲਾਈਨ ਦੇ ਜਾਰੀ ਹਿੱਸੇ ਵਿੱਚ ਫਾਈਲ ਪਾਥ ਅਤੇ ਲਾਈਨ ਨੰਬਰ ਹੁੰਦੇ ਹਨ। ਉਦਾਹਰਨ ਵਜੋਂ, wp-content/plugins/ornek-eklenti/includes/class-loader.php on line 214 ਦਾ ਅਰਥ ਹੈ ਕਿ ornek-eklenti ਫੋਲਡਰ ਵਿੱਚ ਇੱਕ ਫਾਈਲ ਗਲਤੀ ਨੂੰ ਉਤੇਜਿਤ ਕਰ ਰਹੀ ਹੈ।

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

5. PHP ਵਰਜਨ ਅਤੇ ਯਾਦਾਸ਼ਤ ਸੀਮਾ ਦੀ ਜਾਂਚ ਕਰੋ

ਹਰ Fatal Error ਸਿੱਧਾ ਖਰਾਬ ਪਲੱਗਇਨ ਦੇ ਅਰਥ ਨਹੀਂ ਹੁੰਦਾ। ਪਲੱਗਇਨ, ਤੁਸੀਂ ਜੋ PHP ਵਰਜਨ ਵਰਤ ਰਹੇ ਹੋ ਉਸ ਨਾਲ ਗੈਰ-ਸਮਰਥਿਤ ਹੋ ਸਕਦੀ ਹੈ। 2026 ਤੱਕ ਮਾਡਰਨ WordPress ਸਥਾਪਨਾਵਾਂ ਵਿੱਚ ਅਪਡੇਟ PHP ਵਰਜਨਾਂ ਦੀ ਕਾਰਗੁਜ਼ਾਰੀ ਅਤੇ ਸੁਰੱਖਿਆ ਦੇ ਮਾਮਲਿਆਂ ਵਿੱਚ ਮਹੱਤਵਪੂਰਣ ਹੈ; ਪਰ ਪੁਰਾਣੇ ਪਲੱਗਇਨ ਕੁਝ ਨਵੀਂ PHP ਵਿਵਹਾਰਾਂ ਨੂੰ ਸਮਰਥਨ ਨਹੀਂ ਕਰ ਸਕਦੇ। ਇਸਦਾ ਉਲਟ ਵੀ ਹੋ ਸਕਦਾ ਹੈ: ਬਹੁਤ ਪੁਰਾਣੇ PHP ਵਰਜਨ ਵਿੱਚ ਕੰਮ ਕਰਨ ਵਾਲੀ ਸਾਈਟ, ਨਵੇਂ ਪਲੱਗਇਨ ਲਈ ਲੋੜੀਂਦੇ ਫੰਕਸ਼ਨਾਂ ਦਾ ਸਮਰਥਨ ਨਹੀਂ ਕਰਦੀ, ਜਿਸ ਨਾਲ ਇਹ ਡਿੱਗ ਜਾਂਦੀ ਹੈ।

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

• ਛੋਟੀ ਕਾਰਪੋਰੇਟ WordPress ਸਾਈਟਾਂ ਲਈ 256 MB PHP memory_limit ਬਹੁਤ ਵਾਰੀ ਕਾਫੀ ਹੁੰਦਾ ਹੈ।
• WooCommerce ਜਾਂ ਮੈਂਬਰਸ਼ਿਪ ਸਾਈਟਾਂ ਵਿੱਚ 512 MB ਇੱਕ ਸੁਰੱਖਿਅਤ ਸ਼ੁਰੂਆਤੀ ਮੁੱਲ ਹੁੰਦਾ ਹੈ।
• ਭਾਰੀ ਟ੍ਰੈਫਿਕ ਜਾਂ ਬਹੁਤ ਪਲੱਗਇਨ ਵਾਲੀਆਂ ਬਣਾਵਟਾਂ ਵਿੱਚ ਸਰੋਤ ਯੋਜਨਾ ਦਾ ਵਾਧਾ ਕੀਤਾ ਜਾਣਾ ਚਾਹੀਦਾ ਹੈ।
• PHP ਵਰਜਨ ਬਦਲਣ ਸਮੇਂ ਪਹਿਲਾਂ ਸਟੇਜਿੰਗ ਵਾਤਾਵਰਨ ਵਿੱਚ ਟੈਸਟ ਕੀਤਾ ਜਾਣਾ ਚਾਹੀਦਾ ਹੈ।

ਜੇਕਰ ਸਰੋਤ ਦੀ ਕਮਜ਼ੋਰੀ ਵਾਰੰ-ਵਾਰ ਹੋ ਰਹੀ ਹੈ, ਤਾਂ ਸਿਰਫ਼ memory_limit ਵਧਾਉਣ ਦੀ ਥਾਂ, ਪਲੱਗਇਨਾਂ ਦੀ ਗਿਣਤੀ, ਡੇਟਾਬੇਸ ਦੀਆਂ ਪੁੱਛਗਿੱਛਾਂ ਅਤੇ ਹੋਸਟਿੰਗ ਪੈਕੇਜ ਦੀ ਇੱਕ ਨਾਲ ਜਾਂਚ ਕਰਨੀ ਬਹੁਤ ਸਿਹਤਮੰਦ ਹੈ। WordPress ਹੋਸਟਿੰਗ ਪੈਕੇਜ

ਜੇਕਰ ਪ੍ਰਬੰਧਨ ਪੈਨਲ ਖੁਲਦਾ ਨਹੀਂ, ਤਾਂ ਵਰਤਣ ਵਾਲੇ ਵਿਕਲਪਿਕ ਤਰੀਕੇ

FTP ਜਾਂ ਫਾਈਲ ਪ੍ਰਬੰਧਕ ਨਾਲ ਪਲੱਗਇਨ ਫੋਲਡਰ ਬਦਲਣਾ

ਸਭ ਤੋਂ ਭਰੋਸੇਮੰਦ ਮੈਨੂਅਲ ਤਰੀਕਿਆਂ ਵਿੱਚੋਂ ਇੱਕ ਪਲੱਗਇਨ ਫੋਲਡਰ ਦੇ ਨਾਮ ਨੂੰ ਬਦਲਣਾ ਹੈ। ਜੇਕਰ ਸਮੱਸਿਆ ਵਾਲਾ ਪਲੱਗਇਨ ਪਤਾ ਹੈ, ਤਾਂ ਤੁਸੀਂ ਸਾਰੇ plugins ਫੋਲਡਰ ਨੂੰ ਅਯੋਗ ਕਰਨ ਦੀ ਥਾਂ ਸਿਰਫ਼ ਸੰਬੰਧਿਤ ਪਲੱਗਇਨ ਦੇ ਫੋਲਡਰ ਦਾ ਨਾਮ ਬਦਲ ਸਕਦੇ ਹੋ। ਉਦਾਹਰਨ ਵਜੋਂ, wp-content/plugins/siteyi-cokerten-eklenti ਫੋਲਡਰ ਨੂੰ siteyi-cokerten-eklenti-pasif ਬਣਾਉਣਾ ਕਾਫੀ ਹੈ। WordPress ਇਸ ਪਲੱਗਇਨ ਨੂੰ ਲੋਡ ਨਹੀਂ ਕਰੇਗਾ ਅਤੇ ਗਲਤੀ ਦੂਰ ਹੋ ਸਕਦੀ ਹੈ।

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

WP-CLI ਨਾਲ ਪਲੱਗਇਨ ਅਯੋਗ ਕਰਨਾ

ਜੇਕਰ ਤੁਹਾਡੇ ਕੋਲ SSH ਪਹੁੰਚ ਹੈ, ਤਾਂ WP-CLI ਇੱਕ ਪੇਸ਼ੇਵਰ ਅਤੇ ਤੇਜ਼ ਹੱਲ ਹੈ। ਤੁਸੀਂ ਕਮਾਂਡ ਲਾਈਨ ਤੋਂ ਸਾਰੇ ਪਲੱਗਇਨਾਂ ਦੀ ਸੂਚੀ ਦੇਖ ਸਕਦੇ ਹੋ, ਕਿਸੇ ਖਾਸ ਪਲੱਗਇਨ ਨੂੰ ਅਯੋਗ ਕਰ ਸਕਦੇ ਹੋ ਜਾਂ ਸਾਰੇ ਨੂੰ ਇਕੱਠੇ ਬੰਦ ਕਰ ਸਕਦੇ ਹੋ। ਉਦਾਹਰਨ ਵਜੋਂ, ਸਾਰੇ ਪਲੱਗਇਨ ਬੰਦ ਕਰਕੇ ਸਾਈਟ ਨੂੰ ਟੈਸਟ ਕਰਨਾ, ਫਿਰ ਇਕ-ਇਕ ਕਰਕੇ ਸਰਗਰਮ ਕਰਨਾ ਕੁਝ ਮਿੰਟਾਂ ਵਿੱਚ ਪੂਰਾ ਕੀਤਾ ਜਾ ਸਕਦਾ ਹੈ।

WP-CLI ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਸਮੇਂ, ਤੁਹਾਡੇ ਸਹੀ WordPress ਡਾਇਰੈਕਟਰੀ ਵਿੱਚ ਹੋਣ ਦੀ ਯਕੀਨੀ ਬਣਾਓ। ਗਲਤ ਡਾਇਰੈਕਟਰੀ ਵਿੱਚ ਕਮਾਂਡ ਚਲਾਉਣਾ ਕਿਸੇ ਨਤੀਜੇ ਨਹੀਂ ਦੇ ਸਕਦਾ ਜਾਂ ਵੱਖਰੇ ਸਥਾਪਨਾ 'ਤੇ ਕਾਰਵਾਈ ਕਰਨ ਦਾ ਕਾਰਨ ਬਣ ਸਕਦਾ ਹੈ। ਏਜੰਸੀਆਂ ਅਤੇ ਵਿਕਾਸਕਾਂ ਲਈ, ਇਹ ਤਰੀਕਾ ਬਹੁਤ ਸਾਰੇ WordPress ਸਾਈਟਾਂ ਵਿੱਚ ਮਿਆਰੀ ਗਲਤੀ ਹੱਲ ਦੀ ਪ੍ਰਕਿਰਿਆ ਦਾ ਹਿੱਸਾ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ।

ਡੇਟਾਬੇਸ ਤੋਂ ਸਰਗਰਮ ਪਲੱਗਇਨਾਂ ਨੂੰ ਰੀਸੈੱਟ ਕਰਨਾ

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

ਜੇਕਰ ਤੁਹਾਡੀ ਤਕਨੀਕੀ ਜਾਣਕਾਰੀ ਸੀਮਤ ਹੈ, ਤਾਂ ਡੇਟਾਬੇਸ ਦੀ ਥਾਂ ਫਾਈਲ ਦੇ ਨਾਮ ਬਦਲਣ ਦੀ ਵਿਧੀ ਨੂੰ ترجیح ਦਿਓ। ਫਾਈਲ ਸਿਸਟਮ ਰਾਹੀਂ ਕੀਤੀ ਜਾਣ ਵਾਲੀ ਤਾਤਕਾਲਿਕ ਅਯੋਗਤਾ, ਬਹੁਤ ਸਾਰੇ ਸਾਈਟ ਮਾਲਕਾਂ ਲਈ ਘੱਟ ਖਤਰਾ ਹੁੰਦੀ ਹੈ।

ਸਮੱਸਿਆ ਵਾਲੇ ਪਲੱਗਇਨ ਨੂੰ ਲੱਭਣ ਤੋਂ ਬਾਅਦ ਤੁਹਾਨੂੰ ਕੀ ਕਰਨਾ ਚਾਹੀਦਾ ਹੈ?

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

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

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

Fatal Error ਮੁੜ ਨਾ ਹੋਵੇ ਇਸ ਲਈ ਕੀ ਕੀਤੇ ਜਾਣੇ ਚਾਹੀਦੇ ਉਪਾਅ

WordPress ਸਾਈਟਾਂ 'ਤੇ ਗਲਤੀ ਦੇ ਖਤਰੇ ਨੂੰ ਪੂਰੀ ਤਰ੍ਹਾਂ ਦੂਰ ਕਰਨਾ ਸੰਭਵ ਨਹੀਂ ਹੈ; ਪਰ ਚੰਗੀ ਸੰਭਾਲ ਦੀ ਰੁਟੀਨ ਨਾਲ ਇਸਨੂੰ ਬਹੁਤ ਹੱਦ ਤੱਕ ਘਟਾਇਆ ਜਾ ਸਕਦਾ ਹੈ। ਖਾਸ ਕਰਕੇ ਆਮਦਨ ਵਾਲੀਆਂ ਕਾਰਪੋਰੇਟ ਸਾਈਟਾਂ 'ਤੇ ਅੱਪਡੇਟ ਪ੍ਰਕਿਰਿਆ ਬੇਤਰਤੀਬੀ ਨਾਲ ਨਹੀਂ, ਬਲਕਿ ਨਿਯੰਤਰਿਤ ਤਰੀਕੇ ਨਾਲ ਚਲਾਈ ਜानी ਚਾਹੀਦੀ ਹੈ।

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

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

ਲਾਈਵ ਸਾਈਟ 'ਤੇ ਗਲਤੀ ਦੂਰ ਕਰਨ ਦੇ ਸਮੇਂ ਕੀ ਨਹੀਂ ਕਰਨਾ ਚਾਹੀਦਾ ਹੈ

Fatal Error ਦੌਰਾਨ ਕੁਝ ਦਖਲ ਸਮੱਸਿਆ ਨੂੰ ਹੱਲ ਕਰਨ ਦੀ ਥਾਂ ਵਧਾ ਸਕਦੇ ਹਨ। ਖਾਸ ਕਰਕੇ ਤੁਰੰਤ ਖੋਜਣ ਵਾਲੀਆਂ ਪੁਰਾਣੀਆਂ ਸੁਝਾਵਾਂ ਹਰ ਸਾਈਟ ਲਈ ਉਚਿਤ ਨਹੀਂ ਹੁੰਦੀਆਂ। ਹੇਠਾਂ ਦਿੱਤੀਆਂ ਗਲਤੀਆਂ ਤੋਂ ਬਚਣਾ, ਡੇਟਾ ਖੋਹਣ ਅਤੇ ਲੰਬੇ ਸਮੇਂ ਦੇ ਬੰਦ ਹੋਣ ਤੋਂ ਬਚਾਉਂਦਾ ਹੈ।

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

ਖਾਸ ਕਰਕੇ nulled ਜਾਂ ਬਿਨਾਂ ਲਾਇਸੈਂਸ ਵਾਲੇ ਪਲੱਗਇਨ Fatal Error ਦੇ ਨਾਲ-ਨਾਲ ਸੁਰੱਖਿਆ ਖੁਲਾਸਿਆਂ, ਮਾਲਵੇਅਰ ਕੋਡ ਅਤੇ ਡੇਟਾ ਲਿਕਾਅ ਦੇ ਖਤਰੇ ਦਾ ਕਾਰਨ ਬਣ ਸਕਦੇ ਹਨ। ਜੇਕਰ ਕੋਈ ਪਲੱਗਇਨ ਭੁਗਤਾਨੀ ਹੈ, ਤਾਂ ਇਸ ਨੂੰ ਆਧਿਕਾਰਕ ਲਾਇਸੈਂਸ ਨਾਲ ਵਰਤਣਾ ਚਾਹੀਦਾ ਹੈ; ਅੱਪਡੇਟ ਅਤੇ ਸਹਾਇਤਾ ਦੇ ਚੈਨਲ ਖੁੱਲ੍ਹੇ ਰੱਖਣੇ ਚਾਹੀਦੇ ਹਨ।

ਤੁਸੀਂ ਕਦੋਂ ਹੋਸਟਿੰਗ ਸਹਾਇਤਾ ਨੂੰ ਸੰਪਰਕ ਕਰਨਾ ਚਾਹੀਦਾ ਹੈ?