Drupal Commerce - متى يتفوق على Shopify

Drupal Commerce هو الإجابة الخاطئة لمعظم المتاجر الإلكترونية. ليس هذا انتقادًا للمشروع، فهو مبني بإتقان منذ خمسة عشر عامًا. إنه وصف لما عليه معظم المتاجر: بضع مئات من أرقام الأصناف، وعملة واحدة، وعملاء أفراد، ودفعة ببطاقة في النهاية. لنشاط بهذا الشكل تتفوق المنصة المستضافة على كل محور يهم، وينتهي النقاش قبل أن يبدأ.

وهناك أقلية تنقلب لديها الحسبة تمامًا، وهي أقلية مربحة. منتجات قابلة للتهيئة لا يمكن التعبير عنها بشبكة متغيرات. حسابات تجارية بقوائم أسعار متفاوض عليها. كتالوج هو نفسه المحتوى التحريري. نظام ERP يملك المخزون والأسعار ويعامل الموقع كسطح عرض. في هذه الشركات لا تكون المنصة المستضافة أرخص، بل ضريبة دائمة تُدفع في صورة تطبيقات وحلول التفافية وأشياء لا يُسمح لك بتغييرها.

يوضح هذا المقال أين يقع ذلك الخط فعليًا، بالأرقام من الجانبين. إن قرأت قسم Shopify فوجدت فيه وصف نشاطك، فتوقف عند ذلك الحد. ستوفر مالًا كثيرًا ويكون المقال قد أدى مهمته.

متى يتفوق Drupal Commerce على Shopify؟ حين يتعذر تمثيل منتجاتك بشبكة متغيرات بسيطة، وحين يرى عملاء مختلفون أسعارًا مختلفة لرقم الصنف نفسه، وحين يكون الكتالوج والمحتوى التحريري شيئًا واحدًا، أو حين يكون نظام ERP مصدر الحقيقة والمتجر مجرد إطلالة عليه. أما الكتالوج الاستهلاكي المباشر بعملة أو عملتين فإن Shopify أرخص له على مدى ثلاث سنوات وأفضل في التحويل. خط الفصل هو تعقيد المنتج والتسعير، لا حجم الزيارات ولا حجم المبيعات.

ما هو Drupal Commerce حقًا

Drupal Commerce ليس منتج متاجر جاهزًا. إنه مجموعة من أنواع الكيانات موضوعة فوق نظام الكيانات والحقول في Drupal، وكل ما يلي في هذا المقال ينبع من هذه الجملة.

المنتج في Drupal Commerce كيان له حزمة، تمامًا مثل العقدة. وكذلك متغير المنتج والطلب وبند الطلب والدفعة والعرض الترويجي والمتجر. كل واحد منها يقبل حقولًا اعتباطية، فيمكن للمتغير أن يحمل رقم تشغيلة وإشارة إلى شهادة ومهلة تسليم بأيام العمل وبعدًا يُحسب منه سعره. لا شيء من ذلك حقل مخصص مثبت على جانب مخطط ثابت. إنه المخطط نفسه.

الشيء القابل للشراء هو المتغير لا المنتج. المنتج هو الغلاف التقديمي، والمتغير هو الصنف الذي يحمل رقمًا وسعرًا، والسمات هي التي تولد التركيبات القابلة للاختيار. نوع المنتج يقرر ما الحقول التي يملكها المنتج، ونوع المتغير يقرر ما السمات التي تحملها متغيراته. لا شيء في هذا الترتيب يفترض ملابس ولا سلعًا مادية ولا عددًا ثابتًا من الخيارات.

النتيجة أن Drupal Commerce لا يكاد يفرض رأيًا في ما تبيعه. وثمن تلك الحرية أنه لا يكاد يقدم أي قرار أيضًا، ولا بد لأحد أن يتخذها كلها.

أين يقف Drupal Commerce اليوم

الإصدار الموصى به حاليًا هو Drupal Commerce 3.3.8، الصادر في 17 يوليو 2026، وهو يعمل مع Drupal 10.3 أو أحدث ومع Drupal 11. الإصدارات المستقرة مشمولة بسياسة التنبيهات الأمنية في Drupal، وهذا أهم مما يبدو: فالثغرة المفصح عنها تحصل على إصدار منسق بدلًا من بلاغ على GitHub.

تفيد صفحة مشروع Drupal Commerce بأن 35,870 موقعًا تستخدم الوحدة. وكان Commerce 3.0.0 أول إصدار مستقر من خط 3.x في يناير 2025، وقد أسقط دعم Drupal 9. ويحيط به نظام مساهمات صغير: Commerce Shipping عند 3.0.3 بنحو 15,200 تثبيت، والوحدات المتخصصة المذكورة أدناه في نطاق بضعة آلاف.

قارن ذلك بـ WooCommerce الذي يفيد بأكثر من 7 ملايين تثبيت نشط ويتطلب WordPress 6.9 وPHP 7.4 أو أعلى. وبمقياس قاعدة التثبيت فإن Drupal Commerce أصغر بنحو 200 مرة.

