مقارنة مفصلة بين WordPress و October CMS

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

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

لماذا أكتوبر CMS

لقد اكتشفت نظام أكتوبر CMS عندما فازت بجائزة ، وبعد ذلك دخلت في وضع البحث وقضيت وقتًا طويلاً في البحث بعمق في نظام إدارة المحتوى هذا - من منظور كل من المستخدم والمطور. عندما اكتسبت المعرفة حول نظام إدارة المحتوى هذا ، شعرت بالثقة في أنني أستطيع تقديم تقييم موضوعي لميزاته على عكس WordPress. لقد اخترت CMS للمقارنة بين الخيارات البديلة مثل Grav و Statamic و ButterCMS و Joomla و Drupal و Jekyll و Hugo وغيرها ، للأسباب التالية:

• أعرف كيف يعمل نظام إدارة المحتوى (على عكس Grav) ؛
• إنه مجاني ومفتوح المصدر (على عكس Statamic و ButterCMS) ؛
• بعد خمس سنوات ، يكون جديدًا "نسبيًا" (على عكس جوملا ودروبال) ؛
• إنه منشئ محتوى ديناميكي (وليس ثابتًا) ومقره في PHP (على عكس Jekyll و Hugo).
  

أعتقد أن October CMS هو مرشح جيد لأنه يعتمد على Laravel وهو إطار عمل يستخدم لبناء التطبيقات الحديثة. بعد سبع سنوات من وجوده ، حصل على موافقة إيجابية من المطورين (كما يتضح من مجتمعه الكبير ونظامه البيئي) ، ويمثل تباينًا واضحًا مع الترميز في WordPress ، أي أن WordPress هو في الغالب برمجة إجرائية بينما Laravel هو بالتأكيد برمجة موجهة للكائنات.

ما الفرق بين الاثنين؟

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

بالإضافة إلى ذلك ، لا يمكن لهذه المقالة أبدًا استخلاص استنتاجات نهائية لأنها معنية فقط بمجموعة فرعية من جميع الاحتمالات. على سبيل المثال ، يمكننا أيضًا العثور على مقارنات عبر الإنترنت مثل "WordPress vs Drupal vs Joomla" و "WordPress vs Static Site Generators" وحتى "WordPress vs Medium". نظرًا لعدم رؤية أي من هذه المقالات للصورة الكاملة ، فلا يمكن أن تكون أي من هذه المقارنات قاطعة على الإطلاق ، ولا ينبغي التعامل معها على هذا النحو.

لنبدأ بالمقارنة.

مجموعة الفلسفة والهدف

ليس من قبيل المصادفة أن WordPress يدعم ما يقرب من 1 من 3 مواقع. منذ إنشائها ، سعت إلى أن تكون سهلة الاستخدام للغاية وقد نجحت في ذلك ، مما أدى إلى إزالة الاحتكاك للمستخدمين التقنيين وغير التقنيين على حد سواء وكذلك للأشخاص من جميع الخلفيات - بغض النظر عن مستوياتهم التعليمية والاقتصادية. أعرب مؤسس WordPress ، مات مولينويج ، عن أن شعار WordPress "Democratize Publishing" للعصر الحالي يعني ما يلي:

"يجب أن يكون الأشخاص من جميع الخلفيات والاهتمامات والقدرات قادرين على الوصول إلى برنامج Free-as-in-speech الذي يمكّنهم من التعبير عن أنفسهم على الويب المفتوح وامتلاك المحتوى الخاص بهم."

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

في المقابل ، أكتوبر CMS موجه أكثر نحو المطور ، حيث تم إثبات الوضوح منذ إصداره الأول:

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

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

تثبيت

يشتهر WordPress بتثبيته لمدة 5 دقائق ، على الرغم من أن العديد من الأشخاص يشيرون إلى أنه (مع الأخذ في الاعتبار جميع المكونات الإضافية التي يجب تثبيتها) يتطلب التثبيت النموذجي 15 دقيقة أو أكثر. بالإضافة إلى ذلك ، يوفر WordPress أيضًا ميزة المواقع المتعددة ، والتي تتيح لنا إنشاء شبكة من عدة مواقع افتراضية تحت تثبيت واحد. تسهل هذه الميزة على الوكالة إدارة مواقع عملاء متعددين - من بين حالات مستخدمين آخرين.

يعد تثبيت October CMS أيضًا سلسًا للغاية: يستغرق تثبيت المعالج نفسه أقل من خمس دقائق ، وإذا قمت بتثبيته من خلال تثبيت وحدة التحكم ، فسيكون أسرع. يمكنك القيام بهذا الأخير عن طريق الانتقال ببساطة إلى الدليل الهدف ثم تنفيذ curl -s https://octobercms.com/api/installer | php curl -s https://octobercms.com/api/installer | php (وبعد ذلك نحتاج إلى إدخال تكوين قاعدة البيانات ، وإلا فإنه يتصرف كملف ثابت CMS). بمجرد اكتمال التثبيت ، سيكون لدينا موقع ويب يعمل بكامل طاقته ، ولكننا لا نزال مكشوفين تمامًا (إذا أضفت الوقت اللازم لتثبيت المكونات الإضافية المطلوبة وتكوينها ، فيمكنك توقع أن يستغرق الأمر 15 دقيقة على الأقل).

حماية

