چرا کوکی وردپرس کار نمی کند به همراه راه حل رفع مشکل

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

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

کوکی در وردپرس دقیقاً چه نقشی دارد؟

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

در وردپرس، کوکی‌ها چهار نقش اصلی دارند: کوکی احراز هویت (login cookie) که مشخص می‌کند کاربر لاگین کرده است یا نه، کوکی سشن (session cookie) که داده‌ی موقت مانند سبد خرید را نگه می‌دارد، کوکی امنیتی (nonce cookie) که از فرم‌ها در برابر حملات CSRF محافظت می‌کند، و کوکی‌های تحلیلی و تبلیغاتی که توسط افزونه‌های جانبی تنظیم می‌شوند. مباحث مرتبط با این مفهوم در وردپرس چیست و چگونه شروع کنیم باز شده است.

نکته‌ی مهمی که در پروژه‌های واقعی بارها دیده‌ام این است که خطای کوکی، غالباً از یک لایه‌ی ناپیدا می‌آید: تنظیمی که کاربر فکر می‌کند «طبیعی» است ولی در واقع با مرورگرهای مدرن یا با تنظیمات HTTPS ناسازگار است. مثلاً اگر کوکی با پرچم SameSite=Strict تنظیم شود ولی سایت شما از CDN یا دامنه‌ی متفاوت برای پردازش پرداخت استفاده کند، کاربر به‌طور ناخودآگاه لاگ‌اوت می‌شود. همین ظرافت، دلیل اصلی سردرگمی در عیب‌یابی این خطاست.

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

کوکی، حافظه‌ی کوتاه‌مدت وردپرس است. اگر این حافظه از بین برود، وردپرس هر بازدیدکننده را یک غریبه‌ی تازه می‌بیند و همه‌ی جریان‌های احراز هویت، سشن و سبد خرید به هم می‌ریزد.

انواع خطای کوکی و نشانه‌ی هرکدام

خطاهای کوکی در وردپرس، پیام‌ها و نشانه‌های متنوعی دارند که هرکدام به ریشه‌ی متفاوتی اشاره می‌کنند:

در تجربه‌ی چندساله‌ام، چهار نشانه‌ی اول شایع‌تر هستند و در ۷۰ درصد موارد، با اصلاح تنظیمات SameSite یا Secure حل می‌شوند. بقیه‌ی موارد، نیازمند عیب‌یابی دقیق‌تر در لایه‌های CDN یا افزونه است.

ده ریشه‌ی اصلی خطای کوکی در وردپرس

در عیب‌یابی خطای کوکی روی سایت‌های وردپرسی، این ده ریشه بیش از بقیه تکرار می‌شوند:

ریشه‌ی اول: تنظیم SameSite ناسازگار

شایع‌ترین دلیل. از چند سال پیش، مرورگرهای مدرن (مثل Chrome و Firefox) به‌طور پیش‌فرض کوکی‌هایی که پرچم SameSite مشخص ندارند را در درخواست‌های cross-site مسدود می‌کنند. اگر وردپرس یا افزونه‌ای کوکی خود را بدون این پرچم تنظیم کند، ممکن است در بعضی مرورگرها کار کند و در بعضی نه. راه‌حل: تنظیم صریح SameSite=Lax برای کوکی‌های احراز هویت. مباحث مرتبط در امن‌سازی لاگین ادمین وردپرس باز شده است.

ریشه‌ی دوم: پرچم Secure نادرست

اگر کوکی با پرچم Secure تنظیم شود ولی سایت شما روی HTTP باشد (نه HTTPS)، مرورگر کوکی را ذخیره نمی‌کند. این سناریو بعد از انتقال از HTTPS به HTTP یا برعکس، بسیار شایع است. راه‌حل: اطمینان از اینکه تمام صفحات سایت روی HTTPS سرو می‌شوند. مباحث مرتبط در ریدایرکت HTTP به HTTPS باز شده است.

ریشه‌ی سوم: فیلد دامنه ناسازگار

