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