علت ارسال نشدن پیامک در افزونه پیامک ووکامرس و چک لیست بررسی اتصال و تنظیمات

ارسال نشدن پیامک ووکامرس معمولاً از تنظیمات اتصال، فعال نبودن اعلان سفارش، اطلاعات گیرنده، محدودیت خط یا خطای اجرای افزونه ناشی می شود. برای پیدا کردن علت، باید مشخص کنید رویداد سفارش اجرا شده، درخواست به پنل رسیده یا پیام پذیرفته شده اما به گوشی نرسیده است. بررسی این مراحل به ترتیب، مسیر عیب یابی را کوتاه و نتیجه اصلاحات را قابل اندازه گیری می کند.

پیش از تغییر تنظیمات یک خط مبنا بسازید

عبارت «پیامک ارسال نمی شود» برای تشخیص فنی کافی نیست. یک سفارش مشخص انتخاب کنید و زمان ایجاد، روش پرداخت، وضعیت اولیه، وضعیت نهایی و شماره گیرنده آن را یادداشت کنید. سپس ببینید مشکل در همه سفارش ها وجود دارد یا به یک مسیر، مانند پرداخت آنلاین یا خرید مهمان، محدود است.

نسخه وردپرس، ووکامرس، PHP و افزونه پیامکی را کنار نام درگاه ثبت کنید. اگر مشکل بعد از به روزرسانی یا جابه جایی هاست شروع شده، زمان آن تغییر را با نخستین سفارش ناموفق مقایسه کنید. این هم زمانی سرنخ است؛ برای اثبات علت هنوز به آزمایش نیاز دارید.

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

اتصال پنل پیامکی را مستقل از سفارش بررسی کنید

ابتدا از داخل پنل، یک پیام کوتاه به شماره ای که در اختیار دارید بفرستید. از همان روش ارسال و خطی استفاده کنید که قرار است در فروشگاه فعال باشد. موفقیت ارسال با یک خط دیگر یا مسیر متفاوت، سالم بودن اتصال موردنظر را ثابت نمی کند.

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

در تنظیمات وب سرویس، نام ارائه دهنده، نوع اعتبارنامه و آدرس سرویس را با مستندات همان درگاه تطبیق دهید. بعضی اتصال ها کلید API می خواهند و برخی از سازوکار دیگری استفاده می کنند. عنوان یک فیلد به تنهایی مشخص نمی کند که باید رمز ورود به پنل را در آن بنویسید.

کلید را از نظر فاصله اضافی، انقضا، لغوشدن و محدودیت دسترسی بررسی کنید. اگر ارائه دهنده محدودیت IP دارد، IP خروجی درخواست های هاست ملاک است؛ این آدرس الزاماً با IP دامنه یا رایانه توسعه دهنده یکسان نیست. در مهاجرت هاست، این تفاوت را دوباره کنترل کنید.

فعال بودن اعلان و رویداد سفارش را تطبیق دهید

ثبت سفارش را با پرداخت موفق یکسان نگیرید

سفارش ممکن است ایجاد شود اما هنوز پرداختی برای آن تأیید نشده باشد. اگر پیامک فقط برای وضعیت «در حال انجام» فعال است، باقی ماندن سفارش در «در انتظار پرداخت» لزوماً خطای افزونه نیست. باید ببینید شرطی که برای ارسال تعیین کرده اید واقعاً رخ داده است یا خیر.

در مستندات ووکامرس، وضعیت Processing به پرداخت دریافت شده و سفارش در انتظار انجام اشاره دارد؛ On hold می تواند مربوط به انتظار تأیید پرداخت باشد. همچنین سفارش هایی که همه محصولاتشان هم مجازی و هم دانلودشدنی هستند، می توانند مسیر متفاوتی داشته باشند. تنظیم اعلان را با جریان واقعی فروشگاه هماهنگ کنید.

پیامک مدیر و مشتری را جداگانه آزمایش کنید

رسیدن پیام به مدیر نشان می دهد دست کم یک مسیر ارسال کار کرده است، اما درستی اعلان مشتری را ثابت نمی کند. فعال بودن اعلان، وضعیت هدف، متن و گیرنده هر مسیر را مستقل بررسی کنید. اگر افزونه انتخاب دریافت اعلان را به مشتری می دهد، مقدار ثبت شده همان سفارش را نیز ببینید.

