رفع خطای «لینکی که دنبال می‌کردید منقضی شده است» هنگام نصب افزونه وردپرس

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

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

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

۲. محل دقیق خطا را مشخص کنید: افزونه‌ها ← افزودن افزونه ← بارگذاری افزونه یا نمایش ← پوسته‌ها ← افزودن پوسته ← بارگذاری پوسته. نام گزینه‌ها با نسخه وردپرس و ترجمه ممکن است کمی فرق کند.

۳. ببینید آیا پیام بلافاصله پس از زدن دکمه می‌آید یا پس از چند دقیقه انتظار. خطای فوری روی فایل بزرگ می‌تواند به محدودیت اندازه مربوط باشد؛ انتظار طولانی و سپس قطع‌شدن می‌تواند به زمان دریافت فایل یا شبکه مربوط باشد. این نشانه‌ها به‌تنهایی تشخیص قطعی نیستند.

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

از پیشخوان خارج شوید، دوباره وارد شوید و صفحه بارگذاری را تازه باز کنید. فایل ZIP را مجدداً انتخاب و بدون بازگذاشتن طولانی صفحه روی «نصب» بزنید. وردپرس برای برخی عملیات از نشانه امنیتی با عمر محدود استفاده می‌کند؛ بازکردن صفحه تازه می‌تواند خطای یک صفحه قدیمی را برطرف کند. اگر دسترسی مدیر ندارید، از مدیر سایت بخواهید این مرحله را انجام دهد؛ تغییر نقش کاربران فقط برای دورزدن خطا راه‌حل مناسبی نیست.

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

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

در پیشخوان به رسانه ← افزودن پرونده رسانه‌ای بروید. در بسیاری از نصب‌ها، عبارت «بیشینه اندازه بارگذاری پرونده» در این صفحه دیده می‌شود. این عدد یک سرنخ برای محدودیت گزارش‌شده توسط وردپرس است، نه تضمین اینکه همه لایه‌های مسیر آپلود همین اندازه را می‌پذیرند. اگر آن را نمی‌بینید، به جای حدس، تنظیمات PHP دامنه را در کنترل‌پنل بررسی کنید.

مثلاً اگر فایل نصب ۳۰ مگابایت و سقف اعلام‌شده ۲۰ مگابایت است، این اختلاف دلیل مناسبی برای بررسی سقف است. اگر فایل فقط ۲ مگابایت است ولی سقف ۶۴ مگابایت نشان داده می‌شود، بزرگ‌کردن اعداد بدون بررسی معمولاً اولین اقدام مناسب نیست؛ به مرحله نشست، افزونه و پاسخ شبکه در ادامه بروید.

دو تنظیم PHP با نام‌های زیر اغلب مهم‌اند:

| تنظیم | کار آن چیست؟ | نکته عملی | | --- | --- | --- | | upload_max_filesize | سقف اندازه یک فایل آپلودی را تعیین می‌کند. | باید از اندازه فایل نصب شما بزرگ‌تر باشد. | | post_max_size | سقف کل داده درخواست را تعیین می‌کند. | باید از سقف فایل و اندازه کل درخواست بزرگ‌تر باشد، چون درخواست فقط خود فایل نیست. |

برای فایل ۳۰ مگابایتی، مقدار نمونه 64M برای upload_max_filesize و 80M برای post_max_size می‌تواند فضای کافی برای همان آزمایش بدهد؛ این‌ها مقادیر پیشنهادی همگانی نیستند. محدودیت‌های پلن و نیاز واقعی سایت را در نظر بگیرید و اعداد بسیار بزرگ را صرفاً برای حذف خطا انتخاب نکنید. تغییر این تنظیم‌ها ممکن است برای همه برنامه‌های همان دامنه اثر داشته باشد.

فرض کنید اندازه فایل شما ۳۰ مگابایت است و پنل upload_max_filesize را 64M اما post_max_size را 16M نشان می‌دهد. در این حالت، سقف کل درخواست از خود فایل کوچک‌تر است؛ حتی با اینکه سقف فایل ۶۴ مگابایت به نظر می‌رسد، درخواست ۳۰ مگابایتی می‌تواند در مرحله دریافت رد شود. ابتدا مقدارهای فعلی را یادداشت کنید و اگر مجاز به تغییر هستید، برای همین نیاز مشخص سقف کل درخواست را بالاتر از سقف فایل قرار دهید. سپس صفحه نصب را تازه باز کنید و همان فایل را دوباره امتحان کنید. اگر نتیجه تغییر نکرد، فرض نکنید حتماً باید اعداد را باز هم بزرگ‌تر کنید؛ پاسخ شبکه و محدودیت‌های لایه دیگر را بررسی کنید.

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

۱. وارد cPanel شوید و از بخش Software گزینه MultiPHP INI Editor را باز کنید. اگر این گزینه موجود نیست یا اجازه تغییر نمی‌دهد، نام پنل و محدودیت‌های حساب شما ممکن است متفاوت باشد؛ به بخش «اگر پنل این گزینه را ندارد» بروید.

۲. در بخش انتخاب محل، دامنه درست را انتخاب کنید. در حسابی که چند سایت دارد، تغییر دامنه دیگر مشکل این سایت را حل نمی‌کند.

