روابط ووردبريس المعطلة: إعادة إنشاء ملف .htaccess بسرعة

by | WordPress

إذا ظهرت فجأة رسالة خطأ 404 في مقالاتك بينما تعمل الصفحة الرئيسية، فمن المرجح أنك تواجه مشكلة في قواعد إعادة الكتابة - وبالتالي روابط دائمة "معطلة". WordPress 6.9.4، التصحيح الأكثر شيوعًا هو إعادة إنشاء القواعد، وفي Apache، إعادة كتابة الملف .htaccess (متى WordPress له الحق في القيام بذلك).

المشكلة

العرض النموذجي: عناوين URL "النظيفة" الخاصة بك (على سبيل المثال /mon-article/لم تعد الروابط تشير إلى محتواك. تعمل لوحة التحكم، لكن واجهة المستخدم تُظهر خطأ 404، أو أحيانًا خطأ في الخادم.

إليك بعض الرسائل الواقعية التي قد تراها:

# Dans le navigateur (front-end)
404 Not Found

# Dans certains logs Apache/Nginx (selon config)
rewrite or internal redirection cycle while internally redirecting to "/index.php"

# Dans WordPress / Site Health (selon hébergeur)
Le fichier .htaccess n'est pas accessible en écriture.

أين يظهر:

  • الواجهة الأمامية : صفحات، مقالات، فئات، صفحات منتجات WooCommerce التي تحتوي على أخطاء 404.
  • REST API (أحيانًا): نقاط النهاية التي تتوقف عن الاستجابة إذا تعطلت عملية إعادة الكتابة على جانب الخادم.
  • إداري غالباً لا توجد مشكلة... مما يجعل الخلل محيراً.

الظروف النموذجية التي أراها غالبًا عند استكشاف الأخطاء وإصلاحها:

  • بعد هجرة (خادم جديد، نطاق جديد، تحويل HTTP → HTTPS).
  • بعد تفعيل/تعطيل إضافة تقوم بتحديد المسارات (تحسين محركات البحث، التخزين المؤقت، الأمان، ووكومرس، نظام إدارة التعلم).
  • بعد تغيير في تكوين الخادم (التحويل من Apache إلى Nginx، أو إضافة جدار حماية لتطبيقات الويب).
  • بعد "تنظيف" الخادم وحذف الملفات .htaccess عن غير قصد.

لمن هذا الدليل؟ إذا كنت مبتدئًا في استخدام ووردبريس (الإصدار 6.9.4 اعتبارًا من أبريل 2026) وترغب في... استعادة الروابط الدائمة دون إحداث أي خلل في موقعك. في النهاية، ستعرف:

  • حدد ما إذا كانت المشكلة ناتجة عن ووردبريس (القواعد) أو عن الخادم (.htaccess(Nginx).
  • قم بإعادة إنشاء قواعد الروابط الدائمة بشكل نظيف (بدون "تفريغ" غير ضروري في كل صفحة).
  • أضف زر "نقرة واحدة" في لوحة التحكم، مع رمز التحقق (للحماية من هجمات تزوير الطلبات عبر المواقع) وعمليات التحقق.
  • استخدم WP-CLI لإصلاح الأمور بسرعة، خاصة في بيئة الإنتاج.

ملخص سريع

  • الحل الأكثر أماناً: الإعدادات ← الروابط الدائمة ← حفظ (حتى بدون تغيير أي شيء). هذا يُعيد إنشاء القواعد على جانب ووردبريس ويحاول إعادة كتابتها .htaccess على أباتشي.
  • Si .htaccess غير قابل للكتابة: صحيح الأذونات/المالكأو الصق القواعد يدويًا.
  • في إنجن إكس, .htaccess هذا غير مجدٍ: يلزم وجود تكوين صحيح لـ Nginx (try_files).
  • تجنب الرمي flush_rewrite_rules() في كل مرة يتم تحميلها: فإنها تؤثر سلبًا على الأداء.
  • في الإنتاج، الطريقة الأنظف هي: WP-CLI (wp rewrite flush).

الأعراض

أكثر العلامات شيوعاً عند تعطل الروابط الدائمة:

  • خطأ 404 في المقالات/الصفحات لكن الصفحة الرئيسية تعمل.
  • خطأ 404 في /category/...، /tag/…, /author/…
  • WooCommerce : صفحات المنتجات التي تعرض أخطاء 404، وصفحات سلة التسوق/الطلبات التي تعيد التوجيه بشكل غير صحيح.
  • متعدد اللغات : لغة واحدة فقط تعمل (غالباً اللغة الافتراضية)، أما اللغات الأخرى فتعيد خطأ 404.
  • عمليات إعادة توجيه غريبة : الالتفاف نحو /index.php أو إلى الصفحة الرئيسية.
  • خطأ 500 مباشرة بعد "اللمس" .htaccess (قاعدة غير صالحة).
  • REST API : بعض نقاط النهاية تُرجع 404/401 على الرغم من أن المسؤول يعمل بشكل صحيح (غالبًا ما يكون ذلك مرتبطًا بإعادة كتابة أو جدار حماية تطبيقات الويب).
  • يعمل محلياً (MAMP/Laragon) ولكن ليس في بيئة الإنتاج: وحدة Apache مفقودة، أو تكوين Nginx مختلف، أو أذونات مختلفة.

توافق مُنشئ الصفحات: Divi 5. لا يقوم كل من Elementor وAvada بتعطيل الروابط الدائمة تلقائيًا، ولكنهما يعتمدان بشكل كبير على عناوين URL الثابتة (القوالب، والملفات، والمعاينات). عند مخالفة هذه القواعد، ستلاحظ أيضًا ما يلي:

  • Elementor : لم يتم تحميل المعاينة بشكل صحيح، خطأ 404.
  • ديفي 5 أداة إنشاء مرئية تقوم بالتكرار أو إرجاع صفحة غير موجودة.
  • فتح : لا يعرض برنامج Fusion Builder الصفحة المتوقعة في المعاينة.

لماذا وصلت؟

نسخة المبتدئين: يحتاج ووردبريس إلى "ترجمة" عناوين URL الجميلة الخاصة بك (/mon-article/) في استعلام داخلي (index.php?name=mon-articleتمت هذه الترجمة باستخدام إعادة كتابة القواعدفي أباتشي، تُكتب هذه القواعد عادةً بلغة .htaccess.

النسخة التقنية: يقوم ووردبريس بإنشاء قواعد إعادة الكتابة عبر WP_Rewrite وتخزينها في قاعدة البيانات (خيار) rewrite_rulesثم، بحسب الخادم:

  • Apache يحاول ووردبريس كتابة كتلة بين # BEGIN WordPress et # END WordPress في .htaccessمرتكز على mod_rewrite.
  • إنجن إكس : .htaccess يتم تجاهل ذلك. تتم إعادة الكتابة في إعدادات Nginx (غالبًا). try_files).
  • IIS القواعد في web.config (أصبحت نادرة اليوم).

الأسباب المحتملة (من الأكثر شيوعاً إلى الأقل شيوعاً):

  • 1) إعادة كتابة القواعد التي لم يتم "تحديثها" بعد إجراء تغيير (تفعيل المكون الإضافي، نوع المنشور المخصص، التصنيف، الترحيل).
  • 2) تم حذف/تلف ملف .htaccess أو كتلة ووردبريس معدلة يدويًا.
  • 3) الأذونات/المالك منع ووردبريس من الكتابة .htaccess.
  • 4) خادم غير متوافق : mod_rewrite عاجز، AllowOverride None على خادم Apache، أو خادم Nginx مُهيأ بشكل خاطئ.
  • 5) تعارض بين إضافات التخزين المؤقت/الأمان والتي تقوم بإدخال قواعد عدوانية (أو جدار حماية تطبيقات الويب الذي يقوم بالحظر).
  • 6) قاعدة عنوان URL سيئة (siteurl/home) بعد الترحيل: عمليات إعادة التوجيه وأخطاء 404 المتتالية.
  • 7) إعادة كتابة مخصصة تمت إضافته إلى القالب/الإضافة ولكن تم تنفيذ عملية "التنظيف" في الوقت الخطأ.

