ปัญหาหน้าจอขาวใน WordPress: 5 วิธีแก้ไขง่ายๆ

by | WordPress

หากเว็บไซต์ของคุณ WordPress จู่ๆ ก็แสดงหน้าจอว่างเปล่าขึ้นมา Sans ข้อความนี้หมายความว่า คุณไม่ได้ถูก "สาปแช่ง" แต่คุณกำลังเผชิญกับข้อผิดพลาดร้ายแรงที่ WordPress ไม่สามารถแสดงผลได้อย่างถูกต้อง

มีปัญหา

หน้าจอสีขาวแห่งความตาย (WSOD) จะปรากฏขึ้นโดยไม่มีอะไรแสดงอยู่เลย บางครั้ง คุณอาจพบข้อผิดพลาดที่เทียบเท่ากันจากฝั่งเซิร์ฟเวอร์ เช่น ข้อผิดพลาด 500 หรือข้อความสั้นๆ ดังนี้:

HTTP ERROR 500

หรือหากโฮสติ้งแสดงข้อผิดพลาด PHP (ซึ่งเกิดขึ้นไม่บ่อยนักในการใช้งานจริง) จะแสดงข้อความประมาณนี้:

Fatal error: Uncaught Error: Call to undefined function ... in /home/.../wp-content/themes/.../functions.php:123

มันปรากฏที่ไหนและเมื่อไหร่?

  • Front-end หน้าแรกว่างเปล่า หรือแสดงเฉพาะบางหน้า (ส่วนใหญ่มักเป็นหน้าที่มีชอร์ตโค้ด วิดเจ็ต หรือเทมเพลตเฉพาะ)
  • ผู้ดูแลระบบ (/wp-admin) : หน้าจอสีขาวขณะเข้าสู่ระบบ, เข้าถึงแดชบอร์ดไม่ได้ หรือหน้าจอสีขาวในหน้าใดหน้าหนึ่งโดยเฉพาะ (ส่วนขยาย, ลักษณะที่ปรากฏ, ตัวแก้ไข…)
  • โครน / งานที่กำหนดเวลาไว้ เว็บไซต์ "ใช้งานได้" แต่บางการทำงาน (เช่น อีเมล การนำเข้า) หยุดชะงัก และพบข้อผิดพลาดในบันทึกการทำงาน
  • เรสท์ API / เอเจเอ็กซ์ Elementor/Divi/Avada ไม่สามารถโหลดตัวแก้ไขได้อีกต่อไป การร้องขอ XHR ล้มเหลว หรือการแสดงตัวอย่างไม่โหลด

