لوحة المتصدرين

هل صنعت قالب HTML وأحببته لكنّك لم تعرف كيف تُحوّله إلى قالب ووردبريس؟ ليس بعد الآن، ستتعلم في هذا الدرس كيف تقوم بذلك. هل تعلم بأنّ هناك الكثير من المُطوّرين الذين يكسبون رزقهم عن طريق إنشاء قوالب وإضافات ووردبريس (Wordpress) وبيعها؟ وهل تعلم أنّه بإمكان مطوّري ووردبريس الحصول على آلاف الدولارات سنويًَّا من خلال بيع مُنتجاتهم؟ هذا الدّرس مُخصّص لمطوّري الويب، على فرض أن القارئ على اطّلاع (ولو بشكل مُبسّط) بما يتعلّق بلغة PHP وMySQL ومعلومات عامّة عن كيفية تنصيب واستخدام ووردبريس. هذا الدرس جزء من سلسلة تعلم كيفية تطوير قوالب ووردبريس: مقدمة إلى تطوير قوالب ووردبريس: تحويل صفحة HTML إلى قالب ووردبريس (هذا الدرس) التصفيح (Pagination) في قوالب ووردبريس إضافة قوائم التنقل (Navigation Menu) إلى قالب ووردبريس صف وتسجيل ملفات Javascript و CSS في قوالب ووردبريس متطلبات التّشغيل نحتاج إلى تحميل نسخة ووردبريس من الموقع الرسمي ، سنستخدم النّسخة العربية من هذا الرّابط. تحتاج ووردبريس إلى خادوم ويب، سواء كان Apache أو Nginx أو الخادوم المُدمج مع لغة PHP (بإصدار5.4 وما فوق). وتحتاج أيضًا إلى خادوم قواعد البيانات MySQL. لنقم بإنشاء مُجلّد جديد wordpress_tutorials ونضع فيه نسخة ووردبريس النّاتجة عن فكّ ضغط الملف الذي قمنا بتحميله. ملاحظة: يمكن أن تستخدم البرامج المُجهّزة خصّيصًا بخواديم Apache و MySQL مثل MAMP ،WAMP أو XAMPP. مع مُراعاة الاختلاف بين رابط خادوم الويب ومعلومات خادوم MySQL مع ما سنستخدمه في هذا الدّرس. سنقوم باستخدام الخادوم المُدمج مع PHP لتجنّب تنصيب خادوم Apache أو Nginx وتجنب الخوض في الإعدادات الخاصّة بكل واحد منها. لتشغيل الخادوم المُدمج نتوجه باستخدام سطر اﻷوامر إلى المجلّد الذي يحوي نسخة ووردبريس. ثم نكتب أمر: php -S localhost:8000 يتمّ تشغيل خادوم الويب المُدمج مع PHP على الحاسوب، يمكن التّوجّه عن طريق المُتصفّح إلى الرّابط localhost:8000 للتّأكد من أن الخادوم يعمل. تهيئة قالب HTML سنقوم بالاعتماد على قالبٍ قمتُ بإعداده مُسبقاً، يمكن تحميله من هذا الرابط، التّصميم عبارة عن قالب عادي يحوي بضع ملفّات HTML ،CSS و JavaScript. وهو مبني اعتمادًا على إطار عمل Foundation مع بعض التّعديلات والإضافات. هذا القالب تجريبيّ فقط لرؤية كيفية ظهور الشكل العامّ له. نتوجه إلى مجلّد المشروع الذي يحوي ملفات ووردبريس، ومنه نتوجّه إلى مجلد wp-content ثم إلى مُجلّد themes. نقوم بإنشاء مُجلّد اسمه my_theme بمثابة مُجلّد القالب الذي سنقوم بإنشائه. ملفات القالب الأساسية نحتاج إلى وجود ملفّين على الأقل ضمن مجلد القالب الذي أنشأناه، وهما: - style.css - index.php وهذا أقل ما يجب توفّره في القالب ليكون قالبًا صالحًا للاستخدام. نتجه إلى صفحة تغيير القوالب من لوحة تحكم ووردبريس لنرى ما يشبه: كما تلاحظون لا نرى القالب الجديد الذي أنشأناه ضمن القوالب، وذلك ﻷن هناك شيئًا آخر علينا فعله قبل أن نرى القالب الجديد في هذه الصفحة. نحتاج إلى إضافة تعليق في ملف style.css كالتّالي (يمكن تعديل أيّ قيمة أيضًا): /* Theme Name: قالبي الجديد Author: عمار العقاد Author URI: http://aalakkad.me Description: قالب جديد، نقوم من خلاله بالتّدرّب على إنشاء قوالب WordPress. Version: 1.0 */ تقوم ووردبريس بالدخول إلى كل مجلد في مجلد القوالب، ثم تبحث عن ملف style.css بداخله تعليق يشبه التّعليق السابق، ثم تقوم بتفسير هذه التّعليقات ووضعها في صفحة القوالب التي تظهر للمُستخدم من خلالها أسماء وتوصيف القوالب. وهناك تفصيلات أخرى للتعليقات في ملف style.css يمكن الاطلاع عليها كاملة من ملفات التوثيق. يمكن التوجه إلى صفحة القوالب من خلال لوحة التحكم، لنرى شيئًا مُشابهًا لما يلي: لنقم بتفعيل هذا القالب الجديد، ثم نتوجّه إلى الصّفحة الرّئيسية للمُدوّنة (الصفحة التي تُظهر المقالات وليست صفحة لوحة التّحكم). إن كنت تستخدم الخادوم المُدمج مع PHP بالطريقة التي ذكرناها، فيكون رابط الصّفحة الرئيسية هو: localhost:8000. سنرى صفحة بيضاء دون أن تحوي أيّ شيء، وذلك ﻷن القالب ما زال فارغًا تمامًا. سيتغيّر الوضع بعد قليل. نقل قالب HTML إلى قالب ووردبريس ما سنفعله في الخطوة الأولى هو وضع قالب HTML في ملف index.php ثم نقوم بتعديل مسارات ملفات CSS و JavaScript. ستكون جميع الصفحات التي نستخدمها من ووردبريس بعد تفعيل القالب الجديد مُتطابقة، وكأنها قالب HTML نفسه. وهذا هو المطلوب في هذه المرحلة، سنقوم بإضافة التّفاصيل فيما بعد وعلى عدة مراحل. نقوم الآن بنسخ محتوى ملف index.html كاملًا من قالب HTML ونضعه في ملف index.php في قالبنا الجديد my_theme ضمن ووردبريس. ثم ننسخ مجلد assets كما هو إلى داخل مجلد قالبنا الجديد. لنرى كيف أصبح شكل الموقع بعد أن وضعنا محتوى ملف index.html في ملف index.php: يظهر الآن القالب بهذا الشّكل ﻷن ملفات CSS وJavaScript أصبحت في مسار مختلف عن المسار الذي كان موجودًا في قالب HTML. علينا الآن أن نقوم بتعديل مسارات هذه الملفات كي يُصبح شكل قالب ووردبريس الجديد مُطابقًا لشكل قالب HTML. توفّر لنا ووردبريس عددًا من الدّوالّ (functions) مهمتها تسهيل إنشاء القوالب، سنستخدم منها get_template_directory_uri()، تقوم هذه الدالّة بإرجاع قيمة نصّيّة هي رابط القالب. مثلاً، إن كان مجلد القالب هو my_theme ورابط خادوم الويب الذي نعمل عليه هو http://localhost:8000 ستكون نتيجة الدالّة هي: http://localhost:8000/wp-content/my_theme يجب أن نستخدم هذه الدالّة أو ما يشابهها لنحصل على الرّوابط، ولا نستخدم روابط نضعها بشكل يدوي، فيُمكن لرابط خادوم الويب أن يتغير، وإن كانت الروابط موضوعةً بشكل يدوي فسيظهر شكل القالب كما في الأعلى خاليًّا من ملفات CSS و .JavaScript. نقوم بتعديل ملف index.html في قسم head، نبحث عن سطر استدعاء ملفات CSS، ثم نقوم بالتّعديل عليها لتصبح بالشّكل: في قسم head أيضًا نُريد استبدال رابط استدعاء ملف modernizr.js ليستخدم دالّة get_template_directory()، فيُصبح: <script src="<?php echo get_template_directory_uri(); ?>/assets/js/modernizr.js"></script> أخيرًا نبحث في نهاية ملف index.php عن سطر استدعاء ملف JavaScript، ونقوم بالتّعديل عليه ليُصبح كما يلي: <script src="<?php echo get_template_directory_uri(); ?>/assets/js/vendor.js"></script> الآن عندما يتم طلب المُدوّنة من المُتصفّح، ستكون النّتيجة النّهائية للتعديلات الثلاثة التي قمنها بها كالتالي: <link rel="stylesheet" href="http://localhost:8000/wp-content/themes/my_theme/assets/css/main.css"> <script src="http://localhost:8000/wp-content/themes/my_theme/assets/js/modernizr.js"></script> <script src="http://localhost:8000/wp-content/themes/my_theme/assets/js/vendor.js"></script> نذهب الآن إلى الصّفحة الرّئيسية للمُدوّنة لنرى كيف أصبح القالب. في آخر فقرة من هذا الدرس سنقوم بتعديل ترويسة الموقع التي نصّها الحالي هو: "عنوان الموقع"، والذي يظهر في الجُزء العُلويّ. نريد تغيير هذا النصّ ليصبح اسم المدونة التي قمنا بإدخالها أثناء مرحلة التّنصيب، يمكنك تغيير اسم المدونة من لوحة التحكم ثم الإعدادات. لنفتح صفحة index.php في المُحرّر، ثم نبحث عن السطر الذي يحوي: <h1 class="logo">عنون الموقع</h1> ,نقوم باستبداله بما يلي بعض إضافة وسم PHP له: <h1 class="logo"><?php bloginfo('name'); ?></h1> وسم: <?php php bloginfo('name'); ?> يقوم بإظهار/طباعة نصّ يتم جلبه من قاعدة البيانات، النصّ هو اسم المُدوّنة. نلاحظ أن الدّالّة bloginfo() تقوم بالإظهار وليست الإرجاع return كما تفعل دالّة ()get_template_directory_uri. الآن عندما نتوجّه إلى الصفحة الرئيسية للمدونة تكون الترويسة شبيهة بالصورة: فصل محتوى الملفات من قواعد البرمجة الهامة إلغاء التّرابط أو الفصل (decoupling)، فنحاول فصل العناصر المُترابطة قدر الإمكان ووضعها في ملفات مُنفصلة. مثلًا سنقوم لاحقًا بإنشاء صفحة خاصّة لعرض المواضيع المُنفردة، وستحتاج تلك الصّفحة إلى وجود الترويسة (header) والتذييل (footer) كي تحوي ملفات CSS و JavaScript وتكون متناغمة مع باقي القالب. توفّر لنا ووردبريس عدة طُرق لإلغاء التّرابط في الملفات، إمّا أن يتم استخدام التّسلسل الهرمي لملفّات القالب (theme hierarchy) أو يتم استخدام قِطَع القالب (template parts). التّسلسل الهرمي لملفّات القالب (أو ملفات القالب للاختصار) هي ملفات بأسماء ثابتة، تقوم ووردبريس باستخدام الملف المُتوفّر منها حسب الطلب الذي يأتيها من المتصفح؛ مثلاً طلبتَ من المدونة رابط مقالٍ معيّن، تقوم ووردبريس بتحليل الطّلب ومعرفة أن المطلوب هو مقال، فتبحث عن ملف باسم single.php، إن كان موجودًا يتمّ استخدامه، إن لم يكن موجودًا تبحث ووردبريس عن ملف index.php. وهكذا الأمر بالنسبة لجميع الطلبات. أما قِطع القالب، فهي ملفات يقوم المستخدم بإنشائها دون أن يلتزم باستخدام أسماء مُحدّدة كما في ملفات القالب. ثم يقوم المطوّر باستخدام هذه القِطع في أي مكان يريده ضمن القالب. يقوم المُطوّر مثلًا بإنشاء قطعة مُخصّصة لعرض أزرار المُشاركة، يقوم بتسمية الملف: sharing.php، ويضع فيه الوسوم التي يُريدها. ثم يقوم باستدعاء هذا الملف في الصّفحة الرّئيسيّة index.php وصفحة المقال المُنفرد single.php على النّحو التّالي: <?php get_template_part('sharing'); ?> هناك تفصيلات حول كيفية إنشاء قطع القالب والتّعامل معها، ما سنذكره هنا فقط لإعطاء فكرة عامة عنها وليس لشرحها بالتّفصيل. سنستخدم في هذا الدرس التّسلسل الهرمي فقط لسهولته وشهرته. إن كان الاسم غريبًا بالنّسبة إليك فستألفه بمُجرد أن تشرع في استخدامه. سنقوم بإنشاء 3 ملفّات في القالب هي: - header.php - footer.php - sidebar.php ومن ثم يمكننا استخدام هذه الملفّات في أي مكان ضمن القالب عن طريق الدّوال: - get_header() - get_footer() - get_sidebar() هذه الدّوال تعمل بشكل مُشابه لـ require التّي نعرفها في لغة PHP. بهذه الطّريقة لن نحتاج إلى القيام بالنّسخ واللصق في كل مرة نريد إدراج الترويسة في ملفات القالب، وفي حال أردنا تعديل شيء في الترويسة فلن نضطرّ إلى تطبيق التعديل في جميع ملفات القالب. الخطوة التّالية هي نقل المحتوى المُناسب لكل ملفّ من الملفّات السّابقة من ملف index.php إلى الملفّات الثّلاثة الجديدة التي أنشأناها. سنقوم حرفيًا بالنّسخ واللّصق من ملف index.php إلى الملفات الثّلاثة، ثم نقوم بوضع إحدى الدّوال الثلاثة في ملف index.php بدل النصّ الذي قمنا باقتصاصه. ملف الترويسة header.php نقوم باقتصاص مُحتوى ملف index.php من بدايته وحتى نهاية وسم </header> في السطر 57. نضع ما اقتصصناه في ملف header.php. ثم نضع مكان الاقتصاص في ملف index.php ما يلي: <?php get_header(); ?> فتصبح بداية ملف index.php مشابهةً لما يلي: <?php get_header(); ?> <div class="main-content"> <div class="row"> ملف التذييل footer.php نقوم الآن باقتصاص الجزء الخاص بالتذييل من ملف index.php، في السطر 71 بدءاً من وسم: <div class="site-footer"> وحتى نهاية الملف. نقوم بوضع المُحتوى في ملف footer.php، ثم نستبدل مكان الوسوم المقصوصة في ملف index.php بما يلي: <?php get_footer(); ?> ملف الشريط الجانبي sidebar.php الوسوم الخاصّة بالشريط الجانبي ما هي إلا أربعة أسطر، تبدأ من السطر 64، المحتوى هو: <div class="large-4 columns sidebar"> <div class="card"> Sidebar </div> </div> نقوم بنقل المحتوى السّابق من ملف index.php إلى ملف sidebar.php، ونضع مكانه في ملف index.php: <?php get_sidebar(); ?> بهذا ننتهي من المرحلة الأولى من إلغاء الترابط بين الوسوم، وضعنا كل جزءٍ منها في ملفٍّ خاصٍّ به، وكلما أردنا استخدام ذلك الجزء نقوم باستدعاء الدّالّة المناسبة لذلك. أصبح ملف index.php أقصر طولًا، ويؤدّي نفس الغرض الذي كان يؤدّيه قبل أن نقوم بالتّعديلات، محتوى الملف كالتالي: <?php get_header(); ?> <div class="main-content"> <div class="row"> <div class="large-8 right columns news"> <div class="row"> <div class="medium-12 columns"> <article class="card"> <header> <h1>Post title</h1> </header> <div class="date">4 كانون الأول 2014</div> <p>خلافاَ للاعتقاد <a href="#">السائد</a> فإن لوريم إيبسوم ليس نصاَ عشوائياً، بنذ العام 45 قبل الميلاد، مما يجعله أكثر من 2000 عام في القدم. قام البروفيسور "ريتشارد ماك لينتوك" (Richard McClintock) وهو بروفيسور اللغة اللاتينية في جامعة هامبدن-سيدني في فيرجينيا بالبحث عن أصول كلمة لاتينية غامضة في نص لوريم إيبسوم وهي "consectetur"، وخلال تتبعه لهذه الكلمة في الأدب اللاتيني اكتشف المصدر الغير قابل للشك. فلقد اتضح أن كلمات نص لوريم إيبسوم تأتي من الأقسام 1.10.32 و 1.10.33 من كتاب "حول أقاصي الخير والشر" (de Finibus Bonorum et Malorum) للمفكر شيشيرون (Cicero) والذي كتبه في عام 45 قبل الميلاد. هذا الكتاب هو بمثابة مقالة علمية مطولة في نظرية الأخلاق، وكان له شعبية كبيرة في عصر النهضة. السطر الأول من لوريم إيبسوم "Lorem ipsum dolor sit amet.." يأتي من سطر في القسم 1.20.32 من هذا الكتاب.</p> <div class="read-more text-left"> <a href="#">تابع قراءة المقال &raquo;</a> </div> <footer class="tags"> <span class="label">تقني</span> <span class="label">تنمية</span> <span class="label">منوعات</span> </footer> </article> </div> <div class="medium-12 columns"> <article class="card"> <header> <h1>Post title</h1> </header> <div class="date">4 كانون الأول 2014</div> <p>خلافاَ للاعتقاد <a href="#">السائد</a> فإن لوريم إيبسوم ليس نصاَ عشوائياً، بنذ العام 45 قبل الميلاد، مما يجعله أكثر من 2000 عام في القدم. قام البروفيسور "ريتشارد ماك لينتوك" (Richard McClintock) وهو بروفيسور اللغة اللاتينية في جامعة هامبدن-سيدني في فيرجينيا بالبحث عن أصول كلمة لاتينية غامضة في نص لوريم إيبسوم وهي "consectetur"، وخلال تتبعه لهذه الكلمة في الأدب اللاتيني اكتشف المصدر الغير قابل للشك. فلقد اتضح أن كلمات نص لوريم إيبسوم تأتي من الأقسام 1.10.32 و 1.10.33 من كتاب "حول أقاصي الخير والشر" (de Finibus Bonorum et Malorum) للمفكر شيشيرون (Cicero) والذي كتبه في عام 45 قبل الميلاد. هذا الكتاب هو بمثابة مقالة علمية مطولة في نظرية الأخلاق، وكان له شعبية كبيرة في عصر النهضة. السطر الأول من لوريم إيبسوم "Lorem ipsum dolor sit amet.." يأتي من سطر في القسم 1.20.32 من هذا الكتاب.</p> <div class="read-more text-left"> <a href="#">تابع قراءة المقال &raquo;</a> </div> <footer class="tags"> <span class="label">تقني</span> <span class="label">تنمية</span> </footer> </article> </div> </div> <div class="row"> <div class="medium-12 columns"> <ul class="pagination"> <li class="arrow unavailable"><a href="">&laquo;</a></li> <li class="current"><a href="">1</a></li> <li><a href="">2</a></li> <li><a href="">3</a></li> <li><a href="">4</a></li> <li class="unavailable"><a href="">&hellip;</a></li> <li><a href="">12</a></li> <li><a href="">13</a></li> <li class="arrow"><a href="">&raquo;</a></li> </ul> </div> </div> </div> <?php get_sidebar(); ?> </div> </div> <?php get_footer(); ?> جلب المقالات من قاعدة البيانات نحتاج الآن إلى عرض المقالات المحفوظة في قاعدة البيانات (والتي يتم التّحكم فيها من لوحة التّحكم الخاصّة بووردبريس)، سنقوم بعرضها في ملف index.php وفي دروس لاحقة سنستخدم نفس طريقة عرض المقالات في باقي ملفات القالب، سواءً في ملف single.php أو في archive.php أو في غيرها. ضمن ملف index.php نجد أن كل مقال مُحاط بالوسوم: <div class="medium-12 columns"> <article class="card"> كل مقال يجب أن يبدأ بهذه الوسوم، وينتهي بإغلاق هذه الوسوم. نلاحظ أن قالب HTML يحوي مقالين شكليين، سنحذف واحدًا منها ونكتفي بالآخر لنقوم باستخدامه كمعيار لعرض المقالات مثله. نحيط وسوم بداية المقال بالحلقة الرّئيسية التي تكلّمنا عنها سابقًا، فتُصبح الوسوم كما يلي: <?php while(have_posts()) { the_post(); ?> <div class="medium-12 columns"> <article class="card"> وبعد إغلاق الوُسوم التي بدأ المقال عندها نضع نهاية الحلقة (قوس إغلاق الحلقة) كما يلي: </article> </div> <?php } ?> إن قمنا بحفظ التّعديلات والتجربة، سنجد أن المقال الشّكليّ سيتكرّر بعدد المقالات الموجودة في قاعدة بيانات ووردبريس لدينا. لكن جميع المقالات ستكون بنفس الشّكل وبنفس المُحتوى. سنقوم الآن باستبدال المُحتوى الشّكليّ بالمُحتوى المُناسب من قاعدة البيانات حسب كل مقال. تقدم ووردبريس دالّة the_title لطباعة عُنوان المقال الحالي، سنستخدمها بدل عنوان المقال الشّكلي، فتصبح الوسوم كما يلي: <h1><?php the_title();?></h1> وبنفس الطريقة نستخدم دالّة the_date لعرض تاريخ نشر المقال كما يلي: <div class="date"><?php the_date();?></div> ثم لعرض محتوى المقال نستخدم دالّة the_content بدل وسم <p></p> الذي يحوي المحتوى الشكليّ، كما يلي: <p><?php the_content();?></p> يُمكن أن نقوم بحفظ التّعديلات على الملف ومشاهدة النّتيجة في المُتصفّح لنتأكد من أن التّعديلات التي قمنا بها تم تطبيقها وتعرض النّتيجة الصّحيحة. بقي لدينا تعديلان مُشابهان لما قمنا به، الأول لتعديل رابط “تابع قراءة المقال” والثاني لعرض الوسوم الخاصّة بالمقال. لتعديل رابط المقال نستخدم دالّة the_permalink التي وظيفتها عرض رابط الويب الخاصّ بالمقال، لكن لا تقوم الدّالّة سوى بطباعة الرّابط دون وضعه في وسم <a></a> كي يصبح قابلًا للنّقر والاستخدام. علينا إذًا وضع الرّابط في مكانه المُناسب كما يلي: <a href="<?php the_permalink();?>">تابع قراءة المقال »</a> قمنا باستبدال قيمة حقل href="#" بدالّة طباعة رابط المقال. الآن أصبح بإمكاننا مُشاهدة الصّفحة الرّئيسيّة للقالب التي تعرض المقالات ويمكن الضّغط على رابط “تابع قراءة المقال” للوصول إلى المقال بعينه ضمن صفحة مُستقلّة. بقي الآن أن نعرض الوسوم الخاصّة بكل مقال. مكان الوسوم هو داخل وسم: <footer class="tags"> </footer> سنقوم باستخدام دالّة wp_get_post_tags التي مهمتها إرجاع مصفوفة تحوي جميع الوسوم الخاصّة بالمقال على شكل كائنات (Objects) وليس مُجرّد نصّ عادي. وعليه فإنه سيكون بإمكاننا الوصول إلى اسم كل وسم عن طريق: tag->name$ كما يلي: <footer class="tags"> <?php $tags = wp_get_post_tags(get_the_ID()); foreach($tags as $tag) { echo '<span class="label"> ' . $tag->name . '</span> '; } </footer> يُمكننا الآن استعراض المقالات في الصّفحة الرّئيسية للمُدوّنة والوصول إلى كل مقال عن طريق الرّابط الخاص به ورؤية الوسوم الخاصّة بكل مقال أيضًا. سنتوقف هنا في هذا الدرس كي لا تكون المعلومات كثيفة يصعب استيعابها، وسنتابع في دروس أخرى استخدام أرقام الصّفحات في الأسفل بشكل صحيح. (يمكن الآن إضافة تعليق حول وسوم الصفحات كي لا تظهر بشكل خاطئ وبدون روابط صحيحة). خلاصة تعلّمنا في هذا الدّرس كيف نقوم بتجهيز قالب HTML ليُصبح قالبَ ووردبريس، وكيف نُعدّل مسارات ملفات JavaScript وCSS لتُصبح متناغمةً مع رابط الويب الخاص بقالب ووردبريس. وفي القسم الثاني من الدرس تعلّمنا كيف نقوم بفصل المحتوى عن ملف index.php إلى ملفّات فرعية أخرى، لنقوم بإعادة استخدامها في أي ملف ضمن القالب. وفي القسم الأخير رأينا كيف يمكن جلب المقالات من قاعدة البيانات وإظهارها للمُستخدم مع عرض الوسوم الخاصّة بكل مقال. أرجو أن يكون الدرس سهلاً بسيطاً، في حال وجود أي استفسار أو مداخلة نرحّب به في التعليقات.