تم اتهام WordPress بأنه غير آمن بسبب الكم الهائل من نقاط الضعف التي يتم العثور عليها باستمرار. يؤدي ذلك إلى إجبار المستخدمين على تحديث برنامج CMS وجميع المكونات الإضافية المثبتة دائمًا لتجنب الثغرات الأمنية. من بين المشكلات الرئيسية دعم WordPress للإصدارات القديمة من PHP والتي لم تعد مدعومة من قبل مجتمع تطوير PHP (يدعم WordPress حاليًا PHP 5.2.4 ، بينما أحدث إصدار PHP مدعوم بالكامل هو 5.6). ومع ذلك ، يجب حل هذه المشكلة في أبريل 2019 عندما يبدأ WordPress رسميًا في دعم إصدارات PHP 5.6 وما فوق.

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

من ناحية أخرى ، لا يتمتع October CMS بسمعة كونه غير آمن. ومع ذلك ، نظرًا لوجود ما يقرب من 27000 موقع مباشر يستخدم شهر أكتوبر مقارنة بملايين WordPress ، لا يمكننا الحكم على الاثنين وفقًا للشروط نفسها. ومع ذلك ، فإن الفريق الذي يقف وراء نظام إدارة المحتوى لشهر أكتوبر يأخذ الأمان على محمل الجد ، كما يتضح من مطالبة تثبيت المعالج بإدخال عنوان URL الخلفي لنظام إدارة المحتوى ، والذي تم تعيينه /backend بشكل افتراضي ولكنه قابل للتغيير إلى أي شيء آخر ، مما يزيد من صعوبة استهداف المتسللين للموقع . في المقابل ، يجب أن يتم تغيير عناوين URL لتسجيل الدخول والخلفية في WordPress من /wp-login.php و /wp-admin على التوالي إلى شيء آخر من خلال مكون إضافي. بالإضافة إلى ذلك ، يمكن أن يعمل October CMS كملف ثابت CMS (أي بدون قاعدة بيانات) وتجنب الثغرات الأمنية المتعلقة بقاعدة البيانات مثل حقن SQL.

تكنولوجيا المكدس

يعمل كل من WordPress و October CMS على مكدس LAMP التقليدي: Linux و Apache و MySQL و PHP. (ومع ذلك ، تم إصلاح PHP فقط: يمكننا أيضًا استخدام Windows و Nginx و MariaDB وغيرها.) يمكن أيضًا أن يتصرف October CMS كملف ثابت CMS ، مما يعني أنه يمكنه الاستغناء عن قاعدة بيانات ، على الرغم من ذلك ، على حساب التخلي العديد من الوظائف (مثل منشورات المدونة والمستخدمين) الوظيفة الوحيدة المضمونة هي الصفحات ، والتي تعتبر الوحدة الأساسية لإنشاء ونشر المحتوى وشحنها كميزة أساسية.

فيما يتعلق بمكدس اللغة ، فإن المواقع التي تم إنشاؤها باستخدام كل من WordPress و October CMS تستند إلى HTML و CSS وجافا سكريبت (لاحظ أن PHP تستخدم لإنشاء HTML). يسهّل أكتوبر CMS أيضًا استخدام ملفات LESS و SASS.

نموذج البرمجة

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

على الجانب الآخر ، يتبع October CMS نموذج برمجة إلزامي ، بناءً على حساب العمليات الحسابية عن طريق معالجة حالة الكائنات. يقع October CMS على قمة Laravel ، وهو إطار عمل ويب مؤسس بالكامل على مبادئ البرمجة الشيئية التي تمكن من إنتاج تطبيقات معيارية بناءً على مفاهيم مثل Model-View-Controller لفصل واجهة المستخدم عن بيانات التطبيق ، و Dependency Injection إلى تكوين تبعيات الفئة ، ومبدأ فصل الواجهة لتحديد الخدمات الأساسية التي يوفرها إطار العمل ، من بين أشياء أخرى كثيرة.

خطاف / أحداث

يمكن وصف البرمجة في WordPress بأنها HDD والتي تعني "تطوير يحركها هوك". الخطاف هو آلية تسمح بتغيير السلوك أو القيمة الافتراضية والسماح للكود الآخر بتنفيذ الوظائف ذات الصلة. يتم تشغيل الخطافات من خلال "الإجراءات" التي تسمح بتنفيذ وظائف إضافية و "عوامل التصفية" التي تسمح بتعديل القيم.

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

الخبر السار هو أن Laravel (وبالتالي أكتوبر CMS) يدعم أيضًا مفهوم الخطافات ، والتي تسمى "الأحداث". توفر الأحداث تنفيذًا بسيطًا للمراقب ، مما يمكّن الكود من الاشتراك والاستماع إلى الأحداث التي تحدث في التطبيق والتفاعل حسب الحاجة. تجعل الأحداث من الممكن تقسيم وظيفة معقدة إلى مكونات ، والتي يمكن تثبيتها بشكل مستقل مع التعاون مع بعضها البعض ، وبالتالي تمكين إنشاء تطبيقات معيارية.

الاعتماد على مكتبات JavaScript

يشتمل أحدث إصدار من WordPress على Gutenberg المدعوم من React لتجربة إنشاء المحتوى الافتراضية. وبالتالي ، يعتمد تطوير WordPress الآن إلى حد كبير على JavaScript (في الغالب من خلال React) ، على الرغم من أنه من الممكن أيضًا استخدام أطر عمل أو مكتبات أخرى (كما يتضح من Elementor Blocks لـ Gutenberg الذي يعتمد على Marionette). بالإضافة إلى ذلك ، لا يزال WordPress يعتمد على Backbone.js (لمدير الوسائط) و jQuery (رمز قديم) ، ومع ذلك ، يمكننا أن نتوقع أن يتلاشى الاعتماد على هذه المكتبات مع دمج Gutenberg كمعيار جديد.

