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

محصولات زیر برای شماست...

جدیدترین مقالات

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

خطای 500 وردپرس: از روی صفحه خطا بفهمید کدام بخش خراب شده است

پرداخت در محل ووکامرس: کارمزد پست، وضعیت سفارش و فعال‌سازی فقط برای چند شهر

فروش اقساطی ووکامرس: اسنپ‌پی، دیجی‌پی یا ترب‌پی؛ کدام افزونه در تسویه حساب بلوکی نشان داده می‌شود؟

ویرایش صفحه تشکر ووکامرس: چرا فیلتر بدون شرط در قالب بلوکی کد ۵۰۰ می‌دهد؟

دسترسی سریع

روی یک نصب تازه با وردپرس ۷٫۱٫۲ و المنتور ۴٫۳٫۴ ویرایشگر را به ۹ روش خراب کردیم تا لود نشدن المنتور را از نزدیک ببینیم. در هر ۹ حالت می‌شد گفت «المنتور لود نمی‌شود»، ولی ویرایشگر سه جور صفحه نشان داد: پنجره‌ای با پیام، لودینگی که تمام نمی‌شود و صفحه‌ای سفید. علت و راه‌حل هر کدام جای دیگری است.

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

صفحه‌ای که می‌بینید	اول کجا را ببینید	علتی که بازتولید کردیم	راه‌حل
پنجره با کد 500	سقف حافظه PHP	پیش‌نمایش سقف حافظه کمتری از صفحه ویرایشگر دارد	ثابت `WP_MEMORY_LIMIT` یا بالا بردن سقف از سمت هاست
پنجره با کد 403	فایروال هاست و `.htaccess`	قاعده‌ای که آدرس پیش‌نمایش را رد می‌کند	برداشتن قاعده
پنجره بدون کد، با پیام کلی	فایل `index.html` در ریشه سایت	در آزمون ما: فایل ایستا جلوتر از وردپرس خوانده شد	حذف یا تغییر نام فایل
پنجره «کیت پیش فرض»	گزینه کیت فعال	کیت حذف شده	برگرداندن کیت
پنجره «ناحیه محتوایی»	قالب فعال	قالب `the_content` را صدا نمی‌زند	قالب دیگر
لودینگ بی‌پایان	کنسول مرورگر	هدر `X-Frame-Options`، دو آدرس ناهمسان یا یک افزونه	بسته به پیام کنسول؛ برای افزونه، حالت ایمن
صفحه سفید	لاگ خطای آپاچی (Apache)	پاسخ ویرایشگر وسط راه قطع می‌شود	گزینه تغییر روش بارگذاری یا `SubstituteMaxLineLength`

پنجره خطای پیش‌نمایش اگر کد وضعیت داشته باشد، مسیر را نشان می‌دهد

المنتور صفحه را در یک iframe، یعنی قابی داخل ویرایشگر، باز می‌کند. وقتی قاب بار شود و المنتور داخلش نباشد، ویرایشگر همان آدرس را با &preview-debug دوباره می‌خواهد. اگر این درخواست خطا بدهد، متن و کد وضعیت را در پنجره می‌نویسد؛ روی HTTP/2 متن وضعیتی نیست و به جایش «error» می‌آید. اگر درخواست درست جواب بدهد، پیام کلی «مشکلی به وجود آمده است» می‌آید.

در PHP خود المنتور بررسی‌های دیگری هم هست (مانند نبودن فایل‌های قالب و ویرایش صفحه فروشگاه ووکامرس) که پیام اختصاصی خودشان را می‌نویسند؛ آنها را فقط در کد خواندیم و بازتولید نکردیم. دو شاخه بالا، یعنی کد وضعیت و پیام کلی، را در سه حالت زیر دیدیم. منطق این پنجره در کد المنتور ۴٫۳٫۴ است.

در آزمون ما پنجره با کد 500 از کمبود حافظه پیش‌نمایش آمد

اگر سقف PHP کمتر باشد، وردپرس آن را برای صفحه‌های پیشخوان به ۲۵۶ مگابایت می‌رساند و برای صفحه‌های سایت فقط به ۴۰ مگابایت، و هر دو را فقط وقتی که هاست اجازه بدهد. پیش‌نمایش المنتور یک درخواست سمت سایت است. در نصب آزمایشی memory_limit را در تنظیمات PHP روی ۳۲ مگابایت گذاشتیم و افزونه‌ای آزمایشی، به جای قالب و افزونه‌های پرمصرف، ۵۰ مگابایت را فقط در صفحه‌های سایت اشغال می‌کرد:

وضعیت	صفحه ویرایشگر	درخواست پیش‌نمایش
PHP روی ۳۲ مگابایت، بدون تغییر دیگر	باز شد؛ سقف اعمال‌شده ۲۵۶ مگابایت	خطای 500؛ سقف اعمال‌شده ۴۰ مگابایت
همان وضعیت با ثابت `WP_MEMORY_LIMIT` روی ۲۵۶ مگابایت	باز شد	باز شد؛ سقف ۲۵۶ مگابایت
هاست سقف ۳۲ مگابایت را قفل کرده و ثابت هم هست	باز شد	خطای 500؛ سقف ۳۲ مگابایت

پنجره المنتور روی صفحه‌ای تیره: عنوان «پیشنمایش قادر به بارگذاری نیست» و زیر آن Internal Server Error 500

zhaket، wpnovin، elementor-site و مستندات المنتور ثابت WP_MEMORY_LIMIT را پیشنهاد می‌کنند (المنتور ۵۱۲ مگابایت می‌نویسد، ما ۲۵۶ را آزمودیم). آن را در wp-config.php و بالای خطی که عبارت «stop editing» در آن است بگذارید:

PHP

define( 'WP_MEMORY_LIMIT', '256M' );

این ثابت فقط وقتی کار می‌کند که سقف قفل نباشد؛ با سقف قفل‌شده هیچ فرقی نکرد. دو سقف را می‌توانید جدا ببینید: در «ابزارها > سلامت سایت > اطلاعات > سرور» سطر «محدوده حافظه PHP» برای صفحه‌های عادی است و سطر بعدی، که در پرانتزش «فقط برای مدیر بخش» آمده، برای پیشخوان؛ این سطر دوم فقط وقتی هست که دو سقف یکی نباشند. در وضعیت اول سطر اول 40M بود و سطر دوم 256M.

سقف قفل‌شده ممکن است از نیاز خود ویرایشگر هم کمتر باشد. با قفل ۳۲ مگابایتی اولین درخواست بعد از تغییر تنظیمات ناقص ماند و ۸ درخواست بعدی کامل آمدند؛ دلیل این فرق را بررسی نکردیم. با قفل ۲۴ مگابایتی هر بار ناقص ماند و به جای ویرایشگر پیام «یک خطای مهم در این وب سایت وجود دارد» آمد. این چهارمین نوع صفحه است و در شمار ۹ حالت نیست.

سقف قفل‌شده را فقط هاست عوض می‌کند. اگر به پنل هاست دسترسی ندارید، درخواست را می‌توانید در فرم پشتیبانی ثبت کنید و مقدار سطر حافظه در سلامت سایت را پیوست کنید؛ خدمات پشتیبانی فنی وردپرس نیاز برای همین کارهاست.

در آزمون ما پنجره با کد 403 از قاعده‌ای آمد که آدرس پیش‌نمایش را رد می‌کرد

قاعده‌ای در .htaccess، فایلی در ریشه سایت، نوشتیم که هر آدرس دارای elementor-preview را با 403 رد می‌کند و پنجره «Forbidden 403» نوشت. مستندات المنتور قاعده‌های امنیتی هاست مانند mod_security را از علت‌های این پنجره می‌داند. با برداشتن قاعده ویرایشگر باز شد. اگر قاعده از هاست است، پیوند «برای مشاهده پیش‌نمایش اشکال‌زدایی کلیک کنید» در پنجره همان آدرسی را باز می‌کند که رد شده؛ آن را به پشتیبانی هاست بدهید.

پنجره بدون کد در آزمون ما از فایل index.html آمد

اگر کدی نیست، همان درخواست با &preview-debug پاسخ 200 داده، ولی المنتور در قاب نیست. ما این را با فایل index.html ساختیم: فایلی ساده در ریشه سایت گذاشتیم و DirectoryIndex index.html index.php را نوشتیم تا آپاچی آن را جلوتر از index.php بخواند. فقط پیش‌نمایش صفحه اصلی، که آدرسش به ریشه می‌رسد، خراب شد؛ پیش‌نمایش یک برگه دیگر را با curl خواستیم و از وردپرس آمد. پنجره همان پیام کلی را داد و با حذف فایل ویرایشگر باز شد. علت‌های دیگری هم می‌توانند همین پنجره را بدهند؛ مستندات المنتور Rocket Loader و افزونه‌های مرورگر را نام می‌برد و ما آنها را بازتولید نکردیم.

