10 نصائح لجعل صيانة WordPress سلسة

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

لماذا مسائل صيانة ووردبريس المناسبة

في معظم الأحيان ، لا تعد مواقع الويب مسألة "تعيين مرة واحدة وتركها بمفردها" ، وهذا ينطبق على جميع المواقع ، وليس فقط مواقع WordPress. من وقت لآخر ، سيتعين عليك التعامل مع التعديلات أو التحديثات أو إصلاحات الأخطاء ، والتي سيتولى مطور go-to المفضل لديك الاهتمام بها. ومع ذلك ، في بعض الحالات ، قد تحتاج إلى الاعتماد على عدد من المطورين المختلفين طوال عمر موقع الويب الخاص بك.

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

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

1. النسخ الاحتياطي!

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

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

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

2. قم بتثبيت موقع WordPress الخاص بك محليًا

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

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

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

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

3. اذهب جيت

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

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

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

ناهيك عن أنك لا "تنجح" في الواقع إذا لم تستخدم الفروع! قم بإنشاء فرعين على الأقل للتطوير والإنتاج حتى يتمكن المطورون من القيام بكل الأعمال في فرع التطوير ، واختبار الموقع ، ثم إذا كان كل شيء على ما يرام ، فانتقل إلى فرع الإنتاج مع التأكد من عدم حدوث أي خطأ في الموقع المباشر.

4. قم بإزالة الملفات والرموز والمكونات الإضافية غير الضرورية

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

يمكن القضاء على هذا عن طريق إزالة الملفات غير المرغوب فيها على الفور من قبل المطور المقابل الذي عمل عليها. يمكنك التأكيد على هذه الممارسة لجميع مطوريك.

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

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

5. التعليق

ربما تكون على دراية بميم البرمجة الذي يتعامل مع شيء من هذا القبيل: عندما تمت كتابة الكود ، فقد فهمه المؤلف الذي كتبه وزملاء العمل والله. بعد مرور بعض الوقت ، عرف المؤلف والله فقط ما يفعله ، والآن يعلم الله وحده ما يفعله - ما لم يضيف المؤلف تعليقات مناسبة!

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

يجب إضافة التعليقات عندما لا تكون الوظيفة / الفئة أو كتلة التعليمات البرمجية شيئًا واضحًا ، خذ الوظيفة التالية على سبيل المثال:

 function stripWhiteSapaces(str) { … Return str; }

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

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

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

6. Linting

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

على سبيل المثال ، عند استخدام Visual Studio Code باعتباره IDE الخاص بك ، فإن VS Code يستخدم PHP linter ( php -l ) لتشخيصات لغة PHP. يمكنك تكوين القواعد / القيود لكل لغة على حدة (مثل PHP و JavaScript و CSS وما إلى ذلك). يمكنك إلقاء نظرة على معايير ترميز WordPress لمزيد من التفاصيل.

• https://make.wordpress.org/core/handbook/best-practices/coding-standards/php/
• https://make.wordpress.org/core/handbook/best-practices/coding-standards/javascript/

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

7. المتغير وتسمية الملف

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

ضع في اعتبارك بعض النقاط الحيوية:

1. تجنب الأسماء الواضحة
2. اجعلها قصيرة عندما يكون ذلك ممكنا
3. أحيانًا يكون من المفيد حقًا إلحاق "النوع" باسم الملف. على سبيل المثال ، إذا كان رمزًا ، فيمكنك الحصول على شيء مثل BlackArrowIcon.png أو إذا كانت صورة خلفية كبيرة يمكن أن تكون شيئًا مثل FrontYellowBG.jpg. أو إذا كان ملفًا برمجيًا ، فمن السهل أحيانًا معرفة ما يمثله هذا الملف عند العمل مع ملفات متعددة مفتوحة في علامات تبويب مختلفة في IDE. على سبيل المثال ، إذا كانت هناك فئة بها وظائف مساعدة ، فسيكون من المفيد أن تسمي HelperClass.php بدلاً من Helper.php.

لمزيد من المعلومات ، راجع قسم اصطلاحات التسمية في دليل أفضل ممارسات WordPress.

8. تصحيح أخطاء الووردبريس

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

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

• Kint Debugger
• شريط التصحيح
• مراقبة الاستعلام

9. لديك CSS أفضل

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

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

فيما يلي بعض النصائح السريعة من جانبي دون تفاصيل كثيرة:

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

10. احصل على تعليقات من المطورين الحاليين

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