تأتي وحدة التسجيل (logging) مبدئيا توزيعة بايثون المعيارية وتقدم حلا لمتابعة الأحداث التي تحصُل أثناء عمل البرمجية. تستطيع إضافة استدعاءات التسجيل للشيفرة البرمجية الخاصة بك للإشارة لما تحقق من أحداث. تسمح لك وحدة التسجيل بإعداد كل من التسجيلات التشخيصية التي تسجل الأحداث المقترنة بعمليات التطبيق، بالإضافة إلى تسجيلات التدقيق التي تسجل الأحداث الخاصة بحركات المستخدم بهدف تحليلها. وحدة التسجيل هذه مختصة في حفظ السجلات في ملفات. لماذا نستخدم وحدة التسجيل؟ تحافظ وحدة التسجيل على سجل الأحداث التي تحدث خلال عمل البرنامج، مما يجعل من رؤية مخرجات البرنامج المتعلقة بأحداثه أمراً متاحاً. قد يكون استخدام الأمرprint أمرا مألوفا لك خلال الشيفرة البرمجية لفحص الأحداث. يقدم الأمر print طريقة بدائية لإجراء عملية التنقيح الخاصة بحل المشاكل خلال عمل البرمجية. بينما يعد تضمين تعليمات print خلال الشيفرة البرمجية طريقة لمعرفة مسار تنفيذ البرنامج والحالة الحالية له، إلا أن هذه الطريقة اُثبت أنها أقل قدرة على الصيانة من استخدام وحدة التسجيل في بايثون، وذلك للأسباب التالية: باستخدام تعليمات print يصبح من الصعب التفرقة بين مخرجات البرنامج الطبيعية وبين مخرجات التنقيح لتشابههما. عندما تنتشر تعليمات print خلال الشيفرة البرمجية، فإنه لا توجد طريقة سهلة لتعطيل التعليمات الخاصة بالتنقيح. من الصعب إزالة كافة تعليمات print عندما تنتهي من عملية التنقيح. لا توجد سجلات تشخيصية للأحداث. من الجيد البدء بالتعود على استخدام وحدة التسجيل المعيارية في بايثون خلال كتابة الشيفرة البرمجية بما أنها طريقة تتلاءم أكثر مع التطبيقات التي يكبر حجمها عن سكريبتات بايثون بسيطة، وكذلك بما أنها تقدم طريقة أفضل للتنقيح. طباعة رسائل التنقيح في وحدة التحكم إذا كنت متعودا على استخدام تعليمات print لرؤية ما يحدث في برنامجك خلال العمل، فمن المحتمل مثلا أنك تعودت على رؤية برنامج يُعرف صنفًاClass وينشئ منه عناصر كما في المثال التالي: class Pizza(): def __init__(self, name, price): self.name = name self.price = price print("Pizza created: {} (${})".format(self.name, self.price)) def make(self, quantity=1): print("Made {} {} pizza(s)".format(quantity, self.name)) def eat(self, quantity=1): print("Ate {} pizza(s)".format(quantity, self.name)) pizza_01 = Pizza("artichoke", 15) pizza_01.make() pizza_01.eat() pizza_02 = Pizza("margherita", 12) pizza_02.make(2) pizza_02.eat() توجد في الشيفرة السابقة الدالة__init__ التي تستخدم لتعريف خصائصname وprice للصنفPizza. كما تحتوي على الدالتين make لصنع البيتزا، وeat لأكلها وتأخذان المعطى quantity ذا القيمة الافتراضية 1. لنشغل البرنامج: >> python pizza.py وسنحصل على المخرج التالي: Output Pizza created: artichoke ($15) Made 1 artichoke pizza(s) Ate 1 pizza(s) Pizza created: margherita ($12) Made 2 margherita pizza(s) Ate 1 pizza(s) تسمح لنا تعليمات print برؤية أن البرنامج يعمل، ولكننا نستطيع أن نستخدم وحدة التسجيل لذات الغرض بدلا من ذلك. لنقم بإزالة تعليمات print من الشيفرة البرمجية، ونستورد الوحدة باستخدام الأمر import logging: import logging class Pizza(): def __init__(self, name, value): self.name = name self.value = value ... المستوى التلقائي للتسجيل في وحدة التسجيل هو مستوى التحذير (WARNING)، وهو مستوى فوق مستوى التنقيح (DEBUG). بما أننا سنستخدم الوحدة بغرض التنقيح في هذا المثال، سنحتاج الى تعديل إعدادات التسجيل لتصبح بمستوى التنقيح logging.DEBUG بحيث تعود معلومات التنقيح لنا من خلال لوحة التحكم. ونقوم بإعداد ذلك بإضافة ما يلي بعد تعليماتة الاستيراد: import logging logging.basicConfig(level=logging.DEBUG) class Pizza(): ... هذا المستوى المتمثل بlogging.DEBUG يشير لقيد رقمي قيمته 10. سنستبدل الآن جميع تعليمات print بتعليمات logging.debug()، (logging.DEBUG ثابت بينما logging.debug() دالة). نستطيع أن نمرر لهذه الدالة نفس المدخلات النصية لتعليماتة print كما هو موجود بالأسفل: import logging logging.basicConfig(level=logging.DEBUG) class Pizza(): def __init__(self, name, price): self.name = name self.price = price logging.debug("Pizza created: {} (${})".format(self.name, self.price)) def make(self, quantity=1): logging.debug("Made {} {} pizza(s)".format(quantity, self.name)) def eat(self, quantity=1): logging.debug("Ate {} pizza(s)".format(quantity, self.name)) pizza_01 = Pizza("artichoke", 15) pizza_01.make() pizza_01.eat() pizza_02 = Pizza("margherita", 12) pizza_02.make(2) pizza_02.eat() لهذا الحد، نستطيع تشغيل البرنامج عبر تنفيذ الأمر python pizza.py وسنحصل على المخرج التالي: Output DEBUG:root:Pizza created: artichoke ($15) DEBUG:root:Made 1 artichoke pizza(s) DEBUG:root:Ate 1 pizza(s) DEBUG:root:Pizza created: margherita ($12) DEBUG:root:Made 2 margherita pizza(s) DEBUG:root:Ate 1 pizza(s) لاحظ أن مستوى التسجيل في المخرج السابق هو DEBUG بالإضافة لكلمة root والتي تشير لمستوى المُسجل (logger) الذي يتم استخدامه. يعني ما سبق أن وحدة التسجيل logging من الممكن أن يتم استخدامها لإعداد أكثر من مُسجل بأسماء مختلفة. فمثلا، نستطيع إنشاء مسجلين باسمين مختلفين ومخرجات مختلفة كما هو موضح بالأسفل: logger1 = logging.getLogger("module_1") logger2 = logging.getLogger("module_2") logger1.debug("Module 1 debugger") logger2.debug("Module 2 debugger") Output DEBUG:module_1:Module 1 debugger DEBUG:module_2:Module 2 debugger بعد أن أصبحت لدينا المعرفة اللازمة لكيفية استخدام الوحدة logging لطباعة الرسائل على وحدة التحكم، دعونا نكمل شرح الوحدة ونتعرف على كيفية استخدام الوحدة في طباعة الرسائل إلى ملف خارجي. التسجيل في ملف الغرض الأساسي للتسجيل هو حفظ البيانات في ملف وليس إظهار معلومات التسجيل على وحدة التحكم. يتيح لك التسجيل في ملف حفظ بيانات التسجيل مع مرور الوقت واستخدامها في عملية التحليل والمتابعة ولتحديد ما تحتاجه من تغيير على الشيفرة البرمجية. لجعل عملية التسجيل تحفظ التسجيلات في ملف، علينا أن نعدّل logging.basicConfig() بحيث تحتوي على معطى لاسم الملف (filename)، وليكن مثلا test.log: import logging logging.basicConfig(filename="test.log", level=logging.DEBUG) class Pizza(): def __init__(self, name, price): self.name = name self.price = price logging.debug("Pizza created: {} (${})".format(self.name, self.price)) def make(self, quantity=1): logging.debug("Made {} {} pizza(s)".format(quantity, self.name)) def eat(self, quantity=1): logging.debug("Ate {} pizza(s)".format(quantity, self.name)) pizza_01 = Pizza("artichoke", 15) pizza_01.make() pizza_01.eat() pizza_02 = Pizza("margherita", 12) pizza_02.make(2) pizza_02.eat() الشيفرة البرمجية هنا هي نفسها الموجودة سابقا عدا أننا أضفنا اسم الملف الذي سنقوم بحفظ التسجيلات فيه. بمجرد تشغيلنا للشيفرة السابقة، سنجد في نفس المسار الملف test.log. لنفتحه باستخدام محرر النصوص nano (أو أي محرر نصوص من اختيارك): $ nano test.log وسيكون محتويات الملف كالتالي: DEBUG:root:Pizza created: artichoke ($15) DEBUG:root:Made 1 artichoke pizza(s) DEBUG:root:Ate 1 pizza(s) DEBUG:root:Pizza created: margherita ($12) DEBUG:root:Made 2 margherita pizza(s) DEBUG:root:Ate 1 pizza(s) المخرج السابق هو نفسه الذي حصلنا عليه في القسم السابق من المقال، غير أنه الآن في ملف باسم test.log وليس على الطرفية. لنغلق المحرر، ونجر بعض التعديلات التالية على المتغيرين pizza_01 و pizza_02: ... # Modify the parameters of the pizza_01 object pizza_01 = Pizza("Sicilian", 18) pizza_01.make(5) pizza_01.eat(4) # Modify the parameters of the pizza_02 object pizza_02 = Pizza("quattro formaggi", 16) pizza_02.make(2) pizza_02.eat(2) عند تنفيذ الشيفرة بعد حفظ التعديلات، ستُضاف التسجيلات الجديدة للملف وسيكون محتواه كالتالي: DEBUG:root:Pizza created: artichoke ($15) DEBUG:root:Made 1 artichoke pizza(s) DEBUG:root:Ate 1 pizza(s) DEBUG:root:Pizza created: margherita ($12) DEBUG:root:Made 2 margherita pizza(s) DEBUG:root:Ate 1 pizza(s) DEBUG:root:Pizza created: Sicilian ($18) DEBUG:root:Made 5 Sicilian pizza(s) DEBUG:root:Ate 4 pizza(s) DEBUG:root:Pizza created: quattro formaggi ($16) DEBUG:root:Made 2 quattro formaggi pizza(s) DEBUG:root:Ate 2 pizza(s) تُعد البيانات الموجودة في الملف مفيدة، ولكننا نستطيع جعلها أكثر إعلاماً بإضافة بعض الإعدادات. بشكل أساسي، فإننا نريد أن نجعل السجلات مفصلة أكثر بإضافة الوقت الذي أنشئ السجل فيه. نستطيع إضافة المعطى المسمى format ونضيف له النص %(asctime)s الذي يشير للوقت، كذلك، للإبقاء على ظهور مستوى التسجيل في السجلات، لابد أن نضيف النص %(levelname)s بالإضافة للسجل نفسه %(message)s. لابد من الفصل بين كل خيار في المعطى format بالعلامة : كما هو موضح بالأسفل: import logging logging.basicConfig( filename="test.log", level=logging.DEBUG, format="%(asctime)s:%(levelname)s:%(message)s" ) ....... عندما ننفذ الشيفرة السابقة، سنحصل على تسجيلات جديدة في ملف test.log تتضمن الوقت الذي أنشئ فيه التسجيل بالإضافة لمستوى التسجيل ورسالة التسجيل: Output DEBUG:root:Pizza created: Sicilian ($18) DEBUG:root:Made 5 Sicilian pizza(s) DEBUG:root:Ate 4 pizza(s) DEBUG:root:Pizza created: quattro formaggi ($16) DEBUG:root:Made 2 quattro formaggi pizza(s) DEBUG:root:Ate 2 pizza(s) 2017-05-01 16:28:54,593:DEBUG:Pizza created: Sicilian ($18) 2017-05-01 16:28:54,593:DEBUG:Made 5 Sicilian pizza(s) 2017-05-01 16:28:54,593:DEBUG:Ate 4 pizza(s) 2017-05-01 16:28:54,593:DEBUG:Pizza created: quattro formaggi ($16) 2017-05-01 16:28:54,593:DEBUG:Made 2 quattro formaggi pizza(s) 2017-05-01 16:28:54,593:DEBUG:Ate 2 pizza(s) تبعا لاحتياجاتك، من الممكن أن تضيف إعدادات أخرى للمسجل بحيث تجعل التسجيلات التي يتم حفظها في الملف مرتبطة بك نوعا ما. التنقيح بواسطة التسجيل في ملفات خارجية يتيح لك فهما شاملا لبرنامج بايثون مع مرور الوقت، معطيا الفرصة لحل المشاكل التي تظهر وتغيير ما تحتاج تغييره في الشيفرة البرمجية استنادا لما لديك من بيانات تسجيلات تاريخية وأحداث وحركات تمت خلال عمل البرنامج. جدول بمستويات التسجيل تستطيع نسب مستوى الأهمية للحدث الذي يتم تسجيله بواسطة المُسجل وذلك بإضافة مستوى الخطورة (Severity Level). مستويات الخطورة موضحة في الجدول الذي بالأسفل. تتمثل مستويات التسجيل تقنيا بأرقام (ثوابت)، بفرق قيمة بين كل مستوى ب 10، تبدأ من المستوىNOTEST ذي القيمة 0. تستطيع أن تُعرف مستويات خاصة بك مرتبطة بالمستويات المعرفة مسبقا. إذا عَرَّفْتَ مستوى بنفس القيمة الرقمية، فإنك تستبدل اسم المستوى المرتبط بتلك القيمة. المستوى القيمة الرقمية الدالة الاستخدام CRITICAL 50 ()logging.critical اظهار الأخطاء الخطيرة، البرنامج قد لا يستمر بالعمل ERROR 40 ()logging.error إظهار مشكلة خطيرة WARNING 30 ()logging.warning الإشارة لحدث غير متوقع حصل أو قد يصحل INFO 20 ()logging.info الإشارة أن الحدث حصل كما هو متوقع DEBUG 10 ()logging.debug فحص المشاكل، وإظهار معلومات تفصيلية خاتمة الوحدة logging هي وحدة ضمن التوزيعة المعيارية لبايثون، وتقدم حلا لمتابعة الأحداث التي تحدث خلال عمل البرمجية مع إمكانية تسجيل هذه الأحداث في ملفات خارجية أو إظهارها على الطرفية. وهذا يتيح لك فهما شاملا لبرنامج بايثون مع مرور الوقت. هذه المقالة جزء من سلسة مقالات حول تعلم البرمجة في بايثون 3. ترجمة – بتصرّف – للمقال How To Use Logging in Python 3 لصاحبته Lisa Tagliaferri. اقرأ أيضًا المقالة التالية: كيفية ترحيل شيفرة بايثون 2 إلى بايثون 3 المقالة السابقة: كيفية تنقيح شيفرات بايثون من سطر الأوامر التفاعلي المرجع الشامل إلى تعلم لغة بايثون كتاب البرمجة بلغة بايثون

