แก้ไขข้อผิดพลาดร้ายแรงของ SMTP POST ในการตั้งค่า

by | WordPress

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

มีปัญหา

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

ต่อไปนี้คือข้อความแสดงข้อผิดพลาดที่เกิดขึ้นจริงบางส่วนที่ผมเคยเห็นในบันทึกของเว็บไซต์ WordPress 6.9.x (คำพูดที่แน่นอนอาจแตกต่างกันไปขึ้นอยู่กับผู้ให้บริการโฮสติ้งและโหมดการดีบัก):

Fatal error: Uncaught TypeError: array_merge(): Argument #2 must be of type array, string given
in /wp-content/plugins/post-smtp/Postman/PostmanViewController.php:1234
Stack trace:
#0 ...
Fatal error: Uncaught Error: Call to undefined function wp_get_environment_type()
in /wp-content/plugins/post-smtp/Postman/Postman.php:210
Fatal error: Uncaught Error: Class "VendorPackageSomeClass" not found
in /wp-content/plugins/post-smtp/vendor/.../autoload.php:...
Fatal error: Allowed memory size of 268435456 bytes exhausted (tried to allocate 20480 bytes)
in /wp-content/plugins/post-smtp/.../Settings.php on line ...

ปรากฏที่ใด:

  • ผู้ดูแลระบบ โดยเฉพาะอย่างยิ่งในเรื่อง /wp-admin/admin.php?page=postman (หรือรูปแบบอื่น)
  • AJAX บางครั้ง ในระหว่างการโหลดแท็บ หากหน้าการตั้งค่าเรียกใช้งาน ผู้ดูแลระบบ ajax.php.
  • REST API : พบได้ไม่บ่อยนัก แต่ปลั๊กอินสมัยใหม่บางตัวโหลดข้อมูลผ่านทางนี้ /wp-json/.

สถานการณ์ทั่วไป:

  • ยุติธรรม หลังจากการอัปเดต จาก Post SMTP หรือจาก WordPress (ในที่นี้คือ WordPress 6.9.4)
  • หลังจากการเปลี่ยนแปลง เวอร์ชัน PHP (การเปลี่ยนไปใช้เวอร์ชัน 8.1/8.2/8.3) ซึ่งทำให้ข้อผิดพลาด "เงียบๆ" เข้มงวดมากขึ้น (TypeError)
  • หลังจากเปิดใช้งานปลั๊กอินรักษาความปลอดภัย/แคชที่แก้ไขส่วนผู้ดูแลระบบ (การย่อขนาดไฟล์, การบล็อก REST/AJAX, กฎ WAF)

เหมาะสำหรับ: บล็อกเกอร์มือใหม่ คุณจะได้เรียนรู้สิ่งต่างๆ ดังนี้ ดึงข้อมูลร่องรอยที่แท้จริงกลับมา, แยกความขัดแย้งออกไปจากนั้นให้ใช้วิธีแก้ปัญหาที่ปลอดภัย (โดยไม่แตะต้องแกนหลักของ WordPress) ในตอนท้าย คุณจะรู้ว่าต้องให้ข้อมูลอะไรแก่ฝ่ายสนับสนุน (บันทึกการทำงานที่สะอาดหมดจด ขั้นตอนที่ดำเนินการ เวอร์ชัน)

สรุปด่วน

  • เปิดใช้งานโหมดการวินิจฉัยที่สะอาด: WP_DEBUG + บันทึกและดึงร่องรอยที่แน่นอนของ ความผิดพลาด.
  • ทดสอบหน้าการตั้งค่าด้วย การตรวจสุขภาพ (โหมดแก้ไขปัญหา) เพื่อยืนยัน ความขัดแย้งระหว่างปลั๊กอิน/ธีม.
  • อุบัติเหตุหลายครั้งมีสาเหตุมาจากตัวเลือก SMTP ของโพสต์ที่เสียหาย หลังการอัปเดต: รีเซ็ตเป้าหมายผ่าน WP-CLI หรือฐานข้อมูล
  • ข้อผิดพลาด "ไม่พบคลาส" มักบ่งชี้ถึง... ผู้ขาย/โหลดอัตโนมัติ ไม่สมบูรณ์: ติดตั้งปลั๊กอินใหม่ (อย่างสะอาดหมดจด) แทนที่จะใช้แพทช์แบบไม่รู้ที่มา
  • ข้อผิดพลาด "หน่วยความจำหมด" จะได้รับการแก้ไขที่ฝั่งเซิร์ฟเวอร์ (ข้อจำกัดของ PHP) และลดภาระงานของผู้ดูแลระบบ (การตั้งค่าแคช/การย่อขนาดไม่ถูกต้อง)

มีอาการ

ขึ้นอยู่กับเซิร์ฟเวอร์ คุณอาจเห็นข้อความต่อไปนี้:

  • ข้อผิดพลาด 500 โดยเปิด Post SMTP → Settings
  • หน้าจอสีขาว (WSOD) เฉพาะในหน้าผู้ดูแลระบบนี้เท่านั้น
  • ข้อความ "เกิดข้อผิดพลาดร้ายแรงบนเว็บไซต์นี้" + อีเมล WordPress พร้อมตัวอย่างการติดตาม
  • โพสต์แท็บ/ส่วน SMTP ที่โหลดไม่ขึ้น พร้อมข้อผิดพลาดในคอนโซล (AJAX/REST ถูกบล็อก)
  • ไม่สามารถบันทึกการตั้งค่าได้ (ข้อมูลไม่ถูกต้อง, สิทธิ์การเข้าถึงไม่ถูกต้อง หรือเกิดข้อผิดพลาดร้ายแรงขณะส่งข้อมูล)

