OpenCart أم Laravel: لديك تطبيق PHP بالفعل

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

فالصيغة الصادقة للسؤال أضيق: لديكم تطبيق PHP، وتسألون إن كان لا يزال المناسب لما صار العمل يفعله.

ما يجيده OpenCart فعلًا

يستحق القول بوضوح، لأنه يُغفَل عادةً.

كتالوج بخيارات ومتغيرات، وسلة، وصفحة دفع، وقواعد ضريبة وشحن، وإعداد متعدد المتاجر، ولوحة إدارة يشغّلها فريق صغير بلا تدريب. يعمل على استضافة رخيصة، ونُصِّب مئات الآلاف من المرات، ويغطي سوق الإضافات معظم ما يطلبه متجر نامٍ.

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

أين يبدأ السؤال فعلًا

لا عند الزيارات ولا عند حجم الكتالوج. يبدأ حين تكف القواعد التي تحتاجونها عن كونها قواعد كتالوج.

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

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

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

مسألة التعديلات، بصراحة

أجدر ما يُقاس قبل أي شيء هو كم ابتعد تنصيبكم عن التنصيب القياسي.

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

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

ما يغيّره تطبيق Laravel وما لا يغيّره

يغيّر موضع القواعد: طبقة خدمات، ومخطط بقيود عليه، وترحيلات، ومجموعة اختبارات، وطابور للعمل الذي لا ينبغي أن يجري داخل الطلب. فإن كان منطق العمل هو المنتج، فلهذا وُجد إطار العمل.

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

كيف يجري الانتقال فعلًا

مسارًا بمسار، والنظامان يعملان، وهو المقاربة لا الاستثناء.

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

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

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