غوتنبرغ عالق: إصلاح محرر ووردبريس

إذا سبق لك أن رأيت محرر الكتل يتوقف عند عبارة "جارٍ التحميل..." أو يعرض رسالة "واجه المحرر خطأً غير متوقع"، فمن المحتمل أن لديك مشكلة في واجهة برمجة تطبيقات REST، أو نصوص إدارة النظام، أو التخزين المؤقت/الأمان. في ووردبريس 6.9.4 (أبريل 2026)، يعتمد غوتنبرغ بشكل أكبر من ذي قبل على واجهة إدارة سلسة: واجهات برمجة تطبيقات REST، ورموز 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)، وغالبًا مباشرة بعد ذلك:

تحديث لملحق الأمان/التخزين المؤقت،
تغيير في قاعدة جدار الحماية لتطبيقات الويب/شبكة توصيل المحتوى (Cloudflare، Sucuri، ModSecurity)،
إضافة جزء برمجي "ينظف" كود HTML،
عملية نقل البيانات (عنوان URL، HTTPS، وكيل عكسي)،
أو تحديث قالب (Avada) / أداة إنشاء الصفحات (Elementor، Divi 5) التي تضيف نصوصًا برمجية للمسؤول.

هذا الدليل مخصص للمستخدمين ذوي الخبرة المتوسطة: أنتم تعرفون كيفية فتح وحدة التحكم، وقراءة سجلات النظام، وتثبيت إضافة MU، واستخدام WP-CLI. بنهاية هذا الدليل، ستتمكنون من تحديد سبب المشكلة (REST، جافا سكريبت، ذاكرة التخزين المؤقت، الأمان، PHP) وتطبيق حل جذري متوافق مع ووردبريس 6.9.4 والإصدارات الأحدث وPHP 8.1 والإصدارات الأحدث.

ملخص سريع

ابدأ بوحدة التحكم : الخطأ يُملي الخطأ visible (403 REST, invalid JSON, JS file 404) الباقي.
اختبار الراحة الفوري : /wp-json/wp/v2/types/post?context=edit أثناء تسجيل الدخول، ثم قارن مع حساب المسؤول.
قم بتعطيل التداخل : إضافات الأمان/التخزين المؤقت، والمقتطفات، وتحسين JS/CSS، وشبكة توصيل المحتوى (CDN)، ثم أعد تنشيطها واحدة تلو الأخرى.
تفعيل تنظيف السجلات : WP_DEBUG_LOG + استعلم عن المراقب، وابحث عن "REST" و "nonce" و "headers already sent" و "fatal".
لا تقم "بإصلاح" غوتنبرغ باستخدام jQuery معظم حالات الفشل تأتي من عملية إضافة أو تصفية تقوم بتعديل استجابات JSON.
إذا كنت تستخدم برنامج بناء إضافة أصول الإدارة في Divi 5/Elementor/Avada؛ يحدث تعارض في التحسين أو الأمان بشكل متكرر.

الأعراض

فيما يلي الأعراض التي أراها في أغلب الأحيان (من الأكثر شيوعاً إلى الأكثر "صعوبة").

