ریکاور MU-Plugin

مسئله تجاری

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

آنچه تحویل دادم

• a2-recover-sms-mu.php، یک MU-plugin ۱۲۹۵ خطی که پیام‌های بازیابی را با Action Scheduler و در گروه اختصاصی خودش زمان‌بندی می‌کند، نه روی wp-cron.
• چهار نقطه‌ی شروع بازیابی: ثبت سفارش در پرداخت، رفتن سفارش به pending، رفتن به on-hold، و افزودن به سبد یا بازکردن صفحه‌ی پرداخت برای سبدهایی که هیچ‌وقت سفارش نشدند.
• مسیر اجباری pending به failed با مهلت ۳۱ دقیقه، که عمداً کمی بعد از پنجره‌ی خود درگاه تنظیم شده.
• یک جاروی پنج‌دقیقه‌ای قفل‌دار به‌علاوه‌ی یک دیدبان روی wp_loaded، تا این انتقال روی سایتی که رویدادهای زمان‌بندی‌شده‌اش قابل‌اتکا نیست هم انجام شود.
• رهگیری لغو سفارش پرداخت‌نشده‌ی خود ووکامرس، تا دو سازوکار هم‌زمان سراغ یک سفارش نروند.
• لینک‌های کوتاه که به دسته یا کارت هدیه‌ی مشخصی می‌رسند، تا پیام بازیابی بتواند به چیزی مفیدتر از سبد اشاره کند.
• بازگرداندن کوپن از روی کوکی در سه هوک جداگانه‌ی سبد و پرداخت، تا مشوقی که همراه پیام رفته، تا انتهای مسیر بازگشت مشتری دوام بیاورد.

رویکرد فنی

• Action Scheduler به‌جای wp-cron و در یک گروه جدا. پیام بازیابی نباید با ازدست‌رفتن یک اجرای کرون بپرد، و وقتی مشتری می‌پرسد چرا این پیام را گرفته، باید بشود ردش را دید.
• مهلت ۳۱ دقیقه عمداً یک دقیقه بعد از پنجره‌ی درگاه است، تا افزونه هیچ‌وقت سر یک سفارش با ارائه‌دهنده‌ی پرداخت مسابقه ندهد.
• جارو قبل از شروع قفل می‌گیرد. دو جاروی هم‌پوشان روی یک سایت کند، دقیقاً همان چیزی است که یک پیام را دوبار برای مشتری می‌فرستد.
• دیدبان wp_loaded برای این هست که روی فروشگاهی پشت کش سنگین نمی‌شود به رویدادهای زمان‌بندی‌شده اعتماد کرد. جارو مسیر اصلی است و دیدبان فقط تور ایمنی.
• نام قالب پیامک و کلید API از ثابت‌هایی خوانده می‌شوند که جای دیگری تعریف شده‌اند؛ هیچ اعتبارنامه‌ای داخل این فایل نیست.

نتیجه و شواهد

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

اهمیت برای کارفرما

هر دو نیمه در کار روزمره خرجشان را درمی‌آورند. یک طرف سبدهای بازگشته است، طرف دیگر وضعیت درست سفارش — همان چیزی که سطح موجودی و گزارش روزانه به آن تکیه دارند.