هذه النسبة هي أهم رقم في المقال، وهي تحذير لا مباهاة. معناها أن الجواب عن سؤال ما إذا كانت هناك وحدة جاهزة لغرض ما هو في الغالب لا.

الحجة الصادقة لصالح Shopify

يحل Shopify المشكلات الأربع التي تغرق معظم المتاجر ذاتية الاستضافة، ويحلها قبل أن تكتب سطر شفرة واحدًا.

فهو مستضاف، ومن ثم يخرج التوافر والتوسع والترقيع من بند ميزانيتك. وهو يتعامل مع بيانات البطاقة، فتصبح مساحة الامتثال التي ترثها جزءًا يسيرًا مما كانت لتكون عليه. وصفحة الدفع لديه مختبرة على حجم معاملات حقيقية لا تستطيع أي وكالة محاكاته، وعند ذلك الحجم تساوي فروق التحويل الصغيرة أكثر من أي تفضيل معماري. ونظام التطبيقات لديه يجعل معظم المتطلبات تصل في صورة اشتراك لا مشروع.

أما الكتالوج الاستهلاكي الذي يضم بضعة آلاف من أرقام الأصناف وعملة أو عملتين وبلا أسعار متفاوض عليها، فلا ينطبق عليه أي من المزايا الموصوفة لاحقًا. ستدفع لوكالة كي تعيد بناء ما تحصل عليه اليوم مقابل £65 شهريًا، وبصورة أسوأ.

لنقلها صراحة، لأن بقية المقال تحاجج في الاتجاه الآخر: ينبغي لمعظم المتاجر أن تتوقف عند Shopify. وإن كان متجرك منها فإن مقارنتنا بين Shopify وبناء متجر مخصص تتناول القرار بتفصيل أكبر من هذه الصفحة.

كم يكلف Shopify في المملكة المتحدة

ينشر Shopify أسعار المملكة المتحدة بالجنيه، فلا حاجة إلى أي تحويل. وبالقراءة من صفحة أسعار Shopify في سبتمبر 2026: باقة Basic بـ £25 شهريًا بالفوترة الشهرية أو £19 بالفوترة السنوية، وGrow بـ £65 أو £49، وAdvanced بـ £344 أو £259، وتبدأ Plus من £1,800 شهريًا. ويضيف POS Pro مبلغ £69 شهريًا لكل موقع.

رسوم البطاقات أثقل وزنًا من الاشتراك. فنسب البطاقات عبر الإنترنت من خلال Shopify Payments هي 2 % زائد 25 بنسًا على Basic، و1.7 % زائد 25 بنسًا على Grow، و1.5 % زائد 25 بنسًا على Advanced. والرقم الذي يغفل عنه معظم الناس هو رسم مزود الدفع الخارجي، ويُحصل حين تستخدم بوابة غير Shopify Payments: 2 % على Basic، و1 % على Grow، و0.6 % على Advanced، و0.2 % على Plus.

هذا الرسم يُضاف إلى ما تتقاضاه بوابتك أصلًا. ففي متجر تبلغ مبيعاته 1 مليون جنيه سنويًا ويستخدم مستحوذًا خارجيًا على باقة Advanced، يبلغ رسم الطرف الخارجي وحده £6,000 سنويًا، أي £18,000 على ثلاث سنوات، مقابل امتياز عدم استخدام Shopify Payments.

أين ينفد المجال أمام Shopify

الحدود منشورة وهي محددة. فوثائق Shopify عن إضافة المتغيرات تنص على أن لكل منتج ما يصل إلى ثلاثة خيارات وما يصل إلى 2,048 متغيرًا، وأن تجاوز أي منهما يستلزم تطبيقًا خارجيًا أو شفرة قالب تلتقط خصائص البنود.

الخيارات الثلاثة هي السقف الذي يضغط أولًا. فالنافذة واللوح المطبوع والستارة المفصلة والآلة المهيأة تحمل عادة ستة أو ثمانية خيارات مستقلة، وما إن تتجاوز ثلاثة حتى تكف المنصة عن نمذجة منتجك وتبدأ في تقريبه.

صفحة الدفع هي الجدار الثاني. فـامتدادات واجهة الدفع لدى Shopify لخطوات المعلومات والشحن والدفع متاحة على باقة Plus وحدها. ودون Plus يمكنك تغيير هوية صفحة الدفع لكن لا يمكنك إدراج منطق فيها، وهذا يستبعد اختيار نافذة التسليم وفحص الائتمان التجاري وبوابات الامتثال في اللحظة التي يجب أن تحدث فيها.

الحد الثالث هو التراكم. كل فجوة يسدها تطبيق، وكل تطبيق رسم شهري وارتباط ترقية، والمتجر الذي يشغل عشرين تطبيقًا لديه مشكلة صيانة تشبه إلى حد لافت تلك التي هرب منها.

الحجة لصالح WooCommerce وأين يجهد

يستحق WooCommerce إنصافًا أكثر مما يناله عادة. فهو مجاني، ويعمل على استضافة تكلف عشرات الجنيهات شهريًا، والبيانات ملكك، وكتالوج إضافاته هو الأوسع في التجارة الإلكترونية بفارق كبير. وللمتجر الاستهلاكي الصغير أو المتوسط الذي يعرف فريقه WordPress أصلًا، هو في الغالب الجواب الصحيح والأرخص.