يعتمد October CMS على jQuery ، والذي يستخدمه لتنفيذ إطار عمل AJAX الاختياري الخاص به لتحميل البيانات من الخادم دون تحديث صفحة المتصفح.

الصفحات والموضوعات والإضافات

يتعامل كل من WordPress و October CMS مع الصفحة على أنها الوحدة الأساسية لإنشاء المحتوى ونشره (في حالة WordPress ، بالإضافة إلى المنشور) ، ودعم تغيير شكل الموقع وأسلوبه من خلال السمات ، والسماح بتثبيت وظائف الموقع وتوسيعها من خلال المكونات الإضافية . على الرغم من أن المفاهيم هي نفسها في كلا نظامي إدارة المحتوى ، إلا أن هناك بعض الاختلافات في التنفيذ التي تنتج سلوكًا مختلفًا إلى حد ما.

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

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

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

وظائف Core vs Plugin

يحاول WordPress تقديم الحد الأدنى من الوظائف الأساسية التي يتم تحسينها من خلال المكونات الإضافية. يعتمد WordPress على "قاعدة ⁸⁰ ⁄ ₂₀ " لتقرير ما إذا كان سيتم تضمين بعض الوظائف في تجربته الأساسية أم لا. إذا كانت تفيد 80 ٪ من المستخدمين ، فإنها تنتمي إلى plugin-land. عند إضافة المكونات الإضافية إلى موقع ما ، يمكن أن تؤدي إلى سخام إذا تم تثبيت عدد كبير جدًا من المكونات الإضافية. قد لا تعمل المكونات الإضافية بشكل جيد مع بعضها البعض ، أو تنفذ كودًا مشابهًا أو تحمل أصولًا مماثلة ، مما يؤدي إلى أداء دون المستوى الأمثل. ومن ثم ، في حين أن إطلاق موقع WordPress سهل نسبيًا ، فإن التحدي الأكبر هو صيانته العامة والقدرة على الحفاظ على الحالة المثلى والأداء عند إضافة ميزات جديدة.

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

"كل ما تحتاجه ، ولا شيء لا تحتاجه."

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

يتضمن October CMS أيضًا بعض الميزات في جوهره والتي (على الرغم من عدم الحاجة إليها دائمًا) يمكنها تحسين التطبيق بشكل كبير. على سبيل المثال ، يوفر دعمًا خارج الصندوق لتحميل ملفات الوسائط إلى Amazon S3 والوصول إليها من خلال Rackspace CDN. يتضمن أيضًا برنامج Media Manager الذي يتم استخدامه غالبًا من خلال المكونات الإضافية ، على سبيل المثال لإضافة الصور إلى منشور مدونة. (يمكن للصفحات أيضًا استخدام Media Manager لتضمين ملفات الوسائط ، ومع ذلك ، فإن CMS يأتي أيضًا مع قسم الأصول لتحميل ملفات الوسائط لهذه التي تبدو أكثر ملاءمة.)

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

لا تنشأ هذه المشكلة فقط فيما يتعلق بسلوك الكيان ولكن أيضًا فيما يتعلق بحقول البيانات التي يجب أن تحتوي عليها. على سبيل المثال ، هل يجب تحديد حقول بيانات مستخدم موقع الويب مسبقًا؟ هل حقل الهاتف مطلوب؟ ماذا عن حقل عنوان URL في Instagram ، مع الأخذ في الاعتبار أن Instagram حصل على نوع من الروعة مؤخرًا فقط؟ ولكن بعد ذلك ، عند إنشاء موقع ويب احترافي ، ألا يجب أن نستخدم حقل URL الخاص بـ LinkedIn بدلاً من ذلك؟ تعتمد هذه القرارات بوضوح على التطبيق ولا يمكن تحديدها من خلال نظام إدارة المحتوى أو المكون الإضافي.

يقوم المكون الإضافي لشهر أكتوبر CMS المسمى User بتنفيذ المستخدمين ولكن بدون أي حقل مستخدم ، ويضيف المكون الإضافي User Plus على رأسه العديد من حقول المستخدم التعسفية ، والتي ربما لا تكون كافية ، لذلك يضيف المكون الإضافي User Plus + حقول مستخدم أخرى. متى وأين وكيف نوقف هذه العملية؟

هناك مشكلة أخرى تتمثل في عدم وجود مجال لإضافة قدرات جديدة إلى كيان ، مما يؤدي إلى إنشاء كيان آخر مشابه للغاية ، فقط لدعم تلك القدرات المطلوبة. على سبيل المثال ، يأتي October CMS مع الصفحات ، ويسمح بإنشاء "صفحات ثابتة" من خلال مكون إضافي. طبيعتها هي نفسها: يتم حفظ كل من الصفحات والصفحات الثابتة كملفات ثابتة. الفرق الوحيد بينهما (بقدر ما أستطيع أن أقول) هو أن الصفحات الثابتة يتم تحريرها باستخدام محرر مرئي بدلاً من محرر HTML ، ويمكن إضافتها إلى القوائم. في رأيي ، يمكن فقط للاختلافات الهيكلية ، مثل وجود كيان واحد محفوظ كملف ثابت والآخر مخزّن في قاعدة البيانات ، أن يبرر إنشاء كيان ثانٍ لصفحة (هناك طلب سحب للقيام بذلك) ، ولكن ببساطة الميزات ، كما هو الحال حاليا ، فإنه يشكل سخام التنمية.

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

انشاء محتوى

