Gutenberg มีปัญหา: แก้ไขปัญหาตัวแก้ไขบล็อกของ WordPress

หากคุณเคยเห็นตัวแก้ไขบล็อกค้างอยู่ที่ "กำลังโหลด..." หรือแสดงข้อความ "ตัวแก้ไขพบข้อผิดพลาดที่ไม่คาดคิด" คุณอาจมีปัญหาเกี่ยวกับ REST API สคริปต์ผู้ดูแลระบบ หรือแคช/ระบบรักษาความปลอดภัย ใน WordPress 6.9.4 (เมษายน 2026) Gutenberg พึ่งพาอินเทอร์เฟซผู้ดูแลระบบที่สะอาดตามากยิ่งขึ้นกว่าเดิม ได้แก่ REST API, nonce, สคริปต์ที่มีการกำหนดเวอร์ชัน และการตอบสนอง JSON ที่สะอาดตา

มีปัญหา

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

"The editor has encountered an unexpected error."
"Updating failed. The response is not a valid JSON response."
"Error: The REST API encountered an error."
"GET https://example.com/wp-json/wp/v2/types/post?context=edit 403 (Forbidden)"

มันจะปรากฏในแผงควบคุมผู้ดูแลระบบ บน บทความ→เพิ่ม / หน้า → แก้ไขบางครั้งเฉพาะกับเนื้อหาบางประเภท (CPT) และมักจะเกิดขึ้นทันทีหลังจากนั้น:

การอัปเดตปลั๊กอินความปลอดภัย/แคช
การเปลี่ยนแปลงกฎ WAF/CDN (Cloudflare, Sucuri, ModSecurity)
เพิ่มโค้ดสั้นๆ ที่ "ช่วยปรับปรุง" โครงสร้างของ HTML
การย้ายข้อมูล (URL, HTTPS, รีเวิร์สพร็อกซี)
หรือการอัปเดตธีม (Avada) / โปรแกรมสร้างหน้าเว็บ (Elementor, Divi 5) ที่เพิ่มสคริปต์สำหรับผู้ดูแลระบบ

คู่มือนี้เหมาะสำหรับผู้ใช้ระดับกลาง: คุณรู้วิธีการเปิดคอนโซล อ่านบันทึก ติดตั้งปลั๊กอิน MU และใช้งาน WP-CLI แล้ว เมื่ออ่านจบ คุณจะสามารถระบุสาเหตุของปัญหา (REST, JS, แคช, ความปลอดภัย, PHP) และแก้ไขปัญหาได้อย่างหมดจด โดยใช้งานได้กับ WordPress 6.9.4 ขึ้นไป และ PHP 8.1 ขึ้นไป

สรุปด่วน

เริ่มจากคอนโซล : ความผิดพลาด ข้อผิดพลาดที่มองเห็นได้ (403 REST, JSON ไม่ถูกต้อง, ไฟล์ JS 404) จะกำหนดส่วนที่เหลือ
การทดสอบ REST ทันที : /wp-json/wp/v2/types/post?context=edit ขณะที่ล็อกอินอยู่ ให้เปรียบเทียบกับบัญชีผู้ดูแลระบบ
ปิดการใช้งานการรบกวน : ปลั๊กอินด้านความปลอดภัย/แคช, สนิปเป็ต, การเพิ่มประสิทธิภาพ JS/CSS, CDN จากนั้นเปิดใช้งานทีละรายการ
เปิดใช้งานการล้างบันทึก : WP_DEBUG_LOG + ใช้ Query Monitor และค้นหาคำว่า “REST”, “nonce”, “headers already sent”, “fatal”
อย่า "แก้ไข" Gutenberg ด้วย jQuery ความล้มเหลวส่วนใหญ่เกิดจากฟังก์ชัน enqueue หรือ filter ที่แก้ไขข้อมูล JSON ที่ได้รับกลับมา
ถ้าคุณกำลังก่อสร้างอยู่ Divi 5/Elementor/Avada เพิ่มสินทรัพย์สำหรับผู้ดูแลระบบ ซึ่งมักเกิดข้อขัดแย้งด้านการเพิ่มประสิทธิภาพหรือความปลอดภัย

มีอาการ

นี่คืออาการที่ฉันพบเห็นบ่อยที่สุด (เรียงจากอาการที่พบบ่อยที่สุดไปจนถึงอาการที่ "ตรวจยากที่สุด")