وهو يجهد في ثلاثة مواضع متوقعة. الأول نموذج البيانات: فالمنتجات نوع منشور في WordPress بسمات مخزنة كبيانات وصفية متسلسلة، ومن ثم يصبح ترشيح كتالوج كبير غني بالسمات استعلامًا على جدول مفتاح وقيمة لا على أعمدة حقيقية. وهذا محتمل عند 1,000 منتج ومؤلم عند 50,000.

الثاني هو الأداء مع كثرة المتغيرات، وهو أشيع سبب لشعور المستخدم بأن متجر WooCommerce بطيء. وقد شرحنا آليته بالتفصيل في مقالنا عن سبب بطء متجر WooCommerce، وخلاصته أن المنتجات المتغيرة تضاعف الاستعلامات لا الصفوف.

الثالث هو تكاثر الإضافات. فـ WooCommerce يحل المشكلات بتثبيت أشياء، وبعد أربع سنوات يصبح المتجر محكومًا بجداول إصدارات ثلاثين مزودًا لا بجدولك أنت.

نمذجة المنتجات المعقدة: خط الفصل الأول

أوضح حالة لصالح Drupal Commerce هي المنتج الذي يُهيأ لا الذي يُختار. قماش يباع بالمتر مع رسم قص. زجاج يُسعر بالعرض مضروبًا في الارتفاع مع حد أدنى للفاتورة. آلة بثماني مجموعات خيارات، بعضها يلغي بعضًا. طباعة بمنحنى خصم كمي ورسم تجهيز لكل أمر شغل.

لا شيء من هذا شبكة متغيرات. وعلى منصة مستضافة تُقارب هذه الحالات بتطبيق ومجموعة من خصائص البنود، ما يعني أن السعر المعروض على العميل يُحسب خارج منطق التسعير الخاص بالمنصة ويجب تسويته في وقت لاحق.

في Drupal Commerce يُحل السعر بشفرة تكتبها أنت. فمُحلل السعر يستقبل المتغير والكمية والسياق الحالي ويعيد سعرًا. لا شيء غريب في ذلك، ومعناه أن السعر المهيأ هو السعر الحقيقي في كل مكان: في السلة وفي الطلب وفي حساب الضريبة وفي التصدير إلى ERP.

الاختبار الواجب تطبيقه بسيط. إن استطعت كتابة كتالوجك كجدول بيانات بصف واحد لكل شيء قابل للشراء فلست بحاجة إلى هذا. وإن لم تستطع فكل ما تبقى في المقال يصبح ذا صلة.

تسعير B2B وقوائم الأسعار والشروط المتفاوض عليها

خط الفصل الثاني هو ما إذا كان عميلان يريان يومًا سعرين مختلفين لرقم الصنف نفسه. المتاجر الاستهلاكية تجيب بلا. وشركات التجارة تجيب بنعم، وهذه الإجابة هي عادة النشاط كله.

لدى Shopify فعلًا حل B2B، ووثائق ميزات B2B حسب الباقة تؤكد توفره على Basic وGrow وAdvanced وPlus. والتفصيل في الحدود: دون Plus تحصل على ثلاثة كتالوجات نشطة كحد أقصى عبر كل أسواق B2B، وكتالوجات الشركات المباشرة حصرية لـ Plus، وكذلك الدفعات المقدمة والدفعات الجزئية وطلبات الدفع لكل شحنة. ثلاثة كتالوجات تكفي لثلاث شرائح أسعار ولا تنفع لأربعين حسابًا متفاوضًا عليه.

وعلى Drupal يقابل ذلك وحدة Commerce Price List، وهي حاليًا 8.x-2.16 بنحو 1,662 تثبيتًا مبلغًا عنه وبتغطية من فريق الأمن. تضبط الأسعار لكل مستخدم أو لكل دور، وتدعم شرائح الكمية ونطاقات التواريخ، وتستورد من ملفات CSV.

هذه النقطة الأخيرة هي النقطة العملية. فتاجر الجملة الذي لديه أربعون حسابًا، كل منها على قائمته المتفق عليها، تُحدث كل ربع سنة من ERP، هو مهمة استيراد CSV لا هجرة منصة.

متاجر متعددة وعملات ولغات من قاعدة شفرة واحدة

المتجر كيان من الدرجة الأولى في Drupal Commerce، وتُسند المنتجات إلى المتاجر المسموح لها ببيعها. قرار تصميمي صغير بنتيجة كبيرة: إذ يمكن لعدة واجهات متاجر أن تتشارك كتالوجًا واحدًا وخط طلبات واحدًا ولوحة إدارة واحدة، بينما تحمل عملات وإعدادات ضريبية وبوابات دفع وقواعد شحن مختلفة.

الشكل المعتاد هو موقع بريطاني وموقع للاتحاد الأوروبي وبوابة تجارية، كلها من نشر واحد. تُدخل بيانات المنتج مرة واحدة. وتنطبق قائمة الأسعار على المتجر التجاري وحده. وتُحل الضريبة لكل متجر، لأن المتجر يحمل بلد الفوترة الخاص به وتسجيلاته الخاصة.