สถานการณ์ทั่วไปที่ฉันพบเห็นบ่อยที่สุด:

  • หลังจากนั้นไม่นาน ปรับปรุง (WordPress 6.9.4, a เสียบเข้าไป(ธีม, ผู้สร้าง)
  • หลังจากเพิ่ม ตัวอย่างข้อมูล dans functions.php หรือผ่านปลั๊กอินโค้ดสั้นๆ
  • หลังจากเปิดใช้งาน ปลั๊กอิน "หนัก" (แคช, ความปลอดภัย, ตัวสร้าง, อีคอมเมิร์ซ)
  • หลังจากมีการเปลี่ยนแปลงฝั่งเซิร์ฟเวอร์ (เวอร์ชัน PHP, โมดูล OPcache, ข้อจำกัดด้านหน่วยความจำ)

เหมาะสำหรับ: ผู้เริ่มต้นใช้งาน แต่สามารถเข้าถึง FTP/ตัวจัดการไฟล์ (หรืออย่างน้อยก็แผงควบคุมผู้ดูแลระบบ) คุณจะสามารถวินิจฉัยปัญหาและกู้คืนเว็บไซต์ให้กลับมาใช้งานได้อย่างถูกต้อง ในที่สุด คุณจะรู้ ค้นหาข้อผิดพลาดที่แน่นอน, ระบุตัวผู้กระทำผิด (ปลั๊กอิน/ธีม/โค้ดตัวอย่าง) และ หลีกเลี่ยงหน้าจอสีขาวปลอมที่เกิดจากแคช.

สรุปด่วน

  • อย่าเดา : เปิดใช้งานการดีบักและอ่านข้อผิดพลาด (วิธีแก้ปัญหาที่ 1)
  • ไอโซเลท : ปิดใช้งานปลั๊กอินทั้งหมดและเปลี่ยนกลับไปใช้ธีมเริ่มต้น (วิธีที่ 2)
  • ตรวจสอบหน่วยความจำ อาการ WSOD จำนวนมากมีต้นกำเนิดมาจาก... หน่วยความจำที่อนุญาตเต็มแล้ว (วิธีแก้ปัญหาที่ 3)
  • เกร็ดเล็กเกร็ดน้อย : ขาดเครื่องหมายเซมิโคลอนใน functions.php เพียงพอที่จะทำให้ทุกอย่างขาวสะอาด (วิธีแก้ปัญหาที่ 4)
  • แคช คุณสามารถ "แก้ไข" เว็บไซต์ได้โดยไม่ต้องเห็นหน้าเว็บ หาก OPcache/CDN กำลังให้บริการเวอร์ชันเก่าอยู่ (วิธีแก้ปัญหาที่ 5)

มีอาการ

หน้าจอสีขาว (WSOD) ไม่ได้หมายความว่าจะเป็น "แค่หน้าว่างๆ" เสมอไป นี่คือสัญญาณที่ควรสังเกต (และสิ่งที่สัญญาณเหล่านั้นบ่งบอก)

  • เติมหน้าว่างให้สมบูรณ์ (ด้านหน้า) แต่ / wp-admin ที่ วิธีแก้ปัญหา: มักเป็นปัญหาที่ธีม เทมเพลต ชอร์ตโค้ด หรือแคชของหน้าเว็บเสียหาย
  • / wp-admin ที่ สีขาวเช่นกัน: บ่อยครั้งเป็นข้อผิดพลาดร้ายแรงของ PHP (ปลั๊กอิน ธีม หรือโค้ดตัวอย่าง) หรือข้อจำกัดด้านหน่วยความจำ
  • ข้อผิดพลาด 500 ในเบราว์เซอร์: มักเป็นข้อผิดพลาดร้ายแรงของ PHP การกำหนดค่าเซิร์ฟเวอร์ หรือโมดูล (OPcache) ที่ให้บริการโค้ดที่ล้าสมัย
  • ตัวแก้ไข Elementor/Divi/Avada ไม่โหลดอีกต่อไป ข้อผิดพลาด REST API/AJAX, ปัญหาเกี่ยวกับหน่วยความจำ, ความขัดแย้งของปลั๊กอิน (ด้านความปลอดภัย/การแคช) หรือข้อผิดพลาด JavaScript ที่ซ่อนอยู่
  • เว็บไซต์นี้ทำงานในพื้นที่ แต่ไม่ใช่ในสภาพแวดล้อมการใช้งานจริง: ความแตกต่างในเวอร์ชัน PHP, ส่วนขยาย PHP, ข้อจำกัดด้านหน่วยความจำ, แคชของเซิร์ฟเวอร์, สิทธิ์การเข้าถึงไฟล์
  • เฉพาะบางหน้าเท่านั้น : รหัสย่อเสีย, คำขอมีขนาดใหญ่เกินไป, ลูปไม่สิ้นสุด หรือรูปภาพ/ทรัพยากรที่ใช้หน่วยความจำมากเกินไป

ตรวจสอบปัญหาเบื้องต้นฝั่งเบราว์เซอร์อย่างรวดเร็ว: เปิดคอนโซล (F12) แล้วดูที่นี่:

  • ปลอบใจ : ข้อผิดพลาด JavaScript (มีประโยชน์อย่างยิ่งสำหรับนักพัฒนาโปรแกรม)
  • เครือข่าย คำสั่ง XHR ไปยัง /wp-json/ (REST API) หรือ admin-ajax.php ใน 500/403

ทำไมจึงเกิดเหตุการณ์เช่นนี้?

คำอธิบายอย่างง่าย (สำหรับผู้เริ่มต้น)

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

ดังนั้น WSOD จึงไม่ค่อย "ลึกลับ" สักเท่าไหร่ ส่วนใหญ่แล้วมักจะเป็น:

  • un ข้อผิดพลาดของโค้ด (ปลั๊กอิน/ธีม/โค้ดตัวอย่าง)
  • un ขาดแคลนทรัพยากร (ความทรงจำ/เวลา)
  • หรือ แคช ซึ่งจะแสดงเวอร์ชันที่เสียให้คุณเห็น แม้ว่าคุณจะแก้ไขแล้วก็ตาม

คำอธิบายทางเทคนิค (ระดับกลาง/มืออาชีพ)

เบื้องหลังการทำงาน ข้อผิดพลาดมักเกิดขึ้นระหว่างการโหลด WordPress hooks เบ็ด เป็นจุดต่อขยาย: a การกระทำ ดำเนินการโค้ดในเวลาที่กำหนด ฟิลเตอร์ แก้ไขค่า (เช่น เนื้อหา) ก่อนนำไปใช้

สาเหตุ (จากที่พบบ่อยที่สุดไปจนถึงที่พบน้อยที่สุด) พร้อมกับสิ่งที่ฉันสังเกตเห็นในการแก้ไขปัญหา WordPress 6.9.4:

  • ปลั๊กอินนี้ไม่สามารถใช้งานร่วมกับ PHP เวอร์ชัน 8.1 ขึ้นไปได้ (หรืออาจเป็นข้อผิดพลาดหลังจากการอัปเดต)
  • ธีม / ธีมสำหรับเด็ก : รหัสใน functions.phpเทมเพลต หรือเขียนทับ WooCommerce.
  • คัดลอกมาจากบทเรียนเก่า (ฟังก์ชันล้าสมัย, การเชื่อมต่อไม่ถูกต้อง หรือโค้ดถูกเรียกใช้งานเร็วเกินไป)
  • หน่วยความจำ PHP ไม่เพียงพอ (เครื่องมือสร้างเว็บไซต์ + WooCommerce + ปลั๊กอินรักษาความปลอดภัย = การผสมผสานสุดคลาสสิก)
  • แคชเซิร์ฟเวอร์ (OPcache) / CDN ซึ่งให้บริการเวอร์ชันที่ล้าสมัย
  • สิทธิ์ (พบได้น้อยในกรณีที่เกิด WSOD จริง แต่ก็อาจทำให้เกิดข้อผิดพลาด 500 ได้)

เพื่อช่วยให้คุณแยกแยะปัญหาได้ง่ายขึ้น นี่คือตารางวินิจฉัย: “อาการ → ตรวจสอบ → วิธีแก้ไข”

อาการ สาเหตุที่เป็นไปได้ การตรวจสอบ Solution
หน้าจอสีขาวไปหมด ข้อผิดพลาดร้ายแรงของ PHP เปิดใช้งาน WP_DEBUG + อ่าน debug.log วิธีแก้ปัญหา 1 + 2
ข้อผิดพลาด 500 ข้อผิดพลาดร้ายแรงของ PHP / ข้อจำกัดด้านหน่วยความจำ / แคชเซิร์ฟเวอร์ บันทึกเซิร์ฟเวอร์ + debug.log คำตอบ 1 + 3 + 5
ผู้ดูแลระบบอนุมัติแล้ว ด้านหน้าสีขาว ธีม / ชอร์ตโค้ด / แคชหน้าเว็บ เปลี่ยนธีมชั่วคราว + ล้างแคช วิธีแก้ปัญหา 2 + 5
Elementor/Divi จะไม่เปิดโปรแกรมแก้ไขอีกต่อไป ข้อผิดพลาด REST/AJAX, หน่วยความจำ คอนโซล + เครือข่าย (XHR 500/403) วิธีแก้ปัญหาที่ 3 + “ถ้ายังไม่ได้ผลอีก”
หน้าจอสีขาว (WSOD) หลังจากเพิ่มโค้ดสั้นๆ ข้อผิดพลาดทางไวยากรณ์ / การเชื่อมต่อเร็วเกินไป ไฟล์ล่าสุดที่แก้ไข, บันทึก วิธีการแก้ปัญหา 4

ข้อกำหนดเบื้องต้นก่อนเริ่ม

บันทึกก่อนทำการเปลี่ยนแปลงใดๆ หากคุณจำเป็นต้องทำงานกับไฟล์ใดๆ อย่างน้อยที่สุดให้คัดลอกไฟล์ต่อไปนี้:

  • wp-config.php
  • แฟ้ม wp-content (หรืออย่างน้อยก็ themes et plugins)

ข้อกำหนดทางเทคนิคที่แนะนำ (WordPress 6.9.4 ณ เดือนเมษายน 2026):

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

เครื่องมือที่มีประโยชน์ (ฟรี):

กฎทอง : ห้ามแก้ไขส่วนหลักเด็ดขาด (ไฟล์ WordPress ใน wp-includes / wp-adminการแก้ไขจะทำผ่านปลั๊กอิน ธีมย่อย หรือการตั้งค่า

วิธีแก้ปัญหาที่ 1: เปิดใช้งานการดีบักอย่างถูกต้อง (และค้นหาข้อผิดพลาดที่เกิดขึ้นอย่างแม่นยำ)

หน้าจอว่างเปล่าที่ไม่มีข้อผิดพลาดใดๆ ปรากฏให้เห็น บังคับให้คุณต้องเดา เป้าหมายในที่นี้คือการได้ข้อความที่ใช้งานได้ในไฟล์บันทึก

ควรเข้าไปแทรกแซงที่จุดใด: ในแฟ้ม wp-config.phpที่รากของ WordPress (ที่ระดับเดียวกับ) wp-content).

บันทึกก่อนทำการเปลี่ยนแปลงใดๆ มีการพิมพ์ผิดใน wp-config.php อาจทำให้เว็บไซต์ใช้งานไม่ได้

ก่อนหน้านี้ (การตั้งค่าทั่วไปที่ซ่อนทุกอย่าง)

เว็บไซต์หลายแห่งไม่มีข้อมูลใดๆ หรือมีข้อมูลการแก้ไขข้อผิดพลาดที่ไม่สมบูรณ์:

<?php
// ... contenu existant ...

/* C'est tout : aucune trace d'erreur exploitable. */

หลังจาก (การแก้ไขปัญหาโดยเน้นการหาข้อผิดพลาด โดยไม่แสดงผลให้ผู้เข้าชมเห็น)

เพิ่ม (หรือปรับ) ค่าคงที่เหล่านี้ วางไว้ในตำแหน่งที่กำหนด เปรี้ยว La ออนไลน์ /* That's all, stop editing! */ ถ้าไฟล์นั้นมีอยู่แล้ว

<?php
// ... contenu existant ...

/**
 * Debug WordPress (WordPress 6.9.4+ / PHP 8.1+)
 * Objectif : écrire les erreurs dans wp-content/debug.log sans les afficher aux visiteurs.
 */
define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );

// Évite d'afficher des erreurs PHP directement dans le HTML.
@ini_set( 'display_errors', '0' );

ถัดไป :

  1. รีเฟรชหน้าว่าง (หน้าแรกหรือหน้าผู้ดูแลระบบ)
  2. เปิด wp-content/debug.log และมองหาความผิดพลาดครั้งสุดท้าย

ตัวอย่างข้อผิดพลาดที่คุณอาจพบเห็น:

PHP Fatal error:  Uncaught Error: Call to undefined function my_plugin_helper() in /wp-content/plugins/mon-plugin/mon-plugin.php:88
PHP Fatal error:  Allowed memory size of 268435456 bytes exhausted (tried to allocate 20480 bytes) in /wp-includes/class-wpdb.php on line ...

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

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

แหล่งที่มาอย่างเป็นทางการ: ดีบัก WordPress

วิธีแก้ปัญหาที่ 2: แยกปัญหาความขัดแย้งระหว่างปลั๊กอิน/ธีม (วิธีสำหรับผู้เริ่มต้น + วิธี "โดยไม่ต้องเข้าถึงสิทธิ์ผู้ดูแลระบบ")

จากประสบการณ์ของผม WSOD มักเกิดจากการอัปเดตปลั๊กอิน (หรือตัวสร้างเว็บเบราว์เซอร์) ที่ทำให้เกิดข้อผิดพลาดร้ายแรง วิธีแก้ปัญหาคือ: ย้อนกลับไปใช้การตั้งค่าขั้นต่ำ จากนั้นเปิดใช้งานทีละตัว

วิธี A (สำหรับผู้เริ่มต้น): จากแผงควบคุมผู้ดูแลระบบ หากคุณมีสิทธิ์เข้าถึง

  1. ไป ส่วนขยาย> ส่วนขยายที่ติดตั้ง.
  2. เลือกทั้งหมด จากนั้น ยกเลิกการใช้งาน.
  3. ทดสอบเว็บไซต์
  4. เปิดใช้งานอีกครั้ง ต่อทีละส่วน จนกว่าจะเกิด WSOD ขึ้นอีกครั้ง

ขั้นตอนต่อไป ให้เปลี่ยนไปใช้ธีมมาตรฐานชั่วคราว:

  • ลักษณะที่ปรากฏ > ธีม > เปิดใช้งานธีมอย่างเป็นทางการ (มักจะเป็นธีม Twenty*)
  • ลองใหม่อีกครั้ง

หากคุณใช้ Divi 5, Elementor หรือ Avada: ธีม/โปรแกรมสร้างเว็บไซต์เหล่านี้เพิ่มโค้ดจำนวนมาก ซึ่งอาจเกิดความขัดแย้งกับปลั๊กอินแคช/ความปลอดภัยได้ การทดสอบโดย "ปิดใช้งานธีมเริ่มต้นและปลั๊กอิน" เป็นวิธีที่เร็วที่สุดในการหยุดวงจรปัญหาดังกล่าว

วิธี B (โดยไม่ต้องมีสิทธิ์ผู้ดูแลระบบ): ผ่าน FTP/SFTP

Si /wp-admin ถ้าเป็นสีขาว ให้ใช้ FTP/SFTP

ขั้นตอนที่ 1: ปิดใช้งานปลั๊กอินทั้งหมดพร้อมกัน

ควรเข้าไปแทรกแซงที่จุดใด: เปลี่ยนชื่อโฟลเดอร์ wp-content/plugins en plugins.offWordPress จะถือว่าปลั๊กอินเหล่านั้นไม่มีอยู่และจะปิดใช้งานพวกมัน

# Exemple (le nom exact dépend de votre outil FTP)
wp-content/plugins  →  wp-content/plugins.off

ทดสอบเว็บไซต์ หากปัญหายังคงเกิดขึ้น แสดงว่า "ปลั๊กอินเป็นสาเหตุ" จากนั้นให้ติดตั้งปลั๊กอินใหม่:

wp-content/plugins.off  →  wp-content/plugins

จากนั้นข้างใน pluginsเปลี่ยนชื่อโฟลเดอร์ทีละโฟลเดอร์ (เช่น elementor → elementor.off) เพื่อค้นหาผู้กระทำผิด

ขั้นตอนที่ 2: บังคับใช้ธีมสำรองหากธีมหลักเกิดข้อผิดพลาด

หากเว็บไซต์ยังคงเป็นสีขาวแม้จะปิดใช้งานปลั๊กอินแล้ว แสดงว่าธีม (หรือธีมย่อย) อาจมีปัญหา

ตัวเลือกเสริม (Option) ง่าย : เปลี่ยนชื่อโฟลเดอร์ของธีมที่ใช้งานอยู่ (หรือธีมลูก) WordPress จะเปลี่ยนไปใช้ธีมอื่นที่มีให้เลือก

wp-content/themes/mon-theme-enfant  →  wp-content/themes/mon-theme-enfant.off

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

หากคุณต้องการคู่มือการแก้ไขปัญหาอย่างเป็นทางการ: คำถามที่พบบ่อยเกี่ยวกับการแก้ไขปัญหา (WordPress.org)

วิธีแก้ปัญหาที่ 3: แก้ไขปัญหาโปรแกรมหยุดทำงานเนื่องจากหน่วยความจำไม่เพียงพอ (PHP/WordPress)

หน่วยความจำไม่เพียงพอเป็นปัญหาที่พบได้บ่อยในเว็บไซต์ที่ใช้ Elementor/Divi/Avada + WooCommerce + ปลั๊กอินด้านความปลอดภัย/แคช อาการที่พบได้บางครั้งคือหน้าจอสีขาว (WSOD) บางครั้งคือข้อผิดพลาด 500 และบางครั้งคือตัวแก้ไขไม่สามารถโหลดได้

ข้อความทั่วไปใน debug.log :

PHP Fatal error: Allowed memory size of 268435456 bytes exhausted (tried to allocate ...)

ขั้นตอนที่ 1: เพิ่มหน่วยความจำฝั่ง WordPress (อย่างรวดเร็ว)

ควรเข้าไปแทรกแซงที่จุดใด: dans wp-config.phpก่อนที่จะกด “หยุดแก้ไข”

ก่อนหน้านี้ (ไม่มีขีดจำกัดที่ชัดเจน)

<?php
// ...

หลังจาก (ขอให้ WordPress ใช้หน่วยความจำเพิ่มขึ้น)

<?php
// ...

/**
 * Augmente la mémoire pour WordPress.
 * Attention : si PHP a une limite plus basse, cela ne suffira pas.
 */
define( 'WP_MEMORY_LIMIT', '256M' );
define( 'WP_MAX_MEMORY_LIMIT', '512M' ); // Utile pour l'admin et certaines tâches lourdes.

เหตุผลที่มันได้ผล: WP_MEMORY_LIMIT คำสั่งนี้จะแจ้ง WordPress ถึงขนาดหน่วยความจำเป้าหมาย แต่หากเซิร์ฟเวอร์ของคุณกำหนดขีดจำกัดที่ต่ำกว่าไว้ WordPress จะไม่สามารถใช้หน่วยความจำเกินกว่านั้นได้

ขั้นตอนที่ 2: เพิ่มการจัดสรรหน่วยความจำฝั่ง PHP (มักเป็นสิ่งจำเป็น)

ขึ้นอยู่กับผู้ให้บริการโฮสติ้งของคุณ ขั้นตอนนี้จะดำเนินการผ่าน:

  • คณะกรรมการที่พัก (แนะนำ)
  • ไฟล์ php.ini ou .user.ini,
  • หรือการตั้งค่า PHP-FPM (หากคุณเป็นผู้ดูแลระบบเซิร์ฟเวอร์)

ตัวอย่าง (ไฟล์) .user.ini (ในบริการโฮสติ้งแบบแชร์หลายแห่ง):

memory_limit = 512M
max_execution_time = 120

เอกสารอ้างอิงอย่างเป็นทางการของ PHP (memory_limit): php.net memory_limit

สิ่งที่ผมกำลังทดสอบหลังจากเพิ่มหน่วยความจำ

  • กำลังโหลดหน้าว่าง
  • เปิดใช้งานโปรแกรมแก้ไขข้อความ (Elementor/Divi/Avada)
  • หากใช้ WooCommerce: ต้องมีฟังก์ชันเพิ่มลงในตะกร้าสินค้า ชำระเงิน และหน้ารายละเอียดสินค้า

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

วิธีแก้ปัญหาที่ 4: ซ่อมแซมโค้ดสั้นที่เสียหาย (functions.php / ปลั๊กอินโค้ดสั้น) โดยไม่ทำให้ทุกอย่างพัง

สถานการณ์ที่น่าหงุดหงิดที่สุดคือ คุณเพิ่มโค้ด 10 บรรทัด "เพื่อปรับปรุง WordPress" แล้วบันทึก... แต่ทุกอย่างกลับว่างเปล่า ฉันมักเห็นเหตุการณ์แบบนี้ในเว็บไซต์ที่โค้ดถูกวางลงในไฟล์ผิด หรือขาดวงเล็บ

ข้อกำหนด:

  • เศษเล็กเศษน้อย : โค้ดชิ้นเล็กๆ ที่เพิ่มเข้าไปในธีม (มักจะเป็น...) functions.phpหรือผ่านทางปลั๊กอิน
  • ข้อผิดพลาดทางไวยากรณ์ PHP ไม่สามารถอ่านไฟล์ได้ (ขาดเครื่องหมายเซมิโคลอน หรือมีวงเล็บปีกกาเกิน...) ซึ่งเป็นข้อผิดพลาดร้ายแรง

กรณี A: เพิ่มโค้ดลงในไฟล์ functions.php (ธีมลูก)

ควรเข้าไปแทรกแซงที่จุดใด: wp-content/themes/VOTRE-THEME-ENFANT/functions.php

ข้อผิดพลาดที่พบได้บ่อยมาก: ลืมใส่เครื่องหมายอัฒภาค หรือลืมปิดวงเล็บปีกกา

ก่อนหน้า (ข้อความไม่สมบูรณ์: ขาดเครื่องหมายเซมิโคลอน)