يقدم Gutenberg مساهمتين هامتين في WordPress: فهو يستخدم المكونات كوحدة لبناء المواقع (والتي تقدم العديد من المزايا مقارنة بنقاط ترميز HTML) ، ويقدم كيانًا يسمى "block" والذي ، بمجرد اكتمال Gutenberg Phase 2 (يفترض في 2019) ، طريقة موحدة لدمج المحتوى في الموقع ، وبالتالي تمكين تجربة مستخدم أبسط بدلاً من العملية الأكثر فوضوية لإضافة المحتوى من خلال الرموز القصيرة وأزرار TinyMCE والقوائم والأدوات وغيرها.

نظرًا لأن كتل Gutenberg يمكن أن تنتج وتحفظ HTML ثابتًا كجزء من منشور المدونة ، فإن تثبيت العديد من كتل Gutenberg لا يُترجم بالضرورة إلى bloat على موقع الويب من جانب المستخدم ، ولكن يمكن أن يقتصر على الجانب المسؤول. ومن ثم ، يمكن اعتبار Gutenberg طريقة جيدة لإنتاج مواقع الويب بطريقة معيارية ، مع تجربة مستخدم بسيطة لكنها قوية لإنشاء المحتوى. ربما يكون العيب الأكبر هو المطلب (الذي لا مفر منه ، ولكن ليس بهذه السهولة) لتعلم React ، التي يكون منحنى تعلمها حادًا إلى حد ما.

إذا كانت مكونات React هي الوحدة الأساسية لإنشاء المحتوى في WordPress ، فإن October CMS يعتمد على فرضية أن معرفة HTML القديم الجيد يكفي لبناء المواقع. في الواقع ، عند إنشاء صفحة ، نقدم لنا ببساطة محرر HTML (Markup):

إذا كانت الصفحة عبارة عن HTML ثابت فقط ، فلن تكون هناك حاجة إلى CMS. بدلاً من ذلك ، تتم كتابة صفحات أكتوبر CMS باستخدام قوالب Twig التي تم تجميعها إلى كود PHP محسن عادي. يمكنهم تحديد تخطيط لتضمين سقالات الصفحة (مثل العناصر المتكررة ، مثل الرأس والتذييل وما إلى ذلك) ، ويمكنهم تنفيذ العناصر النائبة ، والتي تم تحديدها في التخطيط للسماح للصفحة بتخصيص المحتوى ، ويمكن أن تتضمن الأجزاء ، وهي أجزاء من التعليمات البرمجية يمكن إعادة استخدامها. بالإضافة إلى ذلك ، يمكن أن تتضمن الصفحات كتل المحتوى ، والتي تكون إما ملفات نصية أو ملفات HTML أو Markdown يمكن تحريرها بمفردها ويمكنها إرفاق مكونات هي وظائف يتم تنفيذها من خلال المكونات الإضافية. وأخيرًا ، عندما لا تكون لغة HTML كافية وتحتاج إلى إنتاج كود ديناميكي ، يمكننا إضافة وظائف PHP.

المحرر هو كل شيء عن HTML. لا توجد textarea TinyMCE لإضافة المحتوى بطريقة مرئية - على الأقل ليس من خلال التجربة الافتراضية (هذه الوظيفة تنتمي إلى plugin-land). وبالتالي ، يمكن اعتبار المعرفة بـ HTML أمرًا ضروريًا لاستخدام October CMS. بالإضافة إلى ذلك ، قد تكون المدخلات المختلفة لإنشاء المحتوى (الصفحات والتخطيطات والعناصر النائبة والجزئية وكتل المحتوى والمكونات ووظائف PHP) فعالة للغاية ، ومع ذلك ، فهي بالتأكيد ليست بهذه البساطة من خلال واجهة الكتلة الموحدة من WordPress. يمكن أن يصبح الأمر أكثر تعقيدًا نظرًا لأنه يمكن أيضًا إضافة عناصر أخرى (مثل الصفحات والقوائم الثابتة والمقتطفات) ، ويبدو أن بعضها ، مثل الصفحات والصفحات الثابتة ، يوفر نفس الوظيفة ، مما يجعل من المحير تقرير متى استخدم أحدهما أو الآخر.

نتيجة لذلك ، أجرؤ على القول أنه بينما يمكن لأي شخص استخدام موقع WordPress من جانب المسؤول ، فإن October CMS أكثر ملاءمة للمطورين من كونها غير تقنية سهلة الاستخدام ، لذلك قد يجد المبرمجون متعة في استخدامه ، ولكن البعض الآخر الأدوار (المسوقون ، مندوبو المبيعات ، وما شابه) قد تجدها غير بديهية.

مدير الإعلام

يتم شحن كل من WordPress و October CMS مع Media Manager الذي يسمح بإضافة ملفات الوسائط إلى الموقع دون عناء ، ودعم إضافة ملفات متعددة في وقت واحد من خلال واجهة السحب والإفلات وعرض الصور داخل منطقة المحتوى. هم ينظرون ويتصرفون بشكل مشابه ؛ الاختلافات الملحوظة الوحيدة التي وجدتها هي أن مدير الوسائط في WordPress يسمح بتضمين معارض الصور ، ويسمح Media Manager في أكتوبر بإنشاء بنية مجلد يدويًا حيث يتم وضع الملفات التي تم تحميلها.

منذ تقديم Gutenberg ، على الرغم من ذلك ، تم تحسين إمكانات وسائط WordPress بشكل كبير ، مما يتيح إمكانية تضمين مقاطع الفيديو والصور ومعارض الصور في مكانها مقارنةً بداخل TinyMCE textarea (والذي يوفر فقط نسخة غير دقيقة من الشكل الذي سيبدو عليه في الموقع) ، وإطلاق ميزات قوية وسهلة الاستخدام كما هو موضح في هذا الفيديو.

تدويل