كما يقدم نواة Drupal طبقة متعددة اللغات قوية فعلًا، بمسارات URL بديلة لكل لغة وكيانات مترجمة وروابط لغات بديلة، ولهذا حضور Drupal ثقيل في التعليم العالي والقطاع العام.

يغطي Shopify Markets جانبًا جيدًا من ذلك الآن، لكن الدفع السياقي وتخصيص واجهة المتجر عبر Markets محصوران في باقتي Advanced وPlus، فتصير المقارنة أمام £259 شهريًا على الأقل بدلًا من £25.

حين يكون الكتالوج محتوى تحريريًا

بعض الكتالوجات محتوى. فالتاجر المتخصص الذي تحمل صفحات منتجاته أدلة شراء وجداول مقارنة وشروحًا تقنية وملاحظات مُختبِر إنما يدير مطبوعة تقبل المدفوعات بالمناسبة.

على منصة مستضافة يصبح ذلك نظامين. نظام إدارة المحتوى يحمل المقال، والمتجر يحمل رقم الصنف، ويربطهما رابط وتصدير ليلي. فيعمل المحررون في مكانين، ويفهرس البحث مرتين، وتنمو بنية الروابط بشرخ في منتصفها.

في Drupal Commerce يكون المنتج كيانًا في النظام نفسه الذي يضم كل مقال، فيتشارك سير العمل التحريري وسجل المراجعات ومفردات التصنيف ومكتبة الوسائط وفهرس البحث ونموذج الصلاحيات. ويمكن لصفحة منتج أن تشير إلى ثلاثة مقالات، ولمقال أن يشير إلى تسعة منتجات، في الحالتين كإشارات كيانات حقيقية لا كروابط ملصوقة.

هذه هي الحجة التي تبرر Drupal في أغلب الأحيان لشركة كانت لتستقر مرتاحة على Shopify، وهي الحجة التي يجري رفضها في أغلب الأحيان بوصفها كمالية، إلى أن يقضي فريق تحرير عامًا كاملًا يعمل في واجهتي إدارة.

المنتجات المنظمة والغنية بالسمات

المنتجات التي تحمل بيانات امتثال هي الحالة الرابعة. مواد كيميائية بصحائف بيانات السلامة. أجهزة طبية بأرقام شهادات وتواريخ انتهاء. أغذية بمصفوفات مسببات الحساسية. أجهزة كهربائية بإقرارات المطابقة. وكل ما يحتاج إلى تتبع تشغيلة أو إلى علامة بيع مقيد.

المطلوب ليس مجرد تخزين تلك القيم. المطلوب التحقق منها وحفظ نسخها وعرض القيمة الصحيحة للتشغيلة التي استلمها العميل فعلًا، وإثبات ما كان منشورًا في تاريخ بعينه لاحقًا. وواجهة الحقول في Drupal ونظام المراجعات لديه يفعلان ذلك لأنهما بنيا لحوكمة المحتوى لا للترويج التجاري.

جانب الإنفاذ لا يقل أهمية. فمعالج الطلبات يستطيع رفض عملية دفع من شأنها شحن صنف مقيد بالعمر إلى بلد يحظره، أو تجمع صنفين لا يجوز نقلهما معًا، ويستطيع فعل ذلك داخل خط الطلبات لا في قالب المظهر.

على منصة مستضافة يكون كل فحص من تلك الفحوص تطبيقًا، والتطبيقات لا تتركب. فتطبيقان يعدلان السلة كلاهما هما تطبيقان سيختلفان يومًا ما.

حين يكون نظام ERP مصدر الحقيقة

الحالة الخامسة بنيوية. ففي شركة توزيع أو تصنيع يملك نظام ERP المخزون والأسعار وائتمان العملاء وحالة الطلب، ويكون الموقع سطح عرض معلقة به سلة تسوق. والسؤال ليس ما يستطيع المتجر فعله، بل كم يكلف إبقاؤه متوافقًا مع النظام الذي يقود فعلًا.

يرتاح Drupal Commerce هنا لأن التكامل يعمل داخل عمليتك أنت. فواجهة الطوابير تتولى العمل غير المتزامن، وواجهة الترحيل تتولى عمليات الاستيراد المتكررة والمتماثلة، ولا وسيط يتقاضى أجرًا عن كل سجل أو يخنق نافذة المزامنة لديك. واستيراد ليلي للأسعار والمخزون من 200,000 صف هو مجرد مهمة مجدولة.

على منصة مستضافة يكون التكامل نفسه إما اشتراك تطبيق أو اشتراك برمجية وسيطة، وتتحول حدود معدل الاستدعاء لدى المنصة إلى قيد معماري تصمم حوله بدلًا من أن تكون تفصيلًا. وهذا عملي، ولكثير من الشركات هو المفاضلة الصحيحة. لكنه يكف عن كونه صحيحًا حين تكون المزامنة كبيرة ومتكررة وحرجة للنشاط في آن واحد.

وإن كان عمل التكامل هو الجزء الأكبر من المشروع لا المتجر نفسه، فتلك مهمة تطوير برمجيات معلقة بها واجهة متجر، وينبغي تحديد نطاقها على هذا الأساس من البداية.