کیت حذف‌شده و قالبی که the_content را صدا نمی‌زند هم پنجره خودشان را دارند

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

لودینگی که تمام نمی‌شود پنجره خطا ندارد؛ علتش در کنسول مرورگر است

هدر X-Frame-Options با مقدار DENY را با Header always set در .htaccess اضافه کردیم و لودینگ المنتور دست‌کم پنج دقیقه ماند و پنجره خطایی نیامد. کلید F12 را بزنید، برگه Console را باز کنید و صفحه را دوباره بارگذاری کنید. ما سه علت را بازتولید کردیم و در هر سه کنسول پیام داشت.

هدر DENY این دو پیام را در کنسول گذاشت:

CODE

Refused to display 'http://127.0.0.1:41300/' in a frame because it set 'X-Frame-Options' to 'deny'.
Uncaught SecurityError: Failed to read a named property 'elementorFrontend' from 'Window': Blocked a frame with origin "http://127.0.0.1:41300" from accessing a cross-origin frame.

پیام اول علت است و دومی نتیجه‌اش. صفحه ویرایشگر وردپرس خودش SAMEORIGIN می‌فرستد؛ با همین مقدار برای کل سایت ویرایشگر باز شد. اگر شک دارید هدر روی سایت شما هم هست، این دستور را در Git Bash یا WSL اجرا کنید (example.com را با آدرس سایتتان عوض کنید)؛ در Windows PowerShell این دستور اجرا نمی‌شود، و هدر را در برگه Network مرورگر هم می‌توانید ببینید:

CODE

bash
curl -sI https://example.com/ | grep -i x-frame-options

اگر DENY چاپ شد، جایی را بگردید که هدر می‌سازد؛ ما فقط .htaccess را آزمودیم.

وقتی «نشانی سایت (URL)» در تنظیمات عمومی را روی localhost گذاشتیم و ویرایشگر را با 127.0.0.1 باز کردیم، همان SecurityError آمد و خطاهای 403 متعدد پشت سرش؛ لودینگ دست‌کم دو دقیقه ماند. با یکی کردن دو آدرس ویرایشگر باز شد.

سومی افزونه‌ای است که کتابخانه‌ای از خودش می‌آورد. افزونه‌ای آزمایشی نوشتیم که lodash را در ویرایشگر بار می‌کند و جای _ وردپرس را می‌گیرد. کنسول «_.pluck is not a function»، «Marionette is not defined» و «elementor is not defined» نوشت و لودینگ دست‌کم دو دقیقه ماند.

المنتور بعد از ۳۰ ثانیه به مدیر سایت حالت ایمن را پیشنهاد می‌دهد:

لودینگ المنتور با حلقه و نشان المنتور و در گوشه پایین کادر «نمی‌توانید ویرایش کنید؟» با دکمه فعال‌سازی حالت ایمن

حالت ایمن را از «المنتور > ابزارها > عمومی > حالت ایمن» روشن کردیم، در حالی که افزونه آزمایشی هنوز فعال بود، و ویرایشگر باز شد. اگر در حالت ایمن باز شد، علت یک افزونه یا قالب است. مستندات المنتور می‌گوید همه افزونه‌ها را جز المنتور و المنتور پرو غیرفعال کنید، بعد یکی‌یکی فعال کنید و بعد از هر کدام ویرایشگر را دوباره باز کنید.

طبق کد المنتور، حالت ایمن فقط برای صفحه ویرایشگر، پیش‌نمایش و ایجکس ویرایشگر کسی کار می‌کند که کوکی آن را دارد. در آن درخواست‌ها از افزونه‌های فعال فقط المنتور، المنتور پرو و ووکامرس (اگر نصب باشند) بار می‌شوند و قالب با قالب داخلی المنتور عوض می‌شود. پس اگر مشکل از خود المنتور پرو باشد، حالت ایمن آن را کنار نمی‌گذارد. افزونه‌های ضروری، یعنی فایل‌های پوشه mu-plugins، هم غیرفعال نمی‌شوند: در نصب ما، که دو فایل دیگر کنار فایل خود المنتور در آن پوشه بود، کادر «حالت امن روشن» نوشت نمی‌تواند همه افزونه‌ها را غیرفعال کند.

صفحه سفید در آزمون ما وقتی آمد که پاسخ ویرایشگر وسط راه قطع شد

