เปิด Debug Mode ใน WordPress หาสาเหตุเว็บพัง ทีละขั้นตอน

เว็บ WordPress แสดงหน้าขาว ขึ้น Error 500 หรือ Plugin ทำงานผิดปกติ แต่ไม่รู้สาเหตุ — นี่คือปัญหาที่นักพัฒนา WordPress ทุกคนเจอ Debug Mode คือเครื่องมือที่ WordPress มีให้ตั้งแต่ต้น ช่วยให้เห็น PHP Error ที่ซ่อนอยู่เพื่อแก้ไขได้ตรงจุด

บทความนี้จะแนะนำวิธีตั้งค่า WP_DEBUG และเครื่องมือ Debug เพิ่มเติมทุกตัว พร้อมคำเตือนที่ต้องรู้ก่อนเปิดบน Production Server

1. WordPress Debug Mode คืออะไร?

ตามปกติ WordPress ซ่อน PHP Error และ Warning ทั้งหมดไว้ ผู้เยี่ยมชมจะเห็นแค่หน้าขาวหรือข้อความว่า "There has been a critical error" โดยไม่รู้ว่าเกิดอะไรขึ้น

Debug Mode คือชุดตัวแปร (Constants) ใน wp-config.php ที่สั่งให้ WordPress:

• แสดง PHP Error, Warning, Notice บนหน้าจอ (หรือบันทึกลงไฟล์ log)
• โหลด JavaScript และ CSS แบบไม่ Minify เพื่อ Debug ได้ง่ายขึ้น
• บันทึก Database Query ทุกคำสั่งเพื่อวิเคราะห์ประสิทธิภาพ

2. เปิด WP_DEBUG ใน wp-config.php

ไฟล์ wp-config.php อยู่ที่ Root Directory ของ WordPress (โฟลเดอร์เดียวกับ wp-admin, wp-content) แก้ไขได้ผ่าน File Manager ใน DirectAdmin หรือ FTP

ค้นหาบรรทัดนี้ใน wp-config.php:

define( 'WP_DEBUG', false );

แล้วแก้ไขเป็น:

// เปิด Debug Mode
define( 'WP_DEBUG', true );

// บันทึก Error ลงไฟล์ (แนะนำสำหรับ Production)
define( 'WP_DEBUG_LOG', true );

// ซ่อน Error ไม่แสดงบนหน้าจอ (ปลอดภัยกว่า)
define( 'WP_DEBUG_DISPLAY', false );

// โหลด JS/CSS แบบไม่ Minify
define( 'SCRIPT_DEBUG', true );

// แสดง Database Errors (เฉพาะ Dev เท่านั้น)
define( 'WP_DEBUG_DISPLAY', true ); // เปลี่ยนเป็น true เฉพาะเครื่อง Dev

3. WP_DEBUG_LOG vs WP_DEBUG_DISPLAY

ทั้งสองตัวทำงานต่างกัน และควรเลือกให้เหมาะกับสถานการณ์:

สำหรับ Production Server ใช้ WP_DEBUG_LOG = true + WP_DEBUG_DISPLAY = false เพื่อบันทึก Error โดยไม่แสดงให้ผู้เยี่ยมชมเห็น

4. SCRIPT_DEBUG สำหรับ JavaScript

SCRIPT_DEBUG สั่งให้ WordPress โหลด JavaScript และ CSS เวอร์ชัน Full (ไม่ Minify) แทนเวอร์ชันที่บีบอัดแล้ว ทำให้อ่านและ Debug Code ได้ง่ายขึ้น

define( 'SCRIPT_DEBUG', true );

ใช้ตัวนี้เมื่อ:

• JavaScript ทำงานผิดปกติและต้องการดูโค้ดต้นฉบับ
• ต้องการตรวจสอบว่า Plugin หรือ Theme ใดโหลด Script ไฟล์ใด
• ใช้ Browser DevTools เพื่อ Debug JavaScript Error

5. อ่าน Error Log จาก debug.log