หน้าจอสีขาวในโปรแกรมแก้ไข พร้อมวงล้อหมุนไม่รู้จบ
ข้อความ UI “สำนักพิมพ์พบข้อผิดพลาดที่ไม่คาดคิด”
ข้อผิดพลาดในการเผยแพร่ “การอัปเดตล้มเหลว การตอบสนองไม่ใช่การตอบสนอง JSON ที่ถูกต้อง”
คอนโซลเบราว์เซอร์ (F12 → คอนโซล / เครือข่าย):
- 403/401 บน /wp-json/... (มักจะเป็น WAF หรือกฎความปลอดภัย)
- ข้อผิดพลาด 500 บนเส้นทาง REST (ข้อผิดพลาดร้ายแรงของ PHP ฝั่งเซิร์ฟเวอร์)
- 404 ในไฟล์ wp-includes/js/dist/*.min.js (แคช/CDN หรือการติดตั้งไม่สมบูรณ์)
- ข้อผิดพลาด CORS หรือ CSP (ส่วนหัวด้านความปลอดภัยที่เข้มงวดเกินไป)
- Unexpected token < in JSON (มีการแทรกโค้ด HTML เข้าไปในข้อมูลตอบกลับ JSON ซึ่งโดยทั่วไปจะเป็นข้อความเตือนของ PHP หรือหน้า HTML 403)
มันใช้งานได้ในสภาพแวดล้อมจำลอง แต่ใช้ไม่ได้ในสภาพแวดล้อมการใช้งานจริง : CDN, การแคชข้อมูลอย่างเข้มข้น, WAF หรือความแตกต่างใน PHP/ส่วนขยาย
มันใช้ได้ผลสำหรับผู้ดูแลระบบ แต่ใช้ไม่ได้ผลสำหรับบรรณาธิการ : ความสามารถ ค่า nonce หรือปลั๊กอินที่กรองตามบทบาท
มันพังเฉพาะบน CPT เท่านั้น : show_in_rest เส้นทาง REST ที่ขาดหายไป หรือเส้นทาง REST ที่กำหนดเอง ซึ่งเป็นข้อผิดพลาดร้ายแรง

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

อาการ	สาเหตุที่เป็นไปได้	การตรวจสอบ	Solution
“การตอบกลับ JSON ไม่ถูกต้อง”	มีการแทรก HTML/คำเตือนลงใน REST	เปิดการตอบสนองเครือข่ายของ `/wp-json/...`	ปิดใช้งานปลั๊กอิน/โค้ดตัวอย่าง ถูกต้อง คำเตือน โปรดดูวิธีแก้ปัญหาที่ 1
403 เมื่อ `/wp-json/`	WAF, กฎความปลอดภัย, การตรวจสอบสิทธิ์ขั้นพื้นฐาน	ทดสอบ REST ในโหมดการเรียกดูแบบส่วนตัว + บันทึก WAF	เพิ่มส่วนหัว REST ลงในรายการที่อนุญาต ดูวิธีแก้ปัญหาที่ 1
ตัวหมุนไม่สิ้นสุด ข้อผิดพลาด JavaScript	คิวผู้ดูแลระบบเสีย / การเพิ่มประสิทธิภาพ JavaScript	ข้อความแจ้งเตือน: “ไม่สามารถอ่านคุณสมบัติของค่า undefined ได้”	ถูกต้อง จัดคิว ยกเว้นสินทรัพย์ ดูวิธีแก้ปัญหาที่ 2
404 เมื่อ `wp-includes/js/dist/`	การติดตั้งไม่สมบูรณ์ / แคช CDN	ทดสอบโดยการปิดใช้งาน CDN และล้างแคช	การล้างข้อมูลและการปรับใช้ใหม่ โปรดดูวิธีแก้ปัญหาที่ 3
500 บนถนนพักรถ	ข้อผิดพลาดร้ายแรงของ PHP (ปลั๊กอิน/ธีม)	WP_DEBUG_LOG + Query Monitor	เพื่อแก้ไขข้อผิดพลาดร้ายแรง ให้ทำการย้อนกลับ (rollback) โปรดดูวิธีแก้ปัญหาที่ 1

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

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

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

Gutenberg โหลดชุดข้อมูลจาก wp-includes/js/dist/ และรูปแบบการดูแลระบบ
ระบบจะดึงข้อมูลผ่านทาง REST endpoints (ประเภท, การจัดหมวดหมู่, การตั้งค่า, บันทึกอัตโนมัติ, เสาฯลฯ )
มันส่งคำขอที่ตรวจสอบสิทธิ์แล้วพร้อมกับค่า nonce หากปลั๊กอินแก้ไขส่วนหัว บล็อกเส้นทาง หรือแคชการตอบสนอง "แก้ไขบริบท" มันจะทำให้ระบบทำงานผิดพลาด
คำเตือน PHP, "ข้อความแจ้งเตือน" หรือแม้แต่ช่องว่างก่อนหน้า <?php ปริมาณดังกล่าวอาจมากพอที่จะทำให้การตอบสนอง JSON ปนเปื้อนได้

สาเหตุที่เป็นไปได้ (จากที่พบได้บ่อยที่สุดไปจนถึงที่พบได้น้อยที่สุด):

การบล็อก REST โดยระบบรักษาความปลอดภัย/แคช/CDN (403, การตรวจสอบสิทธิ์แบบท้าทาย, การตรวจสอบสิทธิ์ขั้นพื้นฐาน, กฎ ModSecurity)
การตอบสนอง REST ที่ปนเปื้อน โดยคำเตือนของ PHP var_dump()หรือปลั๊กอินที่พิมพ์ HTML ออกมา
การเพิ่มประสิทธิภาพ JS/CSS ซึ่งจะรวม/ย่อขนาดสคริปต์ผู้ดูแลระบบ (หรือ "เลื่อนการทำงาน" ของ WordPress)
คิวผู้ดูแลระบบที่ออกแบบมาไม่ดี (ขาดส่วนประกอบที่จำเป็น, hook ที่ไม่เหมาะสม, การโหลดแบบทั่วโลกในทุกหน้า)
ส่วนหัว CSP/ความปลอดภัย เข้มงวดเกินไป (บล็อก) blob:, data:หรือสคริปต์/สไตล์ที่คาดหวังไว้)
ความไม่สอดคล้องกันของแคช (service worker, browser cache, object cache, CDN) ซึ่งให้บริการไฟล์จากเวอร์ชันอื่น
ปัญหาเซิร์ฟเวอร์ (สิทธิ์การเข้าถึงไฟล์, การติดตั้งไม่สมบูรณ์, opcache, ส่วนขยาย PHP หายไป)

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

ป้องกัน ไฟล์ + ฐานข้อมูล (หรือสแนปช็อตหากคุณใช้บริการโฮสติ้งแบบจัดการ) ห้ามทดสอบ "แบบสุ่ม" ในสภาพแวดล้อมการใช้งานจริง
สภาพแวดล้อมการทดสอบ : ควรมีการจัดวางอุปกรณ์ หรืออย่างน้อยก็ควรมีช่วงเวลาสำหรับการบำรุงรักษา
รุ่น แนะนำให้ใช้ WordPress เวอร์ชัน 6.9.4 และ PHP เวอร์ชัน 8.1 ขึ้นไป โปรดตรวจสอบข้อมูลเพิ่มเติม เครื่องมือ → สุขภาพเว็บไซต์.
ปลั๊กอินที่มีประโยชน์ :
- Query Monitor (การสืบค้นข้อมูล, ข้อผิดพลาด PHP, hooks, REST)
- ตรวจสอบสุขภาพและแก้ไขปัญหา (โหมดแก้ไขปัญหาโดยไม่ส่งผลกระทบต่อผู้เข้าชม)
ท่อน เปิดใช้งานชั่วคราว WP_DEBUG_LOG (โดยไม่แสดงผลที่ส่วนหน้า)

การกำหนดค่าที่แนะนำ (ชั่วคราว) ใน wp-config.php :

<?php
// Active le debug sans afficher les erreurs à l'écran (évite de polluer des réponses JSON).
define( 'WP_DEBUG', true );
define( 'WP_DEBUG_DISPLAY', false );

// Log dans wp-content/debug.log
define( 'WP_DEBUG_LOG', true );

// Optionnel : réduit les "notices" bruyantes de certains plugins (à ajuster selon votre besoin).
// error_reporting( E_ALL & ~E_NOTICE & ~E_DEPRECATED );

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

วิธีแก้ปัญหาที่ 1: REST API ถูกบล็อก (403/401/500) และ Gutenberg ไม่สามารถเริ่มต้นทำงานได้อีกต่อไป

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

การวินิจฉัย

เปิดโปรแกรมแก้ไขข้อความในฐานะผู้ดูแลระบบ จากนั้นกด F12 → tab เครือข่าย.
กรองตาม wp-json.
ระบุคำถามข้อผิดพลาดแรก (มักจะ) types, settings, posts).
คลิกที่คำค้นหา → ดูผลลัพธ์ คำตอบ :
- ถ้าคุณเห็นโค้ด HTML (หน้าแสดงข้อผิดพลาด, การตรวจสอบสิทธิ์, การเข้าสู่ระบบ) แสดงว่าคุณเจอสิ่งที่ต้องการแล้ว
- หากคุณพบข้อผิดพลาด JSON ของ WordPress โปรดจดบันทึกไว้ code et message.

ทดสอบอย่างรวดเร็วผ่านบรรทัดคำสั่ง (หากคุณมี WP-CLI + คุกกี้/nonce จะซับซ้อนกว่า) สำหรับการทดสอบแบบง่าย ให้รันในเบราว์เซอร์ขณะล็อกอินอยู่:

URL : https://votre-site.tld/wp-json/wp/v2/types/post?context=edit

หากคุณได้รับข้อผิดพลาด 403/401 หรือข้อผิดพลาดของหน้า HTML สาเหตุส่วนใหญ่มักมาจากภายนอก WordPress (WAF, ปลั๊กอินรักษาความปลอดภัย, การตรวจสอบสิทธิ์แบบ Basic Auth, พร็อกซีแบบย้อนกลับ)

กรณีทั่วไป: ปลั๊กอินปิดกั้นการเข้าถึง REST ผ่านตัวกรองที่เข้มงวดเกินไป

ฉันมักพบโค้ดตัวอย่างที่ "ปิดใช้งาน REST API" ด้วยเหตุผลด้านความปลอดภัย แต่โค้ดเหล่านั้นกลับทำให้ตัวแก้ไขข้อความใช้งานไม่ได้ (และบางครั้งก็ทำให้ Elementor/Divi/Avada ในส่วนผู้ดูแลระบบใช้งานไม่ได้เช่นกัน)

ด้านหน้า (ชำรุด)

<?php
// Mauvaise idée : bloque l'API REST pour tout le monde, y compris l'admin.
// Résultat : Gutenberg ne peut plus charger.
add_filter( 'rest_authentication_errors', function( $result ) {
	return new WP_Error(
		'rest_disabled',
		'REST API désactivée',
		array( 'status' => 403 )
	);
} );

หลังจาก (การแก้ไขและการจำกัดเป้าหมาย)

<?php
/**
 * Restriction REST plus sûre : ne bloque pas l'admin, et limite seulement certaines routes publiques.
 * À placer dans un plugin (ou MU-plugin), pas dans functions.php si vous changez souvent de thème.
 */
