حل المشكلات

عندما لا يعمل شيء

معظم ما يُبلَّغ عنه يرجع إلى أربعة أسباب. ومعرفة أيّها أمامك أسرع من قراءة شرح الميزة، وتكفي في العادة. | السبب | كيف يبدو | |---|---| | دور | الصفحة أو الزر غائب تماماً، عندك لا عند زميلك | | خطة أو مفتاح في التثبيت | الصفحة غائبة عن الجميع، والمديرين معهم | | Meta | رفض واتساب شيئاً، والمنتج يبلّغ عن ذلك الرفض | | تهيئة | الميزة موجودة، واستخدمتها، والنتيجة ليست ما توقعته | ابدأ بمن أنت عدد تقارير "الأمر معطّل" الراجعة إلى دور أكبر من أي سبب آخر. فوكيل الدعم لا يرى إلا قنوات التواصل التي هو متعاون فيها، ولا يرى الإعدادات إطلاقاً. والدور المخصص لا يرى إلا ما مُنح له، وقائمة الصلاحيات أقصر مما يفترض الناس — فلا بند فيها لقنوات التواصل ولا الحملات ولا قوالب واتساب ولا التدفقات ولا قواعد الأتمتة ولا الجماهير. والأدوار والصلاحيات تحمل القائمة بدقة. وإن كان زميل مدير لا يراه أيضاً، فتوقّف عن النظر في الأدوار. فهو مفتاح خطة أو مفتاح على مستوى التثبيت، ولا شيء في حسابك يغيّرهما. ثم ابحث عن عارضك | العارض | أول ما تتحقق منه | أين يُشرح | |---|---|---| | لا تصل رسائل واتساب | تبويب صحة الحساب في القناة | حين لا يعمل واتساب | | لا أستطيع كتابة رد، بل إرسال قالب فقط | آخر مرة كتب فيها العميل | نافذة الـ24 ساعة | | قالب مرفوض أو موقوف | سبب الرفض على القالب | دورة حياة القالب | | الحملة تقول مكتملة ولم يستلم أحد | هل القالب لا يزال APPROVED | حملات واتساب | | قالبي غائب عن قائمة الحملة | حالته وتصنيفه ومكوّناته | قوالب واتساب | | المحادثة ليست في قائمتي | مرشّح الحالة، ثم عضويتك في القناة | العمل في صندوق الوارد | | وكيل دعم لا يرى محادثات قناة | تبويب المتعاونين في القناة | إعداد قناة تواصل | | قاعدة أتمتة لم تفعل شيئاً | أن القاعدة مفعّلة | قواعد الأتمتة | | تدفق لم يبدأ أبداً | أنه منشور وعلى قناة WhatsApp Cloud | منشئ التدفقات | | الاستيراد تخطّى كل الصفوف | وسوم غير موجودة، أو بلد ناقص | استيراد جهات الاتصال | | جمهور لا يطابق أحداً | هل وسومك على جهات الاتصال أم على المحادثات | الوسوم أم الجماهير المشتركة؟ | | الطلبات لا تظهر بجانب المحادثة | هل طابقت جهة الاتصال عميل متجر | عرض العميل الشامل | | إجراء الطلب الذي أحتاجه غير معروض | جدول كل منصة | ما تدعمه كل منصة | | رابطي لا يستقبل الأحداث | أن الرابط متاح للعموم | Webhook | | لا أعرف من غيّر إعداداً | هل ذلك الإجراء مدقَّق أصلاً | سجلات التدقيق | ما يترك أثراً وما لا يتركه قبل أن تصرف ساعة في البحث عن سجل، هذا ما هو موجود. | المجال | ما تستطيع فحصه بعد ذلك | |---|---| | الحملات | نتائج كل مستلم، ومعها سبب، حيث يكون تحليل الحملات في تثبيتك | | التدفقات | الجلسات على التدفق: أين انتهى كل تشغيل ولماذا | | واتساب | تبويب صحة الحساب في القناة، وسبب كل رسالة فاشلة على الرسالة نفسها | | تغييرات الإعدادات | سجلات التدقيق، لأنواع الأحداث الأربعة عشر التي تغطيها | | قواعد الأتمتة | لا شيء. فلا تاريخ تشغيل ولا سجل لكل قاعدة في المنتج | | Webhook | لا شيء. فلا سجل إرسال ولا إعادة محاولة ولا إعادة إرسال | | الاستيراد | أعداد نتائج الاستيراد نفسه | وحيث يكون الجواب "لا شيء"، فالطريقة العملية أن تعيد إطلاق المُطلِق بقصد وتراقب ما يحدث، لا أن تبحث عن سجل للمرة الأولى. أربعة لا تُصلحها أي تهيئة - Meta تملك أحكام القوالب وتقييمات الجودة وحدود الإرسال وقرارات اسم العرض. فالمنتج يبلّغ عنها، ولا يستأنفها ولا يتجاوزها. - الرسائل التي أُرسلت إلى رقم واتساب أثناء غياب الـ Webhook ضائعة. ولا تعويض. - التصرّف خارج أوقات العمل لا يُبنى بالأتمتة. فلا يوجد شرط لأوقات العمل ولا لوقت من اليوم ولا لساعات الدوام. وأوقات عمل قناة التواصل نفسها ورسالة عدم التوفر هما الأداة لذلك — راجع إعداد قناة تواصل. - الاسترداد والإلغاء لا يمكن تفويضهما لأي دور مخصص، على أي منصة. من يستطيع ذلك يرى وكلاء الدعم معظم العوارض ولا يرون الأسباب تقريباً: فصحة الحساب وتهيئة قنوات التواصل والقوالب والحملات والأتمتة وسجلات التدقيق كلها للمديرين وحدهم. وإن كنت وكيل دعم، فإسهامك المفيد عارض دقيق — أي محادثة، وأي رقم، وأي وقت — ثم التصعيد. مواضيع ذات صلة - حين لا يعمل واتساب - الأدوار والصلاحيات · إعداد قناة تواصل - سجلات التدقيق · Webhook - حملات واتساب · قواعد الأتمتة · منشئ التدفقات - ما تدعمه كل منصة

