وبلاگ نت‌آرامآموزش، تجربه و راهکارهای زیرساخت

دکمه ثبت سفارش ووکامرس فقط می‌چرخد؛ چطور علت را پیدا و برطرف کنیم؟

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

انتشار:
توسط تیم فنی نت‌آرام
۱۰ دقیقه زمان مطالعه
۰ دیدگاه
محتوای تخصصی، ساده و کاربردی
هماهنگ با هویت حرفه‌ای نت‌آرام
بازگشت به لیست مقالات
تصویر شاخص مقاله دکمه ثبت سفارش ووکامرس فقط می‌چرخد؛ چطور علت را پیدا و برطرف کنیم؟ در وبلاگ نت‌آرام
محتوای آموزشی وبلاگ نت‌آرام
مشتری روی «ثبت سفارش» می‌زند، علامت بارگذاری می‌چرخد و صفحه جلو نمی‌رود. ممکن است سفارش ساخته شده باشد ولی پاسخ به مرورگر نرسیده باشد؛ ممکن هم هست درخواست پیش از ساخته‌شدن سفارش شکست خورده باشد. بنابراین اولین کار، فشار دادن دوباره دکمه یا درخواست پرداخت مجدد از مشتری نیست.
در این راهنما وضعیت سفارش و پرداخت را از هم جدا می‌کنیم، سپس با ابزار مرورگر می‌بینیم کدام درخواست مانده یا خطا داده است. برای تشخیص هر نوع خطا مسیر مناسب را توضیح می‌دهیم و در پایان یک سفارش آزمایشی را از ابتدا تا تأیید نهایی بررسی می‌کنیم.

قبل از هر آزمایش: جلوی پرداخت و سفارش تکراری را بگیرید

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

مرحله اول: بدانید چرخش چه زمانی شروع می‌شود

صفحه تسویه‌حساب را در پنجره خصوصی با یک محصول آزمایشی باز کنید. فقط در محیط مناسب این موارد را ثبت کنید:
۱. آیا صفحه به‌محض بازشدن می‌چرخد یا بعد از تغییر آدرس و روش ارسال؟ ۲. آیا همه فیلدهای لازم پر شده‌اند و پیام خطای مشخصی کنار فیلد وجود دارد؟ ۳. آیا چرخش پس از زدن «ثبت سفارش» شروع می‌شود یا بعد از بازگشت از درگاه؟ ۴. آیا مشکل در چند مرورگر و برای یک روش پرداخت خاص رخ می‌دهد یا در همه حالت‌ها؟
اگر خطای واضحی مثل کد پستی نامعتبر دیده می‌شود، ابتدا همان فیلد را اصلاح کنید. اگر فقط یک درگاه مشکل دارد و روش آزمایشی دیگر کار می‌کند، افزونه یا ارتباط همان درگاه سرنخ مهمی است. اگر جمع سفارش پیش از انتخاب پرداخت هم بارگذاری نمی‌شود، ممکن است مشکل در محاسبه سبد، ارسال یا درخواست‌های صفحه باشد.

مرحله دوم: درخواست ناموفق را در مرورگر پیدا کنید

در Chrome یا Edge روی رایانه، صفحه تسویه‌حساب آزمایشی را باز کنید و کلید F12 را بزنید. تب Network را انتخاب کنید. گزینه Preserve log را روشن کنید تا پس از تغییر صفحه گزارش پاک نشود. در صورت وجود، فیلتر Fetch/XHR را انتخاب کنید و فهرست قبلی را با دکمه پاک‌کردن همان پنل خالی کنید.
حالا فقط یک بار همان کاری را که باعث چرخش می‌شد تکرار کنید. اگر قرار است دکمه ثبت سفارش را بزنید، پیش از تکرار دوباره بررسی کنید تلاش قبلی سفارش یا پرداخت واقعی نساخته باشد. در فهرست Network دنبال درخواستی بگردید که هنگام شروع چرخش ظاهر شده، مدت زیادی در حالت Pending مانده یا کد خطا گرفته است.
در تسویه‌حساب کلاسیک، نام درخواست ممکن است شامل wc-ajax=update_order_review برای به‌روزرسانی جمع یا wc-ajax=checkout برای ثبت سفارش باشد. در تسویه‌حساب بلوکی، ممکن است درخواست‌هایی زیر /wp-json/wc/store/ ببینید. نسخه‌ها و افزونه‌ها مسیرهای دیگری هم دارند؛ نام‌ها را فقط سرنخ بدانید.
روی درخواست مشکوک بزنید و Status، زمان، نشانی بدون اطلاعات حساس و پیام خطای قابل نمایش را یادداشت کنید. سربرگ‌ها و بدنه درخواست ممکن است نشانی مشتری، کوکی، توکن سبد یا اطلاعات پرداخت داشته باشند؛ تصویر کامل Network و فایل HAR را بدون پاک‌سازی داده‌های محرمانه برای دیگران نفرستید.