اگر سایت شما هم روی example.com و هم روی www.example.com پاسخ می‌دهد و کوکی فقط برای یکی از این دو تنظیم شده باشد، کاربرانی که از دامنه‌ی دیگر وارد می‌شوند نمی‌توانند کوکی را ببینند. راه‌حل: انتخاب یک دامنه‌ی canonical و ریدایرکت نسخه‌ی دیگر به آن.

ریشه‌ی چهارم: محدودیت مرورگرهای مدرن

مرورگرهای مدرن محدودیت‌های سختگیرانه‌ای روی کوکی‌ها اعمال می‌کنند: محدودیت تعداد کوکی‌ها به‌ازای هر دامنه، محدودیت حجم هر کوکی، و مسدودسازی کوکی‌های third-party. اگر سایت شما به تعداد زیادی کوکی نیاز دارد یا از کوکی‌های cross-domain استفاده می‌کند، ممکن است با این محدودیت‌ها مواجه شود. راه‌حل: کاهش تعداد کوکی‌ها و حذف کوکی‌های غیرضروری.

ریشه‌ی پنجم: تداخل افزونه‌های امنیتی

افزونه‌های امنیتی مثل Wordfence یا Solid Security، گاهی کوکی‌های خود را اضافه می‌کنند یا کوکی‌های وردپرس را با تنظیمات سختگیرانه‌تر بازنویسی می‌کنند. این سناریو در سایت‌هایی که چند افزونه‌ی امنیتی همزمان دارند، شایع‌تر است. راه‌حل: بررسی تنظیمات کوکی در هر افزونه و رفع تضاد. مباحث مرتبط در رفع خطای تضاد افزونه‌ها در وردپرس باز شده است.

ریشه‌ی ششم: تداخل با CDN یا پراکسی معکوس

اگر سایت شما پشت CDN مثل Cloudflare یا پراکسی معکوس باشد، ممکن است CDN کوکی‌ها را تغییر دهد یا حذف کند. این سناریو در سایت‌هایی که از Page Rules یا قواعد خاص CDN استفاده می‌کنند، شایع‌تر است. راه‌حل: بررسی تنظیمات CDN و اطمینان از اینکه کوکی‌ها به‌درستی عبور می‌کنند. مباحث مرتبط در نقش CDN در سرعت سایت باز شده است.

ریشه‌ی هفتم: کش و ذخیره‌ی کوکی‌ها

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

ریشه‌ی هشتم: مشکل در wp-config یا wp_options

اگر مقدار COOKIE_DOMAIN در wp-config.php نادرست تنظیم شده باشد یا مقادیر siteurl و home در دیتابیس ناسازگار باشند، کوکی به دامنه‌ی اشتباه متصل می‌شود. راه‌حل: بررسی دقیق تنظیمات دامنه.

ریشه‌ی نهم: محدودیت حافظه‌ی مرورگر

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

ریشه‌ی دهم: مسدودسازی توسط نرم‌افزارهای کاربر

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

پروتکل واکنش سریع در بحران

اگر سایت شما همین حالا با خطای کوکی مواجه است و کاربران نمی‌توانند وارد شوند یا خرید کنند، این پنج حرکت را به همین ترتیب اجرا کنید:

1. تعیین دامنه‌ی خطا: سریع تست کنید که آیا مشکل برای همه‌ی کاربران است یا فقط بعضی. اگر همه، ریشه در تنظیمات کوکی یا سرور است. اگر فقط بعضی، ریشه در مرورگر یا افزونه‌های کاربر است.
2. تست در مرورگر متفاوت: سایت را در Chrome، Firefox و Safari باز کنید. اگر مشکل فقط در یک مرورگر رخ می‌دهد، ریشه در تنظیمات SameSite یا Secure است.
3. پاک‌سازی کش مرورگر و افزونه: کش مرورگر و کش افزونه را پاک کنید. اگر مشکل رفع شد، ریشه در کش بوده است.
4. بررسی مجوز پوشه‌ی uploads: اگر از پلاگین ذخیره‌ی سشن روی دیسک استفاده می‌کنید، مجوز پوشه را بررسی کنید. باید 755 باشد.
5. غیرفعال‌سازی موقت افزونه‌های امنیتی: اگر افزونه‌ی امنیتی فعال است، موقتاً آن را غیرفعال کنید و تست کنید.

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

