كيف تؤتمت مهام ووردبريس باستخدام n8n خطوة بخطوة؟

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

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

كيف يتحدّث n8n مع ووردبريس أصلًا؟

كل ما تراه في لوحة تحكّم ووردبريس — إنشاء مقال، الموافقة على تعليق، تعديل مستخدم — له مقابل في واجهة REST API. حين تفتح المحرّر وتضغط "نشر"، فإن لوحة التحكّم نفسها تُرسل طلب POST إلى /wp-json/wp/v2/posts. n8n لا يفعل شيئًا أعجوبيًّا: يرسل الطلب نفسه، لكن من الخارج ومع مصادقة صريحة.

المسار القياسي هو https://example.com/wp-json/wp/v2/<المورد>. جرّبه الآن في متصفّحك: افتح https://موقعك/wp-json/ — إن رأيت كتلة JSON طويلة تصف الواجهة فالمسار مفتوح والربط ممكن. وإن رأيت 404 أو صفحة "غير مصرّح"، فأنت أمام أشهر عائق سنعود إليه في قسم حلّ المشكلات.

هناك ثلاث طرق لبناء الربط، ولكل واحدة موضعها الصحيح:

القاعدة العملية: ابدأ بعقدة WordPress إن كانت العملية ضمن نطاقها، وانتقل إلى HTTP Request فورًا عند أول شيء خارجها. لا تُضِع وقتك في محاولة إجبار العقدة الجاهزة على فعل ما لم تُبنَ له — الانتقال إلى HTTP Request ليس هزيمة، بل هو الاستخدام الطبيعي للأداة.

نقطة مهمّة كثيرًا ما تُقال بالخطأ: لا توجد عقدة "WordPress Trigger" رسمية في n8n. عقدة WordPress هي عقدة إجراء (action) فقط. أي حديث عن "n8n يراقب موقعك تلقائيًا" هو إمّا Webhook تُرسله أنت من ووردبريس، وإمّا Polling مجدول تسأل فيه الواجهة كل بضع دقائق. اعرف الفرق من البداية لتوفّر على نفسك ساعة بحث.

كيف تُنشئ كلمة مرور تطبيق وتربطها بـn8n؟

كلمة مرور التطبيقات ميزة مدمجة في نواة ووردبريس منذ الإصدار 5.6، ووجودها هو ما جعل الربط الخارجي آمنًا وبسيطًا. الفكرة: بدل أن تعطي n8n كلمة مرور حسابك — التي تفتح لوحة التحكّم كاملة وتُبطِل التحقّق بخطوتين — تولّد سلسلة خاصّة بتطبيق واحد، تصلح فقط لطلبات REST API، ويمكنك إبطالها وحدها دون أن تمسّ حسابك.

الخطوات في اللوحة:

1. من لوحة تحكّم ووردبريس اذهب إلى المستخدمون ← أضف جديدًا وأنشئ مستخدمًا خاصًّا للأتمتة، مثلًا باسم n8n-bot وبريد فعلي تملكه.
2. اختر له الدور الأدنى الذي يكفي مهمّته (راجع الجدول التالي) — لا تختر Administrator بشكل افتراضي.
3. افتح ملف ذلك المستخدم (المستخدمون ← كل المستخدمين ← تحرير)، وانزل إلى قسم Application Passwords / كلمات مرور التطبيقات.
4. اكتب اسمًا وصفيًا يخبرك لاحقًا من يستخدمها — مثل n8n-publisher — ثم اضغط إضافة كلمة مرور تطبيق جديدة.
5. ستظهر السلسلة مرّة واحدة فقط على هيئة أربع وعشرين محرفًا مقسّمة بمسافات. انسخها فورًا؛ لن تراها مجدّدًا وسيلزمك توليد بديلة إن فقدتها.

المسافات داخل كلمة مرور التطبيق ليست خطأً ولا يجب حذفها؛ ووردبريس يتجاهلها عند التحقّق، لكن الإبقاء عليها أو حذفها كلاهما يعمل. الخطأ الشائع هو نسخ محرف زائد أو سطر جديد في نهايتها، وهو سبب صامت لأخطاء 401.

