ตัวอย่างสถานการณ์: WordPress Error 500 หลังอัปเดต Plugin

หมายเหตุ: บทความนี้เป็นตัวอย่างสถานการณ์ที่รวบรวมจากรูปแบบปัญหาที่พบบ่อย ไม่ใช่บันทึกงานของลูกค้ารายใดรายหนึ่ง ตัวเลขและระยะเวลาในบทความใช้เพื่ออธิบายขั้นตอนเท่านั้น

หนึ่งในปัญหาที่เจ้าของเว็บ WordPress พบบ่อยที่สุดคือ Error 500 (Internal Server Error) ที่โผล่ขึ้นมาทันทีหลังกดอัปเดต Plugin — หน้าเว็บขาวโพลน หรือแสดงข้อความ 500 ทั้งไซต์ รวมถึง wp-admin ก็เข้าไม่ได้ เคสนี้เกิดขึ้นกับเว็บ WooCommerce ขนาดกลางที่ให้บริการลูกค้า B2C เจ้าของเว็บโทรมาหาทีมงานในช่วงเช้าตรู่ เพราะยอดขายหายไปทันทีนับตั้งแต่กดอัปเดต Plugin ชุดใหญ่เมื่อคืนที่แล้ว

อาการที่พบในเคสนี้

เจ้าของเว็บรายงานอาการดังนี้

• หน้า Front-end แสดงหน้าขาวเปล่า หรือข้อความ 500 Internal Server Error ทุก URL
• เข้า /wp-admin ไม่ได้ แสดง Error เช่นเดียวกัน
• ลูกค้าไม่สามารถสั่งซื้อสินค้าได้ ยอดขายหยุดชะงัก
• ไม่มี Error Message ปรากฏบนหน้าจอ (PHP Error reporting ถูกปิดไว้)

อาการเหล่านี้ชี้ชัดว่าเป็น PHP Fatal Error ระดับ Server ไม่ใช่แค่ปัญหาการแสดงผล การที่ wp-admin เข้าไม่ได้ด้วยแปลว่า WordPress Core เองโหลดไม่สำเร็จ

สาเหตุที่แท้จริง: Plugin ขัดแย้งกันหลังอัปเดต

จากการตรวจสอบ PHP Error Log ใน cPanel (ไฟล์ error_log ที่ Root ของโฮสต์) พบข้อความ

• PHP Fatal error: Cannot redeclare function wc_get_product() in .../plugins/some-plugin/includes/functions.php on line 214
• Plugin ที่อัปเดตได้ประกาศฟังก์ชันซ้ำกับ WooCommerce เวอร์ชันใหม่ที่อัปเดตพร้อมกัน
• นอกจากนี้ยังพบว่า Plugin ตัวหนึ่งต้องการ PHP 8.1 ขึ้นไป แต่เซิร์ฟเวอร์ยังรัน PHP 7.4

ปัญหา WordPress Error 500 ประเภทนี้มักเกิดเมื่ออัปเดตหลาย Plugin พร้อมกันโดยไม่ทดสอบก่อน โดยเฉพาะเมื่อ Plugin ที่อัปเดตมีการเปลี่ยน PHP Version Requirement

ขั้นตอนการแก้ไขที่ทีมดำเนินการ

ขั้นที่ 1: เปิด PHP Error Log และระบุ Plugin ต้นเหตุ

เข้าไปที่ cPanel → Error Logs หรือเปิดไฟล์ error_log โดยตรงผ่าน File Manager อ่าน Fatal Error บรรทัดล่าสุด แล้วจดชื่อไฟล์และ Plugin ที่ก่อปัญหา

ขั้นที่ 2: ปิด Plugin ต้นเหตุผ่าน FTP/SFTP

