رفع مشکل بارگذاری نشدن ویرایشگر بلوکی وردپرس

در بیشتر مواقع، ویرایشگر بلوکی وردپرس که بارگذاری نمی‌شود یک خطای JavaScript است — یک اسکریپت خراب از یک افزونه یا قالب کل اپلیکیشن React را متوقف می‌کند و ویرایشگر هرگز رندر شدنش کامل نمی‌شود. کنسول توسعه‌دهنده مرورگرتان را باز کنید (F12، یا Cmd+Option+I روی مک)، صفحه ویرایش را دوباره بارگذاری کنید و خطای قرمز را بخوانید. تقریباً همیشه نام فایلی را که خطا انداخته نشان می‌دهد. همان یک خط به شما می‌گوید کدام افزونه را باید غیرفعال کنید، و معمولاً می‌توانید در کمتر از پنج دقیقه دوباره مشغول نوشتن شوید. نصب مجدد وردپرس، بالا بردن محدودیت حافظه PHP و سوئیچ کردن به ویرایشگر کلاسیک سه پیشنهاد رایجی هستند که در اینترنت می‌بینید، و هر سه معمولاً کار اشتباهی هستند.

چرا ویرایشگر به این شکل خراب می‌شود

ویرایشگر بلوکی (گوتنبرگ) یک اپلیکیشن تک‌صفحه‌ای React است که داخل wp-admin/post.php و post-new.php اجرا می‌شود. وردپرس مجموعه‌ای از بسته‌های اسکریپت را در صف بارگذاری قرار می‌دهد — wp-blocks، wp-element، wp-editor، wp-edit-post — و اپلیکیشن از طریق wp.domReady() راه‌اندازی می‌شود. JavaScript با اولین استثنای مدیریت‌نشده اجرا را متوقف می‌کند. پس اگر هر اسکریپتی که در صف قرار گرفته حین راه‌اندازی ویرایشگر خطا بیندازد، همه چیزِ بعد از آن هم با آن از بین می‌رود. ناحیه نوشتن پستی که با دقت آماده کرده بودید به یک صفحه سفید خالی تبدیل می‌شود یا پیام «The editor has encountered an unexpected error» را نشان می‌دهد.

وردپرس به‌طور پیش‌فرض اسکریپت‌های مدیریت را هم در درخواست‌های کمتری به هم می‌چسباند (concatenate). این یعنی JS خرابِ یک افزونه می‌تواند اسکریپت‌های بی‌ربط دیگری را که در همان بسته بارگذاری شده‌اند هم پایین بکشد، و به همین دلیل است که مقصر همیشه فقط از روی رفتار مشخص نیست. اما کنسول مشخصش می‌کند.

حالت خرابی دوم متفاوت به نظر می‌رسد: ویرایشگر بارگذاری می‌شود، اما ذخیره کردن خطای «Updating failed. The response is not a valid JSON response» را می‌اندازد. این یک مشکل JavaScript نیست. ویرایشگر با REST API روی آدرس /wp-json/wp/v2/ صحبت می‌کند و انتظار دارد JSON تمیزی برگردد. اگر یک افزونه یا functions.php قالبتان یک notice، warning یا خطای مهلک PHP را پیش از JSON چاپ کند — یا یک افزونه امنیتی مسیر REST را مسدود کند، یا یک افزونه ریدایرکت آدرس را بازنویسی کند — پاسخ آلوده می‌شود و ویرایشگر نمی‌تواند آن را پارس کند.

چطور آن را رفع کنیم، از سریع‌ترین راه شروع کنید

۱. کنسول را بخوانید. خرابی را در حالی که DevTools باز است دوباره بازتولید کنید. خطایی مثل Uncaught TypeError ... some-plugin/build/index.js مستقیماً به افزونه مقصر اشاره می‌کند. همین یک قدم بیشتر موارد را حل می‌کند و شما را از حدس زدن کورکورانه با روش دو نیم کردن نجات می‌دهد.

۲. مرورگر را کنار بگذارید. یک بار hard-refresh کنید (Cmd/Ctrl+Shift+R)، سپس یک پنجره ناشناس (incognito) با افزونه‌های مرورگر خاموش امتحان کنید. مسدودکننده‌های تبلیغات و افزونه‌های حریم خصوصی گاهی اسکریپت‌های مدیریت را حذف می‌کنند. اگر در حالت ناشناس کار کرد، مشکل از یک افزونه مرورگر یا کش قدیمی است، نه از سایت شما.

۳. مستقیماً REST API را بررسی کنید اگر پیام «not a valid JSON» را دیدید. آدرس https://yoursite.com/wp-json/ را در مرورگر باز کنید. باید انبوهی از JSON ببینید. اگر HTML، خطای 500 یا ریدایرکت به صفحه ورود دیدید، ایراد همان‌جاست — یک افزونه دارد پاسخ REST را خراب می‌کند، نه خود ویرایشگر.

