There Has Been a Critical Error on This Website: ข้อความนี้แปลว่าอะไร และแก้อย่างไร

ข้อความนั้นแปลว่า PHP เจอ fatal error ระหว่างสร้างหน้าเว็บของคุณ และ WordPress ดักจับไว้ได้ก่อนที่มันจะกลายเป็นหน้าจอขาวเปล่า ข้อผิดพลาดนั้นมีอยู่จริง เจาะจง และถูกบันทึกไว้แล้ว เพียงแต่ WordPress ไม่ยอมพิมพ์ออกมาในเบราว์เซอร์ เพราะ stack trace บนหน้าเว็บสาธารณะจะเปิดเผยพาธไฟล์และโค้ดให้ใครก็ตามที่เข้ามาดู

การแก้จึงไม่ใช่การเดา แต่คือ อ่านข้อผิดพลาดตัวจริง แล้วลงมือตามที่มันบอก

เกิดอะไรขึ้นกันแน่

ตั้งแต่ WordPress 5.2 เป็นต้นมา มีตัวจัดการ fatal error อยู่ในแกนหลักของระบบ เมื่อ PHP ตายกลางคัน ตัวจัดการนี้จะเข้ามาแทนที่ผลลัพธ์ของการพัง ด้วยประโยคสุภาพกลาง ๆ และถ้ามันพอจะระบุได้ว่าปลั๊กอินหรือธีมตัวไหนเป็นเหตุ ก็จะพยายามส่งอีเมลพร้อมลิงก์เข้าสู่ recovery mode ไปให้ผู้ดูแลเว็บไซต์

นี่คือเหตุผลที่คุณเห็นข้อความนี้แทนหน้าจอขาวแบบเดิม ถือว่าดีขึ้น แต่ก็แปลว่าข้อมูลสำหรับวินิจฉัยถูกซ่อนไว้ตั้งแต่ต้น ข้อความนี้มีอยู่สองแบบ

สิ่งที่คุณเห็น	เห็นที่ไหน	บอกอะไรคุณ
”There has been a critical error on this website.”	หน้าเว็บฝั่งผู้ชม ตอนไม่ได้ล็อกอิน	เกิด fatal error แต่ไม่เปิดเผยรายละเอียดใด ๆ
ประโยคเดิม บวก “Learn more about troubleshooting WordPress”	หน้าเว็บฝั่งผู้ชม หรือใน wp-admin	ข้อผิดพลาดเดียวกัน WordPress แค่เสนอหน้าคู่มือให้
”…Please check your site admin email inbox for instructions.”	หน้าเว็บฝั่งผู้ชม	ตัวจัดการเชื่อว่าได้ส่งอีเมลกู้คืนไปแล้ว

แบบที่สามคือแบบที่มีประโยชน์ที่สุด เพราะแปลว่า WordPress ระบุได้ว่าปลั๊กอินหรือธีมตัวไหนทำให้พัง และพยายามยื่นทางเข้าให้คุณแล้ว

ขั้นที่ 1: ตรวจอีเมล recovery mode

WordPress ส่งลิงก์กู้คืนไปยัง อีเมลผู้ดูแลเว็บไซต์ ซึ่งก็คืออีเมลในหน้า Settings, General ที่บ่อยครั้งไม่ใช่อีเมลที่คุณใช้ล็อกอิน ตรวจกล่องนั้น และตรวจสแปมด้วย

ในอีเมลจะมีลิงก์ยาว ๆ ที่ลงท้ายประมาณ ?action=enter_recovery_mode เปิดลิงก์นั้นแล้วคุณจะเข้า wp-admin ในโหมดกู้คืน ปลั๊กอินหรือธีมที่มีปัญหาจะถูกหยุดไว้และขึ้นแจ้งเตือนสีแดงด้านบน จากตรงนั้นคุณปิดการใช้งานมันได้ตามปกติ

มีข้อควรรู้สองอย่างที่ต้องพูดกันตรง ๆ ข้อแรก อีเมลนี้ถูกสร้างโดยโปรเซส PHP ตัวเดียวกับที่เพิ่งพัง บนโฮสต์ที่อาจไม่มีระบบส่งเมลใช้งานได้เลย การส่งไม่ถึงจึงเกิดขึ้นบ่อย และการที่ไม่มีอีเมลเข้ามาก็ไม่ได้บอกอะไรเกี่ยวกับข้อผิดพลาดเลย ข้อสอง ลิงก์กู้คืนมีวันหมดอายุ (ค่าเริ่มต้นราวหนึ่งวัน) อีเมลเก่าในกล่องจดหมายจึงอาจใช้ไม่ได้แล้ว ให้กระตุ้นให้เกิดข้อผิดพลาดใหม่ด้วยการโหลดหน้าเว็บซ้ำ แล้วรออีเมลฉบับใหม่