متجرك يحتاج إلى إعادة ربط

المتجر في هذه الحالة توقف عن العمل تماماً: سجل الطلبات لا يُحمَّل في المحادثة، والسلات المتروكة تتوقف عن الوصول، وإجراءات الطلبات غير متاحة. والمنتج لا يعيد المحاولة في الخلفية، لأن إعادة المحاولة بوصول رفضه المتجر لن تفيد. المدير وحده يصلحها، وبإجراء واحد: الإعدادات ← التجارة ← المتجر ← إعادة الربط. ما يقوله لك المنتج | ما تراه | الرمز وراءه | |---|---| | «هذا المتجر يحتاج إلى إعادة ربط» في الإعدادات ← التجارة | حالة المتجر needs_reauth | | «لم نتمكن من الوصول إلى متجرك» في لوحة المحادثة | AUTH_INVALID | الحالة دائمة: كُتبت لحظة رفض المتجر للوصول، وتبقى حتى يعيد أحد ربطه. وليست تخميناً من طلب فاشل واحد. لماذا يحدث السبب يختلف بحسب المنصة، ويستحق المعرفة لأن اثنين منها قد يحدثان دون خطأ من أحد. - ووكومرس — حُذف مفتاح الواجهة البرمجية، أو تغيّرت صلاحياته، في ووردبريس ← ووكومرس ← الإعدادات ← متقدّم ← REST API. وهذا هو السبب المتعمَّد عادةً: أحدهم رتّب المفاتيح. - سلة — أُزيل التطبيق أو انقضى تصريحه في لوحة سلة. إعادة تثبيت التطبيق تعيد ربط المتجر وحدها، ولا تحتاج إلى إنشاء رمز ربط جديد إلا إذا كان المتجر قد اختفى من القائمة أيضاً. - زد — انتهى التصريح أو أُزيل التطبيق. وزد تُجيب أحياناً على تصريح مرفوض بإعادة توجيه إلى صفحة الدخول بدل رفض صريح، والمنتج يقرأ ذلك على أنه تصريح مرفوض، وهي القراءة الصحيحة. - شوبيفاي — أُزيل التطبيق من لوحة المتجر، أو سُحب الوصول الممنوح له. ما يُحفَظ وما يُحذَف إعادة الربط لا تبدأ بك من الصفر، وفصل المتجر لا يحذف تاريخك: - يُحذَف وصول المتجر عند انتقاله إلى هذه الحالة، وكذلك بياناته المخزّنة مؤقتاً، ولهذا تَفرُغ اللوحات بدل أن تعرض شيئاً قديماً؛ - تبقى المحادثات وجهات الاتصال وسجل إجراءات الطلبات. فهي سجلات لينوميا نفسها، لا سجلات المتجر؛ - المتجر الذي تفصله يحفظ صفّه، فإعادة ربط المتجر نفسه لاحقاً تستخدمه مرة أخرى بدل أن يُحسَب على حد خطتك مرتين. إذا لم تصمد إعادة الربط إذا رجع المتجر إلى هذه الحالة بعد دقائق من إعادة الربط، فالوصول الذي منحتَه ليس الوصول الذي يحتاجه المنتج — اتصل ثم رُفض في أول طلب حقيقي. وهذه مشكلة صلاحيات لا مشكلة تصريح: راجع مفاتيح متجرك لا تستطيع ذلك.

