لود نشدن المنتور می‌تواند به شکل صفحهٔ سفید، نشانگر بارگذاری مداوم یا پنل خاکستری ابزارها دیده شود. علت همیشه یک افزونهٔ ناسازگار نیست. ابتدا مشخص کنید مشکل در همهٔ برگه‌ها رخ می‌دهد یا فقط یک صفحه؛ سپس مرحله‌ها را یکی‌یکی انجام دهید و نتیجه را ثبت کنید.
۱. نشانهٔ لود نشدن المنتور را مشخص کنید
زمان شروع مشکل، آخرین تغییر و نسخهٔ افزونه‌ها را یادداشت کنید. یک صفحهٔ سادهٔ آزمایشی را با صفحهٔ مشکل‌دار مقایسه کنید. اگر فقط یک صفحه باز نمی‌شود، حجم محتوا، ابزارک خاص یا کد سفارشی همان صفحه را بررسی کنید.
بارگذاری ویرایشگر با نمایش تغییرات در سایت فرق دارد. اگر ویرایشگر باز می‌شود ولی فرانت نسخهٔ قبلی را نشان می‌دهد، مسئله ممکن است کش خروجی باشد و مسیر عیب‌یابی متفاوتی داشته باشد.
۲. مرورگر را جدا آزمایش کنید
با مرورگر به‌روز و یک نشست خصوصی وارد شوید. اگر مشکل برطرف شد، کش یا افزونهٔ مرورگر را بررسی کنید. برای پاک کردن کش، حذف رمزها یا تمام داده‌های حساب‌ها لازم نیست؛ گزینهٔ فایل‌های کش‌شده را هدف بگیرید.
۳. سازگاری نسخه‌ها را بررسی کنید
نسخهٔ WordPress، Elementor و در صورت استفاده Elementor Pro باید سازگار باشند. نیازمندی‌های فعلی Elementor را با محیط وب مقایسه کنید. نسخهٔ PHP خط فرمان الزاماً همان نسخهٔ پردازش سایت نیست.
ارتقا را ابتدا در نسخهٔ آزمایشی و با امکان بازگشت انجام دهید. انتخاب جدیدترین PHP بدون بررسی قالب و افزونه‌ها می‌تواند مشکل دیگری ایجاد کند. صرف دیدن نام یک افزونه در فهرست قدیمی ناسازگاری، دلیل حذف فوری آن نیست.
۴. از Safe Mode برای تشخیص استفاده کنید
در رابط فعلی، از Elementor → Editor → Tools گزینهٔ Safe Mode را فعال و ذخیره کنید؛ در نسخه‌های قدیمی مسیر Tools کوتاه‌تر است. طبق راهنمای عیب‌یابی Elementor، این حالت محیط تمیزتری برای ویرایشگر فراهم می‌کند.
اگر ویرایشگر در این حالت باز شد، تداخل را در محیط آزمایشی پیگیری کنید. افزونه‌ها را مرحله‌ای بررسی کنید و قالب را نیز جدا بسنجید. Safe Mode تشخیص است، نه درمان دائمی؛ بعد از بررسی آن را به وضعیت عادی برگردانید.
۵. حافظهٔ مؤثر را کنترل کنید
در System Info المنتور و سلامت سایت، حافظه و خطاهای PHP را ببینید. مستند فعلی حداقل ۲۵۶ مگابایت را برای Elementor و Pro ذکر می‌کند و برای مجموعهٔ افزونه‌های بیشتر ممکن است حافظهٔ بیشتری لازم باشد. پیام memory exhausted نشانهٔ مشخص‌تری از حدس زدن مقدار است.
افزودن عدد بزرگ به wp-config.php محدودیت واقعی میزبان را تضمین نمی‌کند. مقدار مؤثر PHP و حافظهٔ مدیریت وردپرس باید بررسی شوند؛ تعریف تکراری ثابت‌ها یا ویرایش اشتباه فایل می‌تواند سایت را از دسترس خارج کند.
۶. بهینه‌سازی اسکریپت و کش را بررسی کنید
فشرده‌سازی، ترکیب یا تأخیر JavaScript می‌تواند با ویرایشگر تداخل داشته باشد. تنظیم مشکوک را در محیط تست جدا بررسی کنید. اگر Cloudflare Rocket Loader فعال است، راهنمای رسمی خطای ویرایشگر بررسی آن یا قواعد مناسب را پیشنهاد می‌کند.
پاک کردن کش با غیرفعال کردن همهٔ حفاظت‌های CDN یکی نیست. بخش مدیریت و درخواست‌های شخصی نباید مانند صفحهٔ عمومی کش شوند. هر تغییر را به محدودهٔ لازم محدود کنید.
۷. خطای درخواست و پیش‌نمایش را بخوانید
در ابزار توسعهٔ مرورگر، Console و Network را بررسی کنید. پاسخ ۴۰۳، خطای ۵۰۰، خطای JavaScript و مسدود شدن iframe علت‌های متفاوت دارند. زمان و نشانی درخواست ناموفق را بدون توکن یا اطلاعات خصوصی برای بررسی ثبت کنید.
اگر خطا به URL، HTTPS یا سیاست قاب مربوط است، تنظیم واقعی استقرار را بررسی کنید. نشانی WordPress و سایت در بعضی نصب‌ها عمداً متفاوت است؛ آن‌ها را صرفاً برای آزمایش یکسان نکنید. حذف کامل هدرهای امنیتی هم راه‌حل عمومی نیست.
۸. نتیجه را با ذخیره و نمایش بسنجید
پس از رفع علت، یک تغییر کوچک در صفحهٔ آزمایشی ذخیره کنید و خروجی موبایل و دسکتاپ را ببینید. اگر مشکل ادامه دارد، نسخه‌ها، خطای دقیق و آزمون‌های انجام‌شده را به پشتیبانی بدهید. این اطلاعات از عبارت «المنتور کار نمی‌کند» برای تشخیص مفیدتر است.
مطالعهٔ مرتبط
بازبینی فنی: ۱۳ آبان ۱۴۰۵. تاریخ انتشار اولیه و نشانی قبلی حفظ شده‌اند.
