Unlimited Plugins, WordPress themes, videos & courses! Unlimited asset downloads! From $16.50/m
Advertisement
  1. Code
  2. Plugins
Code

توزيع الإضافات الخاصة بك في جيثب مع التحديثات التلقائية

by
Difficulty:IntermediateLength:LongLanguages:

Arabic (العربية/عربي) translation by Mohammed Ali (you can also view the original English article)

جعلت WordPress من المناسب لنشر المكونات الإضافية للجمهور. ضع المكوّن الإضافي في مستودع المكونات الإضافية لـ WordPress ويمكن العثور عليه بسهولة من قبل أشخاص من داخل لوحة القيادة.

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

ولكن ماذا لو أردت استضافة البرنامج المساعد بنفسك؟ لن تكون ميزة التحديث المريحة متاحة إذا قمت باستضافة المكون الإضافي الخاص بك خارج ملحق البرنامج المساعد WordPress. ولن يتم إخطار المستخدمين بالتحديث المتاح.

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

لماذا استضافة البرنامج المساعد الخاص بك في جيثب؟

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

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

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

كيفية تحديث ملحقات ووردبريس

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

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

Plugin Admin Update Now

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

Plugin Lightbox

أخيرًا ، عند النقر فوق ارتباط التحديث الآن ، يتم تنزيل وتثبيت حزمة البرنامج المساعد المحدثة.

إذن لماذا لا تعمل التحديثات التلقائية للإضافات المستضافة ذاتيًا؟ ذلك لأن WordPress يحاول العثور عليه في مستودع البرنامج المساعد WordPress ولا يمكن العثور عليه هناك!

خطة اللعب

تتمثل خطتنا في تمكين التحديثات التلقائية من خلال المكون الإضافي المستضاف من GitHub.

فيما يلي قائمة بما يتعين علينا القيام به لإنجاحه:

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

كيفية تنفيذ الخطة

سنستخدم بعض مرشحات WordPress حتى نتمكن من تنفيذ خطة لعبتنا. هؤلاء هم:

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

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

إعداد مشروع جيثب

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

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

سنستخدم ميزة رائعة لـ GitHub تسمى الإصدارات.

GitHub Releases

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

شيء جيد آخر حول الإصدارات هو أنه يمكننا وضع تفاصيل تحديث المكون الإضافي في ملاحظات الإصدار. يمكننا بعد ذلك تحليل هذا وعرضه في برنامج WordPress الخاص ببرنامج lightbox للحصول على تفاصيل تحديث البرنامج المساعد. يمكننا أن نذهب أبعد من ذلك وحتى نسمح بخفض سعر جيثب في سجل التغيير الخاص بنا.

GitHub Releases

عندما يحين وقت نشر تحديث على المكوِّن الإضافي لدينا ، اتبع التنسيق في الصورة أعلاه عندما تقوم بإنشاء إصدار جديد:

  • اسم العلامة: إصدار البرنامج المساعد (الرقم فقط)
  • ملاحظات الإصدار: وصف التحديث
يمكنك قراءة المزيد حول إصدارات جيثب في مقالتهم "إطلاق برنامجك"

إنشاء فئة التحديث الخاصة بنا

الآن حان الوقت لترميز البرنامج المساعد لدينا!

أولاً ، نخلق نقطة البداية لفصلنا:

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

وسيطات المنشئ

لتنفيذ فصلنا ، سنحتاج إلى بعض الحجج:

  • $ pluginFile: سنقوم باستدعاء هذه الفئة من البرنامج النصي الرئيسي للمكون الإضافي ، ويجب أن يكون لهذا القيمة __FILE__. سنحصل على تفاصيل حول المكون الإضافي الخاص بنا من هذا لاحقًا.
  • $ gitHubUsername: اسم مستخدم GitHub الخاص بك
  • $ gitHubProjectName: اسم مستودع GitHub الخاص بك
  • رمز الوصول إلى $: وميزة رمز الوصول التي تتيح لنا عرض تفاصيل إعادة الشراء الخاصة بـ GitHub. إذا كان مشروعك مستضافًا في ريبو GitHub عام ، فما عليك سوى ترك هذا فارغًا.