يستخدم WordPress core gettext لتمكين ترجمة السمات والإضافات. بدءًا من ملف .pot يحتوي على جميع السلاسل المراد ترجمتها ، نحتاج إلى إنشاء ملف .po يحتوي على ترجمتها إلى اللغة / اللغة المقابلة ، ثم يتم تجميع هذا الملف إلى ملف .mo ثنائي مناسب لاستخراج الترجمة بسرعة. تتضمن أدوات تنفيذ هذه المهام GlotPress (عبر الإنترنت) و Poedit (تطبيق قابل للتنزيل). بشكل ملائم ، تعمل هذه الآلية أيضًا من أجل الترجمة من جانب العميل لـ Gutenberg.

لا يشحن WordPress حاليًا أي حل جوهري لترجمة المحتوى ، ولن يفعل ذلك حتى المرحلة 4 من Gutenberg (المستهدفة لعام 2020+). حتى ذلك الحين ، يتم توفير هذه الوظيفة من خلال المكونات الإضافية التي تقدم استراتيجيات مختلفة لتخزين وإدارة المحتوى المترجم. على سبيل المثال ، بينما تقوم المكونات الإضافية مثل Polylang و WPML بتخزين كل ترجمة في صفها الخاص من جدول قاعدة بيانات مخصص (وهو نظيف لأنه لا يخلط المحتوى معًا ، ولكنه أبطأ نظرًا لأنه يتطلب رابطًا داخليًا إضافيًا INNER JOIN عند الاستعلام عن قاعدة البيانات) ، يخزن المكون الإضافي qTranslate X جميع الترجمات في نفس الحقل من جدول قاعدة البيانات الأصلي (أسرع للاستعلام عن البيانات ، ولكن المحتوى المختلط معًا يمكن أن ينتج عنه حطام على الموقع في حالة تعطيل المكون الإضافي). وبالتالي ، يمكننا التسوق وتحديد الإستراتيجية الأنسب لاحتياجاتنا.

لا يشحن October CMS الوظائف متعددة اللغات من خلال جوهره ، ولكن كمكوِّن إضافي تم إنشاؤه بواسطة فريق أكتوبر CMS والذي يضمن تكاملًا لا أخطاء فيه في النظام. من وجهة نظر وظيفية ، يقدم هذا البرنامج المساعد ما يعد به. من وجهة نظر التطوير ، ليس من المثالي تمامًا كيفية عمل هذا المكون الإضافي بالفعل. في WordPress ، الصفحة هي مجرد منشور به نوع المنشور "صفحة" وهناك آلية ترجمة واحدة لها ، ولكن في أكتوبر CMS ، هناك كيانات "صفحة" و "صفحة ثابتة" و "منشور مدونة" ، وعلى الرغم من متشابهة تمامًا ، فهي تتطلب ثلاثة تطبيقات مختلفة لترجماتها! بعد ذلك ، يمكن أن يشتمل المحتوى من "صفحة" على رموز رسائل (على سبيل المثال ، أكواد تسمى nav.content و header.title وما إلى ذلك) ، يحتوي كل منها على ترجماته لجميع اللغات ككائن JSON متسلسل في جدول قاعدة البيانات rainlab_translate_messages . يتم إنشاء المحتوى من "صفحة ثابتة" في ملف ثابت جديد لكل لغة ، ومع ذلك ، لا يتم تخزين جميع عناوين URL المترجمة لجميع اللغات في الملف المقابل لها ولكن بدلاً من ذلك في ملف اللغة الافتراضية. يتم تخزين محتوى "منشور المدونة" ككائن JSON متسلسل مع صف واحد لكل لغة في جدول قاعدة البيانات rainlab_translate_attributes ويتم تخزين عنوان URL المترجم بصف واحد لكل لغة في جدول قاعدة البيانات rainlab_translate_indexes . لا أعرف ما إذا كان هذا التعقيد يرجع إلى كيفية تنفيذ المكون الإضافي أو ما إذا كان بسبب بنية أكتوبر CMS. أيًا كان الحال ، فهذه حالة أخرى من الانتفاخ غير المرغوب فيه من جانب التنمية.

إدارة البرنامج المساعد

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

إدارة التبعية

يستخدم October CMS Composer باعتباره مدير الحزم المفضل ، مما يتيح للمكونات الإضافية تنزيل وتثبيت تبعياتها عند التثبيت ، وبالتالي تقديم تجربة غير مؤلمة.

على الجانب الآخر ، لم يعتمد WordPress رسميًا Composer (أو أي مدير تبعية PHP) لأن المجتمع لا يمكنه الموافقة على ما إذا كان WordPress موقعًا أم تبعية للموقع. ومن ثم ، إذا طلبوا Composer لمشاريعهم ، فيجب على المطورين إضافته بأنفسهم. مع التبديل إلى Gutenberg ، أصبح npm مدير التبعية المفضل لـ JavaScript ، مع اعتماد مجموعة أدوات مطور شائعة عليه ، ويتم إصدار مكتبات جانب العميل بشكل مطرد كحزم مستقلة في سجل npm.

التفاعل مع قاعدة البيانات

يوفر WordPress وظائف لاسترداد بيانات قاعدة البيانات (مثل get_posts ) وتخزينها (مثل wp_insert_post و wp_update_post ). عند استرداد البيانات ، يمكننا تمرير المعلمات لتصفية النتائج وتحديدها وترتيبها ، للإشارة إلى ما إذا كان يجب تمرير النتيجة كمثيل لفئة أو كمصفوفة من الخصائص وغيرها. عندما لا تفي الوظيفة بمتطلباتنا بالكامل (على سبيل المثال ، عندما نحتاج إلى إجراء INNER JOIN مع جدول مخصص) ، يمكننا الاستعلام عن قاعدة البيانات مباشرة من خلال المتغير $wpdb . عند إنشاء مكون إضافي بنوع منشور مخصص ، فمن المرجح أن تقوم الشفرة بتنفيذ استعلامات SQL مخصصة لاسترداد و / أو حفظ البيانات في جداول مخصصة. باختصار ، يحاول WordPress توفير الوصول إلى قاعدة البيانات من خلال الوظائف العامة في المرحلة الأولى ، ومن خلال الوصول منخفض المستوى إلى قاعدة البيانات في المرحلة الثانية.

