الدروس المستفادة أثناء تطوير ملحقات WordPress

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

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

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

1. حل مشكلة

إذا لم يحل المكون الإضافي مشكلة ، فلن يتم تنزيله. إنها بهذه السهولة.

خذ البرنامج المساعد Advanced Cron Manager (أكثر من 8000 تثبيت نشط). يساعد مستخدمي WordPress الذين يواجهون صعوبة في تصحيح أخطاء cron الخاصة بهم. تمت كتابة المكوِّن الإضافي بدافع الحاجة - كنت بحاجة إلى شيء لمساعدة نفسي. لم أكن بحاجة إلى تسويق هذا المنتج ، لأن الناس بحاجة إليه بالفعل. خدش حكة لهم.

من ناحية أخرى ، هناك Bug - fly on the screen plugin (أكثر من 70 تثبيتًا نشطًا). يقوم بمحاكاة ذبابة على الشاشة بشكل عشوائي. إنه لا يحل مشكلة حقًا ، لذلك لن يكون لها جمهور كبير. كان تطوير البرنامج المساعد ممتعًا ، على الرغم من ذلك.

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

كما يشهد David Hehenberger في مقالته حول كتابة مكون إضافي ناجح ، فإن الحاجة هي عامل رئيسي في قرار مستخدم WordPress بشأن تثبيت مكون إضافي معين.

إذا كان لديك فرصة لحل مشكلة شخص ما ، اغتنم الفرصة.

2. دعم المنتج الخاص بك

"سيحاول 3 من أصل 5 أمريكيين علامة تجارية جديدة أو شركة جديدة لتجربة خدمة أفضل. قال 7 من أصل 10 إنهم على استعداد لإنفاق المزيد مع الشركات التي يعتقدون أنها تقدم خدمة ممتازة ".

- نيكي ييغر

لا تهمل دعمك. لا تعاملها على أنها ضرورة ، بل تعاملها على أنها فرصة.

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

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

عندما تقدم دعمًا ممتازًا ، يبدأ الناس في الوثوق بك وبمنتجك. والمكوِّن الإضافي منتج ، حتى لو كان مجانيًا بالكامل ومفتوح المصدر.

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

فيما يلي قائمة ببعض الإجراءات التي يمكنك اتخاذها:

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

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

3. لا تستخدم الملحن

Composer هو برنامج إدارة الحزم. يتم استضافة مستودع الحزم على packagist.org ، ويمكنك تنزيلها بسهولة على مشروعك. إنه مثل NPM أو Bower لـ PHP. تعد إدارة حزم الطرف الثالث بالطريقة التي يعمل بها Composer ممارسة جيدة ، ولكن لا تستخدمها في مشروع WordPress الخاص بك.

أعلم ، لقد أسقطت قنبلة. دعني أوضح.

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

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

لم يتم حل مشكلة Composer مع مكونات WordPress الإضافية ، ولن يكون هناك أي حل عملي لهذه المشكلة في المستقبل القريب. لقد أثيرت المشكلة منذ سنوات عديدة ، وكما يمكنك أن تقرأ في مقالة WP Tavern ، يحاول العديد من المطورين حلها دون أي حظ.

أفضل ما يمكنك فعله هو التأكد من أن الظروف والبيئة جيدة لتشغيل التعليمات البرمجية الخاصة بك.

4. دعم إصدارات PHP القديمة بشكل معقول

لا تدعم الإصدارات القديمة جدًا من PHP ، مثل 5.2. لا تستحق مشكلات الأمان والصيانة كل هذا العناء ، ولن تكسب المزيد من التثبيتات من تلك الإصدارات القديمة.

استخدم PHP 5.6 كحد أدنى من المتطلبات ، على الرغم من أنه سيتم إسقاط الدعم الرسمي بحلول نهاية عام 2018. يتطلب WordPress نفسه PHP 7.2.

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

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

5. التركيز على كود الجودة

كتابة كود جيد أمر صعب في البداية. يستغرق الأمر وقتًا لتعلم مبادئ "SOLID" وأنماط التصميم ولتغيير عادات الترميز القديمة.

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

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

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

ما ورد أعلاه مجرد أمثلة قليلة ، ولكن يجب أن تتعرف على مبادئ SOLID. هذه صالحة لأي نظام وأي لغة ترميز.

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

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

6. اختبر البرنامج المساعد الخاص بك قبل الوقت

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

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

يستغرق كل اختبار آلي جزءًا من الثانية. يستغرق إكمال 100 اختبار آلي حوالي 10 دقائق ، بينما يحتاج الاختبار اليدوي إلى دقيقتين تقريبًا لكل حالة.

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

لبدء الاختبار الآلي ، يمكنك استخدام الأمر WP-CLI \\ `wp scaffold plugin-test \\` ، الذي يقوم بتثبيت كل التكوين الذي تحتاجه.

7. توثيق عملك

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

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

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

سيوفر لك استخدام كلتا الطريقتين وقت كتابة الوثائق ، لكن وثائق الكود لن تتم قراءتها من قبل الجميع.

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

خاتمة

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

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