الضرائب هي حيث تتوقف المنصات المستضافة عن كونها رخيصة

الضرائب هي مركز التكلفة الصامت في التجارة الإلكترونية العابرة للحدود، وعندها تبدأ مقارنة الاشتراكات الشهرية في التضليل. وحدان يحسمان معظم الأمر.

حد التسجيل في ضريبة القيمة المضافة البريطانية

يضع دليل GOV.UK عن موعد التسجيل في ضريبة القيمة المضافة الحد عند £90,000 من إجمالي المبيعات الخاضعة للضريبة. ويوجد اختباران منفصلان يستوجبان التسجيل: اختبار متدحرج على اثني عشر شهرًا، يلزمك فيه التسجيل خلال 30 يومًا من نهاية الشهر الذي تجاوزت فيه المبيعات £90,000، واختبار استشرافي يلزمك فيه التسجيل بمجرد أن تدرك أن المبيعات ستتجاوز £90,000 خلال 30 يومًا مقبلة.

الاختبار الاستشرافي هو الذي يوقع بالمتاجر النامية، لأن تاريخ التسجيل هو يوم إدراكك لا يوم وصول المال.

ضريبة القيمة المضافة الأوروبية ونظام الشباك الواحد

يضع دليل المفوضية الأوروبية عن مكان فرض الضريبة حدًا سنويًا مجمعًا قدره EUR 10,000 يغطي معًا مبيعات السلع عن بعد داخل الاتحاد وخدمات الاتصالات والبث والخدمات الإلكترونية. فدونه يكون مكان فرض الضريبة حيث يبدأ الإرسال أو النقل. وفوقه تنتقل الضريبة إلى حيث ينتهي النقل، أي إلى نسبة العميل في بلده.

ويتيح نظام الشباك الواحد الإقرار بذلك كله في إقرار واحد في دولة عضو واحدة، يُقدم ربع سنوي بمواعيد في نهاية أبريل ويوليو وأكتوبر ويناير. ويغطي نظام الشباك الواحد للاستيراد السلع المستوردة من خارج الاتحاد في شحنات لا تتجاوز EUR 150.

ما الذي يفعله Drupal Commerce أصلًا

يشحن Commerce ملحق ضريبة القيمة المضافة للاتحاد الأوروبي داخل النواة لا كإضافة. وهو يحمل نسب الدول الأعضاء الـ 27 كلها إضافة إلى موناكو، ويميز النسب القياسية والمخفضة والوسيطة والمخفضة جدًا والصفرية، ويعالج الأقاليم الخاصة التي تتعثر عندها جداول النسب المسطحة، ومنها كورسيكا والأزور وماديرا والجزر اليونانية وجيب Jungholz النمساوي.

وهو يطبق القواعد أيضًا لا النسب وحدها: فرض الضريبة في بلد المقصد للسلع الرقمية، وتصفير التوريدات بين الشركات داخل الاتحاد عند تقديم رقم ضريبي صالح. وعلى منصة مستضافة يكون هذا السلوك عادة تطبيقًا بتكلفة لكل معاملة.

المدفوعات ومعيار PCI DSS وكيفية استلام البطاقة

طريقة جمعك لرقم البطاقة تحدد عبء الامتثال عليك، وقد تغيرت القواعد مؤخرًا بصورة يساء فهمها على نطاق واسع.

يشرح توضيح مجلس معايير أمن PCI لمعايير أهلية SAQ A شرطًا صار نافذًا في 1 أبريل 2025. على التجار أن يؤكدوا أن موقعهم غير معرض لهجمات من نصوص برمجية قد تؤثر في أنظمة التجارة الإلكترونية لدى التاجر، ويتحقق ذلك إما بتطبيق الأساليب الواردة في متطلبي PCI DSS رقم 6.4.3 و11.6.1، وإما بالحصول من مزود الدفع على تأكيد بأن حله المضمن يتضمن تلك الحمايات.

التحديد الدقيق للنطاق هو ما يخطئ فيه الناس. فذلك الشرط ينطبق فقط على التجار الذين تضمن صفحتهم نموذج الدفع الخاص بالمزود، في إطار مضمن عادة. ويذكر المجلس أنه لا ينطبق على التجار الذين يحولون العميل بعيدًا إلى المزود، سواء بإعادة توجيه HTTP أو بتحديث meta أو بجافاسكريبت، ولا على التجار الذين يسندون وظائف الدفع بالكامل إلى الخارج.

فإعادة التوجيه المستضافة تبقي المساحة صغيرة. أما الحقول المضمنة، وهي أفضل في التحويل وهي ما يريده الجميع تقريبًا في الواقع، فتُدخل سلامة كل نص برمجي على صفحة الدفع لديك في نقاش الامتثال الخاص بك.

هنا تكمن ميزة Shopify الحقيقية، لأن صفحة الدفع لهم والنصوص البرمجية عليها لهم. أما في Drupal Commerce فصفحة الدفع لك، ولذلك يجب هندسة الجواب: سياسة صارمة لأمن المحتوى، وسلامة الموارد الفرعية، وجرد لكل نص برمجي يعمل على صفحة الدفع، ورصد للتغيير حين يتحرك أحدها. هذا العمل ليس صعبًا وليس اختياريًا، ومكانه الميزانية لا أن يُكتشف أثناء تدقيق.