สัญญาณที่บ่งชี้ถึงสาเหตุเฉพาะ:

  • ส่วนหน้าเว็บใช้งานได้ แต่ส่วนติดต่อผู้ดูแลระบบมักล่ม: บ่อยครั้งเกิดจากสาเหตุนี้ ผู้ดูแลระบบ hook การใช้งานผิดวิธีหรือความขัดแย้งกับปลั๊กอิน "ตัวเพิ่มประสิทธิภาพผู้ดูแลระบบ"
  • มันใช้งานได้ในสภาพแวดล้อมจำลอง แต่ใช้ไม่ได้ในสภาพแวดล้อมการใช้งานจริง: บ่อยครั้งที่มันใช้งานได้ไม่ดี เวอร์ชัน PHP, mémoireหรือ WAF (ไฟร์วอลล์แอปพลิเคชัน)
  • มันพัง "ทันทีหลังการอัปเดต": ตัวเลือกไม่เข้ากัน, ผู้จำหน่าย autoloader, แคช OPcache

แผนภูมิการวินิจฉัยอย่างรวดเร็ว

อาการ สาเหตุที่เป็นไปได้ การตรวจสอบ Solution
ข้อผิดพลาดร้ายแรง “array_merge()… ระบุสตริง” ตัวเลือก SMTP ของ Post คาดว่าจะอยู่ในรูปแบบอาร์เรย์ แต่กลับถูกจัดเก็บในรูปแบบสตริง ดูการติดตามและตรวจสอบตัวเลือกในฐานข้อมูล วิธีแก้ปัญหาที่ 3 (รีเซ็ต/แปลงตัวเลือก)
“ไม่พบคลาส … vendor/autoload.php” ปลั๊กอินติดตั้งไม่ถูกต้อง / ผู้จำหน่ายไม่ครบถ้วน เปรียบเทียบโฟลเดอร์ปลั๊กอิน แล้วดาวน์โหลดใหม่อีกครั้งจาก wordpress.org ติดตั้งปลั๊กอินใหม่โดยล้างแคช OPcache ให้หมด
ข้อผิดพลาด 500 โดยไม่มีรายละเอียด ปิดใช้งานการบันทึก / WAF / แคช เปิดใช้งาน WP_DEBUG_LOG + บันทึกเซิร์ฟเวอร์ วิธีแก้ปัญหาที่ 1 + ปิดใช้งานแคช/ย่อขนาดไฟล์ในโหมดผู้ดูแลระบบ
หน้าการตั้งค่าว่างเปล่า เกิดข้อผิดพลาดในคอนโซล JS JS (การย่อขนาด) หรือความขัดแย้งของ REST/AJAX ถูกบล็อกแล้ว คอนโซลเบราว์เซอร์ + แท็บเครือข่าย ปิดใช้งานการย่อขนาดไฟล์สำหรับผู้ดูแลระบบ อนุญาตให้ใช้ /wp-json/
“พื้นที่หน่วยความจำที่อนุญาตเต็มแล้ว” หน่วยความจำ PHP ไม่เพียงพอสำหรับผู้ดูแลระบบ บันทึกข้อผิดพลาด + สุขภาพเว็บไซต์ เพิ่มค่า memory_limit (เซิร์ฟเวอร์) + จำกัดการใช้งานปลั๊กอินที่ใช้ทรัพยากรมาก

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

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

นี่คือสิ่งที่เกิดขึ้นเบื้องหลัง (ในเวอร์ชันเชิงเทคนิค):

  • WordPress โหลดปลั๊กอิน จากนั้นจึงเรียกใช้งาน... ตะขอHook คือ "จุดเชื่อมต่อ" ที่ปลั๊กอินสามารถเรียกใช้โค้ดได้ มีอยู่หลายประเภท การปฏิบัติ (ดำเนินการ) และ FILTRES (แก้ไขค่า)
  • หน้าการตั้งค่าจะแสดงขั้นตอนต่างๆ admin_menu (เพิ่มเมนู) จากนั้นโดยการโหลดหน้าจอ (บ่อยครั้ง) load- $ hook_suffix) จากนั้นจึงแสดงผล
  • การอ่านโพสต์ SMTP ตัวเลือก (จัดเก็บไว้ในฐานข้อมูลผ่านทาง) get_option()หากชนิดข้อมูลไม่ตรงตามที่คาดไว้ (เช่น สตริงแทนที่จะเป็นอาร์เรย์) PHP เวอร์ชัน 8.1 ขึ้นไปจะแสดงข้อผิดพลาด TypeErrors ที่เข้มงวดกว่าเดิม

สาเหตุเรียงลำดับจากที่พบบ่อยที่สุดไปจนถึงน้อยที่สุด (บน WordPress 6.9.4 / PHP 8.1 ขึ้นไป):

  1. ตัวเลือกการโพสต์ SMTP ที่เสียหายหรือล้าสมัย จากเวอร์ชันเก่ากว่า (การย้ายข้อมูลไม่สมบูรณ์)
  2. ความขัดแย้งของปลั๊กอิน (แคช/ย่อขนาด/ตัวเพิ่มประสิทธิภาพการดูแลระบบ/ความปลอดภัย) ซึ่งทำให้ AJAX/REST ทำงานผิดพลาดหรือเปลี่ยนแปลงลำดับการโหลด
  3. การติดตั้งไม่สมบูรณ์ ปลั๊กอิน (โฟลเดอร์ vendor หายไป ไฟล์ถูกตัดทอนหลังจากการอัปเดต)
  4. เวอร์ชัน PHP ที่ไม่รองรับ (เก่าเกินไป) หรือในทางตรงกันข้าม พฤติกรรมที่เข้มงวดกว่า (TypeError) ซึ่งเผยให้เห็นข้อบกพร่องที่ซ่อนอยู่
  5. ขีดจำกัดหน่วยความจำ การดูแลระบบในระดับต่ำเกินไป โดยเฉพาะในเว็บไซต์ขนาดใหญ่ (เช่น WooCommerce, เว็บไซต์สร้างเว็บไซต์ ฯลฯ)

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

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

  • ป้องกัน กรอกข้อมูลให้ครบถ้วน (ไฟล์ + ฐานข้อมูล) ห้ามดำเนินการเหล่านี้โดยตรงในระบบใช้งานจริงโดยไม่มีระบบสำรองเพื่อความปลอดภัย
  • การเข้าถึง:
    • FTP/SFTP หรือโปรแกรมจัดการไฟล์
    • ไฟล์ wp-config.php
    • ควรใช้ WP-CLI (เป็นทางเลือก แต่มีประโยชน์มาก)
  • เวอร์ชันที่แนะนำ: 6.9.4 WordPress et PHP ฮิต +(หากคุณกำลังใช้ PHP เวอร์ชัน 7.4/8.0 โปรดเริ่มต้นด้วยการอัปเกรด: เครื่องมือสมัยใหม่หลายตัวไม่ได้ทดสอบเวอร์ชันเหล่านี้อีกต่อไปแล้ว)
  • เครื่องมือที่มีประโยชน์:

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