الآن في n8n: افتح Credentials ← New، ابحث عن WordPress API، واملأ ثلاثة حقول فقط — عنوان الموقع (بدون /wp-json)، اسم المستخدم، وكلمة مرور التطبيق. اضغط Save، ثم استخدم زرّ الاختبار إن ظهر. الاعتماد يُخزَّن مشفَّرًا في n8n ويُعاد استخدامه في كل عقد الموقع.

للتحقّق السريع من خارج n8n قبل أن تبني أي شيء، جرّب هذا الطلب من طرفيّتك:

# تحقّق أن الواجهة مفتوحة أصلًا (لا تحتاج مصادقة)
curl -s -o /dev/null -w "%{http_code}\n" https://example.com/wp-json/

# تحقّق أن كلمة مرور التطبيق تعمل — يجب أن يعيد بيانات المستخدم
curl -u "n8n-bot:xxxx xxxx xxxx xxxx xxxx xxxx" \
  https://example.com/wp-json/wp/v2/users/me?context=edit

إن أعاد الأول 200 وأعاد الثاني كائن JSON فيه "id" و"capabilities"، فالربط سليم مئة بالمئة والمشكلة — إن وُجدت لاحقًا — في n8n لا في ووردبريس. هذا الفصل بين الطرفين يوفّر عليك ساعات تخمين.

أيّ دور تعطي مستخدم الأتمتة؟

كلمة مرور التطبيق ترث صلاحيات صاحبها كاملة. إن ولّدتها من حساب مدير، فأي تسريب لها يعني سيطرة كاملة على الموقع بما فيها تثبيت إضافات. مبدأ أقل صلاحية هنا ليس نصيحة تجميلية بل خطّ الدفاع الأول:

الترتيب العملي: Author لمعظم أتمتات النشر، وEditor للتعليقات والمزامنة، وAdministrator فقط إن كنت مضطرًّا لقراءة نقاط نهاية الإضافات والتحديثات — وحينها اجعله مستخدمًا منفصلًا بكلمة تطبيق منفصلة مخصّصة لذلك السير وحده. إن سُرّبت كلمة النشر لن تفتح إدارة الإضافات، والعكس صحيح. وفعّل التحقّق بخطوتين على كل حسابات الإدارة البشرية، فهو لا يعطّل كلمات التطبيقات إطلاقًا.

ووردبريس أسرع وأكثر أمانًا بلا إعدادات

ووردبريس المُدار من wpressly: سرعة وكاش وحماية وتحديثات تلقائية مع دعم عربي — ركّز على محتواك لا على السيرفر.

جرّب ووردبريس المُدار

متى تستخدم Webhook ومتى تستخدم Schedule؟

كل سير عمل يبدأ بمُشغّل واحد، واختياره يحدّد سلوك الأتمتة كلّها: هل تستجيب في نفس الثانية، أم كل خمس دقائق، أم مرّة يوميًا؟

Webhook يعني أن ووردبريس هو من يبادر: يقع الحدث فيرسل الموقع طلب POST إلى رابط فريد يمنحك إياه n8n، فينطلق السير فورًا. هذا أسرع وأنظف خيار، لكن ثمنه شرط واحد قاطع: يجب أن يكون خادم n8n متاحًا من الإنترنت العام عبر HTTPS. إن كان n8n يعمل على جهازك المحلي أو خلف شبكة مغلقة فلن يصله شيء. ولمفهوم الـWebhook نفسه راجع تعريف Webhook في الويكي.

Schedule (Cron) يعني أن n8n هو من يبادر على جدول ثابت: كل خمس دقائق، كل ساعة، كل يوم الثامنة صباحًا. لا يحتاج أن يكون خادمك متاحًا من الخارج إطلاقًا، وهذا وحده يجعله الخيار الافتراضي لكل ما لا يشترط الفورية. صيغة الجدولة هنا هي نفس صيغة كرون المعروفة، وإن كانت الحقول الخمسة تربكك فراجع دليل المهام المجدولة (Cron Jobs).