شاشة بيضاء في المحرر مع دوار لا نهائي.
رسالة واجهة المستخدم "واجه الناشر خطأً غير متوقع."
خطأ في النشر "فشل التحديث. الاستجابة ليست استجابة JSON صالحة."
وحدة تحكم المتصفح (F12 → وحدة التحكم / الشبكة):
- 403/401 على /wp-json/... (غالباً ما تكون قاعدة جدار حماية تطبيقات الويب أو قاعدة أمنية)،
- خطأ 500 على مسار REST (خطأ فادح في PHP على جانب الخادم)،
- خطأ 404 في الملف wp-includes/js/dist/*.min.js (ذاكرة التخزين المؤقت/شبكة توصيل المحتوى أو النشر غير المكتمل)،
- أخطاء CORS أو CSP (رؤوس أمان صارمة للغاية)،
- Unexpected token < in JSON (تم إدخال HTML في استجابة JSON، وعادة ما تكون تحذير PHP أو صفحة HTML 403).
يعمل محليًا ولكنه لا يعمل في بيئة الإنتاج : شبكة توصيل المحتوى (CDN)، التخزين المؤقت المكثف، جدار حماية تطبيقات الويب (WAF)، أو الاختلافات في PHP/الإضافات.
إنه يعمل مع المدير، لكنه لا يعمل مع المحرر. : القدرات، أو القيم العشوائية، أو المكونات الإضافية التي تقوم بالتصفية وفقًا للدور.
لا ينكسر إلا في اختبار CPT : show_in_rest مفقود، أو مسار REST مخصص وهو أمر كارثي.

مخطط التشخيص السريع

عرض	السبب المحتمل	التحقق	الحلول
"استجابة JSON غير صالحة"	تم حقن HTML/warning في REST	افتح استجابة الشبكة لـ `/wp-json/...`	تعطيل الملحق/المقتطف، صحيح للاطلاع على التحذيرات، انظر الحل 1
403 في `/wp-json/`	جدار حماية تطبيقات الويب، قاعدة الأمان، المصادقة الأساسية	اختبار REST في وضع التصفح الخاص + سجلات جدار حماية تطبيقات الويب	قم بإضافة عناوين REST المسموح بها إلى القائمة البيضاء، راجع الحل 1
مؤشر تحميل لا نهائي، أخطاء جافا سكريبت	قائمة انتظار الإدارة المعطلة / تحسين جافا سكريبت	وحدة التحكم: "لا يمكن قراءة خصائص غير مُعرَّف"	لتصحيح أضف الأصول إلى قائمة الانتظار، واستبعدها، راجع الحل 2
404 في `wp-includes/js/dist/`	عملية نشر غير مكتملة / ذاكرة تخزين مؤقتة لشبكة توصيل المحتوى	اختبر ذلك عن طريق تعطيل شبكة توصيل المحتوى (CDN) ومسح ذاكرة التخزين المؤقت.	التطهير وإعادة التوزيع، انظر الحل 3
500 على طريق استراحة	خطأ فادح في PHP (إضافة/قالب)	سجل تصحيح الأخطاء WP_DEBUG_LOG + مراقب الاستعلامات	لتصحيح الأخطاء الفادحة، قم بالتراجع، انظر الحل 1

لماذا وصلت؟

ببساطة: محرر الكتل هو تطبيق جافا سكريبت يتواصل باستمرار مع موقعك الإلكتروني عبر واجهة برمجة تطبيقات REST. إذا أعاد REST أي بيانات غير JSON سليمة (أو إذا فشلت البرامج النصية اللازمة في التحميل)، فلن يتمكن المحرر من تهيئة حالته.

إليكم ما يحدث خلف الكواليس (النسخة التقنية):

يقوم غوتنبرغ بتحميل الحزم من wp-includes/js/dist/ وأنماط الإدارة.
يسترجع البيانات عبر نقاط نهاية REST (الأنواع، التصنيفات، إعدادات، الحفظ التلقائي، عن أهمية خطة العمل وتحديد أهداف مشروعك.، وما إلى ذلك).
يرسل طلبات موثقة باستخدام رموز عشوائية (nonce). إذا قام أحد المكونات الإضافية بتعديل الرؤوس، أو حظر المسارات، أو تخزين استجابات "تعديل السياق" مؤقتًا، فسيتعطل.
تحذير PHP، أو "ملاحظة"، أو حتى مسافة قبل <?php قد يكون ذلك كافياً لتلويث استجابة JSON.

الأسباب المحتملة (من الأكثر شيوعاً إلى الأقل شيوعاً):

حظر REST بواسطة الأمان/التخزين المؤقت/شبكة توصيل المحتوى (CDN) (403، تحدي، مصادقة أساسية، قاعدة ModSecurity).
استجابة REST ملوثة بسبب تحذير PHP، var_dump()أو إضافة تقوم بطباعة HTML.
تحسين جافا سكريبت/سي إس إس والذي يجمع/يصغر ملفات الإدارة (أو "يؤجل" نصوص ووردبريس).
قائمة انتظار إدارية مصممة بشكل سيئ (التبعيات المفقودة، خطاف غير مناسب، التحميل العام على جميع الصفحات).
رؤوس أمان CSP متشدد للغاية (يحظر) blob:, data:أو النصوص/الأنماط المتوقعة).
عدم اتساق ذاكرة التخزين المؤقت (عامل الخدمة، ذاكرة التخزين المؤقت للمتصفح، ذاكرة التخزين المؤقت للكائنات، شبكة توصيل المحتوى) التي تقدم الأصول من إصدار آخر.
مشاكل في الخادم (أذونات الملفات، النشر غير المكتمل، ذاكرة التخزين المؤقت opcache، امتداد PHP مفقود).

المتطلبات الأساسية قبل البدء

حماية الملفات + قاعدة البيانات (أو لقطة إذا كنت تستخدم خدمة استضافة مُدارة). لا تختبر بشكل عشوائي في بيئة الإنتاج.
بيئة الاختبار : من الأفضل أن تكون مرحلة تجريبية، أو على الأقل فترة صيانة.
إصدارات يُنصح باستخدام ووردبريس 6.9.4 و PHP 8.1+. سجّل الدخول الأدوات ← صحة الموقع.
إضافات مفيدة :
- مراقبة الاستعلام (الاستعلامات، أخطاء PHP، الخطافات، 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 يتم تفعيلها بشكل دائم على موقع عام. يمكن أن تحتوي السجلات على مسارات وطلبات وحتى معلومات حساسة.

الحل الأول: واجهة برمجة تطبيقات REST محظورة (403/401/500) ولم يعد بإمكان Gutenberg بدء التشغيل

عندما يفشل تحميل غوتنبرغ، أبدأ دائمًا بطلب REST بسيط. لأنه إذا تعطل REST، مهما حاولت إصلاح جميع البرامج النصية في العالم، سيظل المحرر غير مستقر.

تشخيصي

افتح المحرر كمسؤول، ثم اضغط على F12 → tab RESEAU.
الفلتر قيد التشغيل wp-json.
حدد أول استعلام خطأ (غالباً types, settings, posts).
انقر على الاستعلام ← عرض إجابة :
- إذا رأيت HTML (صفحة خطأ، تحدي، تسجيل دخول)، فقد وجدته.
- إذا رأيت خطأً في ملف JSON الخاص بـ WordPress، فقم بتدوينه. code et message.

اختبار سريع عبر سطر الأوامر (إذا كنت تستخدم WP-CLI مع ملفات تعريف الارتباط/الرقم العشوائي، فسيكون الأمر أكثر تعقيدًا). لإجراء اختبار بسيط، قم بتشغيله في المتصفح أثناء تسجيل الدخول:

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

إذا تلقيت خطأ 403/401، أو خطأ في صفحة HTML، فإن السبب يكون دائمًا تقريبًا خارج نطاق WordPress (جدار حماية تطبيقات الويب، أو مكون إضافي للأمان، أو المصادقة الأساسية، أو الخادم الوكيل العكسي).

الحالة الشائعة: يقوم أحد المكونات الإضافية بحظر REST عبر مرشح مفرط في التشدد

لقد صادفت في كثير من الأحيان مقتطفات تقوم "بتعطيل واجهة برمجة تطبيقات REST" لأسباب أمنية، لكنها تعطل المحرر (وأحيانًا 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;
} );

لماذا يتم تصحيحه؟ يستدعي غوتنبرغ نقاط نهاية REST في السياق edit والتي تتطلب جلسة اتصال. إن حظر REST "بشكل عام" يعادل قطع اتصال واجهة برمجة التطبيقات الداخلية للناشر.

نقطة اليقظة يجب أن يكون هذا النوع من المرشحات دقيقًا. يتم الحظر بناءً على "وجود" /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 بيانات JSON دقيقة. أي حرف مُخرَج (تحذير، BOM، صدى) يُعطّل تحليل JSON في جانب المتصفح.

الحالة الشائعة: حظر جدار الحماية لتطبيقات الويب/شبكة توصيل المحتوى (403، تحدي، مصادقة أساسية)

إذا كانت استجابة 403 عبارة عن صفحة HTML "تم رفض الوصول" أو تحدٍ، فإن WordPress ليست مسؤولة.

قم بتعطيل جدار الحماية لتطبيقات الويب/شبكة توصيل المحتوى مؤقتًا (أو التبديل إلى "وضع المطور").
السماح صراحةً /wp-json/ et /wp-admin/admin-ajax.php.
إذا كنت قد فعّلت المصادقة الأساسية في وضع الاختبار، فقد يفشل استخدام غوتنبرغ تبعًا لإعدادات متصفحك. في هذه الحالة، اسمح لعنوان IP الخاص بالمسؤول بالوصول، أو عطّل المصادقة الأساسية مؤقتًا أثناء التحرير.

لفهم عقد REST من جانب WordPress، تجدون الوثائق الرسمية هنا: دليل واجهة برمجة تطبيقات REST.

الحل الثاني: نصوص المحرر المعطوبة (الإضافة إلى قائمة الانتظار، والتبعيات، وترتيب التحميل)

السيناريو الكلاسيكي الثاني: يقوم قالب أو إضافة بتحميل نص برمجي في لوحة التحكم، ولكن:

على الخطاف الخطأ،
بدون تبعيات،
أو عن طريق تجاوز مكتبة (React، lodash) التي يوفرها WordPress بالفعل.

النتيجة: أخطاء جافا سكريبت من النوع wp is not defined, Cannot read properties of undefinedأو تحطم صامت.

تشخيصي

F12 → وحدة التحكم: لاحظ العرض الأول الخطأ (ليس الخامس عشر). غالباً ما يكون الخطأ الأول هو السبب.
F12 → الشبكة: البحث عن ملف JS مع خطأ 404/محظور.
قم بتعطيل إضافات التحسين (التصغير/الدمج/التأجيل) التي تؤثر على لوحة التحكم الإدارية بشكل مؤقت.

حالة شائعة: دراسة استقصائية عالمية حول `admin_enqueue_scripts` دون استهداف الشاشة

كثيراً ما أرى برنامجاً نصياً "للمسؤول" مُحمّلاً في كل مكان، وهو يفترض وجود 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
	);
} );

لماذا يتم تصحيحه؟ تتجنب بذلك ازدحام لوحة التحكم بالكامل، ولا تقوم بالتحميل إلا في الأماكن التي يتوفر فيها غوتنبرغ، وتُعلن عن التبعيات الثابتة. التحكم في الإصدارات بواسطة filemtime() كما أنه يتجنب وجود ذاكرات تخزين مؤقتة "وهمية" بعد النشر.

الحالة الشائعة: يقوم أحد المكونات الإضافية بتحميل React/ReactDOM يدويًا

إذا كانت إحدى الإضافات تتضمن نسختها الخاصة من React (أو تقوم بتحميلها عبر شبكة توصيل المحتوى CDN) في لوحة التحكم، فقد تواجه أخطاءً يصعب تشخيصها، خاصةً بعد تحديث ووردبريس. يوفر ووردبريس بالفعل الحزم اللازمة للمحرر.

الواجهة (مكسورة)

<?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 );
} );

بعد (تم التصحيح: استخدام حزم ووردبريس)

<?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

ديفي 5 إذا قمتَ بتفعيل خيارات الأداء التي "تُحسّن" واجهة الإدارة، فاختبر Gutenberg بعد ذلك. يُحمّل Divi أحيانًا مُحرّرات الأصول لوحداته؛ لذا استبعدها. /wp-admin/ تحسينات مكثفة.
Elementor على الرغم من أن Elementor يمتلك محررًا خاصًا به، إلا أنه يتكامل مع لوحة تحكم WordPress. قد يؤدي استخدام إضافة تحسين تجمع بين نصوص إدارة الموقع إلى تعطيل Gutenberg وشاشة Elementor.
فتح يقوم كل من Fusion Builder و Avada Live بتحميل نصوص برمجية ثقيلة. إذا كانت لديك عملية تخزين مؤقت/تصغير تؤثر على منطقة الإدارة، فغالبًا ما يكون Avada أول من يكشف المشكلة.

الحل الثالث: التخزين المؤقت، والأمان، وسياسة أمان المحتوى (CSP) التي تُعطّل عمل المسؤول

عندما أرى أن غوتنبرغ يعمل في نصف الأوقات فقط، أو بعد تحديث الصفحة بالكامل، أشك في وجود مشكلة في ذاكرة التخزين المؤقت. وعندما أرى رسائل خطأ "تم رفض التحميل... لأنه ينتهك سياسة أمان المحتوى"، أشك في وجود إعدادات غير سليمة لرؤوس الأمان.

الحالة الشائعة: التحسين الذي يقلل حجم/يدمج لوحة التحكم

تتضمن العديد من إضافات تحسين الأداء خيار "تحسين منطقة الإدارة أيضًا". في ووردبريس 6.9.4، غالبًا ما يكون هذا خيارًا غير مُجدٍ: إذ تتغير واجهة الإدارة بسرعة، وتكون الحزم مُحسّنة بالفعل، كما أن خطر تعطيل التبعيات قائم.

العمل الملموس:

تعطيل تحسين جافا سكريبت/سي إس إس /wp-admin/.
استبعد على الأقل:
- /wp-includes/js/dist/
- /wp-admin/js/
- load-scripts.php et load-styles.php (في حال استخدامه)
مسح: ذاكرة التخزين المؤقت للملحقات + ذاكرة التخزين المؤقت للخادم + شبكة توصيل المحتوى + المتصفح.

الحالة الشائعة: الوضع الاجتماعي والاقتصادي المتشدد للغاية

يمكن لسياسة أمان المحتوى "عالية الأمان" حظر الآليات التي يستخدمها الناشر (بحسب الإضافات والوسائط والإطارات المضمنة، إلخ). تظهر الأخطاء في وحدة التحكم، وليس في ووردبريس.

مثال على خطأ في وحدة التحكم:

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: (بحسب الميزات والإضافات). يؤدي تقييد سياسة أمان المحتوى بشكل مفرط إلى منع التحميل/التقييم، وبالتالي لا يبدأ تطبيق جافا سكريبت.

مخاطر أمنية : 'unsafe-inline' et 'unsafe-eval' يزيد هذا من خطر هجمات البرمجة النصية عبر المواقع (XSS). من الناحية المثالية، لا ترغب في ذلك. ولكن في الواقع، العديد من منصات ووردبريس (بما في ذلك الإضافات) غير جاهزة لتطبيق سياسة أمان المحتوى (CSP) "الديناميكية الصارمة" المثالية. استخدم سياسة أمان المحتوى التدريجية والوضع تقرير فقط للتكرار.

الحالة الشائعة: الأصول من إصدار أقدم يتم تقديمها عبر شبكة توصيل المحتوى/ذاكرة التخزين المؤقت للعمليات

بعد تحديث ووردبريس، رأيت بالفعل بعض wp-includes/js/dist/* يقوم برنامج Gutenberg بتحميل مزيج من الإصدارات غير المتوافقة من خلال خدمة الملفات من إصدار سابق عبر شبكة توصيل المحتوى (CDN).

قائمة التحقق:

قم بمسح شبكة توصيل المحتوى (وليس فقط ذاكرة التخزين المؤقت للملحقات).
قم بمسح ذاكرة التخزين المؤقت لـ PHP إذا كان لديك حق الوصول (أو أعد تشغيل PHP-FPM).
تأكد من تحميل عملية النشر بنجاح. جميع ملفات ووردبريس (خاصة عبر بروتوكول نقل الملفات الآمن اليدوي).

عمليات التحقق بعد التصحيح

افتح مقالاً موجوداً وأنشئ مقالاً جديداً: يجب أن تعمل كلتا الشاشتين.
اختبر باستخدام حساب إداري ثم حساب الناشر (تختلف إمكانيات REST).
وحدة التحكم: صفر خطأ أحمر عند التحميل الأولي. قد تظهر بعض التحذيرات، ولكن لا يوجد خطأ يعيق التحميل.
الشبكة: الطلبات /wp-json/ يجب أن يكون رمز الاستجابة 200، ويجب أن تكون الاستجابة بتنسيق JSON.
اختبار النشر السريع: مسودة ← نشر ← تحديث.

إذا كنت تستخدم Elementor/Divi/Avada، فافتح أيضًا شاشات التحرير الخاصة بهم: يجب أن يؤدي تصحيح "المسؤول" إلى تحسين كل شيء، وليس فقط Gutenberg.

إذا لم ينجح ذلك أيضاً

الإجراء الذي أطبقه عندما تستمر المشكلة (بهذا الترتيب، لأنه يتجنب الدوران في حلقة مفرغة).

1) وضع استكشاف الأخطاء وإصلاحها دون التأثير على الزوار

مكن الصحة تحقق و استخدم وضع استكشاف الأخطاء وإصلاحها.
قم بتعطيل جميع الإضافات في هذا الوضع، مع إبقاء القالب نشطًا.
جرب غوتنبرغ.

إذا نجح ذلك، فأعد تنشيط المكونات الإضافية واحدة تلو الأخرى حتى تجد السبب (غالبًا ما يكون السبب هو الأمان أو التخزين المؤقت أو التحسين أو مكون إضافي للحقول المخصصة سيئ البرمجة).

2) تحقق من سجلات PHP وأخطاء REST

فتح wp-content/debug.log مباشرة بعد فشل التحميل.
بحث عن: Fatal error, headers already sent, Deprecated (قد تؤدي بعض عمليات الإهمال إلى تشويه المخرجات إذا تم عرضها)، REST.

لفهم أخطاء "JSON غير صالح"، تجدون وثائق تصحيح الأخطاء الرسمية هنا: تصحيح في وورد.

3) مراقبة الاستعلامات: التحقق من الأخطاء وطلبات AJAX/REST

يعرض برنامج Query Monitor أخطاء PHP، والخطافات، وأحيانًا استدعاءات HTTP. عند استكشاف أخطاء Gutenberg وإصلاحها، أستخدمه بشكل أساسي للأغراض التالية:

لتحديد التحذير الذي يتم تشغيله عند طلب REST،
حدد المكون الإضافي المسؤول من خلال تتبع المكدس.
تحقق مما إذا كان المسؤول يقوم بتحميل أي نصوص برمجية غير متوقعة.

4) تحقق من حالة الموقع وحدود الخادم

ذاكرة PHP قد يتسبب استخدام Gutenberg وأدوات البناء والإضافات الكبيرة في حدوث مشاكل. كما أن نقص الذاكرة قد يؤدي إلى أعطال متقطعة.
القيود : max_input_vars قد يؤثر انخفاض المستوى بشكل كبير على بعض الشاشات (بشكل أقل تكرارًا على Gutenberg النقي، وأكثر تكرارًا على مربعات البيانات الوصفية الثقيلة).
أذونات إذا كانت ملفات WP الأساسية غير قابلة للقراءة، فستتلقى أخطاء 404/500 على الأصول.

5) إعادة ضبط الروابط الدائمة (نادر الحدوث، ولكنه سريع)

عندما يُرجع REST أخطاء 404 على الرغم من وجود الملف، فقد رأيت قواعد إعادة كتابة غير متناسقة بعد الترحيل.

الإعدادات ← الروابط الدائمة ← حفظ (بدون تغيير).

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)
لا يتم تحميل غوتنبرغ إلا على متصفحات معينة.	ذاكرة التخزين المؤقت للمتصفح/عامل الخدمة أو الامتداد	اختبر التصفح الخاص، وعطّل الإضافات، وامسح ذاكرة التخزين المؤقت (الحل 3)
خطأ في جافا سكريبت: "wp غير مُعرّف"	تم تحميل البرنامج النصي مبكرًا جدًا أو على الشاشة الخاطئة	استهداف `post.php`/`post-new.php` + التبعيات (الحل 2)
403 في `/wp-json/` قيد الإنتاج فقط	جدار حماية تطبيقات الويب/شبكة توصيل المحتوى، قاعدة ModSecurity، المصادقة الأساسية	السماح بـ REST/admin-ajax، سجلات WAF، تجاوز (الحل 1)
يعمل البرنامج بعد تعطيل ذاكرة التخزين المؤقت، ثم يتعطل مرة أخرى.	إضافة تحسين التفاعل "minify admin"	استبعاد `/wp-admin/` وحزم ووردبريس (الحل 3)
حدث خطأ بعد تحديث ووردبريس، وتظهر ملفات جافا سكريبت خطأ 404	عملية نشر غير مكتملة / شبكة توصيل المحتوى (CDN) تعرض الإصدار القديم	تنظيف شبكة توصيل المحتوى (CDN) + `wp core verify-checksums` (الحل 3)
الكود موجود "في المكان الصحيح" ولكنه لا يعمل.	تم نسخ الملف إلى الملف الخاطئ (الملحق مقابل القالب الفرعي)، أو تم استخدام خطاف غير مناسب	أضف إلى MU-plugin، وتحقق من الخطاف والأولوية
لا يحدث هذا إلا في حالة دور المحرر.	إمكانيات REST/nonce، إضافة الأدوار	اختبر مسارات REST باستخدام هذا الدور، مع تحديد الصلاحيات الصحيحة.

الأخطاء التي أراها غالباً بين المستخدمين المتوسطين:

اختبر مباشرة على بيئة الإنتاج بدون نسخة احتياطية، ثم قم "بإصلاحها" بشكل عاجل.
أضف مقتطفًا موجودًا في برنامج تعليمي قديم (قبل الإصدار 6.x) يقوم بحظر REST "لأسباب أمنية".
نسيان مسح ذاكرة التخزين المؤقت لشبكة توصيل المحتوى (CDN) بعد تحديث ووردبريس.
استخدام خطاف عام جدًا (على سبيل المثال) init) لطباعة HTML أو تحميل JS.
قم بتصغير/دمج لوحة التحكم "لتوفير 0,2 ثانية" وتخلص من المحرر.

بديل / متغير

طريقة بدون استخدام التعليمات البرمجية: العزل باستخدام فحص الصحة + التراجع المُتحكم به

فحص الحالة ← وضع استكشاف الأخطاء وإصلاحها ← تعطيل الإضافات حسب الفئة (الأمان/التخزين المؤقت/التحسين).
إذا تم تحديد السبب، فقم بتحديثه أو استبداله.
إذا كان الخلل ناتجًا عن تحديث حديث، فقم بإجراء تراجع مؤقت (باستخدام المكون الإضافي) ثم افتح تذكرة دعم مع الناشر.

طريقة أكثر تطوراً: إضافة "الحماية" في MU لتسجيل أخطاء 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 );

تساعد هذه الحماية في ربط شاشة غوتنبرغ المعطلة بمسار REST دقيق.

تجنب هذه المشكلة في المستقبل

لا تحظر REST عالميًاإذا كنت تعمل على تعزيز الأمان، فافعل ذلك من خلال المسارات والأدوار والسياقات. اختبر المسؤول بعد كل تغيير.
لا تقم بتحسين لوحة التحكم (التقليل/الدمج/التأجيل) إلا في حالات محدودة للغاية. المكاسب ضئيلة، والمخاطر هائلة.
قم بتحميل البرامج النصية الإدارية الخاصة بك بشكل صحيح :
- استهداف الشاشة ($hook_suffix + get_current_screen()),
- التبعيات wp-* أعلن،
- إصدار موثوق (filemtime في بيئة بسيطة).
راقب تحذيرات PHP في PHP 8.1 والإصدارات الأحدث، تؤدي بعض الأنماط إلى ظهور المزيد من التحذيرات/الإيقافات. وقد يتسبب التحذير المعروض في حدوث خلل في JSON.
عملية التحديث : بيئة الاختبار → مسح ذاكرة التخزين المؤقت → بيئة الإنتاج. وبعد تحديث ووردبريس، يتم مسح شبكة توصيل المحتوى (CDN) بشكل منهجي.
رؤوس الأمان : نشر CSP في تقرير فقط أولاً، قم بتضييقه تدريجياً. وإلا، ستتسبب في "تعطيل لوحة التحكم" مع الإضافة التالية التي تضيف إطارًا مضمنًا أو كائنًا ثنائيًا.

مراجع مفيدة في لغة PHP: إعدادات معالجة أخطاء PHP.

الموارد

أسئلة fréquentes

لماذا يعرض برنامج غوتنبرغ رسالة "الاستجابة ليست استجابة JSON صالحة"؟

لأن طلب REST يتوقع بيانات JSON ولكنه يستقبل بيانات أخرى (خطأ 403/500 في HTML، تحذير PHP، مخرجات غير مرغوب فيها). افتح الاستجابة في تبويب الشبكة: ستجد السبب غالبًا على الفور.

هل يُعد تعطيل واجهة برمجة تطبيقات REST "لأسباب أمنية" ممارسة جيدة؟

لا، ليس على مستوى النظام ككل. يستخدم ووردبريس (وغتنبرغ) هذه الخاصية داخليًا. إذا أردتَ تعزيز أمانه، فافعل ذلك عبر مسار محدد مع الحفاظ على لوحة التحكم تعمل بشكل سليم. اختبر النظام بشكل منهجي. /wp-json/wp/v2/types/post?context=edit اتصال.

لماذا يعمل هذا مع المدير ولا يعمل مع المحرر؟

تختلف الإمكانيات، وتقوم بعض إضافات الأدوار/الأمان بتصفية واجهات برمجة تطبيقات REST بناءً على الدور. اختبر باستخدام الحساب ذي الصلة وتحقق من وجود أخطاء 403 على مسارات REST في السياق. edit.

هل يمكن أن تتسبب إضافة التخزين المؤقت في تعطيل غوتنبرغ؟

نعم، خاصةً إذا كان يخزن نقاط نهاية REST المصادقة مؤقتًا، أو إذا كان يُحسّن/يُصغّر حجم البرامج النصية الإدارية. استبعاد /wp-admin/ et /wp-json/ قواعد التخزين المؤقت الصارمة.

ماذا أفعل إذا تلقيت خطأ 500 فقط على مسار REST؟

هذا في أغلب الأحيان استدعاء PHP كارثي يتم تشغيله أثناء هذا الطلب. تفعيل WP_DEBUG_LOGتكاثر، ثم شاهد debug.logيساعد برنامج مراقبة الاستعلامات في تحديد المكون الإضافي/السمة المسؤولة.

هل Divi 5 / Elementor / Avada متوافق مع Gutenberg؟

نعم، لكنها تُضيف نصوصًا برمجية وخيارات لتحسين الأداء. تنشأ التعارضات غالبًا من تحسينات الإدارة، أو تصغير حجم الملفات، أو قواعد الأمان المُفرطة في الصرامة. إذا تعطل غوتنبرغ، فاختبر أيضًا مُحرر البناء: فغالبًا ما يكون السبب مشتركًا.

هل ستساعد إعادة حفظ الروابط الدائمة؟

في بعض الأحيان، إذا أعاد REST أخطاء 404 بعد عملية ترحيل أو تغيير في الخادم، فليس هذا هو أول شيء يجب القيام به، ولكنه سريع وخالٍ من المخاطر.

هل يمكنني "إصلاح غوتنبرغ" عن طريق إعادة تحميل jQuery أو إضافة جافا سكريبت مخصصة؟

هذا حل مؤقت يخفي المشكلة الحقيقية (خادم REST معطل، تعارض في البرامج النصية). يجب معالجة السبب: حظر REST، خلل في عملية إضافة الملفات، مشاكل في ذاكرة التخزين المؤقت/شبكة توصيل المحتوى، أو خطأ فادح في PHP.

ما هي الملفات التي يجب عليّ فحصها عندما تُرجع أصول غوتنبرغ خطأ 404؟

انظر إلى عناوين المواقع الإلكترونية 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).

غوتنبرغ عالق: إصلاح محرر ووردبريس

المشكلة

ملخص سريع

الأعراض

مخطط التشخيص السريع

لماذا وصلت؟

المتطلبات الأساسية قبل البدء

الحل الأول: واجهة برمجة تطبيقات REST محظورة (403/401/500) ولم يعد بإمكان Gutenberg بدء التشغيل

تشخيصي

الحالة الشائعة: يقوم أحد المكونات الإضافية بحظر REST عبر مرشح مفرط في التشدد

الواجهة (مكسورة)

بعد (تقييد مصحح وموجه)

الحالة الشائعة: "استجابة JSON غير صالحة" بسبب تحذير PHP

الواجهة (مكسورة)

بعد (مصحح)

الحالة الشائعة: حظر جدار الحماية لتطبيقات الويب/شبكة توصيل المحتوى (403، تحدي، مصادقة أساسية)

الحل الثاني: نصوص المحرر المعطوبة (الإضافة إلى قائمة الانتظار، والتبعيات، وترتيب التحميل)

تشخيصي

حالة شائعة: دراسة استقصائية عالمية حول admin_enqueue_scripts دون استهداف الشاشة

الواجهة (مكسورة)

بعد (تم التصحيح: الاستهداف + التبعيات + الإصدار)

الحالة الشائعة: يقوم أحد المكونات الإضافية بتحميل React/ReactDOM يدويًا

الواجهة (مكسورة)

بعد (تم التصحيح: استخدام حزم ووردبريس)

التوافق مع Divi 5 / Elementor / Avada

الحل الثالث: التخزين المؤقت، والأمان، وسياسة أمان المحتوى (CSP) التي تُعطّل عمل المسؤول

الحالة الشائعة: التحسين الذي يقلل حجم/يدمج لوحة التحكم

الحالة الشائعة: الوضع الاجتماعي والاقتصادي المتشدد للغاية

الحالة الشائعة: الأصول من إصدار أقدم يتم تقديمها عبر شبكة توصيل المحتوى/ذاكرة التخزين المؤقت للعمليات

عمليات التحقق بعد التصحيح

إذا لم ينجح ذلك أيضاً

1) وضع استكشاف الأخطاء وإصلاحها دون التأثير على الزوار

2) تحقق من سجلات PHP وأخطاء REST

3) مراقبة الاستعلامات: التحقق من الأخطاء وطلبات AJAX/REST

4) تحقق من حالة الموقع وحدود الخادم

5) إعادة ضبط الروابط الدائمة (نادر الحدوث، ولكنه سريع)

6) تحقق من وجود تعارض في المقتطفات

7) WP-CLI: التحقق من سلامة الملفات والإصدارات

الأخطاء الشائعة والمزالق

بديل / متغير

طريقة بدون استخدام التعليمات البرمجية: العزل باستخدام فحص الصحة + التراجع المُتحكم به

طريقة أكثر تطوراً: إضافة "الحماية" في MU لتسجيل أخطاء REST

تجنب هذه المشكلة في المستقبل

الموارد

أسئلة fréquentes

لماذا يعرض برنامج غوتنبرغ رسالة "الاستجابة ليست استجابة JSON صالحة"؟

هل يُعد تعطيل واجهة برمجة تطبيقات REST "لأسباب أمنية" ممارسة جيدة؟

لماذا يعمل هذا مع المدير ولا يعمل مع المحرر؟

هل يمكن أن تتسبب إضافة التخزين المؤقت في تعطيل غوتنبرغ؟

ماذا أفعل إذا تلقيت خطأ 500 فقط على مسار REST؟

هل Divi 5 / Elementor / Avada متوافق مع Gutenberg؟

هل ستساعد إعادة حفظ الروابط الدائمة؟

هل يمكنني "إصلاح غوتنبرغ" عن طريق إعادة تحميل jQuery أو إضافة جافا سكريبت مخصصة؟

ما هي الملفات التي يجب عليّ فحصها عندما تُرجع أصول غوتنبرغ خطأ 404؟

أرى رسالة "تم رفض التحميل... ينتهك سياسة أمان المحتوى". ماذا أفعل؟

مقالات ذات صلة

أرسل تعليقًا إلغاء الرد

حالة شائعة: دراسة استقصائية عالمية حول `admin_enqueue_scripts` دون استهداف الشاشة