لينوميا لا تستطيع الوصول إلى متجرك

هذه مشكلة اتصال لا مشكلة تصريح. الوصول سليم؛ لكن المتجر لم يُجب في الوقت، أو لم يُجب أصلاً. | ما تراه | الرمز وراءه | ما يعنيه بدقة | |---|---|---| | «متجرك لم يُجب» | STORE_UNAVAILABLE | فشل الاتصال، أو أرجع المتجر خطأ 5xx | | «متجرك استغرق وقتاً طويلاً للإجابة» | TIMEOUT | أُرسل الطلب ولم تصل إجابة داخل الحد | ما يفعله المنتج دون أن تطلبه - ينتظر مدة محدودة. ثلاث ثوانٍ للاتصال، وثماني ثوانٍ للإجابة، وعشر ثوانٍ لكامل المحتوى. المتجر البطيء يكلّف انتهاء مهلة واحدة، لا صفحة معلّقة. - يعيد المحاولة مرة واحدة، وللقراءة فقط. الاتصال المنقطع أو خطأ 502 أو 503 أو 504 في قراءة يُجرَّب مرة أخرى. وانتهاء المهلة لا يُعاد، فلا يُزاد المتجر البطيء بطئاً بسببنا. وإجراء الطلب لا يُعاد أبداً، لأن إرسال استرداد مرتين أسوأ من الإبلاغ عن فشل واحد. - يعرض لك ما لديه بالفعل. إن استطاعت اللوحة تقديم سجل طلبات مخزّن فستفعل، مع بيان وقت آخر تحديث. اللوحة التي تقول «آخر تحديث قبل ٤٠ دقيقة» تقول الحقيقة بدل أن تتظاهر بأنها لحظية. - لا يغيّر حالة المتجر. المتجر الذي لا يمكن الوصول إليه يبقى active، لأن تعذّر الوصول مؤقتاً ليس مثل فقدان التصريح. ما تتحقق منه، بالترتيب 1. افتح المتجر بنفسك في المتصفح من اتصال إنترنت عادي. إن كان بطيئاً أو متوقفاً عندك فهو كذلك عندنا. 2. ووكومرس فقط: تأكد أن المتجر متاح من الإنترنت العام. المتجر خلف شبكة خاصة أو على عنوان محلي لا يمكن لشيء خارجه الوصول إليه، والمنتج يرفض المحاولة — راجع عنوان المتجر مرفوض. 3. تحقق من استضافتك: حدّ معدل أو قاعدة جدار حماية. الاستضافة التي تحجب حركة غير مألوفة ترفضنا باستمرار بينما يعمل المتصفح، وهذا النمط هو أكثر ما يشبه عيباً في المنتج وليس عيباً فيه. 4. تحقق إن كان بطيئاً تحت الحمل فقط. المتجر الذي يُجيب في اثنتي عشرة ثانية يعمل من وجهة نظره، وسينتهي وقته هنا في كل مرة. وهذا يحتاج إصلاح الاستضافة لا إصلاح الربط. عندما يزول لا شيء يلزم فعله. أول طلب ناجح يعيد تقديم بيانات حيّة، وتتوقف اللوحة عن قول إنها قديمة. ولا ذاكرة مؤقتة تُفرَّغ يدوياً.