تشخیص دقیق با DevTools و کوئری‌های دیتابیس

ابزارهای تشخیصی، دقیق‌ترین راه پیدا کردن ریشه‌ی خطای کوکی هستند. سه ابزار کلیدی:

DevTools مرورگر

در مرورگر، ابزار DevTools را باز کنید (کلید F12) و به تب Application بروید. بخش Cookies را باز کنید. تمام کوکی‌های سایت در این بخش نمایش داده می‌شوند. سه چیز را بررسی کنید:

1. وجود کوکی‌های ضروری: کوکی‌هایی مثل wordpress_logged_in_* و wp_woocommerce_session_* باید در این لیست باشند. اگر نیستند، ریشه در تنظیمات یا مسدودسازی است.
2. ستون SameSite: اگر مقدار None یا خالی باشد، کوکی در بعضی مرورگرها مسدود می‌شود. مقدار درست معمولاً Lax یا Strict است.
3. ستون Secure: اگر سایت شما HTTPS است ولی کوکی Secure نیست، مرورگر ممکن است کوکی را نادیده بگیرد.

در تب Console، هشدارهای مربوط به کوکی را ببینید. پیام‌هایی مثل Cookie "wordpress_logged_in_*" has been rejected because it is already expired یا Cookie without SameSite attribute was blocked در این بخش نمایش داده می‌شوند. مباحث مرتبط در پیدا کردن خطاهای جاوااسکریپت در کنسول مرورگر باز شده است.

کوئری‌های دیتابیس

بعضی تنظیمات کوکی در دیتابیس ذخیره می‌شوند. سه کوئری کلیدی:

بررسی تنظیمات دامنه و مسیر کوکی:

SELECT option_name, option_value FROM wp_options
WHERE option_name IN ('siteurl', 'home', 'cookie_domain', 'cookie_path');

بررسی طول عمر کوکی‌های احراز هویت:

SELECT option_name, option_value FROM wp_options
WHERE option_name LIKE '%cookie%' OR option_name LIKE '%auth%';

بررسی تعداد کوکی‌های ذخیره‌شده در جدول session:

SELECT COUNT(*) FROM wp_woocommerce_sessions WHERE session_expiry < UNIX_TIMESTAMP();

قبل از اجرای این کوئری‌ها، بکاپ کامل دیتابیس بگیرید. مباحث مرتبط در پشتیبان‌گیری از سایت وردپرس باز شده است.

لاگ وب‌سرور

لاگ وب‌سرور می‌تواند نشان دهد که آیا کوکی‌ها به‌درستی در درخواست‌ها ارسال می‌شوند یا نه. بررسی سربرگ Set-Cookie در پاسخ سرور و سربرگ Cookie در درخواست مرورگر، اولین گام تشخیص است. روش دقیق خواندن لاگ در بررسی خطاهای سرور در لاگ‌ها باز شده است.

SameSite، Secure و HttpOnly در کوکی‌های مدرن

سه پرچم کلیدی در کوکی‌های مدرن، تأثیر مستقیم روی رفتار کوکی در مرورگرها دارند:

SameSite

پرچم SameSite مشخص می‌کند که کوکی در چه شرایطی می‌تواند در درخواست‌های cross-site ارسال شود. سه مقدار ممکن:

• Strict: کوکی فقط در درخواست‌های same-site ارسال می‌شود. امن‌ترین حالت، ولی برای کوکی‌های احراز هویت وردپرس سختگیرانه است.
• Lax: کوکی در درخواست‌های same-site و همچنین در درخواست‌های top-level cross-site با متد GET ارسال می‌شود. تعادل خوبی بین امنیت و کاربری.
• None: کوکی در همه‌ی درخواست‌ها ارسال می‌شود، ولی باید همراه با پرچم Secure باشد. برای مواقعی که سایت شما در iframe یا cross-domain است.

برای کوکی‌های وردپرس، مقدار پیشنهادی Lax است. مباحث مرتبط با تنظیم این پرچم در امن‌سازی فایل wp-config باز شده است.

Secure