جدول التشخيص (سريع)

عرض السبب المحتمل التحقق الحلول
خطأ 404 في المقالات/الصفحات، الصفحة الرئيسية تعمل لم يتم إعادة إنشاء القواعد الإعدادات ← الروابط الدائمة ← حفظ حل 1
خطأ 404 في كل مكان باستثناء /wp-admin ملف .htaccess مفقود أو تم تكوين Nginx بشكل غير صحيح وجود ملف .htaccess (في Apache) / إعدادات Nginx الحل الثالث + "إذا لم ينجح ذلك أيضاً"
خطأ 500 بعد تعديل ملف .htaccess بناء جملة غير صحيح / توجيه محظور سجلات الخادم، ارجع استعادة ملف .htaccess، الحل 1
يقول ووردبريس: "ملف .htaccess غير قابل للكتابة". الأذونات/المالك بروتوكول نقل الملفات/SSH: الأذونات والمالك قم بتصحيح الحقوق، أو الصق القواعد يدويًا.
في Nginx، لا يغير "النقرة الواحدة" أي شيء. تم تجاهل ملف .htaccess تحقق من الخادم (Nginx) قم بتكوين try_files (قسم مخصص)

المتطلبات الأساسية قبل البدء

  • حماية : الملفات + قاعدة البيانات. لا تقم أبدًا باستكشاف الأخطاء وإصلاحها "بشكل أعمى" في بيئة الإنتاج.
  • وصول كحد أدنى، لوحة تحكم ووردبريس. والأفضل استخدام بروتوكول نقل الملفات (FTP/SFTP) أو بروتوكول SSH.
  • إصدارات ووردبريس 6.9.4، PHP 8.1+ (موصى به). قد يتسبب استخدام إصدار قديم من PHP في حدوث أخطاء إضافية.
  • أدوات مفيدة :

