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

ملفات الوظائف والأحداث والمفلترات

نقصد بهذه الملفات ملف functions.php والملفات التي يتم تضمينها من خلاله، حيث تحتوي هذه الملفات في قالب underscores على بعض الشيفرات المهمة التي يتكرر استخدامها في كل قالب ووردبريس تقريبا (أحيانا مع تعديلات بسيطة عليها) وبالطبع يمكنك إضافة المزيد من الشيفرات أو التخلي عن بعضها على حسب القالب الذي تقوم بتطويره.

ملف functions.php

الدالة hsb_setup

كما تلاحظ فإن أول الدوال الموجودة في ملف functions.php دالة تأخذ الاسم اللطيف للقالب متبوعا بكلمة setup وبالمناسبة هذه من الممارسات المهمة جدا في تطوير قوالب وإضافات ووردبريس أي أن تقوم ببدء تسمية الدوال الخاصة بالقالب بكلمة مميزة (عادة الاسم اللطيف للقالب) حتى لا تختلط مع اسم أحد الدوال الموجودة في ووردبريس أو أي من الإضافات في الموقع. في حالتنا هنا سنستخدم hsb كاسم لطيف للقالب وهو اختصار لكلمة Hsoub بالتالي فإن اسم الدالة سيكون كالاتي

function hsb_setup()

قبل أن ندخل في شرح مهمة هذه الدالة قد تكون لاحظت السطر البرمجي السابق لها (تجاهل التعليقات البرمجية) والذي هو عبارة عن عبارة شرطية if statement تأخذ الصورة

if ( ! function_exists( 'hsb_setup' ) ) : 

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

• تحميل دعم القالب للترجمة من خلال استخدام الدالة load_theme_textdomain.
• تسجيل قوائم القالب والتي ستظهر للمستخدم عند إنشائه قائمة جديدة في مكان مواضع القالب ويتم تسجيلها من خلال الدالة register_nav_menus، ويأتي قالب underscores مسجلا لقائمة واحدة فقط وهي القائمة الرئيسية، ويمكنك بالطبع إضافة المزيد على حسب عدد القوائم في قالبك.
• تعريف خصائص ووردبريس التي يدعمها القالب، أو ببساطة إضافة خصائص القالب من خلال الدالة add_theme_support ومنها على سبيل المثال الصورة البارزة وخصائص أخرى يمكنك الإطلاع عليها في صفحة توثيق الدالة.

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

الدالة hsb_widgets_init

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

الدالة hsb_scripts

وتستخدم هذه الدالة لصف ملفات CSS وملفات الجافا اسكربت ويمكنك معرفة المزيد عن هذا الامر من خلال هذا المقال.

كما تلاحظ في نهاية هذا الملف يتم تضمين خمسة ملفات تحتوي على بعض الوظائف ومقسمة على حسب مهامها وهي ما سنتطلع علي تفاصيله في الفقرات القادمة

ملف custom-header.php

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

<?php if ( get_header_image() ) : ?>  
  <a href="<?php echo esc_url( home_url( '/' ) ); ?>" rel="home">  
    <img src="<?php header_image(); ?>" width="<?php echo esc_attr( get_custom_header()->width ); ?>" height="<?php echo esc_attr( get_custom_header()->height ); ?>" alt="">  
  </a>  
<?php endif; // End header image check. ?> 

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

ملف template-tags.php

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

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

• الدالة the_posts_navigation وتستخدم لعرض صفحة المقالات السابقة وصفحة المقالات التالية في صفحة الأرشيف (صفحة عرض المقالات، وصفحة التصنيف وغيرها من الصفحات التي تعرض مجموعة من المقالات).
• الدالة the_post_navigation وتستخدم لعرض المقال السابق والتالي للمقال الحالي (في صفحة المقال الحالي).
• الدالة hsb_posted_on تستخدم لعرض تاريخ وكاتب المقال.
• الدالة the_archive_title تستخدم لعرض عنوان الأرشيف إعتمادا على نوعه فمثلا تعرض عنوان التصنيف بصورة مختلفة عن عنوان الوسم وغيرها من الأرشيفات.
• الدالة the_archive_description لعرض وصف الأرشيف.
• الدالة hsb_categorized_blog للتأكد من أن الموقع يحتوي على أكثر من تصنيف للمقالات حيث ترجع true في هذه الحالة.
• الدالة hsb_category_transient_flusher وتستخدم لمسح الtransient الخاص بالتصنيف والذي يستخدم عادة لزيادة سرعة الموقع.

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

ملف extras.php

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

من الدوال في هذا الملفK، الدالة hsb_body_classes والتي تستخدم للتعديل على المتغير الذي يحتوي على CSS Classes الخاص بوسم body للموقع من خلال مفلتره body_class، وهي في هنا تضيف الClass المسمى group-blog في حالة كانت المدونة تحتوي على أكثر من كاتب.

الدالة hsb_wp_title والتي تقوم بالتعديل على إسم الموقع (الذي يظهر في وسم title بداخل وسم head في الموقع) من خلال فلتره wptitle ويتم التعديل على حسب الصفحة المعروضة (حيث يختلف عنوان الموقع في الصفحة الرئيسية من العنوان في صفحة عرض المقال).

الدالة hsb_render_title وهي المسؤولة عن عرض عنوان الموقع داخل وسم head وذلك من خلال إضافتها للحدث wphead. وكما هو الحال بنسبة لملف template-tags.php يمكنك إضافة المزيد من الدوال لهذا الملف كما تريد.

ملف jetpack.php

يستخدم هذا الملف لإضافة توافقية القالب مع إضافة Jetpack المشهورة وبالتحديد مع خاصية Infinite Scroll التي توفرها هذه الإضافة حيث وذلك من خلال دالتين الأولى وهي hsb_jetpack_setup تقوم بإخبار ووردبريس أن الموقع متوافق مع خاصية infinite-scroll بإستخدام الدالة add_theme_support، والدالة الثانية هي hsb_infinite_scroll_render وهي المسؤولة عن طريقة عرض المقالات التي سيتم تحميلها من خلال هذه الخاصية.

ملف customizer.php

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

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

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

لحسن الحظ، بإمكانك إضافة الخط الذي تختاره بسهولة عن طريق قاعدة font-face@ في CSS3. كل ما تحتاجه هو رفع الخط إلى خادوم الويب الخاص بك، ثم إضافته إلى قالبك عن طريق بضعة سطور من CSS.

العثور على خط

هناك أماكن عديدة للعثور على خطوط ويب جيدة مجانًا مثل FontSquirrel أو Adobe Edge Web Fonts. فقط تأكد من اختيارك لخط ذي رخصة تلائم احتياجاتك. حيث أن الخطوط المجانية ليست جميعها متاحة للاستخدام التجاري، ولكن يمكنك شراء خطوط بمقابل مادّي للاستخدام التجاري من أماكن عديدة مثل Typekit.
هناك نوعان رئيسيان من الخطوط في اللغة الإنجليزية: serif و sans-serif. تمتلك خطوط serif منحنيات في أطرافها بينما لا تمتلكها خطوط sans-serif.
عندما يقع اختيارك على الخط الجديد، ستحتاج لتحميل ملفه. ضع في اعتبارك أن هناك أنواع مختلفة من ملفات الخطوط وليست كلها متوافقة مع أغلب متصفحات الإنترنت.

إليك مُلخّصا سريعًا عن الأنواع المختلفة للخطوط وصيغ ملفاتها:

• (TrueType Font (TTF: متوافق مع إنترنت اكسبلور 9.0 وما يليها، وكروم بداية من الإصدارة 4.0، فيرفكس من الإصدارة 3.5، سافاري من الإصدارة 3.1 وأوبرا من الإصدارة 10.0.
• (OpenType Font (OTF: له نفس التوافقيات لخط TrueType.
• (Web Open Font Format (WOFF: يدعمه إنترنت إكسبلورر من الإصدارة 9.0 وما يليها، كروم بداية من الإصدارة 5.0، فيرفكس من الإصدارة 3.6، سافاري من الإصدارة 5.1 وأوبرا من الإصدارة 11.1.
• (Web Open Font Format 2.0 (WOFF2: مدعوم فقط في كروم من الإصدارة 36.0، فيرفكس من الإصدارة 35.0، وأوبرا من الإصدارة 26.0.
• (Embedded Open Type Font (EOT: متاح خصيصًا لإنترنت إكسبلورر 6.0 وما يليه.

صيغة Web Open Font Format هي الصيغة المفضلة نظرًا لأن الخطوط تٌضغط فيها لتستهلك مساحة أقل من الاتّصال المتاح لك وتحتوي على بيانات وصفية إضافية. ولكن للأسف فإنها ليست دائمًا متاحة للتحميل. فإذا وجدت صعوبة بالعثور على هذه الصيغة، يمكنك استخدام صيغ TrueType وOpenType المتاحة بشكل أكبر للتحميل كما أنها اختيارجيد أيضًا.

رفع خطوطك على خادوم الويب

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

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

 wp-content > themes > your-theme

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

فك ضغط الملف المضغوط وارفع المحتويات إلى مجلد القالب الخاص بك عن طريق لوحة التحكم. عبر النّقر على زر File Manager تحت Files في الصفحة الرئيسية للوحة التحكم. وغالبًا ستظهر لك نافذة منبثقة، فحينها ستختار مكان موقعك وبعدها تضغط زر الذهاب Go. انتقل إلى مجلد القالب الخاص بك واضغط زر الرفع Upload في أعلى الصفحة.

يمكنك ترك صلاحيات الملف 644 ولن تواجه مشاكل غالبا. ولكن إذا واجهتك مشكلة صلاحية، فجرب حذف الملفات ثم إعادة رفعها مجددا بصلاحيات مختلفة.

اضغط على زر اختيار الملف Choose file في صفحة رفع الملفات واختر ملفات الخط من حاسوبك. عندما تفتحها، فإن عملية الرفع ستبدأ تلقائيًا دون ضغط زر إضافي على هذه الصفحة.
لا يهم المكان الذي تضع فيه ملف الخطوط، بل ستحتاج لتتذكر مساره. وستجده مكتوبًا في صفحة رفع الملفات بالبنط العريض بعد جملة Select files to upload to.

إضافة خطوطك إلى القالب

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

wp-content > themes > yourtheme

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

@font-face { 
    font-family: FontName; 
    src: url(public_html/your-site/wp-content/themes/your-theme/fonts/FontName-Regular.ttf); font-weight: normal; 
}

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

p { font-family: FontName; } 

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

خاتمة

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

لمزيد من المعلومات عن استخدام الخطوط في ووردبريس، اقرأ الدليل التالي: اللعب بالخطوط.

ترجمة -وبتصرف- للمقال: Adding Custom Fonts to WordPress with @Font-Face and CSS3 لصاحبه: Jenni McKinnon.

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

أحد الطرق لجعل المحتوى في ووردبريس يعمل بشكل أفضل هو إضافة معلومات إضافية له (metadata). قد يكون الأمر على شكل تصنيفات خاصة (taxonomies) أو على شكل بيانات تستخدم لهدف واحد (custom fields).

ماهو الحقل المخصص في ووردبريس؟

إذا أردت أن تستخدم معلومات محددة متغيرة لكل مقال ما (أو شيء شبيه بمقال كمنتج)، هنا تستطيع استخدام الحقول المخصصة في ووردبريس. "الحقول المخصصة" لها تسميتان مختلفتان في ووردبريس، غالبا ما يطلق عليها خصائص المنشور أو المعلومات الجانبية (post metadata) أو post_meta وعادة ما يطلق عليها باسم الحقول المخصصة، وهذه الترجمة الرسمية التي يستخدمها فريق ترجمة ووردبريس العربي.

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

ووردبريس يقوم بتخزين هذه المعلومات في قاعدة البيانات، وباستخدام دوال معينة نقوم بتحديدها وتخزينها واسترجاعها. الحقول المخصصة تنفرد عن خيارات الموقع site_settings حيث أنّ لهم علاقة بالمنشور وليس بالموقع ولكن كلاهما يعملان بنظام عنوان وقيمة key/value pair يتم استخارجهم من قاعدة البيانات عبر دوال محددة، لذا إن كانت لك تجربة بنظام خيارات الموقع Settings API فلن تواجه مشكلة في فهم الحقول المخصصة.

كيف أضيف الحقول المخصصة لمنشور؟

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

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

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

إظهار الحقول المخصصة في منشوراتك

لتستخدم الحقول الخاصة في منشوراتك أمامك عدة دوال، وتسمياتهم تختلف حسب طريقة تكلم الناس عنهم، الدوال الأساسية هي كالتالي:

• ()the_meta: مثل كل دوال ووردبريس التي تبدأ بـ _the فدالة ()the_meta الهدف منها طبع المعلومات (echo) حتى لا تقوم بالأمر يدويا. تستطيع استخدامها عندما لا تريد أن تغير أيّ شيء بالمعلومات التي تريد طباعتها. لكنها تبدو لي غبر مفيدة لأنها لا تتيح لك أيّ تحكم بهيكلة المعلومات التي تحصل عليها، كما أنها تقوم بطبع كل المعلومات للصفحة.
• ()get_post_meta: هي الدالة التي أستخدمها أنا طوال الوقت، المتغير الأول (parameter) الذي تحتاجه هو معرف (ID) المنشور، المتغير الثاني هو اسم الحقل الذي تريد جلبه، والثالث هو Boolean في حال كنت تريد القيمة على شكل string أو array مصفوفة (true من أجل string وfalse ل array).
• ()get_post_custom: عمل بشكل شبيه جدا لـ ()get_post_meta لكنها تختلف في التسمية، الفرق أنك تقوم بتمرير ID المنشور له فحسب (بشكل اختياري أيضا) وسيقوم بإرجال كل القيم المخصصة للمنشور على شكل array.

ما بعد الأساسيات: كيفية تحسين واجهة الحقول المخصصة

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

الدوال التي تحتاجها للتعامل مع الحقول الخاصة

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

• ()add_post_meta : هي الطريقة التي تستخدمها لإنشاء الحقل لأول مرة، تقوم بتمرير ID المنشور لها واسم الحقل المخصص (meta_key) والقيمة التي تريدها، وبشكل اختياري تستطيع تحديد أن يجعل ووردبريس تلك القيمة فريدة من نوعها.

  addpostmeta($postid, $metakey, $meta_value, $unique = false)
  

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

  updatepostmeta($postid, $metakey, $metavalue, $prevvalue='')
  

• ()delete_post_meta : هي كما تتوقع تماما، وخياراتها مثل البقية تماما، عدى أن الخيار الأخير (قيمة الحقل) هي قيمة اختيارية تستطيع أن لا تحددها.

  deletepostmeta( $postid, $metakey, $meta_value = '' )
  

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

استخدام إضافات مصممة لتحسين تجربة الحقول الخاصة

هناك العديد من الإضافات الرائعة التي تقوم بتحسين واجهة الحقول الخاصة، أشهرها في نظري هي Pods و Advanced Custom Fields. تقوم هذه الإضافات باستخدام custom post type لإنشاء حقول جديد تعمل بمثابة حقل مخصص.

أداة أبسط وأقوى

الطريقة التي استخدمها عادة والتي تختلف عن البقية هي إضافة CMB2 فهي تتيح لك تحكم عبر الشفرة البرمجية (عكس الإضافات الأخرى التي تتطلب منك إنشاء الحقول عبر واجهة). استخدام هذه الطريقة للبناء بدل الطريقة التقليدية الذي يوفرها ووردبريس هو أمر مختلف تماما وتجربة رائعة.

لن تحتاج لكتابة دوال كبيرة لبناء صناديق لحقول مخصصة ثم محاولة حفظها فهي تقوم بكل شيء بشكل أوتوماتيكي. كل ما عليك القيام به هو وضع الملفات في قالبك أو إضافتك أو تنصيب الإضافة والعمل مع دوالها من قالبك، لشرح أكبر لها اقرأ التوثيق المرفق لها.
يجدر الذكر أنّ الإضافة مترجمة للعربية بنسبة 93% (بتاريخ هذا اليوم) ويعتبر هذا دعما ممتازا للعربية لذا الشكر لكل من ساهم في ترجمتها (تستطيع الانضمام لهم عبر موقع Transifex).

قوة الحقول المخصصة في ووردبريس

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

ترجمة -وبتصرف- للمقال: Everything You Should Know about WordPress Custom Fields لصاحبه: DAVID HAYES.

واحد من أكثر الأشياء المفيدة في ووردبريس ما يسمى بالوسوم الشرطية (Conditional Tags)، حيث ستمكنك من البرمجة بسهولة وفهم الكود الذي تكتبه كأنك تقرأ نص باللغة الإنجليزية.

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

كيف تعمل الوسوم الشرطية

الوسوم الشرطية هي دوال خاصة بووردبريس تقوم بإرجاع قيمة صح أو خطأ (boolean) إعتمادا على معطيات مختلفة. 

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

مفيدة

• ()is_single سيتم إرجاع قيمة صحيحة إذا كانت الصفحة الحالية متكونة من تدوينة واحدة فقط من أي نوع ماعدا التدوينة مع المرفقات. ويتم ذلك عن طريق تمرير رقم التدوينة أو عنوانها كمعامل (parameter).
• ()is_page سيتم إرجاع قيمة صحيحة إذا كانت الصفحة معروضة (غير مخفية).
• ()is_singular مشابهة لـ ()is_single، لكنها تعود بقيمة صحيحة إذا تم عرض تدوينة تحتوي على مرفقات، وهي مشابهة لـ ()is_single() || is_page() || is_attachment حيث أن || تعني "أو".
• ()is_archive سيتم إرجاع قيمة صحيحة إذا كانت الصفحة الحالية عبارة عن أرشيف مهما كان نوعها.
• ()is_main_query سيتم إرجاع قيمة صحيحة إذا كان الاستعلام الحالي هو الاستعلام الرئيسي لهذه الصفحة.

مبهمة ومخادعة

• ()is_admin سيتم إرجاع قيمة صحيحة إذا كُنت في منطقة الإدارة من موقع ووردبريس، بعض الأشخاص يعتقد أن هذا الوسم لمعرفة هل المستخدم الحالي من المدراء أم لا، وهذا الأمر خاطئ.
• ()is_dynamic_sidebar سيتم إرجاع قيمة صحيحة إذا كان الشريط الجانبي الحالي (ويدجت أو مناطق) لديه أية ودجات مفعلة.
• ()is_home هذا الوسم مربك قليلا، سوف تعتقد للوهلة الأولى أنه لمعرفة هل أنت في الصفحة الرئيسية أم لا مثل http://www.example.com. لكن هذا ليس صحيح لأن هذا الوسم لمعرفة هل أنت في صفحة الرئيسية للتدوينات أم لا لأنه في بعض الأحيان قد تكون الصفحة الرئيسية للموقع ليس هي نفسها للتدوينات.
• ()is_front_page سيتم إرجاع قيمة صحيحة إذا كانت الصفحة التي أنت فيها هي الصفحة الرئيسية سواء أن كانت هي نفسها للتدوينات أو صفحة تابعة للمدونة.

قمنا بعرض جزء فقط من الوسوم الشرطية، إذا أردت المزيد يمكنك زيارة القائمة الكاملة.

بعض الإستخدامات للوسوم الشرطية في ووردبريس

هنالك الكثير من الإستخدامات للوسوم الشرطية وسنقوم الآن باستعراض أشهرها وأكثرها استعمالا.

استخدام الوسوم الشرطية في القوالب

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

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

/* الوسط: داخل ملف single.php */
<?php if ( ! is_page() ): ?>
    <span class="meta-date">
        <?php the_date(); ?>
    </span>
<?php endif; ?>

ملاحظة حول الوسوم الشرطية والقالب الهرمي

إن القالب الهرمي مشابه بالأساس لـشجرة القرار التي يمكنك بناؤها باستعمال الوسوم الشرطية. ويمكنك أيضا وضع كامل القالب في index.php واستخدام هذه الوسوم لعمل ما يعمله القالب الهرمي.

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

إدراج ورقة أنماط خاصة أو ملفات جافا سكريبت

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

add_action( 'wp_enqueue_scripts', 'wpshout_special_page' );
function wpshout_special_page() {
    if ( is_page( 'special-page' ) ) {
        wp_enqueue_script( 
            'special_js', 
            get_stylesheet_directory_uri().'/special.js'
        );
        wp_enqueue_style( 
            'special_css', 
            get_stylesheet_directory_uri().'/special.css'
        );
    }
}

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

لاحظ أن ()is_page ستقوم باختبارين:

• الأول للتأكد من أن المشاركة من نوع صفحة.
• والثاني هل لصفحة special-page اسم للطيف، معناها هل هي slug ؟ ويقصد بها أن الرابط يحتوي على عنوان الصفحة مثلا في هذا الرابط، سيكون slug هو wordpress-203. ولاختبار هذا قمنا بتمرير 'special-page' إلى ()is_page كمعامل.

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

()is_admin يمكن استخدامه أيضا فهو حالة أخرى حيث تحتاج الإضافات للقيام بعمليات اختبار مماثلة.

ملاحظة عن الوسوم الشرطية والحالة العامة

الوسوم الشرطية تستطيع الوصول إلى الحالة العامة (Global State) لووردبريس (طريقة عمل الأشياء في الخلفية) وهذه الحالة يجب أن يتم وضعها قبل أن تستطيع استخدامها، لكن لا يمكنك الاعتماد كليا على استعمال الوسوم الشرطية حتى تتأكد أن عملية المصنع الخاصة بووردبريس قد فعّلت الإجراء (action) المسمى posts_selection. (هنا لائحة الكاملة بالإجراءات المفعلة من قبل ووردبريس وترتيبها).

هذا يعني أن بعض الإجراءات التي يتم استخدامها عادة لا يمكن استخدامها بالتوازي مع الوسوم الشرطية، ومن أشهر هذه الإجراءات: setup_theme، init، register_sidebar و pre_get_posts. ومع ذلك، حوالي نصف الخُطّافات (hooks) وجميع القوالب تعمل جيدا بعد أن يتم تحميل الوسوم الخاصة بالقوالب، وسوف تكون مفيدة جدا هناك.

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

الوسوم الشرطية: تعلمها، استخدمها، وأحبها

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

ترجمة وبتصرف للمقال: WordPress’s Conditional Tags لصاحبه David Hayes.

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

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

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

يجب علينا القيام بثلاثة خطوات حتى نتمكن من ترجمة السلاسل النصية لعناصر الواجهة:

1. اختر، صرّح، و استخدم "مجال النص".
2. استخدم وظائف مناسبة لسلاسلك النصية ومجال النص المختار.
3. سيسمح لك هذا بإنشاء ملفات الترجمة.

بفضل ملفات الترجمة هذه، ستسمح للناس بترجمة قوالبك و إضافاتك.

ما هو "مجال النص" ؟

مجال النص هو "ترجمة مساحة الأسماء"  (translation namespace) لإضافاتك أو ثيماتك وهي طريقة لوردبريس لفصل قائمة من "السلاسل النصية لترجمتها" من بقية السلاسل النصية.
وتكمن أهمية مجال النص في أن بعض السلاسل النصية قد تعني معاني كثيرة في الإضافات والقوالب، فمثلا كلمة "!Let’s go" قد تعني "Create a membership account" في سياق وقد تعني "Start the survey" في سياق آخر.

لذلك بعد تعريف مجال النص، واستخدامه مع "gettext" أو مع دوال الترجمة التي سوف نقوم بشرحها فيما بعد. (إن مشروع gettext جزء أساسي من طريقة عمل نظام الترجمة في الووردبريس)
إذا أردت أن تضع مجال النص في إضافتك أو في قالبك في الجزء العلوي للتعليقات الموجود في ملف style.css للقوالب أو في ملف PHP الرئيسي لإضافتك. فسيكون مشابهًا لهذا بالنسبة للقوالب:

<?php
/*
Plugin Name: Pretend Plugin
[Other comment-block information goes here]
Text Domain: wpshout
*/

أما للقوالب فسيكون مشابهًا لهذا:

/*
Theme Name: Pretend Theme
[Other comment-block information goes here]
Text Domain: wpshout
*/

دوال Gettext: أبقِ ()__ و ()e_ و ()x_ و ()n_ صحيحة

لجعل النصوص الخاصة بك قابلة للترجمة، تحتاج إلى تمرير دالة سوف تقوم باستبدال "!Let’s go" مع ترجمتها باللغة الإسبانية أو العربية أو الفرنسية أو غيرها، ولتسهيل هذا الأمر، يقوم ووردبريس بإعطاء أسماء قصيرة جدا للدوال التي تقوم بهذه الوظيفة.

الدالة ()__

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

echo __(
    'WPShout is a great WordPress site!',
    'wpshout'
);

الطباعة الذاتية بواسطة () e_

الدالة الأولى ستقوم بإرجاع نص فقط ويجب عليك طباعة (عرض) النص بنفسك، فإذا كان هذا يزعجك فيمكنك استخدام ()e_ فهي مثل ()__ echo . ستقوم هذه الدالة باختصار كتابة بعض الأحرف، لكنها لن تقوم بأي شيئ آخر، وهذا مثال تطبيقي على استخدام هذه الدالة:

_e(
    'WPShout is a great WordPress site!',
    'wpshout'
);

والآن سنبدأ بالتعامل مع الجوانب الدقيقة للترجمة.

توفير نص للشرح بواسطة ()x_

في بعض الأحيان كلمة أو جملة تكون مبهمة وصعبة الترجمة فقد تعني العديد من المعاني، فمثلا كلمة "post" قد تعني اسما مثل "مشاركة" أو "تدوينة" وقد تعني فعلا مثل "نشر" (to post - to publish).
على عكس الدالتين السابقتين، يمكنك بواسطة ()x_ وضع نص لشرح الكلمة أو الجملة مثل المثال التالي:

_x(
   'Post',
   'verb, as in "to publish"',
   'wpshout'
);

النص الأوسط لن يظهر للمستخدم، لكنه سيظهر للمترجم حتى يفهم النص. (يذكر أنه توجد دالة ()ex_ و التي تجمع ما بين e_ و x_).

الجمع بواسطة ()n_

من المشاكل التي قد تواجهها في الترجمة هو الجمع. ففي اللغة الإنجليزية، "I have 1 Comment" (أنا أملك 1 تعليق) أو "I have 3 Comments" (أنا أملك 3 تعليقات)، لأجل معالجة مشكلة جمع كلمة تعليق، ووردبريس يوفر لك دالة ()n_ التي ستقوم بمعالجة الفرق بين الإثنين.
في العادة، عندما تستخدم دالة ()n_ سوف تحتاج إلى استدعاء دالة الكتابة ()printf. (أو sprintf التي تقوم بإرجاع سلسلة نصية على عكس printf التي تقوم بطباعة النص).
وهذه الدوال ستقوم باستبدال قيمة في سلسلة نصية مع قيمة تم تمريرها لهم. لتفهم أكثر أنظر للكود أدناه:

printf(
    _n(
        'One comment',
        '%s comments',
        $comments,
        'wpshout'
    ),
    $comments
);

ستلاحظ أننا استخدمنا قيمة عددية مسندة إلى متغير comments$ مرتين. نفترض أن comments$ تمتلك قيمة "3". في المرة الأولى استخدمنا comments$ مع n__ لتحديد هل سنستخدم الجمع أو لا، وبما أن 3 أكبر من 1 سوف يختار " s% comments" بدلا من "One comment".
أما في المرة الثانية فاستخدمناها مع printf لوضع الرقم في السلسلة النصية، عن طريق استبدال s% بـ 3 والتي هي قيمة المتغير comments$، لتكون الجملة الكاملة المطبوعة هي "3 comments".

دوال Gettext أخرى

سوف نقوم بشرح جميع الدوال المهمة والأساسية، وهذا لا يعني أنه لا توجد دوال أخرى جديرة بالاهتمام:

• ()__esc_attr: هذه الدالة تقوم بنفس وظيفة ()__ لكنها سوف تراعي ()esc_attr (سمة الخروج للـ HTML) لدواعي السلامة. (يوجد أيضا دالة ()esc_attr_e و دالة ()esc_attr_x).
• ()__esc_html: نفس الشيء مع هذه الدالة، ففي سبيل السلامة يمكنك الجمع بين سمة الخروج للـ HTML وبين ترجمتك. (و بالطبع توجد دالة ()esc_html_e و دالة ()esc_html_x).
•  ()n_noop_ : هذه الدالة تقوم بنفس وظيفة دالة ()n_ لكن بدون عمليات.

تسليم الترجمة إلى جافا سكريبت عن طريق دالة ()wp_localize_script

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

wp_localize_script(
    'wpshout-js',
    'strings',
    array(
        'hello' => __( 'Hello!', 'wpshout' );
    )
);

وللوصول إلى هذه القيم عن طريق ووردبريس، فستقوم بشيء مثل:

alert(strings.hello);

تمتلك دالة ()wp_localize_script ثلاثة معاملات:

1. المعرّف (handle) الذي استخدمناه في ()wp_enqueue_script (أو ()wp_register_script) للجافا سكريبت التي نقوم بترجمتها.
2. اسم كائن جافا سكريبت الذي نريد أن ترتبط به ترجمتنا.
3. مصفوفة (array) مترابطة للترجمات، مع مؤشر index أو اسم خاص كمفتاح و قيمة كسلسلة نصية ابتدائية لاستخدمها.

يتم التعامل مع الترجمة نفسها عن طريق نفس دوال PHP التي شرحناها في الجزء السابق من الدرس.

ما هي ملفات POT ،PO و MO ؟

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

يعتبر هذا الجزء صعبا بالنسبة لي، فببطء يقوم نظام ووردبريس ببناء حلول أكثر قوة و أكثر إفادة للتعامل مع العمل الحالي للترجمة (أنظر إلى GlotPress ،translate.wordpress.org و the Polyglot Make blog) لكن يبقى هذا الجزء صعبا للمستخدم ذا الخبرة المتوسطة، على الرغم من أننا سنقوم بشرح أساسياته لكننا لن نخوض في التفاصيل، بالنسبة لي اعتدت على استخدام Poedit كمحرر للترجمة.

مهما كانت الطريقة الذي اعتدت بها أن تقوم بإنشاء وتعديل و قراءة ملفات الترجمة، يوجد ثلاثة أنواع أساسية من ملفات الترجمة:

• ملفات pot.: الملفات الرئيسية للإضافات والقوالب، والتي قامت بجمع جميع السلاسل النصية من الدوال ()s__ وغيرها.
• ملفات po.: هذه الملفات عبارة عن نص ترجمة السلاسل النصية الإنجليزية إلى اللغة المستهدفة، نادرا ما سوف تقوم بتعديل واحدة مباشرة (لأن الصيغة بها الكثير من الكلمات والرموز المبهمة والغريبة) لكن يمكنك فتحها باستخدام محرر نصوص والقيام بتعديلات سريعة للترجمة.
• ملفات mo.: الترجمة النهائية من اللغة الإنجليزية إلى اللغة المستهدفة، وهذه الملفات عبارة عن ملفات ثنائية (binary files) تستخدم وتقرأ عن طريق ووردبريس، لذلك عندما تقوم بفتحها مع محرر النصوص لن تستطيع معالجتها، لذا إذا أردت القيام بذلك يجب عليك العودة إلى ملفات PO و التعديل عليها و إعادة إنشاء ملفات MO.

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

ماذا تعلمنا حول تدويل كود ووردبريس

لقد قمنا في هذا الدرس بتغطية الأجزاء الثلاثة الرئيسية لجعل كود ووردبريس الخاص بك جاهزا للترجمة: اختر مجال النص، استخدم دوال gettext ومن ثم أحصل على ملف POT لصنع ملفات الترجمة PO و MO. الخطوات سهلة و قابلة للتنفيذ، ولها تأثير كبير للناطقين بغير اللغة الإنجليزية، أو أولئك الذين يحسون براحة أكبر عند استخدامهم لغة أخرى تعلموها مؤخرا.

ترجمة -وبتصرف- للمقال Making plugins and themes translation ready لصاحبه: David Hayes.

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

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

1- محاولة بناء موقعك من الثيم الافتراضي

سنناقش في هذا الدرس أهمّية تحديث كلّ شيءٍ متعلّق بموقع ووردبريس الخاصّ بك إلى آخر الإصدارات المتوفّرة وأهميّة التحديثات بشكلٍ عام، وهو من أهمّ الأمور التي يمكنك القيام بها لزيادة حماية وأمان موقعك.

لماذا نقوم بالتحديث؟

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

اقتباس

تحديثات سكربت ووردبريس مهمّة بنفس أهمّية تحديثات أنظمة التشغيل والتطبيقات الأخرى، يتم دومًا اكتشاف ثغراتٍ جديدة في البرمجيات كلّ فترة، ويتم مع ذلك إرسال ترقيعاتٍ جديدة لترقيع هذه الثغرات كلّ فترة إلى أجهزة المستخدمين، مما يجعل التطبيق أكثر أمنًا" - Ken Westin الخبير الأمن في Tripwire, Inc.

أنواع التحديثات

قبل أن نتابع، من المهمّ أن نفهم أنواع التحديثات المختلفة المتوفّرة في سكربت ووردبريس. يشير Tony Perez في تدوينة حديثة إلى أنّه هناك 3 أنواع مختلفة من التحديثات: تحديثات الأمان، الترقيعات والإصدارات الرئيسية.

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

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

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

الفشل بالتحديث يعني مشكلة أعظم

كما ذكرنا سابقًا، عدم قيامك / فشلك بتحديث أيّ إضافات أو قوالب ووردبريس مثبّتة على موقعك قد يعرّضك لخطرٍ كبير، وما قد لا تفهمه هو "لماذا"؟

اقتباس

بمجرّد أن يتوفّر ترقيعٌ معيّن كتحديث، يتزايد الخطر على المستخدمين الذين لم يقوموا بالتحديث بصورةٍ كبيرة، لأنّ المخترقين سيكونون قادرين على قراءة الشفرة المصدرية للترقيع ومعرفة الثغرة الحقيقية وبالتالي يمكنهم استغلالها ضدّ مواقع ووردبريس التي لم تقم بالتحديث والترقيع. هناك فترة زمنية قصيرة ما بين توفّر الترقيع كتحديث لووردبريس وما بين قيام المُخترقين بالبدء باستغلال هذه الثغرة على مواقع ووردبريس التي لم تقم بالترقيع، وهذا هو الوقت الذي يجب على المستخدمين الانتباه إليه، حيث أنّ مجرّد الانتظار إهمالًا يتركك عرضةً لهجماتٍ أكثر - Ken Westin.

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

إدارة تحديثات ووردبريس

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

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

الخاتمة

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

ترجمة -وبتصرف- للمقال: The WordPress Developer’s Guide to Security: Updates لصاحبه: Brenda Barron.

يُنفّذ ووردبريس استعلامًا في كل صفحة من صفحات الموقع، ليجلب البيانات من قواعد بيانات (databases) الموقع ومن ثُمّ يعرضها بالطريقة الّتي يحدّدها القالب (theme) المُستخدَم وذلك باستخدام حلقة التكرار (loop)، ويُشار إلى هذا الاستعلام بالاستعلام الرئيسي main query.

سيَستخدم ووردبريس ملفّ القالب (template) المُلائم وذلك اعتمادًا على نوع الصّفحة الّتي يتمّ عرضها، بمعنى أنّ حلقة (loop) قد تتغيّر بناءً على المُحتوى، ولكنّه سيُنفّذ استعلامًا دائمًا لجلب البيانات من قاعدة البيانات.

يُرغب أحيانًا في تغيير طريقة عمل الاستعلام، فعلى سبيل المثال في الصّفحة الرئيسيّة للمدوّنة قد يُرغب في استثناء منشورات من فئة (category) مُعيّنة، أو قد يُرغب في عرض قائمة بالمنشورات على حسب الصنف بدلًا من الترتيب على حسب التاريخ في صفحة الأرشيف (archive page)، كما من المُحتمل جدًا أنّ يُرغب في إضافة استعلامات إضافيّة إلى صفحات (pages) الموقع، أو إضافة قائمة بالمنشورات الأخيرة (recent posts) أو المنشورات ذات الصِلة بمنشورات أخرى، أو قد يُرغب في إنشاء ملفّ قالب (template) يستبدل الاستعلام الرئيسي (main query) باستعلام مُخصّص وجديد كليًّا.

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

سيتطرّق هذا الدليل إلى الأمور التّالية:

• متى يُستخدم الاستعلام المُخصّص، ومتى يُخصّص الاستعلام الرئيسي ومتى يتمّ إنشاء استعلام جديد.
• الطرق الخمس لإنشاء استعلامات مُخصّصة، بما في ذلك الطريقة الّتي لا يجب أنّ تُستخدم ولماذا.

فهم الأساسيات

يجب الإلمام ببعض المصطلحات قبل الدخول في التفاصيل وهي ضروريّة لمن لم يُنشئ استعلامات مُخصّصة من قَبل.

• الاستعلام (query) وهو طريقة يَستعين بها ووردبريس لجب البيانات من قاعدة بيانات الموقع، وتتضمّن هذه البيانات المنشورات posts، المرفقات attachments، التعليقات comments، والصّفحات pages، أو أي مُحتوى تمّت إضافته إلى الموقع.
• الحلقة (loop) وهي شيفرة/كود يستخدمها القالب (theme) (أو أحيانًا الإضافة plugin) لتحديد كيفيّة عرض نتائج الاستعلام على الصّفحة، فعلى سبيل المثال قد تُضمِّن الحلقة في الصّفحة الرئيسيّة عنوان كل صفحة (title)، مُلخص كل تدوينة (extract)، ربّما صورة مُميّزة/بارزة، ورابط صفحة المنشور (والّذي يُدعى permalink أو الرابط الثابت).
• ملفّات القالب (template files): وتُستخدم من قِبل القالب (theme) لعرض الصفحات لكل نوع من أنواع المُحتوى، مع العلم أنّ كل قالب (theme) يملك ملفّات قالب (template) تختلف عن الآخر، ولكن يجب على القالب (theme) أنّ يتضمّن ملفّ index.php رئيسي، وغالبًا على الملفّ page.php للصفحات الثابتة static pages، والملفّ single.php للمنشورات المُنفردة single posts، والملفّ archive.php لصفحات الأرشيف، وربّما الملفّ category.php للتصنيفات، والملفّ tag.php للوسوم، وغيره من الملفّات وللمزيد من التفاصيل يُمكن العودة إلى الصّفحة التّالية في التوثيق الرسمي.
• الوسوم/الدّوال الشرطيّة: والّتي من المُمكن أنّ تُستخدم في ملفّات القالب (template) أو من قِبل الإضافات plugins لتحديد نوع الصّفحة الّتي يتمّ عرضها، فعلى سبيل المثال الدّالّة/الوسم ()is_page تُحدّد فيما إذا كانت الصّفحة الّتي يتمّ عرضها ثابتة (static) أم لا، والدّالّة/الوسم ()is_home تُحدّد فيما إذا كانت الصّفحة هي صفحة البداية home page، ويوجد العديد من هذه الوسوم/الدّوال الشرطيّة منها ما يُحدّد فيما إذا كان المُستخدم مُسجّلًا دخوله logged in أم لا، وغيره من هذه الدوال.

متى يجب استخدام الاستعلام المخصص في ووردبريس

يوجد نوعان من الاستعلامات المُخصّصة:

• الاستعلام الرئيسي بعد تعديله.
• استعلامات جديدة كليًّا لجلب مُحتوى مُختلف/مُحدّد أو محتوى إضافي.

التعديل على الاستعلام الرئيسي Main Query في ووردبريس

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

أمثلة للحالات الّتي من المُمكن بها استخدام استعلام مُعدّل:

• في الصّفحة الرئيسيّة للمدوّنة، عرض أنواع منشورات مُخصّصة بالإضافة إلى المنشورات.
• في صفحة أرشيف التصنيفات category، عرض منشورات من نوع مُحدّد فقط.
• في صفحة أرشيف التصنيفات، ترتيب المنشورات ترتيبًا أبجديًا بدلًا من الترتيب الافتراضي.

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

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

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

أمثلة للحالات الّتي من المُمكن بها إنشاء استعلام جديد عديدة ومُختلفة، ولكن أبرزها:

• عند تنفيذ حلقتين two loops في صفحة الأرشيف: إحداهما للمنشور الأوّل والأخرى للمنشورات اللاحقة، بهدف عرض مُحتوى مُختلف للمنشور الأوّل، مثلًا عندما يكون المطلوب أنّ يتضمّن المنشور الأوّل مُلخّص أو صورة مميّزة فقط بدون بقيّة المنشورات، ولكن إن كان المطلوب هو تنسيق المنشور الأوّل بشكل مُختلف فقط، فمن غير المُستحسن استخدام حلقات (loops) متعدّدة في ذلك، بل من المُفترض استخدام CSS لاستهداف المنشور الأوّل في التنسيق دون بقيّة المنشورات.
• في صفحة المنشور المنفردة (single post)، وذلك عند تنفيذ حلقة (loop) إضافيّة لعرض المنشورات الأخيرة (أو المنشورات المُميّزة) وذلك أسفل محتوى المنشور، بغرض تشجيع القارئ لقراءة المزيد.
• عند إضافة لافتة (banner) مربوطة مع منشور مُميّز منفرد single featured post (أو لجميع المنشورات المُميّزة) في أعلى كل صفحة من صفحات الموقع، كما هو الأمر عند إضافة منشور يُروّج إلى مُنتج جديد، وهذه الطريقة هي أكثر مرونة من إضافة لافتة ثابتة (static banner) بما أنّه من المُمكن تعديل المنشور المُستخدَم بسهولة.
• عند إنشاء قائمة من الصفحات في نفس القسم (section) من الموقع، وذلك عندما يَملك الموقع بُنية مُعتمدة على صفحات هرميّة/شجريّة، فمن المُستحسن وضعها في الشريط الجانبي sidebar.
• إنشاء قالب صفحة page template باستعلام مخصّص كليًّا لعرض المنشورات على حسب التصنيف (taxonomy) أو نوع المنشور (أو ربّما حسب المعيارين).
• في صفحة أرشيف نوع المنشور (post type archive page)، وذلك لعرض المنشورات حسب التصنيف (category) بدلًا من التاريخ.
• إنشاء لافتة (banner) في الشريط الجانبي sidebar للربط إلى المنشور الأخير مع صورته الرئيسيّة.
• إنشاء صفحة لعرض المنشورات المُرتبطة فيما بينها وبأكثر من تصنيف، مثلًا عرض المقالات البرمجيّة وللغة روبي (Ruby) مثلًا ولكاتب مُحدّد.
• إنشاء نوع منشور لمحتوى الشريط الجانبي واستعلام منشورات هذا النوع في الشريط الجانبي، الأمر الّذي يُساعد أصحاب الخلفيّة غير البرمجيّة في إضافة مُحتوى إلى الشريط الجانبي بمرونة أكثر فيما لو تمّ استخدام ودجت (widget).

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

طرق إنشاء استعلام مخصص Custom Query

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

الطرق لتعديل الاستعلام الرئيسي هي:

• استعمال الخطّاف الإجرائي pre_get_posts، والّذي يسمح للمطوّر في التعديل على الاستعلام الرئيسي عن طريق إضافة دالّة إلى ملفّ الدّوال الخاصّ بالقالب (theme) أو بواسطة إضافة (وليس في ملفّات القالب template) ويُمكن دمجه مع تصريح شرطي conditional statement لتأكّد من أنّه يُنفّذ فقط على الصفحات الّتي تعرض أنواع مُحدّدة من المُحتوى.
• استعمال ()query_posts، مع العلم أنّ وجود هذه الدّالّة ضمن القائمة لتوضيح لماذا لا يجب استخدامها، فالدّالّة ()query_posts هي دالّة غير عمليّة ولا يُمكن الاعتماد عليها في تعديل وتحسين الاستعلام الرئيسي، فبدلًا من تحسين وتعديل الاستعلام الرئيسي فهي تجلب الاستعلام الرئيسي ومن ثُمّ توقفه وتبدأ مرّة أخرى بإعادة تنفيذه مع التغيرات المُدخلة، الأمر الّذي سيؤثّر على أداء الموقع، ومن المُمكن جدًا أنّ لا تعمل كما يجب لدى استخدامها مع التّصفيح pagination.

تسمح الطرق المتبقية في إنشاء استعلام جديد:

• باستخدام الصنف WP_Query، وهي طريقة مرنة جدًا في إنشاء استعلام جديد، ويُستخدم هذا الصنف (class) عند إنشاء حلقة (loop) ثانية في ملفّ القالب (template file) أو عند إنشاء ملفّ قالب باستعلام مُخصّص كليًّا لاستبدال الحلقة الرئيسية (main loop)، ولكن يجب الحذر في استخدامه، وتأتي الخطورة في عدم تصفير (reset) الاستعلام بعد تنفيذ الحلقة (loop)، والّذي يعني أنّ ووردبريس لن يكون قادرًا على التعرّف بشكلٍ صحيح ما نوع الصّفحة الّتي يتمّ عرضها، ولكن من المُمكن حل هذه المشكلة بسهولة.
• دالّة/وسم القالب ()get_posts، وتُستخدم في ملفّ القالب (template) (بما في ذلك الشريط الجانبي sidebar وذيل الصّفحة على سبيل المثال) لجلب قائمة المنشورات، ويَستخدم الصنف WP_Query لعمل ذلك، ويُمكن استخدام مُعامِلات (parameters) معه لتحديد المنشورات المطلوبة.
• دالّة/وسم القالب ()get_pages، والّتي تعمل بنفس طريقة عمل ()get_posts، ولكن في جلب الصفحات بدلًا من المنشورات.

سيتم التطرّق إلى أهم هذه الطرق بمزيد من التفصيل بعد أنّ تمّ عرضهم بشكل سريع.

الخطاف الإجرائي pregetposts

إن الدّالّة pre_get_posts هي خطّاف إجرائي (action hook)، وبالتالي يُمكن ربط دالّة معها لجعل شيء ما يحدث في الوقت الذي يُنفّذ ووردبريس الإجراء pre_get_posts، وكما هو واضح، يُنفّذ ووردبريس هذا الإجراء (action) مباشرةً قبل جلب المنشورات من قاعدة البيانات، ولذلك فإن أي دالّة يتمّ ربطّها معها ستؤثّر في كيفيّة جلب ووردبريس لتلك المنشورات.

إن استخدام الدّالّة pre_get_posts يتطلّب إنشاء دالّة ومن ثُمّ ربطّها مع الإجراء، كما في التّالي:

<?php
function my_function() {

    // contents of function go here
}
add_action( 'pre_get_posts', 'my_function');
?>

• أوّلًا، تمّ إنشاء الدّالّة وبالاسم my_function وما ستفعله هذه الدّالّة سيكون داخل الحاصرتين (braces).
• ثانيًا، تمّ ربط تلك الدّالّة مع الخطّاف pre_get_posts باستخدام الدّالّة ()add_action، وبدون ذلك لن تعمل الدّالّة.

سيتمّ الحاجة غالبًا بالإضافة إلى ما سبق، إلى تضمين وسم/دالّة شرطيّة داخل الدّالّة المنشأة، فبدونها لن يقوم ووردبريس بتنفيذ الدالة المُنشأة كل مرّة يتمّ فيها جلب المنشورات، بما في ذلك عند التعامل مع المنشورات في الصفحات الإداريّة (admin)، وعليه ستكون الدالة المُنشأة بالشكل التّالي:

<?php
function my_function() {

    if ( !is_admin() && $query_>is_main_query() ) {
        // contents of function go here
    }
}
add_action( 'pre_get_posts', 'my_function');
?>

تمّ في الشيفرة السابقة، التأكّد من أنّ الصّفحة ليس صفحة إداريّة (admin) وأيضًا أنّ الاستعلام الّذي يتمّ تنفيذه هو الاستعلام الرئيسي (main query)، ومن المهم التأكّد من أن ووردبريس يُنفّذ الاستعلام الرئيسي تجنبًا للمشاكل المحتملة عند تنفيذ الدّالّة من أجل استعلامات إضافية قد تم إنشاؤها، كما يُمكن إضافة وسوم/دوال شرطيّة إضافيّة هنا كما سيتمّ لاحقًا.

إدراج أنواع منشورات مخصصة في صفحة المدونة الرئيسية

يَعرض ووردبريس بشكلٍ افتراضي قائمة بالمنشورات فقط في صفحة البداية (homepage) فإن تمّ إنشاء نوع منشورات مخصصة، فسيفترض ووردبريس أنّ المُراد هو عرضها في مكان آخر وعدم تضمينهم هنا، ولكن أحيانًا قد يُرغب في عرض أكثر من نوع منشور واحد في صفحة البداية (home page) وفي هذه الحالة يجب استخدام الخطّاف pre_get_posts.

ويتم ذلك عبر إضافة الشيفرة التّالية إلى الملفّ functions.php الخاصّ بالقالب (theme) أو الإضافة المُنشأة.

<?php
function my_function() {

    if ( is_home() && $query->is_main_query() ) {
        $query->set( 'post_type', array( 'post', 'custom_post_type') );
        return $query;
    }
}
add_action( 'pre_get_posts', 'my_function');
?>

تتأكّد الشيفرة السابقة من أمرين اثنين، أوّلًا فيما إذا كان الاستعلام هو الاستعلام الرئيسي وثانيًا فيما إذا كانت الصّفحة هي صفحة البداية (باستخدام الدالة ()is_home) بعد ذلك يتمّ تعيين (set) الاستعلام ليتضمّن نوعين من المنشورات: هما 'post' و 'customposttype'، ليكونا نوع المنشور المُخصّص، مع مُلاحظة وجوب تضمين 'post' هنا إن كان المرغوب من صفحة البداية أن تَعرض المنشورات أيضًا بالإضافة إلى نوع المنشور المخصّص، وفي حال إضافة custom_post_type فقط، سيتمّ استبدال السلوك الافتراضي وعرض المنشورات من نوع المنشور المخصّص، وقد يكون هذا المرغوب في بعض الحالات ولكن ليس في المثال الحالي.

عرض منشورات من نوع المنشور المخصص في صفحة أرشيف التصنيف

يَفترض هذا المثال أنه عندما تمّ تسجيل نوع المنشورات المُخصّصة، فقد تمّ منحها دعمًا للتصنيفات (categories) وتم إسناد التصنيفات إلى منشورات نوع المنشور المُخصّص، ولتعديل أرشيفات التصنيفات لكي تَعرض منشورات نوع المنشور المُخصّص يُستخدم التّالي:

<?php
function my_function() {

    if ( is_category() && $query->is_main_query() ) {
        $query->set( 'post_type', 'custom_post_type' );
        return $query;
    }
}
add_action( 'pre_get_posts', 'my_function');
?>

تتأكّد الشيفرة السابقة من أنّ الاستعلام المُنفّذ هو الاستعلام الرئيسي والصفحة هي أرشيف التصنيفات وذلك باستخدام الدالة ()is_category، ومن ثُمّ تمّ التعديل على الاستعلام ليجلب منشورات نوع المنشور المُخصّص، وبما أنّه لم يتمّ تضمين 'post' هنا، فإن المنشورات الاعتياديّة لن يتمّ عرضها في أيٍ من أرشيفات التصنيفات، بالإضافة إلى أنّه لن يتمّ الحاجة إلى استخدام مصفوفة بما أنّه تمّ تحديد نوع منشور واحد.

إنّ كان المطلوب هو التحديد بدقة أكبر فيُمكن تحديد نوع مُعيّن من التصنيفات كما في التّالي:

<?php
function my_function() {

    if ( is_category( 'category-slug' ) && $query->is_main_query() ) {
        $query->set( 'post_type', 'custom_post_type' );
        return $query;
    }
}
add_action( 'pre_get_posts', 'my_function');
?>

سيتمّ في الشيفرة السابقة التعديل الاستعلام الرئيسي في صفحة الأرشيف category-slug فقط، حيثُ أنّ category-slug هو الاسم اللطيف (slug) للتصنيف (category).

تغيير طريقة ترتيب المنشورات

لن يتعامل المثال الأخير مع ما هي البيانات الّتي يتمّ استعلامُها بل مع كيف يتمّ عرضها/خَرْجُها (output)، فمثلًا في صفحات أرشيف التصنيفات (category archive) وعند عدم الرغبة في ترتيب المنشورات بواسطة التاريخ ولكن بالترتيب الأبجدي، يُمكن استخدام pre_get_posts كما في التّالي:

<?php
function my_function() {

    if ( is_category() && $query->is_main_query() ) {
        $query->set( 'orderby', 'title');
        $query->set( 'order', 'ASC' );
        return $query;
    }
}
add_action( 'pre_get_posts', 'my_function');
?>

تمّ في الشيفرة السابقة استعمال المُعامِل orderby والمُعامِل order لتحديد بناءً على ماذا ستُرتّب المنشورات وكيف ستُرتّب وذلك عند عرضها، وللمزيد من المُعامِلات (parameters) الّتي يُمكن استخدامها مع pre_get_posts يُمكن الرجوع إلى التوثيق الرسميّ للصنف WP_Query والّذي يستخدم نفس المُعامِلات.

الصنف WP_Query

يُعتبر الصنف WP_Query الطريقة الأفضل لكتابة استعلام مُخصّص، ويُستخدم عند الرغبة في استبدال الاستعلام الرئيسي (main query) باستعلام جديد أو عند الرغبة في إضافة استعلام جديد بالإضافة إلى الاستعلام الرئيسي.

أجزاء الصنف WP_Query:

• المُعطيات (arguments) للاستعلام، وذلك باستخدام المُعامِلات (parameters) بشكل مُشابه إلى الّتي قد تُستخدم مع أجل pre_get_posts.
• الاستعلام نفسه.
• الحلقة (loop).
• الإنهاء: وذلك بإغلاق وسوم if و while، وتصفير (reset) بيانات المنشور.

ستكون الشيفرة على النحو التّالي:

<?php
$args = array(
    // arguments for your query
);

// the query
$query = new WP_Query( $args );

// The Loop
if ( $query->have_posts() ) :  while ( $query->have_posts() ) : $query->the_post() :
  // contents of the Loop go here

endwhile : endif;
/* Restore original Post Data */
wp_reset_postdata();
?>

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

سيتمّ إلقاء نظرة على مثال للتوضيح أكثر، حيثُ سيتمّ إضافة حلقة (loop) ثانية بعد محتوى المنشور في ملفّ القالب (template) المُسمّى single.php، لعرض قائمة بالمنشورات المُميّزة، حيثُ تمّ تعريف هذه المنشورات المُميّزة باستخدام التصنيف "featured" (مُميّز)، ولكل واحدة من هذه المنشورات سيتمّ عرض الصورة المُميّزة والعنوان (title) مع الروابط الّتي تُحيل إلى المنشور:

<?php
$args = array(
    'post_type' => 'post',
    'posts_per_page' => '4',
    'post__not_in' => array( $post->ID )
);

// the query
$query = new WP_Query( $args );

// The Loop
if ( $query->have_posts() ) { ?>

 <section class="recent-posts clear">
 <?php while ( $query->have_posts() ) : $query->the_post() ; ?>
     <article id="post-<?php the_ID(); ?>" <?php post_class( 'left' ); ?>>
         <a href="<?php the_permalink(); ?>" title="<?php the_title_attribute(); ?>">
             <?php post_thumbnail( 'thumbnail' );?>
         </a>

         <a href="<?php the_permalink(); ?>" title="<?php the_title_attribute(); ?>">
             <?php the_title(); ?>
         </a>
     </article>
 <?php endwhile; ?>

 </section>

<?php }
/* Restore original Post Data */
wp_reset_postdata();
?>

تَستخدم الشيفرة السابقة ثلاثة مُعطيات (arguments) لاستعلام البيانات:

• 'post_type' => 'post' لجلب المنشورات فقط.
• 'posts_per_page' => '4' لجلب أربعة منشورات فقط.
• (post__not_in' => array($post->ID' للتأكيد على أنّ المنشور الّذي يُعرض حاليًا غير مُضمّن.

ستُخرج (output) الشيفرة بعدها أربعة منشورات في حلقة (loop) والّتي تَعرض الصورة المُميّزة والعنوان (title) كلٍ محتوى داخل رابط يُحيل إلى صفحة المنشور، ومن المُمكن استخدام CSS للتنسيق، أو توضيعهم جنبًا إلى جنب أو في عرض شبكي (grid) أو حتّى جعل العنوان يتداخل مع الصورة.

وسم/دالة القالب ()get_posts

يُمكن اللجوء إلى get_posts عند عدم الحاجة إلى تلك المرونة الّتي يُقدمها الصنف WP_Query، وعليه فمن المُمكن الاستفادة منها في تطبيق المثال الأخير، مع العلم أنّ الوسم/الدالة get_posts ما هي إلا وسم قالب (template tag) يَستخدم الصنف WP_Query ويُمكن استخدامه بطريقة مُشابهة إلى WP_Query.

يُمكن إنشاء قائمة بالمنشورات الأربعة الأخيرة باستخدام ()get_posts كما تمّ مع WP_Query على النحو التّالي:

<?php
$args = array(
    'posts_per_page' => '4',
    'exclude' => array( $post->ID )
);

// get posts
$posts = get_posts( $args );

// check if any posts are returned
if ( $posts ) { ?>
    <section class="recent-posts clear">
        <?php foreach ($posts as $post ) { ?>

 <?php setup_postdata( $post ); ?>

 <article id="post-<?php the_ID(); ?>" <?php post_class( 'left' ); ?>>

 <a href="<?php the_permalink(); ?>" title="<?php the_title_attribute(); ?>">
 <?php post_thumbnail( 'thumbnail' );?>
 </a>

 <a href="<?php the_permalink(); ?>" title="<?php the_title_attribute(); ?>">
 <?php the_title(); ?>
 </a>

 </article>

 <?php } ?>

 </section>

<?php }
/* Restore original Post Data */
wp_reset_postdata();
?>

تُشبه الشيفرة السابقة إلى حدٍ كبير جدًا شيفرة مثال الصنف WP_Query السابقة، ولكن مع اختلاف طفيف:

• لا يجب على المُعطيات (arguments) أنّ تُضمّن نوع المنشور.
• تمّ استخدام المُتغيّر posts$ لتخزين خَرْج (output) المصفوفة باستخدام ()get_posts.
• بدلًا من التأكّد فيما إذا كان الاستعلام يملك منشورات، تمّ استخدام (if($posts في ذلك.
• بدلًا من استخدام حلقة (loop) معياريّة (standard)، تمّ استخدام (foreach ($posts as $post، والّتي ستُكرّر لكل صفّ (row) في المصفوفة.
• للوصول إلى جميع بيانات المنشور المطلوبة تمّ تضمين (setup_postdat($post.

بما أنّ الدّالّة ()get_posts تستخدم الصنف WP_Query، فلا فرق يُذكر بين الاثنين عامّةً، ولذلك يميل بعض المُطوّرين إلى استخدام الصنف WP_Query بما أنّه يُقدّم مرونةً أكبر، مع ذلك يُمكن أنّ تكون الدّالّة ()get_posts أكثر نفعًا عند الرغبة من التأكّد إن كان يوجد أي منشورات مع المُعطيات (arguments)، عندها يُمكن خَرْج (output) الشيفرة اعتمادًا على وجود أية منشورات، من دون الضرورة إلى استخدام حلقة (loop).

دالة/وسم القالب ()get_pages

تُشبه الدّالّة ()get_pages إلى حدٍ كبيرٍ الدّالّة ()get_posts وهي تستخدم الصنف WP_Query ولكن في جلب الصفحات الثابتة (static pages) بدلًا من المنشورات، ومن الأمثلة الّتي تُستخدم بها:

إن كان الموقع يملك مجموعة من الصفحات الهامّة ومن النوع top level، وكان الطلوب إضافة قائمة لها في الشريط الجانبي (sidebar) لكي يتمّ تنسيق روابطها وتشجيع الزوار إلى الذهاب إلى هذه الصفحات، فعندها وفي الملفّ sidebr.php يُمكن إضافة الشيفرة التّالية:

<?php
$args = array(
    'parent' => 0,
    'sort_order' => 'ASC',
    'sort_column' => 'post_title',
);

// get posts
$pages = get_pages( $args );

// check if any posts are returned
if ( $pages ) { ?>
 <ul class="sidebar-pages">
     <?php foreach ( $pages as $page ) { ?>
     <li> 
         <a href="<?php echo get_page_link( $page->ID ); ?>">
             <?php echo $page->post_title; ?>
         </a> 
     </li>
    <?php } ?>
 </ul>
<?php }
?>

تفاصيل الشيفرة السابقة هي كالتّالي:

• أوّلًا تمّ تعريف المُعطيات حيثُ أنّ parent' => 0' ستُعيد الصفحات الّتي هي بدون صفحة بداية، بينما بقيّة المُعطيات ستُحدّد كيف ستُرتّب هذه الصفحات.
• تمّ بعد ذلك استخدام ()get_pages وتمرير مصفوفة المُعطيات وتخزينها في المُتغيّر pages$.
• بعد ذلك تمّ التأكّد فيما إذا كان المُتغيّر pages$ يحتوي على أية بيانات وذلك باستخدام (if($pages.
• وفي حال توفّر الصفحات سيتمّ عرضها من خلال عناصر قائمة (list item).
• وبدلًا من استخدام ()setup_postdata كما تمّ مع ()get_pages، فقد تمّ استخدام المُتغيّر post$ مُباشرةً وبوسوم قالب (template) مُختلفة والّتي ستُخرج (output) الرابط والعنوان (title)، ومن الضروري استخدامها هنا بسبب عدم استخدام ()setup_postdata.
• وبسبب عدم استخدام ()setup_postdata فلا داعي لاستخدام ()wp_reset_postdata.

إن طريقة الشيفرة السابقة هي طريقة أكثر عمليّة في خَرْج (output) قائمة من الصفحات من طريقة استخدام الصنف WP_Query وبكل ما يملكنه من إمكانيات.

الختام

إن التعديل على الاستعلام الرئيسي أو كتابة استعلامات جديدة هي مهارة ليجب الاهتمام بها وتطويرها خاصّة إن كان المطلوب هو إنشاء قوالب (themes) مُخصّصة أو إضافات (plugins) أو تطوير مواقع مُعقّدة للعُملاء.

تمّ التطرّق إلى الطرق الخمس في إنشاء استعلامات مُخصّصة، ولكن أربعة منها فقط يُمكن استخدامها:

• pre_get_posts للتعديل على الاستعلام الرئيسي.
• WP_Query لإنشاء استعلامات مُخصّصة ومُعقّدة.
• ()get_posts و ()get_pages وذلك للاستعلامات المُخصّصة والبسيطة في جلب المنشورات والصفحات.

يُمكن الخلط والمزج بين الطرق السابقة وذلك لإنشاء مواقع ووردبريس مُتقدّمة ولعرض البيانات بالكيفيّة المطلوبة.

ترجمة -وبتصرّف- للمقال 5Simple Methods for Creating Custom Queries in WordPress لصاحبته Rachel McCollin.

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

في هذا المقال سنشرح صفحة المرفق مع كيفية إنشاءها.

ما هو المرفق؟

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

في الواقع، المرفقات هي مقالات من نوع مختلف – وهو "مرفق”. وهذه الطريقة في التخزين صُممت لتسهيل النفاذ والبحث، مثمرة عن تطوير أسهل وتقدم أسرع.

ما هي صفحة المرفق؟

صفحة المرفق هي صفحة منفردة. مصطلح الصفحة المنفردة هو مصطلح شامل، يتضمن أنواع مختلفة مثل صفحة المقال المفرد وصفحات المقال المنفرد المُخَصّص. وبما أن المرفق عبارة عن مقال، فهو أيضًا له صفحة منفردة، وتدعى صفحة المرفق.

الصفحة المنفردة الخاصة بك هي صفحة مُخَصّصة لمقالك، وتعرض العنوان، المحتوى، البيانات الوصفية، التعليقات وما شابه. بالمثل، لا بد أن تكون صفحة المرفق مُخَصّصة للمرفق المعروض. أي لو كان المرفق صورة فيجب أن تحتوي الصفحة على العنوان، الصورة، والوصف، وقد تتضمن التعليقات ومعلومات أخرى عن الصورة.

كيف تُعرض صفحة المرفق؟

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

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

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

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

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

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

كيف أصل إلى صفحة المرفق؟

أسهل طريق للوصول إلى صفحة المرفق هو الذهاب إلى قسم الوسائط في لوحة التحكم، ثم اختيار الصورة التي تريدها، وستجد خيار مشاهدة صفحة المرفق "View attachment page” تحت عنوان الصورة.

يمكنك أيضًا استنتاج رابط الصفحة بسهولة إذا كنت تعلم رابط المقال المرفق إليه، ويستخدم موقعك روابط دائمة واضحة. فمثلًا إذا كان رابط المقال هو "http://mywebsite.com/my-post/” واسم ملف الصورة شيء مثل "my-image.jpg”، فمن المحتمل أن يكون رابط صفحة المرفق للصورة هو "http://mywebsite.com/my-post/my-image/”.

كيف تنشء صفحة مرفق

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

ملف صفحة المرفقات

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

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

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

تخصيص صفحة المرفق

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

<h1 class="post-title"><?php the_title(); ?></h1>
<p class="post-byline">
  <?php _e('by','hueman'); ?> 
  <?php the_author_posts_link(); ?> &middot; 
  <?php the_time(get_option('date_format')); ?>
</p>

<?php if( get_post_format() ) { 
  get_template_part('inc/post-formats'); 
} ?>

<div class="clear"></div>

<div class="entry">
  <div class="entry-inner">
    <?php the_content(); ?>
    <?php wp_link_pages(array('before'=>'<div class="post-pages">'.__('Pages:','hueman'),'after'=>'</div>')); ?>
  </div>
  <div class="clear"></div>
</div><!--/.entry-->

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

<?php echo wp_get_attachment_image( get_the_ID(), 'large' ); ?>

<h1 class="post-title"><?php the_title(); ?></h1>

<div class="entry">
  <div class="entry-inner">
    <?php the_content(); ?>
  </div>
  <div class="clear"></div>
</div><!--/.entry-->

يوضح النص البرمجي بالأعلى المحتوى المُعدل الذي يقع ما بين وسميّ البداية والنهاية لعنصر post-inner. وقد استخدمت وظيفة ()wp_get_attachment_image لاستحضار الصورة بتوفير رقم ID للمقال الحالي – لا تنس أنه أيضًا رقم ID للصورة حيث أننا في صفحة المرفق – واخترت الحجم الكبير للصورة.

والآن أصبح لدينا العنوان والوصف بنفس تنسيق القالب الأصلي. وحذفت قسم البيانات الوصفية وترقيم الصفحات للمقال، الآن أصبح أفضل بكثير:

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

<div class="entry">
  <div class="entry-inner">
    <?php the_content(); ?>
    <p class='resolutions'> Downloads:
      <?php
        $images = array();
        $image_sizes = get_intermediate_image_sizes();
        array_unshift( $image_sizes, 'full' );
        foreach( $image_sizes as $image_size ) {
          $image = wp_get_attachment_image_src( get_the_ID(), $image_size );
          $name = $image_size . ' (' . $image[1] . 'x' . $image[2] . ')';
          $images[] = '<a href="' . $image[0] . '">' . $name . '</a>';
        }
        echo implode( ' | ', $images );
      ?>
    </p>
  </div>

  <div class="clear"></div>
</div><!--/.entry-->

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

الختام

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

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

هل وجدت هذا المقال مفيدًا؟ سنسعد بمعرفة آرائكم والرد على استفساراتكم في التعليقات.

مترجم بتصرف من مقال Creating an Advanced Attachment Page in WordPress لصاحبه Daniel Pataki.

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

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

مكونات صفحة لوحة التحكم

هناك مكونين أو ثلاثة لصفحة لوحة التحكم، حسب الوظيفة التي تبني عليها:

1. عنصر قائمة – رئيسي أو فرعي.
2. محتوى الصفحة.
3. برمجة وظيفة الاستمارات – إذا كانت مطلوبة.

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

القوائم الرئيسية والفرعية

هناك نوعين من عناصر القائمة: رئيسي وفرعي. وأرشح لك –كما يقول Wordpress Codex– أن تدرس ما إذا كانت إضافتك تحتاج إلى عنصر قائمة رئيسي فعلًا. حيث توجد العديد من الإضافات التي تضيف عناصر قائمة رئيسية، مما يؤدي إلى إزدحام لوحة التحكم.

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

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

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

إنشاء صفحة لوحة تحكم رئيسية

أولًا نبدأ بإنشاء عنصر قائمة عن طريق الدالة ()add_menu_page.  وترى هنا مثالًا لها مع الشرح:

add_action( 'admin_menu', 'my_admin_menu' );

function my_admin_menu() {
    add_menu_page( 'My Top Level Menu Example', 'Top Level Menu', 'manage_options', 'myplugin/myplugin-admin-page.php', 'myplguin_admin_page', 'dashicons-tickets', 6 );

}

تأخذ الدالة سبع معطيات:

1. عنوان الصفحة، الذي يعرّف وسم العنوان ويظهر في عنوان  صفحة الانترنت في متصفح الانترنت وليس على الشاشة. 
2. العنوان الذي يظهر في القائمة.
3. الصلاحيات المطلوبة للدخول إلى القائمة، يمكن استخدامه لحصر الصفحة على المدراء، أو المحررين، أو المؤلفين.
4. "الاسم اللطيف" أو slug للقائمة، وهو الذي يظهر في رابط الصفحة.
5. الوظيفة، التي تتضمن محتوى الصفحة.
6. رابط الأيقونة. ويقبل العديد من الصيغ. فإذا وُضع رابط صورة سوف تستخدم هذه الصورة. بإمكانك استخدام Dashicons، المبنية داخل ووردبريس، أو حتى استخدام ملف SVG.
7. الترتيب في القائمة. وبما أن الوظيفة تختص بالمقالات، فقد اخترنا أن نضع عنصر القائمة بعدها مباشرة، أي في السادس. ويمكنك التعرف على ترتيب العناصر من Wordpress Codex.

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

function myplguin_admin_page(){
?>
    <div class="wrap">
        <h2>Welcome To My Plugin</h2>
    </div>
<?php
}

إنشاء صفحة لوحة تحكم فرعية

هناك بعض الوظائف التي يمكن استخدامها لإنشاء صفحات فرعية. والدالة العامة ()add_submenu_page تمكنك من إنشاء صفحات فرعية في أي مكان، ولكن كل الصفحات الرئيسية لها وظائفها الخاصة لإضافة صفحات فرعية إليها:

• لإضافة صفحات فرعية إلى قسم المقالات استخدم add_posts_page.
• لإضافة صفحات فرعية إلى قسم الصفحات استخدم add_pages_page.
• لإضافة صفحات فرعية إلى قسم الوسائط استخدم add_media_page.
• لإضافة صفحات فرعية إلى قسم الروابط استخدم add_links_page.
• لإضافة صفحات فرعية إلى قسم التعليقات استخدم add_comments_page.
• لإضافة صفحات فرعية إلى قسم المظهر استخدم add_theme_page.
• لإضافة صفحات فرعية إلى قسم الإضافات استخدم add_plugin_page.
• لإضافة صفحات فرعية إلى قسم المستخدمين استخدم add_users_page.
• لإضافة صفحات فرعية إلى قسم الأدوات استخدم add_management_page.
• لإضافة صفحات فرعية إلى قسم الإعدادات استخدم add_options_page.

كل من الوظائف السابقة تتبع نفس الصياغة:

add_comments_page( $page_title, $menu_title, $capability, $menu_slug, $function); 

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

add_action( 'admin_menu', 'my_admin_menu' );

function my_admin_menu() {
    add_menu_page( 'My Top Level Menu Example', 'Top Level Menu', 'manage_options', 'myplugin/myplugin-admin-page.php', 'myplguin_admin_page', 'dashicons-tickets', 6 );

    add_submenu_page( 'myplugin/myplugin-admin-page.php', 'My Sub Level Menu Example', 'Sub Level Menu', 'manage_options', 'myplugin/myplugin-admin-sub-page.php', 'myplguin_admin_sub_page' );
}

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

 myplugin/myplugin-admin-page.php.

الختام

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

هل هناك أي شيء تريد إضافته إلى المقالة؟ أو تريد الاستفسار عنه؟ سنسعد بالرد عليكم في التعليقات.

مترجم بتصرف من مقال A Quick and Easy Guide To Creating WordPress Admin Pages لصاحبه Daniel Pataki.

حقوق الصورة البارزة: Car vector designed by Freepik.

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

عرض إشعار قياسي

function my_admin_notice(){
    echo '<div class="updated">
       <p>I am a little yellow notice.</p>
    </div>';
}
add_action('admin_notices', 'my_admin_notice');

حيثُ أنَّه قد تمَّ إضافة الصّنف"updated" إلى الوسم div فسيظهر الإشعار باللَّون الأصفر. أمَّا في حالة تغيير الصّنف إلى "error" فإنَّ الإشعار يظهر أحمرًا.

كيفيَّة عمل إشعار قابل للإغلاق

من المُمكن -مع القليل من العمل الإضافي- عرض الإشعار وإبقائه حتَّى يقوم المُستخدم بالضغط على زرٍّ لإغلاقه. تُعتبر تلك الطَّريقة مُفيدة للتأكُّد من أنَّ المُستخدم قد قام برؤية الإشعار وكذلك لن يُضايقه وجود الإشعار طوال الوقت.

المثال التَّالي تمَّ استخراجه من إضافة AddThis. يُستخدم أيضًا شيء مُشابه في Options Framework..

إذا قام المُستخدم بالضَّغط لإخفاء الإشعار فسيتمّ حفظ تفضيله في بيانات user meta.

/* Display a notice that can be dismissed */

add_action('admin_notices', 'example_admin_notice');

function example_admin_notice() {
    global $current_user ;
        $user_id = $current_user->ID;
        /* Check that the user hasn't already clicked to ignore the message */
    if ( ! get_user_meta($user_id, 'example_ignore_notice') ) {
        echo '<div class="updated"><p>'; 
        printf(__('This is an annoying nag message.  Why do people make these? | <a href="%1$s">Hide Notice</a>'), '?example_nag_ignore=0');
        echo "</p></div>";
    }
}

add_action('admin_init', 'example_nag_ignore');

function example_nag_ignore() {
    global $current_user;
        $user_id = $current_user->ID;
        /* If user clicks to ignore the notice, add that to their user meta */
        if ( isset($_GET['example_nag_ignore']) && '0' == $_GET['example_nag_ignore'] ) {
             add_user_meta($user_id, 'example_ignore_notice', 'true', true);
    }
}

عرض الإشعارات في صفحات تحكُّم مُعيَّنة

أحيانًا قد نحتاج إلى تحديد ظهور الإشعار ليكون في صفحاتٍ مُعيَّنة قد يحتاج المُستخدم لرؤية الإشعار بها. يُمكنكَ تنفيذ هذا باستخدام المُتغيِّر العام $pagenow.
على سبيل المثال، سيظهر الإشعار التالي في صفحة الإضافات فقط:

function my_admin_notice(){
    global $pagenow;
    if ( $pagenow == 'plugins.php' ) {
         echo '<div class="updated">
             <p>This notice only appears on the plugins page.</p>
         </div>';
    }
}
add_action('admin_notices', 'my_admin_notice');

التحقُّق من دور المُستخدم قبل عرض الإشعار

يجب عرض الإشعارات للمُستخدمين المعنيين بالأمر فقط. على سبيل المثال، لا فائدة من عرض إشعار عن تعديل خيارات القالب لمُستخدم لا يملك صلاحية التَّعديل على خيارات القالب.
إليكَ طريقة للتّحقق من الأدوار الشائعة:

if ( current_user_can( 'install_plugins' ) )
if ( current_user_can( 'manage_options' ) )
if ( current_user_can( 'edit_theme_options' ) )

آداب الإشعار

أحيانًا تُصبح الإشعارات مُزعجة، لهذا عليكَ الحذر عند استخدامها. أبقِ النَّصَّ قصيرًا وحاول ألَّا تعرض أكثر من إشعار. عليك استخدام هذه الميزة باعتدال.

مصادر أخرى

• http://theme.it/how-to-display-an-admin-notice-for-required-theme-plugins
• http://codex.wordpress.org/Plugin_API/Action_Reference/admin_notices

ترجمة -وبتصرّف- للمقال: Admin Notices in WordPress.

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

ولكن كيف تفعل ذلك؟ هذا هو السؤال الذي سنستكشف إجابته اليوم.

الأمر نسبي

نعم، هاتان الكلمان هي الإجابة القصيرة لذلك السؤال.

لكن هكذا لن تكون المقالة مثيرة للاهتمام، أليس كذلك؟ أفضل طريقة لإضافة نص برمجي مٌخصَّص لووردبريس يعتمد على عدد من العوامل. ولهذا اخترت تقديم خياراتك بصيغة "إذا كان / فافعل".

إذا استخدمت قالبًا صُمِّمَ من قِبل شخص آخر

فيجب ألّا تضيف نصًا برمجيًا مٌخصَّصًا إلى ملفات ذلك القالب، يقول إريك بويلو (صاحب وكالة برمجية):

اقتباس

"حين تجري تحديثات لووردبريس، أو للإضافة، أو للقالب، فأي تعديلات أدخلتها ستحذف تمامًا" 

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

1. أنشئ قالبًا فرعيًا

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

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

إذا لم تمتلك فكرة جيدة عما يكون القالب الفرعي، دعني أشرح لك. إنه بشكل أساسي عبارة عن قالب فرعي للقالب الرئيسي المُنَصّب. ويمكن إنشاؤه بسهولة. إذ كل ما تحتاج فعله هو الولوج إلى موقعك عن طريق FTP وإنشاء مجلد (قد يكون اسم themename-child مناسبًا) ثم أنشء ملف style.css في ذلك المجلد. هذا الملف سيسحب المعلومات من ملف CSS التابع للقالب الرئيسي. ثم ستحتاج لتفعيل القالب الفرعي في لوحة التحكم.

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

2. استخدم إضافة

إذا لم تكن مرتاحًا في التّعامل مع الواجهة الخلفية (backend) لووردبريس لكن ما زلت تريد إدخال تعديلات برمجية مٌخصَّصة، يمكنك استخدام إضافة تساعدك على وضع النص البرمجي في أماكن مناسبة على موقعك. وفقًا لسكوت تشاو من مدونة The Blog Starter، استخدام إضافة "سيٌخفِّض بشكل كبير من احتمالية حذف شيء بالخطأ". ولا حاجة لذكر أن مشكلة "تحديث الموقع وخسارة جميع التعديلات" لن تحدث إطلاقًا هنا.

يُرشّح تشاو إضافتين خصيصًا. الأولى هي Insert Headers and Footers. هذه الإضافة تساعدك على إدخال النص البرمجي في ترويسة أو ذيل موقعك. وهذا مناسب للأشخاص الذين يريدون إضافة شيء مثل Google Analytics.

الإضافة الثانية التي يرشحها هي Global Content Blocks. هذه الإضافة تساعدك على إدخال الشيفرة ضمن المقالات وحفظها كمقتطفات نص برمجي للاستخدام لاحقًا.

رشحت ناتاليا كريس، مطورة أخرى تحدثت معها،  إضافة أخرى تدعى Code Insert Manager وهي ممتازة لإضافة نصوص برمجية لخدمات مثل Google Analytics, Aweber وGetResponse.

لكن مجددًا، قد لا تجد إضافة تستطيع تحقيق تلك المهمة التي تريد فعلها. في هذه الحالة يمكنك..

3. برمجة إضافة

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

يقول أدم سميث، مدير قسم التقنية فيMarketing Mojo:

اقتباس

“ألجأ إلى برمجة إضافة جديدة للموقع لإدخال النص البرمجي المٌخصَّص بدلًا من إدخاله في ملف functions.php التابع للقالب. هذا يفصل وظائف ووردبريس عن التصميم" 

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

عادة ما يصمم سميث الإضافة المٌخصَّصة بحيث تتضمن أنواع المقالات المٌخصَّصة، الاختصارات النصية، تعديلات على إدارة ووردبريس، وتعديلات أخرى يراها مطلوبة.

وينتهج هوارد أسلوبًا مماثلًا، حيث يقول:

اقتباس

"هناك حالات عديدة نبني فيها إضافات مٌخصَّصة بحوالي 10-20 سطرًا برمجيّا ببساطة لأننا نريد إضافة خاصية صغيرة، وهذا مهم للإبقاء على الخاصية حتى لو تغير القالب.”

إذا أنشأت قالبك الخاص

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

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

إنشاء إضافة (نعم، مجددًا)

نعم، تنطبق هذه الطريقة على كلا الحالتين سواء أكنت تستخدم قالب مُصَمَّمًا من قبل أشخاص آخرين أو صمّمته بنفسك.

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

اقتباس

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

حسنًا، ما هو أفضل حل؟

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

• تستخدم قالبًا فرعيًا عند التعديل على خصائص قالب مُصَمَّم من قبل شخص آخر، أو
• تستخدم إضافة لإضافة سطور النص البرمجي إلى موقعك، أو
• تُبرمج إضافات للحصول على مجال أوسع من إضافة الخصائص.

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

خاتمة

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

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

ترجمة -وبتصرف- للمقال What's The Best Way To Add Custom Code To WordPress؟ لكاتبته Brenda Barron.

حقوق الصور محفوظة لـ: +Tuts

تمنح تقنيّة Ajax مواقع الويب إمكانيّةَ تحميل محتوى إلى عناصر مختلفة ضمن الصّفحة دون الحاجة لإنعاش Refresh الصّفحة. قد لا تبدو - للوهلة الأولى - ميزةً مؤثّرة، إلّا أنّها تمكّن من فعل الكثير من الأمور.

تستخدم الكثير من الإجراءات مثل التّصويت، إبداء الإعجاب، التّعليقات على Disqus والتّغريدات على تويتر؛ وإجراءات أخرى كثيرة Ajax للحصول على تجربة مستخدم User experience لا مثيل لها.

ذاع صيت Ajax سنة 2005 عندما استخدمته Google في ميزة اقتراحات البحث، الّتي تُظهر اقتراحات أثناء الكتابة على محرّك بحث Google. لم تكن هذه الميزة لترى النّور لولا وجود تقنيّة Ajax.

سنعرض في هذا المقال لكيفيّة استخدام Ajax في ووردبريس. سيكون الأمر أكثر تعقيدًا قليلًا ممّا تعوّدت عليه، إلّا أنّ الأمور ستجري على ما يُرام إن كان لديك فهم جيّد CSS، HTML وPHP؛ إضافةً لفهم لأساسيّات Javascript.

كيف يعمل Ajax

ليس Ajax في الواقع سوى Javascript. تأتي كلمة Ajax اختصارًا لAsynchronous Javascript And XML (أي: Javascript وXML لا تزامنيّان). تهدف تقنيّة Ajax إلى أن تكون جسرًا بين موقع الويب والخادوم، وهو ما يعني أنّك ستسخدمها بالتّزامن مع Javascript، CSS، HTML وربّما PHP أيضًا؛ الأمر الّذي قد يعقّد الأمور قليلًا.

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

• تحدّد البيانات الّتي تريد إرسالها
• تضبُط نداء Ajax
• تستخدم كائن XMLHttpRequest لإرسال البيانات إلى الخادوم
• تحصُل على إجابة من الخادوم. يُمكن استخدام ردّ الخادوم ضمن شفرة Javascript.

يكثُر استخدام Ajax عبر دوالّ التّغليف Wrapper functions في jQuery، لذا سنركّز على هذه الطّريقة في هذا المقال.

أوّل نداء Ajax

سنحتاج قبل البدء في كتابة شفرة Ajax إلى قالب يُمكن التّعديل عليه، قالب فرعيّ أو إضافة. أنصح باستخدام إضافة. إنشاء إضافة سهل: أنشئ مجلَّدًا فرعيًّا ضمن wp-content/plugins (اخترتُ اسم ajax-text). أنشئ ملفّ PHP ضمن المجلَّد وأعطِه نفس اسم المجلَّد (ajax-text.php) وألصِق الشفرة التّاليّة في الملفّ:

<?php
/**
* Plugin Name: Ajax Test
* Plugin URI: <a href="http://danielpataki.com">http://danielpataki.com</a>
* Description: This is a plugin that allows us to test Ajax functionality in WordPress
* Version: 1.0.0
* Author: Daniel Pataki
* Author URI: <a href="http://danielpataki.com">http://danielpataki.com</a>
* License: GPL2
*/

ستظهر الإضافة، بعد حفظ الملفّ، في ركن الإضافات في لوحة التّحكّم بووردبريس. فعّلها. للمزيد حول تطوير إضافات ووردبريس راجع دليل مدخل إلى برمجة إضافات ووردبريس.

1- صفّ Enqueueing ملفّ Javascript

سنحتاج لماستخدام ملفّ JavaScript في الإضافة، لذا سنصُفّ الملفّ. نستخدم الشّفرة التّاليّة لهذا الغرض:

add_action( 'wp_enqueue_scripts', 'ajax_test_enqueue_scripts' );
function ajax_test_enqueue_scripts() {
  wp_enqueue_script( 'test', plugins_url( '/test.js', __FILE__ ), array('jquery'), '1.0', true );
}

تُضيف الشّفرة أعلاه ملفّ test.js إلى الموقع. أخبرنا ووردبريس أنّ jQuery اعتماديّة يجب تحميلها في التّذييل Footer.

الخطوة التّاليّة هي إنشاء نداء Ajax بسيط داخل ملفّ Javascript.

2- إنشاء نداء Ajax

يحوي نداء Ajax على العديد من المعطيات، سنتعرّف على الأساسيّة منها.

jQuery(document).ready( function($) {

  $.ajax({
    url: "http://yourwebsite.com",
    success: function( data ) {
      alert('يبلُغ عدد عناصر div في الصّفحة الرّئيسيّة لديك:' + $(data).find('div').length);
    }
  })

})

كلّ ما فعلناه هو استخدام دالّة ()ajax.$ وتحديد بعض الخيّارات. يحدّد المُعطى url لنداء Ajax أين يجب أن يُرسل الطّلب الّذي تستقبل الدّالةُ الموجودة في المعطى success الإجابةَ عليه.

يجب أن يُحيل المُعطى url إلى رابط الصّفحة الرّئيسيّة لموقعك. ستظهر لك، إذا نفّذت الخطوات بطريقة صحيحة، نافذةٌ منبثقة بعدد عناصر div الموجودة في الصّفحة الرئيسيّة فورَ إنعاش الصّفحة (ﻷخذ التّغييرات على الإضافة في الحسبان).

لا يبدو المظهر أنيقًا؛ إلّا أنّ ما فعلناه في الواقع هو تحميل صفحة مختلفة تمامًا دون إعادة تحميل تلك الّتي نوجد فيها.

مثال كامل لاستخدام Ajax في ووردبريس

يوفّر ووردبريس دعمًا أكبر للمساعدة في استخدام نداءات Ajax ويقدّم آليّة معياريّة لتأديّتها. سنُبدِل عنوان url بآخر أكثر ديناميكيّة وننشئ طريقةً أفضل للتّخاطب مع الخادوم. سنعرض في المثال التّالي كيفيّةَ إضافة ميزة “أعجبني هذا المقال” إلى موقعنا.

أنشأتُ إضافةً جديدة لهذا الغرض باسم “post-love”، يمكن الملفّ المضغوط للإضافة في آخر الدّرس.

ملحوظة: يجب تعطيل وحذف الإضافة السّابقة ajax-text حتى يمكن للإضافة الجديدة post-love العمل بطريقة صحيحة.

1- تخزين وعرض البيانات

سنستخدم حقلًا مُخصَّصًا Custom field لحفظ عدد الإعجابات الّتي تلقّاها المنشور. سنسمّي هذا الحقل post_love وسنعرض قيمته تحت كلّ مقال في صفحة منفردة Single page. في ما يلي كيفيّة ذلك (ملفّ content-filter.php):

add_filter( 'the_content', 'post_love_display', 99 );
function post_love_display( $content ) {
  $love_text = '';
  if ( is_single() ) {
    $love = get_post_meta( get_the_ID(), 'post_love', true );
    $love = ( empty( $love ) ) ? 0 : $love;
    $love_text = '<p class="love-received"><a class="love-button" href="#" data-id="' . get_the_ID() . '">أبدِ(ي) إعجابك</a><span id="love-count">' . $love . '</span></p>';
  }
  return $content . $love_text;
}

يمكننا عبر استخدام content-filter.php عرض أيّ شيء نُريده أسفل محتوى المقال مباشرةً. نستخدم دالّة ()is_singl للتّأكّد من أنّ الإعجابات تظهر على الصّفحات المنفردة. نحصُل على عدد الإعجابات من الحقل المخصَّص post_love ونتأكّد من أنّ العدد يساوي صفرًا إن لم توجد إعجابات حتى اللّحظة.

استخدمنا HTML لعرض رابط لإبداء الإعجاب وعدد الإعجابات. نحصُل على معرّف المقال عبر الدّالّة ()get_the_ID ونمرّره لدالّة get_post_meta الّتي نحصُل من خلالها على قيمة الحقل المخصَّص post_love؛ ثمّ في اﻷخير نُرجِع المحتوى متبوعًا بالنّص الّذي أنشأناه للتّو.

نستخدم CSS لإضافة بعض التّحسينات على طريقة العرض عبر صفّ ملفّ CSSكان تفهم جيّدًا  على النّحو التّاليّ:

add_action( 'wp_enqueue_scripts', 'post_love_assets' );
function post_love_assets() {
  if( is_single() ) {
    wp_enqueue_style( 'love', plugins_url( '/love.css', __FILE__ ) );
  }

لاحظ استخدام الشّرط ()is_single قبل تحميل ملفّ CSS، يعود السّبب في ذلك إلى أنّه لا معنى لتحميل النّمط في صفحات غير منفردة، حيثُ إنّه لا يُستخدَم إلّا فيها؛ الأمر الّذي يُساعد في التّقليل من تأثير الإضافة على زمن تحميل الموقع.

أنشئ ملفّ love.css في مجلَّد الإضافة وضمّن فيه النّمط التّالي:

.entry-content .love-button {
  background: #f14864;
  color: #fff;
  padding:11px 22px;
  display:inline-block;
  border:0px;
  text-decoration: none;
  box-shadow: 0px 6px #d2234c;
  position:relative;
}

.entry-content .love-button:hover{
  top:3px;
  box-shadow: 0px 3px #d2234c;
}

.entry-content .love-button:active{
  top:6px;
  box-shadow: none;
}


#love-count {
  background: #eee;
  box-shadow: 0px 6px #ddd;
  color: #666;
  padding:11px 22px;
  display:inline-block;
}

تظهر النّتيجة بعد إكمال الخطوات السّابقة على هيئة زرّ بتأثير ثلاثيّ الأبعاد يوجد أمامه عدّاد.

2- نداء Ajax

الخطوة التّاليّة هي تجميع نداء Ajax. يستدعي ذلك كتابة السكربت وصَفَّه. سنناقش، قبل البدْء في كتابة السّكربت، معطَى url الموجود في نداء Ajax. في المثال السّابق (ajax-text) كتبنا عنوان الموقع مباشرةً ضمن الشّفرة البرمجيّة، وهي طريقة غير صحيحة أثناء إنشاء الإضافات؛ فكلّ موقع لديه عنوانه الخاصّ.

ملحوظة: سنحذف الشّفرة التّاليّة ونعيد كتابتها من جديد مع إضافة نداء Ajax:

add_action( 'wp_enqueue_scripts', 'post_love_assets' );
function post_love_assets() {
  if( is_single() ) {
    wp_enqueue_style( 'love', plugins_url( '/love.css', __FILE__ ) );
}

يوفّر ووردبريس ملفًّا موّحدًا للاستخدام (wp-admin/admin-ajax.php) ووسائلَ للحصول على مسار الملفّ كامِلًا. يستدعي الملفّ بعض الحيّل أثناء صفّه، نعرض لها في الشّفرة التّاليّة:

add_action( 'wp_enqueue_scripts', 'ajax_test_enqueue_scripts' );
function ajax_test_enqueue_scripts() {
  if( is_single() ) {
    wp_enqueue_style( 'love', plugins_url( '/love.css', __FILE__ ) );
  }
  wp_enqueue_script( 'love', plugins_url( '/love.js', __FILE__ ), array('jquery'), '1.0', true );
  wp_localize_script( 'love', 'postlove', array(
    'ajax_url' => admin_url( 'admin-ajax.php' )
  ));
}

تُسجّل الشّفرة أعلاه ملفّ Javascript بالطّريقة المُعتادة، ثمّ تمرّر سلسلة محارف String إلى السّكربت عبر الدّالّة ()wp_localize_script (تُستخدَم هذه الدّالّة عادةً لترجمة سلاسل المحارف الموجودة في Javascript). يُمكنك إضافة سلاسل محارف إلى المصفوفة Array بحسب حاجتك.

يمكننا الآن استخدام المتغيّر postlove.ajax_url في ملفّ love.js للحصول على مسار admin-ajax.php، على النّحو التّاليّ:

jQuery( document ).on( 'click', '.love-button', function() {
  var post_id = jQuery(this).data('id');
  jQuery.ajax({
    url : postlove.ajax_url,
    type : 'post',
    data : {
      action : 'post_love_add_love',
      post_id : post_id
    },
    success : function( response ) {
    alert(response)
  }
  });
})

ليست هذه النّسخةَ النّهائيّة، لكنّنا وضعنا أساس التّخاطب مع الخادوم. ننفّذ دالّة في كلّ مرة يُضغَط فيها على الزّرّ أبد(ي) إعجابك، ثمّ نأخذ معرّف المقال ونخزّنه في المتغيّر post_id. يُنشئ سكربت love.js نداء Ajax يأخذ في معطى url قيمةَ المتغيّر postlove.ajax_url. بالنّسبة لمعطى type فقد أعطيناه القيمة post أيّ أنّ التّخاطب مع الخادوم سيكون عبر طلبات Post وهي ما يعني أنّنا سنستخدِم المتغيّر POST_$، من جانب الخادوم، للحصول على البيانات.

توجد في قسم data كلّ المعطيات الّتي تودّ إرسالها. نحتاج لإرسال معرّف المقال (post_id) لنعرِف المقال الّذي أبدى الزّائر إعجابه به. يطلُب ووردبريس تحديد إجراء Action عند استخدام الملفّ admin-ajax.php. حدّدنا الإجراء post_love_add_love.

أخيرًا نعرض النّتيجة في نافذة منبثقة.

إذا جربّت التّعديلات الجديدة وضغط على زرّ إبداء الإعجاب فستظهر رسالة منبثقة تحوي عدد مرّات إبداء الإعجاب (0).

لم نعرّف خطّافًا Hook للإجراء post_love_add_love في الشّفرة أعلاه وهو ما يؤدّي بadmin-ajax إلى إرجاع القيمة 0. سنعرّف في الفقرة المواليّة الخطّاف النّاقص.

3- المعالجة من جانب الخادوم

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

add_action( 'wp_ajax_nopriv_post_love_add_love', 'post_love_add_love' );
add_action( 'wp_ajax_post_love_add_love', 'post_love_add_love' );
function post_love_add_love() {
}

يُنفَّذ الخطّاف الأوّل بالنّسبة للزّوّار الضّيوف، والثّاني لمُسجَّلي الدّخول. بالمناسبة، هذه طريقة جيّدة للتّحكّم في الوصول. الاتّفاق هو كالتّالي:

هل تتذكّر كيف عرّفنا معطى الإجراء في نداء Ajax؟ نحتاج إلى إلحاق هذا المعطى ب_wp_ajax و/أو _wp_ajax_nopriv. بالنّسبة للدّالّة يُمكن استخدام أيّ تسميّة، استخدمنا نفس سلسلة المحارف الموجودة في اسم الإجراء للحفاظ على التّجانس. نُضيف الآن وظيفة الزّيّادة بالتّدرّج Incrementing

add_action( 'wp_ajax_nopriv_post_love_add_love', 'post_love_add_love' );
add_action( 'wp_ajax_post_love_add_love', 'post_love_add_love' );
function post_love_add_love() {
  $love = get_post_meta( $_POST['post_id'], 'post_love', true );
  $love++;
  update_post_meta( $_POST['post_id'], 'post_love', $love );
  echo $love;
  die();
}

نعثُر على القيمة الحاليّة، نزيدها بواحد ثمّ نخزّن القيمة الجديدة ونعرضها. يجب تنفيذ ()die في نهاية الدّالّة وإلّا فإنّ ملفّ admin-ajax.php سينفّذ (0)die الخاصّة به ممّا ينتج عنه عرض 0 إضافيّ في الإجابة.

تظهرعند الضّغط على زر إبداء الإعجاب الآن نافذة منبثقة بها عددُ الإعجابات، وعند إنعاش الصّفحة يظهر العدد إلى جانب الزّرّ المذكور.

لم يتبقّ لنا سوى جعل العدد يتغيّر دون الحاجة لإنعاش الصّفحة. تتكفّل شفرة Javascript التّاليّة بهذه المهمّة:

jQuery( document ).on( 'click', '.love-button', function() {
  var post_id = jQuery(this).data('id');
  jQuery.ajax({
    url : postlove.ajax_url,
    type : 'post',
    data : {
      action : 'post_love_add_love',
      post_id : post_id
    },
    success : function( response ) {
      jQuery('#love-count').html( response );
    }
  });
})

يؤدّي الضّغط على الزّرّ الآن إلى زيّادة عدد الإعجابات دون الحاجة لإنعاش الصّفحة.

4- لمسات أخيرة

ربّما لاحظت أنّنا أضفنا في زرّ الإعجاب رابطًا إلى #:

<a class="love-button" href="#" data-id="' . get_the_ID() . '">أبدِ(ي) إعجابك</a>

يعود السّبب في ذلك إلى أخذ الحالة الّتي يكون Javascript فيها غير مفعَّل لدى الزّائر. في هذه الحالة يؤدّي الضّغط على الزّرّ إلى إعادة تنزيل الصّفحة. إلّا أنّ استخدام # وحده ضمن وسم Tag الرّابط يجعل هذا الأخير غير صالح Invalid. فلنعالج هذا الأمر.

ملحوظة: يُستخدَم ماسك المكان Placeholder # في خاصيّة href ضمن وسم <a> للدّلالة على أنّ الرّابط يُحيل إلى عنصر من الصّفحة يُعطَى معرّفه بعد ماسك المكان (مثلًا:"a href="#id5). استخدام # لوحده يعني أنّ الرّابط يُحيل إلى معرّف غير موجود في الصّفحة. في المحصّلة يُحيل الرّابط إلى الصّفحة لكنّه يبقى غير صالح دلاليًّا Semantic.

سنعدّل على الشّفرة بحيث يُحيل الرّابط إلى نداء Ajax، مثلًا: http://yourwebsite.com/wp-admin/admin-ajax.php?action=post_love_add_love&post_id=23 بالنّسبة للزّوّار الّذين يفعّلون Ajax.

add_filter( 'the_content', 'post_love_display', 99 );
function post_love_display( $content ) {
  $love_text = '';
  if ( is_single() ) {
    $love = get_post_meta( get_the_ID(), 'post_love', true );
    $love = ( empty( $love ) ) ? 0 : $love;
    $love_text = '<p class="love-received"><a class="love-button" href="' . admin_url( 'admin-ajax.php?action=post_love_add_love&post_id=' . get_the_ID() ) . '" data-id="' . get_the_ID() . '">give love</a><span id="love-count">' . $love . '</span></p>';
  }
  return $content . $love_text;
}

إذا كان Javascript مفعَّلًا في المتصفّح فيجب تعطيل إمكانيّة تتبّع رابط URL. لذا نُضيف return false إلى الدّالّة في حدث click كما يلي:

jQuery( document ).on( 'click', '.love-button', function() {
  var post_id = jQuery(this).data('id');
  jQuery.ajax({
    url : postlove.ajax_url,
    type : 'post',
    data : {
      action : 'post_love_add_love',
      post_id : post_id
    },
    success : function( response ) {
      jQuery('#love-count').html( response );
    }
  });
  // نُرجع القيمة false هنا
  return false; 
})

الخطوة الأخيرة هيّ التّفريق بين عمليّات Ajax والعمليّات الأخرى ضمن دالّة ()post_love_add_love. عند استخدام Ajax نعرض القيمة الجديدة، ثمّ يتوقّف السكربت. إن لم يُستخدَم Ajax (يعني هذا أنّ الزّائر سيُوجَّه إلى admin-ajax) فكلّ ما نفعله هو إعادة توجيه المتصفّح إلى المقال بعد تنفيذ السّكربت.

في ما يلي النّسخة النّهائيّة لدالّة ()post_love_add_love:

function post_love_add_love() {
  $love = get_post_meta( $_REQUEST['post_id'], 'post_love', true );
  $love++;
  update_post_meta( $_REQUEST['post_id'], 'post_love', $love );
  if ( defined( 'DOING_AJAX' ) && DOING_AJAX ) {
    echo $love;
    die();
  }
  else {
    wp_redirect( get_permalink( $_REQUEST['post_id'] ) );
    exit();
  }
}

أبدلنا المتغيّر POST_$ بREQUEST_$ إذ أنّ الزوّارّ بAjax مفعَّل سيستخدمون طلب POST في ما يستخدم بقيّة الزّوّار طلب GET. يمكّن متغيّر REQUEST_$ من الحصول على البيانات في الحالتيْن.

جوانب إضافية تجب مراعاتها عند استخدام Ajax

Ajax ليس صعبًا، إلّا أنّه يوجد الكثير من الأمور السّهلة الّتي تجب عليك معرفتها. في ما يلي أهمّ جانبيْن ينبغي عليك الاهتمام بهما.

1- الأمان

يُمكن أن تؤدّي قلّة الحذر أثناء استخدام Ajax إلى مشاكل أمنيّة عديدة. لا تتحقّق الإضافة التّي أنشأناها أعلاه من الضّغطات المتعدّدة الّتي يُمكن أن تؤدّي - فضلًا عن تشويه النّتائج - إلى زيّادة الحمل على الخادوم، خصوصًا إن واصل الكثيرون الضّغط على الزّرّ في نفس الوقت. علاوةً على ذلك فإنّ تغيير العدّاد لا يحتاج للضّغط على الزّر؛ مجرّد الدّخول إلى الرّابط (مثلًا http://yourwebsite.com/wp-admin/admin-ajax.php?action=post_love_add_love&post_id=23) يفي بالمهمّة.

خذ في الحسبان أنّ بعض الإضافات تسمح بحذف المقالات من الواجهة اﻷماميّة دون الحاجة للدّخول إلى لوحة التّحكّم؛ ماذا لو وُجِد رابط تؤدّي زيّارته إلى نفس التّأثير؟ ليست وضعيّة مثاليّة.

استخدام الأرقام الخاصّة Nonces هو إحدى وسائل تأمين الاستمارات والرّوابط ضدّ المحاولات الخبيثة.

2- تجربة المستخدم

يعود انتشار استخدام Ajax إلى أنّ المستخدم يحصُل على تفاعليّة أكبر مع التّقليل من وقت التّحميل. يعني هذا أيضًا أنّه يجب عليك العمل جاهدًا للتّأكّد من أنّ استخدامك لAjax يرفع حقًا من نوعيّة تجربة المستخدم: يجب أن يعرف الزّائر دائمًا مالّذي يحدُث ولماذا. لو كانت إضافة post-love موجَّهةً للنّشر ﻷضفتُ أيقونة لحالة التّحميل تعطّل زرّ الإعجاب عند الضّغط عليه، ثمّ بعد نجاح العمليّة يعود الزّرّ لحالته الطّبيعيّة. تُمكن إضافة هذه الميزة عن طريق معطى beforeSend ضمن دالّة ()ajax.$. يُتيح beforeSend إمكانيّة تنفيذ بعض التّعليمات قبل إرسال البيانات إلى الخادوم.

إضافة إشارة مرئيّة أثناء تغيّر عدد الإعجابات فكرة جيّدة؛ إن لم يكن المستخدم يعرف مالّذي ينتظره عند الّضغط على الزّر فربّما لا يُلاحظ تغيّر عدد الإعجابات.

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

خاتمة

تعدّ تقنيّة Ajax من الأدوات القويّة المتاحة للمطوّرين من أجل إضافة التّفاعليّة والتّقليل من الضّغط على الخادوم. لن يُمكن إحصاء الميزات الممكن تقديمها باستخدام Ajax: عرض التّعليقات دون الحاجة لإعادة تنزيل الصّفحة، التّمرير اللّامتناهيّ Infinite scrolling للمقالات، التّحميل الخامل Lazy-loading للصوّر، وغيرها الكثير.

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

رابط تنزيل إضافة `post-love` في صورتها النّهائيّة. post-love.zip

ترجمة بتصرّف لمقال Using AJAX With PHP on Your WordPress Site Without a Plugin لكاتبه Daniel Pataki.