ถ้าอยากให้อีเมลไปเข้ากล่องที่คุณอ่านจริง ๆ กำหนดไว้ตรง ๆ ใน wp-config.php:

define( 'RECOVERY_MODE_EMAIL', '[email protected]' );

ขั้นที่ 2: อ่านข้อผิดพลาดตัวจริง

นี่คือขั้นตอนที่เปลี่ยนเว็บพัง ๆ ให้กลายเป็นงานห้านาที เพิ่มบรรทัดเหล่านี้ลงใน wp-config.php เหนือบรรทัดที่บอกให้หยุดแก้ไข:

define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );
@ini_set( 'display_errors', 0 );

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

โหลดหน้าที่พังซ้ำหนึ่งครั้ง แล้วเปิด wp-content/debug.log รายการล่าสุดจะหน้าตาประมาณนี้:

PHP Fatal error:  Uncaught Error: Call to undefined function some_plugin_helper()
in /home/user/public_html/wp-content/plugins/some-plugin/includes/render.php:214

พาธไฟล์คือคำตอบ ถ้าชี้เข้าไปใน wp-content/plugins/ ปลั๊กอินตัวนั้นคือต้นเหตุ ถ้าชี้เข้า wp-content/themes/ ก็คือธีม ซึ่งบ่อยมากคือโค้ดที่เพิ่งวางลงใน functions.php

ถ้าไม่มี debug.log โผล่มาเลย อาจเป็นเพราะไดเรกทอรีเขียนไม่ได้ หรือปลั๊กอินความปลอดภัยย้ายที่เก็บ log ไปไว้ที่อื่น ให้ถอยไปดู PHP error log ของโฮสต์แทน แผงควบคุมส่วนใหญ่มีหัวข้อ “Error Log” หรือ “Logs” และ fatal error ตัวเดียวกันจะอยู่ในนั้นพร้อมเวลาที่เกิด

ลองวางข้อความนั้นลงใน ตัวถอดรหัส error log ของ WordPress เพื่อแปลถ้อยคำแบบ PHP ให้เป็นความหมายในทางปฏิบัติ และบอกว่าควรเปิดไฟล์ไหนก่อน

ลบบรรทัดดีบักเหล่านี้ออกเมื่อทำเสร็จ การเปิด WP_DEBUG ทิ้งไว้บนเว็บจริงทำให้ดิสก์เต็ม และถ้าวันหนึ่ง WP_DEBUG_DISPLAY ถูกสลับกลับ พาธของเซิร์ฟเวอร์จะถูกพิมพ์ออกสู่สาธารณะ

ขั้นที่ 3: กลับเข้า wp-admin ให้ได้

ถ้า wp-admin ก็ตายไปด้วยและไม่มีอีเมลกู้คืนเข้ามา ให้ปิดปลั๊กอินทั้งหมดที่ระดับไฟล์ เชื่อมต่อผ่าน SFTP (หรือ file manager ของโฮสต์) แล้วเปลี่ยนชื่อโฟลเดอร์เดียว:

mv wp-content/plugins wp-content/plugins-off

WordPress หาโฟลเดอร์ปลั๊กอินไม่เจอ จึงปิดการใช้งานทั้งหมด และการเข้าหน้าแอดมินมักกลับมาได้ จากนั้น:

1. เปลี่ยนชื่อโฟลเดอร์กลับเป็น plugins ทุกตัวจะยังปิดอยู่ เพราะ WordPress บันทึกไว้แล้วว่าไม่ได้ใช้งาน
2. เปิดปลั๊กอินทีละตัว แล้วโหลดหน้าเว็บฝั่งผู้ชมหลังเปิดแต่ละตัว
3. ตัวที่ทำให้ข้อผิดพลาดกลับมาคือตัวต้นเหตุ

ถ้าปิดปลั๊กอินหมดแล้วเว็บยังพัง ธีมคือผู้ต้องสงสัย เปลี่ยนชื่อโฟลเดอร์ของธีมที่ใช้งานอยู่ใน wp-content/themes/ แล้ว WordPress จะถอยไปใช้ธีมมาตรฐานถ้ามีติดตั้งไว้

สามสาเหตุที่ควรรู้จัก