نتیجه درخواست را چطور تفسیر کنیم؟

| نتیجه | قدم بعدی | | --- | --- | | Pending طولانی یا timeout | زمان درخواست را با لاگ سرور، کار پایگاه داده و ارتباط درگاه تطبیق دهید. فقط از روی انتظار طولانی نمی‌توان یک علت قطعی گفت. | | 403 | متن پاسخ و قانون امنیتی همان زمان را بررسی کنید؛ توکن نشست، دسترسی یا فایروال می‌تواند نقش داشته باشد. | | 404 | نشانی درخواست، مسیر وردپرس، پیوندهای یکتا و قوانین پراکسی را بررسی کنید. | | 500 یا 502 یا 504 | گزارش PHP و وب‌سرور و وضعیت سرویس را در همان بازه ببینید؛ هر کد علت دقیق متفاوتی می‌تواند داشته باشد. | | پاسخ HTML یا صفحه ورود به‌جای پاسخ مورد انتظار | ممکن است تغییر مسیر، کش، حالت تعمیر، افزونه امنیتی یا خطای PHP پاسخ را عوض کرده باشد. | | خطای Mixed Content یا CORS | نام دامنه، پروتکل و مسیر واقعی درخواست را با تنظیم پراکسی و سایت تطبیق دهید. |
این جدول نقطه شروع است؛ یک عدد به‌تنهایی مجوز خاموش‌کردن فایروال یا تغییر همه تنظیمات نیست. اگر هیچ درخواست مرتبطی دیده نمی‌شود، تب Console را هم ببینید؛ خطای JavaScript ممکن است مانع شروع درخواست شده باشد. نام فایل و پیام خطا را بدون اطلاعات خصوصی ثبت کنید.

اگر پاسخ 403 است: نشست، کش و قانون امنیتی را جدا کنید

یک پنجره خصوصی تازه باز کنید، یک سبد آزمایشی جدید بسازید و بدون نگه‌داشتن صفحه برای مدت طولانی دوباره امتحان کنید. در تسویه‌حساب بلوکی، درخواست‌های Store API به توکن معتبر نیاز دارند؛ صفحه یا پاسخ شخصی که به اشتباه از کش عمومی سرو شود می‌تواند باعث ناسازگاری نشست شود. از خاموش‌کردن بررسی توکن امنیتی در سایت واقعی خودداری کنید.
تنظیمات کش افزونه، هاست و CDN را بررسی کنید. صفحات سبد، تسویه‌حساب و حساب کاربر و پاسخ‌های شخصی باید مطابق راهنمای ووکامرس از کش عمومی مشترک کنار گذاشته شوند. نام گزینه‌ها در هر سرویس فرق دارد. ابتدا در محیط آزمایشی یک لایه را اصلاح و با دو مرورگر مستقل بررسی کنید که سبد یک کاربر برای دیگری نمایش داده نشود.
اگر پاسخ شامل نام قانون فایروال یا شناسه رویداد است، آن را با زمان و URL درخواست به مدیر امنیت یا پشتیبانی هاست بدهید. بخواهید همان قانون و همان درخواست بررسی شود. خاموش‌کردن کامل WAF یا بازکردن همه قوانین برای اینترنت، برای رفع یک 403 لازم نیست. بعد از اصلاح محدود، درخواست آزمایشی را دوباره بسنجید.

اگر پاسخ 404 یا تغییر مسیر غیرمنتظره است