เมื่อเปิด WP_DEBUG_LOG = true WordPress จะสร้างไฟล์ debug.log ที่ /wp-content/debug.log อัตโนมัติ

วิธีอ่าน debug.log:

1. เปิด File Manager ใน DirectAdmin
2. ไปที่โฟลเดอร์ public_html/wp-content/
3. คลิกขวาที่ debug.log → View หรือ Edit
4. ดูบรรทัดล่าสุดก่อน — Error ใหม่สุดจะอยู่ท้ายไฟล์

ตัวอย่าง Error ที่พบบ่อย

[16-May-2026 10:30:45 UTC] PHP Fatal error: Uncaught Error: Call to undefined function
  plugin_function() in /home/user/public_html/wp-content/plugins/myplugin/functions.php:42

[16-May-2026 10:30:46 UTC] PHP Warning: include(/wp-content/themes/mytheme/missing-file.php):
  Failed to open stream: No such file or directory in /home/user/public_html/wp-settings.php:500

จาก Error ด้านบน บรรทัดแรกบอกว่า Plugin ชื่อ myplugin เรียกใช้ Function ที่ไม่มีอยู่ บรรทัดที่สองบอกว่า Theme กำลัง Include ไฟล์ที่ไม่พบ ทำให้สามารถแก้ไขได้ตรงจุด

5b. วิธีตีความ Error Message ที่พบบ่อยใน debug.log

Error ที่ปรากฏใน debug.log มีหลายประเภท แต่ละประเภทบ่งบอกถึงสาเหตุและวิธีแก้ที่แตกต่างกัน ตารางต่อไปนี้ช่วยให้คุณตีความ Error ได้รวดเร็วขึ้น:

ตัวอย่าง: การอ่าน Stack Trace

Stack Trace บอกลำดับการ Call Function ที่นำไปสู่ Error ให้อ่านจากล่างขึ้นบน บรรทัดล่างสุดคือจุดที่ Function ถูกเรียกเป็นครั้งแรก บรรทัดบนสุดคือจุดที่ Error เกิดขึ้นจริง:

PHP Fatal error: Maximum execution time of 30 seconds exceeded
  in /home/user/public_html/wp-includes/class-http.php on line 423
  Stack trace:
  #0 /wp-content/plugins/myplugin/import.php(88): WP_Http->request()
  #1 /wp-includes/cron.php(467): myplugin_import_data()
  #2 {main}
  thrown in /wp-includes/class-http.php on line 423

จาก Stack Trace นี้ เห็นได้ว่า Plugin ชื่อ myplugin เรียก import_data() ผ่าน Cron Job ซึ่งทำ HTTP Request ที่ใช้เวลานานเกิน 30 วินาที — ต้องเพิ่ม max_execution_time หรือแบ่งงาน Import ให้เล็กลง

6. Query Monitor Plugin

Query Monitor เป็น Developer Plugin ฟรีที่แสดงข้อมูล Debug ใน WordPress Admin Bar แบบ Real-time โดยไม่ต้องแก้ไขไฟล์ใดๆ

ข้อมูลที่ Query Monitor แสดง:

• Database Queries — แสดงทุก SQL Query, ใช้เวลากี่วินาที, มาจาก Plugin/Theme ใด
• PHP Errors — แสดง Error ทุกประเภทในแถบสีแดงที่เห็นชัดเจน
• Hooks & Actions — แสดง Action และ Filter ที่ถูก Execute บนหน้านั้น
• Scripts & Styles — แสดง Script และ CSS ทั้งหมดที่โหลดพร้อมที่มา
• HTTP API Calls — แสดง External API Request ทั้งหมด
• Rewrite Rules — ช่วย Debug ปัญหา Permalink และ 404

6b. Debug Plugin เพิ่มเติมที่น่าใช้ใน WordPress

นอกจาก Query Monitor แล้ว ยังมี Plugin อื่นที่ช่วย Debug WordPress ได้ในบริบทที่ต่างกัน:

Kint Debugger

