อธิบาย WordPress หน้าขาว (White Screen of Death)

หน้าขาว (White Screen of Death) คือ PHP fatal error ที่คุณมองไม่เห็น WordPress เจอ error ที่กู้ไม่ได้ระหว่างเรนเดอร์ PHP หยุดทำงาน และเพราะบนเซิร์ฟเวอร์ production มีการปิดการแสดง error ไว้ หน้าเว็บเลยขึ้นมาว่างเปล่าแทนที่จะพิมพ์บอกสาเหตุ วิธีแก้แทบไม่ต้องเดาเลย เปิด debug log ขึ้นมา เปิดไฟล์ wp-content/debug.log แล้วอ่านบรรทัด fatal บรรทัดสุดท้าย มันจะบอกชื่อไฟล์ที่เป็นต้นเหตุแบบเป๊ะ ๆ ซึ่งเกือบทุกครั้งจะเป็นปลั๊กอิน WordPress หรือธีม และบรรทัดเดียวนั้นแหละคือทั้งหมดของการแก้ไข

ทำไมหน้าถึงว่างเปล่า

PHP มีการตั้งค่าที่ชื่อ display_errors บนเครื่องสำหรับพัฒนา (development) มักจะเปิดไว้ ดังนั้นเวลาเจอ fatal error มันจะพิมพ์ stack trace ออกมาบนหน้าจอ แต่บนโฮสต์จริงค่านี้จะปิดไว้ตั้งแต่แรก เพราะการปล่อยให้ path ของไฟล์และ error รั่วไปให้ผู้เข้าชมเห็นถือเป็นปัญหาด้านความปลอดภัย ดังนั้นเวลามีอะไรโยน fatal error ออกมา ไม่ว่าจะเป็นการเรียกฟังก์ชันที่ไม่มีอยู่แล้ว คลาสที่ไม่ได้ถูกโหลด หรือ syntax error ในการอัพเดตปลั๊กอิน PHP ก็จะตายและไม่ส่งอะไรกลับมาเลย เบราว์เซอร์ของคุณเลยเรนเดอร์เอกสารเปล่า ๆ ออกมา นั่นแหละคือ “หน้าขาว”

ตั้งแต่ WordPress 5.2 เป็นต้นมามีตัวจัดการ fatal error (WP_Fatal_Error_Handler) ที่พยายามดักจับ error พวกนี้ เวลามันทำงานได้ คุณจะไม่เจอหน้าเปล่า แต่จะเจอข้อความ “There has been a critical error on this website” พร้อมอีเมลส่งไปยังที่อยู่ของแอดมิน ซึ่งบ่อยครั้งจะมี error ตัวจริงและลิงก์ไปยัง Recovery Mode อยู่ด้วย หน้าที่ว่าง เปล่าจริง ๆ มักหมายความว่า error เกิดขึ้นก่อนที่ตัวจัดการนั้นจะได้ทำงาน เช่น parse/syntax error (ถูกจับตอน compile time) must-use plugin ที่พัง หรือ fatal ใน functions.php ของธีมที่ใช้งานอยู่ ไม่ว่าจะกรณีไหน สาเหตุก็ถูกจดไว้อยู่ที่ไหนสักที่เสมอ คุณแค่ต้องเปิดการจดบันทึกขึ้นมา

แก้ตามลำดับนี้

1. เปิด log แก้ไข wp-config.php ผ่าน SFTP แล้วเพิ่มบรรทัดพวกนี้เหนือบรรทัด /* That's all, stop editing! */

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

การตั้ง WP_DEBUG_DISPLAY เป็น false จะกันไม่ให้ error โผล่บนหน้าเว็บสาธารณะ ขณะที่ WP_DEBUG_LOG จะเขียน error ลงไฟล์ wp-content/debug.log ลองรีโหลดหน้าที่พังอีกครั้งเพื่อสร้างรายการใหม่ใน log

2. อ่านบรรทัด fatal ตัวสุดท้าย เปิด wp-content/debug.log แล้วดูที่ท้ายไฟล์

tail -n 30 wp-content/debug.log

สิ่งที่คุณกำลังมองหาคือบรรทัดแบบนี้

[14-Jul-2026 09:12:44 UTC] PHP Fatal error:  Uncaught Error: Call to undefined function wc_get_product() in /var/www/html/wp-content/plugins/some-addon/includes/class-widget.php:88

path จะบอกชื่อตัวการ plugins/some-addon นั่นแหละคือคำตอบ ถ้า trace ยาวหรือข้อความอ่านแล้วงง (Allowed memory size exhausted, Cannot redeclare, หรือชื่อคลาสที่คุณไม่รู้จัก) ลองวางมันลงใน ตัวถอดรหัส error log ของเรา มันจะตัดส่วนที่รกออก บอกว่า path ชี้ไปที่ปลั๊กอินหรือธีมตัวไหน และอธิบายว่า error ชนิดนั้น ๆ หมายความว่าอย่างไร