برای آزمایش، یک سفارش تازه بسازید و آن را از وضعیت قبلی به وضعیت هدف منتقل کنید. ذخیره دوباره سفارشی که از قبل در وضعیت هدف قرار دارد، الزاماً رویداد تغییر وضعیت ایجاد نمی کند. نتیجه را با یادداشت سفارش و زمان درخواست تطبیق دهید؛ صرفاً ظاهر صفحه مدیریت کافی نیست.

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

شماره مشتری را در داده سفارش پیدا کنید

شماره ای که خریدار در صفحه تسویه حساب دیده است ممکن است در فیلد موردانتظار افزونه ذخیره نشده باشد. این موضوع در فرم های سفارشی، خرید مهمان و افزونه های ویرایش فیلد اهمیت دارد. مقدار واقعی سفارش را بخوانید و با شماره موجود در درخواست خروجی مقایسه کنید.

قالب شماره را مطابق قرارداد API بررسی کنید. تفاوت میان شماره داخلی، پیش شماره کشور، علامت مثبت، فاصله و ارقام فارسی ممکن است روی اعتبارسنجی اثر بگذارد. بدون اطلاع از قالب موردقبول درگاه، صفر ابتدایی یا پیش شماره را به صورت سراسری حذف نکنید.

برای تشخیص مشکل نگاشت، سفارش مهمان و کاربر واردشده را با شماره تست یکسان مقایسه کنید. اگر فقط یکی ناموفق است، بررسی کنید افزونه شماره را از سفارش می خواند یا پروفایل کاربر. این آزمایش یک متغیر را تغییر می دهد و نتیجه آن از تغییر هم زمان چند تنظیم روشن تر است.

در توسعه اختصاصی، داده سفارش را از API ووکامرس بگیرید. راهنمای HPOS استفاده از wc_get_order و روش های CRUD ووکامرس را به جای دسترسی مستقیم به داده های سفارش توصیه می کند. خواندن مستقیم جدول های قدیمی می تواند در فروشگاهی با ساختار ذخیره سازی متفاوت، نتیجه نامعتبر بدهد.

اعتبار حساب و مجوز خط را کنترل کنید

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

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

برای آزمایش اولیه از متن کوتاه و گیرنده مشخص استفاده کنید. پس از موفقیت، متن واقعی سفارش را امتحان کنید تا اثر طول متن، کاراکترها و محتوای متغیرها روشن شود. اگر هزینه برحسب بخش پیام محاسبه می شود، متن طولانی ممکن است به اعتبار بیشتری نیاز داشته باشد.

پاسخ وب سرویس را به اقدام مشخص تبدیل کنید

پاسخ شبکه، نتیجه پردازش API و گزارش تحویل سه مدرک متفاوت اند. دریافت پاسخ HTTP موفق، به تنهایی پذیرش پیامک را ثابت نمی کند؛ ممکن است بدنه پاسخ خطای تجاری داشته باشد. شناسه پیام و کد نتیجه را براساس مستندات همان سرویس تفسیر کنید.

این جدول راهنمای دسته بندی است؛ معنی کدهای اختصاصی را از مستندات درگاه استخراج کنید. حتی پاسخ های مشابه ممکن است در سرویس های مختلف معنای متفاوت داشته باشند. برای گزارش فنی، متن خطا را همراه با زمان و شناسه درخواست نگه دارید، نه فقط عبارت «ارسال ناموفق».

ارسال عادی و پترن را مستقل عیب یابی کنید

در ارسال عادی، متن نهایی و فرستنده اهمیت دارند؛ در ارسال پترن، شناسه الگو و نگاشت متغیرها نیز وارد مسیر می شوند. موفقیت یکی، سلامت دیگری را تضمین نمی کند. اگر متن ساده می رسد ولی الگو ناموفق است، ابتدا اختلاف درخواست ها را بررسی کنید.

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

مقدار خالی، نام طولانی محصول یا فهرست چندخطی اقلام را بدون بررسی محدودیت قالب در پارامتر قرار ندهید. همچنین واحد مبلغ و قالب نمایش آن را روشن کنید. پیامک فروشگاه اینترنتی باید برای مشتری قابل فهم باشد؛ پذیرفته شدن درخواست، درستی معنای متن را تأیید نمی کند.

