WordPress Critical Error แก้ยังไง กู้เว็บคืนทีละขั้นตอน

WordPress critical error แก้ยังไง: เริ่มจากเปิดอีเมลผู้ดูแลเว็บเพื่อหาลิงก์ Recovery Mode ถ้าไม่มีอีเมล ให้เปิด WP_DEBUG_LOG เพื่อดูว่าไฟล์ไหนพัง แล้วปิดปลั๊กอินหรือธีมตัวนั้นผ่าน File Manager ข้อความ “There has been a critical error on this website” (เกิดข้อผิดพลาดร้ายแรงบนเว็บไซต์นี้) แปลว่าโค้ด PHP ของเว็บเจอข้อผิดพลาดร้ายแรง (Fatal Error) จนโหลดหน้าต่อไม่ได้ ระบบนี้มีมาตั้งแต่ WordPress 5.2 (Make WordPress Core, 2019) ส่วนใหญ่เกิดหลังอัปเดตปลั๊กอิน ธีม หรือเวอร์ชัน PHP และข้อมูลในฐานข้อมูลยังอยู่ครบ

หมอเว็บเข้าใจดีว่าเปิดเว็บมาเจอหน้าขาวกับข้อความภาษาอังกฤษสั้น ๆ แล้วใจหายแค่ไหน โดยเฉพาะถ้าเป็นเว็บที่มีลูกค้าสั่งซื้ออยู่ บทความนี้อธิบายว่าข้อความนี้มาจากไหน สาเหตุหลัก 4 กลุ่ม และขั้นตอนกู้เว็บจากง่ายไปยาก ข้อมูลทุกข้ออ้างอิงเอกสารของ WordPress และ PHP ณ วันที่ 29 ตุลาคม 2026 ถ้าเว็บล่มด้วยอาการอื่นที่ไม่ใช่ข้อความนี้ ดูภาพรวมได้ที่ WordPress เว็บล่ม แก้ยังไง

ข้อความ “There has been a critical error” หมายถึงอะไร

เอกสารของ WordPress ระบุข้อความเต็มว่า “There has been a critical error on this website. Please check your site admin email inbox for instructions.” และแนะนำให้เช็กอีเมลแอดมินเป็นอย่างแรก (WordPress Developer Resources) ข้อความนี้มาจากระบบ Fatal Error Recovery Mode ที่เพิ่มใน WordPress 5.2 เมื่อปลั๊กอินหรือธีมทำให้เกิด Fatal Error ระบบจะแสดงหน้าข้อความแทนหน้าจอขาวเปล่า และส่งอีเมลที่มีลิงก์ลับสำหรับเข้า Recovery Mode ไปที่อีเมลผู้ดูแลเว็บ (Make WordPress Core, 2019)

ทำไม WordPress ไม่โชว์รายละเอียด Error บนหน้าเว็บเลย? เพราะข้อความ Error ของ PHP มักบอกพาธไฟล์บนเซิร์ฟเวอร์ ชื่อฟังก์ชัน และโครงสร้างโค้ด ซึ่งคนทั่วไปหรือผู้ไม่หวังดีไม่ควรเห็น คู่มือ PHP เองระบุว่าการแสดง Error บนหน้าจอ (display_errors) มีไว้ช่วยตอนพัฒนา และไม่ควรใช้กับระบบที่ต่ออินเทอร์เน็ต ควรบันทึกลง log แทน (PHP Manual) การซ่อนรายละเอียดแล้วส่งให้แอดมินทางอีเมลจึงเป็นทางสายกลางที่ปลอดภัยกว่า

Critical Error ต่างจาก Error 500 และหน้าจอขาวอย่างไร

หน้าข้อความ Critical Error ของ WordPress เองก็ตอบกลับด้วยรหัส HTTP 500 (WordPress Developer Resources) จึงพูดได้ว่าเป็นกรณีหนึ่งของ Error 500 ที่ WordPress ช่วยบอกใบ้ได้มากกว่า

4 สาเหตุหลักที่ทำให้เกิด Critical Error