مرّ معنا أثناء إضافة أرقام الصفحات كيف أضفنا ملف CSS جديد عن طريق وضع بضعة أسطر في ملف functions.php في ملفات القالب. سنتناول في هذا الدرس الشرح التفصيلي لهذه الآلية، وهي الطريقة الآمنة لإضافة ملفات JavaScript و CSS. فهرس السلسلة: مقدمة إلى تطوير قوالب ووردبريس: تحويل صفحة HTML إلى قالب ووردبريس التصفيح (Pagination) في قوالب ووردبريس إضافة قوائم التنقل (Navigation Menu) إلى قالب ووردبريس صف وتسجيل ملفات Javascript و CSS في قوالب ووردبريس (هذا الدرس) ما المقصود بالصف؟ هو وضع الملف في صفّ/دور/طابور (queue) لتقوم ووردبريس بمعالجته لاحقاً. تخيل أنك تضع الملف في دور/طابور شراء جهاز آي فون جديد مثلاً! وعندما يحين موعد عرض الملفات، تقوم ووردبريس بمعالجة الصفّ ومتطلبات كل ملفّ فيه، ثم إعادة ترتيب الصف حسب المتطلبات، وأخيراً عرض الملفات في مكانها المناسب مع متطلباتها. الخطوات العامة سنعرض الآن الخطوات بشكل عام، ثم تفصيلها وطريقة استخدامها في الفقرة اللاحقة. لصفّ ملفٍّ ما، سواء كان ملف JavaScript أو CSS نحتاج إلى: استخدام الحدث (action) المناسب. تسجيل الملف المراد استخدامه؛ حيث يجب استخدام معرّف (handle) للملف، مسار الملف، ويمكن تحديد متطلباته (dependencies) إن وُجدت. صفّ الملف (enqueue)؛ باستخدام المعرّف المُستخدم أثناء تسجيل الملف. تسجيل وصف ملفات CSS تسجيل ملف CSS لتسجيل ملفٍّ جديد نقوم باستخدام دالّة wp_register_style، يمكن للدالّة أن تقبل المحدّدات التالية: handle$: مطلوب، هو المعرّف الخاص بالملف، الذي سيتم استخدامه عند صفّ الملف (enqueue). src$: مطلوب، هو رابط (URL) ملف CSS المطلوب تسجيله، مثل:http://example.com/css/mystyle.css، لكن يجب ألا يتم استخدام الرابط بهذا الشكل، بل يجب أن يكون أكثر مرونة (التفصيل في الملاحظة بعد نهاية الفقرة). deps$: مصفوفة من المعرّفات، التي تمثّل متطلبات الملف الذي نقوم بتسجيله، كي يتم صفّها قبل صفّ الملف المُسجَّل. القيمة الافتراضية: مصفوفة فارغة ()array. ver$: إصدار الملف المُسجَّل، تقوم ووردبريس بوضعه كرقم بعد رابط الملف، على الشكل:custom.css?ver=123، إن لم يتم وضع قيمة لهذا المحدّد، فسيتم وضع إصدار ووردبريس الحالي بدلاً منه، لعدم وضع أي رقم نضع قيمة المحدّد null. القيمة الافتراضية:false. media$: قيمة حقل media الذي سيتم استخدامه مع وسم <link> أثناء صفّ الملف، القيمة الممكنة: all، screen، handheld، print. القيمة الافتراضية هي all. ملاحظة هامة: عند تسجيل أو صفّ الملفات، يجب أن تكون الروابط مرنة، أي أن يتم استبدال اسم الموقع/النطاق عن طريق دوالّ ووردبريس. مثال خاطئ: add_action( 'wp_enqueue_scripts', 'register_invalid_style' ); function register_invalid_style() { wp_register_style( 'my-invalid-style', 'http://localhost/wp-content/themes/my-theme/css/custom.css' ); } هل لاحظتم أنني وضعت المسار كاملاً؟ ترى هل سيعمل الرابط السابق إن قمنا باستخدام القالب على موقع على الإنترنت بدلاً من الموقع المحلّي؟ بالتأكيد لا! مثال صحيح: add_action( 'wp_enqueue_scripts', 'register_valid_style' ); function register_valid_style() { wp_register_style( 'my-valid-style', get_template_directory_uri() . '/css/custom.css' ); } تكون النتيجة في المتصفح مشابهة للتالي: <link rel='stylesheet' id='my-valid-style-css' href='http://localhost:8000/wp-content/themes/my-theme/css/custom.css?ver=4.2' type='text/css' media='all' /> تقوم دالّة ()get_template_directory_uri بإرجاع رابط القالب الفعّال (active)، مثلاً: http://example.com/wp-content/themes/my-theme، بحيث يكون اسم النطاق حسب الموقع الحالي، ثم يقوم المطوّر بإضافة مسار الملّف الذي يريده بعد رابط القالب الفعّال. إن أردنا تسجيل وصفّ الملفات ضمن الإضافات بدلاً من القوالب، نقوم باستخدام دالّة ()plugins_url بدلاً من الدالّة السابقة الخاصة بالقوالب. صف ملف CSS لصفّ ملف CSS نستخدم دالّة wp_enqueue_style، محدّدات الدالّة هي نفسها محدّدات دالّة wp_register_style، باستثناء: محدّد handle$ هو المحدد الوحيد المطلوب في حال استخدامنا لمعرّف ملف مُسجّل مسبقاً. محدد src$ غير مطلوب في حال نقوم باستخدام معرّف لملف مُسجّل مسبقاً، ومطلوب إن كنا نريد استخدام الدالّة لصفّ ملفّ غير مسجّل. فعوضاً عن تسجيل الملف بدالّة منفصلة ثم صفّه بدالّة أخرى، نقوم بصفّه مباشرة في هذه الدالّة. مثال عن صفّ ملف مسجّل مسبقاً: add_action( 'wp_enqueue_scripts', 'enqueue_style' ); function enqueue_style() { wp_enqueue_style( 'my-valid-style' ); } مثال عن صفّ ملف جديد دون تسجيل: add_action( 'wp_enqueue_scripts', 'register_enqueue_style' ); function register_enqueue_style() { wp_enqueue_style( 'my-valid-style', get_template_directory_uri() . 'my-theme/css/custom.css' ); } نلاحظ أننا في المثال الثاني استخدمنا دالّة wp_enqueue_style بشكل مماثل لدالّة wp_register_style. الفرق الرئيسي بين الطريقتين، أن الأولى تسمح لنا باستخدام الملف المُسجل في عدة أماكن، وتتيح مرونة أكبر بالتعامل مع الملفات. إلغاء صفّ أو إلغاء تسجيل ملف CSS قد نحتاج لإلغاء صفّ ملف، أو إلغاء تسجيله (كما سنرى في نهاية المقال)، تتيح ووردبريس دالّتين لهذين الغرضين هما: wp_dequeue_style لإلغاء صفّ ملف و wp_deregister_style لإلغاء تسجيل ملف. في كلا الدالّتين نقوم بتمرير محدّد واحد هو المعرّف الخاص بالملف الذي نريد إلغاء صفّه أو إلغاء تسجيله، لإلغاء صفّ إطار عمل Bootstrap مثلاً، نضع الأسطر التالية في ملف functions.php: add_action( 'wp_enqueue_scripts', 'dequeue_bootstrap' ); function dequeue_bootstrap() { wp_dequeue_style( 'bootstrap' ); } تسجيل وصفّ ملفات جافاسكريبت آلية تسجيل وصفّ ملفات جافاسكريبت هي مماثلة جداً للتعامل مع ملفات CSS، مع بعض الفروقات البسيطة التي سنستعرضها الآن. تسجيل ملف جافاسكريبت نقوم باستخدام دالّة wp_register_script، التي تقبل المحدّدات التالية: handle$: مطلوب، هو المعرّف الخاص بالملف، الذي سيتم استخدامه عند صفّ الملف (enqueue). src$: مطلوب، هو رابط (URL) ملف جافاسكريبت المطلوب تسجيله، مثل:http://example.com/js/myscript.js، لكن يجب ألا يتم استخدام الرابط بهذا الشكل، بل يجب أن يكون مرناً باستخدام ()get_template_directory_uri. deps$: مصفوفة من المعرّفات، التي تمثّل متطلبات الملف الذي نقوم بتسجيله، كي يتم صفّها قبل صفّ الملف المُسجَّل. القيمة الافتراضية: مصفوفة فارغة ()array. ver$: إصدار الملف المُسجَّل، تقوم ووردبريس بوضعه كرقم بعد رابط الملف، على الشكل:custom.js?ver=123، إن لم يتم وضع قيمة لهذا المحدّد، فسيتم وضع إصدار ووردبريس الحالي بدلاً منه، لعدم وضع أي رقم نضع قيمة المحدّد null. القيمة الافتراضية: false. in_footer$: بشكل افتراضي يتم صفّ ملفات جافاسكريبت وملفات CSS ضمن وسم <head>، لكن يمكن بوضع قيمة هذا المحدد true أن يتم صفّ ملفات جافاسكريبت في نهاية المستند، قبل إغلاق وسم <body/>، وهو الأفضل للأداء بالنسبة لزوار الموقع. القيمة الافتراضية: false. ملاحظة: صفّ ملفّات جافاسكريبت و CSS يتطلب وجود خطّاف ()wp_head ضمن القالب، وصفّ ملفات جافاسكريبت مع محدّد in_footer$ بقيمة true يتطلب وجود خطّاف ()wp_footer في القالب، قبل إغلاق وسم <body/>. صفّ ملف جافاسكريبت الاستخدام مشابه تماماً لصفّ ملف CSS، لكنه يتم عن طريق دالّة wp_enqueue_script، والتي تشابه بمحدداتها دالّة التسجيل wp_register_script. الفرق بين محددات دالة الصفّ ودالّة التسجيل الخاصة بملفات جافاسكريبت هي كالفرق بين محددات دالة الصف والتسجيل الخاصة بملفات CSS. محدّدات دالّة wp_enqueue_script هي نفسها محدّدات دالّة wp_register_script، باستثناء: محدّد handle$ هو المحدد الوحيد المطلوب في حال نقوم باستخدام معرّف لملف مُسجّل مسبقاً. محدد src$ غير مطلوب في حال نقوم باستخدام معرّف لملف مُسجّل مسبقاً، ومطلوب إن كنا نريد استخدام الدالّة صفّ ملفّ غير مسجّل. فعوضاً عن تسجيل الملف بدالّة منفصلة ثم صفّه بدالّة أخرى، نقوم بصفّه مباشرة في هذه الدالّة. إلغاء صفّ أو إلغاء تسجيل ملف جافاسكريبت طريقة إلغاء صفّ أو إلغاء تسجيل ملف جافاسكريبت هي مشابه للطريقة في ملفات CSS، لكن باستخدام دالّتي: wp_deregister_script و wp_dequeue_script. أمثلة وحالات استخدام بالمثال يتضح المقال، سنمرّ معاً على أربعة أمثلة وحالات استخدام لنرى من خلالها كيف يمكننا التعامل ثم الاستفادة من تسجيل وصفّ ملفات JavaScript و CSS: 1. عند استخدام إضافة رديئة الجودة لنفرض لسبب ما أنك تستخدم إضافة رديئة -لا تتبع المعايير ولا تستخدم أحد الإصدارات من المكتبات-، تتطلب هذه الإضافة وجود إصدارٍ قديم من مكتبة jQuery، بينما قالبك يستخدم الإصدار اﻷحدث منها. هل من المنطقي وجود نسختين من المكتبة في القالب؟ بالتأكيد لا. لحلّ هذه المشكلة نحن أمام ثلاثة خيارات: إن كانت الإضافة ليست رديئة الجودة كثيراً، وتقوم بصفّ مكتبة jQuery، فهذا شيء جيّد، يمكننا ببساطة إلغاء المكتبة من الصفّ وتنتهي المشكلة. إن كانت الإضافة رديئة كما وصفناها ولا تقوم بصفّ مكتبة jQuery، عندها يجب على المطوّر أن يقوم بالتعديل على ملفات الإضافة يدوياً لإلغاء تحميل مكتبة jQuery. وهناك احتمال كبير أن المطور سينسى التعديل الذي قام به، ومع مرور الأيام يقوم بتحديث الإضافة إلى إصدار جديد ويذهب التحديث اليدويّ الذي قام به! أو إن كان ذو ذاكرة قوية، سيقوم بالقيام بالتعديل اليدوي ذاته في كل مرة يظهر إصدار جديد من الإضافة. لكم أن تتخيلوا المعاناة التي ستصبح على كاهل المطوّر. الخيار الثالث والأسرع هو القيام بحذف هذه الإضافة رديئة الجودة والبحث عن واحدة أفضل منها تتبع المعايير والقواعد وتستخدم أحد الإصدارات من ملفات JavaScript و CSS. الخيار الثالث هو الأفضل لتقليل استخدام مسكنات ألم الرأس. من المهم اتباع المعايير والقواعد المتفق عليها حتى لا يقع المطوّر في الحُفر التي وُضعت تلك المعايير والقواعد من أجل تلافيها. 2. استخدام المكتبات الموجودة في ووردبريس ربّما حدّثتك نفسك في أحد الأيام أن تستعرض ملفات ووردبريس وترى محتواها، إنْ حدث ذلك فلا بدّ أنك رأيت الكثير من مكتبات جافاسكريبت مثل jQuery، jQuery UI، Backbone وغيرها. إن كانت هذه الملفات موجودة ضمن ووردبريس، فلمَ لا نقوم باستخدامها عند الحاجة إليها؟ لو كان القالب يحتاج إلى مكتبتيّ jQuery و jQuery UI فبدلاً من تحميل نسخة من كل مكتبة من الإنترنت ثم وضعها ضمن ملفات القالب واستخدامها، يمكننا بشكل مباشر استخدام نسخة jQuery و jQuery UI الموجودتان ضمن ووردبريس. بهذا نضمن الحصول على إصدار حديث من المكتبة يأتي مع كل تحديث لووردبريس بالإضافة لعدم التكرار (Don’t Repeat Yourself). من المكتبات الشهيرة المضمّنة في ووردبريس: jQuery jQuery UI Backbone jQuery Suggest Thickbox TinyMCE Underscore للاطلاع على كامل القائمة يمكن زيارة صفحة التوثيق. 3. استخدام jQuery بشكل مباشر من شبكة توصيل المحتوى (CDN) لا بدّ أنك سمعت بشبكة توصيل المحتوى (Content Delivery Network). تعريفها على ويكبيديا: هي مجموعة من الخوادم المتزامنة والموزعة والموجودة على الشبكة في أماكن جغرافية مختلفة، تحتوي على نسخ من البيانات. فالعميل يحصل على البيانات من الخادم الموجود في أقرب موقع جغرافي، بغرض تقليل التأخير الناتج في نقل البيانات. هناك موقع مخصص لاستخدام مكتبات JavaScript عن طريق شبكات توصيل المحتوى هو jsDelivr، سنقوم باستخدام رابط مكتبة jQuery منه (//cdn.jsdelivr.net/jquery/2.1.3/jquery.min.js) لنقوم بصفّها واستخدامها ضمن القالب، عوضاً عن استخدام النسخة المتضمنة في ملفات ووردبريس. للقيام بهذا نحتاج لوضع الأسطر القليلة التالي في ملف functions.php الخاص بقالبنا: add_action( 'wp_enqueue_scripts', 'register_jquery' ); function register_jquery() { wp_deregister_script( 'jquery' ); wp_register_script( 'jquery', ( '//cdn.jsdelivr.net/jquery/2.1.3/jquery.min.js' ), false, null, true ); wp_enqueue_script( 'jquery' ); } قمنا بإلغاء تسجيل jQuery (كانت مسجلة مع الملف المتضمَّن في ووردبريس)، ثم قمنا بتسجيلها مع رابط الملف من شبكة توصيل المحتوى (CDN)، وأخيراً قمنا بصفّها (enqueue) ليتم إدراجها في القالب. 4. صفّ ملف جافاسكريبت يعتمد على jQuery في معظم الحالات نحتاج في القوالب لإضافة جافاسكريبت، سواء لإضافة حركات معيّنة أو لتعديل شيءٍ ما، وبسبب شهرة مكتبة jQuery فمعظم المطورين يعتمدون عليها كقاعدة أساسية لبناء ملفات جافاسكريبت الخاصة بقوالبهم. على فرض أن الملف الذي نريد إضافته يعتمد على مكتبة jQuery وهو موجود مع ملفات القالب في المسار: js/custom.js، لصفّ هذا الملف نقوم بإضافة الأسطر التالية إلى ملفfunctions.php: add_action( 'wp_enqueue_scripts', 'enqueue_custom_js' ); function enqueue_custom_js() { wp_register_script( 'my-custom-js', get_template_directory_uri() . '/js/custom.js', ['jquery'] ); wp_enqueue_script( 'my-custom-js' ); } قمنا بتسجيل الملف الذي نريد صفّه، ولنلاحظ كيف حدّدنا متطلبات الملف ضمن مصفوفة، يعتمد الملف على مكتبة jQuery فقط. ثم قمنا بصفّه باستخدام المعرّف الذي استخدمناه أثناء تسجيل الملف. تكون النتيجة في المتصفح مشابهة للتالي: <script type="text/javascript" src="//cdn.jsdelivr.net/jquery/2.1.3/jquery.min.js?ver=4.2"></script> <script type="text/javascript" src="http://localhost:8000/wp-content/themes/my-theme/js/custom.js?ver=4.2"></script> ونلاحظ أن ووردبريس قامت بصفّ مكتبة jQuery قبل الملف الذي قمنا بتسجيله، وذلك كي يقوم المتصفح بقراءة ملف المكتبة في البداية وتكون متوفرة للاستخدام، وعند قراءة المتصفح للملف الخاص يمكن للملف استخدام مكتبة jQuery بعد أن أصبحت متوفرة. تمرير متغيّرات من PHP للجافاسكريبت ماذا لو أردنا استخدام متغيّرات ما ضمن جافاسكريبت؟ قد يتهيؤ للبعض أن يقوم بعمل طلب AJAX أو وضع ما يريد استخدامه في جافاسكريبت بداخل ملف خارجي. قد تعمل هذه الحلول، لكنها لن تجدي نفعاً إن أردنا تمرير متغيّرات تتبدّل قيمتها باستمرار كأن تكون من قاعدة البيانات مثلاً. توفّر ووردبريس حلّاً سهلاً ومناسباً لهذه المشكلة، وذلك باستخدام دالّة wp_localize_script، اسم الدالّة قد يوحي أنها مخصصة للترجمة، لكن يمكن استخدامها لتمرير جمل الترجمة وأي نوع آخر من المتغيّرات إلى جافاسكريبت. محددات الدالّة هي: - handle$: معرّف لملف جافاسكريبت الذي نريد تمرير المتغيّرات له، يجب أن يكون الملف مسجّلاً قبل استخدام الدالّة. - name$: اسم متغيّر جافاسكريبت الذي سيتم وضع البيانات بداخله. - data$: مصفوفة المتغيّرات التي نريد تمريرها إلى جافاسكريب. مثال: لنقم بتمرير متغيّرين هما سلسلة نصية ورقم إلى ملف جافاسكريبت ذو المحدد my-custom-js: add_action( 'wp_enqueue_scripts', 'enqueue_custom_js' ); function enqueue_custom_js() { wp_register_script( 'my-custom-js', get_template_directory_uri() . '/js/custom.js', ['jquery'] ); $translation_array = array( 'some_string' => 'A String to be using inside JS', 'a_value' => '10' ); wp_localize_script( 'my-custom-js', 'object_name', $translation_array ); wp_enqueue_script( 'my-custom-js' ); } كي نصل إلى المتغيّرات من داخل ملف custom.js، نستخدم شيئاً مشابهاً: alert( object_name.some_string); يجب أن تظهر رسالة تنبيه (Alert) بداخلها النصّ الذي استخدمناه. صفّ الملفات في لوحة التحكم كل ما مرّ معنا من تسجيل وصفّ الملفات هو خاص بواجهة الموقع (Front-end)، أي الذي يراه الزوار. إن أردنا تسجيل وصفّ الملفات في لوحة التحكم (Dashboard) يمكننا ذلك بنفس الطريقة، لكن باستبدال حدث wp_enqueue_scripts بحدث: admin_enqueue_scripts. مثلاً لصفّ مكتبة jQuery Suggest في لوحة التحكم (المكتبة معرّفة مسبقاً في ووردبريس)، نستخدم الأسطر التالية: add_action( 'admin_enqueue_scripts' , 'enqueue_jquery_suggest' ); function enqueue_jquery_suggest() { wp_enqueue_script( 'suggest' ); } ملاحظة: من المناسب وضع شروط معيّنة قبل صفّ الملفات وقصرها على صفحاتٍ معينة، كي لا يتم وضع الملف في كل صفحات لوحة التحكم. الخاتمة تعرّفنا على كيفية صفّ ملفات JavaScript و CSS، هذه الآلية تسهّل كثيراً تنظيم الملفات والتعامل معها، ويجب الحرص على استخدامها بشكل دائم، فهي من المعايير والأشياء المتعارف عليها في تطوير قوالب وإضافات ووردبريس. أرجو أن يكون الشرح واضحاً ومفيداً، إن كان لديكم سؤال أو فكرة فلتشاركونا إياها في التعليقات.