إمكانية الوصول مخاطرة قانونية وتجارية

تتجمع إخفاقات إمكانية الوصول في التجارة الإلكترونية عند صفحة الدفع، وهي المكان نفسه الذي يكلف فيه كل إخفاق مالًا مباشرة.

المرجع المعني هو WCAG 2.2، وهي توصية من W3C نُشرت في 12 ديسمبر 2024. والمعايير التي تعض في متجر محددة. فالمعيار 1.3.5 Identify Input Purpose عند المستوى AA يغطي الملء التلقائي لحقول العنوان والبطاقة. والمعيار 3.3.7 Redundant Entry عند المستوى A يُنتهك كلما أجبرت صفحة الدفع العميل على إعادة كتابة عنوان التسليم في خطوة الدفع. والمعيار 3.3.8 Accessible Authentication عند المستوى AA يحكم إنشاء الحساب وتسجيل الدخول. والمعيار 2.5.8 Target Size عند المستوى AA يمسك بمُبدلات الكمية وأزرار الإزالة من السلة، والمعيار 1.4.3 Contrast عند المستوى AA يمسك بالزر الرمادي المعطل ظاهريًا وهو في الحقيقة مفعل.

ويحيط بالطلب نفسه معياران آخران: 3.3.1 Error Identification عند المستوى A، و3.3.4 Error Prevention للمعاملات القانونية والمالية والبياناتية عند المستوى AA، وهو معني تمامًا بإتمام طلب.

كثيرًا ما يُبالغ في وصف الموقف القانوني في المملكة المتحدة. فالتاجر الخاص غير ملزم بتشريع يسمي مستوى مطابقة لـ WCAG. والذي ينطبق هو الواجب الوارد في المادة 20 من قانون المساواة لسنة 2010 باتخاذ خطوات معقولة لتفادي إلحاق ضرر جوهري بذوي الإعاقة، بما في ذلك توفير الوسائل المساعدة. أما اللوائح التي تسمي مستوى مطابقة، وهي Public Sector Bodies (Websites and Mobile Applications) (No. 2) Accessibility Regulations 2018، فتنطبق على هيئات القطاع العام لا على المتاجر.

النقطة التجارية أحد من النقطة القانونية. فعلى قالب مستضاف لا تستطيع دائمًا إصلاح ما يحقنه تطبيق في صفحة الدفع لديك. أما على منصة تتحكم فيها فتستطيع.

كم تكلف ثلاث سنوات فعليًا

المقارنة التي يجريها الناس تضع الاشتراك الشهري أمام الاستضافة الشهرية، وهو أقل سطور الجدول أهمية. فتكلفة البناء والصيانة هما المهيمنان، ونسب المعاملات تهيمن عند الحجم الكبير.

النطاقات أدناه تقديرات داخلية من Mecanik لمتجر بريطاني متوسط السوق، باستثناء أرقام اشتراكات ورسوم Shopify المذكورة بالجنيه تمامًا كما ينشرها Shopify. وكل ما عداها هو ما نتوقع أن نسعره، والفارق داخل كل سطر أوسع من الفارق بين المنصات عند الطرف الأدنى.

ما الذي يشتريه كل سطر في الجدول

بالنثر: تكلف باقة Shopify Advanced بين £9,324 و£12,384 اشتراكًا على ثلاث سنوات بحسب التزامك سنويًا، وتشمل الاستضافة، لكنها تضيف اشتراكات تطبيقات تتراوح واقعيًا بين £5,400 و£14,400 في المدة نفسها. ولا يدفع WooCommerce شيئًا للمنصة ويدفع بين £3,600 و£14,400 للاستضافة، مع إضافات بين £3,000 و£9,000 على مدى الثلاث سنوات. ولا يدفع Drupal Commerce شيئًا للترخيص، وينفق الأكثر على الاستضافة بين £5,400 و£21,600 لأنه أثقل التطبيقات الثلاثة، وينفق الأقل على الإضافات، بين لا شيء ونحو £3,000، لأن نظائرها وحدات مساهمة لا تجارية.

تكلفة البناء هي التي تفصل بين المنصات. فبناء Shopify بين £8,000 و£25,000 يشتري متجرًا بقالب ومع التكاملات المعتادة، مقابل £10,000 إلى £35,000 على WooCommerce. والمواصفات نفسها على Drupal Commerce تساوي £35,000 إلى £120,000، لأن صفحة الدفع ومنطق التسعير والتكاملات تُكتب كلها بدل أن تُضبط. وتتبع الصيانة الشكل نفسه، بين £3,000 و£9,000 سنويًا لـ Shopify، و£4,000 إلى £12,000 لـ WooCommerce، و£12,000 إلى £30,000 لـ Drupal Commerce، بما يعكس أجورًا يومية لوكالات بريطانية تتراوح نحو £600 إلى £900، نتناولها في دليلنا عن أسعار مطوري Drupal.

أين تستقر إجماليات الثلاث سنوات