add_filter( 'rest_authentication_errors', function( $result ) {

	// Si une authentification a déjà échoué/réussi, respectez le résultat.
	if ( ! empty( $result ) ) {
		return $result;
	}

	// Autorisez toujours les utilisateurs connectés (Gutenberg en dépend).
	if ( is_user_logged_in() ) {
		return $result;
	}

	// Exemple : bloquer uniquement une route custom publique (à adapter).
	$request_uri = isset( $_SERVER['REQUEST_URI'] ) ? (string) $_SERVER['REQUEST_URI'] : '';

	if ( str_contains( $request_uri, '/wp-json/mon-namespace/v1/' ) ) {
		return new WP_Error(
			'rest_forbidden',
			'Accès REST interdit.',
			array( 'status' => 403 )
		);
	}

	return $result;
} );

ทำไมจึงถูกต้อง Gutenberg เรียกใช้เอนด์พอยต์ REST ในบริบท edit ซึ่งต้องอาศัยการเชื่อมต่อเซสชัน การบล็อก REST "ทั่วโลก" เทียบเท่ากับการตัดการเชื่อมต่อ API ภายในของผู้เผยแพร่

จุดเฝ้าระวัง ตัวกรองประเภทนี้ต้องมีความแม่นยำสูง บล็อกโดยใช้หลักการ “การมีอยู่ของ” /wp-json/" เป็นรูปแบบที่ไม่ควรทำตาม หากคุณต้องการลดความเสี่ยงจาก REST จริงๆ ให้ทำทีละเส้นทาง และทดสอบในส่วนของผู้ดูแลระบบ

กรณีทั่วไป: ข้อความเตือน "การตอบสนอง JSON ไม่ถูกต้อง" จาก PHP

เมื่อการตอบสนอง REST เริ่มต้นด้วย HTML Gutenberg มักจะแสดงข้อความ "การตอบสนอง JSON ไม่ถูกต้อง" สาเหตุที่แท้จริงบางครั้งอาจเป็นเพียงคำเตือนของ PHP ที่แสดงขึ้นก่อน JSON เท่านั้น

ด้านหน้า (ชำรุด)

<?php
// Exemple réaliste : un plugin/thème affiche un warning (variable non définie) et pollue la réponse REST.
add_action( 'init', function() {
	// Mauvais : echo en init, peut s'exécuter pendant une requête REST.
	if ( isset( $_GET['debug'] ) ) {
		echo "DEBUG"; // Pollue la sortie JSON.
	}
} );

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

<?php
// Ne jamais "echo" dans le cycle WordPress global.
// Utilisez error_log() et limitez à WP_DEBUG.
add_action( 'init', function() {
	if ( defined( 'WP_DEBUG' ) && WP_DEBUG && isset( $_GET['debug'] ) ) {
		error_log( 'Debug init déclenché' );
	}
} );

ทำไมจึงถูกต้อง REST API ต้องส่งคืนข้อมูล JSON ในรูปแบบที่ถูกต้องเท่านั้น อักขระใดๆ ก็ตาม (เช่น คำเตือน, BOM, อักขระสะท้อน) จะทำให้การแยกวิเคราะห์ JSON บนฝั่งเบราว์เซอร์ล้มเหลว

กรณีทั่วไป: การบล็อกโดย WAF/CDN (403, การตรวจสอบสิทธิ์แบบท้าทาย, การตรวจสอบสิทธิ์พื้นฐาน)

หากข้อความตอบกลับ 403 เป็นหน้า HTML “การเข้าถึงถูกปฏิเสธ” หรือข้อความท้าทายใดๆ WordPress จะไม่รับผิดชอบ

ปิดใช้งาน WAF/CDN ชั่วคราว (หรือเปลี่ยนไปใช้ "โหมดพัฒนา")
อนุญาตอย่างชัดเจน /wp-json/ et /wp-admin/admin-ajax.php.
หากคุณเปิดใช้งาน Basic Auth ในโหมดทดสอบ Gutenberg อาจทำงานล้มเหลว ขึ้นอยู่กับการตั้งค่าเบราว์เซอร์ของคุณ ในกรณีนี้ ให้อนุญาตที่อยู่ IP ของผู้ดูแลระบบ หรือปิดใช้งาน Basic Auth ชั่วคราวขณะแก้ไข

หากต้องการทำความเข้าใจสัญญา REST ในฝั่ง WordPress เอกสารอย่างเป็นทางการสามารถดูได้ที่นี่: คู่มือการใช้งาน REST API.

วิธีแก้ปัญหาที่ 2: สคริปต์ตัวแก้ไขที่เสียหาย (การจัดคิว การพึ่งพา ลำดับการโหลด)

สถานการณ์คลาสสิกที่สอง: ธีมหรือปลั๊กอินโหลดสคริปต์ในแผงผู้ดูแลระบบ แต่:

เกี่ยวผิดที่
โดยไม่มีข้อผูกมัดใดๆ
หรือโดยการเขียนทับไลบรารี (React, lodash) ที่ WordPress มีให้แล้ว

ผลลัพธ์: ข้อผิดพลาด JS ประเภท wp is not defined, Cannot read properties of undefinedหรืออาจเป็นการชนที่เงียบสนิท

การวินิจฉัย

F12 → คอนโซล: โปรดสังเกต รอบปฐมทัศน์ ข้อผิดพลาด (ไม่ใช่ข้อที่ 15) ข้อแรกมักเป็นสาเหตุ
F12 → เครือข่าย: ค้นหาไฟล์ JS ที่มีข้อผิดพลาด 404/ถูกบล็อก
ปิดใช้งานปลั๊กอินเพิ่มประสิทธิภาพ (minify/combine/defer) ที่ส่งผลต่อแผงควบคุมผู้ดูแลระบบเป็นการชั่วคราว