Kint เป็น PHP Debugger Library ที่แสดงตัวแปร Array และ Object ใน WordPress ได้อย่างสวยงามและอ่านง่ายกว่า var_dump() มาก โดยใช้งานผ่านฟังก์ชัน d($variable) หรือ dd($variable) ซึ่งแสดงผลแบบ Interactive Collapsible Tree ใน Browser

// ติดตั้ง kint-php/kint ผ่าน Composer แล้วใช้งานใน functions.php
d($wpdb->queries); // แสดง Database Queries ทั้งหมด
dd(get_queried_object()); // แสดงและหยุดการทำงาน

Health Check & Troubleshooting Plugin (WordPress Official)

Plugin อย่างเป็นทางการจาก WordPress.org ที่มีฟีเจอร์ Troubleshooting Mode ซึ่งช่วยให้คุณ Disable Plugin ทั้งหมดชั่วคราว เฉพาะสำหรับ Admin ของคุณเท่านั้น โดยผู้เยี่ยมชมทั่วไปยังเห็นเว็บปกติ เหมาะมากสำหรับหาว่า Plugin ใดทำให้เกิดปัญหา

WP Crontrol

ช่วย Debug ปัญหา WordPress Cron Job ที่ไม่ทำงาน แสดง Cron Event ทั้งหมด Schedule ที่กำหนดไว้ และช่วยให้รัน Event ด้วยมือได้ทันทีเพื่อทดสอบ

วิธีค้นหา Plugin ที่ทำให้เว็บพังโดยไม่ต้องลบทีละตัว

หนึ่งในปัญหาที่พบบ่อยที่สุดใน WordPress คือ Plugin Conflict ซึ่งเกิดเมื่อ Plugin หลายตัวทำงานร่วมกันแล้วเกิดความขัดแย้ง วิธีที่รวดเร็วที่สุดในการหา Plugin ต้นเหตุโดยไม่ต้องลบทีละตัว:

วิธีที่ 1: ใช้ Health Check Troubleshooting Mode

ติดตั้ง Plugin Health Check & Troubleshooting จาก WordPress.org แล้วเปิด Troubleshooting Mode — ระบบจะ Disable Plugin ทั้งหมดชั่วคราวเฉพาะสำหรับ Admin ของคุณเท่านั้น ผู้เยี่ยมชมยังเห็นเว็บปกติ จากนั้นเปิด Plugin ทีละตัวจนกว่าปัญหาจะกลับมา Plugin ตัวสุดท้ายที่เปิดคือต้นเหตุ

วิธีที่ 2: Binary Search (Bisection Method)

ถ้ามี Plugin มากกว่า 10 ตัว วิธี Binary Search ช่วยลดเวลาได้มาก:

1. Disable ครึ่งหนึ่งของ Plugin ทั้งหมด
2. ถ้าปัญหาหายไป — ต้นเหตุอยู่ในกลุ่มที่ Disable
3. ถ้าปัญหายังอยู่ — ต้นเหตุอยู่ในกลุ่มที่ยัง Active
4. ทำซ้ำกับกลุ่มที่สงสัยจนเหลือ Plugin เดียว

วิธีนี้ใช้เวลา O(log n) แทน O(n) ตัวอย่าง: Plugin 32 ตัว ใช้แค่ 5 รอบแทนที่จะทดสอบ 32 ครั้ง

7. Debug Bar Plugin

Debug Bar เป็นอีก Plugin ที่ให้ข้อมูล Debug โดยเพิ่มแถบ "Debug" ใน Admin Bar ประกอบด้วย:

• PHP Information (เวอร์ชัน, Extension ที่โหลด)
• Query Details (จำนวน Query, เวลารวม)
• Cache Information (Object Cache hits/misses)
• Request Information (GET/POST data, Server variables)

Debug Bar รองรับ Extension เพิ่มเติม เช่น Debug Bar Console ที่ให้รัน PHP Code ตรงจาก Browser

7b. การ Debug WordPress บน Hosting AsiaGB ด้วย DirectAdmin