เมื่อเข้า wp-admin ไม่ได้ ให้ใช้ FTP/SFTP เข้าไปที่โฟลเดอร์ wp-content/plugins/ แล้วเปลี่ยนชื่อโฟลเดอร์ของ Plugin ต้นเหตุ เช่น จาก some-plugin เป็น some-plugin_DISABLED WordPress จะมองว่า Plugin นั้นไม่มีอยู่และ Deactivate ให้อัตโนมัติ

ขั้นที่ 3: ทดสอบว่าเว็บกลับมาแล้ว

โหลดหน้าเว็บอีกครั้ง ถ้าเว็บกลับมาปกติ แปลว่า Plugin นั้นคือต้นเหตุ จากนั้นเข้า wp-admin แล้วตรวจสอบ PHP Version ที่ Plugin กำหนด เทียบกับเวอร์ชันที่เซิร์ฟเวอร์รัน

ขั้นที่ 4: แก้ไข PHP Version หรือเลือก Plugin เวอร์ชัน Compatible

ในเคสนี้ ทีมงานอัปเกรด PHP เป็น 8.1 ผ่าน cPanel → MultiPHP Manager แล้วเปิด Plugin กลับตามปกติ นอกจากนี้ยังลบ Plugin ตัวที่มีฟังก์ชันซ้ำออก แล้วติดตั้งเวอร์ชัน Compatible แทน เว็บกลับมาออนไลน์ภายใน 35 นาที

วิธีป้องกันไม่ให้เกิดซ้ำ

• ตรวจสอบ Changelog ก่อนอัปเดต — อ่านว่า Plugin เวอร์ชันใหม่เปลี่ยนแปลงอะไร โดยเฉพาะ PHP Requirement
• อัปเดตทีละตัว — อย่ากด “Update All” พร้อมกันบนเว็บจริง
• สำรองข้อมูลก่อนอัปเดตทุกครั้ง — Backup ทั้ง Files และ Database ด้วย Plugin เช่น UpdraftPlus
• ใช้ Staging Site — ทดสอบการอัปเดตบนสภาพแวดล้อมทดสอบก่อน แล้วค่อย Deploy ขึ้น Production
• เปิด Maintenance Mode — แสดงหน้า “อยู่ระหว่างบำรุงรักษา” ให้ลูกค้าเห็น แทนที่จะเห็น Error 500
• ตรวจสอบ PHP Error Log สม่ำเสมอ — ปัญหาหลายอย่างจะแสดงเป็น Warning ก่อน จะกลายเป็น Fatal Error

สำหรับเว็บ WooCommerce ที่มียอดขายทุกวัน ขอแนะนำให้อ่านบทความเพิ่มเติมเรื่อง WooCommerce Checkout ไม่ได้ และ เคสตัวอย่าง WooCommerce Webhook Error เพื่อเตรียมรับมือปัญหาที่อาจตามมา

เมื่อไหร่ควรเรียกผู้เชี่ยวชาญ

หากคุณทำตามขั้นตอนข้างต้นแล้วยังแก้ไม่ได้ หรือไม่สะดวก Access ผ่าน FTP ควรเรียกผู้เชี่ยวชาญในกรณีเหล่านี้

• เว็บยังขาวหลังจาก Deactivate Plugin ทุกตัวแล้ว (อาจเป็นปัญหา Theme หรือ Core File เสียหาย)
• ไม่สามารถเข้า FTP/cPanel ได้ หรือไม่มีสิทธิ์แก้ไข PHP Version
• Error Log มีข้อความซับซ้อนที่ระบุ Database Error หรือ Memory Exhausted
• เว็บ Down นานเกิน 30 นาที และมีผลต่อยอดขาย

ทีม WP Doctor Thailand พร้อมให้ความช่วยเหลือ สามารถดูรายละเอียดบริการได้ที่ บริการล้างไวรัส WordPress และการแก้ปัญหาเว็บฉุกเฉิน รวมถึงอ่านเพิ่มเติมเรื่อง Checklist ความปลอดภัย WordPress เพื่อเสริมความมั่นคงของเว็บในระยะยาว

คำถามที่พบบ่อย