لتمكين تصحيح الأخطاء بشكل صحيح (مؤقتًا)، قم بالتحرير wp-config.php وإضافة/تعديل:

// wp-config.php
// Sauvegardez avant de modifier. Ne laissez pas WP_DEBUG actif en permanence sur un site public.

define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );     // Log dans wp-content/debug.log
define( 'WP_DEBUG_DISPLAY', false );

الوثائق الرسمية: تصحيح أخطاء ووردبريس.

الحل الأول: إعادة إنشاء ملف .htaccess عبر الإعدادات ← الروابط الدائمة (الطريقة الأكثر أمانًا بنقرة واحدة)

هذه هي الطريقة الأكثر موثوقية للمبتدئين، وهي التي أستخدمها أولاً في 80% من الحالات. فهي تعيد إنشاء قواعد إعادة كتابة ووردبريس، وفي أباتشي، تعيد كتابة كتلة ووردبريس في .htaccess إذا سمحت الأذونات بذلك.

خطوات (بدون كتابة أكواد)

  1. اذهب الإعدادات ← الروابط الدائمة.
  2. دون تغيير أي شيء، انقر على حفظ التغييرات.
  3. اختبر عنوان URL للمقال في وضع التصفح الخاص (لتجنب التخزين المؤقت للمتصفح).

ما يحدث خلف الكواليس: يقوم ووردبريس "بمسح" قواعده (يعيد توليدها وحفظها) rewrite_rules) ويحاول كتابة كتلة ووردبريس في .htaccess (أباتشي). الوظيفة الأساسية على جانب ووردبريس موثقة هنا: flush_rewrite_rules().

مشكلة شائعة: لا يستطيع ووردبريس كتابة ملف .htaccess

إذا عرض ووردبريس ذلك .htaccess إذا لم يكن قابلاً للكتابة، فلديك خياران:

  • الخيار أ (موصى به) : قم بتصحيح الأذونات/المالك عبر مزود الاستضافة الخاص بك (تجنب ترك حقوق مفتوحة بشكل مفرط).
  • الخيار ب : انسخ/ألصق الكتلة التي يوفرها ووردبريس يدويًا في .htaccess.

هذا قالب ووردبريس (أباتشي) قياسي ستجده مُتاحًا في كثير من الأحيان. ملاحظة: قد يختلف هذا القالب باختلاف المجلدات الفرعية، وإعدادات المواقع المتعددة، وما إلى ذلك. لا تنسخ هذا القالب إذا كان تثبيت ووردبريس الخاص بك موجودًا في مجلد فرعي دون تعديله.

# Exemple de bloc WordPress typique (Apache)
# BEGIN WordPress
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteRule .* - [E=HTTP_AUTHORIZATION:%{HTTP:Authorization}]
RewriteBase /
RewriteRule ^index.php$ - [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]
</IfModule>
# END WordPress

إذا كنت متأكدًا إنجن إكسلا تضيع وقتك مع .htaccess : انتقل مباشرة إلى قسم "إذا لم ينجح الأمر بعد" (جزء Nginx).

الكود قبل/بعد (خطأ كلاسيكي: تنفيذ الأمر flush في المكان الخطأ)

كثيراً ما رأيت هذه المشكلة في المواقع التي يقوم فيها شخص ما بنسخ جزء "سحري" موجود في منتدى ولصقه في functions.phpالنتيجة: يقوم ووردبريس بإعادة إنشاء القواعد في كل صفحة، مما قد يؤدي إلى إبطاء الموقع بشكل كبير (وأحيانًا يخلق آثارًا جانبية).

قبل (معطل: شطف في كل غسلة)

أين توقف؟ functions.php من القالب (غالباً) أو من إضافة مقتطفات برمجية.

<?php
// Mauvaise pratique : flush des permaliens à chaque page.
// J'ai déjà vu ça faire exploser le TTFB sur des sites un peu chargés.

add_action( 'init', function () {
	flush_rewrite_rules();
} );

بعد (تم التصحيح: يتم التنظيف مرة واحدة فقط عند التفعيل)

مكان اللصق: إنشاء إضافة صغيرة (موصى به) في wp-content/plugins/bpcab-rewrite-fix/bpcab-rewrite-fix.phpثم فعّله. تجنّب وضع هذا في القالب: تغيير القالب سيؤدي إلى تعطيل الإصلاح.