การอัปเดตปลั๊กอินหรือธีมที่ทำให้พัง พบบ่อยที่สุดแบบทิ้งห่าง log ระบุชื่อไฟล์ให้ตรง ๆ ให้ย้อนปลั๊กอินตัวนั้นกลับไปเวอร์ชันก่อนหน้า หรือปิดมันไว้แล้วติดต่อผู้พัฒนาพร้อมแนบบรรทัดใน log ไปด้วย

เวอร์ชัน PHP ไม่ตรงกัน โฮสต์อัปเกรด PHP ตามรอบ บางครั้งก็แทบไม่แจ้งล่วงหน้า โค้ดที่เขียนสำหรับ PHP รุ่นเก่าอาจอ่านไม่ผ่านเลยบนรุ่นใหม่ สัญญาณที่ชัดคือคุณไม่ได้ทำอะไรเลย แต่ทุกอย่างพังพร้อมกัน การย้อน PHP ลงหนึ่งเวอร์ชันย่อยในแผงโฮสติ้งเป็นการวินิจฉัยที่ใช้ได้ แต่ให้ถือว่าเป็นการซื้อเวลา ไม่ใช่การแก้ เพราะ PHP รุ่นเก่าจะเลิกได้รับแพตช์ความปลอดภัย

หน่วยความจำหมด ใน log จะเขียนว่า “Allowed memory size of X bytes exhausted” การเพิ่มลิมิตใน wp-config.php ถือว่าสมเหตุสมผล:

define( 'WP_MEMORY_LIMIT', '256M' );

แต่ต้องเข้าใจตามจริงว่ามันทำอะไร มันแค่ยกเพดานออก ไม่ได้แก้ว่าอะไรกินหน่วยความจำ 256MB เพื่อเรนเดอร์หน้าเดียว ถ้าต้องเพิ่มลิมิตขึ้นเรื่อย ๆ แสดงว่ามีบางอย่าง มักเป็นการนำเข้าข้อมูล page builder หรือคิวรีที่เขียนไม่ดี ที่เป็นปัญหาตัวจริง

คำแนะนำที่ข้ามไปได้อย่างสบายใจ

“เพิ่มลิมิตหน่วยความจำสิ” เกี่ยวข้องก็ต่อเมื่อ log บอกจริง ๆ ว่าหน่วยความจำหมด นอกนั้นมันไม่เปลี่ยนอะไรเลย แถมยังกลบความจริงว่าคุณไม่เคยอ่านข้อผิดพลาด

“ติดตั้ง WordPress core ใหม่” ไฟล์แกนหลักแทบไม่เคยเป็นต้นเหตุ และการเขียนทับมันคือการเสียเวลาที่ควรใช้อ่าน log แค่บรรทัดเดียว

“ปิดตัวจัดการ fatal error ไปเลย” มีค่าคงที่สำหรับปิดมันอยู่จริง ผลที่ได้คือข้อผิดพลาดดิบถูกพิมพ์ออกบนเว็บสาธารณะแทนที่จะถูกดักไว้ ซึ่งเปิดเผยพาธไฟล์ให้ผู้เข้าชม ใช้ WP_DEBUG_LOG คู่กับการปิด WP_DEBUG_DISPLAY แทน ได้ข้อมูลเท่ากัน โดยไม่เปิดเผยอะไรเลย

“ล้างแคชสิ” fatal error เกิดใน PHP ก่อนที่ปลั๊กอินแคชจะทันเสิร์ฟอะไรได้ ถ้ามีหน้าข้อผิดพลาดที่ถูกแคชไว้ถูกเสิร์ฟอยู่ การล้างแคชช่วยได้ หลังจาก คุณแก้ต้นเหตุแล้ว ไม่ใช่แทนการแก้

ยังติดอยู่ใช่ไหม

ถ้า log ชี้ไปที่ไฟล์ในแกนหลักแทนที่จะเป็นอะไรใน wp-content คำอธิบายที่เป็นไปได้มากกว่าคือมีปลั๊กอินที่โหลดก่อนหน้าไปทำให้สถานะที่แกนหลักพึ่งพาเสียหาย ไม่ใช่ไฟล์แกนหลักเสียเอง ปิดทุกอย่างด้วยการเปลี่ยนชื่อโฟลเดอร์ ยืนยันว่าเว็บโหลดได้สะอาด แล้วค่อยใส่ปลั๊กอินกลับทีละตัว ตัวสุดท้ายที่คุณเปิดก่อนข้อผิดพลาดจะกลับมา คือตัวที่ควรรายงาน พร้อมแนบบรรทัดใน log ไปด้วย