عنوان المتجر مرفوض

هذا يُرفض قبل أن يخرج أي طلب من لينوميا، أو بمجرد أن يُجيب المتجر بإعادة توجيه. وينطبق على ووكومرس، وهي المنصة الوحيدة التي تكتب فيها عنواناً — أما سلة وزد وشوبيفاي فتقدّم عناوينها بنفسها. | ما تراه | لماذا | |---|---| | «هذا العنوان ليس متجراً نستطيع الوصول إليه» | المستضيف يُحَل إلى عنوان خاص أو محلي أو عنوان بيانات وصفية | | «هذا العنوان غير صالح» | العنوان ليس رابط https صالحاً | | «هذا المتجر أعاد توجيهنا إلى مكان آخر» | أجاب المتجر بحالة 3xx | قاعدة العنوان الخاص متعمَّدة، وهي تحميك كل طلب إلى متجر يَحُلّ المستضيف أولاً، ويرفض العناوين الخاصة والمحلية وعناوين البيانات الوصفية، ثم يثبّت الاتصال على العنوان الذي تحقّق منه — فلا يستطيع شيء أن يُجيب على التحقق بعنوان عام ثم يخدم الطلب من مكان داخلي. ولهذا يُرفض http://localhost وhttp://192.168.x.x وhttp://10.x.x.x والمستضيف المنتهي بـ .local كلها. المتجر على جهازك أو شبكة مكتبك لا يمكن ربطه: فهو غير متاح من الإنترنت، والعنوان الذي يُحَل إلى مكان داخلي هو بالضبط شكل الطلب الذي وُجدت هذه القاعدة لرفضه. استخدم عنوان المتجر العام الحقيقي، العنوان الذي يكتبه العميل. إعادة التوجيه لا تُتبَع أبداً إن كان متجرك يُجيب على https://shop.example.com بإعادة توجيه إلى https://www.shop.example.com، فإعادة التوجيه تُرفض بدل أن تُتبَع، وسترى رسالة إعادة التوجيه. أدخل العنوان الذي يخدم منه المتجر فعلاً — الذي تنتهي إليه بعد إعادة التوجيه — وتزول المشكلة. وعدم اتباع إعادة التوجيه متعمَّد: إعادة توجيه متبوعة تعني أن الطلب التالي يذهب إلى مستضيف لم يتحقق منه أحد. ما تُدخله - المخطط: https. المتجر على http لا يمكن ربطه إلا إذا أدرج مدير هذا التركيب مستضيفه صريحاً كمتجر تطوير؛ - المستضيف الذي يخدم منه المتجر، بعد أي إعادة توجيه؛ - بلا مسار: ليس /wp-json ولا /wp-admin ولا صفحة في النهاية. المنتج يضيف مسار الواجهة البرمجية بنفسه. إذا كان العنوان صحيحاً ومع ذلك يُرفض فالمشكلة ليست في العنوان. المتجر الذي يُجيب على العنوان الذي أدخلتَه لكنه يرفض الطلب هو مشكلة اتصال أو صلاحيات — راجع لينوميا لا تستطيع الوصول إلى متجرك ومفاتيح متجرك لا تستطيع ذلك.