<?php
add_action( 'wp_enqueue_scripts', 'mon_site_styles' );

function mon_site_styles() {
	// Charge une feuille de style
	wp_enqueue_style( 'mon-style', get_stylesheet_directory_uri() . '/style.css' )
}

หลังจาก (แก้ไขแล้ว)

<?php
add_action( 'wp_enqueue_scripts', 'mon_site_styles' );

function mon_site_styles() {
	// Charge une feuille de style
	wp_enqueue_style( 'mon-style', get_stylesheet_directory_uri() . '/style.css' );
}

เหตุผลที่วิธีนี้แก้ปัญหาได้: PHP ต้องการเครื่องหมายเซมิโคลอนเพื่อปิดท้ายคำสั่ง หากไม่มีเครื่องหมายนี้ จะทำให้เกิดข้อผิดพลาดในการวิเคราะห์ และ WordPress จะไม่สามารถโหลดได้อีกต่อไป

กรณี B: โค้ดใช้ hook เร็วเกินไป (ฟังก์ชัน "ยังไม่ถูกโหลด")

อีกกรณีหนึ่งที่ผมเคยเจอคือ บทช่วยสอนเก่าๆ บทหนึ่งแนะนำให้เรียกใช้ฟังก์ชันที่ยังไม่มีอยู่จริงเมื่อโค้ดของคุณถูกประมวลผล

ก่อนหน้านี้ (เสียหาย: ดำเนินการทันทีเร็วเกินไป)

<?php
// Mauvaise idée : ce code s'exécute dès le chargement du fichier.
ma_fonction_qui_depend_de_wordpress();

function ma_fonction_qui_depend_de_wordpress() {
	// Exemple : vous faites des appels à des APIs WordPress non disponibles à cet instant
	update_option( 'test', 'ok' );
}

หลังจาก (แก้ไข: การดำเนินการผ่านการกระทำ)

<?php
/**
 * On utilise une action pour attendre que WordPress soit chargé.
 * Une "action" est un hook qui déclenche votre code à un moment précis.
 */
add_action( 'init', 'ma_fonction_qui_depend_de_wordpress' );

function ma_fonction_qui_depend_de_wordpress() {
	update_option( 'test', 'ok' );
}

เหตุผลที่แก้ไข: init ฟังก์ชันนี้จะทำงานหลังจาก WordPress โหลดเสร็จแล้ว ซึ่งจะป้องกันการเรียกใช้งานก่อนเวลาอันควร

กรณี C: การใช้โค้ดตัวอย่างผ่านปลั๊กอิน (WPCode, Code Snippets เป็นต้น)

หากคุณใช้ปลั๊กอินสำหรับแสดงโค้ดสั้นๆ ข้อดีคือบางครั้งมันสามารถปิดใช้งานโค้ดสั้นๆ ที่มีปัญหาโดยอัตโนมัติได้ แต่หากไม่สามารถเข้าถึงแผงควบคุมผู้ดูแลระบบได้ ให้ปิดใช้งานปลั๊กอินแสดงโค้ดสั้นๆ ผ่าน FTP (วิธีที่ 2) จากนั้นแก้ไขโค้ดสั้นๆ นั้น

อ้างอิง (ส่วนเชื่อมต่อ): developer.wordpress.org/plugins/hooks

วิธีแก้ปัญหาที่ 5: กำจัด WSOD ปลอมที่เกิดจากแคช (แคชหน้าเว็บ, CDN, OPcache)

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

ฉันเห็นแบบนี้บ่อยๆ ใน:

  • เว็บไซต์ที่อยู่เบื้องหลัง Cloudflare (หรือ CDN อื่นๆ)
  • ผู้ให้บริการโฮสติ้งที่มีการแคชเซิร์ฟเวอร์อย่างเข้มงวด
  • เว็บไซต์ที่มีการเปิดใช้งาน OPcache และปิดใช้งานอย่างไม่ถูกต้องหลังจากการติดตั้งใช้งาน

ขั้นตอนที่ 1: ล้างแคชที่ "มองเห็นได้"

  • ล้างแคชของปลั๊กอินของคุณ (LiteSpeed ​​​​Cache, WP Rocket, W3TC…)
  • ล้างแคช CDN (Cloudflare: “ล้างทุกอย่าง” หรือล้างแคชแบบเจาะจง)
  • ทดสอบในโหมดการเรียกดูแบบส่วนตัว + โดยการเพิ่มพารามิเตอร์: ?nocache=1

ขั้นตอนที่ 2: OPcache (ฝั่งเซิร์ฟเวอร์)

หากคุณสามารถเข้าถึงเซิร์ฟเวอร์ได้ วิธีแก้ปัญหาที่มีประสิทธิภาพที่สุดคือการรีสตาร์ท PHP-FPM (ขึ้นอยู่กับระบบปฏิบัติการที่คุณใช้) ตัวอย่าง (Linux):

sudo systemctl reload php8.2-fpm

หากคุณใช้บริการโฮสติ้งแบบแชร์ คุณจะไม่มีคำสั่งนี้ ในกรณีนั้น:

  • มองหาตัวเลือก “ล้าง OPcache” ในแผงควบคุม
  • หรือขอให้ฝ่ายสนับสนุนล้าง OPcache (นี่เป็นคำขอมาตรฐานทั่วไป)

เหตุผลที่วิธีนี้แก้ปัญหาได้: OPcache สามารถเก็บเวอร์ชันเก่าของไฟล์ PHP ไว้ในหน่วยความจำได้ คุณแก้ไขไฟล์แล้ว... แต่ PHP ยังคงเรียกใช้เวอร์ชันเก่าอยู่

เอกสารอ้างอิงอย่างเป็นทางการของ OPcache: php.net OPcache

การตรวจสอบหลังการแก้ไข