ตัวอย่างทั่วไป: การสำรวจระดับโลกเกี่ยวกับ `admin_enqueue_scripts` โดยไม่ต้องกำหนดเป้าหมายไปที่หน้าจอ

ผมมักเห็นสคริปต์ "admin" ถูกโหลดอยู่ทุกที่ และมันสันนิษฐานว่ามีอยู่แล้ว wp.data (กูเตนเบิร์ก) แม้แต่บนหน้าจอที่ไม่โหลดมัน หรือในทางกลับกัน: มันจะเขียนทับตัวแปรส่วนกลาง

ด้านหน้า (ชำรุด)

<?php
// Mauvais : charge un script partout dans l'admin, sans dépendances, et trop tôt.
// Sur l'écran de l'éditeur, ça peut entrer en conflit.
add_action( 'admin_enqueue_scripts', function() {
	wp_enqueue_script(
		'mon-admin',
		get_stylesheet_directory_uri() . '/assets/admin.js',
		array(), // Oublie des dépendances éventuelles.
		'1.0',
		true
	);
} );

หลังจาก (แก้ไขแล้ว: การกำหนดเป้าหมาย + การพึ่งพา + การกำหนดเวอร์ชัน)

<?php
/**
 * Charge un script admin uniquement sur l'éditeur de blocs, avec des dépendances correctes.
 * Compatible WP 6.9.4+.
 */
add_action( 'admin_enqueue_scripts', function( $hook_suffix ) {

	// Cible les écrans post.php (édition) et post-new.php (création).
	if ( ! in_array( $hook_suffix, array( 'post.php', 'post-new.php' ), true ) ) {
		return;
	}

	$screen = function_exists( 'get_current_screen' ) ? get_current_screen() : null;
	if ( ! $screen ) {
		return;
	}

	// Optionnel : ne chargez que pour certains post types.
	$allowed_post_types = array( 'post', 'page' );
	if ( empty( $screen->post_type ) || ! in_array( $screen->post_type, $allowed_post_types, true ) ) {
		return;
	}

	$src  = get_stylesheet_directory_uri() . '/assets/admin-editor.js';
	$path = get_stylesheet_directory() . '/assets/admin-editor.js';

	wp_enqueue_script(
		'mon-admin-editor',
		$src,
		array( 'wp-data', 'wp-edit-post', 'wp-element' ), // Dépendances Gutenberg.
		file_exists( $path ) ? filemtime( $path ) : '1.0.0',
		true
	);
} );

ทำไมจึงถูกต้อง คุณหลีกเลี่ยงการทำให้แผงควบคุมผู้ดูแลระบบรกเกินไป คุณโหลดเฉพาะที่ที่มี Gutenberg อยู่ และคุณประกาศการพึ่งพาที่เสถียร การกำหนดเวอร์ชันโดย filemtime() นอกจากนี้ยังช่วยหลีกเลี่ยงแคช "ผี" หลังจากการติดตั้งใช้งานอีกด้วย

กรณีทั่วไป: ปลั๊กอินโหลด React/ReactDOM ด้วยตนเอง

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

ด้านหน้า (ชำรุด)

<?php
// Anti-pattern : charger React via CDN dans l'admin.
// Peut casser Gutenberg (deux React différents).
add_action( 'admin_enqueue_scripts', function() {
	wp_enqueue_script( 'react', 'https://unpkg.com/react@18/umd/react.production.min.js', array(), null, true );
	wp_enqueue_script( 'react-dom', 'https://unpkg.com/react-dom@18/umd/react-dom.production.min.js', array( 'react' ), null, true );
} );

หลังจาก (แก้ไข: ใช้แพ็กเกจ WordPress)

<?php
// Utilisez les packages WordPress (wp-element) au lieu de React embarqué.
add_action( 'admin_enqueue_scripts', function( $hook_suffix ) {
	if ( ! in_array( $hook_suffix, array( 'post.php', 'post-new.php' ), true ) ) {
		return;
	}

	wp_enqueue_script(
		'mon-ui',
		plugin_dir_url( __FILE__ ) . 'assets/mon-ui.js',
		array( 'wp-element', 'wp-components', 'wp-i18n' ),
		'1.0.0',
		true
	);
} );

เอกสารที่เป็นประโยชน์: แพ็คเกจ wp-element et คู่มือการแก้ไขบล็อก.

ความเข้ากันได้กับ Divi 5 / Elementor / Avada

Divi 5 หากคุณเปิดใช้งานตัวเลือกประสิทธิภาพที่ "ปรับแต่ง" ส่วนติดต่อผู้ดูแลระบบ ให้ทดสอบ Gutenberg ในภายหลัง Divi บางครั้งโหลดตัวแก้ไขสินทรัพย์สำหรับโมดูลต่างๆ ให้ยกเว้นตัวแก้ไขเหล่านั้น /wp-admin/ การปรับแต่งเชิงรุก
Elementor แม้ว่า Elementor จะมีตัวแก้ไขของตัวเอง แต่ก็สามารถทำงานร่วมกับแผงควบคุมผู้ดูแลระบบของ WordPress ได้ ปลั๊กอินเพิ่มประสิทธิภาพที่รวมสคริปต์ผู้ดูแลระบบอาจทำให้ Gutenberg และหน้าจอ Elementor ทำงานผิดพลาดได้
Avada Fusion Builder และ Avada Live โหลดสคริปต์ขนาดใหญ่ หากคุณมีกระบวนการแคช/ย่อขนาดไฟล์ที่ส่งผลกระทบต่อพื้นที่ผู้ดูแลระบบ Avada มักจะเป็นโปรแกรมแรกที่เปิดเผยปัญหา

วิธีแก้ปัญหาที่ 3: การแคช ความปลอดภัย และ CSP (นโยบายความปลอดภัยของเนื้อหา) ที่ทำให้การจัดการระบบล้มเหลว

เมื่อผมเห็น Gutenberg ทำงานได้เพียงครึ่งเดียว หรือทำงานได้หลังจากรีเฟรชหน้าเว็บใหม่ทั้งหมด ผมสงสัยว่าอาจเป็นปัญหาเกี่ยวกับแคช และเมื่อผมเห็นข้อความแสดงข้อผิดพลาด "ปฏิเสธการโหลด...เนื่องจากละเมิด CSP" ผมสงสัยว่าอาจเป็นเพราะการตั้งค่าส่วนหัวด้านความปลอดภัยไม่ถูกต้อง

กรณีทั่วไป: การเพิ่มประสิทธิภาพที่ย่อ/รวมไฟล์ผู้ดูแลระบบเข้าด้วยกัน

ปลั๊กอินเพิ่มประสิทธิภาพหลายตัวมีตัวเลือก "เพิ่มประสิทธิภาพพื้นที่ผู้ดูแลระบบด้วย" ใน WordPress 6.9.4 วิธีนี้มักไม่ใช่ความคิดที่ดีนัก เพราะส่วนติดต่อผู้ดูแลระบบเปลี่ยนแปลงอย่างรวดเร็ว ไฟล์แพ็กเกจต่างๆ ได้รับการเพิ่มประสิทธิภาพอยู่แล้ว และมีความเสี่ยงที่จะทำให้การพึ่งพาของปลั๊กอินอื่นๆ เสียหายได้