เอกสารของ WordPress สรุปสาเหตุที่พบบ่อยไว้ว่าเป็นปลั๊กอินขัดกัน ธีมเข้ากันไม่ได้ PHP เวอร์ชันไม่รองรับ Memory เต็ม หรือไฟล์ WordPress เสียหาย (WordPress Developer Resources) จัดกลุ่มได้ดังนี้

1. ปลั๊กอินหรือธีมขัดกันหลังอัปเดต (Plugin / Theme Conflict)

เป็นสาเหตุที่เจอมากที่สุด เช่น ปลั๊กอินเวอร์ชันใหม่เรียกฟังก์ชันที่ปลั๊กอินอีกตัวประกาศชื่อซ้ำ หรือธีมเรียกฟังก์ชันของปลั๊กอินที่ถูกเปลี่ยนชื่อไปแล้ว ถ้าเพิ่งกดอัปเดตแล้วเว็บพังทันที ให้สงสัยตัวที่เพิ่งอัปเดตก่อน อ่านกลไกเพิ่มเติมใน Plugin Conflict คืออะไร และ Theme Conflict ทำให้เว็บ WordPress ล่ม ส่วนขั้นตอนย้อนเวอร์ชันหลังอัปเดตมีใน WordPress พังหลังอัปเดต Plugin

2. PHP เวอร์ชันบนเซิร์ฟเวอร์ไม่เข้ากับปลั๊กอิน

เกิดได้สองทาง ทางแรกคือโฮสต์อัปเกรด PHP แล้วปลั๊กอินเก่าใช้ฟังก์ชันที่ถูกถอดออก ตัวอย่างชัด ๆ คือ PHP 8.0 ถอดฟังก์ชัน create_function() และ each() ออกไปแล้ว (PHP Manual) ปลั๊กอินที่ไม่ได้อัปเดตมานานและยังเรียกฟังก์ชันเหล่านี้จะพังทันทีบน PHP 8 ทางที่สองกลับกัน คือปลั๊กอินเวอร์ชันใหม่ต้องการ PHP ที่ใหม่กว่าที่โฮสต์มี ซึ่งนักพัฒนาระบุไว้ในหัวไฟล์ปลั๊กอินด้วยช่อง “Requires PHP” (WordPress Developer Resources) อ่านวิธีเช็กใน PHP Version ไม่รองรับ ทำให้ WordPress Error

ช่วงนี้ปัญหานี้จะเจอบ่อยขึ้น เพราะ PHP 8.2 ได้รับแพตช์ความปลอดภัยถึง 31 ธันวาคม 2026 เท่านั้น (PHP.net) โฮสต์หลายเจ้าจะย้ายเว็บขึ้น 8.3 หรือ 8.4 วางแผนล่วงหน้าได้จาก PHP 8.2 หมดอายุ ต้องทำอะไร

3. หน่วยความจำ PHP ไม่พอ (Memory Limit Exhausted)

ถ้า log ขึ้นว่า “Allowed memory size … exhausted” แปลว่า WordPress ใช้หน่วยความจำเกินที่ตั้งไว้ (WordPress Developer Resources) ค่า memory_limit ของ PHP คือเพดานหน่วยความจำที่สคริปต์หนึ่งใช้ได้ ค่าเริ่มต้นของ PHP คือ 128M (PHP Manual) ส่วน WordPress จะพยายามตั้งไว้ที่ 40MB สำหรับเว็บเดี่ยวและ 64MB สำหรับ Multisite ถ้าไม่ได้กำหนดเอง (WordPress Developer Resources) เว็บที่มี WooCommerce, Page Builder และปลั๊กอินจำนวนมากจึงชนเพดานได้ง่าย

4. ไฟล์ Core หรือฐานข้อมูลเสียหาย

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

ก่อนลงมือแก้: สำรองข้อมูลก่อนเสมอ