بعد أن تطرّقنا في هذه السّلسلة حول أساسيات تطوير قوالب ووردبريس إلى تحويل صفحة HTML إلى قالب ووردبريس ثم إلى كيفية إضافة Pagination (أو ما يُعرف بالتّصفيح) إليها، سنتطرّق اليوم إلى خاصّيّة أخرى لا تقل أهمّية. قوائم التنقّل (Navigation Menu) هي إحدى ميزات القوالب، توفّر ووردبريس طريقة سهلة للتحكم بالقوائم المخصصة للقالب من داخل لوحة تحكم ووردبريس، وكل ما تحتاجه هو إضافة بضعة أسطر برمجية لتضيف دعم القوائم في قالبك. فهرس السلسلة: مقدمة إلى تطوير قوالب ووردبريس: تحويل صفحة HTML إلى قالب ووردبريس التصفيح (Pagination) في قوالب ووردبريس إضافة قوائم التنقل (Navigation Menu) إلى قالب ووردبريس (هذا الدرس) صف وتسجيل ملفات Javascript و CSS في قوالب ووردبريس تسجيل القوائم بدايةً في ملف functions.php ضمن ملفات القالب نحتاج لإضافة دالّة تقوم بتسجيل أسماء القائمة (أو القوائم) التي تريد إضافتها. كالتالي: add_action('init', function() { register_nav_menu('our-custom-menu', 'القائمة الرئيسية'); }); بعد ذلك يمكن التأكد من صحة إضافة القائمة عن طريق الذهاب من لوحة التحكم إلى المظهر (Appearance) ثم القوائم (Menus)، ستظهر لدينا قائمة باسم القائمة الرئيسية في تبويب إدارة موضع القوائم. تأخذ دالّة register_nav_menu محدّدين هما: المكان (Location) والوصف (Description). محدّد المكان يستخدم كمعرّف للقائمة، حيث يتم طلب محتوى القائمة ضمن ملفات القالب عن طريق محدّد المكان (location) الذي قمنا بتعيينه أثناء تسجيل القائمة. في حالتنا قمنا بوضع قيمة المحدد هي: our-custom-menu. والوصف يتم استخدامه عند عرض القائمة في لوحة التحكم ليكون أنسب وأسهل للقراءة من محدد المكان، في حالتنا قمنا بوضع قيمة الوصف هي: القائمة الرئيسية. يمكننا تسجيل أكثر من قائمة في آن واحد عن طريق استخدام دالّة register_nav_menus التي تستخدم بشكل مشابه لدالّة register_nav_menu لكن المحدّدات تكون على شكل مصفوفة اسميّة (Associative Array)، كل عنصر في المصفوفة يمثّل قائمة واحدة بحيث يكون مفتاح العنصر هو محدّد المكان وقيمة العنصر هي محدّد الوصف. في قالبنا لا نحتاج سوى لقائمة واحدة، في ما يلي كيفية تسجيل أكثر من قائمة معًا: add_action('init', function() { register_nav_menus([ 'our-custom-menu' => 'القائمة الرئيسية', 'our-second-menu' => 'القائمة الفرعية', ]); }); كما ننوه إلى وجود دالّة معاكسة لدالّة تسجيل القوائم هي unregister_nav_menu لكننا لن نتطرّق إليها الآن. إظهار القائمة في القالب الخطوة الأخيرة ضمن القالب هي عرضه في المكان المناسب. في القالب الذي نستعمله نجد أن موقع القوائم أصبح في ملف header.php، في السطر 30 من الملف نجد وسم <section class="top-bar-section">، نريد أن نضع القائمة بدلاً من وسم <ul> الموجود بداخله. نقوم بحذف وسم <ul> مع محتواه، ثم نستخدم السطر البرمجيّ التالي لعرض القائمة: <?php wp_nav_menu(['theme_location' => 'our-custom-menu']); ?> تقبل دالّة wp_nav_menu مُحدداً واحداً هو مصفوفة تحوي عددًا من الإعدادات، الإعداد الوحيد الضروري هو theme_location ويتم استخدامه كما في السطر البرمجي السابق. يمثل هذا المحدّد قيمة محدّد المكان السابقة التي استخدمناها أثناء تسجيل قائمة جديدة والتي كانت: our-custom-menu. في حال لم يتم إدخال هذا المحدّد تقوم ووردبريس باستخدام قيمة إعداد menu (سنأتي إليه في الفقرة التالية)، وإن لم تجد قيمة فسيتم عرض أول قائمة غير فارغة تجدها ووردبريس، وفي حال عدم وجود أي قوائم غير فارغة وعدم تمرير محدّد المكان فلا يتم عرض شيء. إن ألقينا نظرة على القالب من المتصفح سنجد أن شكل عناصر القائمة أصبح مختلف قليلاً عن الشكل الذي كان عليه، وذلك ﻷن الدالّة تقوم بإضافة وسم <div> محيط بوسوم القائمة. في الفقرة التالية سنتعرف على بقية الإعدادات التي يمكن أن نستخدمها مع دالّة wp_nav_menu والتي ستمكننا من إظهار القائمة على الشكل الأنسب. إعدادات دالة wp_nav_menu كما قلنا من قبل فإن دالّة wp_nav_menu تأخذ محدّداً واحداً هو مصفوفة تحوي مجموعة إعدادات، المبرمج ليس مضطراً لإدخال جميع الإعدادات، يمكنه إدخال بعضها والباقي ستقوم ووردبريس بمعالجته وإسناد قيمته الافتراضية. الإعدادات بشكل كامل هي: <?php $defaults = array( 'theme_location' => '', 'menu' => '', 'container' => 'div', 'container_class' => '', 'container_id' => '', 'menu_class' => 'menu', 'menu_id' => '', 'echo' => true, 'fallback_cb' => 'wp_page_menu', 'before' => '', 'after' => '', 'link_before' => '', 'link_after' => '', 'items_wrap' => '<ul id="%1$s" class="%2$s">%3$s</ul>', 'depth' => 0, 'walker' => '' ); wp_nav_menu( $defaults ); ?> theme_location مكان القائمة ضمن القالب، كما تم تحديده أثناء تسجيل القائمة باستخدام دالّة register_nav_menu، ليكون بإمكان المستخدم تحديد القائمة المطلوبة للمكان الذي تم تسجيله (دون تقييد المستخدم بقائمة واحدة). القيمة الافتراضية: '' (سلسلة نصية فارغة) menu القائمة المطلوب عرضها، تقبل قيمة المعرّف الرقمي (ID)، أو الاسم اللطيف (slug)، أو الاسم الخاص بالقائمة (وليس مكان القائمة ضمن القالب). القيمة الافتراضية: '' (سلسلة نصية فارغة) container لتحديد إن كان مطلوبًا من ووردبريس إحاطة وسم <ul> بوسم آخر أم لا، القيمة المسموحة هي div أو nav، وفي حال عدم الرغبة بإحاطة القائمة بوسم نجعل القيمة false. القيمة الافتراضية: 'div' container_class الصنف الخاص بوسم html المحيط بالقائمة، بشكل افتراضي يأخذ الصنف الشكل: menu-{menu slug}-container حيث يكون {menu slug} هو الاسم اللطيف للقائمة. القيمة الافتراضية: '' (سلسلة نصية فارغة) container_id معرّف CSS (ID) الذي يتم تطبيقه على الوسم المحيط (container). القيمة الافتراضية: '' (سلسلة نصية فارغة) menu_class الصنف الذي يتم تطبيقه على وسم القائمة <ul>، يمكن أن يتم وضع أكثر من صنف يتم الفصل بينهم بفراغات (space). القيمة الافتراضية: 'menu' menu_id معرّف (ID) CSS الذي يتم تطبيقه على وسم القائمة <ul>. بشكل افتراضي تكون قيمته: menu-{menu slug} حيث {menu slug} هو الاسم اللطيف للقائمة؛ في حال حدوث تكرار بالاسم يتم إضافة إشارة - مع رقم مميز يبدأ من 1 ويزيد عند كل تكرار، مثلًا: menu-{menu slug}-1، menu-{menu slug}-2، إلخ. القيمة الافتراضية: '' (سلسلة نصية فارغة) echo فيما إن كنا نريد إظهار القائمة مباشرة في مكان استخدام دالّة wp_nav_menu أو نريد إرجاعها (return). القيمة الافتراضية: true fallback_cb دالّة ليتم استخدامها في حال لم تكن القائمة موجودة، نضع قيمتها false في حال لم نكن نريد استخدام دالّة. ويتم تمرير محدّد $args للدالّة التي يتم استخدامها. القيمة الافتراضية: 'wp_page_menu' before إظهار نصّ قبل وسم <a>. القيمة الافتراضية: '' (سلسلة نصية فارغة) after إظهار نصّ بعد وسم </a>. القيمة الافتراضية: '' (سلسلة نصية فارغة) link_before إظهار نصّ قبل نصّ الرابط. القيمة الافتراضية: '' (سلسلة نصية فارغة) link_after إظهار نصّ بعد نصّ الرابط. القيمة الافتراضية: '' (سلسلة نصية فارغة) items_wrap يتم تفسيرها بنفس الطريقة التي يتم تفسير محدّد الهيئة (format) لدالّة sprintf. يحدث تعاون بين المحددات الأخرى عن طريق رموز رقمية. %1$s تُستبدل بقيمة محدد menu_id، %2$s تُستبدل بقيمة محدد menu_class، و %3$s تُستبدل بقيمة عناصر القائمة (وسوم <li>). إن تم استبعاد أي رمز رقمي من هذا المحدّد، سيتم استبعاد المحدّد المرتبط به من وسوم القائمة. القيمة الافتراضية: '<ul id="%1$s" class="%2$s">%3$s</ul>' depth يمثل عدد المستويات الهرمية التي سيتم استخدامها، حيث رقم 0 يعني جميع المستويات. ويتم استخدام قيمة -1 لتحويل جميع المستويات إلى مستوى واحد فقط. القيمة الافتراضية: 0 walker يتم تمرير عنصر هو نسخة من صنف Walker_Nav_Menu أو من صنف يرث من ذلك الصنف. الهدف من هذا المحدد هو التحكم بشكل كامل بالأصناف (classes) والمحدّدات (IDs) ووسوم HTML للقائمة. يمكن العودة لتوثيق WordPress للاطلاع على المثال المقدم القيمة الافتراضية: '' (سلسلة نصية فارغة) تحسين ظهور القائمة في القالب بعد أن تعرّفنا على إعدادات إظهار القائمة، دعونا نقوم بتعديلها في قالبنا لتصبح مناسبة أكثر. إن شاهدنا مصدر HTML للصفحة الرئيسية من المتصفح، نجد أننا نحتاج لإزالة الوسم المحيط بالقائمة (container)، ونحتاج لإضافة صنف right لوسم <ul> المحيط بعناصر القائمة. يمكننا تعديل السطر البرمجي في ملف header.php ليصبح: <?php wp_nav_menu([ 'theme_location' => 'our-custom-menu', 'container' => false, 'menu_class' => 'right', ]); ?> قمنا بجعل قيمة الوسم المحيط (container) تساوي false ﻷننا لا نريد إحاطة القائمة بأي وسم، فنحن من البداية نقوم بإحاطة القائمة بوسم <section> في قالب HTML الذي نستخدمه. وقمنا أيضًا بإضافة قيمة محدد menu_class لتساوي: right، ليتم إضافة صنف right لوسم القائمة <ul> ليظهر بشكل جيّد. بهذا نكون قد جعلنا القائمة تظهر بشكل مرن، ونعطي المستخدم إمكانية أكبر لاختيار ما يناسبه من عناصر للقائمة من خلال لوحة التحكم، وبنفس الوقت جعلنا القائمة التي يختارها المستخدم تظهر بأفضل شكل ضمن القالب الذي نعمل عليه. الشريط الجانبي الأشرطة الجانبية (Sidebars) هي إحدى ميزات القوالب، هو بشكل بسيط عمود شاقولي يقوم القالب بتزويده لعرض معلومات مختلفة عن المحتوى الأساسي للموقع، تقوم الأشرطة الجانبية بعرض ودجات/مربعات (widgets) يقوم مدير المدونة بالتحكم بها. التعامل مع الشريط الجانبي يشبه إلى حدّ كبير التعامل مع القوائم. تسجيل شريط جانبي لنقم معاً بإضافة ما يلي إلى ملف functions.php لتعريف شريط جانبيّ جديد: add_action('widgets_init', function() { register_sidebar(); }); إن قمنا بزيارة لوحة التحكم، نجد أن هناك عنصراً جديداً في قائمة المظهر (Appearance) هو الودجات (Widgets)، بداخله يظهر لنا الشريط الجانبي الجديد بعنوان الشريط الجانبي 1، إن قمنا بإضافة شريط جانبي آخر سيأخذ نفس الاسم لكن بزيادة الرقم بمقدار واحد. والسبب أننا عندما قمنا بتسجيل الشريط الجانبي لم نحدد له اسماً أو معرّفاً. سنقوم بهذا الآن بعد أن نتعرف على إعدادات هذه الدالّة. إعدادات دالّة register_sidebar الإعدادات الافتراضية: $args = array( 'name' => sprintf( __( 'Sidebar %d' ), $i ), 'id' => "sidebar-$i", 'description' => '', 'class' => '', 'before_widget' => '<li id="%1$s" class="widget %2$s">', 'after_widget' => "</li>\n", 'before_title' => '<h2 class="widgettitle">', 'after_title' => "</h2>\n", ); شرح الإعدادات: name اسم الشريط الجانبي (القيمة الافتراضية هي ترجمة كلمة ‘Sidebar’ مع معرّف رقميّ). id معرّف الشريط الجانبي - يجب أن يكون بأحرف صغيرة (lowercase), دون فراغات (القيمة الافتراضية هي معرّف رقمية يتم زيادته تلقائياً ). description وصف نصّي لماهيّة/مكان الشريط الجانبي. يظهر في واجهة إدارجة الودجات في لوحة التحكم. (القيمة الافتراضية: فارغة) class صنف CSS ليتم إسناده للشريط الجانبي في صفحة إدارة الودجات، ولن يتم استخدام هذا الصنف في القالب. ملاحظة: سيتم إضافة كلمة “sidebar” إلى قيمة الصنف. مثلاً: إن وضعنا اسم الصنف: tal ستكون قيمة الصنف هي: sidebar-tal. (القيمة الافتراضية: فارغة). before_widget وسم/وسوم HTML ليتم وضعها قبل كل واحد من الودجات (widget) (القيمة الافتراضية: ‘<li id="%1$s" class="widget %2$s">‘). ملاحظة: يتم استخدام دالّة sprintf لاستبدال المتحولات. after_widget وسم/وسوم HTML ليتم وضعها بعد كل واحد من الودجات (widget) (القيمة الافتراضية: '\n'). before_title وسم/وسوم HTML ليتم وضعها قبل كل عنوان (القيمة الافتراضية: <h2 class="widgettitle">). after_title وسم/وسوم HTML ليتم وضعها بعد كل عنوان (القيمة الافتراضية: “</h2>\n“). عرض الشريط الجانبي في القالب نتوجه إلى ملف sidebar.php، ونقوم بتعديله ليصبح كالتالي: <div class="large-4 columns sidebar"> <?php dynamic_sidebar(); ?> </div> قمنا باستبدال النصّ الموجود مسبقاً “Sidebar” بدالّة ()dynamic_sidebar التي وظيفتها عرض محتويات الشريط الجانبي في المكان المحدد. يمكن أن نمرّر قيمة واحدة لتلك الدالّة إما أن تكون اسم (name) أو معرّف (ID) الشريط الجانبي. وفي حال عدم تمرير أي قيمة يتم عرض الشريط الجانبي الأول. تخصيص الشريط الجانبي كما لاحظنا فشكل ودجات الشريط الجانبي غير مقبولة، لنقم معًا بتحسين مظهرها عن طريق إحاطة كل واحدة من الودجات (widgets) بوسم <div class="card"> الذي كان موجودًا في ملف sidebar.php قبل استخدام دالّة عرض الشريط الجانبي. لنقم باستخدام إعدادات دالّة ()register_sidebar التي مرّت معنا في الفقرات السابقة، في ملف functions.php نقوم بتعديل الدالّة لتصبح: register_sidebar(['before_widget' => '<div class="card">', 'after_widget' => '</div>']); قمنا بتمرير إعدادَين فقط لإضافة وسم div قبل واحدة من الودجات وإضافة إغلاق الوسم بعد كل واحدة منها. بهذا نكون قد انتهينا من إضافة قائمة رئيسية وشريط جانبي إلى القالب، وتعلمنا معاً كيف يمكن تخصيص شكل القائمة والشريط الجانبي ليتناسب مع القالب بأفضل شكل ممكن.