การกระทำที่เป็นรูปธรรม:

ปิดใช้งานการเพิ่มประสิทธิภาพ JS/CSS บน /wp-admin/.
ยกเว้นอย่างน้อยที่สุด:
- /wp-includes/js/dist/
- /wp-admin/js/
- load-scripts.php et load-styles.php (หากใช้)
ล้างแคช: แคชปลั๊กอิน + แคชเซิร์ฟเวอร์ + CDN + เบราว์เซอร์

กรณีทั่วไป: การกำหนดสถานะทางเศรษฐกิจและสังคมที่เข้มงวดเกินไป

CSP ที่ "มีความปลอดภัยสูง" สามารถบล็อกกลไกที่ผู้เผยแพร่ใช้ได้ (ขึ้นอยู่กับปลั๊กอิน สื่อ iframe ฯลฯ) ข้อผิดพลาดจะปรากฏในคอนโซล ไม่ใช่ใน WordPress

ตัวอย่างข้อผิดพลาดที่แสดงในคอนโซล:

Refused to load the script 'blob:https://example.com/...' because it violates the following Content Security Policy directive...

หากคุณจัดการ CSP ผ่าน PHP (ปลั๊กอินความปลอดภัย, ส่วนหัวแบบกำหนดเอง) ให้ทดสอบโดยการผ่อนปรนข้อจำกัดเฉพาะในส่วนผู้ดูแลระบบเท่านั้น นี่คือตัวอย่าง ต่ำสุด (ต้องปรับและตรวจสอบให้สอดคล้องกับนโยบายความปลอดภัยของคุณ):

<?php
/**
 * Exemple : définir des headers CSP uniquement dans l'admin.
 * Attention : une CSP doit être pensée globalement. Ne copiez pas ceci sans comprendre votre surface d'attaque.
 */
add_action( 'send_headers', function() {

	if ( ! is_admin() ) {
		return;
	}

	// Exemple volontairement simple. Ajustez selon vos besoins.
	// Objectif : éviter de casser des scripts/styles nécessaires à l'éditeur.
	header( "Content-Security-Policy: default-src 'self'; script-src 'self' 'unsafe-inline' 'unsafe-eval' blob:; style-src 'self' 'unsafe-inline'; img-src 'self' data: blob:; connect-src 'self' https:; frame-src 'self';" );
}, 20 );

ทำไมจึงถูกต้อง Gutenberg และส่วนประกอบการจัดการบางอย่างสามารถใช้ URL ได้ blob: / data: (ขึ้นอยู่กับคุณสมบัติและส่วนขยาย) CSP ที่เข้มงวดเกินไปจะบล็อกการโหลด/การประเมิน และแอป JS จะไม่เริ่มต้นทำงาน

ความเสี่ยงด้านความปลอดภัย : 'unsafe-inline' et 'unsafe-eval' วิธีนี้จะเพิ่มความเสี่ยงต่อการโจมตี XSS ซึ่งในอุดมคติแล้ว คุณคงไม่อยากให้เกิดเหตุการณ์เช่นนั้น แต่ในความเป็นจริงแล้ว แพลตฟอร์ม WordPress หลายอย่าง (รวมถึงปลั๊กอิน) ยังไม่พร้อมสำหรับ CSP แบบ "strict-dynamic" ที่สมบูรณ์แบบ ควรใช้ CSP แบบ progressive และโหมดที่เหมาะสมกว่า รายงานอย่างเดียว เพื่อทำซ้ำ

กรณีทั่วไป: ไฟล์จากเวอร์ชันเก่าที่ให้บริการผ่าน CDN/opcache