تستقر إجماليات الثلاث سنوات عند نحو £32,000 إلى £79,000 لـ Shopify، و£29,000 إلى £94,000 لـ WooCommerce، و£76,000 إلى £235,000 لـ Drupal Commerce. وتُضاف رسوم البطاقات والبوابات فوق الثلاثة جميعًا وتتوسع مع حجم المبيعات، ولهذا يساوي رسم البوابة الخارجية لدى Shopify البالغ 0.6 % على Advanced مبلغ £18,000 على ثلاث سنوات في متجر بمبيعات 1 مليون جنيه.

اقرأ الجدول بصدق تجد أن Drupal Commerce يكلف ضعفين إلى ثلاثة أضعاف. وهو مبرر فقط حين لا يكون البديل متاحًا فعليًا، وهذا هو مغزى الأقسام الخمسة السابقة كله.

Drupal Commerce بلا رأس ومفصول

فصل Drupal Commerce متطلب حقيقي في مجموعة ضيقة من الحالات وموضة في معظم ما عداها. والاختبار الصادق هو ما إذا كان شيء غير الموقع يحتاج إلى الكتالوج نفسه.

هو متطلب حقيقي حين يجب أن يتشارك تطبيق جوال أصلي وموقع نموذج منتج وتسعير واحدًا، وحين لا تُستبدل واجهة أمامية قائمة بناها فريق آخر، وحين تستهلك أجهزة نقاط بيع أو أكشاك السلة نفسها، أو حين يكون نظام التصميم مملوكًا خارج المشروع ولا يمكن التعبير عنه بـ Twig. في تلك الحالات تكون الواجهة البرمجية هي المنتج ويكون نظام إدارة المحتوى غير مرئي عمدًا.

وهو موضة حين يكون السبب المطروح هو الأداء. فالواجهة الأمامية التقليدية لـ Drupal، إذا خُزنت مؤقتًا جيدًا، تقدم صفحات المنتجات للزوار غير المسجلين من الحافة، ونادرًا ما يكون أسلوب العرض هو ما يجعل المتجر البطيء بطيئًا.

تتركز التكلفة في موضع واحد. فنواة Drupal تكشف المحتوى عبر JSON:API بلا إعداد، ووحدة Commerce Cart API تضع السلال خلف واجهة REST، فتصبح قراءة الكتالوج وبناء السلة شبه مجانيتين. أما صفحة الدفع فلا. إذ يجب إعادة بناء معالجة العناوين وعرض الضريبة واختيار الشحن والعروض الترويجية ودمج عنصر الدفع وتأكيد الطلب كلها في الواجهة الأمامية، وهذا عادة 40 % أو أكثر من إجمالي البناء.

قاعدة القرار في خمس دقائق

أجب عن ستة أسئلة عن كتالوجك أنت. كل نعم تساوي نقطة واحدة.

هل يحتاج أي من منتجاتك إلى أكثر من ثلاثة خيارات أو إلى أكثر من 2,048 تركيبة قابلة للشراء؟ هل يدفع عميلان مختلفان يومًا سعرين مختلفين لرقم الصنف نفسه؟ هل تبيع إلى أكثر من بلد بمعاملة ضريبية مختلفة، أو تتوقع تقديم إقرار الشباك الواحد؟ هل الكتالوج أيضًا محتوى تحريري يكتبه الفريق نفسه ويصونه؟ هل يمثل نظام ERP أو PIM المرجع للسعر والمخزون والمتجر تابع له؟ هل تحتاج إلى إدراج منطق خاص بك داخل صفحة الدفع لا مجرد تغيير هويتها؟

عند صفر أو نقطة واحدة اختر Shopify. فالمزايا الموصوفة في هذا المقال لا تنطبق عليك وستدفع لإعادة بناء ما تستأجره اليوم.

وعند نقطتين يكون القرار مفتوحًا فعلًا، وغالبًا ما يكون WooCommerce الطريق الوسط الأفضل، خاصة إن كان الفريق يشغل WordPress أصلًا.

وعند ثلاث نقاط فأكثر يستحق Drupal Commerce تسعيرًا جادًا، لأن الحلول الالتفافية المطلوبة في غيره ستكلف أكثر من المنصة على ثلاث سنوات. وعند خمس أو ست نقاط لا تكون المنصة المستضافة خيارًا أرخص، بل منتجًا مختلفًا لا يؤدي المهمة.

أين تخطئ مشاريع Drupal Commerce عادة

أشيع إخفاق هو اختياره للسبب الخطأ. فالقول إننا نشغل Drupal أصلًا ليس متطلب تجارة. فموقع المحتوى والموقع المعاملاتي يختلفان في التوافر وفي الاختبار وفي عواقب النشر الفاشل، ومعاملة المتجر كقسم آخر من الموقع القائم هي الطريق التي يكتسب بها مشروع تجارة إلكترونية صغير فريق منصة غير مخطط له.

