أخطاء تطوير موضوع WordPress الأكثر شيوعًا (وكيفية إصلاحها)

يعد إرسال سمة إلى دليل قوالب WordPress.org طريقة رائعة لمشاركة عملك والمساهمة في مجتمع WordPress. يوجد حاليًا أكثر من 7000 سمة في الدليل ، أكثرها شيوعًا يتجاوز 300000 تثبيت نشط. (لا يشمل Twenty____ من السمات التي يتم حزمها مع WordPress ولها عدد تثبيتات بالملايين.)

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

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

https://make.wordpress.org/themes/handbook/review/required/

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

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

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

تحميل الموضوع الخاص بك

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

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

ملاحظة: يمكن لمؤلفي القوالب الذين لديهم سجل حافل بتقديم موضوعات خالية من المشكلات التقدم ليصبحوا "مؤلفين موثوقين".

قضايا التسمية

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

كيف يمكن لذلك ان يحدث؟ والسبب هو أن الاختبار لا يتحقق مقابل الدليل فقط ، بل يتحقق مقابل نظام WordPress البيئي بأكمله. إذا تم إصدار سمة في أي مكان (Github و ThemeForest وما إلى ذلك) ولديها أكثر من 50 عملية تثبيت نشطة ، فلن يكون هذا الاسم متاحًا للاستخدام.

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

إخراج لا مفر منه

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

تعرض المخرجات التي لم يتم تجاوزها مستخدمي السمة الخاصة بك للخطر. فيما يلي مثال على قيمة لم يتم تجاوزها ($ title):

 $ title = get_option ('my_custom_title') ؛
صدى "<h2>". العنوان. "</h2>" ؛

تكمن مشكلة ما سبق في أنه بينما نعرف نوع القيمة التي يجب أن تكون $ title ، سلسلة ، لم نتحقق مما إذا كانت هذه هي الحالة.

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

 تنبيه ('هذا أمر خطير') ؛ 

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

يمكن إصلاح مثالنا مثل هذا:

 $ title = get_option ('my_custom_title') ؛
صدى "<h2>". esc_html ($ title). "</h2>" ؛

الجانب السلبي لاستخدام esc_html هو أنه يزيل كل علامات HTML. إذا اشتمل $ title على خط غامق أو مائل ، على سبيل المثال:

 $ title = "هذه المقالة <strong> مفيدة جدًا </ strong>"؛
echo esc_html ($ title) ؛

لن تكون كلمة "جدًا" جريئة في الواجهة الأمامية ؛ بدلا من ذلك فإنه سينتج الكود <strong> جدا </ strong>.

يوضح هذا سبب أهمية استخدام وظائف escaping الصحيحة للسياق. إذا كنا نتوقع بعض HTML في الإخراج ، فمن الأفضل استخدام wp_kses_post () أو wp_kses () وتعيين المعامل $ allow_html.

الوظائف التي تحتاج أيضًا إلى إلغاء:

 <a href="<؟php echo esc_url( get_permalink() )؛ ؟> ">

الاستثناء هو وظائف WordPress الأساسية التي تتضمن "the_" في أسمائها ، وعادة ما يتم تجاوزها بالفعل.

 دالة the_permalink ($ post = 0) {
    / **
     * يرشح عرض الرابط الثابت للوظيفة الحالية.
     *
     * منذ 1.5.0
     * منذ 4.4.0 تمت إضافة المعلمة `$ post`.
     *
     *param string $ الرابط الثابت الرابط الثابت للوظيفة الحالية.
     *param int | WP_Post $ نشر معرّف النشر أو كائن WP_Post أو 0. الافتراضي 0.
     * /
    echo esc_url (application_filters ('the_permalink'، get_permalink ($ post)، $ post)) ؛
}

نص غير قابل للترجمة

ليتم قبولها في الدليل ، يجب أن تكون جميع السمات "جاهزة للترجمة" بنسبة 100٪. هذا يعني أن كل سلسلة نصية يجب أن تكون مخرجات السمة الخاصة بك قابلة للترجمة.

يحتوي WordPress بالفعل على الأنظمة والوظائف اللازمة للتعامل مع عملية الترجمة ، ما عليك سوى التأكد من استخدام السلاسل الخاصة بك للوظائف الصحيحة.

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

عادة ، قد تفعل شيئًا كالتالي:

 <h1> 404 - غير موجود </ h1>

لجعلها قابلة للترجمة ، تحتاج إلى إضافة بعض PHP:

 // __ الوظائف هي أساس الترجمة.
<h1> <؟ php echo __ ('404'، 'text-domain')؛ ؟>

// _e دوال تردد القيمة.
<h1> <؟ php _e ('404'، 'text-domain') ؛ ؟>

// هرب وكرر السلسلة.
<h1> <؟ php esc_html_e ('404'، 'text-domain') ؛ ؟>

// الترجمة والمتغيرات.
<h1> <؟ php _n ('منشور واحد'، '٪ s posts'، $ count، 'text-domain')؛ ؟>

يجب أن تكون مخرجات السلاسل حسب الدوال جاهزة للترجمة:

 // ليست جاهزة للترجمة :-(
<؟ php next_posts_link ('Older Entries') ؛ ؟>

