اوبرکارت در مقابل دروپال کامرس

اوبرکارت۳ و دروپال کامرس: پیچیده‌تر شدن انتخاب کارت خرید برای دروپال۷

آن دسته از توسعه دهندگان وب که به دنبال سیستم خرید الکترونیکی وابسته به دروپال بودند حالا دو انتخاب مجزا داردند: سیستم موفق دیرینه، اوبرکارت [1] (که حالا به دروپال ۷ منتقل) و دروپال کامرس[2]، سیستمی که از پایه توسط چند نفر از توسعه‌دهندگان سابق تیم اوبرکارت نوشته شده است. حالا با دو انتخاب موجود، کدام پروژه راه خودش رو به بازار پیدا میکنه و موفقیت بیشتری به دست میاره؟ وقتی که ابتدا روی سیستم تجارت الکترونیک کار میکردم، انتخاب‌های سیستم وابسته به دروپال محدود به دو گزینه بود: اوبرکارت و ای-کامرس[3] با توجه به فعالیت‌های توسعه‌دهندگان و تعداد زیاد ماژول‌های موجود، من به شخصه یک پشتیبان مشتاق اوبرکارت شدم. در واقع به طور کلی این اولین انتخاب من برای یک سیستم تجارت الکترونیک بود چون قابلیت‌های زیادی پیش رو می‌گذاشت: یک راه حل برای سیستم تجارت الکترونیک که از همان معماری بر پایه‌ی گره‌های[4] دروپال استفاده میکرد، دارای سیستم تم، روتین‌های مدیریت کاربران به طوری که به هر کدام یک کارت با یک نوار دارای قابلیت‌های پیچیده شخصی‌سازی تعلق میگرفت. اما اگر هردو سیستم سی‌ام‌اس[5] و تجارت الکترونیک رو باهم میخواستید مجبور بودید راه حل بهتری از دروپال۶ و اوبرکارت پیدا کنید.

طی چند سالی که من با اوبرکارت کار میکردم شاهد این موضوع بودم: در حالی که برای پاسخگویی به اکثر درخواست‌های سیستم تجارت الکترونیک مناسب هست، این پروژه بدون عیب های خودش نیست. مستندات کافی ندارد، جواب از طرف کاربران پشتیبان بعضی وقت‌ها کند هست و گاهی اوقات تعداد خیلی زیادی از قابلیت‌های پیشرفته به طرز ناراحت کننده‌ای در نظر گرفته نشده. در حالی که راه حلی برای هیچ کدام از این مشکلات توسط وب‌سایت پروژه ارائه نشده، گشتن در خود وب‌سایت هم میتونه مشکل‌ساز باشه مخصوصا اگر دنبال یک جواب فوری برای مشکل خاص میگردید. اما اوبرکارت هنوز برای دروپال۶ بهترینه. و همچنان هم پیشرفت میکنه. اوبرکارت۳ انتقال[0] پروژه به دروپال۷ هست و همچنین یک عده از توسعه دهندگان در حال کار کردن روی آن هستند. ولی اخیرا انتخاب‌های کارت خرید[6] برای سیستم وابسته به دروپال۷ با معرفی دروپال کامرس بیشتر و بزرگتر شده. کامرس که به بخش کارت خرید دروپال اضافه شده توسط همان توسعه دهندگانی نوشته شده است که قبلا مدیریت و توسعه اوبرکارت رو به عهده داشتند (برنامه‌نویس ارشد پروژه، مدیر ارشد قبلی اوبرکارت بود[17]). بر خلاف اوبرکارت، کامرس یک ماژولی هست که فقط روی دروپال۷ کار میکند. با وجود اینکه از سال ۲۰۰۹ در حال توسعه هست، برای استفاده آماده نبود و فقط از چند ماه قبل بسته‌های قابل دانلودش آمار دانلود بالایی رو نشون میدهند حالا با توجه به توسعه کامرس و اضافه شدن ماژول‌های جدید که اون رو تبدیل به یک انتخاب جدی کرده، از این دو بسته کدام یک انتخاب بهتریست؟