วิธีแก้ปัญหาที่ 1: แยกหาสาเหตุของข้อผิดพลาดร้ายแรงและเก็บข้อมูลการติดตาม (WP_DEBUG, บันทึก, Query Monitor)

เมื่อมีคนบอกผมว่า “การตั้งค่า SMTP หลังการติดตั้งทำให้เกิดข้อผิดพลาดร้ายแรง” ผมมักจะเริ่มต้นด้วยสิ่งเดียวกันเสมอ นั่นคือ การตรวจสอบหาสาเหตุ ร่องรอยที่แน่นอนหากไม่มีการตั้งค่านี้ ปลั๊กอินจะถูกปิดใช้งานแบบสุ่ม

ขั้นตอนที่ 1 — เปิดใช้งานการบันทึกข้อมูล PHP ที่สะอาด (โดยไม่แสดงข้อผิดพลาดแก่ผู้เข้าชม)

เปิด wp-config.php (ในไดเร็กทอรีรากของ WordPress) และเพิ่ม/ปรับค่าคงที่เหล่านี้ วางไว้ที่ไฟล์เหล่านั้น เปรี้ยว ประโยคที่ว่า “แค่นี้แหละ หยุดตัดต่อได้แล้ว!”

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

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

define('WP_DEBUG', false);

// ...

โค้ด AFTER (แนะนำสำหรับการวินิจฉัยปัญหาในสภาพแวดล้อมการผลิตโดยไม่ให้เกิดการรั่วไหลของข้อมูล):

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

/**
 * Diagnostic : active les logs sans afficher d’erreurs aux visiteurs.
 * Pensez à désactiver après dépannage.
 */
define('WP_DEBUG', true);
define('WP_DEBUG_LOG', true);
define('WP_DEBUG_DISPLAY', false);

// Évite que PHP affiche des erreurs malgré WP_DEBUG_DISPLAY à false.
@ini_set('display_errors', '0');

// ...

เหตุผลที่วิธีนี้ช่วยได้: WordPress จะบันทึกข้อผิดพลาดลงใน... wp-content/debug.logนี่คือไฟล์ที่คุณจะต้องอ่านหลังจากจำลองข้อผิดพลาดแล้ว

เอกสารอ้างอิงอย่างเป็นทางการ: ดีบัก WordPress (developer.wordpress.org)

ขั้นตอนที่ 2 — จำลองข้อผิดพลาดและดึงข้อมูลการติดตาม

  1. เปิดแผงควบคุมผู้ดูแลระบบ คลิก Post SMTP → Settings (หรือรายการที่เทียบเท่า)
  2. หากหน้าจอเป็นสีขาว: ให้โหลดหน้าเว็บใหม่หนึ่งครั้ง (บางครั้งข้อมูลจะถูกบันทึกในการกดครั้งที่สอง)
  3. เปิด wp-content/debug.log และคัดลอก:
    • บรรทัด “ข้อผิดพลาดร้ายแรง…”
    • บรรทัดที่ 10–30 ของ stack trace

Si debug.log ไม่เต็ม:

  • ผู้ให้บริการโฮสติ้งของคุณอาจปิดใช้งานสิทธิ์การเขียน ตรวจสอบสิทธิ์การเข้าถึงของไฟล์ wp-content.
  • ดูบันทึกการทำงานของเซิร์ฟเวอร์ (Apache/Nginx) ผ่านแผงควบคุม
  • หากคุณใช้แคชเซิร์ฟเวอร์ที่ทำงานอย่างหนัก ให้ล้างแคชนั้น

ขั้นตอนที่ 3 — ยืนยันความขัดแย้งโดยไม่ทำให้เว็บไซต์สาธารณะเสียหาย (การตรวจสอบสถานะ)

ติดตั้ง/เปิดใช้งาน การตรวจสุขภาพ, แล้ว :

  1. เครื่องมือ → สุขภาพเว็บไซต์ → แท็บ ช่วย
  2. เปิดใช้งานโหมดแก้ไขปัญหา (ผู้เข้าชมเว็บไซต์ของคุณจะไม่ได้รับผลกระทบ)
  3. ทดสอบการโพสต์ SMTP → การตั้งค่า
  4. หากใช้งานได้ในโหมดแก้ไขปัญหา: ให้เปิดใช้งานปลั๊กอินทีละตัวในโหมดนี้จนกว่าจะเกิดข้อผิดพลาดซ้ำ

จากประสบการณ์ของผม ความขัดแย้งที่เกิดขึ้นบ่อยที่สุดคือ:

  • ปลั๊กอินย่อขนาดไฟล์ที่มีผลต่อผู้ดูแลระบบ
  • ปลั๊กอินรักษาความปลอดภัยที่บล็อก admin-ajax.php ou /wp-json/
  • ปลั๊กอินโค้ดสั้นที่โหลดโค้ดที่เสีย admin_init

ขั้นตอนที่ 4 — ตรวจสอบคอนโซลของเบราว์เซอร์ (หากหน้าเว็บโหลดไม่เสร็จสมบูรณ์)

หากคุณเห็นหน้าจอ Post SMTP แต่แท็บว่างเปล่า:

  • เปิด DevTools → Console: มองหาข้อผิดพลาด JavaScript
  • เปิด DevTools → เครือข่าย: ตัวกรอง admin-ajax.php et /wp-json/

หากคุณพบข้อผิดพลาด 403/401 ใน REST มักเกิดจากปลั๊กอินรักษาความปลอดภัยหรือกฎของเซิร์ฟเวอร์ โปรดดูเอกสารประกอบ REST API: คู่มือการใช้งาน REST API