Polling حالة خاصّة من Schedule: تسأل الواجهة دوريًا "هل جدّ جديد منذ آخر مرّة؟"، وتقارن بمعرّف أو تاريخ محفوظ. أبسط من Webhook في الإعداد وأثقل في الاستهلاك، لكنه المنقذ حين تكون الفورية غير ممكنة.

نصيحة اقتصادية: لا تُقصّر الفاصل الزمني بلا سبب. فحص التعليقات كل دقيقة يعني 1440 طلبًا يوميًا على موقعك لتلتقط تعليقين. اجعل الفاصل متناسبًا مع كلفة التأخير الحقيقية — خمس دقائق للتعليقات، وخمس عشرة دقيقة للتحديثات، وساعة للتقارير.

سيناريوهات عملية: كيف تبنيها فعليًا؟

هنا قلب المقال. كل سيناريو مبني على الثلاثي نفسه: مُشغّل ← عُقد ← نتيجة. ابنِ واحدًا منها فقط وستفهم البقيّة بلا شرح.

1. نشر مجدول من قائمة انتظار خارجية

المشكلة: تكتب دفعة مقالات مرّة في الأسبوع وتريد نشرها موزّعة على أيام. جدولة ووردبريس المدمجة تكفي إن كان المحتوى داخل الموقع، لكنها لا تنفع إن كان مصدرك خارجيًا — جدول بيانات، Notion، أو مخرجات نموذج لغوي.

• المُشغّل: Schedule Trigger يوميًا الساعة 09:00.
• العقدة 1: Google Sheets ← Get Rows من ورقة فيها الأعمدة: العنوان، المحتوى، التصنيف، تاريخ النشر، الحالة.
• العقدة 2: Filter ← أبقِ الصفوف التي حالتها ready وتاريخها هو اليوم.
• العقدة 3: WordPress ← Post: Create، مع تعيين Title وContent وStatus: publish من حقول الصف بتعبيرات {{ }}.
• العقدة 4: Google Sheets ← Update Row لتغيير الحالة إلى published — هذه العقدة ليست ترفًا: بدونها سيُعاد نشر الصف نفسه كل يوم.
• النتيجة: مقال منشور يوميًا بلا تدخّل، وسجلّ واضح بما نُشر.

الدرس المتكرّر في كل أتمتة كتابة: علّم المصدر أنه عُولج. سواء بعمود حالة أو بتاريخ آخر معالجة أو بعلامة meta — بدون هذه الخطوة تتحوّل كل أتمتة إلى مُكرِّرة للعمل نفسه.

2. إعادة نشر المقال على وسائل التواصل لحظة نشره

• المُشغّل: Webhook في n8n بطريقة POST.
• من ناحية ووردبريس: إمّا إضافة webhooks تُطلق حدثًا عند post_published، وإمّا سطور قليلة في ملف القالب الابن functions.php:

add_action( 'transition_post_status', function ( $new, $old, $post ) {
    if ( $new !== 'publish' || $old === 'publish' || $post->post_type !== 'post' ) {
        return;
    }
    if ( get_post_meta( $post->ID, '_n8n_sent', true ) ) {
        return; // منع التكرار
    }
    wp_remote_post( 'https://n8n.example.com/webhook/wp-published-9f3a2b', array(
        'timeout'  => 5,
        'blocking' => false,
        'headers'  => array(
            'Content-Type'  => 'application/json',
            'X-Wp-Secret'   => 'ضع-سرًّا-طويلًا-هنا',
        ),
        'body' => wp_json_encode( array(
            'id'    => $post->ID,
            'title' => get_the_title( $post ),
            'url'   => get_permalink( $post ),
        ) ),
    ) );
    update_post_meta( $post->ID, '_n8n_sent', 1 );
}, 10, 3 );