หลังจากอัปเดต WordPress แล้ว ฉันก็พบปัญหาบางอย่างแล้ว wp-includes/js/dist/* การให้บริการไฟล์จากเวอร์ชันก่อนหน้าผ่าน CDN ทำให้ Gutenberg โหลดไฟล์จากเวอร์ชันที่ไม่เข้ากันหลายเวอร์ชัน

รายการตรวจสอบ:

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

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

เปิดบทความที่มีอยู่แล้วและสร้างบทความใหม่: ทั้งสองหน้าจอควรใช้งานได้
ทดสอบด้วยบัญชี ผู้ดูแลระบบ จากนั้นบัญชี สำนักพิมพ์ (ความสามารถของ REST แตกต่างกันไป)
คอนโซล: ศูนย์ เกิดข้อผิดพลาดสีแดงขณะโหลดครั้งแรก อาจมีคำเตือนบางอย่าง แต่ไม่มีข้อผิดพลาดร้ายแรงที่ทำให้ระบบหยุดทำงาน
เครือข่าย: คำขอ /wp-json/ ต้องเป็นหมายเลข 200 และการตอบกลับต้องอยู่ในรูปแบบ JSON
ทดสอบการเผยแพร่แบบรวดเร็ว: ฉบับร่าง → เผยแพร่ → อัปเดต

หากคุณใช้ Elementor/Divi/Avada โปรดเปิดหน้าจอแก้ไขของโปรแกรมเหล่านั้นด้วย: แพทช์ "ผู้ดูแลระบบ" จะช่วยปรับปรุงภาพรวมทั้งหมด ไม่ใช่แค่ Gutenberg เท่านั้น

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

ขั้นตอนที่ฉันใช้เมื่อปัญหายังคงอยู่ (เรียงตามลำดับนี้ เพราะจะช่วยหลีกเลี่ยงการวนลูป)

1) โหมดแก้ไขปัญหาโดยไม่ส่งผลกระทบต่อผู้เข้าชม

ทำให้สามารถ การตรวจสุขภาพ และใช้ โหมดแก้ไขปัญหา.
ในโหมดนี้ ให้ปิดใช้งานปลั๊กอินทั้งหมด แต่ให้คงธีมไว้
ลองใช้ Gutenberg ดูสิ

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

2) ตรวจสอบบันทึก PHP และข้อผิดพลาด REST

เปิด wp-content/debug.log หลังจากโหลดไม่สำเร็จทันที
ค้นหา: Fatal error, headers already sent, Deprecated (การแสดงผลคำที่เลิกใช้แล้วบางคำอาจทำให้ผลลัพธ์ไม่ถูกต้อง) REST.

หากต้องการทำความเข้าใจข้อผิดพลาด “JSON ไม่ถูกต้อง” เอกสารการแก้ไขข้อผิดพลาดอย่างเป็นทางการอยู่ที่นี่: แก้ไขข้อบกพร่องใน WordPress.

3) ตัวตรวจสอบการสืบค้น: ตรวจสอบข้อผิดพลาดและคำขอ AJAX/REST

Query Monitor แสดงข้อผิดพลาด PHP, hook และบางครั้งก็แสดงการเรียกใช้ HTTP เมื่อแก้ไขปัญหา Gutenberg ผมใช้มันเป็นหลักเพื่อ:

เพื่อระบุคำเตือนที่ปรากฏขึ้นเมื่อมีการร้องขอ REST
ระบุปลั๊กอินที่เป็นต้นเหตุโดยดูจากข้อมูลการติดตามการทำงาน (stack trace)
ตรวจสอบว่าผู้ดูแลระบบกำลังโหลดสคริปต์ที่ไม่คาดคิดหรือไม่

4) ตรวจสอบสถานะการทำงานของเว็บไซต์และขีดจำกัดของเซิร์ฟเวอร์

หน่วยความจำ PHP Gutenberg, เครื่องมือสร้างเว็บไซต์ และปลั๊กอินขนาดใหญ่ อาจก่อให้เกิดปัญหาได้ หน่วยความจำไม่เพียงพออาจทำให้โปรแกรมหยุดทำงานเป็นระยะๆ
ขีดจำกัด : max_input_vars การตั้งค่าต่ำเกินไปอาจส่งผลกระทบต่อหน้าจอบางประเภท (พบได้น้อยใน Gutenberg ที่ไม่มีการปรับแต่งใดๆ แต่พบได้บ่อยใน meta-boxes ที่มีรายละเอียดสูง)
สิทธิ์ หากไฟล์หลักของ WordPress อ่านไม่ได้ คุณจะได้รับข้อผิดพลาด 404/500 บนไฟล์สินทรัพย์

5) การรีเซ็ตลิงก์ถาวร (เกิดขึ้นไม่บ่อย แต่ทำได้รวดเร็ว)

เมื่อ REST ส่งคืนข้อผิดพลาด 404 แม้ว่าไฟล์จะมีอยู่จริง ฉันพบว่ากฎการเขียนใหม่ (rewrite rules) ไม่สอดคล้องกันหลังจากทำการย้ายระบบ

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

6) ตรวจสอบความขัดแย้งของโค้ดตัวอย่าง

ปลั๊กอิน Snippet (หรือ functions.php) เป็นสาเหตุสำคัญ เพราะแค่ข้อผิดพลาดทางไวยากรณ์ง่ายๆ ก็ทำให้ทุกอย่างพังหมด

ตรวจสอบว่ามี "เครื่องหมายเซมิโคลอนหายไป" หรือวงเล็บหรือไม่
ตรวจสอบว่าโค้ดตัวอย่างกำลังทำงานอยู่หรือไม่ init / wp_loaded และสร้าง echo / var_dump.

7) WP-CLI: ตรวจสอบความสมบูรณ์และเวอร์ชัน

ในเว็บไซต์ที่ผมสงสัยว่าการติดตั้งอาจไม่สมบูรณ์ WP-CLI มีประสิทธิภาพมาก:

# Vérifie l'intégrité des fichiers du core WordPress
wp core verify-checksums

# Liste plugins et mises à jour en attente
wp plugin list
wp plugin update --all

# Vérifie la version PHP (vue par WP-CLI)
php -v

เอกสารประกอบการใช้งาน WP-CLI: คำสั่ง WP-CLI.

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

อาการ	สาเหตุที่เป็นไปได้	วิธีแก้ปัญหาที่แนะนำ
แสดงข้อความ “การตอบกลับ JSON ไม่ถูกต้อง” หลังจากเพิ่มโค้ดตัวอย่าง	`echo`/`var_dump` หรือข้อความเตือน PHP ระหว่างการดำเนินการ REST	ลบผลลัพธ์ ใช้ `error_log()`แก้ไขคำเตือน (วิธีแก้ปัญหาที่ 1)
Gutenberg โหลดได้เฉพาะในบางเบราว์เซอร์เท่านั้น	แคชของเบราว์เซอร์/เซอร์วิสเวิร์กเกอร์หรือส่วนขยาย	ทดสอบการเรียกดูแบบส่วนตัว ปิดใช้งานส่วนขยาย และล้างแคช (วิธีที่ 3)
ข้อผิดพลาด JS “wp ไม่ได้ถูกกำหนด”	สคริปต์โหลดเร็วเกินไปหรือโหลดผิดหน้าจอ	เป้า `post.php`/`post-new.php` + ความสัมพันธ์ (วิธีแก้ปัญหาที่ 2)
403 เมื่อ `/wp-json/` เฉพาะในขั้นตอนการผลิตเท่านั้น	WAF/CDN, กฎ ModSecurity, การตรวจสอบสิทธิ์แบบ Basic Auth	เพิ่ม REST/admin-ajax ลงในรายการที่อนุญาต, บันทึก WAF, ข้ามขั้นตอน (วิธีที่ 1)
หลังจากปิดใช้งานแคชแล้วก็ใช้งานได้ แต่หลังจากนั้นก็ใช้งานไม่ได้อีกครั้ง	ปลั๊กอินเพิ่มประสิทธิภาพแบบตอบสนอง “minify admin”	ไม่รวม `/wp-admin/` และชุด WP (วิธีแก้ปัญหาที่ 3)
เกิดข้อผิดพลาดหลังการอัปเดต WordPress ไฟล์ JavaScript แสดงข้อผิดพลาด 404	การติดตั้งไม่สมบูรณ์ / CDN ยังคงให้บริการเวอร์ชันเก่าอยู่	ล้าง CDN + `wp core verify-checksums` (วิธีแก้ปัญหาที่ 3)
โค้ดนั้น "อยู่ในตำแหน่งที่ถูกต้อง" แต่ใช้งานไม่ได้	คัดลอกไปยังไฟล์ที่ไม่ถูกต้อง (ปลั๊กอินเทียบกับธีมลูก) หรือใช้ hook ที่ไม่เหมาะสม	เพิ่มลงในปลั๊กอิน MU ตรวจสอบ hook และลำดับความสำคัญ
ฟังก์ชันนี้จะทำงานเฉพาะเมื่อใช้งานในบทบาทบรรณาธิการเท่านั้น	ความสามารถของ REST/nonce, ปลั๊กอินบทบาท	ทดสอบเส้นทาง REST ด้วยบทบาทนี้ และตรวจสอบความสามารถที่ถูกต้อง

ข้อผิดพลาดที่ฉันมักเห็นในกลุ่มผู้ใช้งานระดับกลาง:

ทดสอบโดยตรงบนระบบใช้งานจริงโดยไม่มีข้อมูลสำรอง จากนั้น "ซ่อมแซม" อย่างเร่งด่วน
เพิ่มโค้ดตัวอย่างที่พบในบทช่วยสอนเก่า (ก่อนเวอร์ชัน 6.x) ซึ่งบล็อกการใช้งาน REST "เพื่อความปลอดภัย"
ลืมล้างแคช CDN หลังจากอัปเดต WordPress
การใช้ hook ที่ครอบคลุมมากเกินไป (เช่น init) เพื่อพิมพ์ HTML หรือโหลด JS
ย่อ/รวมเนื้อหาของหน้าผู้ดูแลระบบ "เพื่อประหยัดเวลา 0,2 วินาที" และลบส่วนแก้ไขข้อความออกไป

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

วิธีการไม่ต้องเขียนโค้ด: แยกผู้ป่วยด้วยการตรวจสอบสุขภาพ + ย้อนกลับการรักษาอย่างเป็นระบบ

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

วิธีการขั้นสูงกว่า: ปลั๊กอิน MU “safeguard” สำหรับบันทึกข้อผิดพลาดของ REST

เมื่อเว็บไซต์มีความซับซ้อน (Avada + Elementor + ระบบรักษาความปลอดภัย + แคช) บางครั้งผมจะติดตั้งปลั๊กอิน MU ชั่วคราวเพื่อบันทึกข้อผิดพลาด REST โดยไม่ทำให้ระบบที่ใช้งานจริงหยุดชะงัก

<?php
/**
 * Plugin Name: MU - Debug REST pour éditeur de blocs
 * Description: Journalise les erreurs REST (temporaire) pour diagnostiquer Gutenberg.
 * Author: Votre équipe
 * Version: 1.0.0
 *
 * À placer dans wp-content/mu-plugins/mu-debug-rest.php
 */

