أحد الأسباب الرئيسية وراء استمرار شعبية وورد بريس هو السهولة التي يمكن بها تمديدها وتخصيصها مع المكونات الإضافية.
قد يبدو إنشاء مكون إضافي بمثابة مهمة مستحيلة ، ولكنه أبسط مما تعتقد. نبدأ اليوم في سلسلة "إنشاء أول ملحق WordPress" الخاص بك والذي سيغطي أهم المبادئ وطرق عمل هذه العملية.
بحلول نهاية السلسلة ، ستكون مستعدًا تمامًا لإجراء المزيد من التجارب الخاصة بك ، معتمدين على أفضل الممارسات والاتفاقيات التي يعتمدها مجتمع WordPress الواسع.
وهو عبارة عن نص برمجي لـ PHP يقوم بتعديل أو توسيع الوظيفة الأصلية لـ WordPress.
من خلال توفير بسيطة جدا ولكنها مرنة واجهة برمجة التطبيقات الإضافية يوفر WordPress كل مطور له المزايا التالية لاستخدام المكون الإضافي:
بغض النظر عن تجربة ترميز PHP - كتبت مؤلفها الأول بالفعل بعد الانتهاء من كتاب "PHP for Dummies" - فأنت على بعد خطوة واحدة من إنشاء أول ملحق لـ WordPress. لنأخذ هذه الخطوة معًا.
المهمة الأساسية التي سنقوم باستكشافها اليوم هي بناء أساس ملحق قوي. يجب أن تفي هذه المؤسسة بمتطلبات WordPress وأن تجعل المكون الإضافي قابلاً للتمييز من خلال القلب. في الوقت نفسه ، يجب اتباع الممارسات والاتفاقيات الشائعة ، التي يقبلها المجتمع ، لتجنب التضارب المحتمل مع المكونات الإضافية الأخرى التي قد يتم تثبيتها على الموقع.
أولاً ، تحتاج إلى التأكد من أن اسم المكون الإضافي فريد. حتى إذا لم تكن ستجعل عملك إصدارًا عامًا ، فعليك على الأقل أن تتأكد من عدم وجود إمكانية لاستخدام موقعك باستخدام مكونين إضافيين بنفس الاسم. يعتبر مستودع المستلزمات البسيطة (و Google) صديقك عندما تتجنب الاختيار الخاطئ.
لزيادة احتمال كون الاسم فريدًا ، ينشئ العديد من المطورين بادئة العلامة التجارية ، وهي اختصار لاسم المطور (أو اللقب). يجب استخدام هذه البادئة مع الإشارة القصيرة إلى اسم المكوِّن الإضافي لاحقًا في كل مكان - في أسماء الملفات والوظائف والفئات والمتغيرات وما إلى ذلك. يساعد ذلك في تجنب التعارض مع المكونات الإضافية والموضوعات والنواة نفسها.
لنبدأ بمثال. نتبنى اسم "Hello World Plugin" ولزيادة فرص كوننا مميزين ، نستخدم "My super prefix" الذي يتم تحويله إلى اختصار "MSP". الذي يعطينا اسمًا فريدًا بحق "MSP Hello World Plugin" ؛ البحث من خلال مستودع الإضافات يؤكد أن لا أحد آخر يستخدم ذلك.
خطوتنا التالية هي إنشاء ملفات plugin. يوصى بشدة بتخزينها في مجلد منفصل داخل مجلد مكون إضافي مخصص. يجب تسمية هذا المجلد وفقًا للمكوِّن الإضافي نفسه ، وفي حالتنا يمكن أن يكون "msp-helloworld". يجب أن يتضمن المجلد ملف المساعد الرئيسي بنفس الاسم: 'msp-helloworld.php'.
ال كما توصي WordPress الدستور قمت بتضمين ملف readme.txt. يحتوي هذا الملف على معلومات حول المكوّن الإضافي شكل موحد . إذا كنت ترغب في إرسال المكون الإضافي إلى مستودع WordPress ، فإن وجود الملف readme.txt يعد أمرًا إلزاميًا. لكن لا تفكر في الأمر كعبء ، فهناك الكثير من الفوائد للقيام بذلك.
إذا كان من المفترض أن يكون لديك المكون الإضافي ملفات متعددة أو تحميل بعض الأصول (ملفات الصور وملفات css و js) ، فيجب تنظيمها في مجلدات فرعية. تنظيم الملف الصحيح هو علامة على العمل المهني. يمكنك الاعتماد على النمط التالي:
كل ملحق يجب أن يكون إلزاميا رأس . فهو يساعد WordPress على التعرف على البرنامج النصي كمكون إضافي صالح وإخراج المعلومات المناسبة على شاشة إدارة الملحقات.
هذا العنوان عبارة عن كتلة تعليق PHP موجودة أعلى ملف المساعد الرئيسي:
/*Plugin Name: MSP Hello WorldDescription: Create hello world messageVersion: 1.0Author: Author's nameAuthor URI: http://authorsite.com/Plugin URI: http://authorsite.com/msp-helloworld*/
سيتم عرض معلومات الرأس في صف المكوّن الإضافي المقابل على شاشة الإدارة.
ترتيب الخطوط ليس مهمًا ، ولكن يجب أن يكون الملف بترميز UTF-8.
لاحظ أنه من المهم أن تكون متناسقًا مع نمط ترقيم الإصدار الذي اخترته (egxxx) ، لآلية ترقية WordPress لاكتشافه بشكل صحيح.
حتى الآن ، أنشأنا ملفات مختلفة للمكوِّن الإضافي (في مجلدات فرعية مناسبة) ، نحتاج الآن إلى تحديد المسارات الصحيحة (أو عناوين URL) لهم داخل رمز البرنامج المساعد. مع الأخذ بعين الاعتبار حقيقة أنه يمكن نقل مجلد wp-content من موقعه الافتراضي ، يصبح من الواضح أن مسارات الملفات الإضافية لا ينبغي أن تكون ضمنية ، بل بالأحرى ، يجب أن يتم الكشف عنها.
يحتوي WordPress على وظيفتين ، وهما plugin_dir_path و plugin_dir_url لمعالجة المشكلة ، ولكن يمكننا مواصلة استخدام الخدع التالية:
define('MSP_HELLOWORLD_DIR', plugin_dir_path(__FILE__));define('MSP_HELLOWORLD_URL', plugin_dir_url(__FILE__));
باستخدام هذا المقتطف الصغير (المضمّن في الملف الإضافي الرئيسي) ، نكتشف المسار وعنوان URL لمجلد plugin داخل تثبيت WordPress ونعينهما على ثوابت مناسبة. بعد ذلك يمكننا استخدام هذه الثوابت بالاشتراك مع المسارات النسبية المعروفة إلى المجلدات الفرعية ، على سبيل المثال MSP_HELLOWORLD_DIR.'assets/img/image.jpg'
.
باستخدام هذه الثوابت ، يمكننا أيضًا تضمين الملفات الإضافية بسهولة من المجلدات الفرعية داخل الملف الرئيسي:
function msp_helloworld_load(){if(is_admin()) //load admin files only in adminrequire_once(MSP_HELLOWORLD_DIR.'includes/admin.php');require_once(MSP_HELLOWORLD_DIR.'includes/core.php');}msp_helloworld_load();
بعد التثبيت ، يمكن أن يكون المكون الإضافي في حالة نشطة أو غير نشطة.
تعني الحالة النشطة أنه تم تنشيطه من قبل المستخدم وسيتم تنفيذ الكود الخاص به بواسطة WordPress في كل مرة يتم طلب صفحة.
يمكن أيضًا تعطيل المكوِّن الإضافي من قِبل المستخدم ، مما يعني أنه يتم الاحتفاظ بالملفات في أماكنها ، ولكن لا يتم تنفيذ الشفرة.
(يمكن أيضًا إزالة تثبيت المكوِّن الإضافي تمامًا بواسطة المستخدم ، وهذا يعني أنه يتم حذف الملفات من مجلد الإضافات.)
يمكن لـ WordPress أن يمسك التغييرات إلى هذه الحالات وينفذ بعض الشفرات المجدولة لمثل هذه التغييرات. إذا تمت جدولة أي رمز للتنشيط أو إلغاء التنشيط ، فسيتم تنفيذه فقط في هذه اللحظة المحددة ، وليس في كل تحميل للصفحة.
على سبيل المثال ، إذا كان من المفترض أن يعالج المكون الإضافي قواعد إعادة الكتابة ، فيجب أن يتم مسحها عند التنشيط / التعطيل. إذا قام المكون الإضافي بإنشاء بعض الإدخالات في قاعدة بيانات ، على سبيل المثال من خلال تخزين الخيارات ، فإن الممارسة السليمة هي حذفها ، عند إزالة المكون الإضافي.
كيف يمكن أن تتم؟
للتفعيل وإجراءات التعطيل ، يمكننا تسجيل ما يسمى "خطاف التنشيط" و "خطاف التعطيل". إنها مجرد جزء من التعليمة البرمجية التي تخبر WordPress بتنفيذ وظيفة معينة على التنشيط ووظيفة معينة أخرى على إلغاء التنشيط. إليك مثال على مثل هذا الرمز:
register_activation_hook(__FILE__, 'msp_helloworld_activation');register_deactivation_hook(__FILE__, 'msp_helloworld_deactivation');function msp_helloworld_activation() {//actions to perform once on plugin activation go here}function msp_helloworld_deactivation() {// actions to perform once on plugin deactivation go here}
بالنسبة لإجراءات إزالة التثبيت ، لدينا خياران.
خيار واحد هو إنشاء ملف uninstall.php في مجلد plugin (مع ملف المساعد الرئيسي و readme.txt) وتضمين جميع التعليمات البرمجية المطلوبة هناك. في حالة وجود uninstall.php ، سيقوم WordPress بتنفيذها تلقائيًا عندما يتم حذف البرنامج المساعد من قبل المستخدم. بدلاً من ذلك ، يمكننا تسجيل خطاف إلغاء التثبيت بالطريقة نفسها تمامًا كما فعلنا مع خطاف التنشيط والتعطيل. الجزء الصعب هو أن نطلق عليه مرة واحدة فقط ، عند التنشيط. هنا مثال:
register_activation_hook(__FILE__, 'msp_helloworld_activation');function msp_helloworld_activation() {//actions to perform once on plugin activation go here//register uninstallerregister_uninstall_hook(__FILE__, 'msp_helloworld_uninstall');}function msp_helloworld_uninstall(){//actions to perform once on plugin uninstall go here}
من المهم أن تعرف أن أحد البدائل الموصوفة سيعمل فقط: في حالة وجود uninstall.php ، سيتم تنفيذه ولن يتم فصل أي خطاف إلغاء تثبيت.
تلخيصًا لكل ما سبق ، إليك نظرة عامة على إنشاء أساس متين لمكون Wordpress:
بعد كل هذه الخطوات ، ستكون جاهزًا فعلًا لتنفيذ المكون الإضافي للقيام بشيء ما عن طريق إنشاء شفرته. سوف نتعرف على بعض المفاهيم المفيدة التي تجعل من إضافات WordPress مثيرة ومرنة في المقالة التالية من هذه السلسلة. لكن بعض الجوانب المهمة يمكن تسليط الضوء عليها الآن:
آمل أن تكون هذه المعلومات التمهيدية مصدر إلهام لك للبدء في تطوير WordPress. ابحث عن الجزء التالي من السلسلة في المستقبل القريب.
انقر هنا لتنزيل نموذج "Hello World" المساعد الخاص بنا لاستخدامه كهيكل عظمي لتطويرك.
ما هي النصائح التي ستضيفها إلى هذه المقدمة؟ ما الذي تود مشاهدته في المقالة التالية في السلسلة؟ اسمحوا لنا أن نعرف في التعليقات!