learn

رفع خطای 404 وردپرس در هاست ویندوز و IIS؛ اصلاح web.config

اگر صفحهٔ اصلی باز می‌شود اما نوشته‌ها در IIS خطای ۴۰۴ دارند، ابتدا بازنویسی مسیر را بررسی کنید؛ کد PHP نباید داخل web.config قرار گیرد.

خطای 404 وردپرس در هاست ویندوز همیشه از حذف نوشته ناشی نمی‌شود. وقتی صفحهٔ اصلی باز است اما بیشتر پیوندهای خوانا خطا دارند، تنظیم URL Rewrite در IIS یکی از موارد مهم برای بررسی است. ابتدا علت را مشخص کنید و ساختار URLهای موجود را برای دورزدن مشکل تغییر ندهید.

تشخیص خطای 404 وردپرس در هاست ویندوز

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

کد وضعیت و زیرکد ثبت‌شده در لاگ IIS به تشخیص کمک می‌کند. خطای خود وردپرس با رد درخواست در وب‌سرور یکسان نیست. زمان و URL نمونه را برای میزبان بفرستید، اما مسیرهای خصوصی یا جزئیات کامل سرور را در صفحهٔ عمومی منتشر نکنید.

پیش‌نیازهای IIS را بررسی کنید

این راهنما مخصوص IIS است؛ انتخاب فایل تنظیمات فقط به ویندوز یا لینوکس وابسته نیست. Apache معمولاً از .htaccess استفاده می‌کند و Nginx سازوکار دیگری دارد. در IIS، ماژول URL Rewrite باید برای سایت قابل‌استفاده باشد.

بررسی پشتیبانی پیوندهای یکتا در هستهٔ وردپرس به وجود DOMDocument، ماژول بازنویسی و اجرای PHP از طریق FastCGI توجه می‌کند. ایجاد یک فایل خالی web.config به‌تنهایی این پیش‌نیازها را فراهم نمی‌کند.

ابتدا قواعد پیوند یکتا را تازه کنید

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

طبق مرجع ذخیرهٔ قواعد IIS، وردپرس در شرایط پشتیبانی‌شده و با مجوز نوشتن مناسب می‌تواند web.config را به‌روزرسانی کند. اگر این کار ممکن نیست، مشکل دسترسی را با مدیر هاست حل کنید؛ دسترسی کامل به همهٔ کاربران راه‌حل مناسبی نیست.

نمونهٔ صحیح web.config

نمونهٔ زیر برای نصب عادی تک‌سایتی است که index.php در محدودهٔ همین فایل قرار دارد. اگر web.config موجود است، کل فایل را با این نمونه جایگزین نکنید؛ قاعده را با تنظیمات قبلی ادغام کنید و تگ یا نام قاعدهٔ تکراری نسازید.

<configuration>
  <system.webServer>
    <rewrite>
      <rules>
        <rule name="WordPress" patternSyntax="Wildcard" stopProcessing="true">
          <match url="*" />
          <conditions logicalGrouping="MatchAll">
            <add input="{REQUEST_FILENAME}" matchType="IsFile" negate="true" />
            <add input="{REQUEST_FILENAME}" matchType="IsDirectory" negate="true" />
          </conditions>
          <action type="Rewrite" url="index.php" />
        </rule>
      </rules>
    </rewrite>
  </system.webServer>
</configuration>

این ساختار از قاعدهٔ بازنویسی وردپرس برای IIS پیروی می‌کند: درخواستِ فایل یا پوشهٔ واقعی کنار گذاشته می‌شود و مسیرهای دیگر به index.php می‌رسند. در نصب زیرپوشه، ریشهٔ متفاوت یا شبکه، باید محدوده و مقصد با همان نصب تطبیق داده شود.

کد PHP را داخل web.config نگذارید

web.config فایل XML پیکربندی است. دستور PHP مانند تغییر مقدار REQUEST_URI با UNENCODED_URL نباید به انتهای آن اضافه شود. چنین ترکیبی می‌تواند پیکربندی را نامعتبر کند؛ این قطعه‌کد راه‌حل عمومی خطای ۴۰۴ نیست.

کوتیشن‌ها باید مستقیم باشند و تگ‌ها درست بسته شوند. در مرجع URL Rewrite مایکروسافت، محدودهٔ قواعد نسبت به محل web.config تعریف می‌شود. Rewrite داخلی با Redirect که مرورگر را به نشانی دیگری می‌فرستد تفاوت دارد.

اگر خطا به 500.19 تبدیل شد

تغییر تازه را برگردانید و کد HRESULT را بررسی کنید. طبق راهنمای مایکروسافت، XML نامعتبر، ماژول نصب‌نشده، بخش قفل‌شده، مجوز نامناسب یا ورودی تکراری می‌توانند علت باشند. ریدایرکت همهٔ خطاها به صفحهٔ اصلی این مشکل را رفع نمی‌کند.

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

مطالعهٔ مرتبط

بازبینی فنی: ۱۳ آبان ۱۴۰۵. تاریخ انتشار اولیه و نشانی قبلی حفظ شده‌اند.

مطالب مرتبط

دیدگاهتان را بنویسید

نشانی ایمیل شما منتشر نخواهد شد. بخش‌های موردنیاز علامت‌گذاری شده‌اند *

فهرست مطالب