WordPress أم Laravel: أيّهما تبني فعلًا

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

لذا فالمفيد ليس جدول مزايا، بل اختبار تطبّقه على ما تبنيه، ورواية صادقة عن موضع الخط الفاصل.

في أغلب الأحيان الجواب هو WordPress

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

للشركات التي تبيع إعادة البناء مصلحة واضحة في أن تقول لك غير ذلك. ونحن نبيع عمل Laravel ونقول لك غير ذلك أيضًا: استبدال موقع WordPress يؤدي وظيفته بتطبيق مخصص هو أضمن طريقة نعرفها لإنفاق ستة أرقام والوصول إلى وضع أسوأ قليلًا.

الاختبار الذي يحسم الأمر

انزع لوحة الإدارة. هل يبقى المنتج منتجًا؟

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

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

أين يصير WordPress مكلفًا فعلًا

لا في الأداء، ولا في الأمان بالمعنى الذي تدّعيه صفحات المقارنة. فكلاهما يُحَل بالمال والانتباه.

يصير مكلفًا حين تنتقل قواعد العمل إلى الإضافات.

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

والعلامة الدالة سؤال أين تعيش هذه القاعدة. في موقع WordPress سليم هذا سؤال محتوى بجواب محتوى. أما في المواقع التي نُستدعى إليها فيعطي أربعة أشخاص أربعة أجوبة مختلفة، وأحدها "أظنها في القالب".

WooCommerce، وهو مسألة قائمة بذاتها

يستحق WooCommerce فصلًا خاصًا، لأن هذا القرار يخطئ عنده أكثر من أي موضع آخر، وفي الاتجاهين.

دون بضعة آلاف صنف، بضريبة معتادة وشحن معتاد ومزوّد دفع يدعمه أصلًا، يصعب التفوق على WooCommerce في الكلفة. لا تُعِد بناءه.

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

كيف يبدو الانتقال إن وصل الأمر إليه

ليس إعادة كتابة. رأينا ما يكفي منها يفشل حتى صارت لدينا صفحة تشرح لماذا.

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

الصيغة التي ليست ترحيلًا أصلًا

أحيانًا يكون الجواب أن الاثنين يستمران ولا ينتقل أيٌّ منهما. يبقى الموقع التسويقي على WordPress يصونه من يصونه اليوم، ويكون المنتج تطبيق Laravel، ويتشاركان نظام تصميم ولا شيء غيره.

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

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

وإن كان المتجر على Shopify لا على WooCommerce، تغيّرت الحجة شكلًا. فأنتم لا توازنون بين نظام محتوى وإطار عمل، بل بين منتج مستأجَر ونظام تملكونه، والحدّ يقع في موضع آخر.

الحدّ نفسه يقع في الموضع نفسه في أنظمة المحتوى الأخرى، وهي ليست سواءً. فـ Joomla يأتي بتحكم بالصلاحيات ودعم متعدد اللغات يحتاج WordPress إضافاتٍ لهما، وذلك يغيّر ما يستحق الإبقاء وما يجب نقله.