<?php
/**
 * Plugin Name: BPCAB - Flush permaliens à l'activation
 * Description: Régénère les règles de réécriture une seule fois à l'activation (WordPress 6.9.4+).
 * Version: 1.0.0
 */

defined( 'ABSPATH' ) || exit;

/**
 * Hook d'activation : déclenché une seule fois quand le plugin est activé.
 * Ici, on régénère les règles proprement.
 */
register_activation_hook( __FILE__, function () {
	// true = écrit aussi les règles dans .htaccess si possible (Apache)
	flush_rewrite_rules( true );
} );

/**
 * Hook de désactivation : optionnel, mais propre.
 */
register_deactivation_hook( __FILE__, function () {
	flush_rewrite_rules( true );
} );

لماذا يحل هذا المشكلة؟ لأنك تقوم فقط بتفريغ البيانات عند الضرورة (عند تغيير القواعد)، وليس مع كل طلب. الخطاف register_activation_hook هي آلية في ووردبريس تقوم بتنفيذ وظيفة عند تفعيل إضافة.

وثائق: خطافات التفعيل/إلغاء التفعيل.

الحل الثاني: إضافة زر "إعادة إنشاء ملف .htaccess" في لوحة التحكم (بدون إضافة).

هل ترغب في حلٍّ حقيقي بنقرة واحدة في لوحة التحكم، قابل لإعادة الاستخدام عند نقل البيانات أو بعد إجراء تغييرات معينة؟ إليك حلٌّ أنيق: صفحة أدوات في لوحة التحكم تُجري عملية مسح البيانات، محمية بواسطة قدرة (الحقوق) و السفير البابوي.

حيث :

  • الحركة (الخطاف) : النقطة التي يقوم فيها ووردبريس بتنفيذ الكود (على سبيل المثال admin_menu).
  • القدرات : إذن المستخدم (على سبيل المثال) manage_options (للمسؤولين).
  • مناسبة حالية رمز مضاد لهجمات تزوير الطلبات عبر المواقع (CSRF) لمنع موقع خارجي من تنفيذ الإجراء نيابةً عنك.

أين يتم لصق الكود : إنشاء مو البرنامج المساعد (إضافة إلزامية الاستخدام) بحيث تظل نشطة حتى إذا قمت بتغيير القوالب/الإضافات.

  • طريق : wp-content/mu-plugins/bpcab-oneclick-htaccess.php
  • إذا كان الملف mu-plugins غير موجود، قم بإنشائه.

احفظ الملف قبل التعديلقد يؤدي خطأ في بناء جملة PHP إلى حظر لوحة التحكم.

الكود الكامل (صفحة الأدوات ← إعادة إنشاء الروابط الدائمة)

<?php
/**
 * MU Plugin: BPCAB - Régénérer les permaliens en un clic
 * Description: Ajoute une page dans Outils permettant de régénérer les règles de réécriture (.htaccess sur Apache).
 * Compatibilité: WordPress 6.9.4+, PHP 8.1+
 */

defined( 'ABSPATH' ) || exit;

/**
 * Ajoute une page dans le menu "Outils".
 */
add_action( 'admin_menu', function () {
	add_management_page(
		'Régénérer les permaliens',
		'Régénérer les permaliens',
		'manage_options',
		'bpcab-rewrite-flush',
		'bpcab_render_rewrite_flush_page'
	);
} );

/**
 * Affiche la page et gère l'action sécurisée.
 */
function bpcab_render_rewrite_flush_page() {
	if ( ! current_user_can( 'manage_options' ) ) {
		wp_die( 'Accès refusé.' );
	}

	$did_flush = false;

	// Si le formulaire a été soumis, on vérifie le nonce.
	if ( isset( $_POST['bpcab_rewrite_flush'] ) ) {
		check_admin_referer( 'bpcab_rewrite_flush_action', 'bpcab_rewrite_flush_nonce' );

		// Régénère les règles et tente d'écrire .htaccess (Apache).
		flush_rewrite_rules( true );

		$did_flush = true;
	}

	echo '<div class="wrap">';
	echo '<h1>Régénérer les permaliens</h1>';

	if ( $did_flush ) {
		echo '<div class="notice notice-success is-dismissible"><p><strong>OK</strong> : règles de réécriture régénérées.</p></div>';
	}

	echo '<p>Utilisez ce bouton si vos URL renvoient des 404 après une migration, un changement de plugin, ou une modification de structure d’URL.</p>';
	echo '<p><strong>Attention</strong> : sur Nginx, ce bouton régénère les règles côté WordPress, mais ne remplace pas une configuration serveur correcte.</p>';

	echo '<form method="post">';
	wp_nonce_field( 'bpcab_rewrite_flush_action', 'bpcab_rewrite_flush_nonce' );
	echo '<p><button type="submit" class="button button-primary" name="bpcab_rewrite_flush" value="1">Régénérer maintenant</button></p>';
	echo '</form>';

	echo '<hr />';
	echo '<h2>Vérification rapide</h2>';
	echo '<ol>';
	echo '<li>Ouvrez un article au hasard dans un nouvel onglet.</li>';
	echo '<li>Si vous utilisez un plugin de cache, videz son cache.</li>';
	echo '<li>Testez en navigation privée.</li>';
	echo '</ol>';

	echo '</div>';
}