لاحظ ثلاثة تفاصيل ثمينة هنا: blocking => false يجعل الطلب لا يؤخّر تجربة الكاتب إطلاقًا، والترويسة السرّية X-Wp-Secret تمنع أي غريب من إطلاق سيرك بطلب مزوَّر، وعلامة الـmeta _n8n_sent تمنع الإرسال المكرّر. ولا تضع هذا الكود في ملفات القالب الأصلي — سيُمحى مع أول تحديث؛ استخدم قالبًا ابنًا أو إضافة صغيرة خاصّة بك.

الحمولة التي يستقبلها n8n تبدو هكذا:

{
  "id": 4821,
  "title": "كيف تختار خطة استضافة تناسب متجرك؟",
  "url": "https://example.com/choose-hosting-plan"
}

• العقدة 1: IF ← تحقّق أن X-Wp-Secret يساوي السرّ المتوقّع، وإلا أوقف التنفيذ.
• العقدة 2: HTTP Request ← GET /wp-json/wp/v2/posts/{{ $json.id }}?_embed لجلب الملخّص والصورة البارزة (الحمولة المختصرة قصدًا كي لا تنتفخ).
• العقدة 3 و4: عقدة X وعقدة LinkedIn (أو Telegram) لبثّ العنوان والملخّص والرابط.
• النتيجة: كل مقال جديد يظهر على قنواتك خلال ثوانٍ من نشره.

3. مراقبة التعليقات وفلترة السبام

عقدة WordPress لا تغطّي التعليقات، لذا هذا السيناريو كلّه على HTTP Request — وهو مثال مثالي على الانتقال الطبيعي بين الطريقتين.

• المُشغّل: Schedule Trigger كل 5 دقائق.
• العقدة 1: HTTP Request ← GET /wp-json/wp/v2/comments?status=hold&per_page=20&orderby=date&order=desc (يتطلّب مصادقة بدور Editor فأعلى).
• العقدة 2: Filter ← استبعد ما عُولج سابقًا بمقارنة id بآخر معرّف محفوظ في عقدة بيانات ثابتة أو ورقة جانبية.
• العقدة 3: عقدة ذكاء اصطناعي أو مجموعة شروط ← صنّف التعليق: هل يحوي أكثر من رابطين؟ هل نصّه بلغة لا تناسب جمهورك؟ هل يطابق أنماط سبام معروفة؟
• العقدة 4 (مسار السبام): HTTP Request ← POST /wp-json/wp/v2/comments/{{ $json.id }} بالحمولة {"status":"spam"}.
• العقدة 5 (مسار المشروع): Telegram ← تنبيه فيه نصّ التعليق ورابط الموافقة المباشر.
• النتيجة: صندوق تعليقات نظيف تلقائيًا، وتنبيه بشري فقط للتعليقات التي تستحق ردًّا.

الحمولة التي ترسلها لتغيير الحالة بسيطة إلى هذا الحدّ:

{
  "status": "spam"
}

كن محافظًا في هذا السيناريو تحديدًا: اجعل الشكّ في مصلحة التعليق. حذف تعليق حقيقي لقارئ جادّ خسارة أكبر بكثير من ترك تعليق سبام معلّقًا خمس دقائق إضافية. ابدأ بمسار "أرسل لي للمراجعة" لأسبوعين، وراقب دقّة التصنيف، ثم فعّل الحذف الآلي على الفئة التي أثبتت دقّة كاملة فقط.

4. تنبيهات النسخ الاحتياطي والتحديثات

• المُشغّل: Schedule Trigger يوميًا الساعة 08:00.
• الفرع الأول — التحديثات: HTTP Request ← GET /wp-json/wp/v2/plugins (يتطلّب صلاحية إدارة الإضافات، فاستخدم اعتماد المدير المخصّص هنا وحده)، ثم Filter على الإضافات التي حالتها تشير إلى وجود تحديث، ثم عقدة تجميع تبني قائمة نصّية.
• الفرع الثاني — النسخ الاحتياطي: إن كانت أداة النسخ لديك ترفع الملفات إلى تخزين خارجي، اقرأ قائمة الملفات من هناك وتحقّق أن أحدث ملف عمره أقل من 24 ساعة. إن كانت الأداة ترسل بريدًا فراقب صندوق البريد بعقدة IMAP بدل ذلك.
• العقدة الأخيرة: Slack أو Telegram ← رسالة واحدة يومية تجمع الفرعين: "3 إضافات تنتظر التحديث · آخر نسخة احتياطية قبل 6 ساعات ✅".
• النتيجة: تعرف حالة موقعك كل صباح دون أن تفتح لوحة التحكّم، ولا تكتشف غياب النسخ الاحتياطية يوم تحتاجها.