วิธีแก้ปัญหาที่ 2: ซ่อมแซมหน้าการตั้งค่าที่เสียหายเนื่องจากการโหลด admin hook ที่ไม่ถูกต้อง

ปัญหานี้เกิดขึ้นเมื่อข้อผิดพลาดร้ายแรงไม่ได้เกิดจาก "โดยตรง" จากการส่งข้อมูลผ่าน SMTP แต่เกิดจากโค้ดตัวอย่างหรือปลั๊กอินที่ทำงานอยู่บนนั้น toutes หน้าผู้ดูแลระบบ… และซึ่งจะล้มเหลวเฉพาะในหน้า Post SMTP เท่านั้น (เนื่องจากตัวแปรที่คาดหวังไม่มีอยู่ในหน้าจอนี้)

ตัวอย่างทั่วไป: โค้ด "การปรับแต่งโดยผู้ดูแลระบบ" ที่ตั้งสมมติฐานว่า $_GET['page'] มีการกำหนดค่าไว้เสมอ หรือเรียกใช้ฟังก์ชันเร็วเกินไป

การวินิจฉัยอย่างรวดเร็ว

  • ใน debug.logร่องรอยชี้ไปทาง functions.php (ธีม), ปลั๊กอินโค้ดตัวอย่าง หรือปลั๊กอิน "การปรับแต่งสำหรับผู้ดูแลระบบ"
  • ในโหมดตรวจสอบสุขภาพ (การแก้ไขปัญหา) หากคุณเปลี่ยนกลับไปใช้ธีม Twenty Twenty-Five (หรือธีมมาตรฐาน) แล้วใช้งานได้ แสดงว่าธีมหรือส่วนเสริมสำหรับผู้ดูแลระบบมีปัญหา

ตัวอย่างในโลกแห่งความเป็นจริง: ฮุก admin_init ที่ทำงานรุนแรงเกินไป (ก่อน → หลัง)

ภาคเรียน : การกระทำ = ฮุกที่เรียกใช้ฟังก์ชัน ในที่นี้ admin_init ทำงานทุกครั้งที่ผู้ดูแลระบบโหลดระบบ

โค้ดนี้อยู่ที่ไหน? บ่อยครั้งใน functions.php จากธีมหลัก (บางครั้งอาจเป็นธีมย่อย) หรือจากปลั๊กอินโค้ดสั้นๆ ห้ามแก้ไข ธีมหลัก ใช้งานในธีมย่อย หรือที่ดีกว่านั้นคือใช้ปลั๊กอิน mu

โค้ดก่อน (เสีย: สมมติว่า $_GET['page'] (มีอยู่และจัดการตัวเลือกโดยไม่ตรวจสอบ):

<?php
add_action('admin_init', function () {
	// Mauvaise pratique : $_GET peut être absent, et la page peut ne pas correspondre.
	if ($_GET['page'] === 'postman') {
		// Exemple : on modifie une option sans vérifier son type.
		$settings = get_option('postman_options');
		$settings['force_smtp'] = true; // Fatal si $settings est une chaîne (string).
		update_option('postman_options', $settings);
	}
});

อะไรพัง: ถ้า get_option('postman_options') ส่งคืนค่า เชือก (ตัวเลือกที่เสียหาย) หรือ falseเข้าถึง $settings['force_smtp'] ทำให้เกิดข้อผิดพลาดร้ายแรงใน PHP เวอร์ชัน 8.1 ขึ้นไป

โค้ดหลังจาก (แก้ไขแล้ว: เราตรวจสอบบริบทและประเภท และเราจะไม่แก้ไขตัวเลือกการอ่าน/เขียนในแต่ละครั้งที่โหลด):

<?php
/**
 * MU-plugin recommandé : /wp-content/mu-plugins/postman-admin-guard.php
 * Sauvegardez avant de modifier.
 */
add_action('admin_init', function () {
	// Ne jamais supposer que $_GET existe.
	$page = isset($_GET['page']) ? sanitize_key(wp_unslash($_GET['page'])) : '';

	// On limite strictement au slug de page visé.
	if ($page !== 'postman') {
		return;
	}

	// On lit l’option et on valide le type.
	$settings = get_option('postman_options');

	if (!is_array($settings)) {
		// On évite le fatal error. À ce stade, on journalise pour diagnostic.
		error_log('[Post SMTP] Option postman_options inattendue (non-array) sur la page Settings.');
		return;
	}

	// Exemple : si vous devez vraiment ajuster un flag, faites-le sur une action explicite
	// (submit de formulaire) plutôt qu’à chaque admin_init.
});

เหตุผลที่วิธีนี้ช่วยแก้ปัญหาได้: คุณจะป้องกันไม่ให้โค้ดจากภายนอก "ทำให้" หน้าจอ Post SMTP "เสียหาย" โดยการเข้าถึงข้อมูลที่ไม่ได้รับการตรวจสอบ และที่สำคัญที่สุด คุณจะหลีกเลี่ยงการเขียนข้อมูลลงฐานข้อมูลทุกครั้งที่โหลดหน้าผู้ดูแลระบบ ซึ่งเป็นอีกสาเหตุหนึ่งของข้อผิดพลาด

สร้างปลั๊กอิน mu (แนะนำ)

สร้างโฟลเดอร์ wp-content/mu-plugins หากไม่มีอยู่ ก็จะเป็นไฟล์ postman-admin-guard.php ภายในนั้น ปลั๊กอิน mu จะถูกโหลดโดย WordPress โดยอัตโนมัติ

เอกสารทางการ: ปลั๊กอินที่ต้องใช้

วิธีแก้ปัญหาที่ 3: ล้างตัวเลือกที่เสียหาย/ไม่เข้ากันหลังจากการอัปเดต (WP-CLI / ฐานข้อมูล)

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

  • array_merge(): Argument #2 must be of type array, string given
  • Cannot access offset of type string on string
  • foreach() argument must be of type array|object, string given

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

  • การย้ายถิ่นฐานที่ถูกขัดจังหวะ
  • ปลั๊กอินแคชอ็อบเจ็กต์ (Redis/Memcached) ที่ให้บริการค่าที่ล้าสมัย
  • ข้อความสั้นๆ ที่สร้าง update_option() ด้วยโครงสร้างที่ไม่ดี

ขั้นตอนที่ 1 — ระบุตัวเลือกที่ต้องการ

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

  • postman_options
  • post_smtp_settings
  • postman_plugin_options

ถ้าคุณไม่เห็น ให้ลองมองหาดู debug.log เส้นที่มี get_option หรือไฟล์ “การตั้งค่า/ตัวเลือก”

ตัวเลือก A — การรีเซ็ตแบบสะอาดหมดจดผ่าน WP-CLI (ตัวเลือกที่ปลอดภัยที่สุด)

หากคุณใช้ WP-CLI:

1) ระบุตัวเลือกผู้สมัคร:

wp option list --search=postman --fields=option_name,autoload --format=table
wp option list --search=post_smtp --fields=option_name,autoload --format=table

2) ตรวจสอบตัวเลือก (เพื่อตรวจสอบว่าเป็นสตริงหรืออาร์เรย์ที่ถูกแปลงเป็นรูปแบบอนุกรม):

wp option get postman_options

3) บันทึกตัวเลือกก่อนลบ (มีประโยชน์มากหากคุณต้องการกู้คืน):

wp option get postman_options --format=json > /tmp/postman_options_backup.json

4) ลบตัวเลือกที่เสียหาย (Post SMTP จะสร้างตัวเลือกนั้นขึ้นใหม่โดยใช้ค่าเริ่มต้น):

wp option delete postman_options

เอกสารประกอบการใช้งาน WP-CLI (อ้างอิง): คำสั่งตัวเลือก WP-CLI

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

ตัวเลือก B — รีเซ็ตผ่าน phpMyAdmin (หากคุณไม่มี WP-CLI)

บันทึกฐานข้อมูล ก่อนหน้านี้:

  1. เปิดตาราง wp_options (คำนำหน้าอาจแตกต่างกันไป)
  2. ค้นหาตัวเลือก (เช่น postman_options).
  3. คัดลอกค่าดังกล่าวลงในไฟล์ข้อความ (เพื่อสำรองข้อมูล)
  4. ลบบรรทัดนั้น (หรือเปลี่ยน) option_value en a:0:{} (ถ้าคุณรู้ว่ากำลังทำอะไรอยู่)

หมายเหตุ: แทนที่ด้วย a:0:{} (อาร์เรย์ว่างที่ถูกทำให้เป็นอนุกรม) อาจช่วยหลีกเลี่ยงขั้นตอนการติดตั้งบางอย่างได้ แต่ไม่ใช่ทุกกรณี การลบมักจะสะอาดกว่า

ตัวเลือก C — การแก้ไขชั่วคราวเพื่อ "เอาตัวรอด" และเข้าถึงแผงควบคุมผู้ดูแลระบบ

หากคุณติดปัญหาและต้องการเปิดแผงควบคุมผู้ดูแลระบบอีกครั้งเพื่อปิดใช้งานปลั๊กอินหรือส่งออกข้อมูล คุณสามารถเพิ่มการป้องกันชั่วคราวผ่านปลั๊กอิน mu ได้ นี่ไม่ใช่ "วิธีแก้ไข" สำหรับปลั๊กอิน แต่เป็นมาตรการป้องกันไว้ก่อน

จะปักตรงไหนดี : /wp-content/mu-plugins/postman-option-safety.php

<?php
/**
 * Filet de sécurité temporaire : corrige une option Post SMTP si elle est manifestement corrompue.
 * À retirer après dépannage.
 */

add_action('plugins_loaded', function () {
	// Changez ce nom d’option selon ce que vous voyez dans vos logs.
	$option_name = 'postman_options';

	$value = get_option($option_name, null);

	// Si l’option est une string non sérialisée, on la remet à zéro.
	// Attention : cela réinitialise potentiellement la configuration SMTP.
	if (is_string($value) && $value !== '' && !is_serialized($value)) {
		error_log('[Post SMTP] Option corrompue détectée (' . $option_name . '), réinitialisation.');
		delete_option($option_name);
	}
});

เหตุผลที่ได้ผล: SMTP จะไม่พบค่าที่เป็นไปไม่ได้อีกต่อไป และจะสามารถสร้างค่าเริ่มต้นขึ้นมาใหม่ได้ ความเสี่ยง: คุณอาจสูญเสียการตั้งค่า SMTP (ดังนั้นจึงควรสำรองข้อมูลผ่าน WP-CLI/DB ไว้ก่อน)

อ้างอิงเกี่ยวกับ get_option() : รับตัวเลือก()

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

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

  1. เปิด โพสต์ SMTP → การตั้งค่า หน้าเว็บควรแสดงผลได้โดยไม่มีข้อผิดพลาด
  2. เปิด wp-content/debug.log : ไม่มีข้อความ "ข้อผิดพลาดร้ายแรง" อีกต่อไป
  3. ส่งอีเมลทดสอบจาก Post SMTP (หรือจากแบบฟอร์มติดต่อ)
  4. ตรวจสอบว่าการส่งใช้งานได้ผ่านทางนี้ด้วย WP-Cron หากคุณได้ตั้งเวลาส่งอีเมลไว้แล้ว (เช่น จดหมายข่าว, WooCommerce)
  5. จากนั้นให้ปิดโหมดดีบัก (หรือเปิดไว้ก็ได้) WP_DEBUG_LOG (ใช้งานได้เฉพาะในสภาพแวดล้อมทดสอบเท่านั้น)

หากคุณมีแคช (ปลั๊กอิน เซิร์ฟเวอร์ CDN) ให้ล้างแคชเหล่านั้น:

  • ปลั๊กอินแคช (แคชหน้าเว็บ)
  • แคชเซิร์ฟเวอร์ (Varnish / Nginx microcache)
  • OPcache (หากผู้ให้บริการโฮสติ้งของคุณอนุญาต) — มีประโยชน์มากหลังจากติดตั้งปลั๊กอินใหม่

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

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

1) ติดตั้ง Post SMTP ใหม่แบบสะอาดหมดจด (โดยไม่สูญเสียการตั้งค่าหากเป็นไปได้)