لماذا يُعتبر هذا الحل "آمناً"؟

  • إنها تطالب إدارة الخيارات (مسؤول).
  • يحمي المخزون بـ السفير البابوي (وإلا، فإن أي رابط خارجي قد يتسبب في حدوث عملية مسح البيانات إذا كنت مسجلاً الدخول).
  • إنها لا تنفذ flush_rewrite_rules() ذلك بناءً على الطلب، ليس في كل صفحة.

مرجع المبعوث البابوي: الراهبات.

التوافق مع Divi 5 / Elementor / Avada

لا توجد تبعيات: إنها صفحة في لوحة التحكم. في مواقع البناء، أنصح بمسح ما يلي أيضًا:

  • ذاكرة التخزين المؤقت للمنشئ (Elementor: إعادة إنشاء CSS والبيانات إذا لزم الأمر، Divi: خيارات الأداء، Avada: ذاكرة التخزين المؤقت/التجميع).
  • ذاكرة التخزين المؤقت لمكونات الأداء الإضافية (LiteSpeed ​​Cache، WP Rocket، إلخ).

الحل الثالث: WP-CLI (سريع، نظيف، مثالي للإنتاج)

عند توفر وصول SSH، غالبًا ما تكون WP-CLI هي أسرع طريقة، خاصةً في بيئة الإنتاج حيث يُفضّل تجنّب النقر للوصول إلى لوحة التحكم. WP-CLI هي أداة سطر الأوامر الرسمية لإدارة ووردبريس. أوامر WP-CLI.

أوامر مفيدة

من الدليل الرئيسي لـ WordPress:

# 1) Vérifier que WP-CLI voit bien le site
wp core version

# 2) Flush des règles de réécriture
wp rewrite flush --hard

# 3) (Optionnel) Lister les règles pour debug
wp rewrite list --format=table

ما الذي يفعله - صعب يطلب تنظيفًا "قويًا"، ويحاول أيضًا الكتابة على موقع أباتشي. .htaccess (عند الإمكان). إذا كنت تستخدم Nginx، فإن هذا لا "يصلح" Nginx، ولكنه يُحسّن القواعد على جانب WordPress.

الكود قبل/بعد (حالة واقعية: نص برمجي غير مكتمل للنشر)

لقد رأيتُ مسارات التكامل المستمر/التسليم المستمر (CI/CD) تنشر ووردبريس (أو قالبًا) وتنسى تحديث الصفحة بعد إضافة نوع منشور مخصص (CPT). والنتيجة: كل شيء يعمل في بيئة الاختبار، ولكن يظهر خطأ 404 في بيئة الإنتاج.

قبل (النشر بدون شطف)

# Script de déploiement (extrait)
composer install --no-dev
wp plugin activate mon-plugin-cpt
# Oubli : pas de flush, les nouvelles routes ne répondent pas

بعد (تدفق مُتحكم به)

# Script de déploiement (extrait)
composer install --no-dev
wp plugin activate mon-plugin-cpt
wp rewrite flush --hard

لماذا ينجح هذا الحل: تقوم بمزامنة حالة "الرمز" (CPT/التصنيفات/المسارات) مع حالة "قواعد إعادة الكتابة" في الوقت المناسب.

عمليات التحقق بعد التصحيح

