كيفية تجنب أخطاء تطوير موضوع ووردبريس الشائعة

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

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

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

1. استخدام عناوين URL المطلقة في القوالب

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

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

يحتوي WordPress على طرق مضمنة لتحديد عنوان URL الصحيح - تم سحبه مباشرة من Settings > General في لوحة المعلومات.

بالنسبة للارتباط ، فإن تكرار esc_url( home_url() ) سيوفر مسارًا كاملاً إلى الصفحة الرئيسية. لذلك ، بدلاً من وضع عنوان URL بشكل صريح في شفرتك ، يمكنك إضافة رابط بسيط إلى صفحتك الرئيسية كما يلي:

 <a href="<?php echo esc_url( home_url() ); ?>" />Home</a>

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

 <a href="<?php echo esc_url( home_url() ); ?>/about-us/" />About Us</a>

يعمل مقتطف مشابه أيضًا مع الصور. يسحب هذا المثال صورة من موضوعنا النشط /images/ المجلد الفرعي:

 <img src="<?php echo esc_url( get_stylesheet_directory_uri() ) ; ?>/images/hello.png" />

2. إضافة البرامج النصية والأنماط مباشرة إلى قالب

يعد استخدام البرامج النصية والأنماط التابعة لجهات خارجية مع WordPress عالمًا خاصًا به. عندما تبدأ في إنشاء السمات لأول مرة ، قد تميل إلى وضع علامات <script> أو <style> ، أو حتى رمز تضمين Google Font مباشرة في رأس القالب الخاص بك. هذه هي الطريقة التي تتم بها الأمور بشكل عام مع مواقع HTML الثابتة ، لذا فمن المنطقي أن تفعل الشيء نفسه هنا.

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

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

3. استدعاء مثيلات خارجية لـ jQuery

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

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

والحق يقال ، ليس من الصعب للغاية تنفيذ عنصر jQuery UI المطلوب. على سبيل المثال ، لتمكين استخدام علامات تبويب jQuery UI ، ما عليك سوى إضافة المقتطف التالي إلى functions.php :

 function my_jquery_elements() { wp_enqueue_script( 'jquery-ui-tabs', array('jquery')); add_action( 'template_redirect', my_jquery_elements ', 10 );

هذا يخبر WordPress بالتحميل في العنصر من مكتبته الموجودة بالفعل. من هناك ، صمم علامات التبويب الخاصة بك وحددها كما هو محدد في وثائق jQuery UI.

4. أخذ التخصيص بعيدًا جدًا

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

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

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

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

5. عدم كتابة رمز التعليق

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

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

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

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

تقنيات أفضل بمرور الوقت

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

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

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

الدرس هو أننا جميعًا سنرتكب أخطاء. لكن كل واحد يمنحنا فرصة للتعلم والتحسين.