add_filter( 'rest_request_after_callbacks', function( $response, $handler, $request ) {

	// Ne loguez que si WP_DEBUG est actif pour éviter du bruit en prod.
	if ( ! defined( 'WP_DEBUG' ) || ! WP_DEBUG ) {
		return $response;
	}

	if ( is_wp_error( $response ) ) {
		error_log( '[REST][WP_Error] route=' . $request->get_route() . ' code=' . $response->get_error_code() . ' message=' . $response->get_error_message() );
		return $response;
	}

	if ( $response instanceof WP_REST_Response ) {
		$status = $response->get_status();
		if ( $status >= 400 ) {
			error_log( '[REST][HTTP ' . $status . '] route=' . $request->get_route() );
		}
	}

	return $response;
}, 10, 3 );

ระบบป้องกันนี้ช่วยเชื่อมโยงหน้าจอ Gutenberg ที่เสียหายกับเส้นทาง REST ที่แม่นยำ

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

อย่าบล็อก REST ทั่วโลกหากคุณต้องการเพิ่มความปลอดภัย ให้ดำเนินการโดยใช้เส้นทาง บทบาท และบริบท ทดสอบสิทธิ์ผู้ดูแลระบบหลังจากทำการเปลี่ยนแปลงแต่ละครั้ง
อย่าปรับแต่งส่วนผู้ดูแลระบบ (ย่อขนาด/รวม/เลื่อนเวลา) ยกเว้นในกรณีที่มีการควบคุมอย่างเข้มงวด ผลประโยชน์มีน้อย ความเสี่ยงมหาศาล
โหลดสคริปต์ผู้ดูแลระบบของคุณให้ถูกต้อง :
- การกำหนดเป้าหมายหน้าจอ ($hook_suffix + get_current_screen()),
- การพึ่งพา wp-* ประกาศ
- การกำหนดเวอร์ชันที่เชื่อถือได้ (filemtime ในสภาพแวดล้อมที่เรียบง่าย)
ตรวจสอบคำเตือน PHP ใน PHP เวอร์ชัน 8.1 ขึ้นไป รูปแบบบางอย่างจะทำให้เกิดคำเตือน/การเลิกใช้งานมากขึ้น คำเตือนที่แสดงอาจทำให้ JSON เสียหายได้
กระบวนการอัปเดต : ขั้นตอนการทดสอบ → ล้างแคช → ขั้นตอนการใช้งานจริง และหลังจากอัปเดต WordPress แล้ว ให้ทำการล้างแคช CDN อย่างเป็นระบบ
ส่วนหัวด้านความปลอดภัย : ปรับใช้ CSP ใน รายงานอย่างเดียว ขั้นแรก ค่อยๆ ปรับปรุงให้รัดกุมขึ้นทีละน้อย มิเช่นนั้น คุณจะ "ทำให้ระบบจัดการผู้ดูแลระบบพัง" เมื่อปลั๊กอินตัวต่อไปเพิ่ม iframe หรือ blob เข้ามา

แหล่งข้อมูลอ้างอิงที่เป็นประโยชน์สำหรับ PHP: การกำหนดค่าการจัดการข้อผิดพลาด PHP.

ทรัพยากร

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

เหตุใด Gutenberg จึงแสดงข้อความ “การตอบกลับไม่ใช่การตอบกลับ JSON ที่ถูกต้อง”?

เนื่องจากคำขอ REST คาดหวังข้อมูล JSON แต่ได้รับข้อมูลอื่น (เช่น ข้อผิดพลาด 403/500 ในรูปแบบ HTML, คำเตือน PHP หรือผลลัพธ์ที่ไม่ต้องการ) ลองเปิดดูการตอบสนองในแท็บ Network คุณมักจะเห็นสาเหตุได้ทันที

การปิดใช้งาน REST API "ด้วยเหตุผลด้านความปลอดภัย" เป็นวิธีปฏิบัติที่ดีหรือไม่?

ไม่ ไม่ใช่ทั่วทั้งระบบ WordPress (และ Gutenberg) ใช้ภายในอยู่แล้ว หากคุณต้องการเพิ่มความปลอดภัย ให้ทำทีละเส้นทางและในขณะที่ยังคงรักษาฟังก์ชันการทำงานของแผงควบคุมผู้ดูแลระบบไว้ ทดสอบอย่างเป็นระบบ /wp-json/wp/v2/types/post?context=edit เชื่อมต่อ

ทำไมถึงใช้ได้กับผู้ดูแลระบบ แต่ใช้ไม่ได้กับผู้แก้ไข?

ความสามารถแตกต่างกัน และปลั๊กอินบทบาท/ความปลอดภัยบางตัวจะกรอง REST ตามบทบาท ทดสอบด้วยบัญชีที่เกี่ยวข้องและตรวจสอบข้อผิดพลาด 403 บนเส้นทาง REST ในบริบทนั้น edit.

ปลั๊กอินแคชสามารถทำให้ Gutenberg ใช้งานไม่ได้หรือไม่?

ใช่ โดยเฉพาะอย่างยิ่งหากมีการแคชปลายทาง REST ที่ได้รับการตรวจสอบสิทธิ์ หรือหากมีการปรับปรุง/ย่อขนาดสคริปต์ผู้ดูแลระบบ ยกเว้น /wp-admin/ et /wp-json/ กฎการแคชที่เข้มงวด

ฉันควรทำอย่างไรหากได้รับข้อผิดพลาด 500 เฉพาะใน REST route เท่านั้น?

โดยส่วนใหญ่แล้วนี่คือการเรียกใช้ฟังก์ชัน PHP ที่ผิดพลาดซึ่งเกิดขึ้นระหว่างการร้องขอครั้งนี้ เปิดใช้งาน WP_DEBUG_LOGทำซ้ำ แล้วดู debug.logQuery Monitor ช่วยระบุปลั๊กอิน/ธีมที่เป็นต้นเหตุของปัญหา

Divi 5 / Elementor / Avada เข้ากันได้กับ Gutenberg หรือไม่

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

การ "บันทึกลิงก์ถาวรอีกครั้ง" จะช่วยได้ไหม?

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

ฉันสามารถ "แก้ไขปัญหา Gutenberg" โดยการโหลด jQuery ใหม่หรือเพิ่มโค้ด JavaScript แบบกำหนดเองได้หรือไม่?