۳. مقدار فعلی upload_max_filesize و post_max_size را یادداشت کنید. پس از تصمیم‌گیری درباره نیاز واقعی، مقدارهای مناسب را تنظیم کنید؛ post_max_size را بزرگ‌تر از upload_max_filesize بگذارید. تغییر را با Apply ذخیره کنید.

۴. به پیشخوان برگردید، صفحه رسانه و صفحه بارگذاری افزونه را دوباره باز کنید و عدد نمایش‌داده‌شده را ببینید. نمایش عدد جدید می‌تواند نشانه اعمال تنظیم باشد، اما به‌تنهایی ثابت نمی‌کند لایه‌های دیگر مانند وب‌سرور یا CDN هم همان محدودیت را دارند. اکنون همان فایل را یک بار دیگر نصب کنید.

۵. اگر عدد تغییر نکرد، به جای افزودن فایل‌های متعدد php.ini یا تغییرهای تصادفی، بررسی کنید دامنه درست و نسخه PHP وب را انتخاب کرده‌اید. نسخه PHP فرمانی با نسخه‌ای که وب‌سایت استفاده می‌کند ممکن است متفاوت باشد. در هاست اشتراکی ممکن است میزبان محدودیتی بالاتر از تنظیم شما اعمال کرده باشد.

در بعضی سرویس‌ها تغییرات ممکن است چند دقیقه طول بکشد یا گزینه‌ها نام متفاوتی داشته باشند. برای DirectAdmin یا پنل دیگر، دنبال بخش تنظیمات PHP مربوط به همان دامنه بگردید؛ محل و امکان ویرایش به نسخه پنل و تنظیم ارائه‌دهنده بستگی دارد. اگر تنظیمی در دسترس نیست، فایل پیکربندی دلخواه و دستورهای مربوط به سرور اختصاصی را کورکورانه روی هاست اشتراکی اجرا نکنید.

اندازه دقیق فایل، سقفی که وردپرس نشان می‌دهد، نام دامنه، زمان آزمایش و متن خطا را برای پشتیبانی میزبانی بفرستید و مشخصاً بپرسید: «سقف upload_max_filesize و post_max_size برای PHP وب این دامنه چقدر است و آیا محدودیت کوچک‌تری در وب‌سرور یا پراکسی وجود دارد؟» فایل wp-config.php، رمزها و خروجی کامل تنظیمات PHP را ارسال نکنید.

اگر آپلود مدت زیادی در حال انجام است و بعد قطع می‌شود، علاوه بر اندازه، سرعت اتصال و محدودیت زمان دریافت را هم در نظر بگیرید. تنظیم max_input_time در PHP می‌تواند بر زمان دریافت داده اثر بگذارد؛ اما زمان‌سنج وب‌سرور، CDN یا خود مرورگر هم ممکن است دخیل باشد. مقدارها و محدودیت‌ها را بر اساس علت مشاهده‌شده تنظیم کنید، نه اینکه همه زمان‌ها را بی‌نهایت بگذارید.

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

در نسخه آزمایشی، با همان حساب مدیر، صفحه نصب را دوباره باز کنید و درخواست را یک بار دیگر بفرستید. در Chrome یا Edge با F12 و بخش Network، درخواست مربوط به بارگذاری را پیدا کنید. ستون وضعیت می‌تواند سرنخ بدهد: پاسخ 413 معمولاً یعنی جایی درخواست را به دلیل اندازه نپذیرفته؛ پاسخ 403 می‌تواند از مجوز، افزونه امنیتی یا دیواره آتش باشد؛ پاسخ 500 نشان می‌دهد باید خطای برنامه یا سرور را در گزارش مربوط ببینید. نمایش پیام وردپرس بدون این کدها هم ممکن است و هر کد علت قطعی را به‌تنهایی مشخص نمی‌کند.

اگر Network خالی است، پیش از کلیک نصب، ابزار را باز کنید و صفحه را تازه بارگذاری کنید؛ سپس دوباره فایل را انتخاب کنید. برای 413 سراغ سقف درخواست در PHP و سپس وب‌سرور یا پراکسی بروید. برای 403 زمان دقیق و مسیر بدون اطلاعات محرمانه را با گزارش افزونه امنیتی یا دیواره آتش همان زمان مقایسه کنید؛ اجازه عبور دائمی و عمومی برای همه درخواست‌ها ایجاد نکنید. برای 500 در نسخه آزمایشی گزارش خطای PHP یا گزارش دامنه در کنترل‌پنل را در همان دقیقه باز کنید و متن خطا را بدون اطلاعات محرمانه نگه دارید. اگر پاسخ 200 است اما صفحه وردپرس باز هم پیام منقضی‌شدن می‌دهد، کد موفق HTTP به معنی نصب موفق افزونه نیست؛ نشست مدیر، صفحه تازه و محتوای پاسخ را نیز بررسی کنید.

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

اطلاعات نشست، کوکی‌ها، نشانه امنیتی، رمز و محتوای فرم را در تصویر Network یا پیام پشتیبانی منتشر نکنید. برای شروع، زمان، مسیر درخواست بدون پارامترهای حساس و کد وضعیت معمولاً کافی است.

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

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

منابع: راهنمای محدودیت آپلود PHP، توضیح تنظیم‌های PHP در cPanel و پشتیبانی وردپرس درباره رد درخواست بارگذاری.