HPOS یا High-Performance Order Storage روش ذخیره سفارش‌های ووکامرس در جدولهای اختصاصی سفارش است. هدف آن بهبود ساختار داده سفارش است، نه تغییر ظاهر فروشگاه. فعالکردن HPOS جای بهینه‌سازی تصاویر، رفع خطای افزونه یا اصلاح درگاه کند را نمی‌گیرد. برای فروشگاه فعال، تصمیم اصلی این است که افزونه‌ها سازگارند و انتقال داده بدون حذف یا نادیده‌گرفتن سفارش‌های تازه انجام می‌شود.
این راهنما مسیر بررسی، آزمایش، همگامسازی، تغییر منبع اصلی و بازگشت کنترل‌شده را توضیح می‌دهد. هیچ درصد ثابت افزایش سرعت وعده داده نمی‌شود. اگر از وردپرس مدیریت‌شده پاستا استفاده می‌کنید، بکاپ و امکانات محیط کمک‌کننده‌اند، اما تأیید سازگاری منطق فروشگاه همچنان لازم است.
HPOS چه چیزی را تغییر می‌دهد؟
ووکامرس در ساختار قدیمی از جدولهای عمومی نوشته و متادیتا برای سفارش استفاده می‌کرد. HPOS جدولهای متناسب با سفارش دارد. جزئیات در مستندات توسعه‌دهندگان ووکامرس آمده است. افزونه‌ای که از API رسمی سفارش استفاده میکند، مسیر سازگارتری از افزونه‌ای دارد که مستقیم به جدول قدیمی وابسته است.
تغییر ذخیره سفارش با تغییر همه داده‌های وردپرس یکی نیست. محصول، نوشته و تنظیمات نقش‌های دیگری دارند. همچنین HPOS با Headless متفاوت است: اولی درباره ذخیره سفارش است و دومی درباره جداسازی فرانت‌اند. برای مقایسه معماری، راهنمای Headless WordPress را جدا مطالعه کنید.
آیا فروشگاه کوچک هم به HPOS نیاز دارد؟
اندازه فروشگاه تنها عامل نیست. سازگاری افزونه‌ها، وضعیت نسخه فعلی و هزینه نگهداری مهم‌اند. فروشگاه تازه ممکن است از ابتدا با HPOS کار کند؛ فروشگاه قدیمی با چند افزونه اختصاصی به بررسی بیشتری نیاز دارد. ابتدا وضعیت واقعی سایت را در تنظیمات ووکامرس ببینید؛ وجود گزینه‌ای در راهنما به معنی غیرفعال‌بودن آن روی سایت شما نیست.
اگر مشکل فعلی از تصویر چندمگابایتی یا اسکریپت سنگین مرورگر باشد، HPOS درمان آن نیست. اگر Queryهای سفارش، مدیریت سفارش‌های زیاد یا عملیات هم‌زمان گلوگاه‌اند، ساختار ذخیره سفارش ارزش بررسی بیشتری دارد. برای خط مبنا، راهنمای افزایش سرعت وردپرس کمک میکند علت‌ها را تفکیک کنید.
پیش از انتقال، فهرست وابستگی‌های سفارش را بسازید
فقط افزونه درگاه را بررسی نکنید. صدور فاکتور، حمل‌ونقل، پیامک، حسابداری، اشتراک، باشگاه مشتریان، گزارش فروش، ورود و خروج داده و کدهای سفارشی قالب ممکن است سفارش بخوانند یا تغییر دهند. برای هر مورد نسخه، سازنده، اعلام سازگاری و سناریوی آزمون را ثبت کنید. ادعای سازگاری افزونه نقطه شروع است، نه پایان آزمون.
کد اختصاصی باید از توابع و مدل‌های داده سفارش ووکامرس استفاده کند. وجود SQL مستقیم روی جدول نوشته‌ها یا فراخوانی متادیتای عمومی برای داده سفارش، علامت نیاز به بازبینی است. صرفاً تغییر نام جدول در Query راهحل مطمئنی نیست؛ قرارداد داده و افزونه‌های فیلترکننده نیز مهم‌اند.
| وابستگی | آزمون ضروری | شواهد پذیرش |
|---|---|---|
| درگاه پرداخت | پرداخت، بازگشت، تکرار Callback | یک پرداخت و یک تغییر وضعیت درست |
| انبار و حمل‌ونقل | کاهش موجودی، لغو و برچسب ارسال | تطبیق موجودی و اطلاعات ارسال |
| حسابداری و گزارش | سفارش تازه، تخفیف و بازپرداخت | مبلغ و وضعیت یکسان در دو سیستم |
| کد اختصاصی | خواندن و ویرایش سفارش | عدم وابستگی به ذخیره قدیمی |
۱. بکاپی بگیرید که واقعاً قابل بازیابی باشد
بکاپ فقط فایل دانلودشده نیست؛ باید بدانید دیتابیس، فایل‌ها و تنظیمات ضروری در آن هستند و بازیابی آزمایشی چگونه انجام می‌شود. نسخه ووکامرس، افزونه‌ها و زمان بکاپ را ثبت کنید. محیط بازیابی باید از درگاه واقعی، ارسال پیامک و ایمیل انبوه جدا باشد تا بازگردانی آزمایشی اثر خارجی نسازد.
برای فروشگاه فعال، بکاپ چند ساعت قبل شامل سفارش‌های بعدی نیست. بازگرداندن کامل آن روی سایت زنده میتواند سفارش جدید را حذف کند. بنابراین برنامه بازگشت باید درباره داده‌های ایجادشده پس از تغییر تصمیم روشن داشته باشد. «اگر نشد بکاپ را برمی‌گردانیم» بدون این بخش، برنامه امنی برای فروشگاه نیست.