بعد التجديد، تحقق من التالي بطريقة قابلة للتكرار:

  1. افتح مقالاً وصفحة تصفح خاص.
  2. اختبر أرشيفًا (فئة / علامة) وصفحة نظام (على سبيل المثال /wp-sitemap.xml (في حالة التفعيل).
  3. إذا كنت تستخدم WooCommerce: اختبر منتجًا + سلة التسوق.
  4. مسح ذاكرة التخزين المؤقت:
    • إضافة التخزين المؤقت (WP Rocket، LiteSpeed ​​Cache، إلخ).
    • ذاكرة التخزين المؤقت للخادم (إذا كان مزود خدمة الاستضافة الخاص بك يمتلك واحدة).
    • ذاكرة التخزين المؤقت لشبكة توصيل المحتوى (Cloudflare، إلخ).
  5. بحث wp-content/debug.log إذا قمت بتمكين WP_DEBUG.

إذا كنت تستخدم Query Monitor، فتحقق مما إذا كان الاستعلام يُرجع 404 بسبب "استعلام رئيسي" لا يتطابق مع أي شيء (يحدث هذا عندما لا تكون القاعدة موجودة).

إذا لم ينجح ذلك أيضاً

هنا، نتجاوز "نقرة واحدة": إذا ظلت روابطك الدائمة معطلة بعد مسح الذاكرة، فغالبًا ما تكون المشكلة في الخادم، أو ذاكرة التخزين المؤقت القوية، أو قاعدة بيانات عناوين URL غير المتناسقة.

الخطوة 1: تحديد الخادم الخاص بك (أباتشي أو إنجينكس)

  • في العديد من أماكن الإقامة، يتم الإشارة إلى ذلك في اللافتة.
  • يمكنك أيضًا الاطلاع على رؤوس HTTP (أداة "فحص" المتصفح → الشبكة): Server: nginx ou Server: Apache (ليست موثوقة دائماً).

الخطوة الثانية: إذا كنت تستخدم Nginx، فقم بتصحيح الإعدادات (وإلا فإن ملف .htaccess سيكون عديم الفائدة).

إعدادات Nginx الكلاسيكية لـ WordPress (مثال عام). ستحتاج إلى صلاحية الوصول الخاصة بمزود الاستضافة إذا لم تكن لديك هذه الصلاحية.

# Exemple Nginx (à adapter)
location / {
	try_files $uri $uri/ /index.php?$args;
}

بدون هذا try_filesيمكنك مسح البيانات بقدر ما تريد: لن يقوم Nginx بتمرير عناوين URL إلى WordPress بشكل صحيح.

الخطوة 3: التحقق من ملف .htaccess (أباتشي)

  • الملف .htaccess يجب أن يكون موجودًا في الدليل الرئيسي لـ WordPress (حيث wp-config.php).
  • يجب أن يكون قالب ووردبريس صالح وغير مكرر.
  • يجب أن يسمح الخادم بالتجاوزات: AllowOverride All (خلاف ذلك .htaccess (يتم تجاهلها).
  • mod_rewrite يجب تفعيلها.

إذا حصلت على 500 فور إجراء أي تغيير، ارجع إلى النسخة السابقة من الملف. يكفي وجود توجيه محظور من قِبل مزود خدمة الاستضافة (أو خطأ مطبعي).

الخطوة الرابعة: تحقق من عنوان الموقع الرئيسي (siteurl/home) بعد عملية النقل

عندما يكون عنوان الموقع الإلكتروني غير متناسق، قد تواجه عمليات إعادة توجيه غريبة وأخطاء 404. تحقق من:

  • الإعدادات → عام : "عنوان موقع ووردبريس (URL)" و "عنوان موقع الويب (URL)".

إذا تعذر الوصول إلى لوحة التحكم، فيمكن لـ WP-CLI المساعدة:

wp option get home
wp option get siteurl

إشارة: خيار wp.

الخطوة 5: تعارض الإضافات/القوالب (ذاكرة التخزين المؤقت، والأمان، وعمليات إعادة التوجيه)

استعمال الصحة تحقق في وضع استكشاف الأخطاء وإصلاحها: قم بتعطيل الإضافات/السمة لك وحدك (لا يرى الزوار شيئاً). في تجربتي، غالباً ما يكون المشتبه بهم هم:

  • إضافات التخزين المؤقت (قواعد الخادم المُضافة، عمليات إعادة التوجيه القسرية).
  • إضافات الأمان (جدار حماية تطبيقات الويب، حظر REST، قيود الملفات).
  • إضافات متعددة اللغات (هياكل عناوين URL محددة).

الخطوة السادسة: مسح جميع ذاكرات التخزين المؤقت (فعلاً)

خطأ شائع: "لقد مسحت ذاكرة التخزين المؤقت" تعني مسح ذاكرة التخزين المؤقت للمتصفح فقط. في المواقع الإلكترونية الحديثة، غالبًا ما يكون هناك من 3 إلى 5 طبقات.

  • ذاكرة التخزين المؤقت للمتصفح
  • إضافة التخزين المؤقت
  • ذاكرة التخزين المؤقت للخادم (FastCGI، LiteSpeed، Varnish)
  • ذاكرة التخزين المؤقت لشبكة توصيل المحتوى (CDN)
  • ذاكرة التخزين المؤقت للمنشئ (ملفات CSS/JS المجمعة)

الخطوة 7: التحقق من الأذونات (أباتشي)

إذا لم يتمكن ووردبريس من الكتابة .htaccessقد تميل إلى وضع 777تجنّب هذا. بدلاً من ذلك، صحّح صلاحيات المالك/المجموعة من خلال مزوّد خدمة الاستضافة. راجع مرجع PHP الخاص بالصلاحيات (لمزيد من الفهم): chmod ().

الأخطاء الشائعة والمزالق

العرض / الخطأ السبب المحتمل يوصى بالحل
"ضغطت على زر الحفظ، لكن لم يتغير شيء." تم تجاهل ملف .htaccess في خادم Nginx قم بتهيئة Nginx (try_files) + قم بتحديث ووردبريس
خطأ 500 بعد تعديل ملف .htaccess خطأ مطبعي، توجيه ممنوع، كتلة مكررة استعادة ملف .htaccess، ثم الحل 1
تتعطل الروابط الدائمة بعد كل عملية نشر لم يتم تحديث قواعد إعادة الكتابة بعد إضافة أنواع المنشورات المخصصة/التصنيفات التنظيف عند التنشيط (الحل 1) أو WP-CLI (الحل 3)
الموقع بطيء بعد "الإصلاح" flush_rewrite_rules() تم تنفيذه في init قم بإزالة المقتطف؛ قم بالتنظيف فقط عند التنشيط.
تم نسخ المقتطف في المكان الخطأ يتم لصقها في إضافة ذاكرة التخزين المؤقت، أو في ملف أساسي. ضعه في mu-plugin أو mini-plugin، وليس في core.
تظهر صفحة الإدارة فارغة بعد إضافة الكود. فاصلة منقوطة / قوس منسي صحّح بناء الجملة، وتحقق من سجلات PHP
زر "النقرة الواحدة" يعمل، لكن بعض عناوين URL لا تزال تُظهر خطأ 404. تعارض الإضافات، والقواعد المخصصة، وعمليات إعادة التوجيه فحص صحي + تعطيل مستهدف

أحد الأخطاء التي أراها كثيراً هو الخلط بين الفعل والتصفية.

Un صنارة صيد ربما عمل (يُحفز شيئًا ما) أو مرشحات (يُعدّل قيمة). عملية التحديث هي إجراء: أنت لا "تُصفّي" الروابط الدائمة، بل تُعيد إنشاء القواعد. إذا صادفتَ شرحًا قديمًا يُوصي بفلتر غريب، فكن حذرًا: فالعديد من المقتطفات البرمجية تعود إلى زمن كانت فيه معايير الأداء أقل صرامة.

بديل / متغير

طريقة بدون كتابة كود: إضافة إدارة الروابط الدائمة/إعادة التوجيه

إذا كنت لا ترغب في تعديل الكود، يمكنك استخدام إضافة موثوقة لإدارة عمليات إعادة التوجيه وتشخيص أخطاء 404. لا يُعدّ هذا إصلاحًا لملف .htaccess بحد ذاته، ولكنه يُساعد في الحدّ من تأثير ذلك على المستخدمين أثناء إصلاح عملية إعادة التوجيه.

  • على سبيل المثال، إضافة إعادة توجيه معترف بها (على إضافات ووردبريس.أورج) يمكنه تسجيل أخطاء 404 وإظهار ما إذا كانت المشكلة عامة (إعادة كتابة) أو مستهدفة (تغيير عناوين URL).

تحذير أمني: تجنب الإضافات التي توفر إمكانيات التحرير .htaccess بدون تحكم دقيق. قد يُصبح حقل "محرر ملف .htaccess" غير المحمي جيدًا خطرًا في حال اختراق حساب المدير.

طريقة المطور: تفريغ مستهدف بعد تسجيل البنية

إذا كنت تقوم بتطوير إضافة تقوم بتسجيل CPT (نوع المنشور المخصص = نوع المنشور المخصص)، يجب عليك مسح البيانات مرة عند التفعيل، وليس عند كل تحميل. مثال بسيط (إضافة):

<?php
/**
 * Plugin Name: BPCAB - Exemple CPT + flush propre
 */

defined( 'ABSPATH' ) || exit;

function bpcab_register_book_cpt() {
	register_post_type( 'book', array(
		'label' => 'Livres',
		'public' => true,
		'rewrite' => array( 'slug' => 'livres' ),
		'show_in_rest' => true, // Gutenberg / REST API
	) );
}
add_action( 'init', 'bpcab_register_book_cpt' );

register_activation_hook( __FILE__, function () {
	// Important : enregistrer le CPT avant le flush, sinon les règles ne l'incluent pas.
	bpcab_register_book_cpt();
	flush_rewrite_rules( true );
} );

مرجع register_post_type: register_post_type().

تجنب هذه المشكلة في المستقبل

  • لا تقم بتعديل النواة (ملفات ووردبريس). يجب وضع كل شيء في إضافة، أو إضافة فرعية، أو قالب فرعي.
  • تجنب استخدام عبارات مثل "flush on init"إذا كنت بحاجة إلى استخدام المرحاض، فافعل ذلك:
    • عند تفعيل الملحق
    • بعد عملية ترحيل (مرة واحدة)
    • عبر نشر WP-CLI
  • احتفظ بنسخة من ملف .htaccess (إذا كان Apache) في النسخة الاحتياطية الخاصة بك، أو في إدارة تكوين الخادم الخاص بك.
  • على Nginx : توثيق كتلة ووردبريس الخاصة بك (try_files) ولا تتركه "ضمنياً".
  • بعد تثبيت البنّاء (Divi/Elementor/Avada): اختبر صفحةً ومقالاً وأرشيفاً ومعاينة. هذا يكشف مشاكل إعادة الكتابة مبكراً.

فحص آلي صغير (اختياري) عبر WP-CLI

يمكنك إضافة فحص إلى روتين الصيانة الخاص بك:

# Vérifier qu'une URL répond (exemple simple)
wp eval "echo home_url('/?p=1');"

هذا ليس اختبارًا كاملاً، ولكنه يشجعك على التحقق بانتظام من أن التوجيه يعمل.

الموارد

أسئلة fréquentes

هل يؤدي خيار "حفظ الروابط الدائمة" فعلاً إلى إعادة إنشاء ملف .htaccess؟

نعم، على خادم أباتشي: يقوم ووردبريس بإعادة إنشاء قواعده ويحاول كتابة كتلة ووردبريس في .htaccess إذا كان الملف قابلاً للكتابة. على خادم Nginx، .htaccess غير مستخدم.

لماذا ما زلت أرى أخطاء 404 بعد عملية التحديث؟

السبب الأكثر شيوعًا: ذاكرة التخزين المؤقت (المكون الإضافي/شبكة توصيل المحتوى)، أو خادم Nginx مُهيأ بشكل خاطئ، أو .htaccess تم تجاهل (السماح بالتجاوز). راجع قائمة التحقق "إذا لم ينجح الأمر بعد".

هل يجب أن أضع flush_rewrite_rules() في ملف functions.php؟

لا، ليس باستمرار. إذا كنت مضطرًا للقيام بذلك، فاستخدم إضافة صغيرة مع register_activation_hook (اسحب السيفون مرة واحدة). ضعه على init يؤدي ذلك إلى إبطاء الموقع.

يستخدم مزود استضافة المواقع الخاص بي Nginx: ما هو الحل "بنقرة واحدة"؟

يؤدي النقر إلى إعادة إنشاء قواعد ووردبريس، لكن الحل الحقيقي يكمن في جانب الخادم: إضافة/التحقق من الصحة try_files $uri $uri/ /index.php?$args; في إعدادات Nginx. ثم قم بتنفيذ عملية مسح البيانات عبر لوحة التحكم أو واجهة سطر أوامر ووردبريس (WP-CLI).

هل يمكن لـ Divi 5 / Elementor / Avada أن تتسبب في كسر الروابط الدائمة؟

لا تُعطّل هذه الأخطاء عملية إعادة الكتابة بحد ذاتها، ولكنها تُبرز أعراض المشكلة (مثل تكرار المعاينة، وظهور أصول غير متناسقة). أصلح عملية إعادة الكتابة أولًا، ثم امسح ذاكرة التخزين المؤقت للمنشئ.

أتلقى خطأ 500 بعد لصق كتلة .htaccess التي وجدتها على الإنترنت.

استعد نسخة احتياطية من ملفاتك فورًا. ثم، ارجع إلى الإعدادات ← الروابط الدائمة. لا تأخذ الكتل "العامة" في الاعتبار المجلدات الفرعية، أو إعدادات المواقع المتعددة، أو قيود الاستضافة.

هل يجب إعادة إنشاء الروابط الدائمة بعد كل تحديث لـ WordPress؟

لا. لا تفعل ذلك إلا إذا لاحظت عرضًا (404، توجيه معطل) أو بعد تغيير يؤثر على المسارات (CPT/التصنيفات، الترحيل، تغيير بنية عنوان URL).

هل من الخطورة جعل ملف .htaccess "قابلاً للكتابة"؟

لا يكمن الخطر في إمكانية الكتابة بحد ذاتها، بل في منحها صلاحيات واسعة للغاية (مثلاً، بصلاحيات مفرطة) أو السماح لمهاجم خبيث بإدخال قواعد. من الأفضل تصحيح إعدادات المالك/المجموعة بشكل صحيح والحفاظ على وصول آمن عبر بروتوكولي SFTP/SSH.

أنا مشترك في شبكة متعددة المواقع: هل الأمر نفسه؟

المبدأ هو نفسه (قواعد المسح)، ولكن الكتلة .htaccess يختلف الأمر بالنسبة للمواقع المتعددة. لا تنسخ كتلة "موقع واحد". استخدم الإعدادات ← الروابط الدائمة (أو WP-CLI)، ثم طبّق الكتلة المحددة التي توفرها شبكتك إذا لزم الأمر.

مقالات ذات صلة

تقديم تعليق

لن يتم نشر عنوان بريدك الإلكتروني. الحقول المشار إليها إلزامية *

يستخدم هذا الموقع نظام Akismet لتقليل الرسائل الضارة. تعرف على كيفية معالجة بيانات تعليقك.