الآن دعونا ملء وظائف صفنا مع بعض التعليمات البرمجية.

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

دالة initPluginData

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

دالة getRepoReleaseInfo Function

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

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

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

أخيرًا ، سنحتفظ فقط بالبيانات للحصول على أحدث إصدار من المكون الإضافي:

الآن يمكننا الحصول على بيانات البرنامج المساعد لدينا من GitHub. سنقوم بتحليل هذه البيانات في الوظائف اللاحقة.

دالة setTransitent Function

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

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

بعد ذلك ، سوف نحصل على معلومات البرنامج المساعد التي سنستخدمها:

بعد استدعاء هاتين الوظيفتين ، يمكننا التحقق من إصدار المكون الإضافي المحلي الخاص بنا من الإصدار (اسم العلامة) الموجود في GitHub. يمكننا استخدام وظيفة version_compare المناسبة لـ PHP لمقارنة القيمتين:

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

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

Plugin Update Notification

دالة setPluginInfo Function

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

أولاً ، دعنا نحصل على معلومات المكون الإضافي لدينا:

بعد ذلك نتحقق مما إذا كان الوقت قد حان لعرض أي شيء أم لا. يمكننا التحقق مما إذا كنا نحاول تحميل معلومات عن المكون الإضافي الحالي الخاص بنا عن طريق التحقق من slug:

لعرض تفاصيل المكون الإضافي لدينا ، نحتاج إلى إضافة معلومات المكون الإضافي يدويًا إلى متغير استجابة $ ، وعادةً ما يتم ملء هذا المتغير بالنتائج من مستودع مكون WordPress:

لقد أضفنا حتى الآن تفاصيل المكوّن الإضافي لدينا ، لكننا لم نحلل بعد ملاحظات الإصدار الخاصة بنا من إصدار GitHub. دعونا نتحقق مما لدينا في ملاحظات الإصدار:

GitHub Releases

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

نظرًا لأننا نستضيف المكوِّن الإضافي الخاص بنا في GitHub ، سيكون من الرائع أن نتمكن من استخدام أداة تخفيض السعر في GitHub في ملاحظات الإصدار. سأستخدم فئة PHP تسمى ParseDown لتحويل نص تخفيض السعر إلى HTML:

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

أخيرًا ، سنقوم باستخراج قيم المتطلبات المطلوبة والمختبرة:

دالة postInstall Function

هذه الوظيفة الأخيرة سنتعامل مع تنفيذ عمليات إضافية نحتاجها لتثبيت المكون الإضافي بالكامل بعد تنزيله.

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

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

اهم الاشياء اولا:

بعد ذلك ، يتعين علينا التحقق مما إذا كان المكوِّن الإضافي قيد التشغيل حاليًا ، حتى نتمكن من إعادة تنشيطه بعد ذلك:

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

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

الاتصال بفئة محدثة من جيثب

الآن بعد الانتهاء من الفصل ، كل ما تبقى هو استدعاء هذا في ملف المكون الإضافي الرئيسي:

قم بتجربته :

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

لاختبار ما إذا كان يعمل ، قم بإنشاء إصدار جديد لـ GitHub repo واتبع الإرشادات الموضحة مسبقًا:

GitHub Releases

بمجرد إنشاء الإصدار الخاص بك ، يمكنك إجبار WordPress على البحث عن التحديثات من خلال النقر على زر التحديث الموجود في شريط المسؤول.

الاستنتاج

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

آمل أن يحظى هذا المقال بإعجابكم. أنا أقدر أي تعليقات وتعليقات واقتراحات. مشاركة أفكارك أدناه!

Advertisement
Advertisement
Looking for something to help kick start your next project?
Envato Market has a range of items for sale to help get you started.