ถึงเว็บจะพังอยู่ ไฟล์และฐานข้อมูลยังดาวน์โหลดได้จาก File Manager และ phpMyAdmin ของโฮสต์ WordPress อธิบายว่าการสำรองข้อมูลมี 2 ส่วนคือฐานข้อมูลและไฟล์ ต้องมีทั้งคู่จึงจะกู้เว็บได้ครบ (WordPress Developer Resources) และคู่มืออัปเกรดของ WordPress ย้ำให้ตรวจว่าไฟล์สำรองใช้งานได้จริงก่อนทำอะไรต่อ (WordPress Developer Resources) ใช้เวลาเพิ่มสิบนาที แต่ถ้าแก้ผิดก็ย้อนกลับได้

ขั้นตอนกู้เว็บทีละขั้น (เรียงจากง่ายไปยาก)

ทำตามลำดับ และหยุดเมื่อเว็บกลับมา ไม่จำเป็นต้องทำครบทุกข้อ

ขั้นที่ 1: เปิดอีเมลแอดมิน แล้วเข้า Recovery Mode

อีเมลจะส่งไปที่อีเมลผู้ดูแลเว็บ (Administration Email Address ในหน้า Settings → General) แต่ถ้าใน wp-config.php มีการกำหนดค่าคงที่ RECOVERY_MODE_EMAIL ไว้เป็นอีเมลที่ถูกต้อง WordPress จะส่งไปที่อีเมลนั้นแทน (WordPress Developer Resources) ลองค้นกล่องจดหมายและโฟลเดอร์สแปมด้วยหัวเรื่อง “Your Site is Experiencing a Technical Issue” ซึ่งเป็นหัวอีเมลที่ WordPress ใช้ (WordPress Developer Resources)

• ลิงก์ใช้ได้นานเท่าไร: ตามซอร์สโค้ด อายุลิงก์เท่ากับช่วงห่างของการส่งอีเมล ซึ่งค่าเริ่มต้นคือ 1 วัน (get_link_ttl, get_email_rate_limit) แปลว่า WordPress ส่งอีเมลนี้ไม่เกินวันละครั้ง ถ้าลบอีเมลไปแล้วอาจต้องรอหรือใช้วิธีในขั้นถัดไป
• Recovery Mode ทำอะไร: ระบบใช้คุกกี้บนเบราว์เซอร์ของคุณ และ “พัก” (pause) ปลั๊กอินหรือธีมที่ทำให้เกิด Error เฉพาะสำหรับคุณ ผู้เข้าชมคนอื่นยังเห็นเว็บพังอยู่จนกว่าจะแก้เสร็จ (Make WordPress Core, 2019)
• ทำอะไรต่อเมื่อเข้าได้: ไปหน้า Plugins จะเห็นตัวที่ถูกพักพร้อมข้อความ Error ให้กด Deactivate ตัวนั้น แล้วกดออกจาก Recovery Mode ที่แถบด้านบน จากนั้นเปิดหน้าเว็บในหน้าต่างไม่ระบุตัวตนเพื่อเช็กว่าคนทั่วไปเข้าได้แล้ว

ถ้าอีเมลแอดมินเป็นอีเมลที่ไม่มีใครเปิดแล้ว ตั้งค่าให้ส่งไปที่อีเมลที่ใช้งานจริงได้ด้วยบรรทัดนี้ (เปลี่ยนเป็นอีเมลของคุณ)

define( 'RECOVERY_MODE_EMAIL', 'admin@example.com' );

ขั้นที่ 2: เปิด WP_DEBUG แล้วอ่าน debug.log