مفاتيح متجرك لا تستطيع ذلك

المتجر قد يكون مربوطاً ومتاحاً ويعمل — ومع ذلك يرفض شيئاً. فقراءة الطلبات وتغييرها صلاحيتان مختلفتان في كل منصة، ولينوميا لا ترفع الوصول الذي منحتَه بصمت أبداً: المدير يمنحه بقرار أو يبقى كما هو. | ما تراه | الرمز وراءه | |---|---| | «متجرك رفض ذلك» | PERMISSION_DENIED | | «هذه المفاتيح لا تستطيع تغيير الطلبات» | WRITE_ACCESS_DENIED | | «هذا المتجر غير معتمد لبيانات العملاء» | PROTECTED_DATA_NOT_APPROVED | | إجراءات الطلبات معطّلة، مع سبب | read_only_key أو missing_scope | القراءة والكتابة منحتان مختلفتان - ووكومرس — يُنشأ مفتاح الواجهة البرمجية بصلاحية قراءة أو قراءة وكتابة. ومفتاح القراءة مناسب تماماً إن أردت سجل الطلبات في المحادثات فقط. أما إجراءات الطلبات فتحتاج قراءة وكتابة، والمنتج لا يتظاهر بغير ذلك: يسجّل read_only_key أول مرة تُرفض فيها كتابة، ويعرض ذلك سبباً لعدم توفر الإجراء. ولتغييره أنشئ مفتاحاً جديداً بقراءة وكتابة في ووردبريس ← ووكومرس ← الإعدادات ← متقدّم ← REST API واستبدل المفاتيح في الإعدادات ← التجارة. فصلاحيات مفتاح قائم لا تُرفع في مكانها. - شوبيفاي — تحتاج إجراءات الطلبات نطاق write_orders. وبدونه يسجّل المنتج missing_scope ويبلّغ أن الإجراء غير متاح بدل أن يحاوله. وإعادة ربط المتجر تطلب النطاقات من جديد. - زد — الشكل نفسه: المتجر الذي لا يشمل تصريحه إدارة الطلبات يسجّل missing_scope. - سلة — تطبيق لينوميا للقراءة فقط بحكم التصميم. وإجراءات الطلبات غير معروضة لسلة أصلاً، وهذه قدرة في التكامل لا مشكلة في متجرك. بيانات عملاء شوبيفاي المحمية تشترط شوبيفاي اعتماد التطبيق قبل أن يقرأ أسماء العملاء وبُرُدهم وأرقامهم. وحتى يتم ذلك الاعتماد يُربط متجر شوبيفاي ويعمل في كل شيء إلا تفاصيل العملاء، والمنتج يبلّغ أنه غير معتمد لا أنه فشل — لأنه ليس فشلاً، وليس شيئاً تصلحه من متجرك. ولإجراءات الطلبات مفتاح خاص بها أيضاً بمعزل عن المفاتيح، إجراءات الطلبات معطّلة افتراضياً لكل متجر. الإعدادات ← التجارة ← المتجر ← شغّل إجراءات الطلبات. وتشغيلها يحتاج بيانات تستطيع الكتابة أصلاً، ولهذا يرفض المفتاح بالسبب نفسه أعلاه إن كانت المفاتيح للقراءة فقط: فموافقة لا تفعل شيئاً بصمت أسوأ من رفض صريح. ما ليست هذه المشكلة إن كان المتجر لا يقرأ شيئاً على الإطلاق فالمشكلة ليست هذه — راجع متجرك يحتاج إلى إعادة ربط (الوصول ذهب) أو لينوميا لا تستطيع الوصول إلى متجرك (المتجر لم يُجب).

إجراء طلب لم يُطبَّق

