หากคุณได้คลิกไปแล้ว บทความ ใน wp-admin ทุกอย่างค้างและแสดงข้อผิดพลาดแปลกๆ เช่น “v3.1.1 ไม่สามารถเปิด wp-admin 'บทความ' ได้…” คุณอาจมีข้อขัดแย้งระหว่างปลั๊กอิน (เวอร์ชัน 3.1.1) โค้ดตัวอย่าง และหน้ารายการบทความ (edit.php).
มีปัญหา
ข้อความที่แสดงจะแตกต่างกันไปตามปลั๊กอิน เซิร์ฟเวอร์ และภาษา แต่โดยทั่วไปแล้ว ร่องรอยการทำงานมักจะเริ่มต้นแบบนี้ (ใน หน้าจอสีขาว(ไฟล์บันทึก 500 หน้า หรือไฟล์บันทึก PHP):
v3.1.1 fails to open wp-admin "articles" with a fatal error:
Uncaught TypeError: ... in /wp-content/plugins/mon-plugin/...
or
PHP Fatal error: Uncaught Error: Call to undefined function ...
or
There has been a critical error on this website.
ปรากฏที่ใด:
- เฉพาะผู้ดูแลระบบ โดยการเปิด บทความ> บทความทั้งหมด (URL ทั่วไป:
/wp-admin/edit.php) บางครั้งก็เช่นกัน เพิ่มเกี่ยวกับ (URL:/wp-admin/post-new.php). - บางครั้งใน AJAX : ที่écran เมื่อโหลดเสร็จแล้ว การกระทำใดๆ (เช่น การกรอง การค้นหา การแก้ไขด่วน) จะทำให้เกิดข้อผิดพลาด
- พบได้น้อยครั้งกว่าใน REST API หากปลั๊กอินแก้ไขคำขอ POST ผ่าน REST นั้น Gutenberg ก็อาจได้รับผลกระทบเช่นกัน
สถานการณ์ทั่วไปที่ฉันเคยพบเจอในการแก้ไขปัญหา:
- หลังจากอัปเดตปลั๊กอินเสร็จทันที v3.1.1 (หมายเลข “3.1.1” มักจะเป็นหมายเลขของปลั๊กอิน ไม่ใช่หมายเลขของโปรแกรม) WordPress).
- หลังจากเพิ่มโค้ดตัวอย่าง "เพื่อเปลี่ยนชื่อโพสต์เป็นบทความ" ที่พบในบทช่วยสอนเก่า
- หลังจากเปิดใช้งานปลั๊กอิน SEO/การเปลี่ยนเส้นทาง/ความปลอดภัยที่มีผลต่อฟังก์ชันการทำงานหรือเมนูผู้ดูแลระบบ
- ในเว็บไซต์ที่ใช้ Divi 5, Elementor หรือ Avada: เครื่องมือสร้างเว็บไซต์เหล่านี้จะไม่ทำให้เกิดปัญหาโดยตรง
edit.phpแต่บ่อยครั้งที่มันอยู่ร่วมกับ "โค้ดตัวอย่าง" และปลั๊กอินที่ทำให้ระบบทำงานผิดปกติ
คู่มือนี้เหมาะสำหรับใคร? หากคุณเป็นมือใหม่ คุณจะสามารถระบุได้ว่าคู่มือนี้เหมาะกับคุณหรือไม่ อิฐก้อนไหนทำให้หน้าจอแตก? บทความกู้คืนการเข้าถึงแผงควบคุมผู้ดูแลระบบ และแก้ไขปัญหา WordPress อย่างสะอาดหมดจด 6.9.4 (เมษายน 2026) และ PHP 8.1 +.
สรุปด่วน
- เมนู บทความ คะแนนไปยัง
/wp-admin/edit.phpหากหน้านี้เกิดข้อผิดพลาดหรือปิดตัวลง สาเหตุส่วนใหญ่มักเกิดจาก... ผู้ดูแลระบบ hook (การกระทำ/ตัวกรอง) ของปลั๊กอินหรือโค้ดสั้นๆ - เริ่มต้นด้วยการเปิดใช้งาน WP_DEBUG_LOG และ / หรือ การตรวจสุขภาพ เพื่อแยกปลั๊กอินที่มีปัญหาโดยไม่ทำให้เว็บไซต์สาธารณะเสียหาย
- กรณีทั่วไป: การระบุรหัส CPT ผิดพลาดว่าเป็น “บทความ” (
register_post_type()) กับบางอย่าง ความสามารถที่ไม่สอดคล้องกัน หรือ บุ้ง ซึ่งนำไปสู่ความขัดแย้ง - หลังการแก้ไข: บันทึกลิงก์ถาวรอีกครั้ง และล้างแคช (ปลั๊กอิน/เซิร์ฟเวอร์/เบราว์เซอร์)
- หากคุณไม่สามารถเข้าถึง wp-admin ได้อีกต่อไป: ให้ปิดใช้งานปลั๊กอินผ่าน FTP (เปลี่ยนชื่อโฟลเดอร์) หรือ WP-CLI
มีอาการ
ต่อไปนี้คือสิ่งที่คุณสามารถสังเกตได้ เรียงจากสิ่งที่พบบ่อยที่สุดไปจนถึงสิ่งที่อาจทำให้เข้าใจผิดมากที่สุด:
- จอภาพ Blanc คลิกที่ บทความบางครั้งอาจมีข้อความ "ข้อผิดพลาดร้ายแรง" ปรากฏอยู่ด้วย
- ข้อผิดพลาด 500 เฉพาะบน
/wp-admin/edit.php(หน้าผู้ดูแลระบบอื่นๆ ใช้งานได้ปกติ) - “ขออภัย คุณไม่ได้รับอนุญาตให้เข้าถึงหน้านี้” ในขณะที่คุณดำรงตำแหน่งเป็นผู้ดูแลระบบ
- รายการบทความว่างเปล่า (ไม่พบผลลัพธ์) แต่มีบทความอยู่จริง
- ตัวกรอง/การค้นหาเสีย (หน้าเว็บโหลดเสร็จแล้วเกิดข้อผิดพลาดขณะเรียงลำดับตามผู้เขียน/หมวดหมู่)
- แก้ไขด่วน (แก้ไขด่วน) ซึ่งเปิดไม่ได้อีกต่อไป หรือทำงานไม่สิ้นสุด (มักเป็นปัญหาของ AJAX)
- คอนโซลเบราว์เซอร์ (F12): ข้อผิดพลาด JS บน
edit.php(มักเชื่อมโยงกับสคริปต์ที่ถูกแทรกโดยปลั๊กอิน)
สัญญาณบ่งชี้ความขัดแย้งระหว่างปลั๊กอินและธีม:
- ปัญหาจะหายไปหากคุณปิดใช้งานปลั๊กอินที่ "เพิ่งอัปเดต"
- ปัญหาดังกล่าวปรากฏเฉพาะในบางบทบาทเท่านั้น (เช่น บรรณาธิการ ผู้เขียน): เกิดความสงสัยเกี่ยวกับ... ความสามารถในการ.
- ปัญหาจะเกิดขึ้นหลังจากวาง "ส่วนย่อย" ลงไป
functions.php(ธีมย่อย) หรือปลั๊กอินโค้ดตัวอย่าง
การวินิจฉัยอย่างรวดเร็ว: ถ้า /wp-admin/edit.php?post_type=page (เพจ) ใช้งานได้ แต่ /wp-admin/edit.php (โพสต์) เกิดปัญหา เรามักจะต้องจัดการกับโค้ดที่กำหนดเป้าหมายเฉพาะเจาะจง post หรือเมนู “บทความ”
ทำไมจึงเกิดเหตุการณ์เช่นนี้?
เวอร์ชันสำหรับผู้เริ่มต้น: หน้าจอ บทความ นี่คือหน้าผู้ดูแลระบบมาตรฐาน ปลั๊กอินหลายตัว "เพิ่มประสิทธิภาพ" ให้กับหน้านี้ (เช่น คอลัมน์ ตัวกรอง การเรียงลำดับ ข้อจำกัดบทบาท สถิติ) หากปลั๊กอิน (หรือโค้ดส่วนใดส่วนหนึ่ง) ทำให้เกิดข้อผิดพลาด PHP/JS หน้านี้จะเป็นหน้าที่จะหยุดทำงาน
นี่คือสิ่งที่เกิดขึ้นเบื้องหลัง: WordPress กำลังโหลด wp-admin/edit.phpสร้างแบบสอบถามรายการ (WP_Queryจากนั้นจึงดำเนินการตามลำดับ ตะขอตะขอคือจุดต่อขยาย การกระทำ ดำเนินการโค้ดในเวลาที่กำหนด ฟิลเตอร์ แก้ไขค่า (เช่น แบบสอบถาม คอลัมน์ HTML) หากตัวกรองส่งคืนประเภทที่ไม่ถูกต้อง (เช่น null (แทนที่จะเป็นอาร์เรย์) PHP 8.1 ขึ้นไปมีความยืดหยุ่นน้อยกว่าและอาจทำให้เกิดข้อผิดพลาดได้ ประเภทข้อผิดพลาด.
สาเหตุที่เป็นไปได้ (จากที่พบได้บ่อยที่สุดไปจนถึงที่พบได้น้อยที่สุด):
- ปลั๊กอินเวอร์ชัน 3.1.1 มีข้อบกพร่อง ซึ่งจะเพิ่มคอลัมน์/ตัวกรองลงในรายการโพสต์และทำให้เกิดข้อผิดพลาดร้ายแรง
- ข้อความเก่า (ก่อน PHP 8 / ก่อน WordPress รุ่นใหม่) ซึ่งใช้ hook ที่ไม่เหมาะสม หรือฟังก์ชันที่ไม่ได้โหลด
- CPT “บทความ” ลงทะเบียนด้วย slug/capabilities ที่ขัดแย้งกับ “post” (Native Articles) และทำให้สิทธิ์การเข้าถึงเสียหาย
- ความขัดแย้ง REST/การเขียนใหม่ หลังการย้ายระบบ: ลิงก์ถาวรไม่ได้รับการสร้างใหม่ กฎการเขียนใหม่ล้าสมัยแล้ว
- แคชแบบก้าวร้าว (แคชของผู้ดูแลระบบเกิดขึ้นได้ยากมาก แต่ก็เป็นไปได้ผ่านการตั้งค่าพร็อกซีแบบย้อนกลับที่ไม่ถูกต้อง) หรือการย่อขนาด JavaScript ที่ทำให้ส่วนติดต่อผู้ดูแลระบบใช้งานไม่ได้
- ปัญหาเซิร์ฟเวอร์ : หน่วยความจำ PHP เหลือน้อยเกินไป, OPcache เสียหาย, สิทธิ์การเข้าถึงไฟล์ หรือ PHP เวอร์ชันต่ำกว่า 8.1
หมายเหตุ “v3.1.1”: WordPress 6.9.4 ไม่มี “v3.1.1” หากคุณเห็น “v3.1.1” ส่วนใหญ่แล้วจะเป็นเวอร์ชันของปลั๊กอิน (หรือธีม) กระบวนการวินิจฉัยเกี่ยวข้องกับการระบุว่าเป็นเวอร์ชันใด
ข้อกำหนดเบื้องต้นก่อนเริ่ม
- ป้องกัน : ฐานข้อมูล + ไฟล์ ห้ามทดสอบ "แบบสุ่ม" ในระบบใช้งานจริง
- สภาพแวดล้อมการทดสอบ ถ้าเป็นไปได้ (ในขั้นตอนการเตรียมการ) ผมเคยเห็นหลายครั้งที่การขาดเครื่องหมายเซมิโคลอนเพียงตัวเดียวทำให้หน้าจอผู้ดูแลระบบถูกบล็อกทั้งหมด
- รุ่น WordPress เวอร์ชัน 6.9.4 และ PHP เวอร์ชัน 8.1 ขึ้นไป (หรือ 8.2/8.3 หากผู้ให้บริการโฮสติ้งของคุณอนุญาต) โปรดตรวจสอบอีกครั้ง เครื่องมือ > สุขภาพเว็บไซต์.
- Outils :
- Query Monitor (ดูข้อผิดพลาด, การสืบค้นข้อมูล, ฮุก)
- ตรวจสอบสุขภาพและแก้ไขปัญหา (โหมดแก้ไขปัญหาโดยไม่ส่งผลกระทบต่อผู้เข้าชม)
- การเข้าถึงบันทึกเซิร์ฟเวอร์ (หรืออย่างน้อยที่สุด)
wp-content/debug.log).
เปิดใช้งานบันทึก WordPress (ใน wp-config.php(เหนือข้อความ “หยุดการแก้ไข”)
define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false ); // Affichez false en prod pour éviter de divulguer des infos
เอกสารอ้างอิงอย่างเป็นทางการ: แก้ไขข้อบกพร่องใน WordPress.
ความเสี่ยงด้านความปลอดภัย ห้ามแสดงข้อผิดพลาด PHP บนหน้าจอในสภาพแวดล้อมการใช้งานจริงเด็ดขาด เพราะข้อมูลการติดตามการทำงานของโปรแกรม (stack trace) อาจเปิดเผยเส้นทาง เวอร์ชัน และบางครั้งอาจรวมถึงข้อมูลลับต่างๆ ด้วย
วิธีแก้ปัญหาที่ 1: แก้ไข "บทความ" (slug/capabilities) ของ CPT ที่ทำให้หน้าจอผู้ดูแลระบบมีปัญหา
เหตุการณ์นี้เกิดขึ้นเมื่อมีคนต้องการ "สร้างประเภทเนื้อหาบทความ" ในขณะที่ WordPress เรียกโพสต์แบบดั้งเดิมว่า "บทความ" อยู่แล้ว (postผลลัพธ์: ป้ายกำกับที่สับสน เมนูที่ซ้ำซ้อน และบางครั้งอาจแสดงหน้าจอ "คุณไม่ได้รับอนุญาต..." หรือหน้าเว็บล่มหากปลั๊กอินคาดหวังว่า... post แต่ได้รับอีกอันหนึ่ง post_type.
แนวคิด :
- CPT = ประเภทโพสต์แบบกำหนดเอง (ประเภทเนื้อหาแบบกำหนดเอง) ที่ประกาศผ่านทาง
register_post_type(). - บุ้ง = ตัวระบุ URL (เช่น
article) ใช้ในลิงก์ถาวร และบางครั้งในส่วนผู้ดูแลระบบ - ความสามารถในการ = สิทธิ์การเข้าถึง (เช่น
edit_posts,edit_pagesหากการแมปไม่ถูกต้อง ผู้ดูแลระบบจะปฏิเสธการเข้าถึง
ควรสงสัยสาเหตุนี้เมื่อใด
- คุณมีเมนู "บทความ" ซึ่งไม่ได้แสดงรายการโพสต์ตามปกติ
- คุณจะเห็น URL ในรูปแบบนี้
/wp-admin/edit.php?post_type=articles. - ปัญหาเริ่มขึ้นหลังจากเพิ่มโค้ด “register_post_type('articles', …)”
ควรแก้ไขตรงไหน
ตำแหน่งที่เหมาะสม: ปลั๊กอินแบบกำหนดเองขนาดเล็ก (แนะนำ) หรือ mu- ปลั๊กอิน (ต้องใช้ปลั๊กอิน) หากคุณต้องการให้แน่ใจว่ามันจะโหลดได้แม้ว่าธีมจะเปลี่ยนไป
- อย่าคัดลอกข้อความนี้ไปวางในปลั๊กอินสร้างข้อความย่อ หากคุณอยู่ในโหมดแก้ไขปัญหา: หากปลั๊กอิน snippets เสียหาย คุณจะไม่สามารถเข้าถึงได้
- ถ้าคุณต้องการทำอย่างรวดเร็ว: ธีมสำหรับเด็ก
functions.phpแต่มันเปราะบางกว่า
โค้ดก่อนหน้า (เสีย)
ตัวอย่างที่สมจริงซึ่งผมพบเจอบ่อยๆ (การใช้ lug "articles", ความสามารถที่ไม่สอดคล้องกัน และการชนกันของป้ายกำกับ):
<?php
// functions.php (thème enfant) - EXEMPLE CASSÉ
add_action( 'init', function() {
register_post_type( 'articles', [
'label' => 'Articles',
'public' => true,
'show_in_menu' => true,
'show_in_rest' => true,
'rewrite' => [ 'slug' => 'articles' ],
// Problème : capabilities bricolées, et parfois l’auteur n’a plus accès à edit.php
'capability_type' => 'page',
'map_meta_cap' => false,
] );
} );
สาเหตุที่มันพัง: ด้วย capability_type => 'page' et map_meta_cap => falseคุณสร้างประเภทที่ทำงานคล้ายกับหน้าเว็บสำหรับการกำหนดสิทธิ์ แต่ไม่มีการแมปที่ถูกต้อง ขึ้นอยู่กับบทบาทและปลั๊กอินรักษาความปลอดภัย การเข้าถึงรายการอาจถูกปฏิเสธหรือทำให้เกิดข้อผิดพลาดเมื่อ WordPress คำนวณขีดจำกัด
รหัสหลัง (แก้ไขแล้ว)
วัตถุประสงค์: เพื่อหลีกเลี่ยงความขัดแย้งกับ "บทความ" (โพสต์ดั้งเดิม) และเพื่อให้มีสิทธิ์การเข้าถึงที่สอดคล้องกัน ฉันแนะนำ:
- ชื่อและตัวระบุที่ไม่คลุมเครือ (เช่น
mag_articleouressource). - ป้ายกำกับที่ระบุอย่างชัดเจน (เช่น “แหล่งข้อมูล”)
- ความสามารถต่างๆ ถูกแมปอย่างถูกต้องผ่านทาง
map_meta_cap => true.
<?php
/**
* Plugin: Mon CPT Ressources (corrigé)
* Emplacement : /wp-content/mu-plugins/cpt-ressources.php
* (Créez le dossier mu-plugins s'il n'existe pas)
*/
add_action( 'init', function() {
$labels = [
'name' => 'Ressources',
'singular_name' => 'Ressource',
'add_new' => 'Ajouter',
'add_new_item' => 'Ajouter une ressource',
'edit_item' => 'Modifier la ressource',
'new_item' => 'Nouvelle ressource',
'view_item' => 'Voir la ressource',
'search_items' => 'Rechercher des ressources',
'not_found' => 'Aucune ressource trouvée',
'not_found_in_trash' => 'Aucune ressource dans la corbeille',
'all_items' => 'Toutes les ressources',
'menu_name' => 'Ressources',
];
register_post_type( 'ressource', [
'labels' => $labels,
'public' => true,
'show_in_menu' => true,
'show_in_rest' => true, // Compatible Gutenberg + REST
'menu_position' => 21,
'menu_icon' => 'dashicons-media-document',
'supports' => [ 'title', 'editor', 'thumbnail', 'excerpt', 'author' ],
'has_archive' => true,
'rewrite' => [ 'slug' => 'ressources', 'with_front' => false ],
'capability_type' => 'post',
'map_meta_cap' => true, // Important : mapping correct des permissions
] );
}, 10 );
ทำไมจึงถูกต้อง
- คุณจะหลีกเลี่ยงความขัดแย้งทั้งทางด้านความคิดและเทคนิคกับ "บทความ" (บทความต้นฉบับ)
- WordPress รู้วิธีคำนวณสิทธิ์การเข้าถึง "เหมือนกับโพสต์" (ซึ่งเป็นมาตรฐาน) ซึ่งช่วยลดความขัดแย้งกับปลั๊กอินเกี่ยวกับบทบาท/ความปลอดภัยได้อย่างมาก
- CPT เข้ากันได้กับ REST/Gutenberg (
show_in_restซึ่งจะช่วยหลีกเลี่ยงพฤติกรรมแปลกๆ ในโปรแกรมแก้ไขข้อความ
ขั้นตอนสำคัญหลังจากแก้ไขเสร็จแล้ว
ไป การตั้งค่า> ลิงก์ถาวร แล้วคลิก Enregistrer (โดยไม่ต้องเปลี่ยนแปลงอะไรเลย) ซึ่งจะทำให้ WordPress สร้างกฎการเขียนใหม่ขึ้นมาอีกครั้ง
เอกสารทางการ: register_post_type().
วิธีแก้ปัญหาที่ 2: ซ่อมแซมการเขียนใหม่, REST และ permalink หลังจากการอัปเดต
สถานการณ์นี้มักเกิดขึ้นหลังจาก:
- การย้ายเว็บไซต์ (การเปลี่ยน URL)
- การเปิด/ปิดใช้งานปลั๊กอินที่สร้าง CPTs/หมวดหมู่
- อัปเดตปลั๊กอินเวอร์ชัน “v3.1.1” ที่แก้ไขสลัก (slug) ของปลั๊กอินนั้น
- กู้คืนข้อมูลสำรองบางส่วน
นี่ไม่ได้ทำให้เกิดข้อผิดพลาดร้ายแรงของ PHP เสมอไป บางครั้งหน้าจอ "บทความ" อาจเปิดขึ้น แต่ตัวกรองหรือการกระทำบางอย่างส่งคำขอที่ไม่สำเร็จ (REST/AJAX) ทำให้ส่วนติดต่อผู้ใช้ดูเหมือน "เสีย"
ตรวจสอบวินิจฉัยอย่างรวดเร็ว (ไม่ต้องระบุรหัส)
- ทดสอบ
/wp-admin/edit.phpแล้วก็/wp-admin/edit.php?post_status=trash. - เปิดคอนโซลของเบราว์เซอร์ (F12) แล้วดูที่แท็บเครือข่าย: การเรียกใช้ไปยัง
/wp-json/ใน 404/401/500? - ไป เครื่องมือ > สุขภาพเว็บไซต์ และตรวจสอบคำแนะนำ (REST API, ลูป ฯลฯ)
แก้ไขข้อที่ 1: ล้างข้อมูลลิงก์ถาวร (ส่วนติดต่อผู้ใช้) อย่างหมดจด
ตัวเลือกที่ปลอดภัยที่สุด: การตั้งค่า> ลิงก์ถาวร > Enregistrer.
การแก้ไขครั้งที่ 2: ล้างแคชผ่าน WP-CLI (หากหน้าจอแสดงผลผู้ดูแลระบบไม่เสถียร)
หากคุณมี WP-CLI (ซึ่งมักพบใน VPS/โฮสติ้งแบบจัดการ) ให้รันคำสั่งต่อไปนี้:
wp rewrite flush --hard
เอกสารอ้างอิง WP-CLI: wp เขียนใหม่ ล้าง.
โค้ดก่อนหน้า (เสีย): กดชักโครกผิดที่
ฉันเคยเห็นโค้ดส่วนนี้ทำให้เกิดความล่าช้า การหมดเวลา และแม้กระทั่งพฤติกรรมผิดปกติในโหมดผู้ดูแลระบบ:
<?php
// EXEMPLE CASSÉ : flush à chaque chargement
add_action( 'init', function() {
flush_rewrite_rules(); // Très mauvais : lourd, et peut provoquer des effets de bord
} );
รหัส AFTER (แก้ไขแล้ว): ล้างข้อมูลเฉพาะเมื่อเปิดใช้งานเท่านั้น
วางโค้ดนี้ไว้ใน ปลั๊กอินที่กำหนดเอง (อดีต: /wp-content/plugins/mon-fix/mon-fix.phpจากนั้นเปิดใช้งาน แล้วคุณสามารถเก็บไว้ (โดยไม่ต้องลบทิ้งอย่างถาวร) หรือลบทิ้งก็ได้
<?php
/**
* Plugin Name: Fix Permaliens (flush à l'activation)
* Description: Force une régénération des règles de réécriture à l'activation uniquement.
*/
register_activation_hook( __FILE__, function() {
// On régénère proprement les règles une seule fois
flush_rewrite_rules();
} );
register_deactivation_hook( __FILE__, function() {
// Optionnel : on flush à la désactivation si le plugin ajoutait des règles
flush_rewrite_rules();
} );
ทำไมจึงถูกต้อง
- คุณกำจัดรูปแบบที่ไม่พึงประสงค์:
flush_rewrite_rules()ไม่ควรเปิดหน้าใหม่ทุกครั้ง - คุณจะรีเซ็ตกฎหลังจากมีการเปลี่ยนแปลง CPT/slug ซึ่งจะช่วยให้หน้าจอผู้ดูแลระบบบางส่วนและเอนด์พอยต์ REST/AJAX ที่เกี่ยวข้องมีความเสถียรมากขึ้น
เอกสารทางการ: flush_rewrite_rules().
วิธีแก้ปัญหาที่ 3: ค้นหาสาเหตุของข้อผิดพลาด PHP ที่ร้ายแรงในหน้าจอ "บทความ" (ฮุกผู้ดูแลระบบ คอลัมน์ ตัวกรอง)
นี่คือสาเหตุที่พบบ่อยที่สุดที่ทำให้เกิดข้อผิดพลาด “v3.1.1 ไม่สามารถเปิดบทความใน wp-admin ได้…” ปลั๊กอิน (v3.1.1) หรือโค้ดสั้นๆ เพิ่มคอลัมน์ แก้ไขคำสั่งค้นหา หรือกรองแถว และทำให้เกิดข้อผิดพลาด PHP (TypeError, ฟังก์ชันไม่ถูกกำหนด ฯลฯ)
ขั้นตอนที่ 1: ค้นหาข้อผิดพลาดที่เกิดขึ้นอย่างแม่นยำ
เปิด wp-content/debug.log หลังจากจำลองข้อผิดพลาด (คลิกที่นี่) บทความ). มองหาบรรทัดที่มีข้อความ "PHP Fatal error" แบบนี้:
PHP Fatal error: Uncaught TypeError: array_merge(): Argument #2 must be of type array, null given
in /wp-content/plugins/mon-plugin/includes/admin-columns.php:123
Stack trace:
#0 ...
หากคุณไม่มีไฟล์บันทึก (log) ให้ติดตั้ง Query Monitor แล้วดูที่แท็บ "PHP Errors" (หากหน้าเว็บโหลดไม่สมบูรณ์) เอกสารประกอบการใช้งาน Query Monitor: WordPress.org.
ขั้นตอนที่ 2: แยกตัวโดยไม่รบกวนพื้นที่สาธารณะ (ตรวจสอบสุขภาพ)
กับ ตรวจสอบสุขภาพและแก้ไขปัญหา :
- เปิดใช้งานโหมดแก้ไขปัญหา (เฉพาะในเซสชันของคุณเท่านั้น)
- ทดสอบ บทความถ้าใช้งานได้ แสดงว่าปัญหาเกิดจากปลั๊กอิน/ธีมที่ถูกปิดใช้งานในโหมดแก้ไขปัญหา
- เปิดใช้งานปลั๊กอินทีละตัวจนกว่าจะพบปัญหาโปรแกรมหยุดทำงาน
จากประสบการณ์ของผม นี่เป็นวิธีที่เร็วที่สุดในการระบุ "ปลั๊กอินเวอร์ชัน 3.1.1" โดยไม่ทำให้เว็บไซต์ใช้งานไม่ได้
ตัวอย่างทั่วไป: ตัวกรองคอลัมน์ที่ส่งคืนประเภทข้อมูลที่ไม่ถูกต้อง
เกี่ยวกับ edit.phpโค้ดจำนวนมากใช้ตัวกรอง manage_posts_columns (หรือ manage_edit-post_columns) เพื่อเพิ่มคอลัมน์ ข้อผิดพลาดคลาสสิกใน PHP 8+: การส่งคืนค่า null แทนที่จะเป็นภาพวาด
โค้ดก่อนหน้า (เสีย)
ตัวอย่างที่สมจริง: ปลั๊กอิน/โค้ดส่วนย่อยต้องการลบคอลัมน์ แต่ลืมส่งค่าอาร์เรย์กลับมา:
<?php
// EXEMPLE CASSÉ : filtre qui ne retourne rien (donc null)
add_filter( 'manage_posts_columns', function( $columns ) {
unset( $columns['comments'] );
// Oubli : return $columns;
}, 10, 1 );
ผลลัพธ์ที่เป็นไปได้: ต่อมา WordPress (หรือปลั๊กอินอื่น) จะทำการดำเนินการบางอย่าง array_merge() sur $columns และได้รับ null → TypeError → หน้าจอรายการสินค้าที่สั่งซื้อไม่ตรงลำดับ
รหัสหลัง (แก้ไขแล้ว)
วางวิธีแก้ไขนี้ลงในปลั๊กอินที่กำหนดเอง (หรือ functions.php (ในธีมสำหรับเด็ก) หลังจากบันทึกหากคุณสงสัยว่ามีปัญหาเกี่ยวกับปลั๊กอิน ให้แก้ไขในโค้ดของคุณเองและปิดใช้งานปลั๊กอินที่เป็นต้นเหตุของปัญหา
<?php
/**
* Correctif : toujours retourner un tableau de colonnes.
* Emplacement : functions.php (thème enfant) OU plugin custom.
*/
add_filter( 'manage_posts_columns', function( $columns ) {
if ( ! is_array( $columns ) ) {
// Sécurité : évite les TypeError si un autre code a renvoyé n'importe quoi
$columns = [];
}
unset( $columns['comments'] );
return $columns;
}, 10, 1 );
ทำไมจึงถูกต้อง
- ตัวกรอง ต้อง ส่งคืนค่า มิเช่นนั้น WordPress จะดึงข้อมูลมา
null. - การป้องกัน
is_array()ช่วยปกป้องคุณได้แม้ว่าปลั๊กอินอื่นจะส่งคืนค่าประเภทที่ไม่ถูกต้องก็ตาม
เอกสารอย่างเป็นทางการเกี่ยวกับ hooks (actions/filters): API ปลั๊กอิน: Hooks.
ตัวอย่างทั่วไป: hook "pre-request" ที่ทำให้รายการเสียหาย (pre_get_posts)
อีกหนึ่งข้อผิดพลาดคลาสสิก: คุณต้องการกรองบทความในแผงผู้ดูแลระบบ และคุณแก้ไขคำค้นหาทั้งหมด รวมถึงคำค้นหาในรายการผู้ดูแลระบบด้วย หากคำค้นหาไม่ถูกต้อง หน้า "บทความ" จะว่างเปล่า ทำงานช้า หรือเกิดข้อผิดพลาดขึ้น
โค้ดก่อนหน้า (เสีย)
<?php
// EXEMPLE CASSÉ : modifie toutes les requêtes, y compris l'admin
add_action( 'pre_get_posts', function( $query ) {
// Mauvais : pas de garde-fous, touche REST, admin, widgets, etc.
$query->set( 'posts_per_page', 500 );
$query->set( 'post_status', 'publish' );
} );
รหัสหลัง (แก้ไขแล้ว)
วัตถุประสงค์: แก้ไขเฉพาะส่วนหน้าเว็บหลักเท่านั้น ไม่ใช่ส่วนแผงควบคุมผู้ดูแลระบบ ควรใส่ไว้ในปลั๊กอินที่กำหนดเองหรือธีมลูก
<?php
/**
* Correctif : limiter l'impact de pre_get_posts.
* Emplacement : functions.php (thème enfant) OU plugin custom.
*/
add_action( 'pre_get_posts', function( $query ) {
// Toujours vérifier qu'on ne casse pas l'admin
if ( is_admin() ) {
return;
}
// Ne modifier que la requête principale
if ( ! $query->is_main_query() ) {
return;
}
$query->set( 'posts_per_page', 12 );
}, 10, 1 );
เอกสารทางการ: pre_get_posts.
กรณีทั่วไป: สคริปต์ JavaScript ถูกแทรกเข้าไปในแผงควบคุมผู้ดูแลระบบ ทำให้ไฟล์ edit.php ทำงานผิดพลาด
หากคอนโซลแสดงข้อผิดพลาด JS ให้มองหาปลั๊กอินที่เรียกใช้สคริปต์ผ่านส่วนผู้ดูแลระบบ ซึ่งบางครั้งอาจเป็นสคริปต์ที่ถูกย่อขนาด หรือบางครั้งอาจขึ้นอยู่กับไลบรารีที่ขาดหายไป
โค้ดก่อนหน้า (เสีย)
<?php
// EXEMPLE CASSÉ : charge un script admin partout, sans dépendances ni ciblage
add_action( 'admin_enqueue_scripts', function() {
wp_enqueue_script(
'mon-admin',
plugin_dir_url( __FILE__ ) . 'admin.js',
[],
'3.1.1',
true
);
} );
รหัสหลัง (แก้ไขแล้ว)
เรามุ่งเป้าไปที่หน้าจอ "บทความ" (โพสต์) เท่านั้น และประกาศความสัมพันธ์ที่เหมาะสม
<?php
/**
* Correctif : charger le JS uniquement sur l'écran des articles.
* Emplacement : plugin custom (recommandé).
*/
add_action( 'admin_enqueue_scripts', function( $hook_suffix ) {
// L'écran liste des posts natifs est généralement edit.php
if ( 'edit.php' !== $hook_suffix ) {
return;
}
// Optionnel : s'assurer qu'on est bien sur post (et pas un CPT)
$post_type = isset( $_GET['post_type'] ) ? sanitize_key( $_GET['post_type'] ) : 'post';
if ( 'post' !== $post_type ) {
return;
}
wp_enqueue_script(
'mon-admin',
plugin_dir_url( __FILE__ ) . 'admin.js',
[ 'jquery' ], // Exemple : dépendance explicite si votre script utilise jQuery
'3.1.2', // Bump de version pour casser le cache navigateur
true
);
}, 10, 1 );
เอกสารทางการ: admin_enqueue_scripts et wp_enqueue_script ().
การตรวจสอบหลังการแก้ไข
- ชาร์จใหม่
/wp-admin/edit.phpในโหมดการเรียกดูแบบส่วนตัว (เพื่อหลีกเลี่ยงการใช้แคชมากเกินไป) - ลองดูสิ:
- กำลังค้นหาบทความ
- กรองตามหมวดหมู่
- แก้ไขด่วน
- ตะกร้า
- ตรวจสอบ
wp-content/debug.log: จะไม่มีข้อความ “ข้อผิดพลาดร้ายแรง” ปรากฏขึ้นขณะคลิกอีกต่อไป - หากคุณใช้ปลั๊กอินแคช: ล้างแคชของปลั๊กอิน + แคชของเซิร์ฟเวอร์ (ถ้ามี) + แคชของเบราว์เซอร์
หากปัญหาเกิดจากความขัดแย้งด้านสิทธิ์การเข้าถึง/ความสามารถ ให้ทดสอบด้วยบัญชี "บรรณาธิการ" (ไม่ใช่แค่บัญชีผู้ดูแลระบบ) หลายเว็บไซต์ "ดูเหมือน" จะแก้ไขได้แล้วสำหรับผู้ใช้ที่เป็นผู้ดูแลระบบ แต่ยังคงมีปัญหาสำหรับผู้ใช้ที่มีบทบาทระดับต่ำกว่า
ถ้าวิธีนั้นยังไม่ได้ผลอีก
ขั้นตอนการแก้ไขปัญหาที่ฉันใช้เมื่อหน้าจอ "บทความ" ไม่สามารถเข้าถึงได้
1) ปิดใช้งานปลั๊กอินที่มีปัญหาโดยไม่ต้องใช้ wp-admin (FTP)
- เชื่อมต่อผ่าน FTP/SFTP
- ไป
/wp-content/plugins/. - เปลี่ยนชื่อโฟลเดอร์ของปลั๊กอินที่น่าสงสัย (เช่น
mon-plugin→mon-plugin.off). - รีเฟรช wp-admin
ถ้าคุณไม่รู้ว่าอันไหน ให้เปลี่ยนชื่อชั่วคราว plugins en plugins.off (ปิดใช้งานปลั๊กอินทั้งหมด) จากนั้นเปิดใช้งานและเรียกใช้งานทีละตัว
2) ตรวจสอบหน่วยความจำ PHP
รายการบทความขนาดใหญ่ (ที่มีคอลัมน์ การค้นหา และสถิติจำนวนมาก) อาจทำให้การใช้หน่วยความจำเพิ่มขึ้นอย่างมาก โปรดตรวจสอบข้อผิดพลาด “ขนาดหน่วยความจำที่อนุญาต…”
คุณสามารถเพิ่มขีดจำกัดของ WordPress ได้ (หากผู้ให้บริการโฮสติ้งของคุณอนุญาต):
<?php
// wp-config.php
define( 'WP_MEMORY_LIMIT', '256M' );
define( 'WP_MAX_MEMORY_LIMIT', '512M' ); // Pour l'admin
ข้อมูลอ้างอิง: wp-config.php (ค่าคงที่).
3) ตรวจสอบเวอร์ชัน PHP
หากคุณใช้ PHP 7.4/8.0 ปลั๊กอินบางตัวที่เพิ่งออกมา (หรือ WordPress 6.9.4) อาจทำงานแตกต่างออกไป แนะนำให้ใช้ PHP เวอร์ชัน 8.1 ขึ้นไป
เอกสาร: เวอร์ชัน PHP ที่รองรับ.
4) ตรวจสอบข้อผิดพลาดของ REST/AJAX
- เปิด
/wp-json/ต้องตอบกลับในรูปแบบ JSON (ไม่ใช่ HTML 404) - ตรวจสอบว่ามีปลั๊กอินรักษาความปลอดภัยใดปิดกั้นอยู่หรือไม่
/wp-json/ouadmin-ajax.php.
เอกสาร REST: คู่มือการใช้งาน WordPress REST API.
5) ตัวตรวจสอบการสืบค้น: ระบุฮุก/ตัวกรองที่เสีย
หากหน้าเว็บโหลดไม่สมบูรณ์ Query Monitor สามารถแสดงข้อมูลต่อไปนี้ให้คุณทราบ:
- ข้อผิดพลาด PHP
- การค้นหาที่ช้า
- ข้อผิดพลาดสคริปต์/สไตล์
- ฮุกที่ถูกเรียกใช้งาน
6) วิธีสุดท้าย: เปิดใช้งานโหมดกู้คืน
WordPress มีกลไก "โหมดกู้คืน" ที่จะทำงานเมื่อปลั๊กอินทำให้เกิดข้อผิดพลาดร้ายแรงในแผงควบคุมผู้ดูแลระบบ หากคุณได้รับอีเมลแจ้งว่า "เว็บไซต์ของคุณกำลังประสบปัญหาทางเทคนิค" ให้ใช้ลิงก์กู้คืนเพื่อปิดใช้งานปลั๊กอินที่ก่อปัญหา
เอกสาร: โหมดกู้คืน (รองรับ).
ข้อผิดพลาดและปัญหาที่พบบ่อย
แผนภูมิการวินิจฉัย
| อาการ | สาเหตุที่เป็นไปได้ | การตรวจสอบ | Solution |
|---|---|---|---|
| ข้อผิดพลาดร้ายแรงพบเฉพาะในส่วน "บทความ" เท่านั้น | ปลั๊กอินเวอร์ชัน 3.1.1 เพิ่มคอลัมน์/ตัวกรองและกลุ่มต้นไม้ | ไฟล์ debug.log แสดงพาธใน /plugins/... | ปิดใช้งาน/ย้อนกลับปลั๊กอิน แก้ไขฮุก (วิธีแก้ปัญหาที่ 3) |
| “ขออภัย คุณไม่มีสิทธิ์…” | ความสามารถ CPT หรือปลั๊กอินบทบาทที่แมปไม่ถูกต้อง | ทดสอบในโหมดผู้ดูแลระบบเทียบกับโหมดแก้ไข ตรวจสอบ CPT | แก้ไข CPT/caps ให้ถูกต้อง (วิธีแก้ปัญหาที่ 1) และตรวจสอบปลั๊กอินบทบาท |
| รายการว่างเปล่า (0 รายการ) แต่มีอยู่จริง | pre_get_posts จะแก้ไขคำขอของผู้ดูแลระบบ | ปิดใช้งาน snippet ตรวจสอบโค้ด pre_get_posts | เพิ่มมาตรการป้องกันสำหรับ is_admin/is_main_query (วิธีแก้ปัญหาที่ 3) |
| ไม่สามารถเปิด Quick Edit ได้ | ข้อผิดพลาด JS admin หรือ admin-ajax blocked | กด F12 ที่คอนโซล + แท็บเครือข่าย | กำหนดเป้าหมายไปที่คิว ปิดใช้งานการย่อขนาด อนุญาตการใช้งาน AJAX |
| ปัญหาหลังการย้ายระบบ | เขียนกฎที่ล้าสมัยขึ้นใหม่ | การตั้งค่า > ลิงก์ถาวร, ทดสอบ /wp-json/ | ล้างลิงก์ถาวร (วิธีที่ 2) |
ความผิดพลาดที่ฉันเห็นอยู่บ่อยๆ
- คัดลอกโค้ดไปวางผิดที่ การวางโค้ด PHP ลงในช่อง "CSS" ในตัวสร้างเว็บไซต์หรือในตัวแก้ไขหน้าเว็บ ทำให้ไม่มีอะไรทำงาน หรือโค้ดอาจแสดงผลเป็นข้อความธรรมดา
- ลืมใส่เครื่องหมายเซมิโคลอน dans
functions.phpความผิดพลาดเล็กน้อยอาจทำให้ไม่สามารถเข้าถึง wp-admin ได้ทั้งหมด ควรทำงานในสภาพแวดล้อมทดสอบและรักษาการเข้าถึง FTP ไว้ - การใช้ตะขอที่ไม่เหมาะสม ตัวอย่างเช่น แก้ไขคำขอของผู้ดูแลระบบผ่านทาง
pre_get_postsSansis_admin(). - ความสับสนระหว่างหุ้นและตัวกรอง ตัวกรองจะต้องส่งค่ากลับมา แต่การกระทำไม่จำเป็นต้องส่งค่ากลับมา ในกรณีนี้ ข้อผิดพลาดในการส่งค่ากลับอาจทำให้ "บทความ" ใช้งานไม่ได้
- แคชไม่ได้ถูกล้าง คุณแก้ไขแล้ว แต่เบราว์เซอร์ยังคงแสดงผล JavaScript เวอร์ชันเก่าอยู่ โปรดเพิ่มเวอร์ชันของสคริปต์และล้างแคช
- ทดสอบในสภาพแวดล้อมการใช้งานจริงโดยไม่มีการสำรองข้อมูล : ในแผงควบคุมผู้ดูแลระบบ ระบบอาจล็อกไม่ให้คุณเข้าใช้งานได้
- โค้ดตัวอย่างเสียหายเนื่องจากปลั๊กอินโค้ดตัวอย่าง หากปลั๊กอิน snippets เกิดข้อผิดพลาด คุณจะไม่สามารถปิดใช้งานได้ง่ายๆ อีกต่อไป การใช้ปลั๊กอิน mu จะเป็นวิธีที่เหมาะสมกว่าสำหรับการแก้ไขปัญหา
- โค้ดจากบทเรียนเก่า ไม่สามารถใช้งานร่วมกับ PHP 8.1 ขึ้นไปได้ (อาจเกิดข้อผิดพลาด TypeError, พารามิเตอร์ที่จำเป็น ฯลฯ)
รูปแบบอื่น / ทางเลือกอื่น
วิธีการไม่ต้องเขียนโค้ด: ย้อนกลับไปใช้เวอร์ชัน “v3.1.1”
หากคุณพบว่า "v3.1.1" คือเวอร์ชันของปลั๊กอิน และพบข้อผิดพลาดทันทีหลังจากนั้น:
- ตรวจสอบหน้าปลั๊กอินบน WordPress.org เพื่อดูว่ามีส่วนที่เกี่ยวข้องหรือไม่ มุมมองขั้นสูง อนุญาตให้ดาวน์โหลดเวอร์ชันก่อนหน้าได้
- หรือใช้ปลั๊กอินย้อนกลับ (เช่น WP Rollback) ด้วยความระมัดระวัง และต้องมาจากแหล่งที่น่าเชื่อถือเท่านั้น
ขั้นตอนต่อไป ให้เปิดตั๋วขอความช่วยเหลือสำหรับปลั๊กอิน โดยระบุข้อมูลดังนี้:
- เวอร์ชัน WordPress ของคุณ (6.9.4), PHP,
- บันทึกข้อผิดพลาดทั้งหมด
- ขั้นตอนในการจำลองปัญหา
วิธีการขั้นสูง: ใช้ปลั๊กอิน mu-plugin “bumpers” เพื่อป้องกันข้อผิดพลาดร้ายแรงในไฟล์ edit.php
เมื่อคุณจำเป็นต้องทำให้ระบบผู้ดูแลระบบเสถียรอย่างเร่งด่วน คุณสามารถทำให้ hook ที่รู้จัก (เช่น ตัวกรองคอลัมน์) เป็นกลางได้โดยการแทนที่ด้วยโค้ดป้องกัน คำเตือน: นี่เป็นเพียงวิธีแก้ปัญหาชั่วคราว คุณต้องแก้ไขปัญหาพื้นฐานที่ต้นเหตุในภายหลัง
ตัวอย่าง: คุณได้ระบุตัวกรองที่บางครั้งส่งค่ากลับมา nullคุณไม่สามารถแก้ไขปลั๊กอินได้ (หรือคุณไม่ต้องการแตะต้องโค้ดของมัน) คุณเพิ่มตัวกรองในขั้นตอนสุดท้ายที่ "แก้ไข":
<?php
/**
* Emplacement : /wp-content/mu-plugins/admin-edit-php-safety.php
* Objectif : sécuriser le tableau des colonnes si un plugin renvoie un type invalide.
*/
add_filter( 'manage_posts_columns', function( $columns ) {
// Si un plugin a renvoyé null, on rétablit un tableau minimal
if ( ! is_array( $columns ) ) {
$columns = [
'cb' => '<input type="checkbox" />',
'title' => 'Titre',
'date' => 'Date',
];
}
return $columns;
}, 9999, 1 );
วิธีนี้ไม่ได้ "แก้ไข" ปลั๊กอิน แต่จะช่วยให้คุณเข้าถึงหน้าจอได้อีกครั้งเพื่อดำเนินการวินิจฉัยต่อไป
หลีกเลี่ยงปัญหานี้ในอนาคต
- หลีกเลี่ยงการเรียก CPT ว่า “บทความ” : เก็บ “บทความ” ไว้สำหรับโพสต์ที่เขียนโดยเจ้าของภาษา ตั้งชื่อ CPT ของคุณตามบทบาททางธุรกิจ (แหล่งข้อมูล โครงการ สูตรอาหาร…)
- ไม่มีการล้างแบบถาวร :
flush_rewrite_rules()เฉพาะตอนเปิด/ปิดเครื่องเท่านั้น - รหัสป้องกันบนตัวกรอง : ตรวจสอบประเภท (
is_array,is_stringเมื่อคุณกรองค่าที่ใช้โดยปลั๊กอินอื่นๆ - การจัดลำดับอย่างเป็นระบบ ก่อนการอัปเดตปลั๊กอินครั้งใหญ่ เวอร์ชัน 3.1.1 อาจมีข้อผิดพลาดในหน้าจอผู้ดูแลระบบเฉพาะบางส่วน
- ตรวจสอบหาข้อผิดพลาด เก็บ
WP_DEBUG_LOGสามารถเปิดใช้งานและตั้งค่าการหมุนเวียนไฟล์บันทึกฝั่งเซิร์ฟเวอร์ได้อย่างง่ายดาย - ปลั๊กอินและตัวสร้าง Divi 5, Elementor และ Avada ไม่ได้ป้องกันการแก้ไขเหล่านี้ อย่างไรก็ตาม ควรหลีกเลี่ยงปลั๊กอินเพิ่มประสิทธิภาพแบบ "ครบวงจร" ที่ลดฟังก์ชันการทำงานของผู้ดูแลระบบลงด้วย เพราะนี่คือสาเหตุคลาสสิกของข้อผิดพลาด JavaScript
edit.php.
ถ้าคุณกำลังพัฒนาโปรแกรม: ควรจัดทำเอกสารเกี่ยวกับ hook ของคุณ filter ที่ไม่ส่งค่าอะไรกลับมานั้นเปรียบเสมือนระเบิดเวลา โดยเฉพาะอย่างยิ่งใน PHP 8.1 ขึ้นไป
ทรัพยากร
- การแก้ไขข้อผิดพลาดใน WordPress (WP_DEBUG, บันทึก)
- API ปลั๊กอิน: Hooks (แอ็กชันและตัวกรอง)
- register_post_type() (CPT)
- Hook pre_get_posts (แก้ไขคำสั่งค้นหา)
- flush_rewrite_rules() (rewrites)
- การตรวจสอบสุขภาพและการแก้ไขปัญหา (โหมดแก้ไขปัญหา)
- โปรแกรมตรวจสอบการสืบค้นข้อมูล (การวิเคราะห์ประสิทธิภาพและข้อผิดพลาด)
- WordPress Core บน GitHub (ดูโค้ดอ้างอิง)
- WordPress Core Trac (ตั๋วและข้อผิดพลาด)
- เวอร์ชัน PHP ที่รองรับ
คำถามที่พบบ่อย
ฉันจะรู้ได้อย่างไรว่าปลั๊กอินตัวไหนตรงกับเวอร์ชัน “v3.1.1”?
ดู wp-content/debug.log เส้นทางไปยังไฟล์ที่มีปัญหาเกือบทุกครั้งจะชี้ไปที่ /wp-content/plugins/nom-du-plugin/หรืออีกวิธีหนึ่งคือใช้ฟังก์ชันตรวจสอบสถานะสุขภาพโดยการเปิดใช้งานปลั๊กอินทีละตัว
ฉันไม่สามารถเข้าถึง wp-admin ได้ ฉันควรทำอย่างไร?
เปลี่ยนชื่อโฟลเดอร์ของปลั๊กอินที่น่าสงสัยผ่าน FTP/SFTP (หรือปิดใช้งานปลั๊กอินทั้งหมดโดยการเปลี่ยนชื่อพวกมัน) /wp-content/pluginsจากนั้นเชื่อมต่อใหม่และค่อยๆ เปิดใช้งานทีละขั้นตอน
Divi 5 / Elementor / Avada อาจเป็นสาเหตุของบั๊กนี้ได้หรือไม่?
พวกเขาไม่ค่อยยั่วยุโดยตรงหรอก edit.phpอย่างไรก็ตาม ปลั๊กอินเสริม ปลั๊กอินโค้ดสั้น หรือโปรแกรมเพิ่มประสิทธิภาพ (การย่อขนาด) ที่ติดตั้ง "พร้อมกับตัวสร้าง" อาจทำให้ส่วนติดต่อผู้ดูแลระบบใช้งานไม่ได้ การวินิจฉัยยังคงเหมือนเดิม: ตรวจสอบบันทึกและแยกปลั๊กอิน
ทำไมข้อผิดพลาดนี้จึงปรากฏเฉพาะในส่วน "บทความ" เท่านั้น ไม่ปรากฏในส่วนอื่น ๆ?
เนื่องจากปลั๊กอินหลายตัวใช้ hook เฉพาะที่เกี่ยวข้องกับรายการโพสต์ (คอลัมน์ การเรียงลำดับ ตัวกรอง ข้อจำกัด) ข้อผิดพลาดในโค้ดนี้จึงเกิดขึ้นเฉพาะในกรณีที่จำเป็นเท่านั้น wp-admin/edit.php.
ฉันสามารถแก้ไขปัญหานี้ได้โดยการแก้ไขปลั๊กอินที่มีปัญหาหรือไม่?
หลีกเลี่ยงวิธีนี้ การอัปเดตใดๆ จะเขียนทับการเปลี่ยนแปลงของคุณ ลองทำสิ่งต่อไปนี้แทน: (1) แก้ไขในปลั๊กอินแบบกำหนดเอง/mu-plugin (2) รายงานข้อบกพร่องไปยังผู้พัฒนา (3) เปลี่ยนไปใช้ปลั๊กอินอื่นหากไม่มีการสนับสนุน
ฉันแก้ไขโค้ดแล้ว แต่ก็ไม่มีอะไรเปลี่ยนแปลง
ล้างแคช (ปลั๊กอิน เซิร์ฟเวอร์ เบราว์เซอร์) หากเป็น JavaScript ระดับผู้ดูแลระบบ ให้เพิ่มเวอร์ชันใน... wp_enqueue_script()โปรดตรวจสอบให้แน่ใจว่าคุณได้แก้ไขไฟล์ที่ถูกต้องแล้ว (ธีมลูกหรือธีมหลัก)
“ขออภัย คุณไม่ได้รับอนุญาต…” ทั้งๆ ที่ฉันเป็นผู้ดูแลระบบ
ปัญหานี้เกิดขึ้นหากปลั๊กอินบทบาท/ความปลอดภัยได้แก้ไขความสามารถ หรือหาก CPT มีความสามารถที่ไม่สอดคล้องกัน ให้ปิดใช้งานปลั๊กอินบทบาทชั่วคราว จากนั้นแก้ไขการประกาศ CPT (วิธีแก้ปัญหาที่ 1)
รายการบทความว่างเปล่า แต่หน้าเว็บยังคงแสดงโพสต์อยู่
ตะขอ pre_get_posts หรือปลั๊กอินจำกัดการเข้าถึงสามารถแก้ไขคำขอได้เฉพาะในโหมดผู้ดูแลระบบเท่านั้น ลองค้นหาโค้ดตัวอย่างที่บังคับใช้ฟังก์ชันนี้ post_status, authorหรือ posts_per_page ปราศจากมาตรการป้องกัน is_admin().
วิธีที่ดีที่สุดในการติดแผ่นแปะที่ติดทนนานคืออะไร?
Un mu- ปลั๊กอิน หากคุณต้องการให้การแก้ไขยังคงใช้งานได้แม้ว่าธีมจะเปลี่ยนไป ให้ใช้ปลั๊กอินแบบกำหนดเองมาตรฐาน หลีกเลี่ยงการพึ่งพาธีมสำหรับตรรกะการจัดการผู้ดูแลระบบ
ฉันควรติดต่อผู้ให้บริการโฮสติ้งเมื่อใด?
หากคุณพบข้อผิดพลาด 500 รายการโดยไม่มีร่องรอยใดๆ debug.logหรืออาจมีปัญหาเรื่องสิทธิ์การเข้าถึง/OPcache หรือ PHP เก่าเกินไปและคุณไม่สามารถเปลี่ยนได้ แจ้งเวลาที่ทำการทดสอบและ URL ให้เขาทราบด้วย /wp-admin/edit.php เพื่อเปรียบเทียบกับบันทึกของเซิร์ฟเวอร์