يستخدم October CMS نهجًا مختلفًا: بدلاً من الاتصال بقاعدة البيانات على الفور ، يمكن للتطبيق استخدام Eloquent ORM من Laravel للوصول إلى بيانات قاعدة البيانات ومعالجتها من خلال مثيلات فئات تسمى النماذج ، مما يجعل التفاعل مع قاعدة البيانات يعتمد أيضًا على البرمجة الموجهة للكائنات . إنه وصول عالي المستوى ؛ فقط باتباع القواعد الخاصة بكيفية إنشاء الجداول وإقامة العلاقات بين الكيانات ، يمكن للمكوِّن الإضافي استرداد و / أو حفظ البيانات دون كتابة سطر من SQL. على سبيل المثال ، يسترد الكود أدناه كائنًا من قاعدة البيانات من خلال نموذج Flight ، ويعدل خاصية ويخزنها مرة أخرى:

 $flight = Flight::find(1); $flight->name = 'Darwin to Adelaide'; $flight->save();

ترقية نموذج البيانات

سبب آخر لنجاح WordPress (بالإضافة إلى عدم كسر التوافق مع الإصدارات السابقة) هو بنية قاعدة البيانات الخاصة به ، والتي تم تصميمها لتمكين التطبيقات من النمو بمرور الوقت. يتم تحقيق هذا الهدف من خلال خصائص "التعريف" ، أي الخصائص التي يمكن إضافتها بشكل غير محكم إلى كائن قاعدة البيانات في أي لحظة. لا يتم تخزين هذه الخصائص في عمود من جدول الكيان المقابل (إما wp_posts أو wp_users أو wp_comments أو wp_terms ) ، ولكن بدلاً من ذلك كصف في جدول "التعريف" المقابل ( wp_postmeta أو wp_usermeta أو wp_commentmeta أو wp_termmeta ) ويتم استردادها باستخدام INNER JOIN . وبالتالي ، على الرغم من أن استرداد قيم التعريف هذه يكون أبطأ ، إلا أنها توفر مرونة غير محدودة ، ونادرًا ما يحتاج نموذج بيانات التطبيق إلى إعادة هندسته من البداية من أجل تنفيذ بعض الوظائف الجديدة.

لا يستخدم October CMS الخصائص الوصفية ولكن بدلاً من ذلك يمكنه تخزين عدة قيم عشوائية ، والتي لم يتم تعيينها مباشرة كأعمدة في جداول قاعدة البيانات ، ككائن JSON متسلسل. Otherwise, when an object needs some new property, we need to add a new column on the corresponding table (which is the reason behind plugins User Plus and User Plus+, mentioned earlier on). To update the application's database schema, October CMS relies on Laravel's Migrations, which are sets of instructions to execute against the schema (such as add or drop a column, rename an index, etc) and which are executed when upgrading the software (eg when installing a plugin's new version).

Headless Capabilities

Both WordPress and October CMS can be used as headless, ie treating the CMS as a content management system that makes content accessible through APIs, which allows to render the website on the client-side and can power other applications (such as mobile apps). Indeed, WordPress is steadily heading towards headless, since the Gutenberg content editor itself treats WordPress as a headless CMS (and, as a consequence, Gutenberg can also work with any other CMS too, as Drupal Gutenberg demonstrates).

A headless system needs to implement some API to return the data, such as REST and GraphQL. WordPress supports REST through WP REST API (merged in core), exposing endpoints under some predefined route /wp-json/wp/v2/... ; October CMS supports REST through plugins RESTful and API Generator, which allow to create custom endpoints and, as a consequence, support versioning as part of the endpoint URL and can offer a better security against bots. Concerning GraphQL, WordPress supports it through WPGraphQL, while October CMS currently has no implementations for it.

Quite importantly, a headless system needs to offer powerful content management capabilities. As mentioned earlier on, WordPress has a very solid database architecture, offering a plethora of data entities (users, posts and custom posts, pages, categories, tags and custom taxonomies, comments) over which the application can be reasonably well modelled, meta properties to extend these data entities (enabling the application to upgrade its data model accordingly and without major changes), and with plugin Advanced Custom Fields filling the gap to construct relationships among the data entities. In addition, plugin VersionPress allows to version control the database content using Git. Hence, WordPress is undoubtedly a good fit for managing content, as demonstrated in several projects in the wild.

On its part, and as mentioned earlier on, October CMS can omit the database and behave as a flat-file system, or it can have a database and behave as a hybrid, storing the content from pages as static files and blog posts (and others) on the database. As a consequence, content is not centralized, and its management involves a different approach. For instance, while we can use Git to version control pages, there is no support to version control the database per se; the solution to this is to populate data into the database through Seeders which, being code, can be put under version control and executed upon deployment. In addition, October CMS doesn't offer a baked-in database model featuring predefined data entities that can support the needs of most applications. Hence, more likely than not the application will need custom development to implement its data model, which means more work, but also means that it can be more efficient (eg accessing a property from a column is faster than from a row in another table through an INNER JOIN , which is the case with WordPress' meta properties).

CLI Support