اگر این پرچم فعال باشد، کوکی فقط در درخواست‌های HTTPS ارسال می‌شود. اگر سایت شما روی HTTP باشد، این پرچم باعث می‌شود کوکی هرگز ذخیره نشود. راه‌حل: اطمینان از HTTPS روی تمام سایت. مباحث مرتبط در رفع خطای SSL در سرور باز شده است.

HttpOnly

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

فیلد دامنه و مسیر در کوکی‌ها

دو فیلد domain و path در کوکی، تعیین می‌کنند که کوکی در کدام دامنه‌ها و مسیرها معتبر است:

فیلد دامنه

اگر دامنه‌ی کوکی روی .example.com تنظیم شود، کوکی در تمام زیر‌دامنه‌ها معتبر است. اگر روی www.example.com تنظیم شود، فقط در همان دامنه معتبر است. این تفاوت در سایت‌هایی که هم www و هم بدون www پاسخ می‌دهند، بحرانی است.

فیلد مسیر

اگر مسیر کوکی روی / تنظیم شود، کوکی در تمام مسیرهای سایت معتبر است. اگر روی /wp-admin تنظیم شود، فقط در همان مسیر معتبر است. این تنظیم می‌تواند برای جداسازی کوکی‌های مدیریتی از کوکی‌های عمومی مفید باشد، ولی اگر اشتباه تنظیم شود، کوکی در بخش‌هایی از سایت کار نمی‌کند.

اصلاح تنظیمات در وردپرس

وردپرس به‌طور پیش‌فرض فیلد دامنه را از مقدار siteurl در دیتابیس می‌خواند. اگر این مقدار را اشتباه تنظیم کنید، کوکی در دامنه‌ی درست ذخیره نمی‌شود. برای اصلاح:

UPDATE wp_options SET option_value = 'https://example.com' WHERE option_name IN ('siteurl', 'home');

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

SSL، HTTPS و کوکی‌های امن

انتقال سایت از HTTP به HTTPS، یکی از شایع‌ترین دلایل خطای کوکی است. اگر کوکی‌های احراز هویت وردپرس روی HTTP تنظیم شده باشند و سایت شما روی HTTPS باشد، مرورگر ممکن است این کوکی‌ها را نادیده بگیرد.

مشکل رایج بعد از انتقال به HTTPS

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

تنظیم پرچم Secure در wp-config

برای اینکه کوکی‌های وردپرس در همه‌ی شرایط روی HTTPS تنظیم شوند، می‌توانید در wp-config.php این تنظیمات را اضافه کنید:

define('FORCE_SSL_ADMIN', true);
define('COOKIE_DOMAIN', 'example.com');
@ini_set('session.cookie_secure', 1);
@ini_set('session.cookie_httponly', 1);
@ini_set('session.cookie_samesite', 'Lax');

این تنظیمات، امنیت کوکی‌ها را به‌طور قابل توجهی بالا می‌برند. قبل از اعمال، حتماً بکاپ بگیرید. مباحث مرتبط با این فایل در امن‌سازی فایل wp-config باز شده است.

CDN، پراکسی معکوس و کش

CDN و پراکسی معکوس، می‌توانند به‌طور مستقیم روی رفتار کوکی‌ها اثر بگذارند. سه سناریوی رایج:

تنظیمات SSL در CDN

اگر حالت SSL در CDN روی Flexible باشد و سرور اصلی روی HTTP سرو کند، ممکن است کوکی‌های وردپرس با پرچم Secure تنظیم نشوند و مرورگر آن‌ها را رد کند. راه‌حل: تغییر حالت SSL به Full یا Full Strict. مباحث مرتبط در نقش CDN در سرعت سایت باز شده است.

Page Rules در CDN

بعضی CDNها امکان تعریف قواعد سفارشی برای مسیرهای خاص دارند. اگر این قواعد باعث تغییر یا حذف کوکی‌ها شوند، کاربر به‌عنوان مهمان دیده می‌شود. راه‌حل: بررسی Page Rules و مستثنی کردن مسیرهای پیشخوان از این قواعد.

کش CDN