نشانی صفحه تسویه‌حساب و نشانی درخواست ناموفق را مقایسه کنید: آیا به دامنه قدیمی، HTTP به‌جای HTTPS یا مسیر اشتباه می‌رود؟ در وردپرس بخش تنظیمات ← پیوندهای یکتا را باز کنید و ساختار فعلی را یادداشت کنید. اگر مدیر سایت تشخیص داده قواعد پیوند نیاز به بازسازی دارد، ذخیره همان ساختار موجود می‌تواند قواعد وردپرس را تازه کند؛ پیش از آن از تنظیمات و فایل مرتبط پشتیبان داشته باشید و در نصب چندسایتی یا پراکسی، رفتار محیط را در نظر بگیرید.
اگر نصب وردپرس در زیرپوشه است یا آدرس سایت و آدرس فایل‌های وردپرس عمداً متفاوت‌اند، آن‌ها را صرفاً برای یکسان‌شدن عوض نکنید. تغییر نادرست نشانی می‌تواند پیشخوان را از دسترس خارج کند. مسیر درخواست، تنظیم پراکسی و قوانین وب‌سرور باید با ساختار واقعی تطبیق داده شوند.
اگر پاسخ به صفحه ورود، خطای HTML یا حالت تعمیر می‌رود، نام لایه‌ای را که پاسخ می‌دهد از سربرگ و لاگ‌های مرتبط پیدا کنید. یک تغییر هم‌زمان در چند لایه باعث می‌شود فهمیدن علت دشوار شود؛ هر بار فقط اصلاح شناخته‌شده را اعمال و همان آزمایش را تکرار کنید.

اگر خطای سرور یا انتظار طولانی دیده می‌شود

در ووکامرس به وضعیت ← گزارش‌ها بروید و گزارش مرتبط با زمان آزمایش را ببینید. همچنین مدیر سرور می‌تواند لاگ PHP و وب‌سرور را در همان دقیقه بررسی کند. اگر افزونه درگاه گزارش جدا دارد، فقط در صورت نیاز و با توجه به اطلاعات حساس آن را فعال کنید؛ پس از تشخیص، ثبت جزئیات اضافی را خاموش کنید.
اگر گزارش نام یک افزونه یا تابع مشخص را به‌عنوان خطای PHP نشان می‌دهد، نسخه افزونه، وردپرس و PHP و آخرین تغییر را یادداشت کنید. در محیط آزمایشی، سازگاری و به‌روزرسانی امن همان افزونه را بررسی کنید. اگر درخواست منتظر درگاه یا API بیرونی است، زمان پاسخ و نتیجه ارتباط را از همان سرویس پیگیری کنید. افزایش کورکورانه زمان انتظار ممکن است فقط باعث شود مشتری مدت بیشتری منتظر بماند.
اگر سرور در همان لحظه به محدودیت پردازش یا حافظه می‌رسد، مصرف واقعی و گزارش محدودیت را با میزبان بررسی کنید. ابتدا عامل بار را پیدا کنید؛ افزودن منابع بدون شناخت درخواست معیوب یا حلقه افزونه همیشه مشکل را حل نمی‌کند. راهنمای خطای 504 وردپرس مسیر بررسی درخواست طولانی را توضیح می‌دهد.

اگر افزونه یا قالب مظنون است

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

آزمایش پایانی را کامل انجام دهید

در حالت آزمایشی، یک محصول را به سبد اضافه کنید، آدرس، ارسال و پرداخت آزمایشی را انتخاب و یک بار سفارش را ثبت کنید. بررسی کنید دقیقاً یک سفارش با مبلغ و وضعیت مورد انتظار ساخته شود و صفحه تأیید نمایش داده شود. در پنل درگاه آزمایشی نیز نتیجه را با سفارش تطبیق دهید. سپس با مرورگر دوم و در صورت امکان موبایل یک سناریوی مستقل انجام دهید و مطمئن شوید اطلاعات سبد کاربران جابه‌جا نمی‌شود.
اگر مشکل حل نشده، زمان، نوع تسویه‌حساب، شناسه سفارش آزمایشی، نام درخواست و کد پاسخ و نتیجه لاگ پاک‌سازی‌شده را برای پشتیبانی مربوط بفرستید. امکانات هاست پربازدید ووکامرس نت‌آرام برای بررسی نیاز منابع فروشگاه در دسترس است؛ پاسخ 403 یا اشکال پیکربندی با ارتقای منابع به‌تنهایی رفع نمی‌شود.

منابع فنی

اشتراک‌گذاری:
لینکدینتلگرامایکس

دیدگاه‌ها (۰)

دیدگاه‌های تاییدشده و پاسخ‌های تیم نت‌آرام