هذه الأتمتة تُنبّه ولا تُنفّذ — وهذا مقصود. التحديث التلقائي الأعمى للإضافات على موقع حيّ مقامرة؛ الصواب أن تختبر التحديثات على بيئة اختبار (staging) أولًا. أمّا استراتيجية النسخ نفسها فموضوع مستقلّ يشرحه دليل النسخ الاحتياطي لووردبريس، ولا تُغني عنه أي أتمتة تنبيه.

5. مراقبة تعطّل الموقع

أبسط سيناريو في القائمة، وربما أعلاها قيمة لكل من يبيع أو يجمع عملاء من موقعه.

• المُشغّل: Schedule Trigger كل 5 دقائق.
• العقدة 1: HTTP Request ← GET https://example.com/ مع تفعيل خيار "Never Error" أو "Continue On Fail" ليصل الخطأ إلى العقدة التالية بدل أن يقتل التنفيذ.
• العقدة 2: IF ← هل رمز الاستجابة ليس 200، أو تجاوز زمن الاستجابة 5 ثوانٍ، أو غابت من الصفحة كلمة تظهر دائمًا في الفوتر؟
• العقدة 3: Telegram أو مكالمة/رسالة قصيرة ← تنبيه فوري يحمل رمز الحالة وزمن الاستجابة.
• العقدة 4: عقدة تعطيل تنبيه متكرّر — سجّل حالة "معطّل" ولا ترسل تنبيهًا جديدًا كل خمس دقائق طوال العطل، بل أرسل تنبيهًا واحدًا عند السقوط وآخر عند العودة.

فحص محتوى الصفحة إضافةً إلى رمز الحالة ليس تفصيلًا زائدًا: كثير من الأعطال الحقيقية تُعيد 200 بينما الصفحة بيضاء أو فيها خطأ قاعدة بيانات. ابحث عن سلسلة تظهر في كل صفحة ولا تظهر في صفحات الخطأ. وإن بدأت تنبيهاتك تتكرّر بأنماط ثابتة فالمشكلة في الموقع لا في الأتمتة — راجع دليل إصلاح أخطاء ووردبريس الشائعة.

6. تجميع بيانات النماذج ومزامنة المحتوى

هذان سيناريوهان قريبان لأنهما يشتركان في المنطق: نقل بيانات من ووردبريس إلى مكان آخر دون تدخّل.

للنماذج: معظم إضافات النماذج الجادّة تدعم إرسال Webhook عند كل إرسال — تضع رابط n8n في إعدادات النموذج فينتهي الأمر. المُشغّل: Webhook. العُقد: Set لتوحيد أسماء الحقول (لا تعتمد على أسماء الإضافة الخام، فهي تتغيّر مع أي تعديل على النموذج)، ثم Google Sheets ← إضافة صف، ثم Slack ← إشعار للفريق، ثم عقدة CRM إن وُجد. النتيجة: كل طلب عرض سعر يصل إلى ثلاثة أماكن في نفس اللحظة، ولا يضيع منها واحد في بريد مهمَل.