นี่เป็นเพียงวิธีแก้ปัญหาชั่วคราวที่ปกปิดปัญหาที่แท้จริง (เซิร์ฟเวอร์ REST เสีย, สคริปต์ขัดแย้งกัน) ควรแก้ไขที่ต้นเหตุ: การบล็อก REST, การจัดคิวที่ผิดพลาด, ปัญหาแคช/CDN หรือ PHP ที่มีข้อผิดพลาดร้ายแรง

เมื่อ Gutenberg assets แสดงข้อผิดพลาด 404 ฉันควรตรวจสอบไฟล์ใดบ้าง?

ดูที่ URL เหล่านั้น wp-includes/js/dist/ et wp-includes/css/dist/ข้อผิดพลาด 404 อาจบ่งชี้ว่าการติดตั้งไม่สมบูรณ์ หรือ CDN ให้บริการเวอร์ชันเก่ากว่า wp core verify-checksums ช่วยได้มาก

ฉันเห็นข้อความ “ไม่สามารถโหลดได้… ละเมิดนโยบายความปลอดภัยของเนื้อหา” ฉันควรทำอย่างไร?

ผ่อนปรนข้อกำหนด CSP สำหรับผู้ดูแลระบบ โดยควรทำดังนี้ รายงานอย่างเดียว ขั้นแรก ตรวจสอบแนวทางปฏิบัติก่อน script-src, style-src, connect-srcและการอนุญาตของ blob:/data: ถ้าจำเป็น ให้ทำทีละน้อยเพื่อลดความเสี่ยงจากช่องโหว่ XSS

Gutenberg มีปัญหา: แก้ไขปัญหาตัวแก้ไขบล็อกของ WordPress

มีปัญหา

สรุปด่วน

มีอาการ

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

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

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

วิธีแก้ปัญหาที่ 1: REST API ถูกบล็อก (403/401/500) และ Gutenberg ไม่สามารถเริ่มต้นทำงานได้อีกต่อไป

การวินิจฉัย

กรณีทั่วไป: ปลั๊กอินปิดกั้นการเข้าถึง REST ผ่านตัวกรองที่เข้มงวดเกินไป

ด้านหน้า (ชำรุด)

หลังจาก (การแก้ไขและการจำกัดเป้าหมาย)

กรณีทั่วไป: ข้อความเตือน "การตอบสนอง JSON ไม่ถูกต้อง" จาก PHP

ด้านหน้า (ชำรุด)

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

กรณีทั่วไป: การบล็อกโดย WAF/CDN (403, การตรวจสอบสิทธิ์แบบท้าทาย, การตรวจสอบสิทธิ์พื้นฐาน)

วิธีแก้ปัญหาที่ 2: สคริปต์ตัวแก้ไขที่เสียหาย (การจัดคิว การพึ่งพา ลำดับการโหลด)

การวินิจฉัย

ตัวอย่างทั่วไป: การสำรวจระดับโลกเกี่ยวกับ admin_enqueue_scripts โดยไม่ต้องกำหนดเป้าหมายไปที่หน้าจอ

ด้านหน้า (ชำรุด)

หลังจาก (แก้ไขแล้ว: การกำหนดเป้าหมาย + การพึ่งพา + การกำหนดเวอร์ชัน)

กรณีทั่วไป: ปลั๊กอินโหลด React/ReactDOM ด้วยตนเอง

ด้านหน้า (ชำรุด)

หลังจาก (แก้ไข: ใช้แพ็กเกจ WordPress)

ความเข้ากันได้กับ Divi 5 / Elementor / Avada

วิธีแก้ปัญหาที่ 3: การแคช ความปลอดภัย และ CSP (นโยบายความปลอดภัยของเนื้อหา) ที่ทำให้การจัดการระบบล้มเหลว

กรณีทั่วไป: การเพิ่มประสิทธิภาพที่ย่อ/รวมไฟล์ผู้ดูแลระบบเข้าด้วยกัน

กรณีทั่วไป: การกำหนดสถานะทางเศรษฐกิจและสังคมที่เข้มงวดเกินไป

กรณีทั่วไป: ไฟล์จากเวอร์ชันเก่าที่ให้บริการผ่าน CDN/opcache

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

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

1) โหมดแก้ไขปัญหาโดยไม่ส่งผลกระทบต่อผู้เข้าชม

2) ตรวจสอบบันทึก PHP และข้อผิดพลาด REST

3) ตัวตรวจสอบการสืบค้น: ตรวจสอบข้อผิดพลาดและคำขอ AJAX/REST

4) ตรวจสอบสถานะการทำงานของเว็บไซต์และขีดจำกัดของเซิร์ฟเวอร์

5) การรีเซ็ตลิงก์ถาวร (เกิดขึ้นไม่บ่อย แต่ทำได้รวดเร็ว)

6) ตรวจสอบความขัดแย้งของโค้ดตัวอย่าง

7) WP-CLI: ตรวจสอบความสมบูรณ์และเวอร์ชัน

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

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

วิธีการไม่ต้องเขียนโค้ด: แยกผู้ป่วยด้วยการตรวจสอบสุขภาพ + ย้อนกลับการรักษาอย่างเป็นระบบ

วิธีการขั้นสูงกว่า: ปลั๊กอิน MU “safeguard” สำหรับบันทึกข้อผิดพลาดของ REST

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

ทรัพยากร

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

เหตุใด Gutenberg จึงแสดงข้อความ “การตอบกลับไม่ใช่การตอบกลับ JSON ที่ถูกต้อง”?

การปิดใช้งาน REST API "ด้วยเหตุผลด้านความปลอดภัย" เป็นวิธีปฏิบัติที่ดีหรือไม่?

ทำไมถึงใช้ได้กับผู้ดูแลระบบ แต่ใช้ไม่ได้กับผู้แก้ไข?

ปลั๊กอินแคชสามารถทำให้ Gutenberg ใช้งานไม่ได้หรือไม่?

ฉันควรทำอย่างไรหากได้รับข้อผิดพลาด 500 เฉพาะใน REST route เท่านั้น?

Divi 5 / Elementor / Avada เข้ากันได้กับ Gutenberg หรือไม่

การ "บันทึกลิงก์ถาวรอีกครั้ง" จะช่วยได้ไหม?

ฉันสามารถ "แก้ไขปัญหา Gutenberg" โดยการโหลด jQuery ใหม่หรือเพิ่มโค้ด JavaScript แบบกำหนดเองได้หรือไม่?

เมื่อ Gutenberg assets แสดงข้อผิดพลาด 404 ฉันควรตรวจสอบไฟล์ใดบ้าง?

ฉันเห็นข้อความ “ไม่สามารถโหลดได้… ละเมิดนโยบายความปลอดภัยของเนื้อหา” ฉันควรทำอย่างไร?

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

ส่งความคิดเห็น ยกเลิกการตอบ

ตัวอย่างทั่วไป: การสำรวจระดับโลกเกี่ยวกับ `admin_enqueue_scripts` โดยไม่ต้องกำหนดเป้าหมายไปที่หน้าจอ