كيفية جعل البرنامج المساعد ووردبريس قابل للتوسيع

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

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

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

تخيل لو كنت مطور هذا البرنامج المساعد. ماذا ستفعل إذا طلب المستخدم بعض الوظائف المعينة؟

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

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

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

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

ما الذي يجعل البرنامج المساعد قابل للتوسيع؟

باختصار ، يعني المكون الإضافي القابل للتوسيع أنه يلتزم بالجزء "O" من مبادئ SOLID للبرمجة الموجهة للكائنات - أي مبدأ الفتح / المغلق.

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

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

مثال نموذجي للمكوِّن الإضافي

دعونا نرى كيف يمكننا إنشاء مكون إضافي قابل للتوسيع ، بدءًا من نموذج مكون إضافي ليس كذلك.

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

 function get_some_post_titles() { $args = array( 'posts_per_page' => 3, ); $posts = get_posts( $args ); $output = '
 "؛
  foreach (مشاركات $ كـ $ post) {
      الناتج $. = '
 ". $ post-> post_title. "
 "؛
  }
  الناتج $. = '
 "؛

  إرجاع الناتج $؛
}

بينما يعمل هذا الرمز وينجز المهمة ، فإنه ليس قابلاً للتوسيع تمامًا.

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

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

تضمين مئات الإعدادات ليس هو الحل

هناك عدد من الطرق لتحسين المكون الإضافي أعلاه للسماح للمستخدمين بتخصيصه.

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

ماذا لو أراد المستخدم القيام بأي مما يلي (السيناريوهات التي سنعيد النظر فيها لاحقًا):

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

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

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

إذن ، كيف نبدأ في حل هذه المشكلة؟ سنجعل المكون الإضافي قابلاً للتوسعة.

إضافة الخطافات الخاصة بنا لجعلها قابلة للتوسيع

من خلال دراسة كود المكون الإضافي أعلاه ، نرى بعض العمليات التي تؤديها الوظيفة الرئيسية:

• يحصل على المشاركات باستخدام get_posts .
• يقوم بإنشاء قائمة عناوين الوظائف.
• تقوم بإرجاع القائمة التي تم إنشاؤها.

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

بشكل عام ، هذه مناطق جيدة لإضافة خطافات إلى مكون إضافي:

• حول وضمن العمليات الرئيسية ،
• عند إنشاء HTML الناتج ،
• لتغيير استفسارات المنشور أو قاعدة البيانات ،
• قبل إرجاع القيم من دالة.

مثال نموذجي للمكوِّن الإضافي القابل للتوسيع

باتباع هذه القواعد الأساسية ، يمكننا إضافة عوامل التصفية التالية لجعل المكون الإضافي الخاص بنا قابلاً للتوسيع:

• أضف myplugin_get_posts_args لتعديل وسيطات get_posts ،
• أضف myplugin_get_posts نتائج get_posts ،
• أضف myplugin_list_item لتخصيص إنشاء إدخال قائمة ،
• أضف myplugin_get_some_post_titles القائمة التي تم إنشاؤها.

هذا هو الكود مرة أخرى مع إضافة جميع الخطافات:

 function get_some_post_titles() { $args = array( 'posts_per_page' => 3, ); // Let other people modify the arguments. $posts = get_posts( apply_filters( 'myplugin_get_posts_args', $args ) ); // Let other people modify the post array, which will be used for display. $posts = apply_filters( 'myplugin_get_posts', $posts, $args ); $output = '
 "؛
  foreach (مشاركات $ كـ $ post) {

      // دع الآخرين يعدلون إدخال القائمة.
      الناتج $. = '
 ". application_filters ('myplugin_list_item' ، $ post-> post_title ، $ post). "
 "؛
  }
  الناتج $. = '
 "؛

  // دع الآخرين يعدلون قائمة المخرجات الخاصة بنا.
  إرجاع application_filters ('myplugin_get_some_post_titles'، $ output، $ args) ؛
}

يمكنك أيضًا الحصول على الكود أعلاه في أرشيف GitHub.

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

تباعد الأسماء وسياق الخطافات

قبل المتابعة ، لاحظ شيئين مهمين حول الخطافات التي قمنا بتنفيذها:

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

آثار خطافنا

هل تتذكر السيناريوهات الفريدة التي تحدثت عنها سابقًا؟ دعنا نعيد النظر في هؤلاء ونرى كيف جعلتهم الخطافات ممكنة:

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

أفضل بكثير!

مثال سريع على كيفية استخدام مرشحاتنا

يمكن للمطورين استخدام add_filter لربط عوامل التصفية الخاصة بنا أعلاه (أو استخدام add_action للإجراءات).

بأخذ السيناريو الأول أعلاه ، يمكن للمطور فقط القيام بما يلي لعرض منتجات WooCommerce باستخدام مرشح myplugin_get_posts_args الذي أنشأناه:

 add_filter( 'myplugin_get_posts_args', 'show_only_woocommerce_products' ); function show_only_woocommerce_products( $args ) { $args['post_type'] = 'product'; return $args; }

يمكننا أيضًا استخدام خطافات الحركة

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

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

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

"رائعة! ولكن لماذا يجب أن أهتم بجعل المكون الإضافي الخاص بي قابلاً للتوسيع؟ "

حسنًا ، إذا كنت لا تزال غير مقتنع بالفكرة ، فإليك بعض الأفكار حول لماذا يُعد السماح للآخرين بتعديل سلوك المكون الإضافي فكرة جيدة.

يفتح البرنامج المساعد لمزيد من إمكانيات التخصيص

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

يسمح للأشخاص بإدخال تعديلات دون لمس رمز البرنامج المساعد

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

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

خاتمة

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

ألق نظرة على المكونات الإضافية مثل WooCommerce و Easy Digital Downloads و ACF. هذه المكونات الإضافية قابلة للتوسعة ، ويمكنك معرفة ذلك بسهولة لأن العديد من المكونات الإضافية الأخرى في دليل المكونات الإضافية لـ WordPress تضيف وظائف إليها. كما أنها توفر مجموعة واسعة من الإجراءات ومرشحات الخطافات التي تعدل جوانب مختلفة من المكونات الإضافية. ظهرت القواعد الأساسية التي عددتها أعلاه في دراستي لها.

فيما يلي بعض النصائح لجعل المكون الإضافي الخاص بك قابلاً للتوسيع:

• اتبع مبدأ فتح / مغلق. لا ينبغي أن يضطر الأشخاص الآخرون إلى تعديل التعليمات البرمجية الخاصة بك من أجل تعديل شيء ما.

• لجعل المكون الإضافي الخاص بك قابلاً للتوسعة ، أضف خطافات في هذه الأماكن:

  • حول وضمن العمليات الرئيسية ،
  • عند إنشاء ملف HTML الناتج ،
  • لتغيير استفسارات المنشور أو قاعدة البيانات ،
  • قبل إرجاع القيم من دالة.

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

قراءة متعمقة

فيما يلي بعض الموارد إذا كنت تريد معرفة المزيد حول توسيع المكونات الإضافية:

• كيفية جعل البرنامج المساعد WordPress الخاص بك قابل للتوسيع ، GitHub
  كل نموذج التعليمات البرمجية في هذه المقالة.
• "نصائح مفيدة لبدء استخدام WordPress Hooks" ، توماس ماير ، مجلة Smashing
• "How to Create a WordPress Plugin،" Daniel Pataki، Smashing Magazine
• "الخطافات" ، دليل البرنامج المساعد ، WordPress.org