เมื่อเว็บไซต์กลับมาใช้งานได้แล้ว ผมจะทำการทดสอบ "พื้นฐานแต่ได้ผล" แบบเดิมเสมอ:

  1. ด้านหน้า : หน้าแรก + 2-3 หน้าภายใน + ฟังก์ชันค้นหา
  2. ผู้ดูแลระบบ : แดชบอร์ด, ส่วนขยาย, ลักษณะที่ปรากฏ, ตัวแก้ไข (ถ้าใช้งาน)
  3. ผู้สร้าง :
    • Elementor: เปิดตัวแก้ไข + บันทึกการเปลี่ยนแปลง
    • Divi 5: เปิด Visual Builder แล้วตรวจสอบตัวอย่างการแสดงผลแบบ Responsive
    • Avada: เปิด Fusion Builder แล้วตรวจสอบช่องแก้ไขคอนเทนเนอร์
  4. รูปแบบ : ส่งแบบฟอร์ม (ติดต่อ/สมัครรับจดหมายข่าว)
  5. REST API : ทดสอบอย่างรวดเร็วโดยการเยี่ยมชม /wp-json/ (คุณควรเห็นข้อมูล JSON ไม่ใช่หน้าว่างเปล่า)

ถัดไป :

  • อ่านอีกครั้ง wp-content/debug.log หากเว็บไซต์ยังคงเติบโตต่อไป แสดงว่าคุณยังคงพบข้อผิดพลาดอยู่ (แม้ว่าเว็บไซต์จะ "ใช้งานได้" ก็ตาม)
  • ปิดใช้งานการดีบักหากคุณเปิดใช้งานไว้ในเวอร์ชันใช้งานจริง (วิธีแก้ปัญหาที่ 1)

ถ้าวิธีนั้นยังไม่ได้ผลอีก

เมื่อ 5 วิธีแก้ปัญหาสำหรับ "มือใหม่" ยังไม่เพียงพอ ผมก็จะหันไปใช้วิธีการที่เป็นระบบมากขึ้น วิธีนี้ยังคงใช้ได้ แต่ต้องอาศัยวิธีการสักหน่อย

1) ตรวจสอบบันทึกของเซิร์ฟเวอร์ (มักให้ข้อมูลมากกว่าไฟล์ debug.log)

ในผู้ให้บริการโฮสติ้งหลายราย คุณจะพบ "บันทึกข้อผิดพลาด" ของ Apache/Nginx ในแผงควบคุม ให้มองหา:

  • PHP Fatal error
  • Premature end of script headers
  • Allowed memory size

2) ใช้ฟังก์ชันตรวจสอบสถานะระบบ (โหมดแก้ไขปัญหา)

หากคุณมีสิทธิ์เข้าถึงในฐานะผู้ดูแลระบบ ปลั๊กอิน Health Check จะช่วยให้คุณสามารถปิดใช้งานปลั๊กอิน/ธีมได้ เพื่อคุณโดยเฉพาะโดยไม่ส่งผลกระทบต่อผู้เข้าชม วิธีนี้มีประโยชน์มากบนเว็บไซต์ที่ใช้งานจริง

ปลั๊กอิน: ตรวจสอบสุขภาพและแก้ไขปัญหา

3) ตรวจสอบเวอร์ชัน PHP ที่ใช้งานอยู่จริง

เว็บไซต์อาจ "คิด" ว่ากำลังใช้งาน PHP 8.1 แต่โดเมนย่อยหรือ cron job อาจใช้งานเวอร์ชัน 7.4 อยู่ (ผมเคยเจอมาแล้ว) ตรวจสอบได้ที่นี่:

  • เครื่องมือ > สุขภาพเว็บไซต์
  • หรือแผงควบคุมของผู้ให้บริการโฮสติ้ง

4) ปิดใช้งานปลั๊กอิน mu ชั่วคราว

les mu-ปลั๊กอิน ปลั๊กอินที่จำเป็นต้องใช้จะถูกโหลดโดยอัตโนมัติจาก wp-content/mu-pluginsไฟล์เหล่านี้ไม่ปรากฏอยู่ในรายการส่วนขยายมาตรฐาน ผู้ให้บริการโฮสติ้งบางรายใช้แคช/มาตรการรักษาความปลอดภัย

การทดสอบ: เปลี่ยนชื่อ mu-plugins en mu-plugins.off ผ่าน FTP จากนั้นทดสอบดู

5) ลิงก์ถาวร / กฎการเขียนใหม่ ("admin OK, pages 404/500")

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

การตั้งค่า> ลิงก์ถาวร แล้วคลิก Enregistrer (โดยไม่เปลี่ยนแปลงอะไรเลย)

เอกสารทางการ: WP-CLI (สำหรับมืออาชีพ) (มีประโยชน์หากคุณสามารถเข้าถึง SSH ได้ แต่ในที่นี้ไม่จำเป็นต้องทำก็ได้)

6) ตรวจสอบสิทธิ์การเข้าถึงไฟล์ (พบได้น้อย แต่เกิดขึ้นได้จริง)

การตั้งค่าสิทธิ์ที่เข้มงวดเกินไปอาจทำให้เกิดข้อผิดพลาดของเซิร์ฟเวอร์ ในสภาพแวดล้อม Linux ที่ใช้งานร่วมกัน เรามักพบเห็นสิ่งต่อไปนี้:

  • ไฟล์: 755
  • ไฟล์: 644

หากผู้ให้บริการโฮสติ้งของคุณมีคำแนะนำที่แตกต่างออกไป โปรดปฏิบัติตามคำแนะนำเหล่านั้น

ข้อผิดพลาดและปัญหาที่พบบ่อย