ถ้าไม่ได้รับอีเมล ให้ WordPress บันทึก Error ลงไฟล์ เปิดไฟล์ wp-config.php ผ่าน File Manager หรือ FTP แล้ววางโค้ดนี้ไว้เหนือบรรทัด /* 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_LOG จะบันทึก Error ลง wp-content/debug.log และใช้ได้เมื่อเปิด WP_DEBUG เท่านั้น ส่วน WP_DEBUG_DISPLAY เป็น false เพื่อไม่ให้ Error ไปโผล่บนหน้าเว็บ (WordPress Developer Resources) ข้อควรระวัง: ต้องพิมพ์ true/false โดยไม่มีเครื่องหมายคำพูด เพราะถ้าใส่ 'false' PHP จะตีความเป็น true จากนั้นเปิดหน้าเว็บอีกครั้งหนึ่งรอบ แล้วเปิดไฟล์ debug.log ดูบรรทัดล่าง ๆ

ถ้าโฮสต์มีหน้า Error Log ในแผงควบคุมก็ใช้ได้เช่นกัน เช่น cPanel มีเมนู Errors ที่แสดง Error ล่าสุดของเว็บเซิร์ฟเวอร์สูงสุด 300 รายการ (cPanel Docs) บางโฮสต์มีไฟล์ error_log หรือ php_error.log อยู่ในโฟลเดอร์หลักของเว็บ

ตัวอย่างข้อความที่มักเจอและความหมาย (พาธและชื่อปลั๊กอินเป็นตัวอย่าง)

สำคัญ: แก้เสร็จแล้วให้ตั้ง WP_DEBUG กลับเป็น false และลบไฟล์ debug.log ทิ้ง เอกสาร WordPress ไม่แนะนำให้เปิดโหมดดีบักบนเว็บจริง (WordPress Developer Resources) และหน้า Site Health เตือนว่า WP_DEBUG_LOG เขียน Error ลงไฟล์ที่อาจถูกคนอื่นเปิดอ่านได้ (WordPress.org Documentation) ถ้าต้องเปิดไว้หลายวัน ให้กำหนดพาธไฟล์ log ไว้นอกโฟลเดอร์เว็บ ซึ่ง WP_DEBUG_LOG รองรับการใส่พาธไฟล์แทนค่า true (WordPress Developer Resources)

ขั้นที่ 3: ปิดปลั๊กอินผ่าน File Manager หรือ FTP

ถ้า log ชี้ชื่อปลั๊กอินชัดเจน ให้เข้าโฟลเดอร์ wp-content/plugins/ แล้วเปลี่ยนชื่อโฟลเดอร์ของปลั๊กอินตัวนั้น เช่น old-slider เป็น old-slider-off WordPress จะหาปลั๊กอินไม่เจอและปิดให้เอง

ถ้าไม่รู้ว่าตัวไหน ให้ปิดทั้งหมดในครั้งเดียวโดยเปลี่ยนชื่อโฟลเดอร์ wp-content/plugins เป็น plugins-off ซึ่งเป็นวิธีที่เอกสาร WordPress แนะนำเมื่อเข้าหน้าแอดมินไม่ได้ (WordPress Developer Resources) ถ้าเว็บกลับมา แสดงว่าต้นเหตุอยู่ในกลุ่มปลั๊กอินแน่นอน จากนั้น

1. เปลี่ยนชื่อกลับเป็น plugins (ปลั๊กอินทั้งหมดจะอยู่ในสถานะปิด)
2. เข้า wp-admin → Plugins แล้วเปิดใช้งานทีละตัว
3. รีเฟรชหน้าเว็บทุกครั้ง ตัวที่เปิดแล้วเว็บพังอีกคือต้นเหตุ ปิดตัวนั้นไว้ แล้วเปิดตัวที่เหลือต่อจนครบ

ขั้นที่ 4: สลับเป็นธีมเริ่มต้น

ถ้าปิดปลั๊กอินทั้งหมดแล้วยังพัง หรือ log ชี้ไปที่โฟลเดอร์ธีม ให้เปลี่ยนชื่อโฟลเดอร์ธีมที่ใช้อยู่ใน wp-content/themes/ เมื่อธีมที่ตั้งไว้ไม่ผ่านการตรวจ WordPress จะสลับไปใช้ธีมเริ่มต้น (เช่น Twenty Twenty-Five) ที่ติดตั้งไว้ให้อัตโนมัติ (WordPress Developer Resources) ดังนั้นต้องมีธีมเริ่มต้นอย่างน้อยหนึ่งตัวอยู่ในโฟลเดอร์ ถ้าเว็บกลับมา ให้ติดต่อผู้พัฒนาธีม หรือถ้าเพิ่งแก้ functions.php ให้ย้อนโค้ดที่แก้ เว็บจะดูหน้าตาเปลี่ยนชั่วคราว แต่เนื้อหาไม่หาย

ขั้นที่ 5: เพิ่ม PHP Memory Limit

ถ้า log บอกว่า Memory หมด ให้เพิ่มบรรทัดนี้ใน wp-config.php เหนือบรรทัด “That’s all, stop editing!”

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

WP_MAX_MEMORY_LIMIT ใช้กำหนดหน่วยความจำของหน้าแอดมินแยกจากหน้าบ้าน (WordPress Developer Resources) ถ้าใช้ Apache ที่รัน PHP เป็นโมดูล อาจตั้งใน .htaccess ด้วย php_value memory_limit 256M ได้ (PHP Manual) ถ้าโฮสต์ไม่ได้รัน PHP แบบนั้น บรรทัดนี้อาจกลับทำให้เกิด Error 500 ถ้าเพิ่มแล้วเว็บพังหนักขึ้นให้ลบออก เอกสาร WordPress ระบุว่าบางโฮสต์ไม่อนุญาตให้เพิ่มเองและต้องติดต่อโฮสต์ให้เพิ่มให้ (WordPress Developer Resources)

ขั้นที่ 6: ตรวจเวอร์ชัน PHP

ดูเวอร์ชัน PHP ที่ใช้อยู่ในแผงควบคุมโฮสต์ (เมนูชื่อประมาณ Select PHP Version หรือ PHP Settings) เทียบกับช่อง “Requires PHP” ในหน้าปลั๊กอินบน WordPress.org ปัจจุบัน WordPress แนะนำ PHP 8.3 ขึ้นไป (WordPress.org)

• ถ้าเว็บเพิ่งพังหลังโฮสต์อัปเกรด PHP และปลั๊กอินตัวต้นเหตุเก่ามาก การลด PHP ลงชั่วคราวช่วยให้เว็บกลับมาได้ แต่ต้องรีบเปลี่ยนปลั๊กอิน ไม่ควรค้างอยู่บน PHP ที่หมดอายุ
• ถ้าปลั๊กอินเวอร์ชันใหม่ต้องการ PHP สูงกว่าที่โฮสต์มี ให้อัปเกรด PHP แทนการย้อนปลั๊กอิน

ขั้นที่ 7: ติดตั้งไฟล์ Core ใหม่

ถ้า log ชี้ไปที่ไฟล์ Core หรือทำทุกข้อแล้วยังไม่หาย ให้ดาวน์โหลด WordPress เวอร์ชันเดียวกับที่ใช้อยู่จาก wordpress.org แล้วอัปโหลดโฟลเดอร์ wp-admin และ wp-includes ทับของเดิม ซึ่งเป็นหนึ่งในวิธีที่เอกสาร WordPress แนะนำ (WordPress Developer Resources) ห้ามลบหรือทับ wp-content และ wp-config.php เพราะเป็นที่เก็บธีม ปลั๊กอิน รูปภาพ และการตั้งค่าเชื่อมฐานข้อมูล (WordPress Developer Resources)

สิ่งที่ไม่ควรทำเด็ดขาดระหว่างแก้

• อย่าลบโฟลเดอร์หรือตารางในฐานข้อมูลแบบเดาสุ่ม การเปลี่ยนชื่อโฟลเดอร์ย้อนกลับได้ แต่การลบตารางอย่าง wp_options ย้อนไม่ได้ถ้าไม่มีไฟล์สำรอง
• อย่าเปิด WP_DEBUG_DISPLAY บนเว็บจริง ข้อความ Error จะโชว์ให้ทุกคนเห็นพาธไฟล์และโครงสร้างเว็บ
• อย่าปิดระบบ Recovery Mode ทิ้ง ค่าคงที่ WP_DISABLE_FATAL_ERROR_HANDLER ปิดระบบนี้ทั้งหมด (Make WordPress Core, 2019) เหมาะกับเครื่องนักพัฒนาเท่านั้น ถ้าเปิดบนเว็บจริง ครั้งหน้าจะไม่ได้อีเมลช่วยเหลือ

ป้องกัน Critical Error ครั้งต่อไป

• ทดสอบบน Staging ก่อน: ใช้เว็บสำเนา (Staging) ที่โฮสต์หลายเจ้ามีให้ ทดสอบอัปเดตปลั๊กอิน ธีม Core และ PHP ก่อนขึ้นเว็บจริง
• สำรองข้อมูลอัตโนมัติ: ตั้งสำรองทุกวันด้วยปลั๊กอินอย่าง UpdraftPlus หรือระบบของโฮสต์ และเก็บสำเนาไว้มากกว่าหนึ่งที่ เอกสาร WordPress แนะนำให้เก็บ 3–5 ชุดล่าสุดในหลายตำแหน่ง (WordPress Developer Resources)
• อัปเดตทีละตัว: อย่ากด Update All กับปลั๊กอิน ธีม และ Core พร้อมกัน ถ้าพังจะรู้ทันทีว่าตัวไหน
• ดูความเข้ากันได้ก่อนติดตั้ง: เช็กช่อง “Tested up to” และ “Requires PHP” ในหน้าปลั๊กอิน
• ลดจำนวนปลั๊กอิน: ปลั๊กอินที่ไม่ได้ใช้ให้ลบออก ยิ่งน้อยยิ่งลดโอกาสขัดกันและลดการใช้หน่วยความจำ
• ให้อีเมลแอดมินเป็นอีเมลที่มีคนอ่านจริง: เพราะเป็นช่องทางเดียวที่ WordPress จะส่งลิงก์ Recovery Mode มาให้

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

ถ้าทำครบทุกขั้นแล้วยังไม่หาย log ชี้ไปที่ไฟล์ Core ทั้งที่ไม่มีใครแก้ (อาจเป็นสัญญาณว่าโดนแฮก) มีปัญหาฐานข้อมูลร่วมด้วย เช่น ขึ้น Error Establishing a Database Connection หรือเป็นร้านออนไลน์ที่หยุดขายนานไม่ได้ การให้คนที่ทำเรื่องนี้ทุกวันดูจะเร็วกว่าและเสี่ยงน้อยกว่า ทีม บริการแก้ WordPress ล่ม / Error ของ WP Doctor Thailand ประเมินอาการให้ฟรีก่อน ผู้ก่อตั้งลงมือแก้เองทุกเคส มีรับประกันงานสูงสุด 180 วันตามแพ็กเกจ และคืนเงินเต็มจำนวนถ้าแก้ไม่ได้

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

แหล่งอ้างอิง

1. Make WordPress Core. (2019). Fatal Error Recovery Mode in 5.2. สืบค้นเมื่อ 29 ตุลาคม 2026, จาก https://make.wordpress.org/core/2019/04/16/fatal-error-recovery-mode-in-5-2/
2. WordPress Developer Resources. (ม.ป.ป.). Common WordPress Errors. สืบค้นเมื่อ 29 ตุลาคม 2026, จาก https://developer.wordpress.org/advanced-administration/wordpress/common-errors/
3. WordPress Developer Resources. (ม.ป.ป.). Debugging in WordPress. สืบค้นเมื่อ 29 ตุลาคม 2026, จาก https://developer.wordpress.org/advanced-administration/debug/debug-wordpress/
4. WordPress Developer Resources. (ม.ป.ป.). wp-config.php. สืบค้นเมื่อ 29 ตุลาคม 2026, จาก https://developer.wordpress.org/advanced-administration/wordpress/wp-config/
5. WordPress Developer Resources. (ม.ป.ป.). WP_Recovery_Mode::get_link_ttl(). สืบค้นเมื่อ 29 ตุลาคม 2026, จาก https://developer.wordpress.org/reference/classes/wp_recovery_mode/get_link_ttl/
6. WordPress Developer Resources. (ม.ป.ป.). WP_Recovery_Mode::get_email_rate_limit(). สืบค้นเมื่อ 29 ตุลาคม 2026, จาก https://developer.wordpress.org/reference/classes/wp_recovery_mode/get_email_rate_limit/
7. WordPress Developer Resources. (ม.ป.ป.). WP_Recovery_Mode_Email_Service::get_recovery_mode_email_address(). สืบค้นเมื่อ 29 ตุลาคม 2026, จาก https://developer.wordpress.org/reference/classes/wp_recovery_mode_email_service/get_recovery_mode_email_address/
8. WordPress Developer Resources. (ม.ป.ป.). WP_Recovery_Mode_Email_Service::send_recovery_mode_email(). สืบค้นเมื่อ 29 ตุลาคม 2026, จาก https://developer.wordpress.org/reference/classes/wp_recovery_mode_email_service/send_recovery_mode_email/
9. WordPress Developer Resources. (ม.ป.ป.). WP_Fatal_Error_Handler::display_default_error_template(). สืบค้นเมื่อ 29 ตุลาคม 2026, จาก https://developer.wordpress.org/reference/classes/wp_fatal_error_handler/display_default_error_template/
10. WordPress Developer Resources. (ม.ป.ป.). validate_current_theme(). สืบค้นเมื่อ 29 ตุลาคม 2026, จาก https://developer.wordpress.org/reference/functions/validate_current_theme/
11. WordPress Developer Resources. (ม.ป.ป.). Header Requirements. สืบค้นเมื่อ 29 ตุลาคม 2026, จาก https://developer.wordpress.org/plugins/plugin-basics/header-requirements/
12. WordPress Developer Resources. (ม.ป.ป.). WordPress Backups. สืบค้นเมื่อ 29 ตุลาคม 2026, จาก https://developer.wordpress.org/advanced-administration/security/backup/
13. WordPress Developer Resources. (ม.ป.ป.). Upgrading WordPress. สืบค้นเมื่อ 29 ตุลาคม 2026, จาก https://developer.wordpress.org/advanced-administration/upgrade/upgrading/
14. WordPress.org. (ม.ป.ป.). Site Health screen. สืบค้นเมื่อ 29 ตุลาคม 2026, จาก https://wordpress.org/documentation/article/site-health-screen/
15. WordPress.org. (ม.ป.ป.). Requirements. สืบค้นเมื่อ 29 ตุลาคม 2026, จาก https://wordpress.org/about/requirements/
16. The PHP Group. (ม.ป.ป.). Runtime Configuration: Errors and Logging. สืบค้นเมื่อ 29 ตุลาคม 2026, จาก https://www.php.net/manual/en/errorfunc.configuration.php
17. The PHP Group. (ม.ป.ป.). Description of core php.ini directives. สืบค้นเมื่อ 29 ตุลาคม 2026, จาก https://www.php.net/manual/en/ini.core.php
18. The PHP Group. (ม.ป.ป.). How to change configuration settings. สืบค้นเมื่อ 29 ตุลาคม 2026, จาก https://www.php.net/manual/en/configuration.changes.php
19. The PHP Group. (ม.ป.ป.). Backward Incompatible Changes (Migrating from PHP 7.4.x to PHP 8.0.x). สืบค้นเมื่อ 29 ตุลาคม 2026, จาก https://www.php.net/manual/en/migration80.incompatible.php
20. The PHP Group. (ม.ป.ป.). Supported Versions. สืบค้นเมื่อ 29 ตุลาคม 2026, จาก https://www.php.net/supported-versions.php
21. MDN Web Docs. (ม.ป.ป.). 500 Internal Server Error. สืบค้นเมื่อ 29 ตุลาคม 2026, จาก https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Status/500
22. cPanel. (ม.ป.ป.). Errors. สืบค้นเมื่อ 29 ตุลาคม 2026, จาก https://docs.cpanel.net/cpanel/metrics/errors/