Hosting AsiaGB ใช้ DirectAdmin Control Panel ซึ่งมีเครื่องมือช่วย Debug WordPress ได้สะดวก ต่อไปนี้คือขั้นตอนที่แนะนำ:

แก้ไข wp-config.php ผ่าน File Manager

1. เข้า DirectAdmin ที่ yourdomain.com:2222
2. คลิก Files → File Manager
3. ไปที่ public_html/ (หรือ Directory ที่ติดตั้ง WordPress)
4. คลิกขวาที่ wp-config.php → Edit
5. เพิ่ม Debug Constants ที่ต้องการ → กด Save

ดู PHP Error Log ผ่าน DirectAdmin

DirectAdmin มี Error Log Viewer ในตัว:

1. ใน DirectAdmin ไปที่ Advanced Features → Error Log
2. เลือก Domain ที่ต้องการดู
3. Log จะแสดง PHP Error ล่าสุดโดยตรง ไม่ต้องเข้า File Manager

เปลี่ยนเวอร์ชัน PHP เมื่อ Error ระบุว่าเกิดจาก Compatibility

ถ้า debug.log แสดง Error เกี่ยวกับ PHP Function ที่ไม่มีหรือถูก Deprecated แสดงว่าอาจมีความขัดแย้งกับ PHP Version ที่ใช้อยู่ สามารถเปลี่ยน PHP Version ได้ใน DirectAdmin → PHP Selector โดยไม่ต้อง Restart Server

8. ปิด Debug Mode หลังแก้เสร็จ

หลังจาก Debug และแก้ปัญหาได้แล้ว ต้องปิด Debug Mode ทันที โดยเฉพาะบน Production Server

// ปิด Debug Mode (ค่า Default)
define( 'WP_DEBUG', false );

// หรือถ้าต้องการเก็บ log ไว้ (แต่ปลอดภัยกว่า)
define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false ); // ซ่อนไม่แสดงบนหน้าจอ

นอกจากนี้ควร ลบไฟล์ debug.log หลังแก้ปัญหาเสร็จ เพราะไฟล์นี้อาจมีข้อมูล Path และ Credential บางส่วนที่ไม่ควรเปิดเผย

การตั้ง define() ที่มีประสิทธิภาพสูงสุดใน wp-config.php

นอกจาก Debug Constants แล้ว ยังมีค่า Constants อื่นใน wp-config.php ที่ช่วยให้ Debug ง่ายขึ้นและทำให้เว็บเสถียรขึ้น ต่อไปนี้คือการตั้งค่าที่แนะนำสำหรับแต่ละสภาพแวดล้อม:

Local Development — ตั้งค่าแบบสมบูรณ์

// === Debug Settings (Local Dev) ===
define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', true );
define( 'SCRIPT_DEBUG', true );
define( 'SAVEQUERIES', true ); // บันทึก Query ทุกคำสั่ง (ต้องใช้ RAM เพิ่ม)

// === Performance Settings ===
define( 'WP_MEMORY_LIMIT', '256M' );
define( 'WP_MAX_MEMORY_LIMIT', '512M' );

// === Revision Control ===
define( 'WP_POST_REVISIONS', 5 ); // จำกัด Revision ป้องกัน DB โตเร็ว

Production — ปิด Debug แต่เก็บ Log ไว้

// === Debug Settings (Production) ===
define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );      // บันทึก Error ลงไฟล์
define( 'WP_DEBUG_DISPLAY', false ); // ห้ามแสดงบนหน้าจอ
define( 'SCRIPT_DEBUG', false );
// define( 'SAVEQUERIES', false );   // ปิด — ทำให้ช้า

// === Security Hardening ===
define( 'DISALLOW_FILE_EDIT', true );   // ปิด Theme/Plugin Editor บน Admin
define( 'DISALLOW_FILE_MODS', false );  // ยังให้ Update Plugin ได้

9. สรุปการตั้งค่าแนะนำตามสถานการณ์