อาการ สาเหตุที่เป็นไปได้ วิธีแก้ปัญหาที่แนะนำ
คุณได้เปิดใช้งาน WP_DEBUG แล้ว แต่ debug.log ไม่ปรากฏ wp-content ไม่สามารถเขียนได้ / การกำหนดค่าไม่ถูกต้อง / เกิดข้อผิดพลาดก่อนการโหลด ตรวจสอบสิทธิ์การเข้าถึง จากนั้นดูบันทึกของเซิร์ฟเวอร์
หน้าจอขาว (WSOD) ปรากฏขึ้นทันทีหลังจากวางโค้ด ขาดเครื่องหมายเซมิโคลอน/วงเล็บปีกกา และวางโค้ดผิดที่ วิธีแก้ปัญหาที่ 4 (แก้ไขโค้ดตัวอย่าง) โดยควรทำเป็นปลั๊กอินแบบกำหนดเอง
มันใช้งานได้ในโหมดการท่องเว็บแบบส่วนตัว แต่ไม่ใช่ในโหมด "ปกติ" แคชเบราว์เซอร์ / ปลั๊กอิน / CDN วิธีแก้ปัญหาที่ 5 (การล้างข้อมูล) + ปิดใช้งานการย่อขนาดไฟล์ชั่วคราว
Elementor/Divi/Avada จะไม่เปิดโปรแกรมแก้ไขอีกต่อไป หน่วยความจำ, REST/AJAX ถูกบล็อกโดยระบบรักษาความปลอดภัย, ความขัดแย้งของปลั๊กอิน วิธีแก้ปัญหาที่ 3 + ตรวจสอบคอนโซล + ปิดใช้งานปลั๊กอินความปลอดภัย
คุณทำตามบทช่วยสอนเก่า โค้ดไม่เข้ากัน WordPress 6.9.4 / PHP 8.1 เปลี่ยนไปใช้วิธีการที่ใช้ hooks ปัจจุบัน แล้วทดสอบในสภาพแวดล้อมทดสอบ
คุณได้แก้ไขธีมหลักแล้ว การแก้ไขอาจสูญหายหลังการอัปเดต และมีความเสี่ยงที่จะเกิดความเสียหาย กลับไปใช้ธีมย่อยหรือปลั๊กอินที่กำหนดเอง (ดูส่วน “สิ่งที่ควรหลีกเลี่ยง”)
หน้าจอสีฟ้า (WSOD) กลับมาปรากฏอีกครั้งหลังจาก "แก้ไข" แล้ว OPcache/CDN ยังคงให้บริการเวอร์ชันเก่าอยู่ วิธีแก้ปัญหาที่ 5 (ล้างแคชและติดตั้ง PHP-FPM ใหม่ หากเป็นไปได้)

ข้อผิดพลาด "จากมนุษย์" ที่พบบ่อยที่สุดที่ผมเห็น:

  • วางข้อความย่อลงใน ไฟล์เสีย (เช่น ในเทมเพลตแทนที่จะเป็น) functions.php).
  • การลืม วงเล็บ หรือ อัฒภาค.
  • ทำให้เกิดความสับสน การกระทำ et ฟิลเตอร์ (เช่น การใช้งาน) add_action แทน add_filter).
  • ทดสอบโดยตรงบน การผลิต โดยไม่มีการสำรองข้อมูล
  • ลืมไป ล้างแคช หลังจากแก้ไขแล้ว

รูปแบบอื่น / ทางเลือกอื่น

วิธีการแบบไม่ต้องเขียนโค้ด (แนะนำสำหรับผู้เริ่มต้น)

หากคุณสามารถเข้าถึงแผงควบคุมผู้ดูแลระบบได้ โปรดติดตั้งสิ่งต่อไปนี้:

  • การตรวจสุขภาพ หากต้องการปิดใช้งานปลั๊กอิน/ธีมเฉพาะในเซสชันของคุณ: wordpress.org/plugins/health-check
  • Query Monitor เพื่ออ่านข้อผิดพลาดและระบุ hook หรือ plugin ที่มีปัญหา: wordpress.org/plugins/query-monitor

นี่เป็นวิธีที่ปลอดภัยที่สุดในการใช้งานเว็บไซต์ออนไลน์: คุณทำการสำรวจโดยไม่รบกวนประสบการณ์ของผู้เยี่ยมชม

วิธีการขั้นสูงกว่า (สำหรับนักพัฒนา): การสำรองข้อมูลปลั๊กอิน mu

หากคุณแก้ไขปัญหาบ่อยครั้ง (หรือจัดการหลายเว็บไซต์) คุณสามารถสร้างได้ mu- ปลั๊กอิน (โหลดโดยอัตโนมัติ) เพื่อบังคับให้มีการบันทึกข้อมูลน้อยที่สุดและหลีกเลี่ยงการแสดงข้อผิดพลาด

ควรวางโค้ดไว้ที่ใด: สร้างไฟล์ wp-content/mu-plugins/00-rescue.php (สร้างโฟลเดอร์หากยังไม่มีอยู่)

<?php
/**
 * Plugin Name: Rescue minimal
 * Description: Aide au dépannage : loggue des infos minimales si le site plante tôt.
 * Author: Votre Nom
 *
 * Attention : ceci ne remplace pas WP_DEBUG. C'est un filet de sécurité.
 */

if ( ! defined( 'ABSPATH' ) ) {
	exit;
}

// Exemple : log simple pour confirmer que WordPress charge bien les mu-plugins.
error_log( '[Rescue] mu-plugin chargé' );

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

เอกสารอ้างอิงอย่างเป็นทางการเกี่ยวกับปลั๊กอิน mu: developer.wordpress.org/advanced-administration/plugins/mu-plugins

หลีกเลี่ยงปัญหานี้ในอนาคต

อาการ WSOD จะกลับมาอีกครั้งเมื่อคุณแก้ไขปัญหาเฉพาะหน้าโดยไม่เปลี่ยนนิสัย นี่คือสิ่งที่จะช่วยลดความเสี่ยงได้อย่างแท้จริง

1) โปรดทำการแก้ไขในปลั๊กอินที่กำหนดเอง ไม่ใช่ในไฟล์ functions.php

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

ควรวางโค้ดไว้ที่ใด: สร้าง wp-content/plugins/mon-plugin-custom/mon-plugin-custom.phpจากนั้นจึงเปิดใช้งาน

<?php
/**
 * Plugin Name: Mon plugin custom
 * Description: Snippets stables pour ce site (WordPress 6.9.4+ / PHP 8.1+).
 * Version: 1.0.0
 */

if ( ! defined( 'ABSPATH' ) ) {
	exit;
}

/**
 * Exemple : on accroche un code sur une action.
 */
add_action( 'init', function () {
	// Code sûr : exécuté après le chargement de WordPress.
} );

2) ดำเนินการตามแผนการจัดลำดับขั้นตอน

ทดสอบการอัปเดต (WordPress, ปลั๊กอิน, ธีม, ตัวสร้างเว็บไซต์) ในสภาพแวดล้อมทดสอบ มันคือความแตกต่างระหว่าง "ความเครียด 5 นาที" กับ "ความตื่นตระหนก 2 ชั่วโมง"

3) ตรวจสอบความเข้ากันได้กับ PHP เวอร์ชัน 8.1 ขึ้นไป

ปลั๊กอินที่ไม่ได้รับการดูแลรักษาอาจใช้งานไม่ได้หลังจากอัปเกรดเวอร์ชัน PHP ตรวจสอบความเข้ากันได้ในหน้าของปลั๊กอิน (wordpress.org) และติดตามบันทึกการเปลี่ยนแปลงอย่างสม่ำเสมอ