การติดตั้งไม่สมบูรณ์ (ขาดผู้จำหน่าย) ทำให้เกิดข้อผิดพลาด "ไม่พบคลาส" ขั้นตอนการแก้ไข:

  1. บันทึกตัวเลือก (หากเป็นไปได้ ให้ส่งออกข้อมูลในรูปแบบ JSON ผ่าน WP-CLI)
  2. ปิดใช้งานการโพสต์ SMTP
  3. ลบโฟลเดอร์นั้น /wp-content/plugins/post-smtp/ (เฉพาะปลั๊กอินนี้เท่านั้น)
  4. ติดตั้งใหม่จาก WordPress.org (โพสต์ SMTP) (ไม่ใช่จากไฟล์ ZIP ที่น่าสงสัย)
  5. เปิดใช้งานหน้าการตั้งค่าอีกครั้งและทดสอบดู

2) ตรวจสอบเวอร์ชัน PHP และส่วนขยาย

  • ในเมนู เครื่องมือ → สุขภาพเว็บไซต์ ให้ตรวจสอบ PHP.Target 8.1 +.
  • ตรวจสอบส่วนขยาย: openssl, mbstring, curlโดยทั่วไปแล้ว การส่งคำขอผ่าน SMTP มักขึ้นอยู่กับสิ่งนี้ทางอ้อม

เอกสารประกอบการใช้งาน PHP (เช่น OpenSSL): PHP OpenSSL

3) ปิดใช้งานปลั๊กอิน “admin” และ “security” ชั่วคราว

ในโหมดตรวจสอบสุขภาพ (โหมดแก้ไขปัญหา) ให้ปิดใช้งานสิ่งต่อไปนี้:

  • ย่อ/รวมไฟล์ JavaScript/CSS (โดยเฉพาะอย่างยิ่งหากส่งผลกระทบต่อส่วนผู้ดูแลระบบ)
  • ปลั๊กอินรักษาความปลอดภัยที่กรอง REST/AJAX
  • ปลั๊กอินโค้ดสั้น (โค้ดสั้นที่ใช้งานไม่ได้เพียงอันเดียวก็เพียงพอแล้ว)

ทดสอบทุกครั้งโดยไปที่ Post SMTP → Settings เมื่อปัญหาเกิดขึ้นอีกครั้ง แสดงว่าคุณพบต้นเหตุแล้ว

4) ตรวจสอบขีดจำกัดของหน่วยความจำ

หากร่องรอยดังกล่าวกล่าวถึงหน่วยความจำ:

  • เพิ่ม memory_limit โดยจะกำหนดการตั้งค่าผ่านฝั่ง PHP (แผงควบคุมโฮสติ้ง) แทนที่จะผ่าน WordPress
  • หลีกเลี่ยงการพึ่งพา define('WP_MEMORY_LIMIT', ...) หากผู้ให้บริการโฮสติ้งของคุณกำหนดขีดจำกัดที่ต่ำกว่า

เอกสารอ้างอิง WordPress (หน่วยความจำ): WP_MEMORY_LIMIT

5) ตรวจสอบกฎการเขียนลิงก์ถาวร/กฎการเขียนใหม่ (พบได้ไม่บ่อย แต่เคยเจอมาก่อน)

หาก Post SMTP โหลดเอนด์พอยต์ภายในแล้วส่งคืนข้อผิดพลาด 404:

  1. การตั้งค่า → ลิงก์ถาวร → บันทึก (โดยไม่เปลี่ยนแปลง)

วิธีนี้จะทำให้ WordPress สร้างกฎการเขียนใหม่ขึ้นมาอีกครั้ง อ้างอิง: flush_rewrite_rules() (ไม่จำเป็นต้องเรียกใช้ในทุกหน้า)

6) หากคุณพบข้อผิดพลาดบน hook ใด hook หนึ่ง

ปัญหาที่พบบ่อย: ความสับสนระหว่าง การปฏิบัติ et FILTRESต้องมีตัวกรอง กลับ มูลค่า หุ้นไม่ได้ให้ผลตอบแทนใดๆ

ตัวอย่างก่อนหน้านี้ (ใช้งานไม่ได้: ใช้ add_filter แต่ไม่ส่งค่าอะไรกลับมา):

<?php
add_filter('admin_menu', function () {
	// Mauvais : admin_menu est une action, pas un filtre.
	// Et on ne retourne rien : comportement imprévisible.
});

ตัวอย่างหลังแก้ไข:

<?php
add_action('admin_menu', function () {
	// Correct : admin_menu est une action.
});

ฮุกเอกสาร: API ปลั๊กอิน: Hooks

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

