خطای 405 وردپرس با پیام Method Not Allowed یعنی روش HTTP درخواست برای منبع هدف پشتیبانی نمی‌شود. برای مثال، یک مسیر ممکن است GET را بپذیرد اما درخواست POST فرم را رد کند. این وضعیت با نبود صفحه در 404 یا ممنوعیت دسترسی در 403 یکسان نیست.
پیش از رفع خطای 405 وردپرس چه چیزی ثبت کنیم؟
عملیات ناموفق، زمان، نشانی مقصد و روش درخواست را مشخص کنید. طبق تعریف 405، پاسخ باید هدر Allow داشته باشد که روش‌های پشتیبانی‌شده را اعلام می‌کند. نبود این هدر یا ظاهر صفحهٔ خطا به‌تنهایی مشخص نمی‌کند کدام لایه پاسخ را ساخته است؛ برنامه، وب‌سرور و پراکسی را با شواهد تفکیک کنید.
بررسی فرم یا API در مرورگر
- ابزار توسعه و بخش Network را پیش از اجرای عملیات باز کنید.
- فرم یا درخواست ناموفق را یک بار در محیط مناسب اجرا کنید.
- Request URL، Request Method، پاسخ و Allow را ببینید.
- مسیر را با action فرم یا نشانی مستند سرویس مقایسه کنید.
بازکردن URL در نوار آدرس معمولاً GET می‌فرستد؛ موفقیت آن ثابت نمی‌کند POST همان مسیر کار می‌کند. در درخواست‌های حساس مانند سفارش، پرداخت یا ارسال پیام، تکرار بی‌برنامهٔ درخواست ممکن است اثر تکراری ایجاد کند؛ آزمایش را روی محیط تست یا عملیات بی‌اثر انجام دهید.
راهنمای Network برای مشاهدهٔ زنجیرهٔ درخواست مفید است. ریدایرکت میان دامنه، اسلش یا مسیر قدیمی را هم بررسی کنید؛ مقصد نهایی ممکن است با مسیر مورد انتظار فرم فرق کند.
تغییر اخیر را هدفمند بررسی کنید
اگر مشکل پس از آپدیت فرم، افزونه یا کد اختصاصی شروع شده، نسخه، مسیر و روش مورد انتظار آن مؤلفه را بررسی کنید. روی کپی تست، تنها مؤلفهٔ مرتبط را ایزوله و نتیجه را مقایسه کنید. حذف همهٔ افزونه‌ها، کاهش نسخهٔ هسته یا دست‌کاری جدول‌ها بدون شواهد می‌تواند مشکل دیگری بسازد.
برای API، روش را طبق مستند endpoint انتخاب کنید؛ تبدیل POST به GET فقط برای حذف پیام خطا می‌تواند هم عملکرد و هم نحوهٔ نگهداری داده را اشتباه کند. اگر درخواست OPTIONS مربوط به بررسی مقدماتی CORS شکست خورده، تنظیم همان مسیر و مبدأهای مجاز باید بررسی شود.
قواعد وب‌سرور و لایهٔ امنیتی
اگر لاگ نشان می‌دهد پاسخ پیش از رسیدن به وردپرس ساخته شده، قواعد روش HTTP، مسیر، پراکسی یا حفاظت میزبان را بررسی کنید. تنها قانون شناسایی‌شده باید توسط مسئول سرویس اصلاح شود؛ فایروال و همهٔ محدودیت‌های روش را برای رفع یک خطا خاموش نکنید.
در Apache، قواعد .htaccess ممکن است دخیل باشند، اما وجود این فایل اثبات نوع وب‌سرور نیست. مسیر نصب برای همه /home/public_html نیست. Nginx قواعد .htaccess را اجرا نمی‌کند؛ اصلاح باید در تنظیم واقعی سرویس انجام شود.
لاگ مناسب و تأیید نتیجه
محل لاگ در همهٔ هاست‌ها یک پوشهٔ logs داخل public_html نیست. از ابزار پنل یا میزبان، access log و error log مربوط به همان دامنه و زمان را بگیرید. روش، مسیر، وضعیت و شناسهٔ درخواست را مقایسه کنید و اطلاعات نشست یا فرم خصوصی را عمومی نفرستید.
بعد از اصلاح، همان عملیات مجاز را دوباره آزمایش کنید. موفقیت باید هم در پاسخ HTTP و هم در نتیجهٔ مورد انتظار فرم یا API دیده شود. روش‌هایی که عمداً پشتیبانی نمی‌شوند لازم نیست صرفاً برای سبزشدن آزمون، مجاز شوند.
مطالعهٔ مرتبط
بازبینی فنی: ۱۳ آبان ۱۴۰۵. تاریخ انتشار اولیه و نشانی قبلی حفظ شده‌اند.