۴. افزونه‌ها را دو نیم کنید. همه را غیرفعال کنید، مطمئن شوید ویرایشگر بارگذاری می‌شود، سپس یکی‌یکی دوباره فعال کنید تا دوباره خراب شود. اگر کلاً از wp-admin بیرون مانده‌اید، این کار را از طریق SFTP با تغییر نام پوشه انجام دهید:

mv wp-content/plugins wp-content/plugins_off

وقتی پوشه ناپدید می‌شود، وردپرس همه چیز را غیرفعال می‌کند. نامش را دوباره برگردانید، سپس افزونه‌ها را تک‌تک بیرون و داخل کنید.

۵. قالب را تست کنید. به Twenty Twenty-Four سوئیچ کنید. قالبی که JS خرابِ ویرایشگر را در صف می‌گذارد یا در functions.php خطای PHP می‌اندازد همین نشانه‌ها را تولید می‌کند.

۶. لاگ را روشن کنید و خطای واقعی را بخوانید. به‌ویژه برای خرابی‌های REST/JSON، دیباگ را در wp-config.php فعال کنید:

define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );

خطای مهلک همراه با نام دقیق فایل و شماره خط در wp-content/debug.log نوشته می‌شود. اگر آن stack trace شلوغ بود — نام کلاس‌های namespace‌دار، زنجیره‌های require، یک خطای مهلک که زیر ده خط trace دفن شده — آن را در رمزگشای لاگ خطای وردپرس ما جای‌گذاری کنید تا به زبان ساده ببینید واقعاً کدام افزونه و کدام خط باعثش شده. این تفاوتِ میان «یک چیزی خراب است» و «خط ۲۱۴ این افزونه خاص خراب است» است.

اگر مشکوکید که چسباندن اسکریپت‌ها مقصر واقعی را پنهان کرده، هر اسکریپت را مجبور کنید جداگانه بارگذاری شود تا خطای کنسول دقیقاً به یک فایل اشاره کند:

define( 'SCRIPT_DEBUG', true );
define( 'CONCATENATE_SCRIPTS', false );

چه کارهایی نباید کرد

افزونه ویرایشگر کلاسیک را نصب نکنید و آن را «رفع‌شده» ندانید. این چیزی را رفع نمی‌کند — فقط ویرایشگر بلوکی را پنهان می‌کند تا دیگر خطا را نبینید. JavaScript خراب یا پاسخ REST خراب هنوز سر جایش است و دوباره در ویرایشگر سایت، در ابزارک‌ها، یا دفعه بعدی که به‌روزرسانی کنید گریبانتان را می‌گیرد. اول تشخیص بدهید؛ فقط در صورتی به کلاسیک برگردید که آگاهانه تصمیم گرفته باشید دیگر از بلوک‌ها استفاده نکنید.

محدودیت حافظه PHP را از روی عادت بالا نبرید. این محبوب‌ترین راه‌حل کپی‌پیستی اینترنت است، اما یک ویرایشگر خالی به‌ندرت به خاطر تمام شدن حافظه است. تمام شدن واقعی حافظه یک خطای مهلک مشخص می‌اندازد — «Allowed memory size of N bytes exhausted» — که آن را در debug.log خواهید دید. اگر آن خط آنجا نیست، حافظه بیشتر چیزی را عوض نمی‌کند.

هسته وردپرس را دوباره نصب نکنید. فایل‌های هسته روی هر نصبی بیت‌به‌بیت یکسان‌اند. اگر مشکل از هسته بود، همین الان هر سایت وردپرسی روی زمین ویرایشگر خرابی داشت. ایراد تقریباً همیشه در افزونه‌ها یا قالب شماست، و نصب مجدد هسته این خطر را دارد که چیزهایی را بازنویسی کند بی‌آنکه چیزی را رفع کند.

کش‌ افزونه‌تان را کورکورانه به‌عنوان قدم اول پاک یا غیرفعال نکنید. فشرده‌سازی و چسباندن تهاجمی JS می‌تواند ویرایشگر را خراب کند، پس ارزش تست کردن دارد — اما پیش از آنکه بی‌هدف به پاک کردن کش‌ها بیفتید، کنسول را بررسی کنید. حدس زدن همان چیزی است که یک راه‌حل پنج‌دقیقه‌ای را به یک بعدازظهر تلف‌شده تبدیل می‌کند.

هنوز گیر کرده‌اید؟

اگر کنسول تمیز است، REST API جیسون معتبر برمی‌گرداند، و دو نیم کردن کامل افزونه‌ها و قالب هم باز ویرایشگر را مرده رها می‌کند، جواب تقریباً همیشه در debug.log نشسته است. WP_DEBUG_LOG را فعال کنید، یک بار خرابی را بازتولید کنید، و خطای مهلک حاصل را از رمزگشای لاگ خطا عبور دهید. stack trace نام فایل را می‌گوید — از همان‌جا شروع کنید.