9 أخطاء يجب تجنبها عند تطوير قوالب ووردبريس الإضافية

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

الخطأ الأول: التضحية بالجودة لصالح الحلول السريعة

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

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

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

سيؤدي تطوير رمز نظيف وجيد الكتابة ومحسّن إلى زيادة وقت التطوير بنسبة 10-30٪ ، ولكنه بالتأكيد يستحق ذلك على المدى الطويل. في نهاية اليوم ، ستحصل على مكون إضافي أو سمة قابلة للصيانة وذات أداء جيد وعملي.

الخطأ الثاني: الإخفاق في تتبع تغييرات الكود

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

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

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

الخطأ الثالث: عدم استخدام مساحات الأسماء

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

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

namespace Geometry;

class Circle {
    private $radius;

    public circle($r) {
        $radius = $r;
    }

    public get_radius() {
        return $radius;
    }
   
    public get_area() {
        return pi() * $radius * $radius;
    }
}

الخطأ الرابع: عدم استخدام WordPress nonces

إن اتباع ممارسات الأمان الحديثة لا يقل أهمية عن ضمان وظائف المكون الإضافي أو السمة الخاصة بك. يستخدم WordPress الرموز غير الرسمية لتوفير مستوى معين من الحماية للتحقق من صحة الطلبات. تعد Nonces مفيدة بشكل خاص في منع هجمات Cross-Site Request Forgery (CSRF).

لإنشاء nonce ، استخدم الوظيفة التالية.

$nonce= wp_create_nonce( 'name');

تحقق من مرجع رمز WordPress هذا إذا لم تكن على دراية بـ nonces.

اشترك واحصل على نسخة مجانية من موقعنا

WordPress البرنامج المساعد كتاب الأعمال

بالضبط كيفية إنشاء عمل إضافي لبرنامج WordPress مزدهر في اقتصاد الاشتراك.

شارك مع صديق

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

شكرا لك للمشاركة

رائع - تم إرسال نسخة من "The WordPress Plugin Business Book" إلى . هل تريد مساعدتنا في نشر الكلمة أكثر؟ استمر وشارك الكتاب مع أصدقائك وزملائك.

شكرا على الإشتراك!

- لقد أرسلنا نسختك من "The WordPress Plugin Business Book" إلى .

شارك مع صديق إعادة إرسال البريد الإلكتروني

هل لديك خطأ مطبعي في بريدك الإلكتروني؟ انقر هنا لتعديل عنوان البريد الإلكتروني وإرساله مرة أخرى.

تحميل

الخطأ الخامس: عدم استخدام وظائف WordPress الأساسية

يفشل العديد من المطورين في الاستفادة من الإمكانات الكاملة لوظائف WordPress الأساسية الحالية. تحتوي بعض السمات والإضافات على ملفات تتوافق مع ملفات WordPress الأساسية ، مثل Color Pickers و jQuery.

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

من خلال استخدام ما يقدمه WordPress ، يمكنك إنشاء المزيد من السمات أو المكونات الإضافية خفيفة الوزن وعملية.

الخطأ السادس: إدراج ملفات JavaScript و CSS في قائمة الانتظار

يعد إدراج ملفات JavaScript و CSS في قائمة عند عدم الحاجة إليها خطأ شائعًا آخر. يمكن أن يؤدي ذلك إلى إبطاء وقت التحميل وترتيب محرك البحث المرفوض حيث يضيف كل ملف مدرج في قائمة الانتظار طلب HTTP إضافيًا.

الخطأ رقم 7: وضع كود JavaScript في ملف رئيسي واحد لسمات التقدم

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

ثانيًا ، سيؤدي إنشاء ملف واحد إلى زيادة صعوبة إدارة الكود. على سبيل المثال ، لن تتمكن من وضع وظائف ، مثل wp_dequeue_script () لإلغاء تحميل التعليمات البرمجية في بعض الصفحات من أجل تحسين السرعة.

إليك مقطع فيديو يشرح قليلاً عن هذا الموضوع:

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

الخطأ الثامن: الإخفاق في إنشاء خيارات إضافية لتعديل الكود

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

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

الخطأ التاسع: عدم استخدام ممارسات تصميم الكود الحديثة

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

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

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

أيضًا ، لا أوصي بدمج كود PHP ورمز HTML معًا. من الأفضل إبقائهم مفصولين عن طريق استخدام نموذج Model-View-Controller (MVC) ، خاصةً إذا كان المكوِّن الإضافي الخاص بك يخضع لصيانة العديد من المطورين.

الوجبات الجاهزة

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

في المراجعة ، الأخطاء الأكثر شيوعًا هي:

1. التضحية بالجودة لصالح الحلول السريعة
2. فشل في تتبع تغييرات التعليمات البرمجية
3. عدم استخدام مساحات الأسماء
4. عدم استخدام WordPress nonces
5. عدم استخدام وظائف WordPress الأساسية
6. إدراج ملفات JavaScript و CSS في قائمة الانتظار
7. وضع كود JavaScript في ملف رئيسي واحد لسمات التقدم
8. عدم إنشاء خيارات إضافية لتعديل التعليمات البرمجية
9. عدم استخدام ممارسات تصميم الكود الحديث

على الرغم من أن ارتكاب الأخطاء أمر لا مفر منه ، بعد أن عرفت ماهيتها ، سيكون من الأسهل تجنبها.

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

بمساهمة من أليز فالك.