قبل از همه چیز این رو در نظر داشته باشید که پکیج‌های خرید کمی هستند که بتونن همه افراد رو راضی نگه داردند و تهییه این پکیج‌ها تکنیک‌ها و پیچیدیگی‌های خاص خودش رو دارد چون باید انتظارهای زیادی رو برآورده کنند مثل مدیریت خریداران و محاسبه هزینه حمل و نقل و مدیریت انبار. در حالی که این پکیج‌ها توسط کاربران غیر فنی مدیریت میشوند که متقاضی یک سیستم ساده در عین حال دارای تمام قابلیت‌های سفارشی شدن هستند. یک بسته میتونه رابط کاربری فوق‌العاده‌ای داشته باشه در حالی که اصلا قابلیت محاسبه هزینه حمل و نقل خوبی برای اون در نظر گرفته نشده باشه یا دارای قابلیت مدیریت و پردازش هزاران [7]SKU رو داشته باشه اما کار با اون برای یک کاربر غیر حرفه‌ای و بی‌تجربه فوق‌العاده سخت باشه. در واقع سیستم‌ها باید ضدگلوله باشند! چون توی هر صفحه مقداری پول در حال مبادله شدن هست بنابراین هر اشتباهی میتونه هزینه‌بر باشه. این بازه‌ی گسترده‌ی نیازها باعث میشه سیستم‌های مبتنی بر دروپال یک سرو گردن از رقیبانشون بالاتر باشند چون انعطاف‌پذیری دروپال زبان‌زد همه است: معماری مبتنی بر ماژول آنقدر به اون انعطاف میدهد که تقریبا برای هر وضعیتی راه حلی داشته باشد.

تفاوت‌های دروپال کامرس و اوبرکارت در هسته:

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

محصولات و موجودیت‌ها:

کاربرانی که از اوبرکارت استفاده کردند میدونند که از ساختمان داده دروپال۶ پیروی میکند. در واقع محصولات همان گره‌ها هستند. این یعنی وارد کردن یک محصول به اوبرکارت مثل وارد کردن یک story است با این تفاوت که فیلدهای بیشتری وجود دارد، مثل وزن و قیمت. از طرفی تنوع کالا (رنگ، سایز، ...) به عنوان خصایص[8] کالای اصلی در نظر گرفته میشوند. بنابراین اگر کالایی سبز یا قرمز باشد، بزرگ یا کوچک، هر خصیصه‌ای که اضافه بشود هر کالا باز یک گره محسوب میشود. برای کاربر نهایی درک این نوع معماری سادست: یک کالا یکبار وارد میشود و هر خصوصیت[8] اضافی مربوط به کالای اصلیست. هروقت که کالایی رو منتشر کنید روی وبسایت نمایش داده میشود. اما کامرس از سیستم موجودیت‌های[9] دروپال۷ استفاده میکند و با هر گزینه‌ی اضافه شده‌ای به هر کالا به عنوان یک کالای جدید جداگانه برخورد میکند. بنابراین اگر یک تاجر تی‌شرتی رو در رنگ‌های آبی و قرمز بفروشد (که هم طرفدارای تیم قرمز ازون راضی باشن هم تیم آبی، این یعنی تجارت موفق) این دو به عنوان دو کالای مجزا محسوب میشوند اگر چه ممکن است از نظر دیگر مشابه باشند. این شیوه خیلی به شیوه‌ای که خرده‌فروشانی که از سیستم سنتی یک SKU خاص برای هر کالا استفاده میکنند شبیه هست. این شیوه برای طراح پایگاه داده نیز آسان‌تر است. در واقع این تغییر ممکن است راه حلی برای یکی از بزرگترین ضعف‌عای اوبرکارت باشد. در سیستمی که انواع مختلف یک کالا به عنوان یک خصیصه به کالا اضافه میشود بدون توجه به تعداد خصایص مختلف همگی یک کالا محسوب میشوند، یعنی فقط یک گره در سیستم.

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

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

خرده‌فروشی رو در نظر بگیرید که تی‌شرت میفروشد که سایزهای اسمال مدیم و لارج دارند و در دو رنگ آبی و قرمز موجود هستند. برای اعمال چنین سیستمی در دروپال کامرس یک کاربر این مراحل رو طی میکند: ابتدا مدیر سیستم نوع کالای تی‌شرت رو ایجاد میکند. فیلدهای مربوط به انواع مختلف کالا در این مرحله اضافه میشوند. سپس SKUهای مختلف برای هرگونه ترکیب ممکن سایز و رنگ وارد میشود سپس نمایش[10] کالا ایجاد میشود که حاوی متن عنوان و شرح کالاست. SKUهای تعریف شده در یک فیلد دارای قابلیت پر کردن خودکار فرم [11] اضافه میشن. درست همانطوری که taxonomy terms رو در گره‌های دروپال اضافه میکنید. درک این فرایند برای کاربران غیرفنی آسان نیست. حداقل نه برای دفعه اول! فرایندی رو در نظر بگیرید که فروشنده در نظر داشته باشد رنگ جدیدی رو به کالای موجود (تی‌شرت) اضافه کند. برای این کار یک فیلد به فیلدهای خصیصه‌های رنگ تی‌شرت اضافه میکند. سپس برای هر سایز موجود از لباس یک SKU تعریف میکند (که میشود گفت حجم کار بیشتر از مقداریست که فروشنده انتظار دارد) اما این رو در نظر بگیرین: اگر فروشنده به خود سایت مراجعه کند و انتظار داشته باشد گزینه اضافه شده رو ببیند کاملا ناامید میشود چون قبل از اینکه گزینه مربوط به کالا بتونه نمایش داده بشه باید به صورت دستی به گره نمایش کالا اضافه بشود. بنابراین قبل از اینکه کالا نمایش پیدا کند کاربر باید به صفحه گره نمایش برگردد و از طریق فیلد مربوطه SKU جدید رو در قسمت ویرایش اضافه کند. آخ.....این خیلی طولانی و پیچیده شد!

