ریکاور MU-Plugin

مسئله تجاری

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

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

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

رویکرد فنی

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

نتیجه و شواهد

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

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

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