อาการ/ข้อผิดพลาด สาเหตุที่เป็นไปได้ วิธีแก้ปัญหาที่แนะนำ
คุณกำลังวางโค้ดลงในไฟล์ที่ไม่ถูกต้อง โค้ดที่วางไว้ในธีมหลักหรือในปลั๊กอินที่อัปเดตตัวเอง ใช้ a mu- ปลั๊กอิน หรือปลั๊กอินที่กำหนดเอง ไม่ใช่ส่วนหลัก ไม่ใช่ธีมแม่
เกิดข้อผิดพลาดร้ายแรงหลังจากเพิ่มโค้ด: “โทเค็นที่ไม่คาดคิด” ลืมใส่เครื่องหมายเซมิโคลอน, ใส่เครื่องหมายวงเล็บปีกกาเกิน, ปิดแท็ก PHP ไม่ถูกต้อง ย้อนกลับการเปลี่ยนแปลงผ่าน FTP แก้ไขไวยากรณ์ และตรวจสอบความถูกต้องด้วยโปรแกรมแก้ไขข้อความ
บันทึกยังคงว่างเปล่า สิทธิ์การเข้าถึง WP_DEBUG ผิดที่ ผู้ให้บริการโฮสติ้งบล็อกการเข้าถึงการเขียน ตรวจสอบตำแหน่งที่ตั้งใน wp-config.php + บันทึกเซิร์ฟเวอร์
มันใช้งานได้ในโหมดแก้ไขปัญหาการตรวจสอบสุขภาพ แต่ไม่ใช่ใน "สภาวะปกติ" ความขัดแย้งของปลั๊กอินหรือธีม เปิดใช้งานทีละรายการในโหมดแก้ไขปัญหา จนกว่าคุณจะพบต้นเหตุของปัญหา
หน้าการตั้งค่าโหลดขึ้นมา แต่แท็บต่างๆ ยังว่างเปล่า REST/AJAX ถูกบล็อก การย่อขนาดโดยผู้ดูแลระบบ คอนโซล + เครือข่าย ปิดใช้งานการย่อขนาดไฟล์สำหรับผู้ดูแลระบบ อนุญาต /wp-json/
ข้อผิดพลาด “หน่วยความจำที่อนุญาตเต็มแล้ว” ขีดจำกัดหน่วยความจำ PHP ต่ำเกินไป เพิ่ม memory_limit ฝั่งเซิร์ฟเวอร์ จากนั้นทดสอบอีกครั้ง
คุณกำลังทดสอบในสภาพแวดล้อมการใช้งานจริงโดยไม่มีข้อมูลสำรอง ปริมาณน้ำฝน ควรทำการโคลนสภาพแวดล้อมชั่วคราว หรืออย่างน้อยก็สำรองข้อมูลฐานข้อมูลก่อนที่จะลบตัวเลือกต่างๆ
คุณกำลังใช้บทช่วยสอนเก่า (PHP 7) กับ WordPress เวอร์ชัน 6.9.4 โค้ดนี้ไม่สามารถใช้งานร่วมกับ PHP 8.1 ขึ้นไปได้ (เกิดข้อผิดพลาด TypeError และฟังก์ชันที่ล้าสมัย) ปรับให้เข้ากับการตรวจสอบประเภทข้อมูล sanitize_*และตะขอที่ถูกต้อง

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

วิธีการแบบไม่ต้องเขียนโค้ด: แทนที่ Post SMTP ชั่วคราว

หากคุณจำเป็นต้องกู้คืนการส่งอีเมลในระหว่างที่คุณกำลังตรวจสอบปัญหา:

  • ติดตั้งปลั๊กอิน SMTP ที่น่าเชื่อถืออีกตัวหนึ่ง ตั้งค่า และทดสอบการส่งอีเมล
  • ปิดใช้งานการส่งข้อความ SMTP ชั่วคราวตลอดระยะเวลาที่กำหนด ถูกต้อง.

คำเตือน: ปลั๊กอิน SMTP สองตัวที่เปิดใช้งานพร้อมกันอาจแย่งใช้ hook กันได้ wp_mail และทำให้เกิดพฤติกรรมที่ไม่สอดคล้องกัน (การส่งข้อมูลซ้ำซ้อน ส่วนหัวข้อมูลเสียหาย)

วิธีการขั้นสูงกว่า: ติดตามการทำงานของ wp_mail และ hooks โดยไม่ต้องแก้ไขปลั๊กอิน

สำหรับนักพัฒนา (หรือหากคุณทำงานร่วมกับผู้ให้บริการ) คุณสามารถใช้งานการส่งอีเมลในฝั่ง WordPress ผ่านปลั๊กอิน mu ได้ เป้าหมายคือการตรวจสอบว่าการส่งข้อมูลผ่าน SMTP ได้รับการแก้ไขอย่างถูกต้องหรือไม่ wp_mail และหากข้อผิดพลาดนั้นเกิดจากหน้าจอผู้ดูแลระบบหรือระบบส่งอีเมล

จะปักตรงไหนดี : /wp-content/mu-plugins/mail-trace.php

<?php
/**
 * Trace légère de wp_mail (ne loggez jamais des contenus sensibles en production).
 * À utiliser temporairement.
 */

add_filter('wp_mail', function ($args) {
	// $args contient to/subject/message/headers/attachments.
	// Risque sécurité : ne loggez pas le message complet si vous envoyez des données privées.
	$to = is_array($args['to']) ? implode(',', $args['to']) : (string) $args['to'];

	error_log('[MailTrace] wp_mail appelé vers: ' . $to . ' | sujet: ' . (string) $args['subject']);

	return $args; // Filtre = on doit retourner la valeur
}, 10, 1);

เอกสารอ้างอิงอย่างเป็นทางการ: ตัวกรอง wp_mail

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

  • ทำการอัปเดตบนสำเนาทดสอบก่อน เมื่อคุณมีเวลาว่าง หน้าการตั้งค่ามักเป็นจุดแรกที่พบข้อผิดพลาดในการย้ายข้อมูล
  • หมั่นอัปเดต PHP ให้เป็นเวอร์ชันล่าสุดอยู่เสมอ (แนะนำเวอร์ชันขั้นต่ำ 8.1 ขึ้นไป) ข้อผิดพลาด "แปลกๆ" หลายอย่างเกิดจากเวอร์ชัน PHP ที่ล้าสมัย หรือการขาดส่วนขยายบางส่วน
  • หลีกเลี่ยงการใช้โค้ดสั้นแบบ "ทั่วโลก" ใน admin_init โดยไม่มีมาตรการป้องกัน ตรวจสอบความถูกต้องเสมอ:
    • บริบท (หน้า/หน้าจอ)
    • สิทธิ์ (current_user_can())
    • ประเภทของตัวเลือก (is_array(), is_string())
  • อย่าใช้การย่อขนาดกับส่วนผู้ดูแลระบบ เว้นแต่คุณจะรู้แน่ชัดว่ากำลังทำอะไรอยู่ ผมเคยเห็นหน้าการตั้งค่าพังเพราะการใช้ JavaScript ที่ต่อกันเป็นแถวอยู่บ่อยครั้ง
  • ตรวจสอบบันทึกข้อมูล : รักษาการหมุนและการเข้าถึงให้ง่าย ข้อผิดพลาดร้ายแรงมักจะมีคำเตือนที่เป็นประโยชน์นำมาก่อนเสมอ

โค้ดตัวอย่าง "Safeguard" สำหรับหน้าผู้ดูแลระบบ (เทมเพลตที่นำกลับมาใช้ใหม่ได้)