لمزامنة المحتوى: المُشغّل Schedule كل ساعة. العقدة الأولى HTTP Request ← GET /wp-json/wp/v2/posts?modified_after=<آخر مزامنة>&per_page=100 تجلب ما تغيّر فقط. ثم عقدة تحويل تختصر كل مقال إلى الحقول التي تهمّ الوجهة، ثم كتابة إلى قاعدة بياناتك أو أداة تحليلاتك أو مؤشر بحث خارجي. المفتاح كلّه في المُعامل modified_after: بدونه ستسحب الموقع كاملًا كل ساعة، ومعه تسحب التغييرات فقط. ومع متجر ووكومرس ينطبق المنطق نفسه على نقاط نهاية المنتجات والطلبات.

سحابة الأتمتة n8n من wpressly

شغّل n8n على سحابة wpressly بموارد مخصّصة وحماية ودعم عربي — اربط أدواتك وأتمت مهامك بلا إدارة سيرفر معقّدة.

ابدأ مع سحابة الأتمتة

ما الذي لا يستحقّ الأتمتة أصلًا؟

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

القاعدة الأشمل مشروحة في دليل أتمتة المهام المتكرّرة، ولمزيد من الأمثلة الجاهزة خارج ووردبريس راجع أمثلة أتمتة عملية بـn8n.

كيف تؤمّن الربط؟

ربط n8n بووردبريس يفتح بابًا برمجيًا في موقعك، والباب المفتوح يحتاج قفلًا. خمس ممارسات تغطّي 95% من المخاطر:

أولًا، مستخدم مخصّص بأقل دور. تكرّرت هذه في المقال ثلاث مرّات لأنها الأهمّ: لا تربط n8n بحساب المدير الشخصي، ولا تعطِ دور Administrator لمهمّة نشر.

ثانيًا، مسار Webhook غير قابل للتخمين. n8n يولّد معرّفًا عشوائيًا افتراضيًا — لا تستبدله بمسار "جميل" مثل /webhook/new-post. المسار العشوائي الطويل هو نصف الحماية.

ثالثًا، سرّ في الترويسة. النصف الآخر: أرسل ترويسة مثل X-Wp-Secret من ووردبريس، وافحصها بعقدة IF أولى في n8n، وأوقف كل ما لا يطابق. بدون هذا الفحص يستطيع أي شخص يعرف رابط الـWebhook أن يُطلق سيرك بحمولة مزوّرة متى شاء.

رابعًا، HTTPS في الاتجاهين. كلمة مرور التطبيق تُرسل في ترويسة Authorization بترميز Base64 — وBase64 ليس تشفيرًا. بدون HTTPS فأنت ترسل مفتاح موقعك بنصّ شبه صريح. تأكّد أن الطرفين على شهادات صالحة، وأضف ترويسات أمان HTTP على واجهة n8n نفسها — وإن لم تكن أعددت شهادة بعد فراجع دليل تثبيت SSL وتفعيل HTTPS.

خامسًا، دوّر المفاتيح واحذف المهمَل. كل كلمة تطبيق لم تعد تستخدمها يجب إبطالها من ملف المستخدم فورًا؛ قائمة كلمات التطبيقات تُظهر آخر استخدام لكل واحدة، فراجعها كل بضعة أشهر. باقي الأساسات الأمنية للموقع في دليل تأمين موقع ووردبريس.

حلّ المشكلات: لماذا لا يعمل الربط؟

هذا القسم مبني على الأخطاء التي ستقابلها فعلًا، مرتّبة بترتيب شيوعها.

الفروق الدقيقة التي توفّر أكثر الوقت:

الفرق بين 401 و403 حاسم. الأول يقول "لا أعرف من أنت" — مشكلة مصادقة، أي كلمة تطبيق أو اسم مستخدم أو ترويسة ضائعة. والثاني يقول "أعرفك ولا يحقّ لك" — مشكلة صلاحيات، أي دور المستخدم. لا تعبث بكلمة المرور حين تكون المشكلة في الدور، ولا العكس.

اختبر الطرفين منفصلين دائمًا. إن نجح curl من سطر الأوامر وفشل n8n، فالمشكلة في الاعتماد أو إعداد العقدة داخل n8n. وإن فشل curl أيضًا، فالمشكلة في ووردبريس أو الخادم ولا فائدة من العبث بـn8n. هذا الفصل وحده يقصّر التشخيص من ساعات إلى دقائق.

