كيفية التعامل مع تطوير WordPress الحديث (الجزء الأول)

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

فلماذا نهتم بجودة الكود في نواة WordPress؟ إنه يعمل ، أليس كذلك؟

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

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

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

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

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

هذا ليس شيئًا سيئًا ، في حد ذاته - حقيقة أن بعض الحلول بهذه البساطة هي سبب شهرة WordPress. لكن في هذه السلسلة سأتحدث عن تطوير WordPress حقيقي : كتابة كود PHP و HTML و CSS و JavaScript. سأبدأ بسير العمل العام ثم أركز على تطوير الواجهة الأمامية لـ WordPress في هذه المقالة.

سير عمل تطوير WordPress الحديث

بشكل عام ، كود الجودة هو:

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

النتائج الرئيسية - انخفاض تكلفة التطوير والملكية - لها العديد من الفوائد العرضية التي لن أتناولها هنا.

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

استخدم التحكم في الإصدار

هذا يعني استخدام Git. للأسف ، "تشفير رعاة البقر" على الإنتاج عبر بروتوكول نقل الملفات لا يزال إلى حد كبير شيئًا. لقد عملت مؤخرًا في وكالة مقرها المملكة المتحدة وكان لديهم ملفات بأسماء مثل هذه في جميع أنحاء قاعدة بياناتهم البرمجية:

• functions copy.php
• functions copy 2.php
• functions test.php
• functions2.php
• functions test2.php

أول شيء يجب عليك فعله عند استخدام موقع WordPress هو وضعه تحت التحكم في الإصدار. تعد Tanking Servers بمثابة عرض رجعي ممتع لأخطاء تطوير WordPress. كان من السهل جدًا تعديل هذه الحوادث - وحوادث مماثلة ربما حدثت للجميع - باستخدام Git.

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

احذر من تعريض المجلد .git

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

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

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

 RedirectMatch 404 /\.git RedirectMatch 404 ^.*\.log

استخدم بيئات منفصلة

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

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

على سبيل المثال ، يمكن تخزين التكوين الخاص بالخادم في ملف منفصل. يمكنك إنشاء ملف wp-config-local.php لكل بيئة محلية ومرحلة. (لا تنس إضافته إلى ملف .gitignore الخاص بك!) ثم أضف المقتطف التالي إلى wp-config.php :

 if (file_exists(dirname(__FILE__) . '/wp-config-local.php')) : // use local settings require_once(dirname(__FILE__) . '/wp-config-local.php'); else : // production settings endif;

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

استخدم WP-CLI

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

مثال آخر هو أن النشر الأولي سهل للغاية مع WP-CLI. يمكن تحقيق ذلك بأوامر قليلة:

• تنزيل الأساسي والموضوعات والإضافات
• البحث والاستبدال في قاعدة البيانات
• إضافة مستخدم إداري

علاوة على ذلك ، يمكن كتابة هذه الإجراءات وأتمتتها.

استخدم خيارات النشر المتقدمة

عند الحديث عن الأتمتة ، يجدر تعلم بعض تقنيات وعمليات النشر مثل:

• التكامل المستمر / النشر المستمر / التسليم (CI / CD)
• عامل ميناء
• الاختبار الآلي (بما في ذلك اختبارات الانحدار الأمامية)

من المؤكد أن الانتقال من عدم استخدام التحكم في الإصدار إلى التعامل مع Docker يعد قفزة هائلة لتحقيقها ومن المحتمل أن تكون مربكة لمشروع WordPress النموذجي لشخص واحد. قد لا تكون بعض الخيارات ممكنة حسب مزود الاستضافة الخاص بك. لكن النشر المتقدم أمر لا بد منه للفرق وللمشاريع الأكبر.

استخدم Linting

بالنسبة للمشاريع من أي حجم ، فإن الفحص هو نعمة لمعظم المطورين. الفحص يعني التحقق تلقائيًا من التعليمات البرمجية الخاصة بك بحثًا عن الأخطاء. IDE كامل الميزات مثل PHPStorm يفعل ذلك بالفعل خارج الصندوق ؛ ومع ذلك ، تحتاج برامج التحرير الأبسط مثل VSCode أو Sublime Text إلى برنامج مخصص يسمى linter. طريقة واحدة لإعداد هذا هو تكوين المحرر الخاص بك لتشغيل linter كلما قمت بحفظ ملف.

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

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

تتمثل إحدى حالات الاستخدام القوية هنا في دمج الفحص في خط أنابيب إنشاء CI / CD بحيث يتم التحقق من صحة جميع التعليمات البرمجية تلقائيًا قبل نشرها.

تقنيات تطوير واجهات WordPress الحديثة

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

استخدم الأدوات الحديثة: Sass و ES6 +

إن عالم التطوير الأمامي متغير باستمرار ودائمًا في حالة حركة. بمجرد أن اعتقدنا أن Sass كانت أفضل أداة لكتابة CSS - ولتطوير ما قبل Gutenberg WordPress ، فإنها لا تزال كذلك - ولكن بعد ذلك بدأ الجميع يتحدثون عن CSS-in-JS والمكونات المصممة.

حتى WordPress لم يستطع المقاومة والتقط عددًا قليلاً من تلك التقنيات الجديدة. تم بناء Gutenberg ، محرر الكتلة الجديد ، على React وواجهة برمجة تطبيقات REST.

يجب عليك بالتأكيد الحصول على السرعة مع هذه التقنيات الأمامية الأساسية:

• ES6 +. تسميها وثائق WordPress ESNext وتشجع حتى على استخدامها.
• ساس. يستخدمه WooCommerce وأفضل طريقة لكتابة CSS إذا لم تكن مهتمًا بشيء CSS-in-JS حتى الآن.
• حزمة الويب. حتى نواة WordPress تستخدم Webpack و Babel الآن.

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