3. ปิดการทำงานของส่วนที่ถูกระบุชื่อ คุณเข้า /wp-admin ไม่ได้ ก็เลยต้องทำผ่าน SFTP เปลี่ยนชื่อโฟลเดอร์ของปลั๊กอินที่มีปัญหา เช่น some-addon → some-addon.off WordPress โหลดโฟลเดอร์ที่หาไม่เจอไม่ได้ มันเลยจะปิดปลั๊กอินตัวนั้นและเว็บก็กลับมาใช้งานได้ ถ้า log ชี้ไปที่ธีมของคุณ ให้สลับไปใช้ธีมเริ่มต้นด้วยการเปลี่ยนชื่อโฟลเดอร์ของธีมที่ใช้งานอยู่ WordPress จะย้อนกลับไปใช้ธีมที่มากับตัวติดตั้งอย่าง twentytwentysomething

4. ถ้า log ไม่ยอมเขียน แสดงว่า wp-content เขียนไม่ได้ หรือ error อยู่ที่ระดับเซิร์ฟเวอร์ ให้ไปดูที่ PHP error log ของโฮสต์แทน

find . -name "error_log" -newermt "-1 hour"

ข้อมูลเหมือนกัน แค่คนละไฟล์ ระบบ cPanel/Apache มักจะวางไฟล์ error_log ไว้ที่ root ของเว็บหรือในไดเรกทอรีที่มีปัญหา

สิ่งที่ไม่ควรทำ

อย่าเพิ่งไปเพิ่ม memory limit เฉย ๆ คำแนะนำที่ถูกพูดซ้ำ ๆ มากที่สุดในเน็ตคือให้ดัน WP_MEMORY_LIMIT ขึ้นไปเป็น 256M หรือ 512M แต่วิธีนั้นแก้หน้าขาวได้ก็ต่อเมื่อ log บอกจริง ๆ ว่า Allowed memory size of N bytes exhausted เท่านั้น ถ้า error คือ Call to undefined function การเพิ่ม memory ไม่ช่วยอะไรเลย คุณแค่ไปเปลี่ยนค่าตั้งมั่ว ๆ แล้วหน้าจอก็ยังขาวอยู่ดี อ่าน log ก่อน แล้วค่อยเพิ่ม memory เฉพาะเมื่อ memory เป็นปัญหาตามที่ระบุไว้จริง ๆ

อย่าล้าง cache แล้วคิดว่านั่นคือการวินิจฉัย หน้าขาวคือ PHP ตายบนเซิร์ฟเวอร์ก่อนที่จะมี HTML เกิดขึ้น asset ที่ค้างอยู่ใน cache ไม่มีทางทำให้เอกสารว่างเปล่าได้ (แต่ ปลั๊กอินทำ cache ที่พังทำได้ ซึ่ง log ก็จะบอกชื่อมันอยู่ดี นั่นแหละคือประเด็น)

อย่าแก้หรือติดตั้ง core ของ WordPress ใหม่ fatal แทบไม่เคยอยู่ใน wp-includes หรือ wp-admin เลย มันอยู่ที่ปลั๊กอินหรือธีมที่ log ชี้ไป การติดตั้ง core ใหม่ทั้งช้า ทั้งเสี่ยง และเป็นการรักษาอาการที่คุณยังไม่ได้ยืนยันว่าเป็นสาเหตุจริง

อย่าปิดปลั๊กอินทั้งหมดแล้วเปิดกลับทีละตัวแบบเดาสุ่ม วิธีไล่หา (bisect) ใช้ได้ผลก็จริง แต่มันเป็นทางที่ช้า log บอกโฟลเดอร์ที่เป็นต้นเหตุแบบเป๊ะ ๆ ในขั้นตอนเดียว ใช้วิธี “ปิดทุกอย่าง” เฉพาะเมื่อไม่มี error ที่อ่านได้เลยจริง ๆ เท่านั้น

อย่าเปิด display_errors ทิ้งไว้บน production พอเว็บกลับมาใช้งานได้แล้ว ให้ลบ define สำหรับ debug ออก (หรือตั้ง WP_DEBUG กลับเป็น false) การพิมพ์ error ให้ผู้เข้าชมเห็นจะเปิดเผย path ของคุณ

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

ถ้า log บอกชื่อปลั๊กอินแต่ปิดมันแล้วหน้าจอก็ยังไม่หายขาว แสดงว่ามี fatal ตัวที่สองซ่อนอยู่ใต้ตัวแรก ให้เปิด log กลับขึ้นมาแล้วอ่านบรรทัดสุดท้ายใหม่ fatal มันซ้อนกันได้ ถ้าตัวข้อความเองแหละคือกำแพงที่ทำให้ไปต่อไม่ได้ ลองวางมันลงใน ตัวถอดรหัส error log แล้วปล่อยให้มันแปลชนิดของ error และ path ของไฟล์ให้คุณ หน้าขาวจะยังเป็นปริศนาอยู่ก็แค่ตอนที่ log ยังปิดอยู่เท่านั้น