4) จัดให้มีทางเข้าออกฉุกเฉิน

  • การเข้าถึง SFTP/FTP ที่ใช้งานได้
  • สามารถเข้าถึงแผงควบคุมโฮสติ้ง (บันทึกการทำงาน เวอร์ชัน PHP แคช)
  • สำรองข้อมูลทุกวัน (ควรเป็นแบบภายนอก)

5) แคช: จัดทำเอกสารเกี่ยวกับ “เส้นทางการล้างแคช” ของคุณ

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

ทรัพยากร

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

หน้าจอสีขาว (WSOD) จำเป็นต้องเกิดจากปลั๊กอินหรือไม่?

ไม่เลย ธีม ธีมย่อย โค้ดส่วนย่อย หน่วยความจำไม่เพียงพอ หรือแคชของเซิร์ฟเวอร์ ล้วนสามารถทำให้เกิดอาการเดียวกันได้ วิธีที่เร็วที่สุดยังคงเป็นการใช้ debug.log ร่วมกับการปิดใช้งานแบบกลุ่ม (วิธีแก้ปัญหาที่ 1 และ 2)

ทำไมฉันถึงไม่ได้รับข้อความแสดงข้อผิดพลาดใดๆ เลย?

เนื่องจากเซิร์ฟเวอร์ส่วนใหญ่จะซ่อนข้อผิดพลาด PHP ในสภาพแวดล้อมการใช้งานจริง ซึ่งเป็นเรื่องปกติ (เพื่อความปลอดภัย) เปิดใช้งานการบันทึกข้อมูลผ่านทาง WP_DEBUG_LOG เพื่อดึงข้อมูลข้อผิดพลาดโดยไม่แสดงให้ผู้เข้าชมเห็น

ฉันสามารถแก้ไขปัญหานี้ได้โดยไม่ต้องใช้ FTP หรือไม่?

ใช่ ถ้าคุณมีสิทธิ์เข้าถึงระดับผู้ดูแลระบบ การตรวจสอบสถานะระบบ (Health Check) และการปิดใช้งานปลั๊กอินมักจะเพียงพอแล้ว แต่ถ้าไม่มีสิทธิ์เข้าถึงระดับผู้ดูแลระบบ การเข้าถึงไฟล์ (FTP/SFTP) คือวิธีที่ตรงที่สุด

เว็บไซต์ของฉันเป็นสีขาวแค่หน้าเดียว ไม่ได้เป็นทุกหน้า ทำไมถึงเป็นเช่นนั้น?

หน้านี้มีแนวโน้มที่จะเรียกใช้โค้ดเฉพาะบางอย่าง เช่น ชอร์ตโค้ด วิดเจ็ต เทมเพลต คำขอที่ใช้ทรัพยากรมาก หรือเนื้อหาที่ใช้หน่วยความจำไม่เพียงพอ เปิดใช้งานการดีบัก จากนั้นโหลดหน้านี้ซ้ำอีกครั้งเพื่อดูการติดตามการทำงานที่ใช้งานได้

Elementor แสดงหน้าจอสีขาวในโปรแกรมแก้ไข: มันเหมือนกันหรือไม่?

โดยส่วนใหญ่แล้วใช่ แต่ปัญหาอาจอยู่ที่ฝั่ง REST API/AJAX ตรวจสอบแท็บ Network: หากคำขอไปยัง /wp-json/ ou admin-ajax.php หากแสดงรหัสข้อผิดพลาด 500 ให้ตรวจสอบหาข้อผิดพลาดของ PHP (วิธีแก้ปัญหาที่ 1) หรือหน่วยความจำไม่เพียงพอ (วิธีแก้ปัญหาที่ 3)

หลังจากแก้ไขแล้ว ฉันก็ยังเห็นหน้าจอสีขาวอยู่ ฉันควรทำอย่างไรดี?

ลองพิจารณาเรื่องการแคชดู เช่น การเรียกดูแบบส่วนตัว การล้างปลั๊กอิน การล้าง CDN และถ้าเป็นไปได้ การล้าง OPcache (วิธีแก้ปัญหาที่ 5) นี่เป็นกับดักที่พบได้บ่อยมาก

การเปิดใช้งาน WP_DEBUG ในเว็บไซต์ที่ใช้งานจริงนั้นอันตรายหรือไม่?

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

ฉันต้องแก้ไขไฟล์ใดบ้าง: functions.php, wp-config.php หรือ .htaccess?

เพื่อการวินิจฉัย: wp-config.php (วิธีแก้ปัญหาที่ 1) เพื่อแก้ไขส่วนของโค้ด: functions.php จากธีมย่อย หรือที่ดีกว่านั้นคือปลั๊กอินแบบกำหนดเอง (วิธีแก้ปัญหาที่ 4 / “หลีกเลี่ยง”) .htaccess เหมาะสำหรับแก้ไขปัญหาการเขียนทับลิงก์/การสร้างลิงก์ถาวรมากกว่า ไม่ใช่สำหรับปัญหาหน้าจอขาวผิดปกติส่วนใหญ่

เว็บไซต์กลับมาใช้งานได้เมื่อฉันปิดใช้งานปลั๊กอิน แต่ฉันจำเป็นต้องใช้ปลั๊กอินนั้น ฉันควรทำอย่างไรดี?

โปรดจดบันทึกข้อผิดพลาดที่เกิดขึ้นอย่างแม่นยำ (ไฟล์/บรรทัด) และอัปเดตปลั๊กอิน จากนั้นติดต่อผู้พัฒนาพร้อมแนบไฟล์บันทึกข้อผิดพลาดไปด้วย ในระหว่างนี้ ให้ลองหาทางเลือกอื่น หรือปิดใช้งานเฉพาะฟีเจอร์ที่ทำให้เกิดข้อผิดพลาด (ส่วนใหญ่จะเป็นการแคช/การย่อขนาดไฟล์/การรักษาความปลอดภัย)

บทความที่เกี่ยวข้อง

ส่งความคิดเห็น

ที่อยู่อีเมลของคุณจะไม่ถูกเผยแพร่ ช่องที่ต้องการถูกทำเครื่องหมาย *

ไซต์นี้ใช้ Akismet เพื่อลดสแปม เรียนรู้วิธีการประมวลผลข้อมูลความคิดเห็นของคุณ