إجراء الطلب — إلغاء طلب، أو تغيير حالته، أو إصدار استرداد — هو الشيء الوحيد الذي تكتبه لينوميا في متجرك. وكل سلوكه ينبع من قاعدة واحدة: الكتابة لا تُرسَل مرتين أبداً. فاسترداد مكرر أسوأ من فشل تراه. كل نتيجة وما تفعله | ما تراه | الرمز | ما حدث فعلاً | ما تفعله | |---|---|---|---| | «تغيّر الطلب وأنت تنظر إليه» | ORDER_CHANGED | غيّر شخص آخر الطلب بين تحميل اللوحة وإرسال الإجراء | أعد فتح الطلب وحاول على حالته الحالية | | «لم يُطبَّق ذلك» | NOT_APPLIED | قَبِل المتجر الطلب والطلب لم يتغيّر بالدليل | آمن أن تحاول مرة أخرى | | «متجرك رفض الاسترداد» | REFUND_DECLINED | رفضت بوابة الدفع، لا المتجر | استرِد من لوحة المتجر نفسها حيث يظهر سبب البوابة | | «متجرك رفض ذلك» | PROVIDER_REJECTED | رفض المتجر الإجراء نفسه | راجع الطلب في لوحة المتجر؛ يكون عادةً في حالة لا تسمح به | | «هذا الإجراء يعمل بالفعل» | ACTION_IN_PROGRESS | الإجراء نفسه جارٍ | انتظر؛ لا تبدأ ثانياً | | «هذا المبلغ غير صالح» | INVALID_AMOUNT | المبلغ خارج ما يسمح به الطلب | راجع إجمالي الطلب وما استُرد منه | | «لا نعرف إن طُبِّق ذلك» | نتيجة غير معروفة | أُرسل الطلب وفُقدت الإجابة | اقرأ بقية هذه الصفحة | | «إجراءات الطلبات معطّلة» | ACTIONS_DISABLED | المفتاح معطّل لهذا المتجر | المدير يشغّله في الإعدادات ← التجارة | | «هذا الإجراء غير متاح لهذا المتجر» | ACTION_UNAVAILABLE | المنصة لا تدعمه | لا شيء؛ هذه قدرة لا خطأ | «لا نعرف» إجابة صادقة لا عيب إن وصل الطلب إلى متجرك وفُقدت الإجابة — انتهت المهلة بعد الإرسال، أو انقطع الاتصال — فلينوميا لا تستطيع فعلاً أن تعرف إن طُبِّق الإجراء. ولن تخمّن، ولن ترسل الإجراء مرة أخرى لتعرف. وما تفعله بدلاً من ذلك: 1. تقرأ الطلب من جديد، بعد قليل، وتحكم بما يقوله المتجر الآن فقط. فإن كان الطلب في الحالة التي طلبها الإجراء فقد نجح. وإن كان بالدليل في حالته الأصلية فقد فشل وإعادته آمنة. 2. وإن لم تحسم إعادة القراءة الأمر، يبقى الإجراء مسجّلاً كغير معروف، وتقول اللوحة ذلك. 3. ولا تعيد الإرسال أبداً. الإجراء الذي قد يكون طُبِّق لا يرسله المنتج ثانية بأي حال. وإن بقي إجراء على «غير معروف» فافتح الطلب في لوحة متجرك. فهذه هي الإجابة الموثوقة، وتأخذ ثوانٍ. لماذا الإجراءات بقرار لا بتسهيل - معطّلة لكل متجر حتى يشغّلها مدير؛ - تحتاج بيانات تستطيع الكتابة — راجع مفاتيح متجرك لا تستطيع ذلك؛ - تُفحَص مقابل الطلب كما رآه الموظف، وهذا ما ينتج ORDER_CHANGED بدل مفاجأة؛ - وكل إجراء يُسجَّل بمن نفّذه وبما أجاب به المتجر. وهذه أربع فرص لرفض إجراء، وكل رفض جملة لا صمت.