اگر منصفانه قضاوت کنیم در اوبرکارت هم این کار چندان آسان نیست. با در نظر گرفتن اوبرکارت۳، ابتدا باید خصیصه‌های عمومی[12] ایجاد بشود سپس اضافه کردن اونها به محصول انجام می‌شود. مراحل اضافی نیز لازم است: اگر تاجری باشید که فراموش کنید شماره SKU جدید یا تعداد کالای موجود در انبار رو وارد کنید، احتمالا باعث میشوید کالاهایی به فروش برسد که عملا وجود ندارند!

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

هردوی این پکیج‌ها پروژه‌های بزرگ و پیچیده‌ای هستند که نیازمند یک راهنمای جامع برای کاربر نهایی[13] هستند. به همین دلیل هردو پکیج وب‌سایت خودشون رو برای انجمن‌های کاربری[14]، پشتیبانی و راهنما و مستندات[15] دارند. این یک چیز خاص نیست، پروژه‌های زیادی وب‌سایت مربوط به خودشون رو برای این موارد دارند، اما پکیج‌های خرید یک موضوع خاص هستند. موضوع تبادل آنلاین پول هست! بنابراین خیلی مهم است هر سوالی که پیش میاید، هم توسعه‌دهندگان هم کاربر نهایی، باید به آخرین مستندات و راهنما‌ها، ماژول‌ها و پچ‌ها دسترسی داشته باشند. به همین دلیل است که این دو سایت نیاز به کار بیشتری دارند. متاسفانه به نظر میاید که توسعه‌دهندگان کامرس از بعضی تکنیک‌های مشابه تکنیک‌های قدیمی استفاده میکنند. نقش انجمن‌ها در پشتیبانی فنی خیلی بزرگ است (برای مثال اگر شما کامرس رو از طریق روش نصب پیشنهادی kickstart نصب کنید، میتوانید در صفحه اصلی یک محصول رو به کارت خودتون اضافه کنید اما نمیتونید تعداد محصول درخواستی رو تا لحظه پرداخت تعیین کنید، چرا؟ چون به طور پیش‌فرض فیلد تعداد نمایش داده نمی‌شود. این مشکل رو به سادگی میتوان حل کرد. اما جست‌وجو در سایت کامرس برای پیدا کردن توضیحات مرحله به مرحله این کار واقعا یک کار عذاب‌آوره. آیا واقعا لازم است توی همه‌ی کامنت‌ها و نظرات کاربران گشت تا تنظیمات پایه رو فهمید؟ با این وجود، کامرس یک‌سری از کارها رو خیلی خوب انجام داده: رندی فی [16]، عضو تیم توسعه کامرس، یک کتابخانه از آموزش‌های تصویری درست کرده که برای یک کاربرعادی همه چیز رو به صورت واضح توضیح میده و واقعا مرجع خوبیست. اگرچه بهتر بود یک موتور جست‌وجوی مناسب به پروژه اضافه میکردن، هر پروژه نیاز به یک موتور جست‌وجوی خوب مثل Solr یا Lucene دارد. همچنین بهتر بود نحوه نمایش راهنماها و مستندات رو تغییر میدادند، چون هنگام تنظیمات آخرین چیزی که کاربر نیاز دارد بحث و گفت‌وگوی کاربران دیگرست. به طور کلی مطلب مورد نیاز در راهنمای کاربر باید ساده و خلاصه باشد و مطلب رو سریع انتقال بدهد، مثل کارت آموزش‌های اظطراری در هواپیما. در زمان نوشتن این مقاله مدیر ارشد پروژه کامرس اعلام کرده تغییراتی برای صفحه وب‌سایت کامرس در دست انجامست. همچنین اعلام کرده شاید سیستمی مثل سیستم فوق‌العاده موفق Stack Exchange راه‌اندازی کند.

و برنده‌ی این مسابقه...

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

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

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

منبع: markroyko.com

[0] این کلمه به عنوان معادل کلمه‌ی Port در نظر گرفته شده!

[1]Ubercart

[2]Drupal Commerce

[3]e-Commerce

[4]Node

[5]CMS

[6]Shopping Cart

[7]Stock Keeping Unit : واحد نگه‌داری کالا

[8]Attribute

[9]Entity

[10]Display

[11]Form Auto-Completion

[12]General Attribute

[13]End-User

[14]Forum

[15]Documentation

[16]Randy Fay

[17]Ryan Szrama