تخطَّ إلى المحتوى

OpenCart وNext.js: مسألة واجهة متجر

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

2 دقيقة قراءة

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

المطروح أضيق. فـ OpenCart يعرض أيضًا واجهة متجركم، وذلك وحده موضوع هذا القرار.

ما يجيده القالب

لمتجرٍ هو متجر، مسار العرض الافتراضي جيد: صفحات المنتجات والفئات والبحث والسلة. هو HTML معروض من الخادم، قابل للتخزين المؤقت، وقالبٌ مصان على استضافة محترمة سريع.

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

القياس الذي يسبق كل شيء

خذوا القوالب التي تحمل الإيرادات: الرئيسية، وفئة واحدة، وصفحة منتج. واقرأوا بيانات الميدان لا درجة مختبر.

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

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

أين تحتاج الواجهة تغييرًا فعلًا

ثمة حدٌّ حقيقي، وليس هو السرعة.

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

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

كيف تجتمع الأجزاء

يحتفظ OpenCart بالكتالوج والسلة وصفحة الدفع ولوحة الإدارة. ويعرض Next.js واجهة المتجر ويخاطب OpenCart عبر واجهته REST، عادةً بطبقة رقيقة أمامها، لأن تلك الواجهة مصوغة حول السلة لا حول كونها مصدر محتوى عامًا.

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

ويجري الانتقال مسارًا بمسار: القوالب التي تحمل الزيارات أولًا، والباقي لا يزال يقدّمه OpenCart، وملاحظة مكتوبة بأي نظام يجيب عن أي عنوان. هكذا نحدد نطاق هذا النوع من العمل، وخريطة العناوين أول ما يُتفق عليه لا آخره.

متى تتركونه وشأنه

متجر هو متجر. ولا أحد في الداخل يكتب جافاسكربت. ومنتجات تدور أسرع من الشيفرة. ومجموعة إضافات تعمل ويفهمها أحد.

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

أسئلة ذات صلة

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

العودة إلى كل المقالات