صفحه ویرایشگر روی نصب فارسی ما ۳٬۲۵۷٬۲۶۷ بایت بود و بزرگ‌ترین سطر آن ۲٬۲۸۹٬۶۱۲ بایت؛ همان سطری که تنظیمات ویرایشگر در آن چاپ می‌شود. ماژول mod_substitute در آپاچی خروجی را سطر به سطر بازنویسی می‌کند و طبق مستندات آپاچی پیش‌فرضش سطر بزرگ‌تر از ۱ مگابایت، یعنی ۱٬۰۴۸٬۵۷۶ بایت، را نمی‌پذیرد. آن سطر ۲٫۱۸ برابر این سقف است.

با آپاچی ۲٫۴٫۶۹ و PHP-FPM قاعده‌ای از mod_substitute را در .htaccess نوشتیم. پاسخ با کد 200 شروع شد، ولی فقط ۸۹۹٬۹۰۵ بایت از ۳٬۲۵۷٬۲۶۷ بایت رسید. لاگ آپاچی «Line too long, URI /wp-admin/post.php» نوشت، کنسول مرورگر ERR_INCOMPLETE_CHUNKED_ENCODING را نشان داد و صفحه ویرایشگر خالی ماند. همین قاعده با PHP به‌صورت ماژول آپاچی ۲٫۴٫۶۸ خطا نداد و صفحه کامل رسید؛ دلیلش را پیدا نکردیم، پس نمی‌دانیم کدام هاست‌ها دچار می‌شوند. نوع PHP هاستتان را در «ابزارها > سلامت سایت > اطلاعات > سرور» و سطر «PHP SAPI» می‌بینید: fpm-fcgi یعنی FPM و apache2handler یعنی ماژول آپاچی. نوع ماژول امن بودن نمی‌آورد: در آزمون ما روی ماژول آپاچی، فایل PHP ساده‌ای که یک سطر ۱٫۵ میلیون نویسه‌ای چاپ می‌کرد هم با همین خطا شکست خورد.

دو راه جواب داد. اولی گزینه «تغییر روش بارگذاری ویرایشگر» در «المنتور > تنظیمات > پیشرفته» است. اسمش از چیز دیگری می‌گوید، ولی در کد المنتور ۴٫۳٫۴ این گزینه فقط یک کار می‌کند، و آن را در تابع print_js_config می‌بینید:

PHP

$config = str_replace( '}},"', '}},' . PHP_EOL . '"', $config );

یعنی بعد از هر جا که دو آکولاد بسته را کاما و کلید بعدی دنبال کند، سطر جدید می‌گذارد. بزرگ‌ترین سطر از ۲٬۲۸۹٬۶۱۲ به ۶۶٬۰۵۰ بایت رسید و ویرایشگر در مرورگر باز شد. راه دوم بالا بردن سقف آپاچی است:

APACHE

<IfModule mod_substitute.c>
SubstituteMaxLineLength 30m
</IfModule>

این سه سطر را در .htaccess بالای بخش # BEGIN WordPress گذاشتیم و با آنها پاسخ ویرایشگر کامل آمد و در مرورگر باز شد. فقط وقتی لازم است که لاگ آپاچی «Line too long» بنویسد.

wpnovin (به‌روز شده در ۷ شهریور ۱۴۰۵) و mihanlearn (منتشرشده در ۲۱ مهر ۱۴۰۱) همین دستور را داخل IfModule می‌گذارند و بیرون از آن LimitRequestBody 9999999 را هم می‌نویسند. بدون IfModule روی آپاچی‌ای که ماژول را بار نمی‌کند، همان دستور کل سایت را به خطای 500 برد و لاگ «Invalid command ‘SubstituteMaxLineLength’» نوشت؛ پس اگر دستور اول را کپی می‌کنید، شکل داخل IfModule را کپی کنید.

از آن دو دستور فقط اولی لازم بود. LimitRequestBody 9999999 سقف بدنه درخواست را ۹٬۹۹۹٬۹۹۹ بایت می‌کند، کمی کمتر از ۱۰ میلیون بایت. پیش‌فرض آپاچی از نسخه ۲٫۴٫۵۴ یک گیگابایت، یعنی ۱٬۰۷۳٬۷۴۱٬۸۲۴ بایت، است و در نسخه‌های قدیمی‌تر صفر، یعنی بدون سقف. وقتی post_max_size و upload_max_filesize را در PHP روی ۶۴ مگابایت بردیم، بدنه‌ای ۱۲٬۰۰۰٬۰۰۰ بایتی با این دستور پاسخ 413 داد و بدون آن پاسخ 200. صفحه ویرایشگر با GET باز می‌شود و بدنه ندارد؛ بدون این دستور هم کامل آمد و اثری که از آن دیدیم فقط رد شدن بدنه‌های بزرگ بود.

