Faragiri

همهٔ زبان‌ها

آموزش ووکامرس و ساخت فروشگاه وردپرس

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

۴بخش
۳دقیقه خواندن
۵عمق

از محصول تا سفارش

مرحله‌هایی که یک خرید از آن‌ها رد می‌شود

هر باند یک مرحله است و هر مرحله قلاب‌های خودش را دارد؛ بررسی‌ای که در مرحله بالاتر انجام شود، در مرحله پایین‌تر باز هم لازم است.

  1. دیدن محصولیک نوشته است، پس همه کوئری‌های نوشته رویش کار می‌کنند
  2. افزودن به سبدقلاب اعتبارسنجی همین مرحله، که جلوی افزودن را می‌گیرد
  3. شروع تسویهجایی که هزینه ارسال و مالیات حساب می‌شوند
  4. ثبت سفارشآخرین جایی که هر بررسی باید دوباره انجام شود
  5. تایید پرداختباید از سمت سرور تایید شود و نه از پارامترهای بازگشتی

عرض هر باند مرحله را نشان می‌دهد و نه نرخ تبدیل. آن عدد به فروشگاه شما بستگی دارد و در هیچ‌کدام از این باندها نوشته نشده.

در ووکامرس هر محصول یک نوشته است، با همان جدول و همان فراداده. همین یک تصمیم، هر دو نیمه ماجرا را توضیح می‌دهد: هر چیزی که برای نوشته‌ها کار می‌کند برای محصول هم کار می‌کند، و هر محدودیت نوشته‌ها هم اینجا هست.

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

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

فراداده، و جایی که کند می‌شود

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

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

قلاب‌های تسویه، و ترتیبشان

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

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

جایی که کار گیر می‌کند، درگاه پرداخت و پست ایران است

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

ابزار، و سالی که این حرف درست است

در سال ۲۰۲۶، ووکامرس چیدمان جدول‌های اختصاصی سفارش را به‌عنوان پیش‌فرض دارد و جای ذخیره سفارش در جدول نوشته‌ها را گرفته؛ متن‌باز و رایگان است. برای دیدن کوئری‌های هر صفحه فروشگاه، Query Monitor همان کار را می‌کند و رایگان است. و WP-CLI دستورهای مخصوص ووکامرس دارد که برای وارد کردن دسته‌ای محصول و برای اجرای مهاجرت‌ها از پنل سریع‌تر و قابل تکرارترند.

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

کنار این

بالای این