الثاني هو نقص الموارد المخصصة للصيانة. فمع 35,870 تثبيتًا يكون النظام صغيرًا بما يكفي لأن تستخدم وحدات يصونها عدد قليل من الأشخاص، ولا بد لأحد من جهتك أن يتابع التنبيهات الأمنية ويجدول التحديثات. وموقع Drupal Commerce الذي لا يتولى أحد هذه المسؤولية فيه هو حادث أمني مؤجل، وهو ما نتناوله بتفصيل أكبر إلى جانب متطلبات الاستضافة التي يفرضها Drupal فعلًا.

الثالث هو افتراض وجود وحدة جاهزة. تحقق قبل التسعير. فإن لم تكن موجودة فالعمل مهمة تطوير موقع مخصصة وتحتاج إلى تقدير حقيقي لا إلى بند في قائمة.

الرابع هو الانضباط في الإصدارات الرئيسية. فـ Commerce 3 يتطلب Drupal 10.3 أو أحدث، والموقع الذي يتخلف عن النواة يكتشف في النهاية أن وحدات التجارة لديه مضت من دونه. ودليلنا عن تطوير Drupal في 2026 والمقال عن تكاليف الهجرة وخياراتها ومواعيدها يتناولان كلاهما هذه الدورة.

اتخاذ القرار الصحيح

يُحسم الاختيار بتعقيد المنتج والتسعير، لا بحجم الزيارات ولا بالمبيعات ولا بالتفضيل. فانمذج كتالوجك أولًا على الورق، بكل خيار وكل سعر متفاوض عليه وكل تكامل يجب أن يبقى متوافقًا مع شيء آخر. فإن اتسعت له شبكة متغيرات فاشتر المنصة المستضافة وأنفق الميزانية الموفرة على العرض والتسويق.

تبني Mecanik وتصون النوعين من المتاجر، وسنخبرك على أي جانب من الخط أنت قبل أن نسعر أي شيء. فإن كان الجواب Drupal Commerce فالعمل مهمة تطوير موقع بمكون تكامل كبير؛ وإن رجح عمل ERP على واجهة المتجر فهو ينتمي إلى تطوير البرمجيات بدلًا من ذلك. وإن كان الجواب Shopify فسنقولها، ونفضل قولها الآن لا بعد ثمانية عشر شهرًا من بدء إعادة البناء.

الأسئلة الشائعة

هل Drupal Commerce أفضل من Shopify؟ ليس لمعظم المتاجر. فـ Shopify أرخص على ثلاث سنوات، ويتولى امتثال PCI والاستضافة، ولديه صفحة دفع مختبرة على حجم لا تضاهيه أي وكالة. ويتفوق Drupal Commerce في مجموعة ضيقة من الحالات: منتجات بأكثر من ثلاثة خيارات أو 2,048 متغيرًا، وأسعار متفاوض عليها لكل عميل، وكتالوجات هي أيضًا محتوى تحريري، ومتاجر يملك فيها نظام ERP السعر والمخزون.

كم يكلف بناء Drupal Commerce في المملكة المتحدة؟ توقع £35,000 إلى £120,000 للبناء الأولي و£12,000 إلى £30,000 سنويًا للصيانة، بأجور يومية لوكالات بريطانية تتراوح نحو £600 إلى £900. وعلى ثلاث سنوات يستقر متجر Drupal Commerce عادة بين £76,000 و£235,000 شاملة الاستضافة، مقابل نحو £32,000 إلى £79,000 لباقة Shopify Advanced. وهذه تقديرات داخلية لا عروض أسعار.

أي إصدار من Drupal Commerce ينبغي أن أستخدم؟ Drupal Commerce 3، وهو حاليًا عند 3.3.8 الصادر في 17 يوليو 2026. يعمل مع Drupal 10.3 أو أحدث ومع Drupal 11، وإصداراته المستقرة مشمولة بسياسة التنبيهات الأمنية في Drupal. أما Commerce 2 فقد دعم Drupal 9 و10 وهو دورة الإصدار السابقة، ولذلك ينبغي للمشاريع الجديدة أن تبدأ على خط 3.x.

هل يتعامل Drupal Commerce مع ضريبة القيمة المضافة الأوروبية والشباك الواحد؟ قواعد الضريبة مبنية داخل نواة Commerce لا مباعة كإضافة. فملحق ضريبة القيمة المضافة للاتحاد الأوروبي يحمل نسب الدول الأعضاء الـ 27 كلها إضافة إلى موناكو، ويميز النسب القياسية والمخفضة والوسيطة والمخفضة جدًا والصفرية، ويعالج الأقاليم الخاصة، ويطبق ضريبة بلد المقصد على السلع الرقمية، ويصفر التوريدات بين الشركات داخل الاتحاد مقابل رقم ضريبي صالح. أما تقديم إقرار الشباك الواحد فيبقى مهمة محاسبية.

متى يستحق Drupal Commerce بلا رأس العناء؟ حين يستهلك شيء غير الموقع الكتالوج نفسه، مثل تطبيق أصلي أو جهاز نقطة بيع أو واجهة أمامية يملكها فريق آخر. وهو لا يستحق العناء لمجرد السرعة، لأن الواجهة التقليدية المخزنة مؤقتًا سريعة أصلًا. وخصص ميزانية لإعادة بناء صفحة الدفع، وهي عادة 40 % أو أكثر من بناء مفصول.