// جاهز للترجمة :-)
<؟ php next_posts_link (esc_html __ ('Older Entries'، 'text-domain')) ؛ ؟>

نصيحة: الكثير من أمثلة الأكواد في codex.wordpress.org لا تستخدم وظائف الترجمة ، لذا كن حذرًا عند نسخها ولصقها.

إحاطة الموارد بشكل غير صحيح

يجب وضع ملفات .css و .js التي يستخدمها القالب في قائمة الانتظار باستخدام الوظائف الصحيحة: wp_enqueue_style () لـ CSS و wp_enqueue_script () لجافا سكريبت.

الخطأ الشائع هو ترميز البرامج النصية والأنماط مباشرة في <head> أو قبل </ body>. هناك مشكلتان لهذا النهج:

1. من المستحيل إزالته

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

 / **
 * Dequeue موضوع جافا سكريبت.
 *
 * مرتبط بإجراء wp_enqueue_scripts ، بأولوية متأخرة (100) ،
 * بحيث يكون بعد وضع النص في قائمة الانتظار.
 * /
الوظيفة wptavern_dequeue_script () {
   wp_dequeue_script ("نصوص الموضوع") ؛
}
add_action ('wp_enqueue_scripts'، 'wptavern_dequeue_script'، 100) ؛

2. تحميل مكرر

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

 / **
 * Enqueue jQuery
 *
 * سيتم تحميل jQuery مرة واحدة فقط ، على الرغم من قائمتَي الانتظار.
 * يتم حزم jQuery مع WordPress لذلك لا نحتاج إلى تحديد src. 
 * /
الوظيفة wptavern_enqueue_script () {
   wp_enqueue_script ('jquery') ،
   wp_enqueue_script ('jquery') ،
}
add_action ('wp_enqueue_scripts'، 'wptavern_enqueue_script') ؛

إذا كنت قد قمت بدلاً من ذلك بترميز jQuery في <head> الخاص بك ، فلن تكون هناك طريقة لكي يعرف WordPress ، وسيتم تحميله مرتين.

وظائف البرنامج المساعد-إقليم

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

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

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

بعض الأمثلة على وظائف منطقة البرنامج المساعد:

• التحليلات / التتبع
• ضوابط SEO
• نماذج الاتصال
• الرموز القصيرة
• كتل جوتنبرج

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

ليس بادئة

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

شارك جاستن تادلوك قائمة بالأشياء الشائعة التي يجب أن تكون مسبوقة:

• أسماء وظائف PHP.
• أسماء فئات PHP.
• المتغيرات العامة PHP.
• خطاطيف العمل / المرشح.
• مقابض البرنامج النصي.
• مقابض النمط.
• أسماء حجم الصورة.

المصدر: https://themereview.co/prefix-all-the-things/

 // مثال على الوظيفة.
my_prefix_example () ،

// مثال على الفصل.
فئة My_Prefix_Example {…}

// عمل ومثال التصفية.
do_action ('my_prefix_action') ؛
application_filters ('my_prefix_filter' ، قيم $) ؛

// قائمة الأمثلة.
wp_enqueue_script ('my_prefix_script'، get_template_directory_uri (). '/js/custom-script.js') ؛
wp_enqueue_style ('my_prefix_style'، get_template_directory_uri (). '/css/styles.css') ؛

// مثال لحجم الصورة.
add_image_size ('my_prefix_image_size'، 220، 180) ؛ // 220 بكسل في العرض × 180 بكسل في الطول.

استثناء: عند إدراج موارد الجهات الخارجية في قائمة الانتظار ، لا تقم بإضافة بادئة:

 // إدراج نص لجهة خارجية (selected.js).
 wp_enqueue_script ('المختار'، get_template_directory_uri (). '/js/chosen.js') ؛

قضايا الترخيص

يجب أن يكون قالبك وجميع ملفاته متوافقة مع GPL بنسبة 100٪. يتضمن ذلك الصور والمكتبات والنصوص والخطوط.

يجب أن تسرد جميع موارد الجهات الخارجية معلومات المصدر والترخيص الخاصة بها.

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

"لا يتضمن هذا الترخيص الحق في تجميع الصور من Unsplash لتكرار خدمة مماثلة أو منافسة."

ومع ذلك ، فإن هذا التقييد يكفي لجعله غير متوافق مع GPL ، وعلى هذا النحو ، لن ترى صور Unsplash مضمنة في قوالب wordpress.org.

تتوفر قائمة بالتراخيص المتوافقة مع GPL هنا - https://www.gnu.org/licenses/license-list.html#GPLCompatibleLicenses

مؤخرا، كان stocknap.io المصدر الأكثر شيوعًا للصور في الدليل حيث أن جميع الصور المدرجة مرخصة كـ CC0 (متوافقة مع GPL).

أخطاء لقطة الشاشة

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

يجب أن تتبع الصور أيضًا نفس متطلبات الترخيص التي اكتشفناها أعلاه.

المكافأة: استخدم معيار ترميز

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

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

يمكن أن يؤدي استخدام PHP_CodeSniffer ومجموعة قواعد WordPress في محرر الشفرة إلى جعل الالتزام بالمعيار أسهل كثيرًا - https://github.com/WordPress-Coding-Standards/WordPress-Coding-Standards

استنتاج

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