โมเดลนี้ช่วยให้คุณไม่ต้องเขียนโค้ดในทุกหน้าผู้ดูแลระบบ ซึ่งช่วยลดความเสี่ยงของการเกิดข้อขัดแย้งได้อย่างมาก

จะปักตรงไหนดี : ปลั๊กอิน mu หรือปลั๊กอินแบบกำหนดเอง

<?php
/**
 * Modèle : exécuter du code uniquement sur un écran admin précis.
 */

add_action('current_screen', function ($screen) {
	if (!($screen instanceof WP_Screen)) {
		return;
	}

	// Exemple : adaptez selon l’ID réel de l’écran (à lire via Query Monitor).
	if ($screen->id !== 'toplevel_page_postman') {
		return;
	}

	// Ici, votre code spécifique à la page Post SMTP.
	// Toujours valider les types et permissions.
	if (!current_user_can('manage_options')) {
		return;
	}
});

ข้อมูลอ้างอิง: ฮุคหน้าจอปัจจุบัน

ทรัพยากร

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

ฉันควรปิดใช้งาน Post SMTP ทันทีหรือไม่?

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

ฉันได้รับข้อความว่า “เกิดข้อผิดพลาดร้ายแรงขึ้น…” แต่ไม่มีรายละเอียดใดๆ

ทำให้สามารถ WP_DEBUG_LOG (วิธีแก้ปัญหาที่ 1) และตรวจสอบบันทึกเซิร์ฟเวอร์ด้วย ในบางแพ็กเกจโฮสติ้ง WordPress อาจไม่ได้รับอนุญาตให้เขียนข้อมูลลงในไฟล์ดังกล่าว wp-content ตราบใดที่สิทธิ์การเข้าถึงยังไม่ถูกต้อง

การลบตัวเลือกจะทำให้ระบบอีเมลของฉันใช้งานไม่ได้หรือไม่?

ใช่ อาจเป็นไปได้: คุณต้องรีเซ็ตการตั้งค่า บันทึกตัวเลือกไว้ก่อน (เช่น ส่งออก JSON ผ่าน WP-CLI หรือคัดลอกฐานข้อมูล) จากนั้นตั้งค่า SMTP ใหม่ในอินเทอร์เฟซเมื่อแก้ไขข้อผิดพลาดแล้ว

Divi 5 / Elementor / Avada สามารถทำให้เกิดข้อผิดพลาดร้ายแรงนี้ได้หรือไม่?

ไม่โดยตรง แต่ระบบนิเวศของพวกมันมักประกอบด้วยปลั๊กอินเพิ่มประสิทธิภาพ ปลั๊กอินรักษาความปลอดภัย หรือส่วนเสริมสำหรับผู้ดูแลระบบ การทดสอบตรวจสอบสุขภาพด้วยธีมมาตรฐานช่วยให้สามารถตรวจสอบได้อย่างรวดเร็ว

ฉันใช้ PHP 8.0 อยู่ และฉันกลัวที่จะอัปเกรดเป็นเวอร์ชัน 8.1 ขึ้นไป

ใน WordPress เวอร์ชัน 6.9.4 ปี 2026 แนะนำให้ใช้ PHP เวอร์ชัน 8.1 ขึ้นไปเป็นเวอร์ชันพื้นฐาน ปลั๊กอินหลายตัวแก้ไขข้อบกพร่องเฉพาะในเวอร์ชันเหล่านี้เท่านั้น ลองเปลี่ยนไปใช้สภาพแวดล้อมทดสอบ (staging) และตรวจสอบปลั๊กอินที่สำคัญของคุณ

ทำไมข้อผิดพลาดจึงปรากฏเฉพาะในหน้าการตั้งค่าเท่านั้น?

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

ฉันได้รับข้อผิดพลาด "Class not found" ในไฟล์ vendor/autoload.php

ปัญหานี้มักเกิดจากการอัปเดตที่ไม่สมบูรณ์ (ไฟล์ ZIP ถูกตัดทอน ปัญหาเรื่องสิทธิ์การเข้าถึง โปรแกรมป้องกันไวรัสบนเซิร์ฟเวอร์) วิธีแก้ไขที่เร็วที่สุดคือการติดตั้งปลั๊กอินใหม่ทั้งหมดจาก wordpress.org จากนั้นล้างแคช/OPcache หากเป็นไปได้

ฉันจำเป็นต้องแก้ไขไฟล์ปลั๊กอินเพื่อแก้ไขปัญหานี้หรือไม่?

หลีกเลี่ยงวิธีนี้ การเปลี่ยนแปลงใดๆ จะถูกเขียนทับในการอัปเดตครั้งถัดไป แทนที่จะทำเช่นนั้น ให้ลองติดตั้งใหม่ ล้างตัวเลือก หรือใช้ปลั๊กอิน mu-plugin ชั่วคราวเพื่อป้องกันไม่ให้เกิดปัญหาในระหว่างที่คุณหาสาเหตุ

ฉันไม่สามารถเข้าถึงแผงควบคุมผู้ดูแลระบบได้เลย ฉันควรทำอย่างไรดี?

เปลี่ยนชื่อโฟลเดอร์ปลั๊กอินชั่วคราวผ่าน FTP (post-smtp → post-smtp.off) เพื่อบังคับปิดใช้งาน จากนั้น เปิดใช้งาน WP_DEBUG_LOG อีกครั้ง และดำเนินการวินิจฉัยต่อ

จำนวนเงินขั้นต่ำที่ต้องส่งให้ฝ่ายสนับสนุน Post SMTP คือเท่าไหร่?

ข้อมูลการติดตามทั้งหมด (โดยไม่รวมข้อมูลที่ละเอียดอ่อน), เวอร์ชันของคุณ (WordPress 6.9.4, PHP, Post SMTP), รายชื่อปลั๊กอินที่ใช้งานอยู่ และผลลัพธ์ของการทดสอบตรวจสอบสุขภาพ (ระบบล่มหรือไม่เมื่อปิดใช้งานปลั๊กอินอื่นๆ ทั้งหมด)

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

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

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

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