في السّنوات الأخيرة ازداد الطلب على مُصمّمي تجربة المستخدم لدرجة عالية جدًا، كما ازداد عدد الكتب التي تتحدّث عن هذا الموضوع وأُضيف لهذا التخصّص قوانين، نظريات وفلسفيات من أجل تطويره وتحسينه. إذا عدنا بالزّمن للوراء إلى بداية البرامج الحاسوبية، تجد أن مهندسين البرامج ومديري المنتجات كانوا يُعلّمون بأن البرنامج إذا ازدادت ميزّاته ووظائفه ازدادت مبيعاته. هذا كان صحيحًا وذلك لأنه لم يكن السّوق مليئا بالبرامج والمنتجات التقنية مما لا يدع للمستخدم أي خيار سوى أن يشتري هذا البرنامج حتى ولو كان معقّدًا من ناحية الاستخدام. إذا نظرنا الآن نجد أنّ البرامج والحلول التقنية في أيّ موضوع بسيط، مثلا تنظيم المهام، تجد أن عدد البرامج المتوفرة قد يجاوز المائة كحد أدنى مما يجعل المستخدم أمام كثير من الخيارات ويفتح باب المنافسة لأسهل البرامج استخدامًا، أجملها واجهة وحتى أكثرها متعة. إنّ من أهم المزايا التنافسية في الشركات العملاقة في عالمنا اليوم أمثال Google ،Apple ،Microsoft ،Samsung هي تجربة المستخدم. فعلى سبيل المثال جهاز بلاك بيري، كانت أجهزة بلاك بيري هي الرّائدة في سوق الهواتف الذكية ولكن عندما دخلت Apple بجهاز iPhone الذي كان بتطبيقات وخصائص عملية أقل من البلاك بيري، استطاعت أن تحصل على النّسبة الأكبر من السوق. هناك عوامل تنافسية كثيرة بين المنتجات ولكن بالنسبة لمنتجين متشابهين وقابلين للمقارنة تجربة المستخدم من أهم العوامل. ولتوضيح الفكرة أكثر انظر مثلا إلى جهاز iPod، بشكله البسيط، الرائع، الممتع في استخدامه وطرريقة ربطه مع برنامج iTunes، ما لبث أن ينزل على السّوق حتى أحَبه الجميع، مع العلم بوجود أجهزة تؤدي نفس الوظائف الرئيسية التي يؤديها iPod. ماهي تجربة المستخدم وماذا يندرج تحتها؟ الكثير من الناس يخطئ في فهم تجربة المستخدم أو قد يختزلها في موضوع معين، فمثلا هناك من يخلط ما بين تجربة المستخدم وواجهة المستخدم User Interface أيضا هناك من يخلط ما بينها وبين سهولة الاستخدام، لا يتّسع المجال لذكر كل المفاهيم الخاطئة فلذلك سنقوم في البداية بشرحٍ بسيط لتجربة المستخدم ومن ثم نقوم بتوضيح أكثر المفاهيم الخاطئة انتشارًا. تجربة المستخدم مجمل التأثير الذي يشعر به المستخدم كنتيجة لتفاعله واستخدامه لنظام (برنامج)، جهاز أو منتج متضمنا تأثير كل من سهولة الاستخدام والمنفعة والتأثير العاطفي. مع مراعاة أن التفاعل مع المنتج يتضمن النظر، اللمس، التفكير، الإعجاب بالمنتج وصورة المنتج في ذهن المستخدم قبل تجربته. لذا يمكن القول أن كلاً من سهولة الاستخدام والمنفعة والتأثير العاطفي هي عناصر مكونة لتجربة المستخدم. ولكن ماذا يعني كل عنصر من هذه العناصر ضمن إطار تجربة المستخدم، سأقوم بكشف هذا الغموض في توضيح هذه العناصر. سهولة الاستخدام هي العنصر العملي لتجربة المستخدم ويتضمن الفعالّية، الكفاءة، الإنتاجية، المرونة، القدرة على التعلم والاحتفاظ، ومدى رضا المستخدم. المنفعة العنصر المسؤول عن مدى تحقيق الوظائف التطبيقية للمنتج لأهداف المستخدمين، بمعنى هل حقق استخدام المنتج غايات المستخدمين وأهدافهم عندما أرادوا استخدامه. التأثير العاطفي العنصر العاطفي الذي يؤثر على عواطف المستخدم بشكل عام. ولكثرة العواطف وصعوبة حصرها سنذكر أكثرها أهمية ومراعاة مثل المتعة، السرور، الاستمتاع أثناء الاستخدام، جاذبية المنتج، أصالته، الرغبة باستخدامه وإبداعيته. كما يدخل أيضا فيها المشاعر العميقة مثل التعبير، الهوية الذاتية، الشعور بالمساهمة في العالم وفخر الملكية. تجربة المستخدم لا يمكن تصميمها تجربة المستخدم هي شعور داخلي يشعر به المستخدم أثناء استخدامه للمنتج ولذلك لا يمكن تصميمها، ولكننا نُصمّم المنتجات بحيث تعطي للمستخدم هذه التجربة، أي أننا نُصمّم لأجل تجربة المستخدم ولا نُصمّم التجربة ذاتها. حتى أن الكثير من المصممين اقترحوا تغيير مصلطح مصمم تجربة المستخدم إلى مهندس تجربة المستخدم أو المخطط الاستراتيجي لتجربة المستخدم. تجربة المستخدم ليست واجهة المستخدم واجهة المستخدم UI ليست إلا واجهة يقوم المستخدم بالتفاعل معها ليقوم بالوظائف التطبيقية التي يقوم بها النظام، ووجود كلمة مصمم هي ما أدت إلى الوقوع في هذا اللبس، فظن البعض أن مصمم تجربة المستخدم مثل مصمم الواجهات أو التصميم المرئي على Photoshop مثلا. في الحقيقة مصممي تجربة المستخدم يقومون بالتصميم ولكن ليس بالطريقة المعروفة في التصميم المرئي وإنما يقومون بتصميم الشيء غير المرئي ليقوموا بحلِ مشكلة ما أو تحسين العملية الوظيفية. سهولة الاستخدام مهمة ولكن تجربة المستخدم أكثر من ذلك مع بداية تطور هذا العلم ونضجه أصبحت الكثير من الشركات التقنية تتبنّى المبادئ الهندسية لسهولة الاستخدام وتستثمر في المختبرات المعقدة وتساهم في وضع اختبارت لسهولة الاستخدام، كل هذا وبلا شك رفع من جودة المنتجات من ناحية سهولة الاستخدام إلا أنه ثبت فيما بعد أن سهولة الاستخدام ليست هي الميزة التنافسية الوحيدة بين المنتجات وظهرت هناك عوامل تنافسية أخرى فيما بين المنتجات. لذلك، بالرغم من أن سهولة الاستخدام هي من أساسات تجربة المستخدم ولكنها لا تقف فقط هنا، فالتركيز في تصميم تجربة المستخدم يعود على البشر وليس على التقنية. تجربة المستخدم ليست محصورة على البرامج والأنظمة التصميم لتجربة المستخدم ليس محصورا على البرامج أو المواقع الإلكترونية، ولكنه يضم أيضا التصميم لكافة المنتجات سواء كانت برمجية أو مادية. فمثلا، وأنت تقوم بسحب النقود من الصراف الآلي فأنت تشعر بتجربة معينة نتيجة لانتظارك في الصف، لقرائتك للتعليمات، لإدخالك البطاقة ولسحبك النقود. تخيل ماذا لو كانت نافذة الصراف الآلي أطول أو أقصر منك ماذا لو قَرَأتِ البطاقة ولم تخرجها أو أخرجت مبلغا غير الذي طلبت. ما أحاول أن أصل إليه هنا هو أن المنتجات في كل مكان ونتفاعل معها في حياتنا اليومية وانتباهك لهذه المنتجات سيحسّن من طريقة تفكيرك كمُصمم لتجربة المستخدم وسيعمّق من نظرتك للأمور. سير العملية والاستراتيجة في تصميم تجربة المستخدم بالنظر إلى تجربة المستخدم وعناصره، يتضح لنا كم هو واسع إطار تجربة المستخدم وعن كمية الأشياء الهائلة التي يمكن أن تندرج تحته، لذلك لا بد من منهجية عمل تسهل بناء المنتجات بطريقة احترافية مع المحافظة على إمكانية الإبداع فيها. في الصورة أعلاه هناك خمس خطوات لإصدار النسخة الأولية من المنتج أو البرنامج وهو ما يسمى في الشركات الناشئة بالمنتج الفعّال القاعدي (Minimum Viable Product) أما الخطوتان الأخيرتان فهما تعودان إلى ما بعد الإصدار الأول وذلك لإنه حتى نصل إلى جودة عالية في المنتج لا بد من التكرار والتحسين عليه، بناءً على التغيرات التي تحدث في العالم (تطور التكنولوجيا، زيادة المنتجات المنافسة، …) وبناءً على رُدود الفعل من المستخدمين. منهجية العمل البحث: أنت لست المستخدم النهائي للمنهج وبالتالي لا بد لك من عمليات بحث مع أصحاب العمل ومع الجمهور المستهدف والتخطيط لكيفية بناء المنتج وما التكنولوجيا المستخدمة حتى تتمكن من فهم الأهداف من وراء المنتج. وبالعادة يتم استخدام البحث النوعي أو الإثنوجرافي (Ethnography) في بداية أية مشروع. المعالجة: تقارير البحث النهائية ليست كافية لتبدأ التصميم، هناك فجوة ما بينها وما بين التصميم، لا بد من معالجة نتائج البحث بحيث يمكن ترجمتها إلى أشياء قابلة للتصميم والعمل. التصميم: هنا نبدأ بالتصميم ولكن المقصود بالتصميم ليس التصميم المرئي فقط، يتم التصميم عبر خطوات من رسم ونماذج حتى الوصول للنموذج البصري النهائي في التصميم المرئي. الاختبار: إن كان هناك أخطاء معينة في التصميم فلا بد لك من معرفتها قبل أن يكتشفها المستخدم بنفسه، لذا لا بد من التأكد هل ما تم تصميمه مفهوم وسهل الاستخدام أم هو معقد ولا يصل للأهداف المرجوة. في هذه المرحلة يتم الاختبار للتصميم الذي قمنا به مع العلم بأنه يسير بشكل متوازي مع مرحلة التصميم بمعنى أنه لا نقوم بالاختبار عندما ننتهي من الخطوة الثالثة نهائيا وإنما نقوم باختبار كل مرحلة من مراحل التصميم في الخطوة السابقة. الإصدار: في هذه المرحلة نقوم بإطلاق الإصدار الأول ولكن مع وضع المعايير التي سوف تحدد نجاح أهدافنا التي سوف نقوم بقياسها بعد أن يتم تجربة البرنامج من قبل المستخدمين، ويتم التركيز هنا على البحث الكمي. القياس: عندما يصبح لدينا معلومات عن سلوك المستخدمين وكيفية استخدامهم لمنتجنا نقوم بتحليل هذه المعلومات وترجمتها إلى مرحلة التعلم. التعلم: عندما تبدأ بقياس النتائج سيتضح لك سلوك المستخدمين الحقيقي وليس الذي افترضته، هنا تتعلم أكثر عن حاجات وسلوك المستخدمين ومن ثم تقوم بترجمة هذه المعلومات إلى تحسينات، وعادة يتم استخدام البحث الكمي والنوعي في هذه المرحلة. لمزيد من القراءة مقال 10Most Common Misconceptions About User Experience Design مقالات UX Myths كتاب The Elements Of User Experience كتاب Don't Make Me Think