کش ووکامرس؛ چرا قیمت قدیمی یا سبد خرید اشتباه نمایش داده می‌شود؟
اگر قیمت در مدیریت تغییر کرده اما مشتری مقدار قبلی را می‌بیند، یا سبد خرید پس از افزودن کالا خالی به نظر می‌رسد، کش یکی از علت‌های قابل بررسی است. پیش از پاک‌کردن همه‌چیز، مشخص کنید کدام پاسخ قدیمی است و از کدام لایه می‌آید. هدف، فروشگاه سریع با قیمت و سبد صحیح است؛ این راهنما مسیر تشخیص و آزمون اصلاح را توضیح می‌دهد.
اول تفاوت قیمت را دقیق ثبت کنید
نام کالا و تنوع، صفحه‌ای که مقدار اشتباه دارد، زمان آخرین تغییر و وضعیت ورود مشتری را بنویسید. قیمت فهرست، صفحهٔ محصول و سبد را در شرایط یکسان مقایسه کنید. تفاوت مالیات، واحد پول، قیمت ویژه یا انتخاب تنوع ممکن است شبیه کش قدیمی دیده شود. اگر خود دادهٔ محصول نادرست است، پاک‌کردن کش دادهٔ درست نمی‌سازد.
برای نمونه، اگر فقط مشتری مهمان قیمت قدیمی می‌بیند ولی مدیر مقدار جدید را دریافت می‌کند، پاسخ عمومی و پاسخ کاربر واردشده را جدا بررسی کنید. این تفاوت فرضیهٔ کش صفحه را تقویت می‌کند، اما به‌تنهایی آن را اثبات نمی‌کند. اگر قیمت از فایل یا انبار می‌آید، ابتدا نتیجهٔ ویرایش گروهی قیمت یا همگام‌سازی انبار را کنترل کنید.
کدام لایه را بررسی کنیم؟
- مرورگر: آیا مشکل فقط در یک مرورگر رخ می‌دهد؟ بازکردن یک نشست مستقل کمک می‌کند اثر دادهٔ محلی از پاسخ عمومی جدا شود.
- کش صفحه در افزونه یا سرور: ممکن است HTML آماده را بدون اجرای دوبارهٔ وردپرس برگرداند. قانون حذف کش باید صفحهٔ تغییرکرده و محل‌های مرتبط با آن را پوشش دهد.
- CDN یا پراکسی: حتی پس از پاک‌شدن کش افزونه، یک پاسخ قدیمی در لایهٔ بیرونی ممکن است باقی بماند. دامنه، مسیر و قانون فعال را ثبت کنید.
- کش داده یا نتیجهٔ محاسبه: اگر HTML تازه تولید می‌شود اما قیمت محاسبه‌شده قدیمی است، مسیر خواندن داده و کلید کش افزونهٔ مربوط را بررسی کنید.
در ابزار Network مرورگر، پاسخ HTML و درخواست‌های داده را جدا ببینید. سربرگ‌های Cache-Control، Age و وضعیت اختصاصی کشِ ارائه‌دهنده سرنخ‌اند؛ نام و معنای همهٔ سربرگ‌ها یکسان نیست. نبود Age هم ثابت نمی‌کند هیچ کشی وجود ندارد. رفتار واقعی و تنظیمات هر لایه را کنار هم بررسی کنید.
کدام صفحات نباید پاسخ مشترک مشتریان داشته باشند؟
راهنمای رسمی تنظیم کش ووکامرس می‌گوید سبد خرید، تسویه‌حساب و حساب کاربری به دادهٔ همان مشتری وابسته‌اند و باید از کش صفحه مستثنا شوند. بسیاری از افزونه‌ها این استثناها را دارند؛ پس از نصب یا تغییر تنظیمات، عملکردشان را بررسی کنید. مسیر واقعی صفحات فروشگاه خود را در نظر بگیرید؛ ممکن است نامک فارسی یا مسیر سفارشی داشته باشند.
این استثناها باید در تمام لایه‌های کش صفحه برقرار باشند. مستثناکردن صفحه در افزونه، قانون عمومی CDN را عوض نمی‌کند. درخواست افزودن کالا، تغییر تعداد، اعمال کوپن و پاسخ‌های شخصی سفارش هم نباید به‌صورت یک پاسخ عمومی بین مشتریان بازاستفاده شوند. قواعد را با روش درخواست، پارامترها و نوع رابط خرید فروشگاه تطبیق دهید.
کوکی نشست و Store API چه نقشی دارند؟
طبق مستند کوکی‌های ووکامرس، کوکی‌های woocommerce_cart_hash و woocommerce_items_in_cart به تشخیص تغییر سبد کمک می‌کنند و wp_woocommerce_session_ به یافتن دادهٔ سبد همان مشتری مربوط است. قواعد کشی که وضعیت نشست را نادیده می‌گیرند باید بررسی شوند. مقدار کوکی یا توکن مشتری را در گزارش عمومی قرار ندهید.
در رابط‌های سفارشی، بررسی فقط HTML کافی نیست. مستند Cart Tokens توضیح می‌دهد که در اتصال headless، توکن می‌تواند سبد را در درخواست‌های Store API مشخص کند. در چنین معماری‌ای، آزمون جدایی سبد باید توکن و درخواست‌های API را نیز پوشش دهد؛ قاعده‌ای که فقط کوکی را می‌شناسد برای همهٔ پیاده‌سازی‌ها کافی نیست. پیکربندی آمادهٔ یک فروشگاه دیگر را بدون بررسی معماری کپی نکنید.
مثال فرضی: پاک‌کردن کش فقط چند دقیقه کمک می‌کند
فرض کنید پس از تغییر قیمت، پاک‌کردن کش افزونه برای مدیر نتیجهٔ درست دارد، اما مهمان هنوز قیمت قبلی می‌بیند. در یک محیط آزمایشی، ابتدا پاسخ محصول برای مهمان را ثبت می‌کنیم، سپس فقط کش همان مسیر در لایهٔ بیرونی را کنار می‌گذاریم و درخواست را تکرار می‌کنیم. اگر تفاوت تأیید شد، مسیر بررسی به قانون CDN و پاک‌سازی وابسته به تغییر محصول می‌رسد.
حالا باید بدانیم قیمت در دسته‌بندی، جست‌وجو و کارت محصولات مرتبط هم دیده می‌شود یا نه. حذف کش فقط URL محصول ممکن است همهٔ نمایش‌ها را تازه نکند. این سناریو آموزشی است، نه نتیجهٔ یک پروژهٔ مشتری. معیار پیشنهادی این است که پس از تغییر، تمام محل‌های توافق‌شده حداکثر در بازهٔ زمانی مشخص به مقدار جدید برسند؛ زمان را بر اساس نیاز همان فروشگاه تعیین کنید.
آزمون دو مشتری مستقل، پیش و پس از اصلاح
- دو نشست جدا بسازید: از دو پروفایل مرورگر مستقل استفاده کنید. دو تب معمولی یک مرورگر معمولاً نشست جدا ایجاد نمی‌کنند.
- سبدهای متفاوت بسازید: مشتری الف کالای اول و مشتری ب کالای دیگری اضافه کند. تعداد و حذف کالا در هر نشست فقط همان سبد را تغییر دهد.
- بازگشت به صفحات را امتحان کنید: از محصول به دسته و سپس به سبد برگردید؛ شمارندهٔ سبد، محتوای آن و مبلغ باید با هم سازگار باشند.
- قیمت را کنترل‌شده تغییر دهید: در محیط آزمایشی، تغییر قیمت یک تنوع را از محصول تا سبد دنبال کنید. رفتار سبد از قبل بازشده باید مشخص و قابل توضیح باشد.
- شرایط خرید را تغییر دهید: کوپن، آدرس ارسال و ورود یا خروج را امتحان کنید؛ نتیجه باید مربوط به همان مشتری و قواعد فروشگاه باشد.
- کش گرم را هم بسنجید: پس از چند درخواست تکراری و فعال‌شدن کش، آزمون جدایی دو مشتری را دوباره اجرا کنید. درست‌بودن اولین پاسخ کافی نیست.
آزمون را با دادهٔ ساختگی و روش پرداخت آزمایشی انجام دهید. نتیجهٔ مورد انتظار، نتیجهٔ مشاهده‌شده، زمان و لایهٔ اصلاح‌شده را ثبت کنید. اگر مشکل فقط در تسویه‌حساب بلوکی دیده می‌شود، درخواست‌های آن را جدا بررسی کنید؛ راهنمای سازگاری Checkout Blocks به تعیین دامنهٔ آزمون کمک می‌کند.
خاموش‌کردن همهٔ کش‌ها راه‌حل نهایی است؟
کنارگذاشتن موقت یک لایه در محیط آزمایشی می‌تواند به تشخیص کمک کند. برای انتشار، محدودهٔ کش عمومی، مسیرهای شخصی، روش تازه‌کردن داده و آزمون بازگشت باید مشخص باشند. سرعت صفحهٔ محصول مهمان را از زمان پاسخ سبد و تسویه‌حساب جدا گزارش کنید؛ بهترشدن یکی، بهترشدن همهٔ مسیر خرید را ثابت نمی‌کند.
پس از اصلاح، همان شرایط و چند اجرای مشابه را مقایسه کنید و صحت خرید را کنار زمان پاسخ بنویسید. راهنمای شروع بهینه‌سازی سرعت چارچوب اندازه‌گیری را توضیح می‌دهد. اگر مسئله در مدیریت سفارش‌هاست، تشخیص کندی پیشخوان مسیر جداگانه‌ای دارد.
برای بررسی کش فروشگاه چه اطلاعاتی لازم است؟
دو URL نمونه، تفاوت مورد انتظار و مشاهده‌شده، زمان تغییر قیمت، وضعیت ورود مشتری و نام افزونهٔ کش، میزبان و CDN را آماده کنید. تصویر خطا و سربرگ‌ها را بدون کوکی، توکن و اطلاعات مشتری بفرستید. در بررسی سرعت و زیرساخت، دامنهٔ تشخیص و معیار صحت خرید مشخص می‌شود. از فرم درخواست بررسی سرعت توضیح دهید مشکل برای مهمان، مشتری واردشده یا هر دو رخ می‌دهد.