Both WordPress and October CMS can be interacted with from the console through a Command Line Interface (CLI): WordPress through WP-CLI and October CMS through Laravel's Artisan. In addition to Laravel's commands, October CMS implements several custom commands for updating the system, migrating the database, and others. These tools make it very convenient to access the site from outside a browser, for instance for testing purposes.

Managed Hosting

It is not a problem finding a managed hosting provider for a WordPress site: given WordPress' market share, there are dozens (if not hundreds) of providers out there vying with each other for the business, constituting a very dynamic market. The only problem is finding the most suitable provider for our specific sites based on all of their offerings, which can vary based on price, quality, type (shared or dedicated services), bandwidth and storage size, customer support, location, frequency of renewal of equipment, and other variables which we can navigate mainly through reviews comparing them (such as this one, this one or this one).

Even though nothing near as many as WordPress, October CMS still enjoys the offering from several hosting providers, which allows for some consideration and selection. Many of them are listed as October Partners, and several others are found DuckDuckGoing, but since I haven't found any independent review of them or article comparing them, the task of finding out the most suitable one will take some effort.

Marketplace, Ecosystem And Cost

WordPress' commercial ecosystem is estimated to be USD $10 billion/year, evidencing how many people and companies have managed to make a living by offering WordPress products and services, such as the creation of sites, hosting, theme and plugin development, support, security, and others. Indeed, its size is so big it is even bloated, meaning that it is very common to find different plugins solving the same problem, plugins that underdeliver, underperform or have not been updated for years, and themes which seem to look-alike each other. However, when creating a new site, the size and variety of the ecosystem also means that we will most likely find at least one plugin implementing each of the required functionalities, enabling us to save money by not having to develop the functionality ourselves, and the availability of customizable themes enables to produce a reasonably distinctive-looking site with minimal effort. As a consequence, we can easily create and launch a WordPress site for less than USD $100, making WordPress a sensible option for projects of any budget.

Being relatively new (only five years so far), OctoberCMS certainly doesn't enjoy anything near WordPress' marketplace and ecosystem sizes, however, it has been growing steadily so its size is bound to become bigger. Currently, its marketplace boasts 600+ plugins, and only a handful of themes. Concerning plugins, the October CMS team is requesting the community to put their effort into the creation of original plugins, delivering functionality not yet provided by any other plugin.

Hence, even though 600+ plugins doesn't sound like much, at least these translate into 600+ different functionalities. This way, even though it is not possible to choose among several vendors, at least we can expect to have those basic website features (such as blogging, comments, forum, integration with social media, e-commerce, and others) to be covered. Also, since October's founders are personally reviewing all submitted plugins and judging them according to quality guidelines, we can expect these plugins to perform as expected. As another plus, October plugins can incorporate elements from Laravel packages (even though not all of them are compatible with October, at least not without some hacks). Concerning themes, the low number of offerings implies we will most likely need to develop our own theme by hiring a developer for the task. In fact, I dare say that the theme in October CMS will most likely be a custom development, since themes and plugins are not thoroughly decoupled (as explained earlier), with the consequence that a market for easily-swappable themes is more difficult to arise. (This is a temporary problem though: once this pull request is resolved, pages will be able to be stored in the database, and swapping themes should not disrupt functionality.)

In my opinion, because of the smaller offerings of themes and plugins, creating a simple site with OctoberCMS will be more expensive than creating a simple WordPress site. For complex sites, however, October's better architecture (Object-Oriented Programming and Model-View-Controller paradigms) makes the software more maintainable and, as a consequence, potentially cheaper.

تواصل اجتماعي

Being a part of and having access, WordPress' community represents one of the most compelling reasons for using WordPress. This is not simply as a matter of size (powering nearly one third of all websites in the world, there are so many stakeholders involved with WordPress, and its community is representatively big) but also as a matter of diversity. The WordPress community involves people from many different professions (developers, marketers, designers, bloggers, sales people, and so on), from all continents and countries, speaking countless languages, from different social, educational and economic backgrounds, with or without disabilities, from corporate, not-for-profit and governmental organizations, and others. Hence, it is quite likely that, for whatever problem we encounter, somebody will be able to help on any of the support forums. And contributing to WordPress is pretty straightforward too: The Make WordPress group congregates stakeholders interested in supporting different projects (accessibility, design, internationalization, and many others) and organizes how and how regularly they communicate — mostly through some dedicated channel on its Slack workspace.

Furthermore, the WordPress community is real and tangible: it doesn't exist just online, but it gathers offline in WordCamps and meetups all over the world; in 2018, there were a total of 145 WordCamps in 48 countries with over 45,000 tickets sold, and a total of 5,400 meetup events from 687 meetup groups. Hence, it is likely that there is a local chapter nearby which anyone can join to ask for help, learn how to use the platform, keep learning on a regular basis, and teach others as well. In this sense, WordPress is not just a CMS but, more importantly, it's also people, and considering to leave WordPress should never be done only on its technical merits but on the power of its community, too.

October CMS' community is nothing near in size or diversity as WordPress', even though it has been growing steadily following the increasing popularity of the software. October provides a support forum to ask for help, however, it is not very active. A Slack workspace exists which is pretty active and where, quite importantly, October's founders participate regularly, helping make sure that all enquiries are properly addressed. This channel is a great source for learning low-level tips and tricks about the software, however, it is geared towards developers mainly: There are no channels concerning accessibility, design, internationalization, and other topics as in the WordPress community, at least not yet. Currently, there are no conferences concerning October CMS, but there is Laracon, the conference for the Laravel community.

Maintainers And Governance