اگر CDN صفحات پویا (مثل پیشخوان، سبد خرید، تسویه‌حساب) را کش کند، کاربران کوکی‌های خود را از دست می‌دهند. راه‌حل: مستثنی کردن این مسیرها از کش CDN.

نکته‌ی میدانی: در یکی از پروژه‌های فروشگاهی که با آن مواجه شدم، سبد خرید ووکامرس فقط برای کاربرانی که پشت Cloudflare بودند خالی می‌شد. ریشه این بود که Cloudflare تنظیمات Caching Level را روی Standard قرار داده بود ولی بعضی درخواست‌های AJAX سبد خرید را کش می‌کرد. با مستثنی کردن مسیر /wp-json/wc/store/، مسئله در چند دقیقه حل شد. مباحث مرتبط با ووکامرس در افزایش امنیت فروشگاه ووکامرس باز شده است.

تداخل افزونه‌ها و قالب

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

افزونه‌های امنیتی

افزونه‌هایی مثل Wordfence، Solid Security یا Sucuri، کوکی‌های خود را برای مدیریت سشن‌ها تنظیم می‌کنند و ممکن است کوکی‌های وردپرس را با تنظیمات سختگیرانه‌تر بازنویسی کنند. این سناریو در سایت‌هایی که چند افزونه‌ی امنیتی همزمان دارند، شایع‌تر است. راه‌حل: حذف افزونه‌های امنیتی موازی و نگه‌داشتن یک افزونه‌ی اصلی. مباحث مرتبط در بهترین افزونه‌های امنیتی وردپرس باز شده است.

افزونه‌های کش

افزونه‌های کش مثل WP Rocket یا LiteSpeed Cache، اگر تنظیمات استثنا به‌درستی انجام نشود، می‌توانند صفحات پویا را کش کنند و کوکی‌های کاربران را از بین ببرند. راه‌حل: مستثنی کردن مسیرهای پیشخوان، سبد خرید و تسویه‌حساب از کش. مباحث مرتبط در بهترین افزونه‌های کش وردپرس باز شده است.

افزونه‌های شخصی‌سازی

افزونه‌هایی که فرم‌های ورود یا ثبت‌نام را بازنویسی می‌کنند، ممکن است کوکی‌های احراز هویت را با تنظیمات ناسازگار تنظیم کنند. این سناریو در سایت‌هایی که از افزونه‌های چندمنظوره استفاده می‌کنند، شایع‌تر است.

روش تشخیص افزونه‌ی مقصر

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

کوکی‌های سشن ووکامرس و سبد خرید

ووکامرس، برای مدیریت سبد خرید و سشن کاربران، از کوکی‌های مخصوص خود استفاده می‌کند. اگر این کوکی‌ها از کار بیفتند، سبد خرید خالی می‌شود و مشتری نمی‌تواند خرید کند.

ساختار کوکی‌های ووکامرس

ووکامرس از دو نوع کوکی استفاده می‌کند: wp_woocommerce_session_* که سشن کاربر را مدیریت می‌کند و woocommerce_items_in_cart که تعداد اقلام سبد را نگه می‌دارد. اگر این کوکی‌ها از کار بیفتند، سبد خرید در هر رفرش خالی می‌شود.

مشکل خاص: سبد خرید برای کاربران مهمان

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

SELECT COUNT(*) FROM wp_woocommerce_sessions;
SELECT session_expiry, session_key FROM wp_woocommerce_sessions LIMIT 10;

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

مشکل خاص: کاربر لاگین‌شده سبد خرید را از دست می‌دهد

اگر کاربر لاگین‌شده سبد خرید خود را بعد از ورود یا خروج از حساب از دست می‌دهد، ریشه در جدول wp_woocommerce_sessions و کوکی‌های احراز هویت است. راه‌حل: بررسی Health Check ووکامرس در مسیر ووکامرس > وضعیت که می‌تواند مشکلات جدول session را نشان دهد.

تداخل با درگاه پرداخت