رابط الاختبار غير رابط الإنتاج. أشهر إحباط للمبتدئين: يجرّب الـWebhook فينجح، ثم يغلق الشاشة فيتوقّف كل شيء. رابط الاختبار في n8n يعمل فقط أثناء ضغطك زرّ "Listen"، ورابط الإنتاج يعمل فقط حين يكون السير مفعّلًا (Active). تأكّد أن ما وضعته في ووردبريس هو رابط الإنتاج وأن المفتاح مفعّل.

حدود REST API ليست مطلقة. المُعامل per_page سقفه 100 عنصر لكل طلب؛ لسحب أكثر استخدم الترقيم عبر page واقرأ ترويسة X-WP-TotalPages لتعرف متى تتوقّف. ولا تجلب أبدًا ما لا تحتاج: modified_after و_fields يقلّصان الحمولة والزمن معًا بشكل هائل. سحب مئة مقال كامل كل ساعة قد يبطئ الموقع فعلًا، وهو تعارض مباشر مع كل جهد بذلته في تسريع الموقع.

من أين تبدأ عمليًا؟

لا تبنِ السبعة سيناريوهات في يوم. الترتيب الذي يُنتج نتيجة أسرع:

الأسبوع الأول: مراقبة التعطّل. سير من ثلاث عقد، ينجز في نصف ساعة، وقيمته تظهر من أول عطل. وهو أفضل تمرين لفهم Schedule وIF بلا أي مخاطرة على الموقع، لأنه يقرأ فقط ولا يكتب شيئًا.

الأسبوع الثاني: تنبيه التحديثات والنسخ الاحتياطي. لا يزال قراءة فقط، لكنه يعلّمك المصادقة والاعتمادات فعليًا.

الأسبوع الثالث: أول أتمتة تكتب في موقعك — النشر المجدول أو إعادة النشر على القنوات. جرّبها على بيئة اختبار قبل الموقع الحيّ، فالكتابة الخاطئة عبر API تصنع عشرين مسودّة مكرّرة في ثوانٍ.

بعدها فقط انتقل إلى ما يحتاج حكمًا: التعليقات والمزامنة. وفي كل خطوة التزم بالمبدأ نفسه — ابنِ سيرًا واحدًا يعمل بثبات لأسبوعين قبل أن تبني الثاني. عشرة سيارات نصف مبنية أسوأ من سير واحد يعمل.

سحابة الأتمتة n8n من wpressly

شغّل n8n على سحابة wpressly بموارد مخصّصة وحماية ودعم عربي — اربط أدواتك وأتمت مهامك بلا إدارة سيرفر معقّدة.

ابدأ مع سحابة الأتمتة

الأسئلة الشائعة

هل أحتاج خادمًا خاصًّا لتشغيل n8n أم يكفي موقعي؟

تحتاج مكانًا مستقلًّا. n8n تطبيق Node.js ولا يعمل داخل استضافة ووردبريس مشتركة تدعم PHP فقط. الخياران الواقعيان: نسخة n8n السحابية المدارة، أو تثبيته على سيرفر VPS تملكه. الفصل عن الموقع مفيد لا مزعج — إن سقط موقعك يبقى n8n حيًّا ليخبرك بذلك، وهو ما يجعل سيناريو مراقبة التعطّل ممكنًا أصلًا. خطوات التثبيت الكاملة في دليل تثبيت n8n على VPS.

هل تدعم عقدة WordPress في n8n كل شيء في الموقع؟

لا. العقدة تغطّي ثلاثة موارد فقط: المقالات والصفحات والمستخدمين، بعمليات إنشاء وجلب وتحديث. لا تغطّي التعليقات ولا التصنيفات والوسوم ولا مكتبة الوسائط ولا الإضافات ولا نقاط نهاية الإضافات الخارجية. لكل ما عداها استخدم عقدة HTTP Request على المسار المناسب في /wp-json/ بنفس اعتماد الموقع — لا فرق أمني بين الطريقتين، فكلتاهما تستخدمان الواجهة نفسها والمصادقة نفسها.