ارتباط خروجی هاست را از همان محیط آزمایش کنید

بازشدن پنل پیامکی در مرورگر شما، دسترسی سرور فروشگاه به API را ثابت نمی کند. درخواست آزمایشی را از همان هاست و ترجیحاً مسیر اجرای افزونه بفرستید. خطاهای DNS، گواهی TLS، فایروال و پراکسی را از خطای احراز هویت جدا کنید.

در بررسی HTTP API وردپرس، ابتدا تفاوت WP_Error و پاسخ HTTP را مشخص کنید. در حالت نخست ممکن است اصلاً پاسخی از سرویس دریافت نشده باشد؛ در حالت دوم، کد وضعیت و بدنه پاسخ برای تشخیص لازم اند. اگر افزونه از SOAP یا کتابخانه دیگری استفاده می کند، ابزار و وابستگی همان مسیر را بررسی کنید.

طبق مرجع رسمی درخواست HTTP وردپرس، مقدار پیش فرض timeout برابر ۵ ثانیه است. این مقدار ویژگی پیش فرض آن API است و افزونه یا فیلتر می تواند تغییرش دهد؛ بنابراین نباید آن را زمان انتظار قطعی همه افزونه ها دانست. مقدار مؤثر درخواست را بررسی کنید.

برای رفع خطای گواهی، اعتبارسنجی TLS را دائمی غیرفعال نکنید؛ زنجیره گواهی و تنظیمات سرور را اصلاح کنید. افزایش زمان انتظار هم باید بر پایه اندازه گیری باشد. اگر سرویس درخواست را پذیرفته اما پاسخ دیر رسیده، تکرار فوری آن می تواند پیامک تکراری بسازد.

صف ارسال و کرون را در صورت استفاده افزونه بررسی کنید

همه افزونه های پیامکی از صف استفاده نمی کنند. ابتدا با مستندات یا کد مشخص کنید ارسال هم زمان انجام می شود یا به کار پس زمینه سپرده شده است. تنها در حالت دوم، سلامت زمان بند مستقیماً به این بخش از عیب یابی مربوط می شود.

همانطور که در developer.wordpress.org گفته شده: «WP-Cron does not run constantly as the system cron does; it is only triggered on page load.» 

ترجمه: WP-Cron مانند کرون سیستم دائماً اجرا نمی شود و با بارگذاری صفحه فعال می شود. این محدودیت می تواند اجرای کارهای زمان بندی شده را عقب بیندازد.

اگر اتصال از Action Scheduler استفاده می کند، نام هوک مربوط را در اقدامات زمان بندی شده پیدا کنید و وضعیت، زمان و لاگ آن را بخوانید. طبق مستندات رسمی Action Scheduler، اندازه پیش فرض دسته ۲۵ اقدام و سقف پیش فرض زمان پردازش هر درخواست ۳۰ ثانیه است؛ تنظیمات سایت می تواند متفاوت باشد.

این اعداد نرخ ارسال پیامک نیستند و ظرفیت اپراتور را نشان نمی دهند. پیش از افزایش محدودیت ها، علت شکست کار، ازدحام صف و زمان پاسخ سرویس را بررسی کنید. اجرای دسته جمعی کارهای معوق نیز باید پس از بررسی گیرندگان و احتمال ارسال مجدد انجام شود.

لاگ را به زنجیره شواهد تبدیل کنید

در ووکامرس، مسیر «ووکامرس ← وضعیت ← گزارش ها» نقطه شروع مناسبی برای بررسی خطاهای PHP است. راهنمای رسمی نیز این بخش را پیش از مراجعه به لاگ PHP سرور پیشنهاد می کند. بااین حال، ثبت جزئیات پیامک به امکانات و تنظیمات افزونه وابسته است.

اگر توسعه اتصال در اختیار شماست، برای هر تلاش ارسال یک شناسه پیگیری داخلی ثبت کنید. آن را میان رویداد سفارش، فراخوانی API و پاسخ سرویس حفظ کنید تا بتوانید توقف مسیر را پیدا کنید. شماره کامل مشتری و کلید دسترسی نباید وارد لاگ عمومی شوند.

برای یک گزارش عیب یابی قابل پیگیری، این اطلاعات را کنار هم نگه دارید:

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

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

