หากคุณได้คลิกไปแล้ว บทความ ใน 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_article ou ressource).
  • ป้ายกำกับที่ระบุอย่างชัดเจน (เช่น “แหล่งข้อมูล”)
  • ความสามารถต่างๆ ถูกแมปอย่างถูกต้องผ่านทาง 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().

สถานการณ์นี้มักเกิดขึ้นหลังจาก:

  • การย้ายเว็บไซต์ (การเปลี่ยน 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: แยกตัวโดยไม่รบกวนพื้นที่สาธารณะ (ตรวจสอบสุขภาพ)

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

  1. เปิดใช้งานโหมดแก้ไขปัญหา (เฉพาะในเซสชันของคุณเท่านั้น)
  2. ทดสอบ บทความถ้าใช้งานได้ แสดงว่าปัญหาเกิดจากปลั๊กอิน/ธีมที่ถูกปิดใช้งานในโหมดแก้ไขปัญหา
  3. เปิดใช้งานปลั๊กอินทีละตัวจนกว่าจะพบปัญหาโปรแกรมหยุดทำงาน

จากประสบการณ์ของผม นี่เป็นวิธีที่เร็วที่สุดในการระบุ "ปลั๊กอินเวอร์ชัน 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)

  1. เชื่อมต่อผ่าน FTP/SFTP
  2. ไป /wp-content/plugins/.
  3. เปลี่ยนชื่อโฟลเดอร์ของปลั๊กอินที่น่าสงสัย (เช่น mon-pluginmon-plugin.off).
  4. รีเฟรช 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/ ou admin-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_posts Sans is_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 ขึ้นไป

ทรัพยากร

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

ฉันจะรู้ได้อย่างไรว่าปลั๊กอินตัวไหนตรงกับเวอร์ชัน “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 เพื่อเปรียบเทียบกับบันทึกของเซิร์ฟเวอร์