بعضی درگاه‌های پرداخت، کاربر را به دامنه‌ی خود منتقل می‌کنند و سپس به سایت شما برمی‌گردانند. اگر کوکی‌های سشن با پرچم SameSite=Strict تنظیم شده باشند، کاربر بعد از بازگشت از درگاه، سبد خرید خود را از دست می‌دهد. راه‌حل: تنظیم SameSite=Lax برای کوکی‌های ووکامرس. مباحث مرتبط در رفع خطای درگاه پرداخت ووکامرس باز شده است.

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

بعد از پیدا کردن ریشه، نوبت به بازگردانی کوکی‌ها می‌رسد. ترتیب اولویت‌بندی من در پروژه‌های واقعی:

1. پاک‌سازی کوکی‌های قدیمی: از مرورگر، تمام کوکی‌های سایت را پاک کنید و دوباره تست کنید.
2. اصلاح تنظیمات SameSite: اگر ریشه در SameSite است، با تنظیمات wp-config.php یا افزونه، مقدار Lax را اعمال کنید.
3. غیرفعال‌سازی افزونه‌ی مقصر: اگر ریشه در افزونه است، موقتاً غیرفعال کنید و تست بگیرید.
4. اصلاح تنظیمات CDN: اگر ریشه در CDN است، حالت SSL یا Page Rules را اصلاح کنید.
5. مستندسازی: ریشه، روش تشخیص و راه‌حل را ثبت کنید.

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

پایش مستمر و پیشگیری

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

سطح اول: پایش ورود به پیشخوان

هر روز، یک‌بار با مرورگر خام (بدون افزونه) وارد پیشخوان وردپرس شوید. اگر ورود موفق نبود، ریشه را قبل از بحران پیدا کنید.

سطح دوم: پایش کوکی‌های وردپرس

هر هفته، در DevTools کوکی‌های وردپرس را بررسی کنید. اگر کوکی‌های ضروری نیستند یا پرچم‌هایشان تغییر کرده، بلافاصله بررسی کنید.

سطح سوم: پایش سشن ووکامرس

ماهی یک‌بار، جدول wp_woocommerce_sessions را بررسی کنید. اگر رکوردهای منقضی‌شده زیاد است، پاک‌سازی کنید.

سطح چهارم: تست بعد از هر تغییر

بعد از هر تغییر در SSL، CDN، افزونه‌ی امنیتی یا کش، سریع تست کنید که کوکی‌ها به‌درستی کار می‌کنند یا نه. این عادت ساده، از بحران‌های جدی جلوگیری می‌کند.

سطح پنجم: بکاپ منظم قبل از تغییرات

قبل از هر تغییر در تنظیمات کوکی، SSL یا CDN، بکاپ کامل بگیرید. مباحث مرتبط با این حوزه در بهترین افزونه‌های بکاپ وردپرس باز شده است.

پرسش‌های پرتکرار درباره خطای کوکی وردپرس

چرا بعد از ورود، صفحه‌ی ورود دوباره نمایش داده می‌شود؟

این الگو معمولاً به یکی از سه دلیل برمی‌گردد: کوکی احراز هویت به‌درستی ذخیره نمی‌شود، پرچم SameSite روی Strict تنظیم شده و کاربر از دامنه‌ی متفاوتی وارد شده، یا افزونه‌ی کش صفحه‌ی پیشخوان را کش کرده است. بررسی کوکی‌ها در DevTools، سریع‌ترین راه تشخیص است.

آیا افزونه‌های امنیتی می‌توانند خطای کوکی ایجاد کنند؟

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

چرا بعد از انتقال به HTTPS، کاربران لاگ‌اوت می‌شوند؟

اگر کوکی‌های قدیمی روی HTTP تنظیم شده باشند و سایت شما به HTTPS منتقل شده باشد، این کوکی‌ها نامعتبر می‌شوند و کاربر باید دوباره وارد شود. راه‌حل: اطلاع‌رسانی به کاربران برای پاک کردن کوکی‌ها یا انتظار برای انقضای طبیعی. مباحث مرتبط در ریدایرکت HTTP به HTTPS باز شده است.

آیا خطای کوکی می‌تواند ناشی از هک شدن سایت باشد؟

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

چرا سبد خرید ووکامرس در هر رفرش خالی می‌شود؟