ما الفرق بين كلمة مرور التطبيق ومفتاح API؟

في ووردبريس هما الشيء نفسه عمليًا. كلمة مرور التطبيق هي آلية النواة المدمجة منذ الإصدار 5.6 وتُرسل عبر مصادقة HTTP الأساسية، وترث صلاحيات المستخدم الذي وُلّدت منه بالكامل. لا تحتاج إضافة ولا إعدادًا إضافيًا. ما يجعلها أفضل من كلمة مرور الحساب أمران: تصلح لـREST API فقط ولا تفتح لوحة التحكّم، ويمكن إبطالها منفردة دون تغيير كلمة مرورك ودون كسر بقيّة التكاملات.

هل تُبطئ الأتمتة موقعي؟

بحسب المُشغّل. الـWebhook لا يكلّف شيئًا يُذكر: طلب واحد خارج عند وقوع الحدث، ومع blocking => false لا يؤخّر الزائر ولا الكاتب إطلاقًا. Polling هو ما قد يؤذي: طلب كل دقيقة على نقطة نهاية ثقيلة يعني 1440 استعلامًا يوميًا. خفّف الأثر بثلاثة أشياء: باعد الفاصل الزمني إلى الحدّ المقبول، استخدم modified_after لتجلب المتغيّر فقط، وحدّد _fields لتقلّص حجم الاستجابة. مع هذه الثلاثة تصير الكلفة مهمَلة.

إضافة الأمان لديّ تحجب /wp-json — ماذا أفعل؟

هذا أشهر سبب لفشل الربط على الإطلاق. لا تعطّل الإضافة كاملة؛ معظم إضافات الأمان تسمح باستثناء مستخدم بعينه أو عنوان IP بعينه من حجب REST API. أضف مستخدم الأتمتة أو عنوان خادم n8n إلى الاستثناءات وأبقِ الحجب على الجميع سواهم — وهذا في الواقع إعداد أكثر أمانًا من الافتراضي: الواجهة مغلقة أمام العالم ومفتوحة لطرف واحد معروف. تحقّق أيضًا من جدار حماية الاستضافة، فقد يحجب هو الطلبات قبل أن تصل ووردبريس أصلًا.

كيف أمنع الأتمتة من الدخول في حلقة لا نهائية؟

بثلاث طبقات لا واحدة. الأولى: علامة meta على كل ما تنشئه الأتمتة (مثل _created_by_n8n)، وشرط IF في مقدّمة سير الـWebhook يتجاهل كل ما يحمل هذه العلامة. الثانية: اجعل مستخدم النشر الآلي مختلفًا عن المستخدم الذي يُطلق الـWebhook، وافحص المؤلّف. الثالثة: اضبط حدًّا أقصى لعدد التنفيذات في إعدادات السير، وراقب سجلّ التنفيذ في أوّل أسبوعين. الطبقتان الأوليان تمنعان، والثالثة تحدّ الضرر إن سقطت الأوليان.

هل أستطيع الربط دون كتابة أي كود في functions.php؟

نعم تمامًا. من n8n إلى ووردبريس لا كود أصلًا — عقدة WordPress أو HTTP Request مع اعتماد. ومن ووردبريس إلى n8n لديك خياران بلا كود: إضافة webhooks مخصّصة تُطلق حدثًا عند نشر مقال أو تعليق جديد أو تسجيل مستخدم وتُرسله إلى رابطك، أو إعدادات الـWebhook المدمجة في إضافة النماذج التي تستخدمها. الكود المباشر في functions.php يعطي تحكّمًا أدقّ وحمولة أخفّ ولا يضيف إضافة جديدة، لكنه ليس شرطًا للبدء. ولمن يريد الأساس النظري لكامل هذا الربط، مدخل n8n في الويكي نقطة انطلاق جيدة، ومدخل الإضافات يشرح كيف تختار إضافة webhooks موثوقة.

المصادر

• توثيق n8n الرسمي