تداخل افزونه ها را با آزمایش کنترل شده پیدا کنید

اگر مشکل پس از افزودن ابزارهای مدیریت فروشگاه اینترنتی شروع شده، افزونه های تغییر وضعیت، تسویه حساب، امنیت و اتوماسیون را بررسی کنید. چند ابزار ممکن است یک رویداد را تغییر دهند یا هم زمان پیام بفرستند. حذف تصادفی تنظیمات معمولاً منشأ این رفتار را روشن نمی کند.

در محیط آزمایشی، مسیر ضروری خرید و ارسال را نگه دارید و افزونه های مشکوک را مرحله ای بررسی کنید. پس از هر تغییر، همان سناریوی ثابت را تکرار کنید. راهنمای عیب یابی ووکامرس نیز استفاده از محیط تست و فعال سازی مرحله ای افزونه ها را برای تشخیص تداخل توضیح می دهد.

پس از اصلاح اتصال سناریوی واقعی خرید را تکرار کنید

موفقیت دکمه ارسال آزمایشی پایان کار نیست. یک خرید واقعی در محیط تست انجام دهید و مسیر ثبت، پرداخت، تغییر وضعیت و اعلان را دنبال کنید. سپس آزمون های پذیرش را با شماره های کنترل شده اجرا کنید:

• سفارش مهمان و کاربر واردشده، با داده گیرنده معتبر.
• پرداخت موفق و ناموفق، با متن متناسب وضعیت هرکدام.
• پیامک مدیر و مشتری، با بررسی مستقل گیرنده و محتوا.
• تغییر وضعیت مجدد و تکرار پاسخ پرداخت، با کنترل پیامک ناخواسته.
• ارسال عادی و پترن، فقط برای مسیرهایی که فروشگاه استفاده می کند.

معیار قبولی را پیشاپیش تعیین کنید: درخواست در رویداد درست ایجاد شود، گیرنده و متن صحیح باشند و نتیجه سرویس قابل پیگیری بماند. برای جلوگیری از تکرار، منطق اتصال باید رویدادهای تکراری را تشخیص دهد. صرفاً علامت گذاری سفارش پیش از مشخص شدن نتیجه ارسال می تواند تلاش ناموفق را پنهان کند.

تطبیق تنظیمات اتصال پیام رسان

در بسته معرفی شده پیام رسان، درگاه را روی payam-resan.com قرار دهید، کلید API را در «نام کاربری وب سرویس» بنویسید و فیلد رمز عبور را خالی کنید. سپس خط مجاز حساب و اعلان وضعیت موردنظر را بررسی کنید. این تنظیمات مخصوص همین اتصال است و نباید به درگاه های دیگر تعمیم داده شود.

اگر مشکل بعد از تعویض نسخه شروع شده، بسته نصب شده را نیز با راهنمای ارائه دهنده تطبیق دهید. برای بررسی مراحل اتصال و دستور پترن، راهنمای فنی را در نشانی زیر ببینید: https://payam-resan.com/lab/plugins/persian-woocommerce-sms/

پرسش های متداول

چرا پیامک آزمایشی می رسد اما پیامک سفارش ارسال نمی شود

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

آیا رسیدن پیامک مدیر سلامت اعلان مشتری را ثابت می کند

خیر. تنظیمات و گیرنده این دو مسیر ممکن است متفاوت باشند. شماره مشتری را در داده همان سفارش پیدا کنید و با گیرنده درخواست خروجی مقایسه کنید؛ به شماره پروفایل اکتفا نکنید.

چرا با وجود شناسه پیام مشتری چیزی دریافت نکرده است

شناسه معمولاً امکان پیگیری درخواست ثبت شده را فراهم می کند و به تنهایی تحویل را اثبات نمی کند. گزارش تحویل همان پیام را بررسی کنید و معنی وضعیت آن را از مستندات سرویس بخوانید.

آیا افزایش زمان انتظار خطای اتصال را برطرف می کند

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

برای پشتیبانی چه اطلاعاتی ارسال کنیم

نسخه ها، زمان خطا، شناسه سفارش، سناریوی بازتولید، پاسخ پوشانده شده سرویس و شناسه پیام را ارائه کنید. کلید API، رمزها و اطلاعات کامل مشتری را در تیکت عمومی یا تصویر تنظیمات نمایش ندهید.