اگر علت شما در این ۹ حالت نبود، در فرم پشتیبانی دو چیز را بنویسید: متن پنجره یا پیام کنسول، و پاسخ آدرسی که پیوند «برای مشاهده پیش‌نمایش اشکال‌زدایی کلیک کنید» باز می‌کند. المنتور پرو را آزمایش نکردیم و Cloudflare Rocket Loader و افزونه‌های مرورگر را هم، که مستندات المنتور نامشان را می‌برد، بازتولید نکردیم.

پرسش‌های متداول

پیام «پیش‌نمایش قادر به بارگذاری نیست» یعنی چه؟

یعنی پیش‌نمایش در قاب ویرایشگر بار نشده یا المنتور داخل آن نیست. اگر پنجره کد وضعیت دارد، همان کد مسیر را نشان می‌دهد: در آزمون ما 500 از کمبود حافظه می‌آمد و 403 از یک قاعده. بدون کد، در آزمون ما علت فایل index.html در ریشه سایت بود.

چرا المنتور لود نمی‌شود و فقط لودینگ می‌چرخد؟

چیزی مانع باز شدن پیش‌نمایش یا اجرای اسکریپت‌های ویرایشگر شده و المنتور فقط بعد از ۳۰ ثانیه حالت ایمن را پیشنهاد می‌دهد. در آزمون ما سه چیز این حالت را ساخت: هدر X-Frame-Options با مقدار deny، دو آدرس ناهمسان و افزونه‌ای که کتابخانه خودش را بار می‌کرد. علت در Console مرورگر (کلید F12) نوشته شده بود.

چرا صفحه ویرایشگر المنتور سفید می‌ماند؟

در آزمون ما با آپاچی و PHP-FPM و یک قاعده mod_substitute، سطر ۲٬۲۸۹٬۶۱۲ بایتی ویرایشگر از سقف ۱ مگابایتی آپاچی بزرگ‌تر بود و پاسخ ناقص رسید. گزینه «تغییر روش بارگذاری ویرایشگر» یا SubstituteMaxLineLength 30m داخل IfModule آن را رفع کرد.

گزینه «تغییر روش بارگذاری ویرایشگر» دقیقاً چه کار می‌کند؟

در المنتور ۴٫۳٫۴ فقط به تنظیمات ویرایشگر سطر جدید اضافه می‌کند، بعد از هر جایی که دو آکولاد بسته را کاما و کلید بعدی دنبال کند. در آزمون ما بزرگ‌ترین سطر صفحه از ۲٬۲۸۹٬۶۱۲ به ۶۶٬۰۵۰ بایت رسید.

حالت ایمن المنتور چه چیزی را غیرفعال می‌کند؟

در درخواست‌های ویرایشگر، پیش‌نمایش و ایجکس ویرایشگر کسی که کوکی حالت ایمن را دارد، از افزونه‌های فعال فقط المنتور، المنتور پرو و ووکامرس (اگر نصب باشند) بار می‌شوند؛ افزونه‌های پوشه mu-plugins غیرفعال نمی‌شوند و قالب با قالب داخلی المنتور عوض می‌شود.

خط LimitRequestBody 9999999 در htaccess چه می‌کند؟

سقف بدنه درخواست را ۹٬۹۹۹٬۹۹۹ بایت می‌کند. وقتی post_max_size و upload_max_filesize در PHP روی ۶۴ مگابایت بودند، بدنه‌ای ۱۲٬۰۰۰٬۰۰۰ بایتی با آن پاسخ 413 گرفت و بدون آن پاسخ 200. صفحه ویرایشگر با GET و بدون بدنه باز می‌شود و در آزمون ما برای باز شدن ویرایشگر لازم نبود؛ اثری که دیدیم فقط رد شدن بدنه‌های بزرگ بود.

چرا بعد از افزایش WP_MEMORY_LIMIT هم پیش‌نمایش لود نمی‌شود؟

اگر هاست memory_limit را قفل کرده باشد، ثابت وردپرس آن را بالا نمی‌برد. در آزمون ما با سقف قفل‌شده ۳۲ مگابایت هیچ فرقی نکرد و سقف را باید هاست عوض کند.