Can we trust that the software will be maintained in the long term, so that if we decide to start a project today, we will not need to migrate to some other platform down the road? How many people are taking care of developing the software? And who is deciding in what direction the software moves towards?

يعمل WordPress على تشغيل ثلث جميع المواقع في العالم ، ولا ينقصه عدد من أصحاب المصلحة الذين يساهمون في البرنامج ؛ وبالتالي لا داعي للخوف من أن البرنامج سوف يقع في الاضمحلال. ومع ذلك ، يخضع WordPress لمداولات داخلية تتعلق بنموذج الحوكمة الخاص به ، حيث أعرب العديد من أعضاء المجتمع عن أن القرارات المتعلقة بتوجيه WordPress يتم اتخاذها من جانب واحد بواسطة Automattic ، الشركة التي تدير WordPress.com. كانت المرحلة المركزية لهذا التصور هي قرار إطلاق Gutenberg ، والذي اختلف معه العديد من الأعضاء ، والذي عانى من نقص في التواصل المناسب من قبل قيادات المشروع أثناء تطويره وإطلاقه. نتيجة لذلك ، يتساءل العديد من أعضاء المجتمع عن دور "الديكتاتور الحميد" ، والذي تم منحه تاريخيًا لمؤسس WordPress والرئيس التنفيذي لشركة Automattic Matt Mullenweg ، ويبحثون في نماذج حوكمة مختلفة للعثور على نموذج أكثر ملاءمة لمستقبل WordPress. لم يتضح بعد ما إذا كانت هذه المهمة تؤدي إلى أي نتيجة ، أو ما إذا كان الوضع الراهن مستمرًا.

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

توثيق

توثيق WordPress في موقعه الخاص ليس شاملاً للغاية ، لكنه يؤدي المهمة بشكل معقول. ومع ذلك ، عند أخذ جميع الوثائق حول WordPress في الاعتبار من جميع المصادر ، مثل المواقع العامة (مجلة Smashing و CSS وغيرها الكثير) والمواقع المتخصصة (WPShout و WPBeginner وغيرها الكثير) والمدونات الشخصية والدورات التدريبية عبر الإنترنت ، وهكذا ، لا يوجد عمليًا أي جانب من جوانب التعامل مع WordPress لم يتم تغطيته بالفعل.

لا يتمتع October CMS بأي شيء بالقرب من العديد من الدورات التدريبية أو البرامج التعليمية أو منشورات المدونات التابعة لجهات خارجية مثلما يفعل WordPress ، ومع ذلك ، فإن التوثيق على موقعه شامل إلى حد معقول ويكفي بالتأكيد لبدء الترميز. يقوم مؤسسو أكتوبر أيضًا بإضافة وثائق جديدة بانتظام من خلال البرامج التعليمية. أحد الجوانب التي استمتعت بها شخصيًا هو تكرار توثيق Laravel في وثائق أكتوبر لكل ما له صلة بالموضوع ، لذلك يجب على القارئ ألا يملأ الفجوات بنفسه / بنفسها ويضطر إلى تخمين مجال أكتوبر وما هو مجال Laravel. ومع ذلك ، هذا ليس مثاليًا بنسبة 100٪. تستخدم وثائق أكتوبر المصطلحات التي نشأت من Laravel ، مثل البرمجيات الوسيطة وحاويات الخدمة والواجهات والعقود ، دون شرح كافٍ لها. بعد ذلك ، يمكن أن تكون قراءة وثائق Laravel مسبقًا مفيدة (لحسن الحظ ، وثائق Laravel شاملة بالتأكيد ، وتسجيلات Laravel ، Laracasts هي مصدر كبير آخر للتعلم ، ليس فقط فيما يتعلق بـ Laravel ولكن تطوير الويب بشكل عام).

خاتمة

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

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

من الناحية الشخصية ، بصفتي مطورًا ، فإن ما وجدته في أكتوبر CMS جذاب حقًا بالنسبة لي ، في الغالب قدرته على إنشاء تطبيقات معيارية على النحو المنصوص عليه من خلال Laravel. بالتأكيد سأعتبر هذا CMS لموقع ويب جديد. ومع ذلك ، أثناء كتابة هذا المقال ، قمت أيضًا "بإعادة اكتشاف" WordPress. نظرًا لكون WordPress شائعًا جدًا ، فقد تلقى أكثر من نصيبه العادل من الانتقادات ، خاصة فيما يتعلق بقاعدة الكود القديمة ، ومنذ وقت قريب ، تقديم Gutenberg ؛ ومع ذلك ، يحتوي WordPress أيضًا على بعض الميزات الممتازة (مثل نموذج قاعدة البيانات القابلة للتطوير الفائق) والتي نادرًا ما يتم الإشادة بها ولكن يجب أخذها في الاعتبار أيضًا. والأهم من ذلك ، لا ينبغي النظر إلى WordPress من حيث جوانبه التقنية وحدها: على وجه الخصوص ، فإن حجم مجتمعه ونظامه البيئي يضعه في مستوى أو مستويين أعلى من بدائله. باختصار ، قد تستفيد بعض المشاريع من التمسك بـ WordPress ، بينما قد يعتمد البعض الآخر بشكل أفضل على October CMS أو نظام أساسي آخر.

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

مزيد من القراءة على SmashingMag:

• التخزين المؤقت بذكاء في عصر جوتنبرج
• تحسين كود WordPress باستخدام PHP الحديث
• الدروس المستفادة أثناء تطوير ملحقات WordPress
• كيفية استخدام الخرائط الحرارية لتتبع النقرات على موقع WordPress الخاص بك
• انتبه: وظائف PHP و WordPress التي يمكن أن تجعل موقعك غير آمن