سه دلیل رایج: کوکی سشن ووکامرس ذخیره نمی‌شود، جدول wp_woocommerce_sessions پر از رکوردهای منقضی‌شده است، یا افزونه‌ی کش صفحات پویا را کش می‌کند. بررسی کوکی‌های wp_woocommerce_session_* در DevTools، اولین گام است. مباحث مرتبط در سفارشی‌سازی سبد خرید و تسویه‌حساب ووکامرس باز شده است.

چطور SameSite را برای کوکی‌های وردپرس تنظیم کنم؟

ساده‌ترین روش، اضافه کردن تنظیمات به wp-config.php است. اما بعضی افزونه‌های امنیتی این تنظیم را بازنویسی می‌کنند. راه‌حل: بررسی تنظیمات افزونه‌ها و اطمینان از عدم تضاد. مباحث مرتبط در امن‌سازی فایل wp-config باز شده است.

آیا کوکی‌های third-party می‌توانند باعث خطا شوند؟

بله. مرورگرهای مدرن کوکی‌های third-party را به‌طور پیش‌فرض مسدود می‌کنند. اگر سایت شما به کوکی‌های third-party وابسته است (مثلاً برای ورود با گوگل)، کاربران ممکن است با مشکل مواجه شوند. راه‌حل: انتقال به سیستم‌های احراز هویت مبتنی بر OAuth که به کوکی third-party نیاز ندارند.

چرا بعضی کاربران مشکل کوکی دارند و بعضی نه؟

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

آیا WP-CLI می‌تواند در عیب‌یابی کوکی کمک کند؟

بله، WP-CLI دستوراتی برای بررسی و پاک‌سازی سشن‌ها دارد. مثلاً wp cache flush برای پاک‌سازی کش و wp transient delete --all برای پاک‌سازی ترنزینت‌ها. برای مدیریت سشن‌های ووکامرس، wp wc tool run clear_sessions می‌تواند مفید باشد.

چطور بفهمم ریشه در CDN است یا سرور اصلی؟

سریع‌ترین تست، دور زدن CDN است. با دستور curl -I --resolve yourdomain.com:443:server_ip https://yourdomain.com می‌توانید سایت را مستقیم از سرور اصلی تست کنید. اگر کوکی‌ها مستقیم کار کردند ولی از دامنه نه، ریشه در لایه‌ی CDN است.

نکته‌های میدانی از رفع خطای کوکی

در پایان این مقاله، چند نکته‌ای را می‌گویم که در مستندات رسمی کم‌تر به آن‌ها اشاره می‌شود ولی در پروژه‌های واقعی بارها به کارم آمده:

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

دوم: در سایت‌هایی که پشت CDN یا پراکسی معکوس هستند، همیشه تنظیمات SSL را در یک لایه مدیریت کنید، نه در چند لایه. تجربه‌ی من نشان داده که تنظیم متناقض در چند لایه، شایع‌ترین ریشه‌ی خطاهای کوکی پیچیده است. اگر از Cloudflare استفاده می‌کنید، حالت SSL را روی Full Strict بگذارید و تنظیمات HTTPS را در سرور اصلی مدیریت کنید.

سوم: قبل از هر تغییر در SSL، SameSite یا تنظیمات CDN، حتماً بکاپ کامل بگیرید و در محیط استیجینگ تست کنید. تغییرات در تنظیمات کوکی، اگر اشتباه باشند، می‌توانند کل کاربران را از سایت بیرون بیندازند. عادت بکاپ و تست در استیجینگ، تفاوت میان چند دقیقه و چند ساعت است.

در تجربه‌ی چندساله‌ام روی سایت‌های وردپرسی، الگویی که بارها تکرار شده این است که خطای کوکی تقریباً همیشه در یکی از پنج لایه ریشه دارد: SameSite و Secure، دامنه و مسیر، SSL و HTTPS، CDN و پراکسی، افزونه‌های امنیتی و کش. تشخیص سریع این لایه، از هر راه‌حل آماده مؤثرتر است. اگر ابزارهای تشخیصی را در اختیار داشته باشید و لایه‌ها را به ترتیب بررسی کنید، این خطا از یک بحران ترسناک به یک تمرین روتین تبدیل می‌شود.

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