الانتقال من jQuery إلى Vue.js أو React

تعتمد نواة WordPress وتقريبًا جميع مكونات WordPress الإضافية على jQuery ، لذلك لا يمكنك التوقف عن استخدامها. في الواقع ، ليس من المنطقي التوقف عن استخدامه لمهام بسيطة مثل إخفاء بضع <div> أو إجراء طلب AJAX لمرة واحدة عندما تكون معتادًا على القيام بذلك بهذه الطريقة. سيتم تحميل jQuery على أي حال ، وهو بسيط وسهل الاستخدام.

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

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

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

هناك مكتبتان شائعتان في الوقت الحالي: Vue.js و React. سيكون React خيارًا واضحًا لأنه مستخدم بالفعل بواسطة Gutenberg. ومع ذلك ، بالنسبة لشخص جديد على JavaScript الحديث ، قد يكون من الأفضل أن تبدأ Vue.js.

تلقي بك React في النهاية العميقة باستخدام ميزات ES6 ، والفئات ، وبناء جملة JSX الخاص ، وخط أنابيب بناء Webpack على الفور. منحنى التعلم شديد الانحدار.

من ناحية أخرى ، يعد Vue.js أكثر ملاءمة للمبتدئين ، ويمكن استخدامه بمجرد وضع علامة <script> . يستخدم Vue.js جافا سكريبت عادي (ES5) و HTML و CSS. مقدمة للمفاهيم الجديدة أكثر تدريجيًا.

بعد العمل على عدد قليل من مشاريع Vue.js ، ستكون مستعدًا بشكل أفضل للتعمق في React. لا يعني ذلك دائمًا أنها مطلوبة ، ولكن تطوير Gutenberg ، على سبيل المثال ، يتطلب ذلك.

استخدم WordPress REST API

WordPress 'REST API هي مجرد واجهة قياسية لطلب البيانات وتعديلها عن بُعد من WordPress. إنه شيء يتعلق بهندسة البرامج أكثر من كونه طريقة مختلفة تمامًا للترميز. يمكن استخدام مقتطفات jQuery AJAX القديمة نفسها مع معلمات مختلفة قليلاً.

اهم فائدة؟ نظرًا لأن WordPress REST API يوحّد الاتصال بين الواجهة الخلفية والواجهة الأمامية ، فهي خطوة رئيسية نحو نمطية وقابلية إعادة الاستخدام وقابلية القراءة في التعليمات البرمجية الخاصة بك. هذه القوالب الرهيبة مع HTML و PHP مختلطة معًا وبعض SQL التي تم طرحها في المزيج يجب أن تذهب. بمجرد أن تكون القوالب عبارة عن HTML فقط مع عناصر نائبة للبيانات التي تم تمريرها كمعلمات ، فلا يوجد فرق كبير بين تمرير تلك البيانات في PHP أو عبر واجهة برمجة تطبيقات REST إلى تطبيق الواجهة الأمامية.

قد ترغب أيضًا في البحث في WPGraphQL. قد تحل أو لا تحل محل WordPress REST API ، لكنها تكتسب قوة دفع سريعة.

تعلم جوتنبرج (سيطلبها العملاء قريبًا)

الهدف النهائي من Gutenberg هو التخصيص الكامل للموقع ، من بين خطط أخرى.

يضع هذا الأساس لنموذج جديد لـ WordPress Core سيؤثر في النهاية على تجربة النشر الكاملة للمنصة.

صفحة مشروع WordPress Gutenberg على GitHub

تلقى Gutenberg معارضة كبيرة من مطوري WordPress. بعض الحجج ضد دمجها في WordPress الأساسية كانت:

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

ومع ذلك ، بالنسبة لكتاب المحتوى الذين يستخدمون WordPress كمنصة تدوين ، من الواضح أن Gutenberg يوفر تجربة أفضل من المحرر القديم.

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

حان الوقت للحصول على السرعة: حتى "طريقة WordPress" تتطور

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

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

لبعض الوقت ، كان WordPress و WooCommerce يتبعان ممارسة تطوير "المكونات الإضافية للميزات" التي تنفذ وتستخدم التقنيات الجديدة. عندما يحين الوقت ، يتم دمج هذه المكونات الإضافية في النواة ، كما فعل جوتنبرج. تمتلك WooCommerce أيضًا مشروع React الخاص بها. بدأت واجهة برمجة تطبيقات WordPress REST أيضًا كمكوِّن إضافي منفصل وهي الآن جزء من نواة WordPress.

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

على سبيل المثال ، تعرف على كيفية استخدام Webpack مع جميع البرامج النصية القديمة. يمكن لـ Webpack تحويل كود ES6 + الجديد إلى JavaScript "عادي" متوافق مع المتصفحات القديمة. يمكنه أيضًا تصغير البرامج النصية وتجميعها معًا. هذا شيء جديد. منجز؟ ثم أعد كتابة JavaScript بالاستفادة من ميزات ES6. إنها طريقة جديدة لفعل ما تعرفه جيدًا.

النتيجة: ستتعلم Webpack و ES6. كمحترفين ، يجب أن نتقدم ولا نتراجع. استمر في التعلم دائمًا. وشارك عندما تفعل ذلك: تحتفظ Toptal بقائمة بأفضل ممارسات تطوير WordPress وترحب بمساهمات المجتمع فيها.

في الجزء الثاني من سلسلتنا ، سنتعمق في جزء PHP من تطوير WordPress للواجهة الخلفية الحديثة.