عبد اللطيف ايمش

تعلمنا في الجزء الأول من بُنى التحكم عن الأمر if وكيف يُستخدم لتعديل مسار تنفيذ البرنامج بناءً على حالة خروج أحد الأوامر. يسمى هذا النوع من مسارات تنفيذ البرامج -وفق الاصطلاحات البرمجية- بالتفرّع (branching) لأنَّه يشبه كثيرًا التنقل في شجرة، فعندما تصل إلى تفرّع، فستُحدِّد نتيجة الشرط أيَّ فرعٍ ستذهب إليه. هنالك نوعٌ آخرٌ أكثر تعقيدًا من أنواع التفرع يُسمى case، وهنالك عدِّة خيارات في case، فعلى عكس التفرّع البسيط الذي فيه طريقان فقط، يمكن أن تكون هنالك عدِّة نواتج بناءً على تحقيق شرط معيّن لقيمةٍ ما. يمكنك بناء مثل هذا النوع من أنواع التفرّع باستخدام عدِّة جمل if شرطية. سنحاول في المثال الآتي التحقق من مدخلات المستخدم: #!/bin/bash echo -n "Enter a number between 1 and 3 inclusive > " read character if [ "$character" = "1" ]; then echo "You entered one." elif [ "$character" = "2" ]; then echo "You entered two." elif [ "$character" = "3" ]; then echo "You entered three." else echo "You did not enter a number between 1 and 3." fi لكن ما سبق ليس كفؤًا كما كنا نتوقع، ولكن لحسن الحظ، توفِّر الصَدَفة لنا حلًا أفضل لهذه المشكلة: الأمر المُضمَّن ‏case، الذي يمكن استخدامه لبناء برنامج مكافئ تمامًا للبرنامج السابق: #!/bin/bash echo -n "Enter a number between 1 and 3 inclusive > " read character case $character in 1 ) echo "You entered one." ;; 2 ) echo "You entered two." ;; 3 ) echo "You entered three." ;; * ) echo "You did not enter a number between 1 and 3." esac الشكل العام للأمر case: case word in patterns ) commands ;; esac يُنفِّذ الأمر case عباراتٍ برمجيةً معيّنة إذا طابَقت الكلمة نمطًا (pattern)، يمكنك وضع أي عدد من الأنماط والعبارات. ويمكن أن تكون الأنماط نصًا عاديًا أو "محارف بديلة" (wildcards). يمكن وضع أكثر من نمط في نفس السطر بفصل الأنماط بمحرف |. هذا مثالٌ متقدمٌ يشرح لك ما أعنيه بكلامي السابق: #!/bin/bash echo -n "Type a digit or a letter > " read character case $character in # Check for letters [[:lower:]] | [[:upper:]] ) echo "You typed the letter $character" ;; # Check for digits [0-9] ) echo "You typed the digit $character" ;; # Check for anything else * ) echo "You did not type a letter or a digit" esac لاحظ النمط الخاص * الذي سيُطابِق أي شيء، لذلك سنحتاج إليه لمطابقة الحالات التي لم تُطابِقها الأنماط التي تسبقه. من المستحسن تضمين هذا النمط في نهاية الأمر case لكي يُستخدَم لكشف المدخلات غير الصحيحة. حلقات التكرار آخر جزء من بُنى التحكم التي سنناقشها هي حلقات التكرار، تُنفِّذ حلقات التكرار قسمًا من البرنامج لعددٍ من المرات وذلك بناءً على حالة خروج أحد الأوامر. توفِّر الصَدَفة ثلاثة أوامر للتكرار: while و until و for، وسنشرح while و until في هذا الدرس وسنترك for لدرسٍ لاحق. يؤدي الأمر while إلى تنفيذ كتلة من الشيفرة مرارًا وتكرارًا لطالما كانت حالة خروج الأمر المُحدَّد true (أي حالة الخروج 0). هذا مثالٌ بسيطٌ يعد الأرقام من 0 إلى 9: #!/bin/bash number=0 while [ "$number" -lt 10 ]; do echo "Number = $number" number=$((number + 1)) done أنشأنا في السطر الثالث متغيرًا وأسميناه number وأسندنا القيمة 0 إليه، ثم بدأنا حلقة while. وكما لاحظت، كان الأمر التي ستختبر حلقة while حالة خروجه هو الأمر test الذي يختبر قيمة العدد number. وفي مثالنا السابق، اختبرنا إذا كانت قيمة number أصغر من 10. لاحظ الكلمة do في السطر الرابع والكلمة done في السطر السابق. هاتان الكلمتان تحيطان بالشيفرة التي ستُكرَّر لطالما كانت حالة خروج الأمر المُحدَّد مساويةً للصفر. في غالبية الحالات، تقوم الشيفرة التي ستُكرَّر بشيءٍ ما سيؤدي في نهاية المطاف إلى تغيير حالة خروج الأمر المُحدَّد، وإلا فستكون لديك حلقة تكرار لا نهائية؛ أي حلقةُ تكرارٍ لا يتوقف تنفيذها أبدًا. تطبع الشيفرة التي ستُكرَّر في المثال السابق قيمة المتغير number (الأمر echo في السطر الخامس)، ثم تُزيد قيمة number بمقدار 1 في السطر السادس. وفي كل مرة يكتمل فيها تنفيذ الشيفرة، فسيتم التحقق من قيمة حالة الخروج للأمر test، وبعد التكرار العاشر للحلقة، فسيزداد المتغير number عشر مرات وسينتهي الأمر test بحالة خروج لا تساوي الصفر. وفي هذه المرحلة، سيُكمِل البرنامج مساره بتنفيذ التعليمات البرمجية التي تلي الكلمة done، لكن ولمّا كانت done هي آخر كلمة في مثالنا، فسينتهي تنفيذ البرنامج فورًا. يعمل الأمر until بشكلٍ مماثل، عدا أنَّ الشيفرة ستُكرَّر لطالما كانت حالة خروج الأمر المُحدَّد false (أي ليست 0). لاحظ تغيير التعبير الذي مررناه للأمر test لكي يعمل بشكلٍ مماثل للمثال السابق عن حلقة while: #!/bin/bash number=0 until [ "$number" -ge 10 ]; do echo "Number = $number" number=$((number + 1)) done بناء قائمة طريقة شائعة لتوفير واجهة للمستخدم للبرامج النصيّة (أي التي تعمل من سطر الأوامر) هي استخدام القوائم. القائمة هي سلسلة من الخيارات التي يستطيع المستخدم انتقاء واحدة منها. سنستخدم ما تعلمناه سابقًا عن الحلقات وعبارة case لبناء برنامج بسيط فيه قائمة: #!/bin/bash selection= until [ "$selection" = "0" ]; do echo " PROGRAM MENU 1 - Display free disk space 2 - Display free memory 0 - exit program " echo -n "Enter selection: " read selection echo "" case $selection in 1 ) df ;; 2 ) free ;; 0 ) exit ;; * ) echo "Please enter 1, 2, or 0" esac done الغرض من حلقة until هو إعادة عرض القائمة في كل مرة يتم اختيار عنصر من القائمة فيها. ستتكرر الحلقة إلى أن يختار المستخدم 0 (خيار الخروج). لاحظ ماذا سنفعل إذا لم تكن مدخلات المستخدم صحيحة (1 أو 2 أو 0). نستطيع إضافة دالة تطلب من المستخدم الضغط على الزر Enter بعد عرض كل خيار لتحسين طريقة عرض البرنامج عند تشغيله، وذلك بمسح الشاشة قبل إعادة عرض القائمة مرةً أخرى. هذا هو المثال المُحسَّن: #!/bin/bash press_enter() { echo -en "\nPress Enter to continue" read clear } selection= until [ "$selection" = "0" ]; do echo " PROGRAM MENU 1 - display free disk space 2 - display free memory 0 - exit program " echo -n "Enter selection: " read selection echo "" case $selection in 1 ) df ; press_enter ;; 2 ) free ; press_enter ;; 0 ) exit ;; * ) echo "Please enter 1, 2, or 0"; press_enter esac done عندما "يُعلِّق" حاسوبك … لقد مررنا جميعًا بتجربة "تعليق" أحد البرامج، الذي يحدث عندما يتوقف البرنامج عن العمل ولا يستجيب لأي شيء. ربما تظن أنَّ البرنامج قد توقف، إلا أنَّه -في معظم الحالات- ما يزال يعمل لكن واجهته مشكلةٌ في البنية المنطقية فيه وقد دخل في حلقة تكرار لا نهائية. تخيل هذه الحالة: لنقل أنَّك وصلت جهازًا خارجيًا إلى حاسوبك، مثل قرص USB، لكنك نسيت تشغيله. ثم حاولت استخدام الجهاز لكن التطبيق علّق، فعندما يحدث ذلك، تستطيع أن تتخيل المحادثة الآتية بين التطبيق والمنفذ الذي يتصل عبره الجهاز: وسيستمر الأمر هكذا إلى ما لا نهاية … البرامج المكتوبة بطريقة جيدة تتفادى الحالة السابقة بضبط مهلة زمنية (timeout)، وهذا يعني أنَّ حلقة التكرار تحسب عدد المحاولات أو تحسب مقدار الزمن الذي انتظرته لكي يحدث شيءٌ مُحدَّد. وإن تجاوز عدد المحاولات أو الزمن المُنتَظَر حدًّا معيّنًا، فسينتهي تنفيذ الحلقة وسيولِّد البرنامج رسالة خطأ. ترجمة -وبتصرّف- للمقال Flow Control - Part 2 لصاحبه William Shotts.

هل أنت من محاربي PHP القدامى وتريد معرفة ما الذي استجد منذ عدِّة سنوات؟ أم أنت منتقلٌ حديثًا إلى PHP من لغةٍ أخرى وتود معرفة الأمور المثيرة في PHP، ها قد وصلت إلى المكان الصحيح. لننفض الغبار عن معلوماتك، وتهيّأ أن تتعلم ميزاتٍ أضيفت حديثًا إلى PHP. معايير PHP-FIG أعداد مشاريع ومكتبات وأطر عمل PHP الموجودة حاليًا مهولة، إذ هنالك العديد من أطر عمل PHP المتوفرة للاستعمال، لكن من الصعب استعمالها معًا، فماذا لو استطاع أحد أطر العمل الاستفادة من مكتبة ما خارجية، بدلًا من كتابتها يدويًا، أو الاستفادة من مكتبة من إطار Laravel مثلًا؟ لهذا الغرض أُنشِئت PHP-FIG (اختصار للعبارة Framework Interoperability Group) في مؤتمر php|tek في 2009ـ التي وضعت عدِّة معايير يُرمَز لها بالاختصار PSR (أي PHP Standards Recommendations) سنورد ذكرها هنا باختصار. PSR-1: معيار كتابة الشيفرات يوضح هذا المعيار الأمور الأساسية التي يجب أخذها بعين الاعتبار عند كتابة الشيفرات لتحقيق أكبر قدر من المحمولية وإمكانية التشغيل مع بقية المكتبات والبرمجيات. يجب استعمال وسوم ‎<?php ?>‎ الاعتيادية، ووسم echo المختصر ‎<?= ?>‎ فقط. يجب أن يكون ترميز ملفات الشيفرات UTF-8 دون BOM. يجب على الملف أن يُنشِئ بنى برمجية جديدة مثل الأصناف (classes) والدوال …إلخ. دون أن يُحدِث أي "تأثير جانبي"، أو يجب أن ينفِّذ الخطوات المنطقية التي تؤدي إلى "تأثيرات جانبية" ولكن لا يُسمَح أن يقوم بكلا الأمرين. نستطيع تعريف "التأثيرات الجانبية" بالأمور غير المتعلقة بتعريف الأصناف أو الدوال، وهي تشمل: توليد المخرجات، أو تضمين الملفات (عبر include أو require)، أو الاتصال إلى الخدمات الخارجية، أو تعديل ضبط ini، أو تعديل المتغيرات العامة أو الكتابة إلى ملفات، وهلم جرًا. يجب أن تكون مجالات الأسماء (namespaces) وأسماء الأصناف متوافقة مع معيار PSR-4 (سنأتي على ذكره بعد قليل)، وهذا يعني أن كل ملف سيحتوي على صنف وحيد باسمه، وفي مجال أسماء من مرحلة (level) واحدة على الأقل. يجب أن تكون أسماء الأصناف على الشكل StudlyCaps (أي الحرف الأول من كل كلمة كبير). يجب أن تكون الثوابت المُعرَّفة في الأصناف بأحرف كبيرة وتفصل الشرطة السفلية بين الكلمات. يجب أن تكون أسماء الدوال على الشكل camelCase (أي الحرف الأول من كل كلمة كبير، عدا أول كلمة). PSR-2: معيار تنسيق الشيفرات يساعد هذا المعيار في تسهيل التعامل مع الملفات التي كتبها مبرمجون آخرون عبر تحديد قواعد مشتركة لكيفية تنسيق شيفرات PHP. يعتمد هذا المعيار على المعيار PSR-1، أي على المبرمج تطبيق قواعد PSR-1 أولًا. يجب أن تُستعمل أربعة فراغات (مسافات) لمحاذاة الشيفرات، وليست مسافات الجدولة (tabs)، ولا يجوز أن تدمج بين الطريقتين، وذلك لتفادي حدوث مشاكل في ملفات الفروقات (diff) وغيرها. ليس هنالك حدٌ أقصى لعدد المحارف في السطر، لكن يستحسن أن يكون بطول 80 محرف أو أقل، ويمكن إضافة أسطر فارغة لتحسين مقروئية النص. ولا يجوز وضع أكثر من تعبير برمجي في السطر الواحد. يجب أن تكون الكلمات المفتاحية (keywords) في PHP بأحرفٍ صغيرة، وكذلك الأمر للثوابت true و false و null. يجب وجود سطر فارغ وحيد بعد تعريف مجال الأسماء (namespace)، وكذلك الأمر بعد use. يجب أن يكون قوس البداية لصنف أو دالة في سطرٍ منفصل، وكذلك قوس النهاية؛ ولا يجوز وضع فراغ بين اسم الدالة وقوس المعاملات، ويجب وضع فراغ وحيد بعد الفاصلة "," في حال وجود أكثر من معامل. يجب تعيين مُحدِّد وصول مثل public أو private أو protected، وعدم استخدام var. يجب وضع فراغ وحيد بعد الكلمة المحجوزة لبنى التحكم (مثل if و for وغيرهما). PSR-3: معيار السجلات يُعرِّف هذا المعيار واجهةً (interface) للتسجيل (logging). PSR-4: معيار التحميل التلقائي شرحنا التحميل التلقائي في درس توزيع شيفرات PHP على عدة ملفات، يمكنك العودة إليه لمزيدٍ من المعلومات. الحزم البرمجية تخيل معي الوضع التالي: أنت مُطور PHP، لديك مشروع تود تطويره، قد تختار إطار عمل مُعين لهذه المهمة، لكنك ستحتاج إلى بضعة مكتبات إضافية للقيام بذلك، تخيل بأنك تود أن يقوم تطبيقك بنشر تحديثات مُعينة على حساب المُستخدم على تويتر، وجدت المكتبة التي ترغب في استخدامها لكنها مكتبة تعتمد على مكتبة أخرى. مُطور PHP من العصر الحجري سيقوم بالتالي: سيقوم بتحميل نُسخة من إطار العمل، ومن ثم يقوم بإنشاء مُجلد يضع فيه المكتبات الإضافية التي يحتاجها ومن ثم يُحاول فهم آلية عملها ليربطها ببعضها البعض. قد تؤتي هذه الطريقة أكلها، وقد تسمح لك بتطوير مشروعك "من دون أية مشاكل"، لكن ماذا يحدث مثلا لو تم إطلاق تحديث لأي من المكتبات التي تعتمد عليها؟ هل ستقوم بإعادة تحميلها من جديد واستبدال الإصدار القديم بالجديد؟ هل يُمكن أن تفعل ذلك لو كنت تستخدم أكثر من مكتبة يعتمد بعضها على بعض؟ لست متأكدا من ذلك. لكن ما هو البديل؟ هل عرفت فائدة أدوات إدارة الحزم؟ ما رأيك أن تكمل قراءة مقال ما هو Composer ولماذا يجب على كل مطور PHP استخدامه وتتعرف على composer وتتعلم طريقة استخدامه. كلمات المرور توجد قابلية تسجيل مستخدمين جدد في أغلبية المواقع، وهذا يعني أنَّ على المستخدم توفير كلمة مرور لكي يدخل على حسابه، لكن هل تساءلت من قبل عن أكثر الطرق أمانًا في تخزين كلمات مرور المستخدمين؟ سأنصحك بعض النصائح في هذا الصدد. لا يجدر بك معرفة كلمات مرور مستخدميك هذا يعني أنَّك ستخزِّن كلمة المرور على شكل نص بسيط في مكانٍ ما في قاعدة بياناتك، افترض مثلًا أنَّ موقعك قد تعرض للاختراق، واستطاع المُخترَق الوصول إلى قاعدة بيانات موقعك واستطاع رؤية جميع كلمات مرور مستخدميك! أنت تعرض سلامة حسابات مستخدميك الأخرى (وسمعة موقعك) للخطر. لا ترسل كلمات المرور الجديدة عبر البريد الإلكتروني هذا خطأٌ كبيرٌ لأنه يعني أنَّ الموقع يعلم كلمة مرور المستخدم، ولقد أرسلها عبر خدمة البريد (قد لا يكون الاتصال مشفرًا!)؛ وإنما عليك إرسال رابط سيسمح للمستخدم بكتابة كلمة مرور جديدة. لا تشفر (encrypt) كلمات المرور قد تظن أنَّ التشفير فكرةٌ جيدةٌ لكن تذكر أنَّ العملية قابلة للعكس، فأي شخص يملك وصولًا إلى شيفرات موقعك البرمجية سيقدر على تحويل كلمات المرور المُشفَّرة إلى أصلها. لا تستخدم MD5 من الجيد أن تستعمل طريقة تحويل غير قابلة للعكس، فهذه الطرق -مثل MD5- غير قابلة للعكس، مما يُصعِّب مهمة معرفة كلمة المرور الأصلية؛ وإذا أردت التأكد أنَّ كلمة المرور التي أدخلها المستخدم مطابقة لكلمة المرور المخزنة في قاعدة البيانات، فعليك أولًا تحويل كلمة المرور التي أدخلها بإحدى الطرق ثم مقارنتها مع الكلمة المخزنة في قاعدة البيانات. لكن يَسهُل كثيرًا توليد جداول بالقيم الأصلية والقيم المحوَّلة تسمى "جداول rainbow"، وسيتم البحث عن القيم المحولة إلى أن يُعثَر على تطابق (ينطبق المثل على SHA-1). أتت PHP 5.5 بدوال بسيطة لتحويل كلمات المرور بأمان وهي password_hash()‎ و password_verify()‎. تُستعمل الدالة الأولى لتحويل كلمة المرور إلى عبارة غير قابلة للعكس التي تستطيع تخزينها بأمان في قاعدة بياناتك. $hash = password_hash($password, PASSWORD_DEFAULT); هذا كل ما في الأمر: أول وسيط هو كلمة المرور التي تريد تحويلها، والوسيط الثاني هو الخوارزمية التي تريد استخدامها للتحويل. الخوارزمية الافتراضية هي bcrypt، ويجب أن تُخزِّن القيم الناتجة في حقل أكبر من 60 محرف في قاعدة البيانات (ربما تستعمل 255). يمكنك أيضًا تمرير PASSWORD_BCRYPT كوسيط في حال أردت أن يكون الناتج بطول 60 محرف دومًا. أما دالة password_verify()‎ فهي تقارن كلمة المرور التي أدخلها المستخدم (الوسيط الأول) بكلمة المرور المحوَّلة والمخزنة في قاعدة البيانات (الوسيط الثاني). <?php if (password_verify($password, $hash)) { // كلمة المرور صحيحة } else { // كلمة المرور غير مطابقة } الأخطاء في PHP أكثر ما يواجهه المبرمج في حياته هو الأخطاء! نحاول -نحن معشر المبرمجين- أن نتلافى حدوث الأخطاء، لكن ذلك ليس ممكنًا في الحياة العملية. علينا أن نعي أنَّ هنالك تصنيفين: الأول هو الأخطاء (errors) التي رأيتها سابقًا خلال هذه السلسلة، التي تُظهِرها الدوال المُضمَّنة في اللغة؛ والثاني هو الاستثناءات (exceptions) التي تظهر في البرامج التي تعتمد على البرمجة غرضية التوجه. تُصنَّف PHP على أنها لا تعتمد كثيرًا على الاستثناءات، وإنما تعتمد على الأخطاء. فلو حاولت مثلًا أن تطبع قيمة متغير غير معرف، فستظهر تنبيهًا لكن PHP ستكمل تفسير السكربت: $ php -a php > echo $foo; Notice: Undefined variable: foo in php shell code on line 1 أما في اللغات الأخرى التي تعتمد اعتمادًا كاملًا على الاستثناء -مثل بايثون- فستختلف النتيجة: $ python print foo Traceback (most recent call last): File “”, line 1, in NameError: name ‘foo’ is not defined التبليغ عن الأخطاء في PHP هنالك مستويات مختلفة من التبليغ عن الأخطاء في PHP، أشهر ثلاثة مستويات هي الأخطاء (errors) والتنبيهات (notices) والتحذيرات (warning). الأخطاء (errors) هي المشاكل التي تظهر في وقت التشغيل (run-time) التي يكون سببها مشاكل في الشيفرة وستسبب توقف التنفيذ. أما التنبيهات فهي رسائل إرشادية التي قد تسبب مشاكل أثناء تنفيذ السكربت، لكن التنفيذ لن يتوقف. أما التحذيرات فهي شبيهة بالأخطاء لكنها لن توقف عمل السكربت. تستطيع تغيير السلوك الافتراضي للتبليغ عن الأخطاء عبر الدالة error_reporting()‎ التي تستطيع تستطيع ضبط مستوى التبليغ عن الأخطاء أثناء التنفيذ بتمرير ثابت من الثوابت المُعرَّفة مسبقًا لمستويات الأخطاء (E_ERRORللأخطاء، E_NOTICE للتنبيهات، E_WARNING للتحذيرات). فلو كنت تريد مشاهدة الأخطاء والتحذيرات لكنك لا تريد التنبيهات، فيمكنك ضبط ذلك كالآتي: <?php error_reporting(E_ERROR | E_WARNING); تستطيع أن تخبر PHP أن تتجاهل الأخطاء في عبارة برمجية معيّنة باستخدام معامل التحكم بالأخطاء @. يمكنك وضع هذا المعامل قبل تعبير برمجي، وسيتم تجاهل أيّة أخطاء يُسبِّبها هذا التعبير. <?php echo @$foo['bar']; المثال السابق سيطبع قيمة ‎$foo['bar']‎ إن كانت موجودةً، لكنه لن يطبع شيئًا إن لم يكن المتغير ‎$foo أو المفتاح 'bar' موجودًا؛ فدون وجود معامل التحكم بالأخطاء، كان سيظهر أحد التنبيهين: PHP Notice: Undefined variable: foo أو PHP Notice: Undefined index: bar. بالطبع يمكنك استخدام العبارة الآتية لتنجب وضع معامل تجاهل الأخطاء: <?php echo isset($foo['bar']) ? $foo['bar'] : ''; الاستثناءات تمثِّل الاستثناءات جزءًا مهمًا من العديد من لغات البرمجة مثل ruby أو java، فأي شيء يحدث بشكل خاطئ في تلك اللغات -مثل فشل طلبية HTTP أو فشل الاتصال بقاعدة البيانات- فسيُرمَى (throw) استثناء يعني أنَّ هنالك خطأٌ ما. لكن PHP نفسها متساهلة جدًا بهذا الأمر، فلو فشل استدعاء الدالة file_get_contents()‎ فستحصل على FALSE وربما رسالة تحذيرية (أي من المستوى E_WARNING)؛ أما أطر العمل الحديثة، فتستعمل الاستثناءات. تبنى آلية معالجة الأخطاء في PHP على وضع التعبيرات البرمجية في كتلة try التي تريد مراقبتها من أجل الأخطاء، فلو حدث استثناءٌ ما داخل كتلة try (تحدث الاستثناءات عند "رميها" [throw]) فسيُلتَقَط باستخدام catch التي تلي كتلة try التي رمت الاستثناء. أنا متأكدٌ أنَّك تتساءل عن معنى ما سبق. ما رأيك أن نأخذ مثالًا توضيحيًا يساعد على الفهم: <?php try { $num = 10; if ($num < 20) { throw new Exception("Exception here!"); } $foo = "bar"; } catch(Exception $exception) { print "Exception!\n"; } ?> دخل مُفسِّر PHP إلى كتلة try وبدأ تنفيذ الشيفرة، وعند وصوله إلى السطر throw new Exception توقف عن تنفيذ كتلة try وانتقل إلى كتلة catch؛ لاحظ أنَّه عندما "يغادر" مُفسِّر PHP كتلة try فلن يعود إليها مطلقًا، أي أنَّ السطر ‎$foo = "bar"‎ لن يُنفَّذ. قد ترى أنَّ كتلة catch معقدة في بادئ الأمر، لكنني سأريك مثلًا يعتمد على أنَّ مفسر PHP سينتقل إلى كتلة catch المناسبة، لكن علي أولًا شرح التعبير (catch(Exception $exception. نُحدِّد في كتلة catch أنَّ الصنف هو Exception لأنَّ على PHP أن تُحدِّد أي كتلة من كتل catch يجب تنفيذها بالبحث عن الصنف الموافق للصنف الذي رُميَ. أو بالأحرى، تُجري PHP عملية instanceof (هل تذكرها من درس البرمجة كائنية التوجه؟) وهذا يعني أنَّ على الاستثناء الذي رُميَ أن يكون من الصنف المُحدَّد أو من صنف مشتق منه (أعلم تمامًا العلم أنَّ ما سبق يبدو معقدًا، لكنه أبسط بكثير مما تظن). لاحظ أنَّ جميع الاستثناءات مشتقة من الصنف Exception الذي يوفِّر وظائف أساسية، وأغلبية الدوال الموجودة في الصنف Exception هي final أي لا يمكن إعادة كتابتها في الأصناف المشتقة. يمكنك مثلًا استدعاء الدالة ‎$exception->getMessage()‎ لمعرفة رسالة الخطأ ("Exception here!‎" في المثال السابق)، أو يمكنك استدعاء getFile()‎ لمعرفة الملف الذي رمى الاستثناء. هذا المثال يوضِّح الشرح السابق: <?php class ExceptFoo extends Exception { } class ExceptBar extends ExceptFoo { } try { $foo = "bar"; throw new ExceptFoo("Baaaaad PHP!"); $bar = "baz"; } catch (ExceptFoo $exception) { echo "Caught ExceptFoo\n"; echo "Message: {$exception->getMessage()}\n"; } catch (ExceptBar $exception) { echo "Caught ExceptBar\n"; echo "Message: {$exception->getMessage()}\n"; } catch (Exception $exception) { echo "Caught Exception\n"; echo "Message: {$exception->getMessage()}\n"; } ?> ناتج السكربت السابق: Caught ExceptFoo Message: Baaaaad PHP! هذا منطقي لأننا رمينا استثناء من الصنف ExceptionFoo، ولهذا ستنتقل PHP إلى كتلة catch. جرب الآن هذه الشيفرة: <?php class ExceptFoo extends Exception { } class ExceptBar extends ExceptFoo { } try { $foo = "bar"; throw new ExceptBar("Baaaaad PHP!"); $bar = "baz"; } catch (ExceptFoo $exception) { echo "Caught ExceptFoo\n"; echo "Message: {$exception->getMessage()}\n"; } catch (ExceptBar $exception) { echo "Caught ExceptBar\n"; echo "Message: {$exception->getMessage()}\n"; } catch (Exception $exception) { echo "Caught Exception\n"; echo "Message: {$exception->getMessage()}\n"; } ?> لماذا ناتج الشيفرة السابقة مماثلة لما قبلها؟ لأنَّ PHP تنتقل إلى أول كتلة catch مُطابِقة لصنف الاستثناء أو أيّة أصناف أب له؛ ولما كان ExceptionBar مشتقٌ من ExceptionFoo، وكانت كتلة catch التابع للصنف ExceptionFoo تأتي قبل ExceptionBar، فستنفَّذ كتلة ExceptionFoo. يمكنك إعادة كتابة الشيفرة كالآتي لتفادي هذه الإشكالية: <?php class ExceptFoo extends Exception { } class ExceptBar extends ExceptFoo { } try { $foo = "bar"; throw new ExceptBar("Baaaaad PHP!"); $bar = "baz"; } catch (ExceptBar $exception) { echo "Caught ExceptBar\n"; echo "Message: {$exception->getMessage()}\n"; } catch (ExceptFoo $exception) { echo "Caught ExceptFoo\n"; echo "Message: {$exception->getMessage()}\n"; } catch (Exception $exception) { echo "Caught Exception\n"; echo "Message: {$exception->getMessage()}\n"; } ?> بقي أمرٌ بسيطٌ تجدر الإشارة إليه ألا وهو كتلة finally الموجودة في إصدار PHP 5.5 وما بعده، التي تضمن لك تنفيذ الشيفرات البرمجية الموجودة فيها دائمًا حتى لو حدث استثناءٌ ما. <?php try { complicatedCode(); } catch (NastyException $e) { handleError($e); } finally { importantCleanup(); } ?> المولدات Generators هذه ميزةٌ جديدةٌ في PHP منذ الإصدار 5.5، وهي تسمح لك باستعمال حلقة foreach للمرور على مجموعة من البيانات دون الحاجة إلى إنشاء مصفوفة في الذاكرة، الأمر الذي قد يؤدي إلى تجاوز حد استهلاك الذاكرة المسموح، أو إلى وقت معالجة كبير… إذ تستطيع كتابة دالة مولدة (generator function) التي تشبه الدوال العادية، إلا أنها بدلًا من إعادة قيمة ما، فهي "تُنتِج" (yield) قيمًا لكي يتم المرور عليها باستعمال الحلقات. مثالٌ بسيطٌ عنها هو دالة range(0, 1000000)‎ التي تولد مصفوفة فيها قيم عددية من الصفر إلى المليون، وستستهلك 100 ميغابايت من الذاكرة العشوائية. ونستطيع بدلًا من ذلك أن نكتب مولدة اسمها xrange()‎ -على سبيل المثال- وستستهلك أقل من 1 كيلوبايت! <?php function xrange($start, $limit) { for ($i = $start; $i <= $limit; $i++) { // استعملنا yield بدلًا من return yield $i; } } // استعملنا المصفوفة المُعادة من استدعاء الدالة range في foreach كالمعتاد foreach (range(1, 9) as $number) { echo "$number "; } echo "\n"; // وكذلك استعملنا نواتج المولدة xrange foreach (xrange(1, 9) as $number) { echo "$number "; } ?> الفرق بين الطريقتين في استهلاك الذاكرة فقط، ولا تأثير لها على سرعة التنفيذ. المصادر راجع صفحة Basic Coding Standard و Coding Style Guide و Logger Interface و Autoloading Standard، وتابع الجديد عبر موقع PHP-FIG. راجع مقالة ما هو Composer ولماذا يجب على كل مطور PHP استخدامه لصاحبها يوغرطة بن علي. لمزيد من المعلومات حول تحويل كلمات المرور، راجع صفحة password_hash و password_verify في دليل PHP، وهذا السؤال على stack overflow. انظر إلى قسم الاستثناءات في PHP: The Right Way، ومقالة Exception handling، وصفحة Exceptions في دليل PHP. تعلم المزيد عن المولدات عبر دليل PHP بصفحتيه Generators overview و Generator syntax.

أي شخصٍ زار موقع YouTube في الأعوام الماضية يعلم تمام العلم أنَّ بالإمكان تضمين مقاطع الفيديو في صفحات الويب؛ لكن لم تكن هنالك طريقةٌ معياريةٌ لفعل ذلك قبل وجود HTML5. نظريًا كل مقاطع الفيديو التي سبق وأن شاهدتها على "الويب" تمَّ تشغيلها عبر إضافة خارجية (ربما QuickTime أو RealPlayer أو Flash ‏-YouTube يستخدم تقنية Flash-). تتكامل تلك الإضافات مع متصفحك بشكلٍ ممتاز إلى درجة أنَّك لن تلاحظ استخدامها إلى أن تحاول مشاهدة مقطع فيديو على منصة (أو جهاز) لا تدعم تلك الإضافة. تُعرِّف HTML5 طريقةً معياريةً لتضمين مقاطع الفيديو في صفحة الويب وذلك باستخدام العنصر <video>، ما يزال دعم العنصر <video> قيد التطوير، وهذه طريقةٌ مهذبةٌ للتصريح أنَّه لا يعمل بعد، أو على الأقل لا يعمل في كل مكان؛ لكن لا تقنط ولا تقلق، هنالك بدائل وخيارات أخرى كثيرة نستطيع اللجوء إليها. يبيّن الجدول الآتي إصدارات مختلف المتصفحات التي تدعم العنصر <video>: IE Firefox Safari Chrome Opera iPhone Android 9.0+ 3.5+ 3.0+ 3.0+ 10.5+ 1.0+ 2.0+ لكن الدعم لعنصر <video> نفسه ليس كافيًا بل هو جزءٌ صغيرٌ من الحكاية. لكن قبل أن نتحدث عن دعم الفيديو في HTML5، علينا أن نفهم بعض المعلومات حول مقاطع الفيديو نفسها (إن كنت تعرف تلك المعلومات، فيمكنك تخطي الفقرات الآتية والبدء من فقرة "ما الصيغ التي تعمل في الويب"). حاويات الفيديو قد تتخيل ملفات الفيديو على أنها ملفات "AVI" أو "MP4". لكن "AVI" و "MP4" في الواقع ما هي إلا صيغ حاوية للفيديو. فهي تُشبِه ملفات ZIP التي يمكنها احتواء أي نوع من الملفات ضمنها، فصيغ حاويات الفيديو (video container formats) تُعرِّف طريقة تخزين الأشياء ضمنها فقط، ولا تُحدِّد ما هي أنواع البيانات المُخزَّنة (الأمر أكثر تعقيدًا من هذا، لعدم توافق جميع أنواع مسارات (أو دفق) الفيديو (video streams) مع جميع صيغ الحاويات، لكن اغضض الطرف عنها الآن). يحتوي ملف الفيديو عادةً على عدِّة "مسارات" (tracks)، التي هي مسار الفيديو (دون صوت) بالإضافة إلى مسار صوتي أو أكثر (دون فيديو). تكون المسارات مترابطةً عادةً، فيحتوي مسار الصوت على مؤشرات أو علامات ضمنه للمساعدة في مزامنة الصوت مع الفيديو. يمكن لكل مسار أن يملك بيانات وصفية (metadata)، مثل نسبة العرض إلى الارتفاع في مسار الفيديو، أو لغة مسار الصوت. يمكن للحاويات أيضًا امتلاك بيانات وصفية، مثل عنوان (title) الفيديو نفسه، وغلاف (cover) للفيديو، وأرقام الحلقات (للمسلسلات)، وهلمَّ جرًا. هنالك العديد والعديد من صيغ حاويات الفيديو، هذه أشهرها: MPEG 4، التي تأتي عادةً مع اللاحقة ‎.mp4 أو ‎.m4v، حاوية MPEG 4 مبنية على حاوية QuickTime القديمة (من Apple) ‎.mov، ما تزال تستخدم "الأفلام القصيرة" في موقع Apple حاوية QuickTime القديمة، لكن الأفلام التي تأخذها من iTunes مبنية على حاوية MPEG 4. Flash Video، تأتي عادةً مع اللاحقة ‎.flv، صيغة Flash Video (بدهيًا) تُستعمَل من Adobe Flash؛ وكانت هذه هي صيغة الحاويات الوحيدة التي كان يدعمها Flash قبل الإصدار 9.0.60.184 (أي مُشغِّل Flash الإصدار 9 التحديث 3). الإصدارات الحديثة من Flash تدعم حاوية MPEG 4 أيضًا. Ogg، تأتي عادةً مع اللاحقة ‎.ogv؛ صيغة Ogg معيارها مفتوح المصدر، وغير مرتبطة بأيّة براءات اختراع. متصفحات Firefox 3.5 و Chrome 4 و Opera 10.5 تدعم -داخليًا، دون إضافات خاصة- الحاوية Ogg، ومسار فيديو Ogg (المُسمى "Theora")، ومسار صوت Ogg (المُسمى "Vorbis"). صيغة Ogg مدعومة تلقائيًا في جميع توزيعات لينُكس المشهورة، ويمكنك استخدامها على Mac وويندوز بتثبيت "QuickTime components" أو "DirectShow filters" على التوالي وبالترتيب. من الممكن أيضًا تشغيل هذه الصيغة ببرنامج VLC على جميع المنصات. WebM، هي صيغة حاويات جديدة، وهي -تقنيًا- شبيهة بصيغة أخرى تُسمى Matroska. أُعلِنَ عن WebM في أيار/مايو من عام 2010، وهي مصمَّمة لكي تُستخدم حصريًا مع مرماز الفيديو VP8 ومرماز الصوت Vorbis (سنأتي على ذكرهما بعد قليل)، وهذه الصيغة مدعومةٌ داخليًا -دون إضافات خاصة- في آخر إصدار من Chromium و Google Chrome و Mozilla Firefox و Opera، وأعلنت Adobe أنَّ Flash 10.1 سيدعم صيغة WebM. Audio Video Interleave، التي تأتي عادةً مع اللاحقة ‎.avi تم ابتكار صيغة AVI من مايكروسوفت منذ وقتٍ طويل، حين كانت إمكانية تشغيل الحواسيب لمقاطع الفيديو أمرًا عظيمًا. لا تدعم هذه الصيغة –رسميًا– ميزات صيغ الحاويات الأحدث منها مثل البيانات الوصفية المدمجة، ولا تدعم أيضًا -رسميًا- أغلبية ترميزات الفيديو والصوت المُستعمَلة حاليًا. وقد حاولت الشركات مع مرور الوقت توسعة هذه الصيغة بطرق غير متوافقة مع بعضها بعضًا لدعم بعض الميزات، ولكنها مع ذلك بقيت صيغة الحاوية الافتراضية لبعض المُرمِّزات (encoders) مثل MEncoder. مرمزات الفيديو عندما تتحدث عن "مشاهدة مقطع فيديو" فغالبًا ستقصد مشاهدة تجميعة من مسار للفيديو ومسار للصوت؛ لكن ليس عندك ملفان منفصلان، فكل ما لديك هو ملف "فيديو" واحد، وربما يكون ملف AVI أو MP4؛ تلك هي صيغ الحاويات، مثل ملف ZIP الذي يحتوي على عدِّة أنواع من الملفات داخله. تُعرِّف صيغة الحاوية آلية تخزين مسارات الفيديو والصوت في ملفٍ وحيد. سيقوم مُشغِّل الفيديو بثلاثة أشياء على الأقل عندما "تشاهد مقطع فيديو": محاولة تفسير صيغة الحاوية لمعرفة ما هي مسارات الفيديو والصوت المتوفرة، وطريقة تخزينها ضمن الملف كي يعرف أين سيعثر على البيانات التي يجب عليه فك ترميزها لاحقًا فك ترميز مسار الفيديو وعرض سلسلة من الصور على الشاشة فك ترميز مسار الصوت وإرسال الأصوات إلى مكبرات الصوت في جهازك مرماز الفيديو (video codec) هو الخوارزمية التي يُرمَّز (encode) فيها مقطع الفيديو، أي أنَّه يُحدِّد طريقة القيام بالخطوة رقم 2 مما سبق (الكلمة "codec" آتية من دمج الكلمتين "coder" و "decoder"). يفك مُشغِّل الفيديو ترميز (decode) مسار الفيديو وفقًا لمرماز الفيديو المستخدم، ثم سيعرض سلسلة من الصور أو "الإطارات" على الشاشة، أغلبية مرمزات الفيديو الحديثة تستخدم حيلًا عديدة لتقليل حجم المعلومات اللازمة لعرض الإطار تلو الإطار. على سبيل المثال، بدلًا من تخزين كل إطار على حدة (كأنه لقطة شاشة)، فسيتم تخزين الاختلافات بين الإطارين. لا يحدث في أغلبية مقاطع الفيديو تغيرات كبيرة بين الإطارات المتتالية، مما يسمح بضغطها بدرجة أكبر، مما يؤدي إلى تقليل المساحة التخزينية للملف. هنالك مرمازات فيديو تؤدي إلى ضياع في البيانات (lossy) وأخرى لا تؤدي إلى ضياع البيانات (lossless). المساحة التخزينية لملفات الفيديو التي ليس فيها ضياعٌ في البيانات كبيرةٌ جدًا ولن تكون ذات فائدةٍ في الويب، لهذا سنركِّز على المرمازات التي تؤدي إلى ضياعٍ في البيانات. مرماز يؤدي إلى ضياعٍ في البيانات يعني أنَّ بعض المعلومات ستضيع دون إمكانية استعادتها أثناء عملية الترميز (encoding)، مثل عملية نسخ كاسيت صوتي إلى آخر. ستفقد في هذه العملية بعض المعلومات المتعلقة بالفيديو المصدري، وستُقلِّل الجودة في كل مرة تُعيد ترميز المقطع فيها. فبدلًا من صوت "التشويش" في شريط الكاسيت (إن كنت تستعمله في صغرك)، سيبدو مقطع الفيديو الذي تُعيد ترميزه مراتٍ عدِّة غير واضحٍ، خصوصًا المشاهد التي فيها الكثير من الحركة (في الواقع، يمكن أن يحدث ذلك حتى لو قمتَ بالترميز من المصدر مباشرةً، فربما اخترت مرماز فيديو سيئ أو مررت مجموعة وسائط خاطئة). أما على الكفة الأخرى، تضغط مرمزات الفيديو التي تؤدي إلى ضياعٍ في البيانات مقاطع الفيديو ضغطًا كبيرًا ويصعب في الوقت نفسه ملاحظة فقدان البيانات بالعين المجردة. هنالك الكثير من مرمازات الفيديو، لكن أهم ثلاثة منها هي H.264، و Theora، و VP8. H.264 H.264 معروفٌ أيضًا باسم "MPEG-4 part 10" أو "MPEG-4 AVC" أو "MPEG-4 Advanced Video Coding". طوِّرَ مرماز H.264 من MPEG group وتم جعله معيارًا قياسيًا في 2003، ويهدف إلى توفير مرماز واحد للأجهزة ذات التراسل الشبكي المحدود وقدرة المعالجة المحدودة (أي الهواتف المحمولة)، وللأجهزة التي يتوفر لها تراسلٌ شبكيٌ كبير وقدرة معالجة ممتازة (مثل الحواسيب الحديثة)، وأي شيء يقع بينهما. ولكي يتم تحقيق ذلك، قُسِّم معيار H.264 إلى "أنماط" (profiles) التي يُحدِّد كلٌ منها مجموعة من الميزات الاختيارية التي توازن بين تعقيد ترميز الملف ومساحته التخزينية. الأنماط العليا (Higher profiles) تستخدم ميزات اختيارية أكثر، وتوفر جودةً أكبر بمساحة تخزينية أقل، لكنها تأخذ وقتًا أطول لتُرمَّز، وتستهلك طاقة معالجة أكبر لفك الترميز في الوقت الحقيقي. لإعطائك فكرةً عامةً عن تنوع الأنماط: يدعم iPhone ‏نمط "Baseline"، ويدعم AppleTV نمطي ‏"Baseline" و "Main"، بينما يدعم Adobe Flash على الحواسيب أنماط "Baseline" و "Main" و "High". ويستعمل YouTube الآن مرماز H.264 لترميز مقاطع الفيديو عالية الدقة (HD) التي يمكن تشغليها عبر Adobe Flash؛ ويدعم YouTube أيضًا إرسال مقاطع الفيديو المرمزة بمرماز H.264 إلى الهواتف المحمولة، بما في ذلك هواتف iPhone والهواتف العاملة بنظام أندرويد. إضافةً إلى ما سبق، مرماز H.264 هو المرماز الذي تستعمله مواصفة Blu-Ray، إذ تستخدم أقراص Bul-Ray ‏نمط "High" في العموم. أغلبية الأجهزة التي تُشغِّل فيديو H.264 عدا الحواسيب (بما في ذلك هواتف iPhone وقارئات Blu-Ray) تستعمل شريحة منفصلة لفك ترميز الفيديو، لأن معالجاتها المركزية ضعيفة نسبيًا لفك ترميز الفيديو في الوقت الحقيقة. وأصبحت في هذه الأيام بطاقات العرض الرخيصة للحواسيب المكتبية تدعم فك ترميز فيديو H.264 عتاديًّا. وهنالك أيضًا تنافس بين مرمزات H.264، بما في ذلك المكتبة مفتوحة المصدر x264. معيار H.264 محمي ببراءات اختراع؛ ويتم الترخيص عبر MPEG LA group. يمكن تضمين فيديو H.264 في أغلبية الحاويات الحديثة، بما في ذلك MP4 (تستعملها Apple بشكلٍ أساسي في متجر iTunes) و MKV (التي تُستعمَل بشكلٍ أساسي من هواة الفيديو الذين ليس لهم هدف تجاري). Theora تم تطوير Theora من مرماز VP3 ثم طوِّرَ من مؤسسة Xiph.org.‏ Theora مرماز مجاني الاستخدام (royalty-free) وليس محميًا بأيّة براءات اختراع عدا براءات اختراع مرماز VP3 الأصلي، الذي رُخِّص على أنَّه مجانيُ الاستخدام أيضًا. على الرغم من أنَّ المعيار قد "جُمِّدَ" (frozen) منذ عام 2004، إلا أنَّ Theora project (الذي يتضمن مكتبات ترميز وفك ترميز مفتوحة المصدر) قد أصدر النسخة 1.0 في تشرين الثاني/نوفمبر عام 2008، والإصدار 1.1 في أيلول/سبتمبر عام 2009. يمكن تضمين الفيديو المرمَّز بمرماز Theora في أيّة صيغة من صيغ الحاويات، لكن من الشائع أن نراه في حاوية Ogg. تدعم جميع توزيعات لينكس Theora، ويتضمن متصفح Mozilla Firefox 3.5 دعمًا داخليًا للفيديو المرمز بمرماز Theora؛ وأقصد بكلمة "داخليًا" أنَّه متوفرٌ على جميع الأنظمة دون إضافات خاصة. يمكنك أيضًا تشغيل الفيديو المرمز بمرماز Theora على ويندوز أو على Mac OS X بعد تثبيت برمجية فك الترميز المفتوحة المصدر من Xiph.org. VP8 VP8 هو مرماز فيديو آخر من On2، نفس الشركة التي طوَّرت VP3 (الذي أصبح لاحقًا Theora). بكلامٍ تقني، يُنتِج هذا المرماز فيديو بنفس جودة النمط "High" في H.264، في حين يحاول تقليل تعقيد عملية فك الترميز كما في نمط "Baseline" في H.264. في عام 2010، اشترت Google شركة On2 ونشرت مواصفات مرماز الفيديو وأصدرت برمجية ترميز وفك ترميز مفتوحة المصدر. وكان جزءًا من هذه العملية هو "فتح" Google لجميع براءات الاختراع التي سجلتها شركة On2 لمرماز VP8، وذلك بجعلها مجانية الاستخدام أي royalty-free (وهذا أفضل ما يمكن فعله مع براءات الاختراع، فلا يمكنك حقًا "التخلي" عنها أو حذفها بعد تسجيلها. لكن لجعلها متوافقة مع البرمجيات مفتوحة المصدر فيمكن ترخيص للاستخدام مجانًا، وبهذا يستطيع أي شخصٍ استخدام التقنيات المُغطاة من براءة الاختراع دون دفع أي شيء أو دون محاولة الحصول على ترخيص خاص). وبهذا أصبح VP8 مرماز عصري مجاني الاستخدام ليس محميًا بأيّة براءات اختراع عدا تلك التي سجلتها شركة On2 (وتملكها Google حاليًا) والتي يمكن استعمالها مجانًا. مرمزات الصوت ستحتاج إلى تضمين مسار صوتي في مقاطع الفيديو إلا إذا كنتَ ستنشر الأفلام قبل عام 1927 فقط. ومثل مرمزات الفيديو، مرمازات الصوت هي خوارزميات التي يُرمَّز (encode) بها مسار الصوت. وأيضًا مثل مرمازات الفيديو، هنالك مرمازات صوت ليس فيها ضياعٌ في البيانات (lossless) وأخرى تضيع فيها بعض البيانات (lossy). وكما هو حال الفيديو الذي لا يوجد فيه ضياعٌ في البيانات، ستكون المساحة التخزينية لمسارات الصوت التي ليس فيها ضياعٌ في البيانات كبيرةً جدًا لكي نستفيد منها على الويب؛ لذلك سنركِّز على مرمازات الصوت التي تسبب فقدانًا لبعض البيانات. وسأضيق المجال قليلًا، لوجود تصنيفاتٍ مختلفة لمرمازات الصوت؛ إذ أنَّ الصوت يستعمل في أماكن لا يُستعمَل فيها الفيديو (في الهواتف مثلًا)، وهنالك تصنيفٌ كاملٌ من مرمازات الصوت المُتخصصة بترميز الكلام، فلا تفكر في ترميز الموسيقى بهذه المرمازات، لأن النتيجة النهائية ستبدو وكأن طفلًا ذا أربعة أعوام يغني على الهاتف. لكنك تستطيع استخدامها في خدمة PBX من Asterisk لأن تراسل البيانات ثمين هناك، ولأن هذه المرمازات تضغط الصوت البشري ليأخذ مساحةً تخزينيةً لا تشكِّل إلا جزءًا بسيطًا من المساحة التخزينية التي كانت ستأخذها المرمازات ذات الغرض العام. لكن نتيجةً لعدم دعم تلك المرمازات في المتصفحات داخليًا أو عبر الإضافات الخارجية، فلم يسطع نجم تلك المرمازات في الويب، ولهذا سنركِّز على مرمزات الصوت العامة التي تسبب ضياعًا في بعض البيانات. وكما ذكرنا سابقًا، سيقوم حاسوبك بثلاثة أشياء على الأقل في وقتٍ واحد عندما "تشاهد مقطع فيديو": محاولة تفسير صيغة الحاوية فك ترميز مسار الفيديو فك ترميز مسار الصوت وإرسال الأصوات إلى مكبرات الصوت في جهازك يُحدِّد مرماز الصوت طريقة القيام بالخطوة رقم 3 مما سبق: فك ترميز مسار الصوت وتحويله إلى موجات رقمية يمكن لمكبرات الصوت عندك تحويلها إلى صوت. وكما في مرمازات الفيديو، هنالك حيلٌ عدِّة تُستعمَل لتقليل حجم البيانات المُخزَّنة في مسار الصوت. ولمّا كنّا نتحدث عن مرمازات الصوت التي تُسبِّب ضياعًا في بعض البيانات، فسنفقد بعض المعلومات أثناء عملية "التسجيل ← الترميز ← فك الترميز ← الاستماع". تحذف مختلف مرمزات الصوت أشياءً مختلفة، لكنها كلها تخدم نفس الغرض: ألّا تشعر بضياعِ أيِّ شيءٍ عندما تستمع إلى المسار. هنالك مفهومٌ في مسارات الصوت ليس موجودًا في مسارات الفيديو ألا وهو "القنوات" (channels). نحن نرسل الصوت إلى مكبرات الصوت، صحيح؟ حسنًا، ما عدد مكبرات الصوت عندك؟ إذا كنت تجلس أمام حاسوبٍ محمول فربما يكون عندك مكبران: أحدهما على اليمين والآخر على اليسار. لكن حاسوبي المكتبي يملك ثلاثة مكبرات: واحد على اليمين وآخر على اليسار وثالث على الأرض. أنظمة "الصوت المحيطي" (surround sound) السمعية تملك ستة مكبرات أو أكثر متوزعة توزيعًا مدروسًا في أنحاء الغرفة. مهمة كل مكبر أن يُخرِج قناة (channel) معيّنة من التسجيل الأصلي. الفكرة النظرية وراء ذاك النظام هي أنَّك ستجلس في منتصف المسافة الفاصلة بين تلك المكبرات محاطًا بست قنوات منفصلة من الصوت، وسيدرك مخك الصوت وستشعر كما لو أنك في منتصف الأحداث التي تسمع صوتها. لكن هل تعمل فعلًا كما شرحنا أعلاه؟ تقول الشركات ذوات رؤوس الأموال الكبيرة أنها تعمل. تستطيع أغلبية مرمازات الصوت ذات الغرض العام التعامل مع قناتين من الصوت. يُقسَم الصوت أثناء التسجيل إلى قناتين يمنى ويسرى؛ وستُخزَّن كلا القناتين في نفس المسار الصوتي أثناء الترميز؛ وستُرسَل محتويات كل قناة إلى مكبر الصوت الموافق لها أثناء فك الترميز. يمكن لبعض مرمزات الصوت التعامل مع أكثر من قناتين، إذ يعرفون أي قناة يجب أن تُرسَل لأي مكبر ثم سيتولى مُشغِّل الصوتيات عندك الأمر. هنالك الكثير من مرمازات الصوت، هل ذكرتُ لك سابقًا أنَّ هنالك الكثير من مرمازات الفيديو؟ انسَ ذلك! هنالك الكثير والكثير من مرمازات الصوت، لكن يهمنا في الويب ثلاثةٌ منها: MP3 و ACC و Vorbis. MPEG-1 Audio Layer 3 MPEG-1 Audio Layer 3 معروفة بالعامية على أنها "MP3"؛ لا أعرف من أي كوكبٍ أتيت إن لم تسمع من قبل عن MP3. تبيع شركة Walmart مشغِّلات موسيقى محمولة وتسميها "MP3 players". وهي منتشرة انتشارًا كبيرًا. يمكن أن تحتوي ملفات MP3 على قناتين صوتيتين على الأكثر، ويمكن ترميزها بمختلف معدلات البث (أي bitrates): 64 كيلوبت/ثانية، أو 128 كيلوبت/ثانية، أو192 كيلوبت/ثانية، أو غيرها التي تتراوح قيمها من 32 إلى 320. قيم معدلات البث (bitrates) الأعلى تعني أنَّ مساحة الملفات أكبر وجودة الصوت أدق، لكن العلاقة بين جودة الصوت ومعدل البث ليست خطيّة (linear، أي أنَّ جودة الأصوات المرمزة بمعدل بث 64 كيلوبت/ثانية أفضل بالضعفين من 64 كيلوبت/ثانية، لكن 256 كيلوبت/ثانية ليس أكثر جودة بمقدار الضعفين من 128 كيلوبت/ثانية). تسمح صيغة MP3 بالترميز ذي معدل البث المتغير (variable bitrate encoding، الذي يعني أنَّ أجزاءً من المسار مضغوطةٌ أكثر من غيرها). على سبيل المثال، يمكن ترميز السكت بين النوتات الموسيقية بمعدل بث منخفض، ثم سيرتفع معدل البث عندما يُعزَف لحنٌ معقَّدٌ على عدِّة آلات موسيقية. يمكن أيضًا ترميز MP3 بمعدل بث ثابت، ولا غرابة أن يُسمى ذلك بالترميز ذي معدل البث الثابت (constant bitrate encoding). لا يُعرِّف معيار MP3 كيفية الترميز باستخدام MP3 تمامًا (على الرغم من أنَّه يُعرِّف تمامًا كيفية فك الترميز)؛ تستخدم مختلف المُرمِّزات آلياتٍ مختلفة تُنتِج نتائج متنوعة كثيرًا، لكن يمكن قراءتها جميعًا من نفس المشغِّلات. مشروع LAME المفتوح المصدر هو أفضل مرمِّز حر، ويمكن القول أنَّه أفضل المرمِّزات لجميع معدلات البث إلا المنخفضة منها. صيغة MP3 (التي وُضِعَ معيارها عام 1991) هي صيغة محمية ببراءة اختراع، وهذا هو السبب وراء عدم إمكانية تشغيل نظام لينكس لملفات MP3 مباشرةً. وبشكل عام، تدعم جميع مشغلات الموسيقى المحمولة ملفات MP3، ويمكن تضمين مسارات MP3 ضمن أيّ حاوية فيديو. ويمكن أن يُشغِّل Adobe Flash ملفات MP3 لوحدها أو مسارات MP3 الموجودة ضمن حاوية MP4. Advanced Audio Coding Advanced Audio Coding المعروفة أيضًا باسم "AAC" التي وضِعَ معيارها عام 1997، والتي أنتشر صيتها عندما اختارتها Apple صيغةً افتراضيةً لمتجر iTunes. كانت جميع ملفات AAC التي تم "شراؤها" من متجر iTunes مشفرةً بحقوق رقمية مملوكة لشركة Apple ‏(أي DRM) التي كانت تدعى FairPlay؛ أصبحت بعض الأغنيات متاحةً في متجر iTunes كملفات AAC غير محمية، التي تدعوها Apple ‏"iTunes Plus" لأن ذلك أفضل من تسمية جميع الأشياء الأخرى باسم "iTunes Minus". صيغة AAC محمية ببراءات اختراع؛ وأسعار الترخيص متوفرة على الإنترنت. صُمِّمَت AAC لتوفير صوت بجودة أعلى من MP3 بنفس معدل البث (bitrate)، ويمكن ترميز الصوت بأي معدل بث (صيغة MP3 محدودة بعدد ثابت من معدلات البث، حدّها الأقصى هو 320 كيلوبت/ثانية). يمكن لصيغة AAC ترميز 48 قناة صوتية كحد أقصى، على الرغم من عدم وجود حالة لتطبيق ذلك عمليًا. تختلف صيغة AAC عن MP3 في أنها تُعرِّف أنماطًا (profiles) بطريقة مشابهة لمرمز H.264 ولنفس الأسباب. فهنالك "نمط" بسيط مُصمَّم لكي يُشغَّل في الوقت الحقيقي على الأجهزة ذات قدرة المعالجة المحدودة، بينما توجد "أنماط" توفر صوتًا أكثر جودةً بنفس معدل البث لكن ذلك على حساب البطء في الترميز وفك الترميز. جميع منتجات Apple الحالية بما فيها iPod و AppleTV و QuickTime تدعم بعض "profiles" صيغة AAC في ملفات الصوت المنفصلة وفي مسارات الصوت المدمجة في حاوية MP4. يدعم Adobe Flash جميع "أنماط" صيغة AAC في MP4، وكذلك المشغلات الحرة مثل MPlayer و VLC. أما للترميز، فمكتبة FAAC هي مكتبةٌ مفتوحة المصدر؛ وهنالك خيارٌ في وقت البناء (compile-time) في برمجية mencoder و ffmpeg لدعم ترميز AAC. Vorbis Vorbis تُسمى عادةً "Ogg Vorbis" (على الرغم من أنَّ هذا خاطئ تقنيًا، لأن "Ogg" هي صيغة حاويات ويمكن لمسارات صوت Vorbis أن تُضمَّن في حاويات أخرى). صيغة Vorbis ليست محمية بأيّة براءات اخترع ولهذا ستجدها مدعومةً في توزيعات لينكس مباشرةً وفي جميع الأجهزة المحمولة التي تُشغِّل نظام Rockbox. يدعم Mozilla Firefox 3.5 مسارات صوت Vorbis في حاوية Ogg، أو فيديو Ogg مع مسار صوتي بصيغة Vorbis، ويمكن أيضًا للهواتف العاملة بنظام أندرويد أن تُشغِّل ملفات Vorbis الصوتية المستقلة. عادة ما تُضمَّن مسارات Vorbis الصوتية في حاوية Ogg أو WebM، لكن يمكن أيضًا تضمينها في حاوية MP4 أو MKV (أو بعد تطبيق بعض الحيل: في حاوية AVI). تدعم صيغة Vorbis الصوتية أي عدد من القنوات الصوتية. هنالك عددٌ من برمجيات ترميز وفك ترميز صوت Vorbis المفتوحة المصدر، بما في ذلك OggConvert (للترميز)، و ffmpeg (فك ترميز)، و aoTuV (للترميز)، و libvorbis (لفك الترميز). وهنالك إضافات لبرمجية QuickTime لنظام Mac OS X و DirectShow لنظام ويندوز. ما الصيغ التي تعمل في الويب إن لم يؤلمك رأسك إلى الآن فأنت تبلي بلاءً حسنًا. يمكنك أن تستنتج بسهولة أنَّ الفيديو (والصوت) هو موضوعٌ معقدٌ، وما أوردناه سابقًا هو النسخة المختصرة من القصة! أنا متأكد أنك تتساءل عن ارتباط HTML5 بما سبق. حسنًا، يوجد في HTML5 عنصرٌ اسمه <video> لتضمين مقاطع الفيديو في صفحة ويب، ولا توجد هنالك أيّة قيود على المرماز المستخدم لترميز الفيديو أو الصوت أو حتى صيغة الحاوية التي يمكنك استخدامها لمقاطع الفيديو. يمكن لعنصر <video> وحيد أن يُشير إلى عدِّة ملفات فيديو، وسيختار المتصفح أول ملف فيديو يستطيع تشغيله. كل ما عليك فعله هو معرفة ما هي الحاويات والمرمازات التي تدعمها المتصفحات. هذا هو حال دعم صيغ الفيديو في HTML5 في الوقت الراهن: متصفح Mozilla Firefox ‏(3.5 أو ما بعده) يدعم فيديو Theora وصوت Vorbis في حاوية Ogg. ويدعم Firefox 4 صيغة WebM. متصفح Opera ‏(10.5 وما بعده) يدعم فيديو Theora وصوت Vorbis في حاوية Ogg. يدعم Opera 10.60 صيغة WebM. متصفح Google Chrome ‏(3.0 وما بعده) يدعم فيديو Theora وصوت Vorbis في حاوية Ogg. يدعم Google Chrome 6.0 صيغة WebM. متصفح Safari على نظامي Mac وويندوز (3.0 وما بعده) سيدعم أي شيء يدعمه QuickTime. نظريًا، هذا يعني أنَّك قد تطلب من مستخدميك تثبيت إضافات خارجية إلى مُشغِّل QuickTime؛ لكن عمليًا لن يفعل ذلك إلا القليل. لذلك عليك أن تستعمل الصيغ التي يدعمها QuickTime مباشرةً. وهذه قائمة طويلة إلا أنها لا تحتوي WebM، أو Theora، أو Vorbis، أو حاوية Ogg. لكن QuickTime فيه دعمٌ مدمج لفيديو H.264‏ (نمط main) وصوت AAC في حاوية MP4. الهواتف المحمولة متل iPhone والهواتف التي تعمل بنظام أندرويد تدعم فيديو H.264 ‏(نمط baseline) وصوت AAC ‏(‎نمط ‎"low complexity"‎) في حاوية MP4. يدعم Adobe Flash (الإصدار 9.0.60.184 وما بعده) فيديو H.264 وصوت AAC في حاوية MP4. يدعم Internet Explorer جميع "أنماط" فيديو H.264 وصوت AAC أو MP3 في حاوية MP4. ويمكنه أيضًا تشغيل فيديو WebM إن ثبتتَ مرمازًا خارجي، الذي لا يكون مثبتًا افتراضيًا في أي إصدار من ويندوز. لا يدعم IE9 المرمازات الخارجية الأخرى (على عكس Safari، الذي سيُشغِّل ما يستطيع QuickTime تشغيله). لا يدعم متصفح Internet Explorer 8 عنصر video في HTML5 إطلاقًا، لكن تقريبًا جميع مستخدمي Internet Explorer يملكون إضافة Adobe Flash. وسأريك لاحقًا في هذا الفصل كيف يمكنك استخدام عنصر video في HTML5 لكن مع خيارٍ احتياطي هو استخدام Flash. ربما من الأسهل تلخيص ما سبق في جدول. الترميز/الحاوية IE Firefox Safari Chrome Opera iPhone Android Theora+Vorbis+Ogg . 3.5+ * 3.0+ 10.5+ . 2.3+ H.264+AAC+MP4 9.0+ 21+ 3.2+ 3.0+**** 25+ 3.2+ 2.0+ WebM 9.0+** 4.0+ * 6.0+ 10.6+ . 2.3*** * متصفح Safari سيُشغِّل أي شيء يستطيع QuickTime تشغيله، لكن QuickTime لا يأتي مع دعمٍ مسبق إلا لصيغ H.264/AAC/MP4. ** متصفح Internet Explorer 9 سيدعم WebM "فقط إذا ثبَّت المستخدم مرماز VP8"، الذي يعني ضمنيًا أنَّ مايكروسوفت لن تضيف المرماز بنفسها. *** على الرغم من أنَّ متصفح أندرويد 2.3 يدعم WebM، لكن لا توجد إمكانية لفك الترميز عتاديًا، وهذا يقلل من عمر البطارية. **** قد أعلِنَ أنَّ Google Chrome سيسقط الدعم عن H.264 قريبًا، وقد تم تبرير ذاك القرار؛ لكنه لم يُطبَّق إلى الآن. ولكن هذه هي الطامة الكبرى: لا توجد تجميعة واحدة من الحاويات والمرمازات التي تعمل في جميع متصفحات HTML5، ومن غير المحتمل أن يتغير هذا في المستقبل القريب. لكي تجعل مقاطع الفيديو قابلة للعرض في مختلف الأجهزة والمنصات، فعيلك أن تُرمِّز مقطع الفيديو بأكثر من صيغة. هذا هو مسار عملك إذا كنت تريد توفير مقطع الفيديو بأكبر قدر من التوافقية بين المتصفحات: أنشِئ نسخةً تستعمل WebM ‏(VP8 + Vorbis). أنشِئ نسخةً أخرى تستعمل فيديو H.264 بنمط baseline مع صوت AAC‏ بنمط low complexity‎ في حاوية MP4. أنشِئ نسخةً أخرى تستعمل فيديو Theora وصوت Vorbis في حاوية Ogg. اربط ملفات الفيديو الثلاثة السابقة إلى عنصر <video> وحيد، واترك مجالًا لاستعمال مشغِّل يعتمد على تقنية Flash إن لم يدعم المتصفح العنصر video. مشاكل الترخيص مع فيديو H.264 قبل أن نكمل، علي أن أُشير أنَّ هنالك تكلفة لترميز مقاطع الفيديو مرتين. حسنًا، لا أقصد أنَّ عليك فعلًا ترميزها مرتين، وهذا يعني استهلاك أكبر للوقت ولطاقة المعالجة فيما لو كنت سترمِّزها مرةً واحدة. لكن هنالك تكلفة حقيقة مرتبطة بفيديو H.264: تكلفة الترخيص. هل تتذكر عندما شرحتُ H.264 أول مرة، وذكرت بسرعة أنَّ ذاك الترميز خاضع لبراءات اختراع ويمكن أخذ ترخيص بالاستخدام من MPEG LA؟ قد تبيّن أنَّ ما سبق مهم، ولكن لتفهم لماذا، سأحيلك إلى مقتطف من مقالة "The H.264 Licensing Labyrinth": تُقسِّم MPEG LA رخصة H.264 إلى رخصتين فرعيتين: واحدة لمصنعي برمجيات الترميز وفك الترميز، وأخرى لموزعي المحتوى. الرخصة الفرعية المتعلقة بتوزيع المحتوى تُقسَّم بدورها إلى أربعة تصنيفات أساسية، اثنان منها (الاشتراك subscription و "title-by-title" أي لكل مقطع على حدة) مرتبطان فيما إذا كان المستخدم النهائي سيدفع مباشرةً لقاء خدمة بث الفيديو، واثنان منها (البث "المجاني" للتلفاز وللإنترنت) مرتبطان بالربح القادم من مصادر أخرى بخلاف المشاهد. تكلفة الرخصة للبث "المجاني" للتلفاز مبنيةٌ على خيارَي دفع. أول خيار هو دفع مبلغ 2500$ لكل مُرمِّز AVC، الذي يعني تسليم مُرمِّز AVC واحد فقط "مُستخدَم من قبل أو نيابةً عن المُرخَّص له لبث فيديو AVC للمستخدم النهائي"، الذي سيفك الترميز ويشاهد الفيديو. إذا كنت تتساءل فيما إذا كانت التكلفة مضاعفة هنا، فالجواب هو نعم: دُفِعَت أجرة الرخصة من مُصنِّع المرمِّز، وسيدفع الطرف الذي سيبث الفيديو أحد خيارَي الدفع. الخيار الثاني للترخيص هو دفع اشتراك سنوي للبث. وأجرة البث السنوي مُقسَّمة إلى شرائح تختلف حسب عدد المشاهدين: ‎2500‏‎$‎ في كل سنة لكل سوق من أسواق البث (broadcast markets) لعدد الأسر التي تشاهد البث بين 100,000–499,999 5000‏$‏ في كل سنة لكل سوق من أسواق البث (broadcast markets) لعدد الأسر التي تشاهد البث بين 500,000–999,999 10,000‏$‏ في كل سنة لكل سوق من أسواق البث (broadcast markets) لعدد الأسر التي تشاهد البث الأكبر من 1,000,000 بعد استعراض جميع المشاكل التي تحف البث "المجاني" للتلفاز، لماذا يجب أن يهتم بها شخصٌ لا يبث الفيديو؟ كما ذكرتُ سابقًا، تكلفة الاشتراك تنطبق على أيّ عملية توصيل للمحتوى، لكن تعريف البث "المجاني" للتلفاز يعني أكثر من البث عبر الهوائيات (over-the-air). أضافت MPEG LA أجور اشتراك لبث الفيديو عبر الإنترنت التي لن يدفع المستخدم النهائي أيّة تكاليف لمشاهدة المقطع، أي بكلامٍ آخر: أي بث عام لفيديو سواءً كان عبر الهوائيات أو خدمة "الكيبل" أو الأقمار الاصطناعية أو عبر الإنترنت… سيخضع إلى أجور الاشتراك. لكن MPEG-LA أعلنوا أنَّهم لن يأخذوا أجورًا على البث عبر الإنترنت، لكن هذا لا يعني أنَّ مرماز H.264 مجاني الاستخدام لجميع المستخدمين؛ وبشكل خاص برمجيات الترميز (كالتي تُعالِج الفيديو المرفوع على موقع YouTube) وبرمجيات فك الترميز (مثل البرمجية الموجودة في متصفح Microsoft Internet Explorer 9) التي ما زالت تخضع لأجور الترخيص. ترجمة -وبتصرّف- لفصل "Video" من كتاب Dive Into HTML5 لمؤلفه Mark Pilgrim. اقرأ أيضًا المقال التالي: ترميز مقاطع الفيديو بعدة صيغ المقال السابق: الرسم عبر عنصر canvas في HTML5 النسخة العربية الكاملة من كتاب نحو فهم أعمق لتقنيات HTML5

لم تكن السكربتات التي نكتبها إلى الآن تفاعليةً، أي أنها لا تتطلب أيّ مدخلاتٍ من المستخدم. سنرى في هذا الدرس كيف نجعل السكربتات تسأل المستخدم أسئلةً وتحصل على الإجابة وتستخدمها. read استعمل الأمر read للحصول على مدخلات من لوحة المفاتيح. يأخذ الأمر read المدخلات من لوحة المفاتيح ويُسنِدها إلى متغير. هذا مثالٌ بسيطٌ عنه: #!/bin/bash echo -n "Enter some text > " read text echo "You entered: $text" عرضنا رسالةً في السطر الثالث، لاحظ كيف استعملنا الخيار ‎-n لكي نجعل الأمر echo يُبقي على مؤشر الكتابة موجودًا في نفس السطر، أي أنَّه لن يطبع محرف الانتقال إلى سطرٍ جديد (كالعادة). ثم استدعينا الأمر read مع تمرير text كوسيط، وما سيفعله هو انتظار المستخدم إلى أن يكتب شيئًا ثم يضغط على زر Enter، ثم سيُسنِد ما كتبه المستخدم إلى المتغير text. هذا مثالٌ جربنا فيه السكربت السابق: $ read_demo.bash Enter some text > this is some text You entered: this is some text إن لم تُحدِّد اسم المتغير الذي تريد أن يحفظ الأمر read مدخلات المستخدم فيه، فسيَستعمِل متغير البيئة REPLY. هنالك عدِّة خيارات للأمر read، أهم اثنين منها هما ‎-t و ‎-s. يأتي الخيار ‎ -tمتبوعًا بعدد الثواني التي سينتظر فيها الأمرُ read المستخدمَ لتوفير مدخلات. وهذا يعني أنَّ الأمر read سيتوقف عن قبول مدخلات من المستخدم بعد هذه المهلة الزمنية. يمكن أن يُستخدَم هذا الخيار إذا كان على السكربت الاستمرار في التنفيذ حتى لو لم يوفِّر المستخدم مدخلات (ربما ستوضع قيمة افتراضية بدلًا من مدخلات المستخدم في هذه الحالة). هذا مثالٌ عن الخيار ‎-t: #!/bin/bash echo -n "Hurry up and type something! > " if read -t 3 response; then echo "Great, you made it in time!" else echo "Sorry, you are too slow!" fi يؤدي الخيار ‎-s إلى عدم إظهار المدخلات التي يكتبها المستخدم على الشاشة، وهذا مفيدٌ عندما تسأل المستخدم عن كلمة مروره، أو غير ذلك من المعلومات السرية. العمليات الحسابية من البديهي أنَّ الحاسوب يستطيع إجراء عمليات حسابية بسيطة. توفِّر الصدفة إمكانية إجراء عمليات حسابية على الأعداد الصحيحة (integer). ما هي الأعداد الصحيحة؟ هي الأعداد الكاملة مثل 1 و 2 و 456 و -235 التي لا تحتوي على فواصل عشرية مثل 0.5 و ‎.443 أو 3.1415. إذا كان من الضروري أن تتعامل مع الأعداد العشرية، فهنالك برنامجٌ منفصل اسمه bc الذي تتعامل معه بلغة خاصة للحساب الدقيق، ويمكن أن يُستعمَل في سكربتات الصَدَفة لكنه خارج عن نطاق هذه السلسلة. لنقل أنَّك تريد استخدام سطر الأوامر كآلة حاسبة بسيطة. تستطيع فعل ذلك كالآتي: $ echo $((2+2)) عندما تواجه الصَدَفة التعبير ‎$(( ))‎ فستحاول وضع ناتج العملية الحسابية الموجودة داخل الأقواس بدلًا منه. لاحظ كيف سيتم تجاهل الفراغات: $ echo $((2+2)) 4 $ echo $(( 2+2 )) 4 $ echo $(( 2 + 2 )) 4 تستطيع الصَدَفة إجراء مختلف العمليات الحسابية الشهيرة (وغير الشهيرة). هذا مثالٌ عنها: #!/bin/bash first_num=0 second_num=0 echo -n "Enter the first number --> " read first_num echo -n "Enter the second number -> " read second_num echo "first number + second number = $((first_num + second_num))" echo "first number - second number = $((first_num - second_num))" echo "first number * second number = $((first_num * second_num))" echo "first number / second number = $((first_num / second_num))" echo "first number % second number = $((first_num % second_num))" echo "first number raised to the" echo "power of the second number = $((first_num ** second_num))" لاحظ أنَّ علامة $ التي تسبق أسماء المتغيرات غير ضرورية داخل التعابير الرياضية مثل first_num + second_num. جرِّب البرنامج الآتي وراقب كيف سيتعامل مع القسمة (تذكَّر أننا نقسِّم الأعداد الصحيحة هنا) وكيف سيتعامل مع الأعداد الكبيرة. عندما تصبح الأعداد كبيرةً جدًا، فسيحدث "فيضان" (overflow) في الذاكرة كما في عدَّاد المسافة المقطوعة في السيارات عندما يتجاوز عدد الكيلومترات التي صُمِّمَ لإحصائها. حيث يبدأ من جديد، لكن يجب المرور على الأعداد السالبة في الحاسوب (ﻷن هذه هي طريقة تخزين الأعداد داخليًا في الذاكرة). تؤدي القسمة على صفر (التي لا تجوز رياضيًا) إلى ظهور خطأ. أنا متأكد أنَّك ستتعرف على أول أربع عمليات التي هي الجمع والطرح والضرب والقسمة، لكن العملية الخامسة غريبة بعض الشيء، الرمز % يُمثِّل باقي القسمة (يُسمى modulo). تُجري هذه العملية القسمة لكن بدلًا من إظهار نتيجة القسمة، فستظهِر باقي القسمة. على الرغم من أنَّ ذلك لا يبدو مفيدًا جدًا، لكنه كذلك، حيث يوفِّر أداةً مفيدةً جدًا أثناء كتابة البرامج. على سبيل المثال، عندما يُعيد باقي القسمة القيمة صفر، فهذا يُشير إلى أنَّ العدد الأول هو من مضاعفات العدد الثاني، وقد تستفيد من هذه المعلومة كثيرًا: #!/bin/bash number=0 echo -n "Enter a number > " read number echo "Number is $number" if [ $((number % 2)) -eq 0 ]; then echo "Number is even" else echo "Number is odd" fi وكذلك الأمر في برنامج يُحوِّل الثواني إلى ساعات ودقائق: #!/bin/bash seconds=0 echo -n "Enter number of seconds > " read seconds hours=$((seconds / 3600)) seconds=$((seconds % 3600)) minutes=$((seconds / 60)) seconds=$((seconds % 60)) echo "$hours hour(s) $minutes minute(s) $seconds second(s)" ترجمة -وبتصرّف- للمقال Keyboard Input And Arithmetic لصاحبه William Shotts.

تُعرِّف HTML العنصر <canvas> على أنه "لوحة نقطية ذات أبعاد معينة يمكن استخدامها لعرض المخططات ورسومات الألعاب وغيرها من الصور المرئية برمجيًا". ويُمثِّل مستطيلًا في صفحتك حيث تستخدم JavaScript لرسم أي شيء تريده فيه. الدعم الأساسي للعنصر canvas IE Firefox Safari Chrome Opera iPhone Android 7.0+* 3.0+ 3.0+ 3.0+ 10.0+ 1.0+ 1.0+ * يتطلب IE ‏7 و 8 مكتبة خارجية هي explorercanvas، أما IE 9 فهو يدعم العنصر <canvas> داخليًا. كيف يبدو عنصر canvas؟ ليس له شكل، حقًا! ليس في عنصر <canvas> أي محتوى وليس له إطارٌ حتى. يُضاف عنصر canvas كالآتي: <canvas width="300" height="225"></canvas> لنضف إطارًا منقطًا لكي نستطيع أن نرى ما الذي نتعامل معه: الشكل 1: عنصر canvas مع إطار يمكن أن يكون لديك أكثر من عنصر <canvas> في نفس الصفحة، وسيظهر كل عنصر على حدة في شجرة DOM، ويحافظ كل عنصر canvas على خاصياته؛ فإن أعطيت كل عنصر canvas خاصية id، فيمكنك الوصول إليه كما تفعل مع أي عنصر آخر. لنوسِّع الشيفرة السابقة لكي تتضمن خاصية id: <canvas id="a" width="300" height="225"></canvas> أصبح بإمكاننا بسهولة العثور على عنصر <canvas> السابق في شجرة DOM. var a_canvas = document.getElementById("a"); الأشكال البسيطة IE Firefox Safari Chrome Opera iPhone Android 7.0+* 3.0+ 3.0+ 3.0+ 10.0+ 1.0+ 1.0+ * يتطلب IE ‏7 و 8 مكتبة خارجية هي explorercanvas، أما IE 9 فهو يدعم رسم الأشكال البسيطة في العنصر <canvas> داخليًا. يبدأ كل عنصر canvas فارغًاـ ثم علينا الرسم فيه. لنبدأ ببعض الأشكال. يمكن استخدام الحدث (action) ‏onclick لاستدعاء الدالة الآتية عندما يضغط المستخدم على زرٍ ما: function draw_b() { var b_canvas = document.getElementById("b"); var b_context = b_canvas.getContext("2d"); b_context.fillRect(50, 25, 150, 100); } لا يوجد شيءٌ مميزٌ في أول سطر من الدالة، إذ أنَّ مهمته هي العثور على عنصر <canvas> الموجود في شجرة DOM. function draw_b() { var b_canvas = document.getElementById("b"); var b_context = b_canvas.getContext("2d"); b_context.fillRect(50, 25, 150, 100); } لدى كل عنصر canvas ما نسميه "إطار الرسم" (drawing context)، الذي يحدث فيه كل الأمور المسلية. فبعد أن تعثر على عنصر <canvas> في شجرة DOM (باستخدام document.getElementById()‎ أو أيّة طريقة أخرى) ستستطيع أن تستدعي الدالة getContext()‎، يجب عليك تمرير السلسلة النصية "2d" دومًا إلى الدالة getContext()‎. س: هل يمكن رسم رسوميات 3D في canvas؟ ج: نعم، عبر تقنية WebGL التي يمكنها رسم الأشكال ثلاثية الأبعاد في المتصفحات دون إضافات. تدعم أغلبية المتصفحات الحديثة هذه التقنية (Firefox الإصدار الرابع وما بعده، و Chrome الإصدار التاسع وما بعده، و Opera 12 وما بعده، و Safari 5.1 وما بعده، و IE 11)؛ يتم العمل على تطوير هذه التقنية في مجموعة عمل WebGL. إذًا، أصبح لديك عنصر <canvas> ولديك إطار الرسم (drawing context) الخاص به. إطار الرسم هو المكان الذي ستُعرَّف فيه جميع دوال وخاصيات الرسم. هنالك مجموعةٌ كاملةٌ من الخاصيات والدوال المُكرَّسة لرسم المستطيلات: يمكن أن تكون الخاصية fillStyle لونًا من ألوان CSS، أو نقشًا (pattern)، أو تدرجًا لونيًا (gradient) (سنذكر مزيدًا من المعلومات عن التدرجات اللونية بعد قليل). القيمة الافتراضية لهذه الخاصية هي اللون الأسود، لكنك تستطيع أن تضبطها لما تشاء. سيتذكر كل إطار رسم (drawing context) خاصياته لطالما بقيت الصفحة مفتوحةً إلا إن فعلت شيئًا لإعادة ضبطه. الدالة (fillRect(x, y, width, height ترسم مستطيلًا مملوءًا باللون أو النقش الموجود في fillStyle. الخاصية strokeStyle شبيهة بخاصية fillStyle، فيمكن أن تكون لون CSS أو نقشًا أو تدرجًا لونيًا. الدالة (strokeRect(x, y, width, height ترسم مستطيلًا دون ملئه، إذ ترسم حوافه وإطاره الخارجي فحسب، وتَستعمل الخاصية strokeStyle لذلك. الدالة (clearRect(x, y, width, height تسمح كل البكسلات الموجودة في المستطيل المُحدَّد. س: هل يمكنني أن أعيد ضبط لوحة الرسم في عنصر canvas؟ ج: نعم، فسيؤدي تحديد عرض أو ارتفاع عنصر <canvas> إلى إعادة ضبط (reset) كل الخاصيات في إطار الرسم إلى قيمها الافتراضية. لاحظ أنَّه ليس من الضروري تغيير العرض، إذ يمكنك أن تضبطه إلى قيمته الحالية كما يلي: var b_canvas = document.getElementById("b"); b_canvas.width = b_canvas.width; بالعودة إلى الشيفرة في المثال السابق: var b_canvas = document.getElementById("b"); var b_context = b_canvas.getContext("2d"); b_context.fillRect(50, 25, 150, 100); سترسم الدالة fillRect()‎ عند استدعائها مستطيلًا وتملؤه بنمط الملء الحالي الذي هو اللون الأسود (إلا إذا غيرتَه). يُعرَّف المستطيل عبر زاويته العليا اليسرى (50، 25)، وعرضه (150)، وارتفاعه (100). لكي نفهم ذلك فهمًا جيدًا، فلنلقِ نظرةً إلى نظام الإحداثيات في canvas. الإحداثيات في عنصر canvas يمكننا تخيل لوحة الرسم في عنصر canvas على أنها شبكة ثنائية البعد، ويكون مبدأ الإحداثيات فيها (‎0, 0) في الزاوية العليا اليسرى من لوحة الرسم. تزداد القيم على المحور X عند الانتقال نحو الحافة اليمنى من لوحة الرسم، وتزداد القيم على المحور Y بالانتقال نحو الحافة السفلية من لوحة الرسم. الشكل 2: توضيح لنظام الإحداثيات في عنصر canvas رُسِمَ الشكل السابق عبر عنصر <canvas> الذي يحتوي على: مجموعة من الخطوط الأفقية مجموعة من الخطوط الشاقولية خطين أفقيين سوداوين خطين صغيرين سوداوين مائلين يشكلان سهمًا خطين شاقوليين سوداوين خطين صغيرين سوداوين مائلين يشكلان السهم الآخر الحرف "x" الحرف "y" النص "(‎(0, 0" قرب الزاوية العليا اليسرى النص "(‎500, 375)" قرب الزاوية السفلى اليمنى نقطة في الزاوية العليا اليسرى، وأخرى في الزاوية السفلى اليمنى علينا أولًا تعريف العنصر <canvas> نفسه، حيث يُحدِّد العنصر <canvas> خاصية العرض width والارتفاع height، والمُعرِّف id كي نستطيع العثور عليه بسهولة لاحقًا. <canvas id="c" width="500" height="375"></canvas> ثم علينا كتابة سكربت لكي نجد عنصر <canvas> في شجرة DOM ونحصل على إطار الرسم الخاص به. var c_canvas = document.getElementById("c"); var context = c_canvas.getContext("2d"); نستطيع الآن البدء في رسم الخطوط. المسارات IE Firefox Safari Chrome Opera iPhone Android 7.0+* 3.0+ 3.0+ 3.0+ 10.0+ 1.0+ 1.0+ * يتطلب IE ‏7 و 8 مكتبة خارجية هي explorercanvas، أما IE 9 فهو يدعم المسارات في العنصر <canvas> داخليًا. تخيل أنك تريد أن ترسم رسمةً بالحبر، من المؤكد أنَّك لن تبدأ الرسم بأقلام الحبر مباشرةً، لأنك قد تُخطئ؛ فعوضًا عن ذلك سترسم المستقيمات والمنحنيات بقلم الرصاص، ثم إن أعجبتك فيمكنك أن "تُحبِّرَها". هنالك ما نسميه "المسارات" (paths) في عناصر canvas، وتعريف المسار يُشبِه تمامًا الرسم بقلم الرصاص؛ يمكنك رسم ما تشاء لكنه لن يكون جزءًا من اللوحة النهائية إلا إن أمسكت أقلام التحبير ومررتها فوق المسار الذي رسمتَه. استعمل الدالتين الآتيتين لرسم المستقيمات "بقلم الرصاص": (moveTo(x, y تحريك قلم الرصاص إلى نقطة البداية المُحدَّدة. (lineTo(x, y رسم خط إلى نقطة النهاية المُحدَّدة. سيزداد حجم المسار كلما استدعيت الدالتين moveTo()‎ و lineTo()‎. ترسم الدالتان السابقتان "بقلم الرصاص" (يمكنك أن تسمي هذه العملية ما تشاء)، أي أنَّك لن ترَ شيئًا على لوحة الرسم إلى أن تستدعي إحدى دوال "التحبير". لنبدأ برسم الشبكة: //رسم المستقيمات الشاقولية for (var x = 0.5; x < 500; x += 10) { context.moveTo(x, 0); context.lineTo(x, 375); } //رسم المستقيمات الأفقية for (var y = 0.5; y < 375; y += 10) { context.moveTo(0, y); context.lineTo(500, y); } تلك الدوال "رصاصية"، أي لن يظهر شيءٌ على لوحة الرسم بعد؛ إذ سنحتاج إلى دالة "تحبير" لإظهار تلك الخطوط. context.strokeStyle = "#eee"; context.stroke(); الدالة storke()‎ هي إحدى دوال "التحبير"، وهي تُحبِّر المسار المعقد الذي عرَّفتَه بدوال moveTo()‎ و lineTo()‎ السابقة. خاصية strokeStyle تتحكم بلون تلك الخطوط. هذه هي النتيجة: الشكل 3: شبكة مرسومة داخل عنصر canvas س: لماذا بدأت x و y من 0.5 وليس من 0؟ ج: تخيل أنَّ كل بكسل هو مربع كبير، وأنَّ الإحداثيات ذات الرقم الكامل (0، 1، 2…) هي حواف تلك المربعات؛ فإذا أردت أن ترسم خطًا عرضُه واحدة الأطوال (one-unit-wide) بين الإحداثيات ذات الرقم الكامل، فسوف يمتد إلى أن يصل إلى طرفَي المربع (انظر الشكل الآتي للإيضاح)، وسيكون الخط الناتج مرسومًا بعرض بكسلين. أما لرسم خط عرضه بكسل واحد، فعليك أن تُزيح الإحداثيات بمقدار 0.5 عموديًا على منحى (أو اتجاه) الخط. على سبيل المثال، إذا كنت تحاول رسم خط من (‎1, 0) إلى (‎1, 3)، فسيرسم المتصفح خطًا يغطي 0.5 بكسل على جانبَيّ x=1، ولكن الشاشة غير قادرة على عرض نصف بكسل، لذلك سيمتد الخط لكي يُغطي بكسلين: أما لو أردت أن ترسم خطًا من (1.5, 0) إلى (1.5, 3)، فسيرسم المتصفح خطأ يغطي 0.5 بكسل على طرفَي x=1.5، الذي يؤدي إلى رسم خط بعرض 1 بكسل: لنرسم الآن السهم الأفقي. جميع الخطوط والمنحنيات الموجودة على نفس المسار ستُرسَم بنفس اللون (أو التدرج اللوني، وسنأتي لذكر ذلك لاحقًا). لكننا نريد أن نرسم السهم بلون مختلف (الأسود)، لذلك نحتاج إلى البدء بمسار (path) جديد. //مسار جديد context.beginPath(); context.moveTo(0, 40); context.lineTo(240, 40); context.moveTo(260, 40); context.lineTo(500, 40); context.moveTo(495, 35); context.lineTo(500, 40); context.lineTo(495, 45); وبنفس الطريقة نرسم السهم الشاقولي؛ ولمّا كان السهم الشاقولي بنفس لون السهم الأفقي، فلا حاجة إلى إنشاء مسار جديد، إذ سيُشكِّل السهمان مسارًا واحدًا. //لا حاجة إلى إنشاء مسار جديد context.moveTo(60, 0); context.lineTo(60, 153); context.moveTo(60, 173); context.lineTo(60, 375); context.moveTo(65, 370); context.lineTo(60, 375); context.lineTo(55, 370); لقد قلتُ أنَّ هذين السهمين يجب أن يُرسما باللون الأسود، لكن لون strokeStyle ما يزال "الفضي الفاتح" (لا تتم عملية إعادة تعيين قيم fillStyle و strokeStyle عندما تبدأ مسارًا جديدًا). لا بأس، لأننا رسمنا إلى الآن "بالرصاص" ولم "نُحبِّر" بعد، علينا الآن أن نضبط قيمة strokeStyle إلى اللون الأسود؛ وإلا سيُرسم هاذين السهمين بالفضي الفاتح وسيصعب علينا رؤيتهما. سيُغيّر السطران الآتيان اللون إلى الأسود ويرسمان الخطوط في لوحة الرسم: context.strokeStyle = "#000"; context.stroke(); هذه هي النتيجة: الشكل 4: المحوران مرسومان دون تسمية على لوحة الرسم النص IE Firefox Safari Chrome Opera iPhone Android 7.0+* 3.0+ 3.0+ 3.0+ 10.0+ 1.0+ 1.0+ * يتطلب IE ‏7 و 8 مكتبة خارجية هي explorercanvas، أما IE 9 فهو يدعم طباعة النصوص في العنصر <canvas> داخليًا. ** يتطلب Firefox 3.0 مكتبة للتوافقية. بالإضافة إلى القدرة على رسم خطوط في لوحة الرسم، يمكنك أيضًا "رسم" الجمل النصية. وعلى عكس النصوص في الصفحة المحيطة بلوحة الرسم، لا يوجد هنالك أيّة خاصيات CSS تتعلق بالتخطيط (layout) مثل floats و margins و padding و word wrapping. تستطيع ضبط بعض خاصيات الخط، ثم اختيار نقطة على لوحة الرسم و"رسم" نصك هناك. تتوفر خاصيات الخطوط الآتية في لوحة الرسم: الخاصية font التي يمكن أن تُضبَط إلى أي شيءٍ تستطيع ضبطه في خاصية font في CSS. وهذا يتضمن نمط الخط، ونوع الخط، وسماكة الخط، وحجم الخط، وارتفاع السطر، واسم "عائلة" الخط. الخاصية textAlign تتحكم بمحاذاة النص، وهي شبيهة (لكن ليس مماثلة تمامًا) بخاصية text-align في CSS. القيم المحتملة هي start و end و left و right و center. الخاصية textBaseline تتحكم في مكان "رسم" النص نسبةً إلى نقطة البداية. القيم المحتملة هي top أو hanging أو middle أو alphabetic أو ideographic أو bottom. الخاصية textBaseline معقدة ودقيقة، لأن طريقة كتابة النصوص معقدة (لا أقصد هنا الإنكليزية، لكنك تستطيع رسم أي محرف يونيكود في عنصر canvas، وكتابة نصوص يونيكود معقدة)، تشرح مواصفات HTML5 مختلف خطوط الأساس (baselines): أعلى مربع em هو تقريبًا على مستوى أعلى المحارف في الخط (font)، أما "hanging baseline" فهو مكان ارتكاز بعض المحارف مثل आ، أما خطmiddle فهو يقع في منتصف المسافة بين أعلى مربع em وأسفل مربع em. أما خط alphabetic فهو مكان ارتكاز الأحرف مثل Á و ÿ و f و Ω، وخط ideographic هو مكان ارتكاز المحارف مثل 私 و 達، وأسفل مربع em هو تقريبًا أسفل المحارف الموجودة في خطٍ (font) ما. قد يكون أعلى وأسفل الصندوق المحيط (bounding box) بعيدًا عن خطوط الأساس السابقة نتيجةً لامتداد بعض المحارف خارج مربع em. الشكل 5: خطوط الأساس تستطيع استخدام top أو middle أو bottom لخاصية textBaseline للأبجديات البسيطة مثل الإنكليزية دون أن تكترث للبقية. لنرسم بعض النصوص! النص المرسوم داخل عنصر canvas يرث حجم الخط ونمطه من عنصر <canvas> نفسه، لكنك تستطيع إعادة تعريف تلك القيم بضبط خاصية font في إطار الرسم. //تغيير نمط الخط context.font = "bold 12px sans-serif"; context.fillText("x", 248, 43); context.fillText("y", 58, 165); ترسم الخاصية fillText()‎ النص. context.font = "bold 12px sans-serif"; //رسم النص context.fillText("x", 248, 43); context.fillText("y", 58, 165); س: هل أستطيع استخدام مقاسات الخطوط النسبية لرسم النصوص في عنصر canvas؟ ج: نعم. مثل أي عنصر HTML آخر في صفحتك، يحسب العنصر <canvas> مقاس الخط بناءً على قواعد CSS في صفحتك. فإذا ضبطت خاصية context.font إلى مقاس خط نسبي مثل 1.5em أو ‎150%، فسيضرب متصفحك هذا الرقم بحجم الخط المحسوب لعنصر <canvas> نفسه. أريد أن يكون أعلى النص الموجود في الزاوية العليا اليسرى على بعد y=5 من الحافة العلوية، لكنني كسول ولا أريد قياس ارتفاع النص وحساب بعد خط الأساس (baseline)، وإنما سأضبط textBaseline إلى top وسأمرر إحداثيات الزاوية العليا اليسرى من مربع النص. context.textBaseline = "top"; context.fillText("( 0 , 0 )", 8, 5); أما للنص في الزاوية السفلى اليمنى، فسأرسم الزاوية السفلى اليمنى للنص في الإحداثيات (492,370)، أي بضعة بكسلات من الزاوية السفلى اليمنى من لوحة الرسم؛ لكنني لا أريد قياس عرض أو ارتفاع النص، لهذا أضبط الخاصية textAlign إلى right والخاصية textBaseline إلى botton، ثم استدعي الدالة fillText()‎ مُمرِّرًا إليها إحداثيات الزاوية السفلى اليمنى من مربع النص. context.textAlign = "right"; context.textBaseline = "bottom"; context.fillText("( 500 , 375 )", 492, 370); وهذه هي النتيجة: الشكل 6: تسمية المحاور لقد نسينا النقاط الموجودة على الزوايا! سنتعلم كيف نرسم الدوائر لاحقًا، أما الآن، فسأغش قليلًا وأرسمها كمستطيلات. context.fillRect(0, 0, 3, 3); context.fillRect(497, 372, 3, 3); هذا كل ما في الأمر! هذه هي النتيجة النهائية: الشكل 7: الرسم النهائي للإحداثيات عبر عنصر canvas التدرجات اللونية IE Firefox Safari Chrome Opera iPhone Android التدرجات اللونية الخطية 7.0+* 3.0+ 3.0+ 3.0+ 10.0+ 1.0+ 1.0+ التدرجات اللونية الشعاعية 9.0+ 3.0+ 3.0+ 3.0+ 10.0+ 1.0+ 1.0+ * يتطلب IE ‏7 و 8 مكتبة خارجية هي explorercanvas، أما IE 9 فهو يدعم التدرجات اللونية في العنصر <canvas> داخليًا. لقد تعلمنا سابقًا في هذا الفصل كيف نرسم مستطيلًا مملوءًا بلونٍ ما، ثم تعلمنا كيف نرسم مستطيلًا ذا إطارٍ ملوَّن بلونٍ معين. لكن الأمر ليس محدودًا للألوان فقط، إذ يمكنك فعل ما تشاء بالتدرجات اللونية، لننظر إلى أحد الأمثلة. الشكل 8: تدرج لوني من اليسار إلى اليمين سيبدو وسم canvas كغيره من الوسوم: <canvas id="d" width="300" height="225"></canvas> علينا أولًا أن نعثر على عنصر <canvas> ثم نحصل على إطار الرسم: var d_canvas = document.getElementById("d"); var context = d_canvas.getContext("2d"); يمكننا أن نبدأ بتعريف التدرج اللوني بعد حصولنا على إطار الرسم. التدرج اللوني هو انتقالٌ ناعمٌ بين لونين أو أكثر. يمكن تعريف نوعين من التدرجات اللونية في إطار الرسم: الدالة (createLinearGradient(x0, y0, x1, y1 ترسم تدرجًا لونيًا عبر قطعة مستقيمة من النقطة (x0, y0) إلى (x1, y1). الدالة (createRadialGradient(x0, y0, r0, x1, y1, r1 ترسم تدرجًا لونيًا عبر مخروط (cone) بين دائرتين. وتُمثِّل أول ثلاثة معاملات (parameters) دائرة البداية ذات المركز (x0, y0) ونصف القطر r0. أما آخر ثلاثة معاملات فهي تمثل دائرة النهاية ذات المركز (x1, y1) ونصف القطر r1. لنُنشِئ تدرجًا لونيًا خطيًّا (linear)؛ يمكن أن تكون التدرجات اللونية بأي قياس، لكننا سنجعل هذا التدرج بعرض 300 بكسل، مثل لوحة الرسم. var my_gradient = context.createLinearGradient(0, 0, 300, 0); لما كانت قيم y (الوسيط الثاني والرابع) تساوي 0، فسيكون اتجاه التدرج اللوني من اليسار إلى اليمين. يمكنك تعريف ألوان التدرج بعد أن تحصل على كائن التدرج اللوني. يمكن أن يكون للتدرج محطتَي توقف لوني أو أكثر. التوقف اللوني (color stop) يمكن أن يكون في أي مكان في التدرج. ولإضافة توقف لوني، عليك تحديد مكانه ضمن التدرج اللوني، يمكن أن تكون تلك القيم بين 0 و 1. لنُعرِّف تدرجًا لونيًا من الأسود إلى الأبيض. my_gradient.addColorStop(0, "black"); my_gradient.addColorStop(1, "white"); لا يُرسَم أيّ شيءٍ في لوحة الرسم عند تعريف التدرج اللوني، إذ سيُخزَّن ذاك الكائن في مكانٍ ما في الذاكرة. أما لرسم التدرج اللوني، فعليك أن تضبط خاصية fillStyle إلى ذاك التدرج ثم ترسم شكلًا ما مثل مستطيل أو مستقيم. context.fillStyle = my_gradient; context.fillRect(0, 0, 300, 225); وهذه هي النتيجة: الشكل 9: تدرج لوني من اليسار إلى اليمين لنفترض أنَّك تريد تدرجًا لونيًا من الأعلى إلى الأسفل؛ فسيكون عليك إنشاء كائن للتدرج اللوني تكون فيه قيمة x ثابتة (الوسيطين الأول والثالث)، وتجعل قيم y (الوسطين الثاني والرابع) تتراوح بين 0 إلى ارتفاع لوحة الرسم. var my_gradient = context.createLinearGradient(0, 0, 0, 225); my_gradient.addColorStop(0, "black"); my_gradient.addColorStop(1, "white"); context.fillStyle = my_gradient; context.fillRect(0, 0, 300, 225); وهذه هي النتيجة: الشكل 10: تدرج لوني من الأعلى إلى الأسفل وتستطيع أيضًا أن تجعل التدرجات اللونية قطرية. //قيم x و y متغيرة var my_gradient = context.createLinearGradient(0, 0, 300, 225); my_gradient.addColorStop(0, "black"); my_gradient.addColorStop(1, "white"); context.fillStyle = my_gradient; context.fillRect(0, 0, 300, 225); وهذه هي النتيجة: الشكل 11: تدرج لوني قطري الصور IE Firefox Safari Chrome Opera iPhone Android 7.0+* 3.0+ 3.0+ 3.0+ 10.0+ 1.0+ 1.0+ * يتطلب IE ‏7 و 8 مكتبة خارجية هي explorercanvas، أما IE 9 فهو يدعم تضمين الصور في العنصر <canvas> داخليًا. يُظهِر الشكل الآتي قطةً معروضةٌ عبر عنصر <img>: الشكل 12: قطة معروضة عبر عنصر img أما هذه فهي نفس القطة لكن مرسومة في عنصر canvas: الشكل 13: قطة معروضة ضمن عنصر canvas هنالك دالة اسمها drawImage()‎ في إطار الرسم تُستعمل لتضمين صورة في عنصر canvas. تأخذ هذه الدالة ثلاثة، أو خمسة، أو تسعة وسائط: (drawImage(image, dx, dy تأخذ صورةً وترسمها في لوحة الرسم، والإحداثيات المعطية (dx, dy) هي إحداثيات الزاوية العليا اليسرى من الصورة. فلو مررنا الإحداثيات (‎(0, 0 فستُرسَم الصورة في الزاوية العليا اليسرى من لوحة الرسم. (drawImage(image, dx, dy, dw, dh تأخذ صورةً وتغير عرضها إلى dw وارتفاعها إلى dh، ثم ترسمها على لوحة الرسم في الإحداثيات (dx, dy). (drawImage(image, sx, sy, sw, sh, dx, dy, dw, dh تأخذ صورةً وتقتطعها لتصبح مساويةً إلى المستطيل (sx, sy, sw, sh) ثم تغير أبعادها إلى (dw, dh) ثم ترسمها على لوحة الرسم في الإحداثيات (dx, dy). توضِّح مواصفات HTML5 معاملات (parameters) الدالة drawImage()‎: المستطيل المصدر هو المستطيل (ضمن حدود الصورة المصدرية) الذي تكون رؤوس أضلاعه هي (sx, sy)، و (sx+sw, sy)، و (sx+sw, sy+sh)، و (sx, sy+sh). أما المستطيل الوجهة، فهو المستطيل (ضمن حدود لوحة الرسم) الذي تكون رؤوس أضلاعه هي النقاط (dx, dy)، و (dx+dw, dy)، و (dx+dw, dy+dh)، و (dx, dy+dh). الشكل 14: تمثيل رسومي لمعاملات الدالة drawImage لرسم صورة داخل لوحة الرسم، فستحتاج إلى صورة! يمكن أن تكون الصورة عنصر <img> موجود مسبقًا، أو بإمكانك إنشاء كائن Image()‎ باستخدام JavaScript. وفي كلا الحالتين عليك أن تتأكد أنَّ الصورة محمَّلة تحميلًا كاملًا قبل أن ترسمها في لوحة الرسم. إذا كنت تستخدم عنصر <img> موجود مسبقًا، فيمكنك رسم الصورة في لوحة الرسم أثناء الحدث window.onload. <img id="cat" src="images/cat.png" alt="sleeping cat" width="177" height="113"> <canvas id="e" width="177" height="113"></canvas> <script> window.onload = function() { var canvas = document.getElementById("e"); var context = canvas.getContext("2d"); var cat = document.getElementById("cat"); context.drawImage(cat, 0, 0); }; </script> أما لو كنتَ تُنشِئ كائن الصورة عبر JavaScript، فيمكنك رسم الصورة داخل لوحة الرسم أثناء الحدث Image.onload. <canvas id="e" width="177" height="113"></canvas> <script> var canvas = document.getElementById("e"); var context = canvas.getContext("2d"); var cat = new Image(); cat.src = "images/cat.png"; cat.onload = function() { context.drawImage(cat, 0, 0); }; </script> المعاملان الاختياريان الثالث والرابع في دالة drawImage()‎ يتحكمان في تغيير أبعاد الصورة. هذه هي نفس الصورة بعد تقليل أبعادها إلى النصف مرسومةً بشكل تكراري في إحداثياتٍ مختلفة ضمن نفس لوحة الرسم. الشكل 15: الكثير من القطط! هذا هو السكربت الذي يؤدي إلى رسم الشكل السابق: cat.onload = function() { for (var x = 0, y = 0; x < 500 && y < 375; x += 50, y += 37) { //تغيير أبعاد الصورة context.drawImage(cat, x, y, 88, 56); } }; ربما تتساءل سؤالًا منطقيًا: لماذا تريد رسم صورة في لوحة الرسم أصلًا؟ بماذا ستستفيد من التعقيد الناتج عن رسم صورة داخل لوحة الرسم عوضًا عن استخدام عنصر <img> وبعض خاصيات CSS؟ حتى التأثير السابق (تكرار صورة القطة) يمكن أن يتم باستخدام 10 عناصر <img> متداخلة. الجواب المبسط هو: لنفس سبب حاجتك إلى رسم النصوص في لوحة الرسم. لاحظ كيف تُضمَّن مخطط إحداثيات canvas نصًا ومستقيماتٍ وأشكالًا. فوضع النص ضمن لوحة الرسم هو جزءٌ من عملٍ أكبر. والمخططات الأكثر تعقيدًا ستستفيد كثيرًا من الدالة drawImage()‎ لتضمين الأيقونات والرسوميات وغيرها. ماذا عن متصفح IE؟ لم تكن الإصدارات الأقدم من الإصدار التاسع من متصفح Internet Explorer تدعم الواجهة البرمجية (API) لعنصر canvas (يدعم IE9 واجهة canvas البرمجية بالكامل). لكن الإصدارات القديمة من Internet Explorer تدعم تقنية مملوكة من مايكروسوفت اسمها VML، التي تفعل العديد من الأشياء التي يفعلها العنصر <canvas>، وبهذا وُلِدَت المكتبة excanvas.js. Explorercanvas ‏(excanvas.js) هي مكتبة JavaScript مفتوحة المصدر مُرخَّصة برخصة Apache التي تجعل من الممكن استعمال واجهة canvas البرمجية في متصفح Internet Explorer. عليك تضمين وسم <script> الآتي في أعلى صفحتك لكي تستخدمها. <!DOCTYPE html> <html> <head> <meta charset="utf-8"> <title>Dive Into HTML5</title> <!--[if lt IE 9]> <script src="excanvas.js"></script> <![endif]--> </head> <body> ... </body> </html> الأسطر ‎<!--[if lt IE 9]>‎ و ‎<![endif]-->‎ تسمى التعليقات الشرطية. حيث يعاملها Internet Explorer كأنها عبارة if الشرطية: "إن كان الإصدار الحالي من متصفح Internet Explorer أقل من الإصدار 9، فنفِّذ الشيفرة الآتية."، وستعامل بقية المتصفحات تلك الشيفرة على أنها تعليقات HTML. فالخلاصة هي أنَّ متصفح Internet Explorer (الإصدار الثامن والسابع) سيُنزِّل السكربت ثم سيُنفِّذه، لكن ستتجاهله بقية المتصفحات تمامًا، وهذا يجعل صفحتك تُحمَّل بشكلٍ أسرع في المتصفحات التي تدعم واجهة canvas البرمجية داخليًا (أي أنها لن تُنزِّل السكربت، ولن تنفذه، ولن تفعل أيّ شيءٍ معه). ليس عليك فعل أي شيءٍ إضافي بعد تضمين excanvas.js في ترويسة صفحتك. ضمِّن عناصر <canvas> في شيفرتك أو أنشِأها ديناميكيًا باستخدام JavaScript، واتبع التعليمات الواردة في هذا الفصل للحصول على لوحة رسم عنصر <canvas>، ثم تستطيع البدء برسم الأشكال والنصوص والنقوش. ليس تمامًا… هنالك بعض المحدوديات: يمكن أن تكون التدرجات اللونية خطيةً فقط. التدرجات اللونية الشعاعية غير مدعومة. يجب تكرار النقوش (patterns) في كلا الاتجاهين. ميزة Clipping regions غير مدعومة. تغيير الأبعاد غير المنتظم لا يستطيع تغيير أبعاد حدود الأشكال (strokes) بشكلٍ صحيح. إنها بطيئة؛ ولا أظن أنَّ ذلك صادمٌ لأي شخص، فمن المعلوم أنَّ مُفسِّر JavaScript في متصفح Internet Explorer أبطأ من غيره من المتصفحات؛ فما بالك برسم أشكال معقدة عبر مكتبة JavaScript ستحول الدوال والأوامر إلى تقنيةٍ مختلفة تمامًا؟ لن تلاحظ بطئًا في الأداء في الأمثلة البسيطة مثل رسم بعض الخطوط وإجراء بعض العمليات على صورة، لكنك سترى ذلك بوضوح بعد أن تحاول إنشاء تأثيرات حركية باستخدام تقنية canvas. هنالك تحذيرٌ آخر حول استخدام excanvas.js، وهذه مشكلة واجهتني أثناء إنشاء أمثلة هذا الفصل. يُهيّئ ExplorerCanvas واجهته البرمجية لعنصر canvas في مكان تضمينك لسكربت excanvas.js في صفحة HTML. لكن ذلك لا يعني أنَّ Internet Explorer جاهزٌ لاستخدامها مباشرةً، وفي بعض الحالات ستواجه حالة خاصة تكون فيها واجهة canvas جاهزة "تقريبًا" (لكن ليس تمامًا) للاستعمال. الأعراض الظاهرة لهذه المشكلة هي أنَّ Internet Explorer سيشتكي من أنَّ "object doesn’t support this property or method" في كل مرة تحاول فيها فعل أي شيء مع عنصر <canvas> مثل الحصول على لوحة الرسم الخاصة به. أسهل حل هذه المشكلة هي تأجيل كل العمليات التي ستجريها على canvas إلى أن يحدث الحدث onload، ولكن هذا قد يستغرق بعضًا من الوقت، خصيصًا إذا كانت في صفحتك الكثير من الصور أو مقاطع الفيديو، التي ستؤخر الحدث onload، لكن ذلك سيعطي المكتبة ExplorerCanvas وقتًا لفعل اللازم. مثال متكامل "الضامة" هي لعبةٌ قديمةٌ جدًا، وهنالك عدِّة نسخ منها؛ أنشأتُ في هذا المثال نسخة السوليتر (أي التي يلعبها شخصٌ واحد فقط) من الضامة ذات تسعِ قطعٍ في رقعةٍ مقاسها 9×9. تتواجد القطع في بداية اللعبة في مربع 3×3 في الركن الأسفل الأيسر من الرقعة. هدف اللعبة هو نقل جميع القطع كي تُشكِّل مربع 3×3 في الركن الأعلى الأيمن من الرقعة بأقل عدد من الحركات. هنالك نوعان من الحركات المسموحة في الضامة: خذ قطعةً وحركها إلى أي مربع فارغ مجاور. المربع "الفارغ" يعني أنَّه لا يحتوي على قطعةٍ فيه حاليًا. أما "مجاور" فهي تعني المربع الذي يقع مباشرةً في شمال أو جنوب أو شرق أو غرب أو الشمال الغربي أو الشمال الشرقي أو الجنوب الغربي أو الجنوب الشرقي من موقع القطعة الحالي (لا يمكن الالتفاف في الرقعة من طرفٍ آخر لآخر، فلو كانت قطعتك في العمود الأيسر من الرقعة، فلا يمكنك أن تحركها نحو الغرب أو الشمال الغربي أو الجنوب الغربي. وإذا كانت قطعتك في السطر الأدنى من الرقعة، فلا تستطيع تحريكها نحو الجنوب أو الجنوب الشرقي أو الجنوب الغربي). يمكنك أخذ قطعة وجعلها "تقفر" فوق قطعة مجاورة، ويمكنك تكرار ذلك. هذا يعني أنَّه إذا قفزت فوق قطعة مجاورة ثم قفزت فوق قطعة أخرى مجاورة لموقعك الجديد، فكل هذا يُحتَسب على أنَّه حركة واحدة. وفي الحقيقة، يتم احتساب أي عدد من القفزات على أنها خطوة واحدة (لأن الهدف من اللعبة هو تقليل العدد الكلي من الحركات؛ ويتطلب اللعب بشكلٍ جيد في الضامة بناءً واستخدامًا لسلاسل طويلة من القطع لكي تستطيع القطع الأخرى القفز قوفها في سلاسل طويل). هذه لقطة شاشة للعبة، يمكنك زيارة الصفحة الآتية لتجربة اللعبة تجربةً حيةً أو لإلقاء نظرة إلى مصدر الصفحة. الشكل 16: لقطة شاشة للعبة الضامة كيف تعمل؟ أنا ممتن لسؤالك. لن أريك كل الشيفرات هنا (يمكنك رؤيتها في halma.js)، وسأتخطى معظم الشيفرات التي تستعمل في تحديد آلية اللعب، لكنني سأركِّز على بعض الأجزاء التي مهتمها هي الرسم في عنصر canvas والاستجابة إلى نقرات الفأرة. سنُهيّئ اللعبة أثناء تحميل الصفحة بضبط أبعاد عنصر <canvas> ثم تخزين مرجع (reference) متعلق بلوحة الرسم. gCanvasElement.width = kPixelWidth; gCanvasElement.height = kPixelHeight; gDrawingContext = gCanvasElement.getContext("2d"); ثم سنفعل شيئًا لم نفعله من قبل قط: سنضيف متتبع أحداث إلى العنصر <canvas> لكي يتتبع حدث النقر على العنصر. gCanvasElement.addEventListener("click", halmaOnClick, false); ستُستدَعى الدالة halmaOnClick()‎ عندما ينقر المستخدم في أي مكان ضمن العنصر canvas، والوسيط الذي يُمرَّر إليها هو كائن MouseEvent الذي يحتوي على معلومات حول مكان نقر المستخدم. function halmaOnClick(e) { var cell = getCursorPosition(e); for (var i = 0; i < gNumPieces; i++) { if ((gPieces.row == cell.row) && (gPieces.column == cell.column)) { clickOnPiece(i); return; } } clickOnEmptyCell(cell); } الخطوة الآتية هي أخذ الكائن MouseEvent وحساب في أي مربع في رقعة الضامة قد تم النقر. تحتل رقعة الضامة كامل عنصر canvas، ولهذا تكون كل نقرة هي نقرة في مكانٍ ما على الرقعة، وكل ما علينا هو معرفة المكان. هذا أمرٌ معقدٌ بعض الشيء، لأن الأحداث المولدة من الفأرة تختلف بشكلٍ أو بآخر بين المتصفحات. function getCursorPosition(e) { var x; var y; if (e.pageX != undefined && e.pageY != undefined) { x = e.pageX; y = e.pageY; } else { x = e.clientX + document.body.scrollLeft + document.documentElement.scrollLeft; y = e.clientY + document.body.scrollTop + document.documentElement.scrollTop; } } أصبح لدينا في هذه المرحلة إحداثيات x و y نسبةً إلى المستند (أي صفحة HTML كلها)، أي أنها ليس مفيدةً بعد؛ حيث نريد أن تكون الإحداثيات منسوبةً إلى لوحة الرسم. x -= gCanvasElement.offsetLeft; y -= gCanvasElement.offsetTop; أصبح لدينا إحداثيات x و y منسوبةً إلى لوحة الرسم، هذا يعني أنَّه لو كانت قيمة x مساويةً للصفر و y مساوية للصفر، فهذا يعني أنَّ المستخدم قد نقر على البكسل في أعلى وأيسر لوحة الرسم. من هنا سنستطيع معرفة أي مربع قد نقر المستخدم عليه، ثم نتصرف بناءً على ذلك. var cell = new Cell(Math.floor(y/kPieceHeight), Math.floor(x/kPieceWidth)); return cell; أوه! أمرُ الأحداث المرتبطة بالفأرة معقدٌ. لكنك يمكنك استخدام نفس التسلسل المنطقي (أو بالأحرى، يمكنك استخدام نفس الشيفرة) في جميع البرمجيات التي تعتمد على عنصر canvas. تذكر: نقرة بالفأرة ← إحداثيات منسوبة إلى المستند كله ← إحداثيات منسوبة إلى لوحة الرسم ← شيفرة خاصة بالتطبيق. حسنًا، لنلقِ نظرةً على آلية الرسم الرئيسية. لمّا كانت الرسوميات بسيطةً جدًا، فقررت مسح محتويات لوحة الرسم وإعادة رسم الرقعة في كل مرة يحصل فيها تغييرٌ في اللعبة ولكن هذا ليس ضروريًا. سيحتفظ إطار الرسم في عنصر canvas بمحتواه الذي رسمته عليه حتى لو تخطاه المستخدم بتمريره في الصفحة، أو إذا غيّر إلى لسانٍ (tab) آخر ثم عاد إليه لاحقًا. إذا كنتَ تُطوِّر تطبيقًا مبنيًا على عنصر canvas فيه رسوميات معقدة (مثل ألعاب الورق) فيمكنك تحسين الأداء بتتبع المناطق التي يجب مسحها من لوحة الرسم وإعادة الرسم داخل تلك المناطق فقط. لكن هذا خارجٌ عن نطاق هذا الكتاب. gDrawingContext.clearRect(0, 0, kPixelWidth, kPixelHeight); يجب أن تكون الشيفرات الآتية مألوفةً لديك، لأنها شبيهة بتلك التي استعملناها لرسم مخطط إحداثيات canvas سابقًا. gDrawingContext.beginPath(); // الخطوط الشاقولية for (var x = 0; x <= kPixelWidth; x += kPieceWidth) { gDrawingContext.moveTo(0.5 + x, 0); gDrawingContext.lineTo(0.5 + x, kPixelHeight); } // الخطوط الأفقية for (var y = 0; y <= kPixelHeight; y += kPieceHeight) { gDrawingContext.moveTo(0, 0.5 + y); gDrawingContext.lineTo(kPixelWidth, 0.5 + y); } // لنرسم الرسمة gDrawingContext.strokeStyle = "#ccc"; gDrawingContext.stroke(); المتعة الحقيقة تبدأ عندما نهم برسم القطع. القطعة هي دائرة، لكننا لم نرسم الدوائر من قبل، وعلاوةً على ذلك، لو اختار المستخدم قطعةً لكي يحركها، فسنحتاج إلى رسم تلك القطعة كدائرة مملوءة. يُمثِّل المعامل p هنا قطعة، التي لها خاصيات row (سطر) و column (عمود) التي تُحدِّد المكان الحالي للقطعة. سنستخدم آلية لتحويل (column, row) إلى إحداثيات منسوبة إلى لوحة الرسم (x, y)، ثم سنرسم دائرة، ثم -إن كانت القطعة مُحدَّدةً من المستخدم- سنملأ الدائرة بلونٍ معين. function drawPiece(p, selected) { var column = p.column; var row = p.row; var x = (column * kPieceWidth) + (kPieceWidth/2); var y = (row * kPieceHeight) + (kPieceHeight/2); var radius = (kPieceWidth/2) – (kPieceWidth/10); أصبح لدينا الآن إحداثيات (x, y) منسوبة إلى لوحة الرسم لمركز الدائرة التي نريد رسمها. للأسف لا توجد دالة باسم circle()‎ في واجهة canvas البرمجية، لكن هنالك الدالة arc()‎؛ لكن الدائرة ما هي إلا قوسٌ تتصل بدايته مع نهايته. هل تتذكر أساسيات الهندسة؟ تأخذ الدالة arc()‎ نقطة المركز (x, y)، ونصف قطر، وزاوية البداية والنهاية (بالردايان)، ورايةً (flag) لتحدد اتجاه الدوران (false لاتجاه دوران عقارب الساعة، و true لعكس جهة دوران عقارب الساعة). يمكنك استخدام وحدة Math المبنية في لغة JavaScript لحساب الزوايا بالردايان. gDrawingContext.beginPath(); gDrawingContext.arc(x, y, radius, 0, Math.PI * 2, false); gDrawingContext.closePath(); انتظر برهة! لم يُرسَم شيء. الدالة arc()‎ تشبه عمل moveTo()‎ و lineTo()‎. حيث ترسم "بقلم الرصاص". ولرسم الدائرة فعليًا، علينا ضبط خاصية strokeStyle ثم استدعاء الدالة stroke()‎ "لتحبيرها". gDrawingContext.strokeStyle = "#000"; gDrawingContext.stroke(); ماذا لو كانت القطعة مُحدَّدةً؟ يمكننا إعادة استخدام نفس المسار الذي أنشأناه لرسم حدود القطعة لملئها بلونٍ معيّن. if (selected) { gDrawingContext.fillStyle = "#000"; gDrawingContext.fill(); } هذا كل ما في الأمر. تهتم بقية السكربت بالبنية المنطقية للعبة، مثل التفريق بين الحركات الصحيحة وغير الصحيحة، وإحصاء عدد الحركات، ومعرفة إذا انتهت اللعبة. مرحى! لقد أنشأنا لعبةً عبر عنصر canvas برسم 9 دوائر وبعض المستقيمات ودالة وحيدة مرتبطة بالحدث onclick. لمزيد من المعلومات حول عنصر canvas يمكنك الإطلاع على سلسلة التعامل مع العنصر canvas باستخدام جافاسكربت. ترجمة -وبتصرّف- لفصل "Canvas" من كتاب Dive Into HTML5 لمؤلفه Mark Pilgrim. اقرأ أيضًا المقال التالي: صيغ ترميز الفيديو والصوت وحاوياتها وكيفية عملها في الويب المقال السابق: اكتشاف دعم المتصفحات لميزات HTML5 النسخة العربية الكاملة من كتاب نحو فهم أعمق لتقنيات HTML5

بعد أن ازدادت السكربتات التي نكتبها تعقيدًا، فأحببت أن أشير إلى بعض الأخطاء الشائعة التي قد تصادفك أثناء مسيرتك. سنتعرض في هذا الدرس مثالًا ونعمل على تحليل الأخطاء التي قد نرتكبها، ولنسمِّ ذاك السكربت trouble.bash، تأكد من كتابة السكربت كما هو موجود حرفيًا. #!/bin/bash number=1 if [ $number = "1" ]; then echo "Number equals 1" else echo "Number does not equal 1" fi يجب أن يُخرِج السكربت السابق السطر "Number equals 1"، لأنَّ المتغير number يساوي 1، إن لم تحصل على المخرجات التي توقعتها، فتحقق من صحة كتابتك للسكربت، فربما ارتكبتَ خطأً… المتغيرات الفارغة عدِّل السطر الثالث من السكربت من: number=1 إلى: number= ثم شغِّل السكربت مرةً أخرى، وستحصل هذه المرة على المخرجات الآتية: $ ./trouble.bash /trouble.bash: [: =: unary operator expected. Number does not equal 1 كما لاحظت، عَرَضَت الصَدَفة bash رسالة خطأ عندما شغلنا السكربت، وربما ظننتَ أنَّ حذف القيمة "1" من السطر الثالث قد أدى إلى خطأٍ بنيوي (syntax error) لكن هذا ليس صحيحًا، ألقِ نظرةً إلى رسالة الخطأ مجددًا: ./trouble.bash: [: =: unary operator expected يمكننا ملاحظة أنَّ ‎./trouble.bash يُبلِّغ عن الخطأ، الذي يرتبط -بشكلٍ أو بآخر- مع ]؛ تذكَّر أنَّ ] هو اختصارٌ للأمر المُضمَّن في الصَدَفة test. ومن رسالة الخطأ السابقة استطعنا تحديد أنَّ الخطأ يحدث في السطر الخامس وليس الثالث. عليّ القول بادئ الأمر أنَّه لا توجد أيّة مشكلة في السطر الثالث، حيث number=‎ صحيحة بنيويًا؛ فقد ترغب في بعض الأحيان بحذف القيمة المُخزَّنة في متغيّر. يمكنك التحقق من سلامة هذه الصياغة بكتابتها وتجربتها في سطر الأوامر: $ number= $ أرأيت! لا توجد رسالة خطأ، لكن ما هو الشيء الخاطئ في السطر الخامس؟ لقد جربناه قبل تعديل السكربت ولم يكن يسبب أيّة مشاكل. لكي نفهم هذا الخطأ، علينا أن ننظر إلى الموضوع من وجهة نظر الصَدَفة. وَضَعَت الصَدَفة، في السطر الخامس، قيمة المتغير number عندما رأت ‎$number. ففي أول محاولة لتشغيل السكربت (أي عندما كان number=1)، بدَّلَت الصدفة المتغير ‎$number بالرقم 1 كما يلي: if [ 1 = "1" ]; then لكننا عندما أزلنا قيمة المتغير (number=‎)، فستحاول الصدفة تنفيذ ما يلي: if [ = "1" ]; then وهذا خطأ، ويُفسِّر أيضًا ما تبقى من رسالة الخطأ التي حصلنا عليها. المُعامِل = هو معامِل ثنائي، الذي يعني أنَّه يتوقع وجود عنصرين (كل عنصر على طرف). وما تحاول الصَدَفة إخبارنا به هو أنَّ هنالك عنصرٌ واحدٌ فقط، ولهذا يجب وضع معامل أحادي (مثل !) الذي يتطلب وجود عنصر وحيد فقط. علينا تعديل السطر الخامس إلى ما يلي لحل هذه المشكلة: if [ "$number" = "1" ]; then وسترى الصَدَفة ما يلي (إذا كانت قيمة number=‎): if [ "" = "1" ]; then وبهذا تجنبنا هذا الخطأ. تعلمنا من هذا الخطأ أمرًا مهمًا عند كتابة السكربتات: خذ بعين الاعتبار ماذا سيحدث لو كانت قيمة أحد المتغيرات فارغة. غياب إحدى علامات الاقتباس عدِّل السطر السادس وأزل علامة إغلاق الاقتباس من نهاية السطر: echo "Number equals 1 ثم شغِّل السكربت مرةً أخرى وستحصل على: $ ./trouble.bash ./trouble.bash: line 8: unexpected EOF while looking for matching " ./trouble.bash: line 10 syntax error: unexpected end of file هذه مشكلةٌ أخرى شائعةٌ تُسبِّب مشاكل في أماكن أخرى في السكربت. ماذا يحدث لو استمرت الصَدَفة بحثها عن علامة إغلاق الاقتباس لمعرفة نهاية سلسلةٍ نصيةٍ ما، لكنها وصلت إلى نهاية الملف ولم تجدها. يصعب كثيرًا اكتشاف هذا النوع من الأخطاء في السكربتات الطويلة؛ وهذا أحد الأسباب التي تدفعك لتجربة السكربتات بين الحين والآخر عندما تكتبها لوجود كمية قليلة من الشيفرات الجديدة التي عليك اختبارها. أرى أيضًا أنَّ استخدام المحررات النصيّة التي توفِّر تلوينًا للشيفرات يساعد كثيرًا في الكشف عن مثل هذه الأخطاء. عزل مكان المشكلة قد تكون عملية إيجاد الأخطاء والعِلل في برنامجك صعبة ومحبطة، هذه بعض التقنيات التي قد تستفيد منها: اعزل أجزاءً من الشيفرات بوضع علامة تعليق قبل الأسطر التي لا تريد أن تنفذها الصَدَفة. طبِّق هذا على كتلة من الشيفرات لكي ترى إن اختفت مشكلة معيّنة. وبهذه الآلية ستعرف ما هو الجزء الذي يسبب (أو لا يسبب) المشكلة. على سبيل المثال، لو عدنا إلى السكربت الذي فيه علامة اقتباس ناقصة، فيمكننا أن نعزل المشكلة كالآتي: #!/bin/bash number=1 if [ $number = "1" ]; then echo "Number equals 1 #else # echo "Number does not equal 1" fi سنعلم بعد وضع عبارة else في تعليق ثم تشغيل السكربت أنَّ المشكلة ليس في عبارة else حتى لو أشارت رسالة الخطأ إلى ذلك. استخدم الأمر echo للتحقق من القيم. فبعد أن تكتسب خبرة في تتبع العلل، ستكتشف أنَّ العلل ستتواجد في مكانٍ مختلف عن المكان الذي تتوقع وجودها فيه. إحدى المشاكل الشائعة هي افتراضك أنَّ التسلسل المنطقي لبرنامجك صحيحٌ تمامًا، وعندما ترى مشكلة في مرحلة ما في البرنامج فستفترض أنَّها موجودة هناك؛ وهذا خاطئ في معظم الحالات. يمكنك وضع أوامر echo في الشيفرة أثناء محاولة تنقيح (debugging) الأخطاء لكي تحصل على رسائل تؤكد لك أنَّ البرنامج يعمل كما تتوقع. هنالك نوعان من الرسائل التي عليك وضعها. الغرض من أول نوع هو الإعلان أنَّ التنفيذ قد وصل إلى مكان معيّن في البرنامج، ولقد رأينا ذلك سابقًا عند كتابتنا لشيفرات وهمية في الدوال التي أضفناها. وهذا مفيد لكي تعلم أنَّ مسار تنفيذ البرنامج مماثل تمامًا لما نتوقعه. النوع الثاني يعرض قيم المتغيرات المستخدمة في الحسابات أو الاختبارات. قد تجد في بعض الأحيان قسمًا من السكربت لا يُنفَّذ تنفيذًا سليمًا لأنك افترضت أنَّ شيئًا ما في ما سبقه من الشيفرات صحيحٌ؛ إلا أنَّ فيه مشكلةً تؤدي إلى فشل تنفيذ ما يليه من الشيفرات. مراقبة تشغيل السكربت من الممكن أنَّ تعرض لك bash ما الذي يحدث عندما تُشغِّل السكربت. وذلك بإضافة الخيار ‎-x في أول سطر من السكربت كما يلي: #!/bin/bash -x وعندما ستُشغِّل السكربت، فستعرض bash كل سطر ستحاول تنفيذه (بعد تعويض قيم المتغيرات…). تُسمى هذه التقنية بالتتبع (tracing)، وهذا مثالٌ عنها: $ ./trouble.bash + number=1 + '[' 1 = 1 ']' + echo 'Number equals 1' Number equals 1 تستطيع أيضًا أن تستعمل الأمر set داخل السكربت لتفعيل أو تعطيل التتبع. استخدم set -x لتشغيل التتبع و set +x لتعطيل التتبع، مثال: #!/bin/bash number=1 set -x if [ $number = "1" ]; then echo "Number equals 1" else echo "Number does not equal 1" fi set +x ترجمة -وبتصرّف- للمقال Stay Out Of Trouble لصاحبه William Shotts.

ربما تتساءل: "كيف أستطيع البدء باستخدام HTML5 إن لم تكن تدعمها المتصفحات القديمة؟" لكن السؤال نفسه مُضلِّل، فليست HTML5 شيئًا واحدًا كبيرًا، وإنما هي مجموعة من الميزات المتفرقة، فلا يمكنك الكشف عن "دعم HTML5" لأن هذا غير منطقي، وإنما يمكنك الكشف عن دعم الميزات المتفرقة مثل canvas أو تشغيل الفيديو أو تحديد الموقع الجغرافي. تقنيات الاكتشاف عندما يُحمِّل متصفحك صفحة ويب، فإنه يُنشِئ ما نسميه "Document Object Model" (اختصارًا DOM)، الذي هو مجموعة من الكائنات التي تُمثِّل عناصر HTML الموجودة في الصفحة، فكل عنصر -كل وسم <p> أو <div> أو <span>- يُمثَّل في DOM بكائن مختلف (هنالك كائنات عامة مثل window و document، التي لا ترتبط بعناصر محددة). تتشارك جميع كائنات DOM بمجموعةٍ من الخاصيات المشتركة، لكن لبعض الكائنات خاصيات أكثر من بعضها الآخر. ويكون لدى بعض الكائنات خاصيات فريدة في المتصفحات التي تدعم ميزات HTML5؛ لذلك يكون من الكافي عادةً إلقاء نظرة على DOM لتعرف ما هي الميزات المدعومة. هنالك أربع تقنيات أساسية لاكتشاف دعم المتصفح لميزة مُحدَّدة، هذه هي بالترتيب من الأبسط إلى الأكثر تعقيدًا: التحقق من وجود خاصية معينة في كائن عام (مثل window أو navigator)، مثلما هو عليه الحال مع دعم تحديد الموقع الجغرافي. إنشاء عنصر، ثم التحقق من وجود خاصية معيّنة في ذاك العنصر، مثلما هو عليه الحال مع تحديد دعم canvas. إنشاء عنصر، ثم التحقق من وجود دالة (method) معينة في ذاك العنصر، ثم استدعاء تلك الدالة والتحقق من القيمة التي تُعيدها. مثلما هو عليه الحال مع معرفة صيغ الفيديو المدعومة. إنشاء عنصر، وضبط خاصية فيه إلى قيمةٍ معيّنة، ثم التحقق من أنَّ تلك الخاصية قد احتفظت بقيمتها. مثل ما هو عليه الحال مع معرفة أنواع حقول <input> المدعومة. Modernizr: مكتبة اكتشاف دعم ميزات HTML5 Modernizr هي مكتبة JavaScript مفتوحة المصدر مُرخَّصة برخصة MIT مهمتها اكتشاف الدعم للعديد من ميزات HTML5 و CSS3، وأنصحك باستعمال آخر إصدار منها دومًا. عليك -لاستعمالها- تضمينها عبر عنصر <script> في ترويسة (header) صفحتك كما يلي: <!DOCTYPE html> <html> <head> <meta charset="utf-8"> <title>Dive Into HTML5</title> <script src="modernizr.min.js"></script> </head> <body> ... </body> </html> سيعمل Modernizr تلقائيًا، فلا توجد هنالك دالة modernizr_init()‎ لكي تستدعيها. فعندما يُشغَّل السكربت، فإنه يُنشِئ كائنًا عامًا اسمه Modernizr يحتوي على مجموعة من الخاصيات المنطقية (أي True أو False) لكل خاصية يمكنه الكشف عن دعمها. فعلى سبيل المثال، إن كان متصفحك يدعم استخدام canvas، فإن قيمة الخاصية Modernizr.canvas ستكون True، وإن لم يكن متصفحك يدعمها، فستكون قيمة الخاصية Modernizr.canvas مساويةً إلى False. if (Modernizr.canvas) { // لنرسم بعض الأشكال } else { // لا يوجد دعم لخاصية canvas } الكشف عن دعم Canvas تُعرِّف HTML العنصر <canvas> على أنه "لوحة نقطية ذات أبعاد معينة يمكن استخدامها لعرض المخططات ورسومات الألعاب وغيرها من الصور المرئية برمجيًا". ويُمثِّل مستطيلًا في صفحتك حيث تستخدم JavaScript لرسم أي شيء تريده فيه، وتُعرِّف HTML5 مجموعةً من الدوال (تدعى "canvas API") لرسم الأشكال (shapes) وتعريف المسارات (paths) وإنشاء التدرجات اللونية وتطبيقات التحويلات (transformations) على العناصر. سنستخدم تقنية الكشف عن الدعم الثانية للتحقق من دعم المتصفح للعنصر canvas، فإن دعم متصفحك واجهة canvas البرمجية (API) فهذا يعني أن الكائن في DOM الذي يُمثِّل عنصر <canvas> سيملك الدالة getContext()‎، وإن لم يكن يدعم متصفحك واجهة canvas البرمجية، فسيملك الكائن المُنشَأ لعنصر <canvas> الخاصيات العامة لكل العناصر، وليس من بينها أي شيءٍ متعلقٍ بتقنية canvas. function supports_canvas() { return !!document.createElement('canvas').getContext; } تبدأ هذه الدالة عملها بإنشاء عنصر <canvas> لا حول له ولا قوة، لكن ذاك العنصر لن يرتبط مطلقًا بصفحتك، ولن يراه أحد، وإنما سيبقى عائمًا بالذاكرة دون أن يفعل شيئًا. return !!document.createElement('canvas').getContext; وبعد إنشاء عنصر <canvas>، ستختبر وجود الدالة getContext()‎، فستكون هذه الدالة موجودةً إذا كان المتصفح يدعم واجهة canvas البرمجية. return !!document.createElement('canvas').getContext; وفي النهاية، استعملنا علامة النفي المزدوجة (!!) كي تكون النتيجة قيمةً منطقية (أي true أو false). return !!document.createElement('canvas').getContext; تكتشف هذه الدالة الدعم لأغلبية مكونات واجهة canvas البرمجية، بما في ذلك الأشكال، والمسارات، والتدرجات اللونية والأنماط. لكنها لا تكتشف وجود المكتبة الخارجية explorercanvas التي تسمح باستخدام واجهة canvas البرمجية في متصفح Internet Explorer. وبدلًا من كتابة الدالة السابقة بنفسك، تستطيع استعمال Modernizr للكشف عن دعم واجهة canvas البرمجية. if (Modernizr.canvas) { // لنرسم بعض الأشكال } else { // لا يوجد دعم لخاصية canvas :( } هنالك اختبارٌ منفصلٌ للتحقق من دعم واجهة canvas text البرمجية، وذلك في الفقرة الآتية. الكشف عن دعم النصوص في عنصر Canvas حتى لو كان يدعم متصفحك واجهة canvas البرمجية، فقد لا يدعم واجهة canvas text البرمجية، فنَمَتْ واجهة canvas البرمجية على مر الزمن، وأُضيفت دوال النصوص في فترةٍ لاحقة، لهذا هنالك بعض المتصفحات التي تدعم canvas لكن قبل أن يكتمل العمل على دوال النصوص. سنستخدم تقنية الكشف عن الدعم الثانية للتحقق من دعم المتصفح للعنصر canvas، فإن دعم متصفحك واجهة canvas البرمجية (API) فهذا يعني أن الكائن في DOM الذي يُمثِّل عنصر <canvas> سيملك الدالة getContext()‎، وإن لم يكن يدعم متصفحك واجهة canvas البرمجية، فسيملك الكائن المُنشَأ لعنصر <canvas> الخاصيات العامة لكل العناصر، وليس من بينها أي شيءٍ متعلقٍ بتقنية canvas. function supports_canvas_text() { if (!supports_canvas()) { return false; } var dummy_canvas = document.createElement('canvas'); var context = dummy_canvas.getContext('2d'); return typeof context.fillText == 'function'; } تبدأ الدالة السابقة بالتحقق من دعم canvas باستخدام دالة supports_canvas()‎ التي رأيتها في القسم السابق، فإن لم يكن يدعم متصفحك واجهة canvas البرمجية، فهو بالتأكيد لن يدعم إضافة النصوص إلى عناصر canvas. if (!supports_canvas()) { return false; } ثم ستُنشِئ عنصر <canvas> جديد ثم تحاول الوصول إلى "لوحة الرسم" (drawing context)، ومن المؤكد أن ما سبق سيعمل دون مشاكل لأن الدالة supports_canvas()‎ قد تحققت من وجود الدالة getContext()‎ في جميع عناصر canvas. var dummy_canvas = document.createElement('canvas'); var context = dummy_canvas.getContext('2d'); وفي النهاية، ستتحقق إن كان لدى لوحة الرسم الدالة fillText()‎، فإن كانت تملكها، فهنالك دعمٌ للنصوص في canvas. return typeof context.fillText == 'function'; وبدلًا من كتابة الدالة السابقة بنفسك، تستطيع استعمال Modernizr للكشف عن دعم واجهة canvas text البرمجية. if (Modernizr.canvastext) { // لنضع بعض النصوص } else { // لا يوجد دعم لخاصية canvas text } الكشف عن دعم الفيديو أضافت HTML5 عنصرًا جديدًا هو <video> لتضمين مقاطع الفيديو في صفحات الويب، كان تضمين الفيديو في السابق من المستحيلات دون استخدام إضافات خارجية مثل Apple QuickTime®‎ أو Adobe Flash®‎. صُمِّمَ عنصر <video> ليُستعمَل دون الحاجة إلى أيّة سكربتات للكشف عن الدعم، فيمكنك تحديد عدِّة مسارات لمقاطع الفيديو، وستختار المتصفحات التي تدعم HTML5 video أحدها بناءً على الصيغ التي تدعمها. المتصفحات التي لا تدعم HTML5 video ستتجاهل وسم <video> تمامًا. لكنك تستطيع استخدام ذلك لصالحك بإخبارها أن تُشغِّل المقطع باستخدام إضافة خارجية. برمَج Kroc Camen حلًا اسمه Video for Everybody!‎ الذي يستخدم دعم الفيديو في HTML5 عند توفره، لكنه سيعود إلى استخدام QuickTime أو Flash في المتصفحات القديمة. لا يستعمل هذا الحل JavaScript مطلقًا، ويعمل نظريًا على أي متصفح، بما في ذلك متصفحات الهواتف المحمولة. إذا أردت القيام بأكثر من مجرد وضع الفيديو في صفحتك وتشغيله، فستحتاج إلى استخدام JavaScript، نستخدم التقنية الثانية للتحقق من دعم الفيديو. فإذا كان متصفحك يدعم HTML5 video، فإن كائن DOM الذي سيُنشئه المتصفح لتمثيل عنصر <video> سيملك الخاصية canPlayType()‎. وإن لم يكن يدعم متصفحك HTML5 video، فإن كائن DOM المُنشَأ لعنصر <video> سيملك الخاصيات العامة لأي عنصر. يمكنك التحقق من دعم الفيديو عبر هذه الدالة: function supports_video() { return !!document.createElement('video').canPlayType; } وبدلًا من كتابة الدالة السابقة بنفسك، تستطيع استعمال Modernizr للكشف عن دعم HTML5 video. if (Modernizr.video) { // لنشغل مقاطع الفيديو } else { // لا يوجد دعم للفيديو :( // ربما علينا استخدام QuickTime أو Flash بدلًا منه } سأشرح -في الدرس الخاص بالفيديو- حلًا آخر يستعمل تقنيات الكشف السابقة لتحويل عناصر <video> إلى مشغلات فيديو مبنية على تقنية Flash، وذلك لتشغيل الفيديو على المتصفحات التي لا تدعم HTML5 video. هنالك اختبارٌ منفصلٌ للتحقق من صيغ الفيديو التي يمكن للمتصفح تشغيلها، مشروحٌ في الفقرة الآتية. صيغ الفيديو مَثَلُ صيغ الفيديو كمَثَلِ اللغات المكتوبة، فقد تحتوي صحيفة إنكليزية على نفس المعلومات التي تحتويها صحيفة عربية، لكن إن كنت تقرأ اللغة العربية فقط، فستكون إحدى تلك الصحيفتين مفيدةً لك. ولتشغيل مقطع فيديو، يجب أن يفهم المتصفح "اللغة" التي كُتِبَ فيها هذا المقطع. تسمى "اللغة" التي تكتب فيها مقاطع الفيديو "بالمرماز" (codec) الذي هو الخوارزمية المستخدمة لترميز (encode) مقطع الفيديو إلى سلسلة من البتات، وهنالك عدِّة مرمزات، لكن أيها تستعمل؟ في الواقع، من المؤسف أن المتصفحات لم تتوافق على مرماز معيّن، لكنهم قللوا الخيارات إلى خيارين فقط. أحدهما يكلف مالًا (بسبب براءة الاختراع)، لكنه يعمل في متصفح Safari وفي iPhone (وهو يعمل أيضًا في مشغلات Flash إن كنت ستستعمل حلًا مثل Video for Everybody!‎). أما المزمار الآخر فهو مجاني ويعمل على المتصفحات مفتوحة المصدر مثل Chromium و Firefox. نستخدم التقنية الثالثة لمعرفة صيغ الفيديو المدعومة. وإذا كان متصفحك يدعم HTML5 video، فإن كائن DOM الذي سيُنشئه المتصفح لتمثيل عنصر <video> سيملك الخاصية canPlayType()‎. ستخبرك الطريقة الآتية إن كان متصفحك يدعم صيغة فيديو معينة. تتحقق هذه الدالة من دعم الصيغة المحمية بحقوق براءة الاختراع والمدعومة من أجهزة Mac و iPhone. function supports_h264_baseline_video() { if (!supports_video()) { return false; } var v = document.createElement("video"); return v.canPlayType('video/mp4; codecs="avc1.42E01E, mp4a.40.2"'); } تبدأ هذه الدالة بالتحقق من دعم HTML video في المتصفح، وذلك باستخدام الدالة supports_video()‎ التي رأيتها في القسم السابق. فإن لم يكن يدعم متصفحك HTML5 video، فهو بالتأكيد لن يدعم أيّة صيغة من صيغ الفيديو. if (!supports_video()) { return false; } ثم ستُنشِئ الدالة عنصر <video> (لكن دون أن تضيفه إلى الصفحة، أي أنه لن يكون مرئيًا) وتستدعي الدالة canPlayType()‎، من المؤكد وجود هذه الدالة لأن الدالة supports_video()‎ تحققت منها في الخطوة السابقة. var v = document.createElement("video"); في الواقع، "صيغة الفيديو" هي مجموعة من عدِّة أشياء، فبكلامٍ تقني، أنت تسأل المتصفح إن كان يستطيع تشغيل فيديو H.264 بنمط Baseline مع صوت AAC LC في حاوية MPEG-4. return v.canPlayType('video/mp4; codecs="avc1.42E01E, mp4a.40.2"'); لن تُعيد الدالة canPlayType()‎ القيمة true أو false، وإنما ستعيد سلسلة نصية آخذةً بعين الاعتبار الطبيعة المُعقَّدة لصيغ الفيديو: "probably" إن كان المتصفح واثقًا أنه يستطيع تشغيل هذه الصيغة "maybe" إن ظن المتصفح أنه يستطيع تشغيل هذه الصيغة "" (سلسلة نصية فارغة) إن كان المتصفح متأكدًا أنه لن يستطيع تشغيل هذه الصيغة أما الدالة الآتية فهي تتحقق من دعم صيغة الفيديو المفتوحة المدعومة من متصفح Firefox وغيره من المتصفحات مفتوحة المصدر. العملية مماثلة تمامًا لما سبق، لكن الاختلاف الوحيد هو في السلسلة النصية التي تمررها إلى الدالة canPlayType()‎. تقنيًا، أنت تسأل المتصفح إن كان قادرًا على تشغيل فيديو Theora مع صوت Vorbis في حاوية Ogg. function supports_ogg_theora_video() { if (!supports_video()) { return false; } var v = document.createElement("video"); return v.canPlayType('video/ogg; codecs="theora, vorbis"'); } في النهاية، WebM هو مرماز فيديو جديد ومفتوح المصدر (وغير محمي ببراءة اختراع) تم دعمه في الإصدارات الجديدة من المتصفحات الحديثة، بما في ذلك Chrome، و Firefox، و Opera. ويمكنك استخدام نفس التقنية السابقة لاكتشاف دعم صيغة WebM. function supports_webm_video() { if (!supports_video()) { return false; } var v = document.createElement("video"); return v.canPlayType('video/webm; codecs="vp8, vorbis"'); } بدلًا من كتابة هذه الدالة بنفسك، يمكنك استعمال Modernizr (الإصدار 1.5 أو ما بعده) لاكتشاف الدعم لمختلف صيغ الفيديو في HTML5. if (Modernizr.video) { // لنشغل مقاطع الفيديو! لكن ما صيغتها؟ if (Modernizr.video.webm) { // لنجرب WebM } else if (Modernizr.video.ogg) { // لنجرب Ogg Theora + Vorbis في حاوية Ogg } else if (Modernizr.video.h264){ // لنجرب H.264 video + AAC audio في حاوية MP4 } } التخزين المحلي Local Storage يوفر التخزين المحلي لمواقع الويب طريقةً لتخزين المعلومات على حاسوبك ثم استعادتها لاحقًا، مفهومها مشابه لمفهوم "الكعكات" (cookies)، لكنها مصممة لكمية معلومات أكبر، فالكعكات محدودة الحجم، ويرسلها المتصفح إلى خادوم الويب في كل مرة يطلب فيها صفحة جديدة (مما يأخذ وقتًا أطول ويستهلك بيانات التراسل). أما تخزين HTML5 فهو يبقى في حاسوبك، وتستطيع مواقع الويب الوصول إليه عبر JavaScript بعد أن يتم تحميل الصفحة. س: هل التخزين المحلي هو جزءٌ من HTML5؟ ولماذا وضعوه في معيار منفصل؟ ج: الجواب المختصر هو "نعم"، التخزين المحلي هو جزءٌ من HTML5. أما الجواب الأطول فهو أن التخزين المحلي كان جزءًا من معيار HTML5 الرئيسي، لكنه أصبح معيارًا منفصلًا بسبب شكوى بعض الأشخاص في مجموعة عمل HTML5 أن HTML5 أصبحت كبيرة جدًا. حتى لو كان ذلك يشبه تقسيم شطيرة إلى قطع صغيرة لتقليل كمية الحريرات :-| حسنًا، أهلًا بك في العالم العجيب للمعايير القياسية. سنستخدم تقنية الكشف الأولى للتحقق من دعم المتصفح للتخزين المحلي، فإن دَعَم متصفحك التخزين المحلي، فستكون هنالك خاصية localStorage في كائن window العام. وإن لم يكن يدعم متصفحك التخزين المحلي، فلن تكون الخاصية localStorage معرَّفةً. وبسبب علِّة في الإصدارات القديمة من Firefox، سيسبب هذا الخيار بحدوث استثناء (exception) إن كانت الكعكات (cookies) مُعطَّلةً، لذلك وضعنا الاختبار في عبارة try..catch. function supports_local_storage() { try { return 'localStorage' in window && window['localStorage'] !== null; } catch(e){ return false; } } بدلًا من كتابة هذه الدالة بنفسك، يمكنك استعمال Modernizr (الإصدار 1.1 أو ما بعده) لاكتشاف الدعم للتخزين المحلي. if (Modernizr.localstorage) { // متوفرة! window.localStorage } else { // لا يوجد دعم للتخزين المحلي // ربما تجرب Gears أو مكتبة أخرى } لاحظ أنَّ JavaScript حساسة لحالة الأحرف، إذ تُدعى خاصية Modernizr ‏"localstorage" (جميعها بأحرفٍ صغيرة)، أما خاصية DOM فهي window.localStorage (حرف S كبير). س: ما مدى أمان قاعدة بيانات التخزين المحلي في HTML5؟ هل يستطيع أحدٌ قراءتها؟ ج: أي شخص لديه وصولٌ فيزيائيٌ لحاسوبك قد يستطيع عرض (أو حتى تعديل) البيانات الموجودة في قاعدة بيانات التخزين المحلي في HTML5. ويستطيع أي موقع ويب قراءة وتخزين القيم الخاصة به، لكن لا يستطيع الوصول إلى القيم التي خزنتها المواقع الأخرى، وهذا يسمى same-origin restriction. Web Workers توفر ميزة Web Workers طريقةً قياسيةً لتشغيل JavaScript في الخلفية، إذ تستطيع تشغيل عدِّة "خيوط" (threads) التي تعمل في نفس الوقت تقريبًا (تذكر طريقة تشغيل الحاسوب لعدِّة تطبيقات معًا في آنٍ واحد)، تستطيع تلك الخيوط التي تعمل في الخلفية أن تجري عمليات حسابية معقدة، أو أن تجري طلبيات شبكيّة، أو أن تصل إلى التخزين المحلي في أثناء استجابة صفحة الويب إلى تفاعل المستخدم معها. نستعمل طريقة الاكتشاف الأولى لمعرفة إن كان المتصفح يدعم واجهة Web Worker البرمجية، وذلك إن وُجِدَت الخاصية Worker في الكائن العام window، وإن لم يكن يدعم متصفحك واجهة Web Worker البرمجية، فستكون خاصية Worker غير معرفة. function supports_web_workers() { return !!window.Worker; } بدلًا من كتابة هذه الدالة بنفسك، يمكنك استعمال Modernizr (الإصدار 1.1 أو ما بعده) لاكتشاف الدعم لواجهة Web Workers البرمجية. if (Modernizr.webworkers) { // window.Worker متوفرة! } else { // لا يوجد دعم لواجهة Web Workers :( // ربما تجرب Gears أو مكتبة أخرى } لاحظ أنَّ JavaScript حساسة لحالة الأحرف، إذ تُدعى خاصية Modernizr ‏"webworkers" (جميعها بأحرفٍ صغيرة)، أما خاصية DOM فهي window.Worker (حرف W كبير في Worker). تطبيقات الويب دون اتصال Offline Web Applications يمكن ببساطة قراءة صفحات الويب الثابتة دون اتصال: اتصل إلى الإنترنت، حمِّل صفحة الويب، اقطع اتصالك بالإنترنت، ثم سافر إلى بلدٍ آخر، واقرأ الصفحة في وقت فراغك (يمكنك تخطي خطوة السفر إلى بلدٍ آخر لتوفير الوقت). لكن ماذا عن تطبيقات الويب مثل Gmail أو Google Docs؟ الفضل يعود إلى HTML5، التي تُمكِّن الجميع (وليس فقط Google) من بناء تطبيقات ويب تعمل دون اتصال. تبدأ تطبيقات الويب التي تعمل دون اتصال كتطبيقات تعمل بوجود اتصال بالإنترنت، ففي أول مرة تزور فيها تطبيق ويب يدعم العمل دون اتصل، فسيخبر الخادومُ متصفحَك ما هي الملفات التي يحتاج لها كي يعمل دون اتصال. قد تكون هذه الملفات من أي نوع: صفحات HTML، أو JavaScript، أو الصور أو حتى مقاطع الفيديو. وبعد أن ينزِّل متصفحك كل الملفات الضرورية، ستستطيع إعادة زيادة موقع الويب حتى لو لم تكن متصلًا بالإنترنت، وسيلاحظ متصفحك أنَّك غير متصل وسيستعمل الملفات التي نزلها من قبل. وعندما تتصل مجددًا بالإنترنت، فيمكن رفع أيّة تعديلات أجريتها على خادم الويب البعيد. نستعمل طريقة الاكتشاف الأولى لمعرفة إن كان المتصفح يدعم تشغيل تطبيقات الويب دون اتصال، وذلك إن وُجِدَت الخاصية applicationCache في الكائن العام window، وإن لم يكن يدعم متصفحك تشغيل تطبيقات الويب دون اتصال، فستكون خاصية applicationCache غير معرفة؛ يمكنك التحقق من دعم تشغيل تطبيقات الويب دون اتصال مع هذه الدالة: function supports_offline() { return !!window.applicationCache; } بدلًا من كتابة هذه الدالة بنفسك، يمكنك استعمال Modernizr (الإصدار 1.1 أو ما بعده) لاكتشاف الدعم لتشغيل تطبيقات الويب دون اتصال. if (Modernizr.applicationcache) { // window.applicationCache متوفرة! } else { // لا يوجد دعم للتطبيقات دون اتصال :( // ربما تجرب Gears أو مكتبة أخرى } لاحظ أنَّ JavaScript حساسة لحالة الأحرف، إذ تُدعى خاصية Modernizr ‏"applicationcache" (جميعها بأحرفٍ صغيرة)، أما خاصية DOM فهي window.applicationCache (حرف c كبير في Cache). تحديد الموقع الجغرافي Geolocation يفيد تحديد الموقع الجغرافي في معرفة أين أنت في هذا الكوكب و (اختياريًا) مشاركة تلك المعلومات مع الأشخاص الذين تثق بهم، هنالك أكثر من طريقة لمعرفة أين أنت: عبر عنوان IP، أو عبر اتصال شبكتك اللاسلكية، أو أيّ برج تغطية خلوية تتصل منه، أو عبر عتاد GPS الذي يحسب إحداثيات موقعك الحالي عبر المعلومات التي ترسلها الأقمار الاصطناعية في السماء. س: هل تحديد الموقع الجغرافي جزءٌ من HTML5؟ ولماذا تتحدث عنه إذًا؟ ج: لقد أضيف دعم تحديد الموقع الجغرافي من المتصفحات مع ميزات HTML5 الجديدة. لكن إذا ابتغينا الدقة، يُوفَّر معيار تحديد الموقع الجغرافي من مجموعة عمل Geolocation، التي هي مجموعة عمل منفصلة عن مجموعة عمل HTML5، لكننا سنتحدث عن تحديد الموقع الجغرافي في هذه السلسلة على أيّة حال، لأنه جزءٌ من التطوير الذي يحدث في الويب في الوقت الراهن. نستعمل طريقة الاكتشاف الأولى لمعرفة إن كان المتصفح يدعم واجهة تحديد الموقع الجغرافي البرمجية، وذلك إن وُجِدَت الخاصية geolocation في الكائن العام navigator، وإن لم يكن يدعم متصفحك تحديد الموقع الجغرافي، فستكون خاصية geolocation غير معرفة؛ يمكنك التحقق من دعم تحديد الموقع الجغرافي مع هذه الدالة: function supports_geolocation() { return !!navigator.geolocation; } بدلًا من كتابة هذه الدالة بنفسك، يمكنك استعمال Modernizr لاكتشاف الدعم لتحديد الموقع الجغرافي. if (Modernizr.geolocation) { // لنكتشف أين أنت الآن! } else { // لا يوجد دعم لتحديد الموقع الجغرافي :( // ربما تجرب Gears أو مكتبة أخرى } إن لم يدعم متصفحك واجهة تحديد الموقع الجغرافي البرمجية داخليًا، فلا تيأس. فهنالك Gears التي هي إضافة مفتوحة المصدر للمتصفحات من Google التي تعمل على ويندوز و Mac OS X ولينُكس والهواتف العاملة بنظامَي ويندوز وأندرويد. حيث توفر ميزاتٍ للمتصفحات القديمة التي لا تدعم الأشياء الجديدة التي تحدثنا عنها في هذا الدرس. إحدى الميزات التي توفرها Gears هي تحديد الموقع الجغرافي، لكنها ليست مطابقة لواجهة navigator.geolocation البرمجية، لكنها تخدم نفس الغرض. هنالك واجهات برمجية لتحديد المواقع لأنظمة الهواتف القديمة مثل BlackBerry، و Nokia، و Palm، و OMTP BONDI. سيشرح الدرس الخاص بتحديد الموقع الجغرافي بالتفصيل كيفية استخدام مختلف الواجهات البرمجية السابقة. أنواع الإدخال في النماذج Input Types أنت تعرف الكثير عن نماذج الويب، صحيح؟ أنشِئ عنصر <form> ثم أضف بعض عناصر <input type="text"‎> إليه وربما عنصر <input type="password"‎>، ثم أنهِ النموذج بزر <input type="submit"‎>. حسنًا، ذلك جزءٌ يسيرٌ من النماذج، إذ أضافت HTML5 حوالي ثلاثة عشر نوعًا من أنواع المدخلات التي يمكنك استعمالها في نماذجك. <"input type="search"> لصناديق البحث <"input type="number"> لإدخال الأرقام <"input type="range"> للمزلاج (slider) لتحديد مجال <"input type="color"> لاختيار الألوان <"input type="tel"> لأرقام الهواتف <"input type="url"> لعناوين الويب <"input type="email"> لعناوين البريد الإلكتروني <"input type="date"> التقويم لاختيار التاريخ <"input type="month"> للأشهر <"input type="week"> للأسابيع <"input type="time"> لبصمات الوقت <"input type="datetime"> لبصمات الوقت والتاريخ بدقة <"input type="datetime-locale"> للوقت والتاريخ المحليين سنستخدم التقنية الرابعة لاكتشاف أنواع الحقول المدعومة في النماذج. في البداية سننشِئ عنصر <input> في الذاكرة، وسيكون نوع الحقل الافتراضي لجميع عناصر <input> هو "text"، وسيتضح لك لماذا هذا مهمٌ جدًا. var i = document.createElement("input"); ثم سنضبط خاصية type في عنصر <input> إلى نوع حقل الإدخال الذي تريد معرفة إن كان مدعومًا أم لا. i.setAttribute("type", "color"); إن كان يدعم متصفحك نوع حقل الإدخال المعين، فستحتفظ خاصية type بالقيمة التي ضبطتها، أما إن لم يكن يدعم متصفحك نوع الحقل المعيّن، فسيتجاهل القيمة التي ضبطتها وستبقى قيمة الخاصية type مساويةً إلى "text". return i.type !== "text" بدلًا من كتابة 13 دالة منفصلة يدويًا، تستطيع استخدام Modernizr لاكتشاف الدعم لجميع أنواع حقول الإدخال المُعرَّفة في HTML5. يُعيد Modernizr استخدام عنصر <input> وحيد لكي يكتشف ما هي أنواع حقول الإدخال المدعومة. ثم يبني جدولًا من نوع hash باسم Modernizr.inputtypes يحتوي على 13 مفتاح (خاصيات type في HTML5) و 13 قيمة منطقية (أي true إن كان الحقل مدعومًا، أو false إن لم يكن كذلك). if (!Modernizr.inputtypes.date) { // لا يوجد دعم لحقل <input type="date"‎> :( // ربما تستعمل مكتبة Dojo أو jQueryUI } النص البديل Placeholder بالإضافة إلى أنواع حقول الإدخال الجديدة، تضمنت HTML5 بعض الإضافات الصغيرة للنماذج. أحدها هو إمكانية وضع نص بديل (placeholder) في حقل الإدخال. يُعرَض النص البديل في حقل الإدخال لطالما كان الحقل فارغًا، وبمجرد أن تكتب شيئًا في الحقل، فسيختفي ذاك النص البديل. هنالك لقطات للشاشة في درس نماذج الويب يمكنك النظر إليها إن واجهت صعوبةً في تخيله. سنستخدم تقنية الكشف عن الدعم الثانية للتحقق من دعم المتصفح للنص البديل في حقول الإدخال، فإن دعم متصفحك النص البديل فهذا يعني أن الكائن في DOM الذي يُمثِّل عنصر <input> سيملك الخاصية placeholder (حتى لو لم تضع خاصية placeholder في شيفرة HTML)، وإن لم يكن يدعم متصفحك النص البديل، فلن يملك الكائن المُنشَأ لعنصر <input> الخاصية placeholder. function supports_input_placeholder() { var i = document.createElement('input'); return 'placeholder' in i; } بدلًا من كتابة هذه الدالة بنفسك، يمكنك استعمال Modernizr (الإصدار 1.1 أو ما بعده) لاكتشاف الدعم للنص البديل في حقول الإدخال. if (Modernizr.input.placeholder) { // يمكنك استعمال النص البديل في حقول الإدخال! } else { // لا يوجد دعم للنص البديل :( // استعمل سكربت لفعل ذلك } التركيز التلقائي على النماذج autofocus تستعمل مواقع الويب JavaScript للتركيز (focus) على حقل من حقول الإدخال في نماذج الويب. على سبيل المثال، الصفحة الرئيسية لمحرك البحث Google ستُركِّز تلقائيًا على حقل البحث كي تستطيع كتابة ما الذي تريد البحث عنه مباشرةً دون الحاجة إلى النقر على حقل الإدخال، ربما هذا ملائم للكثيرين، لكنه مزعج للمستخدمين المتقدمين أو لأولي الاحتياجات الخاصة، فإن ضغطت على زر المسافة (space) متوقعًا أن تُمرِّر إلى الأسفل، فلن يتم ذلك، لوجود المؤشر في حقل إدخال (وستُكتب مسافة فارغة في حقل الإدخال بدلًا من التمرير)، وإن ركزت على حقل إدخال مختلف في أثناء تحميل الصفحة، فسيحرك سكربت التركيز التلقائي التركيز إلى الحقل المُحدَّد بعد إكمال تحميل الصفحة، مما يؤدي إلى كتابتك في المكان الخاطئ. ولأن التركيز التلقائي كان يتم عبر JavaScript، فمن الصعب التعامل مع جميع الحالات الغريبة، وليس هنالك ملجأ من التركيز التلقائي للحقول لِمَن لا يريد ذلك! ولحل هذه المشكلة، قدَّمَت HTML5 خاصية autofocus في جميع عناصر نماذج الويب. وهذه الخاصية تفعل تمامًا كما هو واضح من اسمها: تنقل التركيز إلى حقل إدخال معين، ولأنها من شيفرة HTML بدلًا من كونها سكربت، فإن سلوكها سيكون متناغمًا ومتماثلًا في كل مواقع الويب، ويمكن لصانعي المتصفحات (أو مطوري الإضافات) توفير طريقة للمستخدمين لكي يُعطِّلوا إمكانية التركيز التلقائي. سنستخدم تقنية الكشف عن الدعم الثانية للتحقق من دعم المتصفح للتركيز التلقائي في حقول الإدخال، فإن دعم متصفحك التركيز التلقائي فهذا يعني أن الكائن في DOM الذي يُمثِّل عنصر <input> سيملك الخاصية autofocus (حتى لو لم تضع خاصية autofocus في شيفرة HTML)، وإن لم يكن يدعم متصفحك التركيز التلقائي، فلن يملك الكائن المُنشَأ لعنصر <input> الخاصية autofocus. يمكنك اكتشاف دعم التركيز التلقائي عبر هذه الدالة: function supports_input_autofocus() { var i = document.createElement('input'); return 'autofocus' in i; } بدلًا من كتابة هذه الدالة بنفسك، يمكنك استعمال Modernizr (الإصدار 1.1 أو ما بعده) لاكتشاف الدعم للتركيز التلقائي في حقول الإدخال. if (Modernizr.input.autofocus) { // التركيز التلقائي يعمل! } else { // التركيز التلقائي غير مدعوم :( // استعمل سكربت لفعل ذلك } البيانات الوصفية Microdata البيانات الوصفية (Microdata) هي الطريقة القياسية لتوفير هيكليّة معنوية لصفحات الويب. على سبيل المثال، يمكنك استعمال البيانات الوصفية لتصرِّح أن صورةً ما مرخَّصة بإحدى رخص المشاع الإبداعي. وكما سترى لاحقًا في هذه السلسلة، يمكنك استعمال البيانات الوصفية لتوصيف صفحة "معلومات عني"، فيمكن للمتصفحات –أو لإضافات المتصفحات– أو لمحركات البحث تحويل تلك البيانات الوصفية إلى vCard، التي هي صيغة معيارية لمشاركة معلومات الاتصال؛ يمكنك أيضًا تعريف أنواع خاصة بك من البيانات الوصفية. معيار البيانات الوصفية في HTML5 يتضمن شيفرات HTML (تستعملها محركات البحث بشكلٍ أساسي) ومجموعة من دوال DOM (تستعملها المتصفحات بشكلٍ أساسي). لا حرج في تضمين البيانات الوصفية في صفحات الويب، فهي مجرد خاصيات ذات معنى خاص، وستتجاهلها محركات البحث التي لا تستطيع تفسير البيانات الوصفية. لكن إن كنت تريد الوصول إلى أو تعديل البيانات الوصفية عبر DOM، فعليك أن تتحقق أن متصفحك يدعم واجهة البيانات الوصفية البرمجية (API). نستعمل طريقة الاكتشاف الأولى لمعرفة إن كان المتصفح يدعم واجهة البيانات الوصفية البرمجية، وذلك إن وُجِدَت الدالة getItems()‎ في الكائن العام document، وإن لم يكن يدعم متصفحك البيانات الوصفية، فستكون الدالة getItems()‎ غير معرفة. function supports_microdata_api() { return !!document.getItems; } بدلًا من كتابة هذه الدالة بنفسك، يمكنك استعمال Modernizr لاكتشاف الدعم للبيانات الوصفية. if (Modernizr.microdata) { // هنالك دعمٌ للبيانات الوصفية! } else { // البيانات الوصفية غير مدعومة :( } التأريخ History API واجهة التأريخ البرمجية في HTML5 هي طريقة معيارية لتعديل تأريخ (history) المتصفح عبر السكربتات، جزءٌ من هذه الواجهة -التنقل في التأريخ- كان متوفرًا في الإصدارات السابقة من HTML. أما الجزء الجديد في HTML5 هو طريقة إضافة مدخلات جديدة إلى تأريخ المتصفح، والاستجابة عندما تُحذَف تلك المدخلات عبر ضغط المستخدم لزر الرجوع، وهذا يعني أن URL سيبقى يعمل عمله كمُعرِّف فريد للمورد الحالي، حتى في التطبيقات التي تعتمد اعتمادًا كبيرًا على السكربتات التي لا تجري عملية تحديث لكامل الصفحة. نستعمل طريقة الاكتشاف الأولى لمعرفة إن كان المتصفح يدعم واجهة التأريخ البرمجية، وذلك إن وُجِدَت الدالة pushState()‎ في الكائن العام history، وإن لم يكن يدعم متصفحك واجهة التأريخ البرمجية، فستكون الدالة pushState()‎ ‎ غير معرفة. function supports_history_api() { return !!(window.history && history.pushState); } بدلًا من كتابة هذه الدالة بنفسك، يمكنك استعمال Modernizr (الإصدار 1.6 أو ما بعده) لاكتشاف الدعم لواجهة التأريخ البرمجية. if (Modernizr.history) { // يمكنك تعديل تأريخ المتصفح! } else { // لا يوجد دعم لتعديل التأريخ :( // استعمل مكتبة مثل History.js } مراجع إضافية مكتبات JavaScript: Modernizr، مكتبة اكتشاف الدعم لميزات HTML5 geo.js، مكتبة لإضافة الدعم لواجهة تحديد المواقع Video for Everybody!‎ ترجمة -وبتصرّف- للفصل Detecting HTML5 Features من كتاب Dive Into HTML5 لمؤلفه Mark Pilgrim. اقرأ أيضًا المقال التالي: الرسم عبر عنصر canvas في HTML5 المقال السابق: نظرة على تاريخ HTML - الجزء الثاني النسخة العربية الكاملة من كتاب نحو فهم أعمق لتقنيات HTML5

سنتعلم في هذا الدرس من سلسلة مدخل إلى كتابة سكربتات الصدفة كيفية إضافة "ذكاء" إلى سكربتاتنا، فإلى الآن كان يحتوي مشروعنا على سلسلة من الأوامر التي يبدأ تنفيذها من بداية الملف ويستمر سطرًا بسطر إلى أن يصل إلى نهاية الملف. لكن إمكانيات أغلبية البرامج أكبر من ما سبق، حيث تستطيع "اتخاذ القرارات" وإجراء عمليات مختلفة بناءً على مجموعة من الشروط. توفِّر الصَدَفة عدِّة أوامر يمكننا استخدامها للتحكم في جريان تنفيذ البرنامج، وسنتعلم في هذا الدرس: if test exit الأمر if أول أمر سنلقي عليه نظرةً هو الأمر if، يبدو من أول وهلة أنَّ الأمر if بسيط جدًا، لأنه يتخذ قرارًا بناءً على "حالة الخروج" (exit status) لأحد الأوامر. الشكل العام لأمر if: if commands; then commands [elif commands; then commands...] [else commands] fi حيث commands هي مجموعة أوامر. قد تبدو الأمور مربكةً بعض الشيء في البداية، لكن قبل شرح الأمر if بالتفصيل، لنلقِ نظرة على آلية معرفة الصَدَفة لنجاح أو فشل تنفيذ أمر ما. حالة الخروج تُرسِل الأوامر (بما في ذلك السكربتات ودوال الصدفة التي نكتبها) قيمة إلى النظام عند انتهاء تنفيذها تُسمى "حالة الخروج" (exit status)؛ هذه القيمة (والتي هي عدد صحيح يتراوح ما بين 0 و 255) تُشير إلى نجاح أو فشل تنفيذ الأمر. من الأعراف البرمجية أن تكون القيمة 0 تعني نجاح التنفيذ وأي قيمة أخرى تعني فشله. توفِّر الصَدَفة معاملًا (parameter) خاصًا لتفحص حالة الخروج لآخر أمر مُنفَّذ: $ ls -d /usr/bin /usr/bin $ echo $? 0 $ ls -d /bin/usr ls: cannot access /bin/usr: No such file or directory $ echo $? 2 نفَّذنا -في المثال السابق- الأمر ls مرتين، حيث نُفِّذ تنفيذًا سليمًا في أول مرة، فلو عرضنا قيمة المعامل ‎$?‎ فسنرى أنها تساوي الصفر؛ ثم نفَّذنا الأمر ls مرةً أخرى لكنه عرض رسالة خطأ وعندما طبعنا قيمة المعامل ‎$?‎ مرةً أخرى فسنرى أنَّها تساوي 2، مما يشير إلى أنَّ آخر أمر قد نُفِّذ واجه مشكلةً. تستعمل بعض الأوامر حالات خروج مختلفة لتوفير معلومات حول الخطأ، لكن العديد من الأوامر تستعمل الرقم 1 فقط للإشارة إلى باقي أنواع الأخطاء. تحتوي صفحات الدليل man عادةً على قسم مُعنوَن "Exit Status" يشرح ما هي أرقام حالات الخروج المحتملة، لكن تذكَّر أنَّ 0 تُشير دائمًا إلى نجاح التنفيذ. توفِّر الصَدَفة أمرَين مُضمَّنين فيها بسيطين للغاية، كلُ ما يفعلانه هو الانتهاء بحالة خروج 0 أو 1. ينجح تنفيذ الأمر true دائمًا ويفشل تنفيذ الأمر false دائمًا: $ true $ echo $? 0 $ false $ echo $? 1 يمكننا استخدام هذه الأوامر لتجربة عبارة if الشرطية. ما تفعله عبارة if هو أنَّها تتحقق من نجاح أو فشل تنفيذ الأوامر التي تليها: $ if true; then echo "It's true."; fi It's true. $ if false; then echo "It's true."; fi $ يُنفَّذ الأمر echo "It's true."‎ عندما يُنفَّذ الأمر الذي يلي كلمة if بنجاح، ولن يُنفَّذ عندما يفشل تنفيذ الأمر الذي يلي كلمة if. الأمر test يُستخدَم الأمر test كثيرًا مع الأمر if لإنتاج القيمة true أو false. هذا الأمر غير اعتيادي لأنَّ له شكلان مختلفان: # الشكل الأول test expression # الشكل الثاني [ expression ] آلية عمل الأمر test بسيطةٌ جدًا، فلو كان التعبير (expression) الذي يليه صحيحًا، فسينتهي تنفيذ الأمر test بحالة خروج تساوي الصفر؛ فيما عدا ذلك سينتهي بحالة خروج تساوي 1. من أهم مميزات الأمر test تنوع التعابير التي تستطيع كتابتها فيه؛ هذا مثالٌ بسيط: if [ -f .bash_profile ]; then echo "You have a .bash_profile. Things are fine." else echo "Yikes! You have no .bash_profile!" fi استخدمنا في المثال السابق التعبير ‎ -f .bash_profile الذي يقول: "هل الملف ‎.bash_profile موجود؟" فإن كان موجودًا فسينتهي الأمر test بحالة خروج تساوي الصفر (أي true) وسيُنفِّذ الأمر if الأوامر التي تتبع الكلمة then؛ وإذا لم يكن الملف موجودًا فسينتهي الأمر test بحالة خروج تساوي الواحد (أي false) وسيُنفِّذ الأمر if الأوامر التي تلي الكلمة else. هذه قائمة مختصرة بالتعابير التي يمكن استعمالها في الأمر test. ولمّا كان الأمر test مُضمَّنًا في الصَدَفة (shell builtin)، فتستطيع استخدام help test لرؤية القائمة الكاملة. ‎-d dir: الناتج هو true إذا كان dir مجلدًا. ‎-e file: الناتج هو true إذا كان file موجودًا. ‎-f file: الناتج هو true إذا كان file ملفًا عاديًا موجودًا. ‎-L file: الناتج هو true إذا كان file وصلةً رمزيةً (symbolic link). ‎-r file: الناتج هو true إذا كنت تستطيع قراءة الملف file. ‎-w file: الناتج هو true إذا كنت تستطيع الكتابة على الملف file. ‎-x file: الناتج هو true إذا كنت تستطيع تنفيذ الملف file. file1 -nt file2: الناتج هو true إذا كان الملف file1 أحدث (وفقًا لوقت التعديل [modification time]) من الملف file2. file1 -ot file2: الناتج هو true إذا كان الملف file1 أقدم من file2. ‎-z string: الناتج هو true إذا كنت السلسلة النصية string فارغة. ‎-n string: الناتج هو true إذا لم تكن السلسلة النصية string فارغة. string1 = string2: الناتج هو true إذا كانت السلسلة النصية string1 مساويةً للسلسلة النصية string2. string1 != string2: الناتج هو true إذا لم تكن السلسلة النصية string1 مساويةً للسلسلة النصية string2. قبل أن نواصل أريد أن أشرح بقية المثال السابق لأنه يبرز عددًا من الأفكار المهمة. رأينا في بداية السكربت الأمر if متبوعًا بالأمر test متبوعًا بفاصلة منقوطة وفي النهاية الكلمة then. اخترت استعمال الشكل [ expression ] للأمر test لأنَّ أغلبية الناس يرون أنَّ قراءته أسهل. لاحظ أنَّ الفراغات مطلوبة بين قوس البداية ] وبداية التعبير، وكذلك الفراغ بين نهاية التعبير وقوس الإغلاق [. تعمل الفاصلة المنقوطة كفاصل بين الأوامر، مما يسمح بوضع أكثر من أمر في نفس السطر. مثلًا: $ clear; ls سيؤدي إلى مسح الشاشة ثم تنفيذ الأمر ls. استخدمتُ الفاصلة المنقوطة في عبارة if السابقة لأنني أريد وضع الكلمة then في نفس سطر الأمر if لأنني أرى أنَّها قراءتها أسهل بهذه الطريقة. سنشاهد صديقنا القديم echo في السطر الثاني، لكنك ستلاحظ وجود محاذاة (أي فراغات قبل الأمر)، وهذا لغرض تسهيل قابلية القراءة، ومن التقاليد البرمجية أن نحاذي جميع الأوامر داخل العبارة الشرطية if (أي جميع الأسطر التي ستُنفَّذ عند تحقيق شرط معيّن). تذكَّر أنَّ الصَدَفة لا تتطلَّب فعل ذلك، لكننا نفعله لجعل قراءة الشيفرة أسهل. بعبارة أخرى، يمكننا كتابة الشيفرات الآتية وسنحصل على نفس النتيجة: # Alternate form if [ -f .bash_profile ] then echo "You have a .bash_profile. Things are fine." else echo "Yikes! You have no .bash_profile!" fi # Another alternate form if [ -f .bash_profile ] then echo "You have a .bash_profile. Things are fine." else echo "Yikes! You have no .bash_profile!" fi الأمر exit لكي نكتب سكربتات صدفة جيدة، فعلينا ضبط حالة خروج عندما ينتهي تنفيذ السكربت، ونستعمل الأمر exit لفعل ذلك، الذي يؤدي إلى إيقاف تنفيذ السكربت فوريًا وضبط حالة الخروج إلى القيمة المُمرَّرة كوسيط إليه. على سبيل المثال، الأمر الآتي: exit 0 سيؤدي إلى إيقاف تنفيذ السكربت وضبط حالة الخروج إلى 0 (أي نجاح التنفيذ)، بينما: exit 1 سيؤدي إلى إيقاف تنفيذ السكربت وضبط حالة الخروج إلى 1 (أي فشل التنفيذ). التحقق من أن المستخدم المشغل للسكربت هو الجذر آخر مرة تركنا فيها السكربت كنا نحتاج إلى تشغيله بامتيازات الجذر، وذلك لأنَّ الدالة home_space تحتاج إلى معرفة المساحة التخزينية التي تستهلكها مجلدات المنزل للمستخدمين. لكن ماذا سيحدث لو حاول مستخدمٌ عادي تشغيل السكربت؟ سيؤدي ذلك إلى إظهار الكثير من رسائل الخطأ القبيحة. لكن ماذا لو وضعنا شيئًا في السكربت يمنع تنفيذه من المستخدم العادي؟ الأمر id يخبرنا من هو المستخدم الحالي، وعند تمرير الخيار ‎-u إليه فسيطبع قيمة عددية لمُعرِّف المستخدم (user ID) الحالي. $ id -u 501 $ su Password: # id -u 0 فلو نفَّذ المستخدم الجذر الأمر id -u فسيكون الناتج هو 0، ويمكننا أن نستثمر هذه المعلومة لكي تكون الأساس الذي سنبني عليه الاختبار الذي سنضعه في السكربت: if [ $(id -u) = "0" ]; then echo "superuser" fi تحققنا في المثال السابق أنَّ ناتج الأمر id -u مساوٍ للسلسلة النصية "0" ثم طبعنا العبارة "superuser". وعلى الرغم من أنَّ الأمر السابق يكتشف إن كان المستخدم هو المستخدم الجذر، إلا أنَّه لم يحل المشكلة بعد. إذ نريد أن يتوقف تنفيذ السكربت إن لم يكن المستخدم المُشغِّل له هو الجذر، لذلك نكتب الشيفرة الآتية: if [ $(id -u) != "0" ]; then echo "You must be the superuser to run this script" >&2 exit 1 fi نتحقق في الشيفرة السابقة أنَّ ناتج الأمر id -u لا يساوي "0"، ثم سيطبع السكربت رسالة خطأ مفهومة، ثم ينتهي تنفيذه بحالة خروج مساوية للواحد، لكي يخبر النظام أنَّه لم يتم التنفيذ بنجاح. لاحظ وجود ‎>&2 في نهاية الأمر echo، الذي هو شكلٌ من أشكال إعادة توجيه الدخل والخرج (I/O redirection)، وسترى هذا التعبير عادةً في نهاية الأوامر التي تطبع رسائل خطأ، لأننا لو لم نُعِد توجيه مجرى الخطأ هنا، فسترسَل رسالة الخطأ إلى مجرى الخرج القياسي (standard output stream)، لكننا نريد أن تظهر رسائل الخطأ بمعزل عن مخرجات السكربت، لأننا نعيد توجيه مجرى الخرج القياسي الناتج من تنفيذ السكربت إلى ملف. علينا أن نضع الأسطر السابقة في بداية السكربت لكي نتمكن من تحديد هوية المستخدم المُشغِّل قبل أن يقع الخطأ، لكننا نريد في الوقت نفسه أنَّ يمكن المستخدمون العاديون من تشغيل السكربت، لذلك سنعدِّل الدالة home_space لكي تتأكد من امتيازات المستخدم كالآتي: function home_space { # Only the superuser can get this information if [ "$(id -u)" = "0" ]; then echo "<h2>Home directory space by user</h2>" echo "<pre>" echo "Bytes Directory" du -s /home/* | sort -nr echo "</pre>" fi } # end of home_space بهذه الطريقة سيتمكن المستخدم العادي من تشغيل السكربت، وسيتم تجاوز الشيفرة التي قد تتسبب بخطأ بدلًا من تنفيذها وإظهار رسالة للمستخدم. ترجمة -وبتصرّف- للمقال Flow Control - Part 1 لصاحبه William Shotts.

أنا منبهر كثيرًا بجميع نواحي المحادثة ذات 23 عامًا، التي أدت إلى إنشاء عنصر HTML الذي استعمل في كل صفحة ويب تقريبًا. خذ بعين الاعتبار أنَّ: HTTP ما زال موجودًا، ونجح بالتطور من الإصدار 0.9 إلى 1.0 ثم إلى 1.1، وما يزال يتطور. HTML ما زالت موجودةً، صيغة البيانات البدائية تلك التي لم تكن تدعم تضمين الصور! تطورت إلى الإصدار 2.0 ثم إلى 3.2 ثم إلى 4.0، أي أنَّ خط تطويرها لم ينقطع، لكنه بالتأكيد خطٌ ملتوٍ ومتعرج، وفيه العديد من النهايات المغلقة. لكن ها نحن ذا في عام 2016، وما زالت صفحات الويب من عام 1990 تُعرَض بشكلٍ جيد في المتصفحات الحديثة. ولقد فتحتُ إحداها في متصفح هاتفي الحديث العامل بنظام أندرويد، ولم أحصل على رسالة تقول "الرجاء الانتظار إلى أن يتم استيراد الصيغة القديمة". نتجت HTML من النقاشات بين صانعي المتصفحات والمطورين وواضعي المعايير والأشخاص الذين يحبون التحدث عنها. أغلبية الإصدارات الناجحة من HTML كانت عبارة عن إضفاءِ صفةٍ رسميةٍ لما هو موجودٌ مُحاوِلَةً توجيهه نحو الطريق الصحيح. أي شخص يخبرك أنه يجب أن تكون HTML «صرفة» (أي على الأرجح بتجاهل صانعي المتصفحات أو المطورين أو كليهما) هو شخصٌ لديه معلوماتٌ خاطئة. لم تكن HTML صرفةً أبدًا، وأيةّ محاولات لجعلها كذلك قد باءت بالفشل. لم يبق أي متصفح منذ عام 1993 موجودًا كما هو. فتم التخلي عن متصفح Netscape Navigator في 1998، ثم أعيدت كتابته من الصفر لإنشاء Mozilla Suite، ثم تم الاشتقاق لإنشاء Firefox. وكانت لمتصفح Internet Explorer بداياتٌ متواضعة في «Microsoft Plus!‎» لويندوز 95، حيث حُزِّمَ مع بعض سمات سطح المكتب ولعبة pinball (لكن بالطبع يمكن تتبع تاريخ المتصفح إلى أبعد من تلك النقطة). بعض أنظمة التشغيل من عام 1993 ما زالت موجودةٌ، لكن ليس لها صلة بالويب الحديث الذي نعرفه. فأغلبية مستخدمي الويب الآن بدؤوا باستعماله على حاسوب مكتبي يعمل بنظام ويندوز 2000 أو أحدث منه، أو على جهاز Mac يعمل بنظام OS X، أو على حاسوب مكتبي يعمل بتوزيعة من توزيعات لينُكس، أو على هاتف محمول مثل هواتف أندرويد أو iPhone. لكن كان إصدار ويندوز 3.1 في عام 1993، وكان لينُكس يوزَّع عبر Usernet. بقي بعض الأشخاص موجودين وما يزالون منهمكين في العمل على ما ندعون «معايير الويب»، حيث بقي هؤلاء الأشخاص يعملون لأكثر من 20 عامًا، وعمل بعضهم على اللغات التي تسبق HTML التي يمكن تتبع تاريخها إلى ثمانينيات القرن الماضي. بالحديث عن اللغات التي سبقت HTML، أصبح من السهل نسيان الصيغ والأنظمة التي كانت موجودةٌ عند إنشاء HTML بعد الانتشار الواسع والكبير للغة HTML والويب. ماذا عن Andrew؟ أو Intermedia؟ أو HyTime؟ لم تكن HyTime مشروعًا بحثيًا أكاديميًا لا شأن لها، وإنما كانت من معايير ISO، ولقد كانت تُستعمل لأغراضٍ عسكرية. لم يُجِب كل ما سبق عن تساؤلنا الأصلي: لماذا لدينا عنصر <img>؟ لماذا ليس عنصر <icon>؟ أو عنصر <include>؟ لماذا ليس رابطًا مع خاصية include، أو مجموعةٌ من قيم الخاصية rel؟ لماذا عنصر <img>؟ الجواب بسيطٌ للغاية، لأن Marc Andreessen قام بتنفيذ (بناء) وتوفير العنصر <img> في مُتصفّحه والذي يقوم ببناء العنصر وتوفيره في متصفّحه سيربح. لكن هذا لا يعني أنَّ مَن يبني العُنصر وينشره سيربح دائمًا، فلا تنسَ أنَّ Adnrew و Intermedia و HyTime قامت بذلك أيضًا، فبناء العنصر وتوفيره هو شرطٌ لازمٌ لكنه غير كافٍ للنجاح؛ وأنا هنا لا أقصد أنَّ بناء العُنصر قبل المعيار هو الحل الأمثل، ووسم <img> لم يكن يستعمل صيغة صور شائعة، ولم يُعرِّف كيف يلتف النص حول الصورة، ولم يكن يدعم النص البديل أو محتوى احتياطي للمتصفحات القديمة، وبعد 23 عامًا، ما زلنا نعاني مع مشكلة Content Sniffing، وما تزال هذه المشكلة مصدرًا للثغرات الأمنية. ويمكنك تتبع كل هذا إلى 23 عامًا مضت، مرورًا بحرب المتصفحات، إلى 23 شباط/فبراير عام 1993، عندما قال Marc Andreessen بشكلٍ عابر «ربما في يوم ما سنعتمد الـ MIME» ومع ذلك نشر العنصر الذي قام ببنائه وتضمينه في مُتصفّحه. التسلسل الزمني لتطوير HTML من 1997 إلى 2004 في كانون الأول/ديسمبر من عام 1997، نشرت رابطة الشبكة العالمية (W3C) نسخة HTML 4.0 ثم أغلقت مجموعة عمل HTML‏ (HTML Working Group) في الحال. وبعد أقل من شهرين، نشرت مجموعة عمل أخرى من W3C معيار XML 1.0، وبعد ذلك بثلاثة أشهر، أنشَأ القائمون على W3C ورشة عمل (workshop) اسمها "بلورة مستقبل HTML"‏ (Shaping the Future of HTML) للإجابة عن هذا السؤال: "هل تخلت W3C عن HTML؟" وكان جوابهم: منحت W3C مجموعة عمل HTML هذا التكليف لإنشاء "مجموعة من وسوم XML"، كانت أول خطوة –في كانون الأول/ديسمبر 1998– هي كتابة مسودة لمعيار مؤقت (انتقالي) الذي كانت مهمته إعادة قولبة HTML في XML دون إضافة أيّة عناصر أو خاصيات جديدة، عُرِفَ هذا المعيار لاحقًا باسم "XHTML 1.0" وعرَّف نوع MIME جديد لمستندات XHTML ‏"application/xhtml+xml"، لكن لتسهيل انتقال صفحات HTML 4 الموجودة من قبل، فقد تضمن المعيار "الملحق C" الذي "يلخص إرشادات التصميم للمطورين الذين يريدون تشغيل مستندات XHTML في متصفحات HTML الموجودة من قبل"، إذ قال الملحق C أنك تستطيع كتابة ما يسمى "صفحات XHTML" لكن تستطيع تخديمها عبر نوع MIME القديم text/html. الهدف الجديد هو النماذج (forms)، ففي آب/أغسطس 1999، نشرت مجموعة عمل HTML نفسها أول مسودةٍ لنماذج XHTML الموسعة ولقد وضعوا التوقعات التي يرمون إلى تنفيذها في أول فقرة: وبعد عدِّة أشهر أُعيدت تسمية "XHTML Extended Forms" إلى "XForms" وانتقلت إلى مجموعة العمل الخاصة بها، وعَمِلَت هذه المجموعة على التوازي مع مجموعة عمل HTML ونَشرت في النهاية الإصدار الأول من XForms 1.0 في تشرين الأول/أكتوبر 2003. وفي تلك الأثناء -وبعد اكتمال التحويل إلى XML- حطَّت مجموعة عمل HTML أنظارها إلى إنشاء "الجيل الجديد من HTML"، ففي أيار/مايو 2001، نشروا الإصدار الأول من XHTML 1.1، الذي أضاف بعض الميزات الصغيرة على XHTML 1.0، لكنه أزال الملحق C، فيجب -بدءًا من الإصدار 1.1- تخديم مستندات XHTML بنوع MIME الخاص بها application/xhtml+xml. كل شيء تعرفه عن XHTML خاطئ لماذا أنواع MIME مهمة جدًا؟ لماذا أذكرها بين الحين والآخر؟ لسبب واحد: draconian error handling (أي عدم التساهل في معالجة الأخطاء). فكانت المتصفحات "متسامحة" مع HTML، فلو أنشأت صفحة HTML ولكن نسيت وسم الإغلاق ‎</head>‎، فستُظهِرها المتصفحات على أيّة حال (لأن هنالك وسومًا معيّنة تشير إلى نهاية قسم <head> وبداية <body>)، فيجب عليك أن تضع هيكلية معيّنة عند تداخل الوسوم (أي إغلاق الوسوم المفتوحة بنمط "last-in-first-out" أي أن آخر وسم مستعمل سيُغلق أولًا) لكن إن كتبتَ <b><i></b></i>، فستتعامل المتصفحات معها (بطريقةٍ ما) وستكمل عرض الصفحة دون إظهار رسالة خطأ. وكما قد تتوقع، أدت عدم كتابة شيفرات HTML بطريقة سليمة تمامًا إلى جعل المطورين يكتبون شيفرات غير سليمة. ففي بعض التقديرات، أكثر من 99% من صفحات HTML على الويب فيها خطأ واحد على الأقل، لكن لما كانت هذه الأخطاء لا تسبب عرض رسالة خطأ مرئية من المتصفحات، ولهذا لن يصلحها أحد. رأت W3C هذه المشكلة الأصولية في الويب، ثم همّوا لتصحيحها. لغة XML، المنشورة في 1997، تخلصت من العملاء المتساهلين وقالت بأن جميع البرامج التي تستعمل XML يجب أن تعامل الأخطاء المتعلقة "بطريقة الكتابة السليمة" على أنها أخطاء (Fetal Errors). اشتهر مفهوم توقف المعالجة عند أول خطأ بالاسم "draconian error handling" وذلك نسبةً إلى القائد الإغريقي Draco الذي شرَّع عقوبة الموت لأيّة تجاوزات (ولو صغيرة نسبيًا) لقوانينه. فعندما أعادت W3C صياغة HTML بمفردات XML، اعتبرت أنَّ جميع المستندات التي تُخدَّم بنوع MIME الجديد application/xhtml+xml ستخضع إلى سياسة draconian error handling، فلو كان هنالك خطأٌ ما في أسلوب صياغة صفحة XHTML -نسيان وسم الإغلاق ‎</head>‎ أو تداخل غير صحيح للوسوم على سبيل المثال- فلن يكون لمتصفح الويب خيارٌ إلا إيقاف معالجة الصفحة وإظهار رسالة خطأ إلى المستخدم النهائي. لم تكن هذه الفكرة شائعةً على نطاقٍ واسع، لأن النسبة المُقدَّرة للأخطاء في صفحات الويب هي 99%، هذا يعني أن رسائل الخطأ ستُعرَض على المستخدم طوال الوقت، ولقلة الميزات التي توفرها XHTML 1.0 و 1.1، فقرر مطورو الويب تجاهل application/xhtml+xml، لكن هذا لا يعني أنهم تجاهلوا XHTML بالكلية، لأن الملحق C من معيار XHTML 1.0 أعطى مطوري الويب ثغرةً يمكنهم استعمالها: "اكتب شيئًا يشبه بنية XHTML، لكن خدِّمه بنوع MIME القديم text/html"، وهذا ما فعله الآلاف من مطوري الويب، إذ «حدَّثوا» صفحاتهم إلى بنية XHTML لكن بقيت تلك الصفحات مُخدَّمة بنوع MIME القديم text/html. ولليوم، ما تزال تعلن ملايين الصفحات أنها XHTML، فيبدؤون بنوع المستند doctype الخاص بلغة XHTML في أول سطر، ويستعملون أحرفًا صغيرةً لأسماء الوسوم، ويستعملون علامات الاقتباس حول قيم الخاصيات، ويضيفون خطًا مائلًا بعد العناصر الفارغة مثل <br /‎> و <hr /‎> لكن قلّة قليلة من تلك الصفحات تُخدَّم بنوع MIME الجديد application/xhtml+xml، الذي سيُفعِّل عدم التساهل في الأخطاء الخاص بلغة XML. فأيّة صفحة تُخدَّم بنوع MIME القديم text/html -بغض النظر عن doctype أو بنية الوسوم- ستُفسَّر باستعمال مُفسِّر HTML المُتساهل، وسيتم تجاهل الأخطاء دون إظهار أيّة رسالة، ودون تحذير المستخدم (أو أي شخص آخر) حتى لو كانت الصفحة فيها أخطاء تقنية. فتحت XHTML 1.0 هذه النافذة، ولكن XHTML 1.1 أغلقتها، والنسخة التي لن تُصدَر XHTML 2.0 استمرت في منهج عدم التساهل في الأخطاء، وهذا هو السبب وراء ادعاء ملايين الصفحات على أنها XHTML 1.0 وأنَّ حفنة قليلة منهم هي XHTML 1.1 (أو XHTML 2.0)، فهل أنت تستعمل XHTML حقًا؟ تحقق من نوع MIME (في الواقع، إن لم تكن تعرف ما هو نوع MIME الذي تستعمله، فأنا أضمن لك أنك ما زلتَ تستعمل text/html)، فما لم تُخدِّم صفحاتك بنوع MIME الجديد application/xhtml+xml، فإن «XHTML» هي XML بالاسم فقط. رؤية تنافسية في حزيران/يونيو 2004، أقامت W3C ورشة عمل حول تطبيقات الويب والمستندات المجمّعة، حضر هذا الاجتماع ممثلون عن مصنعي ثلاثة متصفحات، وشركات تطوير الويب، وأعضاء آخرون من W3C، ومجموعة من الجهات المهتمة بما في ذلك منظمة Mozilla وشركة Opera Software، وأعطوا رؤيتهم لمستقبل الويب: تطوير معيار HTML 4 لتضمين ميزات جديدة تساعد مطوري تطبيقات الويب الحديثة. تمثِّل المبادئ السبعة الآتية ما نظن أنه أهم المتطلبات اللازمة لهذا العمل: التوافقية مع الإصدارات القديمة، ومسار واضح للهجرة يجب أن تكون تقنيات تطبيقات الويب مبنية على تقنيات مألوفة للمطورين، بما في ذلك HTML و CSS و DOM و JavaScript. يجب أن تُطبَّق الميزات الأساسية لتطبيقات الويب باستعمال السكربتات وصفحات الأنماط في IE6، لذا يكون هنالك مسارٌ واضحٌ للهجرة نصب عيني المطورين. أي حل لا يمكن أن يستعمل مع المتصفحات ذات الشعبية الكبيرة حاليًا دون حاجة إلى إضافات لن يكون ناجحًا. نظام معالجة أخطاء مُحدَّد بدقة يجب تفصيل كيفية معالجة الأخطاء إلى درجة لا تحتاج المتصفحات فيها إلى اختراع نظام معالجة أخطاء خاص بهم، أو أن يبنوا واحدًا مشتقًا من المتصفحات الأخرى. لا يجب عرض الأخطاء على المستخدمين يجب أن تُحدِّد المعايير السلوك اللازم اتباعه عند حدوث أي نوع من الأخطاء، ويجب أن يكون نظام معالجة الأخطاء متساهلًا (كما في CSS) بدلًا من أن يكون واضحًا للمستخدم وكارثيًا (كما في XML). الاستعمال العملي يجب أن تُبرَّر إضافة كل ميزة إلى معايير تطبيقات الويب بحالات الاستعمال العملي لها، لكن العكس ليس صحيحًا بالضرورة: ليست كل حالة استخدام تتطلب إنشاء ميزة جديدة. يُفضَّل أن تكون حالات الاستخدام ذات أساس في مواقع حقيقة استخدم فيها المطورون حلًا ليس مثاليًا للالتفاف على القصور في التقنية. سيبقى استخدام السكربتات قائمًا لكن يجب الابتعاد عنه إذا توفرت وسوم مناسبة. ويجب أن لا تتدخل السكربتات في طريقة العرض، وأن تكون مستقلة عن الجهاز المشغل لها. يجب تجنب التفريق بين الأجهزة يجب أن يتمكن المطورون من استخدام نفس الميزات الموجودة في نسخة سطح المكتب ونسخة الهواتف المحمولة لنفس المتصفح. عملية مفتوحة استفاد الويب من كونه مطوَّرًا في بيئة مفتوحة. وستصبح تطبيقات الويب أساسية في المستقبل، ويجب أن يكون تطويرها في بيئةٍ مفتوحةٍ أيضًا، ويجب إتاحة القوائم البريدية والأرشيفات ومسودات المعايير للجميع. سُئِلَ المشاركون في ورشة العمل في استطلاعٍ للرأي: «هل يجب على W3C تطوير إضافات لوظائف جاهزة في HTML و CSS، وإضافات لأساس DOM لكي تتحقق متطلبات تطوير تطبيقات الويب متوسطة التعقيد. أم عليها تطوير واجهة برمجية (API) كاملة على مستوى النظام (OS-level)؟ (هذا الاقتراح من Ian Hickson، من Opera Software)» كان التصويت 11 إلى 8 ضد هذا الاقتراح، وكتبت W3C في ملخص الورشة: وبعد هذا القرار، كان لدى الأشخاص الذين اقترحوا تطوير HTML ونماذج HTML خياران فقط: الاستسلام، أو إكمال عملهم خارج إطار W3C، وقرروا المضي قدمًا في الخيار الثاني، وسجلوا النطاق whatwg.org، وفي حزيران/يونيو 2004، وُلِدَت مجموعة عمل WHAT. مجموعة عمل WHAT ما هي مجموعة عمل WHAT؟ سأقتبس من كلامهم: الجملة الأساسية في الفقرة السابقة هي "دون التسبب بمشاكل تتعلق بالتوافقية"، ليست XHTML (دون الثغرة التي وفرها الملحق C) متوافقةً مع HTML، وتتطلب نوع MIME خاص بها، وXForms ليست متوافقة مع نماذج HTML لعدم القدرة على استعمالها إلا مع الصفحات المُخدَّمة بنوع MIME الخاص بصفحات XHTML، هذا يعني أن XForms تتطلب عدم التساهل في التعامل مع الأخطاء. فبدلًا من أن نرمي ما يقارب عقدًا من الزمن من العمل على HTML ونجعل 99% من صفحات الويب الموجودة حاليًا غير قابلة للاستخدام، قررت مجموعة عمل WHAT أن تنتهج منهجًا آخر: توثيق خوارزميات التعامل مع الأخطاء «المتسامحة» التي تستعملها المتصفحات. كانت وما زالت المتصفحات متساهلةً مع أخطاء HTML، لكن لم يُتعِب أحدٌ نفسه ويوثق آلية التساهل بالضبط. لدى متصفح NCSA Mosaic خوارزميات خاصة به للتعامل مع الأخطاء، وحاول Netscape أن يقلده، ثم حاول Internet Explorer تقليد Netscape، ثم حاول Opera و Firefox تقليد Internet Explorer، ثم حاول Safari تقليد Firefox، وهلّم جرًا حتى يومنا هذا. إذ ضيع المطورون آلاف الساعات محاولين جعل منتجاتهم متوافقة مع منتجات منافسيهم. استغرقت مجموعة عمل WHAT خمسة أعوامٍ من العمل للنجاح في توثيق كيفية تفسير HTML (ما عدا بعض الحالات الخاصة جدًا والغامضة) بطريقة متوافقة مع جميع المحتوى الموجود على الويب. فلا يوجد في الخوارزمية النهائية أيّة حالة يتوقف فيها مفسر HTML عن إكمال تفسير صفحة HTML ويعرض رسالة خطأ للمستخدم النهائي. وفي الفترة التي كانت تجرى فيها الهندسة العكسية، كانت تعمل مجموعة WHAT بصمت على أشياءٍ أخرى أيضًا، منها معيارٌ سُمي في بادئ الأمر "Web Forms 2.0" الذي أضاف بعض عناصر التحكم إلى نماذج HTML (ستتعلم المزيد عن نماذج HTML في درسٍ لاحق). ومسودة معيار أخرى باسم "Web Applications 1.0" التي حَوَت ميزات أخرى رئيسية مثل canvas والدعم المُضمَّن لتشغيل الصوت والفيديو دون إضافات. العودة إلى W3C لمدة تقارب السنتين ونصف، تجاهلت W3C ومجموعة عمل WHAT بعضهما البعض، على الرغم من أن مجموعة عمل WHAT كانت تركز على نماذج الويب وميزات HTML الجديدة، ومجموعة عمل W3C مشغولة بإصدار 2.0 من XHTML، لكن بحلول تشرين الأول/أكتوبر، كان جليًا أن مجموعة عمل WHAT قد أحدثت زخمًا كبيرًا، بينما كانت XHTML 2.0 تقبع على شكل مسودة لم يتم تطبيقها من أيّ متصفح رئيسي. في تشرين الأول/أكتوبر، أعلن Tim Berners-Lee -مؤسس W3C- أن W3C ستعمل مع مجموعة عمل WHAT لتطوير HTML. واحد من أول الأشياء التي قررت مجموعة عمل W3C الجديدة فعلها هي إعادة تسمية "Web Applications 1.0" إلى "HTML5"، ومن هنا بدأت رحلة هذا السلسلة. حاشية في تشرين الأول/أكتوبر 2009، أغلقت W3C مجموعة عمل XHTML 2 وأصدرت هذه الإفادة لشرح قرارها: مراجع إضافية The History of the Web، مسودة قديمة كتبها Ian Hickson HTML/History كتبها Michael Smith، و Henri Sivonen، وآخرون A Brief History of HTML لكاتبها Scott Reynen ترجمة -وبتصرّف- لفصل A Quite Biased History of HTML5 من كتاب Dive Into HTML5 لمؤلفه Mark Pilgrim. اقرأ أيضًا المقال التالي: اكتشاف دعم المتصفحات لميزات HTML5 المقال السابق: نظرة على تاريخ HTML - الجزء الأول النسخة الكاملة من كتاب نحو فهم أعمق لتقنيات HTML5 دليل: تعلم لغة HTML

إذا كنت تستخدم موقع ووردبريس ما لأغراض التجربة، أو إذا أردت إعادة إعداد مدونتك من الصفر، فربما تتساءل كيف يمكنك إعادة ضبط ووردبريس إلى الإعدادات الافتراضية. يمكن أن تستفيد من إعادة ضبط مواقع ووردبريس إذا كنت تُجرِّب إضافات أو قوالب جديدة، أو إذا كنت تريد تجربة ميزات ووردبريس ثم أردت إعادة الموقع إلى ما كان عليك عند تثبيته. بدلًا من حذف الموقع وإعادة تثبيت ووردبريس (مما يأخذ وقتًا وجهدًا)، هنالك حلٌ أسهل: الضغط على زر إعادة الضبط. إعادة ضبط موقعك باستخدام WordPress Database Reset WordPress Database Reset هي إضافة مجانية متوفرة في مستودع إضافات ووردبريس التي تسمح لك بإعادة ضبط قاعدة البيانات إلى قيمها الافتراضية. ولمّا كانت قاعدة البيانات تحتوي على جميع معلومات الموقع والتخصيصات التي أُجريت عليه، فهذا يعني أنَّ الإضافة ستحذف كل محتويات موقعك، وسيمسي موقعك كأنه قد ثُبِّتَ الآن. عليك أولًا تنزيل وتثبيت وتفعيل الإضافة، وستجدها قد أضافت عنصرًا جديدًا إلى قائمة لوحة التحكم تستطيع الوصول إليه من: Tools > Database Reset ستحذف هذه الإضافة كل المحتوى الموجود على موقعك اختر الجداول التي تريد إعادة ضبطها، أو اضغط على Select All لاختيارها جميعًا وإعادة ضبط كل الموقع. اضغط على Select All لحذف كل شيء على موقعك يسمح لك اختيار الجداول بتحديد المحتوى الذي تريد حذفه، مثل التعليقات، أو جميع الصفحات (pages)، أو جميع المستخدمين (عدا مدير الموقع بالطبع). عندما تختار Select All فسيظهر لك حقلٌ يسألك إن كنت تريد إعادة تفعيل القالب والإضافات الحالية بعد إعادة الضبط. فعِّل هذا الحقل إن أردت الاحتفاظ بها، وإلا فاتركه معطلًا. عليك الآن كتابة كود التحقق (الذي هو في مثالنا "c140a") ثم الضغط على Reset Tables. ستؤخذ إلى لوحة التحكم بعد إعادة ضبط جميع الإعدادات إلى قيمها الافتراضية. ستُظهِر الإضافة مربع حوار يسألك إن كنت تريد المتابعة، اضغط على OK. من الجيد تثبيت إضافة WordPress Database Reset إذا كنت تُعيد ضبط موقع ووردبريس الخاص بك كثيرًا ولا تريد أن تضيّع 5 دقائق في كل مرة لتثبيت ووردبريس. هذه الإضافة هي طريقة سهلة وسريعة لإعادة ضبط الموقع. الميزات المتقدمة أما إذا كنتَ مستخدمًا خبيرًا، مثل مطوري الإضافات والقوالب، فيمكنك استخدام هذه الإضافة مع WordPress CLI – واجهة سطر أوامر لووردبريس. إن كنتَ قد ثبتتَ WordPress CLI من قبل، فيمكنك إعادة ضبط قاعدة البيانات باستخدام الأمر الآتي: wp reset database وتستطيع أيضًا تحديد قائمة بالجداول التي تريد إعادة ضبطها: wp reset database –tables=’users, posts, comments, options’ راجع مستودع WordPress Database Reset على GitHub لمزيدٍ من المعلومات حول استخدام WordPress CLI مع إضافة WordPress Database Reset. أريد أن أذكِّرك مرةً أخرى أنَّ هذه الإضافة ستحذف كل المحتوى في موقعك (إن اخترت Select All) لذلك استخدمها إذا أردت حذف كل محتويات موقعك. هل ترغب في امتلاك موقع ووردبريس سريع وآمن؟ احصل على موقع ووردبريس احترافي بالاستعانة بأفضل خدمات الووردبريس على خمسات أنشئ موقع ووردبريس الآن ترجمة -وبتصرّف- للمقال How to Reset Your WordPress Website لصاحبته Raelene Morey.

عندما يزداد طول البرامج وتعقيدها، فستزداد صعوبة تصميمها وبرمجتها وصيانتها؛ لذا من المفيد عادةً تقسيم المهام الكبيرة إلى سلسلة من المهام الأصغر. سنُقسِّم في هذا الدرس السكربت الذي كنا نعمل عليه إلى عدد من الدوال (functions) المنفصلة. لكي نتعرف على مفهوم الدوال، فلنحاول وصف طريقة القيام بمهمة يومية: الذهاب إلى السوق وشراء الطعام. تخيل أننا سنصف العملية إلى كائنات فضائية آتية من المريخ. سيبدو الوصف العام لعملية شراء الطعام كالآتي: غادر المنزل قد السيارة إلى السوق اركن السيارة ادخل السوق اشترِ طعامًا قد السيارة إلى المنزل اركن السيارة ادخل إلى المنزل سيُغطِّي الشرح السابق الآلية العامة للذهاب إلى السوق؛ لكن تلك الكائنات الفضائية ستحتاج مزيدًا من التفاصيل، فمثلًا يمكن وصف المهمة الفرعية "اركن السيارة" كالآتي: اعثر على مكان فارغ لركن السيارة قد السيارة إلى ذاك المكان أطفئ المحرك "ارفع" المكابح اليدوية اخرج من السيارة اقفل السيارة ويمكن بالطبع تقسيم خطوة "أطفئ المحرك" إلى عدد من الخطوات مثل: أطفئ دارة الإشعال أخرج مفتاح السيارة وهكذا إلى أن تُفصِّل كل خطوة من كامل عملية الذهاب إلى السوق. عملية تعريف الخطوط الأساسية ومن ثم كتابة التفاصيل لتلك الخطوات تسمى "نمط تصميم Top-Down". يسمح هذا النمط لنا بتقسيم المهام الكبيرة والضخمة إلى مهام أبسط وأصغر. سنستخدم نمط تصميم Top-Down ليساعدنا في التخطيط لبرنامجنا الذي سنكمل تطويره وإضافة الميزات إليه. يمكننا تلخيص "الوصف العام" للمهام التي يقوم بها السكربت الآن: بداية الصفحة بداية ترويسة الصفحة كتابة العنوان إغلاق الترويسة بداية جسم الصفحة كتابة العنوان كتابة بصمة الوقت (timestamp) إغلاق الجسم إغلاق الصفحة تمت برمجة كل الخطوات السابقة، لكننا نريد إضافة المزيد. لندرج بعض المهام الإضافية بعد المهمة السابعة: كتابة بصمة الوقت كتابة معلومات عن إصدار النظام كتابة الوقت الذي مضى منذ آخر تشغيل (uptime) كتابة مساحة القرص كتابة المساحة التخزينية لمجلدات المنزل (home) إغلاق الجسم إغلاق الصفحة سيكون من حسن حظنا وجود أوامر تستطيع تنفيذ المهام الإضافية، فسنستطيع استخدام "تعويض الأوامر" (command substitution) لوضعها في السكربت كالآتي: #!/bin/bash # sysinfo_page - A script to produce a system information HTML file ##### Constants TITLE="System Information for $HOSTNAME" RIGHT_NOW=$(date +"%x %r %Z") TIME_STAMP="Updated on $RIGHT_NOW by $USER" ##### Main cat <<- _EOF_ <html> <head> <title>$TITLE</title> </head> <body> <h1>$TITLE</h1> <p>$TIME_STAMP</p> $(system_info) $(show_uptime) $(drive_space) $(home_space) </body> </html> _EOF_ أما للمهام التي لا توجد أوامر تستطيع فعل ما نريد تحديدًا، فيمكننا إنشاؤها باستخدام دوال الصدفة (shell functions). وكما تعلمنا في أحد الدروس السابقة، يمكن اعتبار دوال الصدفة على أنها "برامج صغيرة ضمن البرامج" وتسمح لنا باتباع مبادئ نمط التصميم top-down. علينا تعديل السكربت كالآتي لإضافة دوال الصدفة: #!/bin/bash # sysinfo_page - A script to produce an system information HTML file ##### Constants TITLE="System Information for $HOSTNAME" RIGHT_NOW=$(date +"%x %r %Z") TIME_STAMP="Updated on $RIGHT_NOW by $USER" ##### Functions system_info() { } show_uptime() { } drive_space() { } home_space() { } ##### Main cat <<- _EOF_ <html> <head> <title>$TITLE</title> </head> <body> <h1>$TITLE</h1> <p>$TIME_STAMP</p> $(system_info) $(show_uptime) $(drive_space) $(home_space) </body> </html> _EOF_ هنالك نقطتان تجدر الإشارة إليهما: أولهما أنَّه يجب تعريف دوال الصدفة قبل محاولة استخدامها؛ وثانيهما هو أنَّ جسم الدالة (أي القسم الذي يقع بين قوس البداية "}" وقوس النهاية "{") يجب أن يحتوي على أمرٍ واحدٍ على الأقل. لن يعمل السكربت السابق وسيُظهِر رسالة خطأ وذلك لأنَّ جسم الدوال فارغ. أبسط طريقة لتصحيح هذه المشكلة هي وضع عبارة "return" في جسم كل دالة، وبعدها سيُنفَّذ السكربت بنجاح. إبقاء السكربتات قابلة للتشغيل من المفيد أثناء تطويرنا للتطبيق أن نُضيف جزءًا يسيرًا من الشيفرات ثم نُجرِّب السكربت ثم نضيف المزيد ثم نجرِّب السكربت وهكذا. وبهذه الطريقة سيسهل العثور على الأخطاء في الشيفرة ومن ثم تصحيحها. بعد إضافة الدوال إلى السكربت، أصبح بإمكانك الآن مراقبة التسلسل المنطقي لتنفيذ السكربت وذلك عبر آلية يُطلَق عليها اسم stubbing أي إضافة شيفرة وهمية. يمكنك تخيل هذه الآلية كما يلي: لنفترض أننا نريد إنشاء دالة اسمها "system_info" لكننا لم نفكر في تفاصيل الشيفرة بشكل كامل. فبدلًا من إيقاف عملية تطوير السكربت إلى أن ننتهي من الدالة system_info فيمكننا إضافة الأمر echo إليها كالآتي: system_info() { # Temporary function stub echo "function system_info" } سنتمكن باستخدام هذه الآلية من تنفيذ السكربت دون خطأ حتى لو لم نكمل برمجة الدالة system_info؛ ونستطيع لاحقًا وضع الشيفرة الحقيقية بدلًا من أمر echo السابق. سبب استخدامنا لأمر echo هو أننا نحتاج إلى مؤشر لكي نعرف أنَّ السكربت قد نفَّذ الدالة المعنية. لنُطبِّق هذه الآلية على جميع الدوال في السكربت: #!/bin/bash # sysinfo_page - A script to produce an system information HTML file ##### Constants TITLE="System Information for $HOSTNAME" RIGHT_NOW=$(date +"%x %r %Z") TIME_STAMP="Updated on $RIGHT_NOW by $USER" ##### Functions system_info() { # Temporary function stub echo "function system_info" } show_uptime() { # Temporary function stub echo "function show_uptime" } drive_space() { # Temporary function stub echo "function drive_space" } home_space() { # Temporary function stub echo "function home_space" } ##### Main cat <<- _EOF_ <html> <head> <title>$TITLE</title> </head> <body> <h1>$TITLE</h1> <p>$TIME_STAMP</p> $(system_info) $(show_uptime) $(drive_space) $(home_space) </body> </html> _EOF_ سنكمل الآن العمل على كل دالة على حدة لكي تُخرِج معلوماتٍ مفيدةً. show_uptime ستُظهِر الدالة show_uptime ناتج الأمر uptime، الذي يعرض عدِّة معلومات مثيرة للاهتمام حول النظام، بما في ذلك المدة الزمنية منذ آخر إعادة تشغيل، وعدد المستخدمين، والحِمل (load) الحالي على النظام. $ uptime 9:15pm up 2 days, 2:32, 2 users, load average: 0.00, 0.00, 0.00 لعرض ناتج الأمر uptime في صفحة HTML، فسنحتاج إلى برمجة دالة الصدفة كالآتي (وذلك بعد حذف الشيفرة الوهمية التي كانت فيها): show_uptime() { echo "<h2>System uptime</h2>" echo "<pre>" uptime echo "</pre>" } كما ترى، تُخرِج الدالة السابقة نصًا يحتوي على خليطٍ من وسوم HTML مع مخرجات الأمر uptime؛ وستصبح هذه المخرجات جزءًا من here script عندما تُجرى عملية "تعويض الأوامر" في الجزء الرئيسي من السكربت. drive_space تستخدم الدالة drive_space الأمر df لتوفير ملخص للمساحة التخزينية المستهلكة من أنظمة الملفات الموصولة (mounted file systems). $ df Filesystem 1k-blocks Used Available Use% Mounted on /dev/hda2 509992 225772 279080 45% / /dev/hda1 23324 1796 21288 8% /boot /dev/hda3 15739176 1748176 13832360 12% /home /dev/hda5 3123888 3039584 52820 99% /usr ستبدو بنية دالة dive_space شبيهةً للغاية بدالة show_uptime: drive_space() { echo "<h2>Filesystem space</h2>" echo "<pre>" df echo "</pre>" } home_space ستُظهِر دالة home_space مقدار المساحة التخزينية التي يستهلكها كل مستخدم في مجلد المنزل الخاص به. سيُعرَض الناتج كقائمة مرتبة تنازليًا وفق مقدار المساحة التخزينية المستخدمة. home_space() { echo "<h2>Home directory space by user</h2>" echo "<pre>" echo "Bytes Directory" du -s /home/* | sort -nr echo "</pre>" } لاحظ أنَّه يجب تنفيذ السكربت عبر مستخدم يملك امتيازات إدارية لكي تعمل الدالة السابقة بشكلٍ صحيح، لأنَّ الأمر du يتطلب امتيازات الجذر (root) لكي يتفحص محتويات المجلد ‎/home. system_info لسنا جاهزين بعد لإكمال دالة system_info. لكننا سنُحسِّن من الشيفرة الوهمية التي فيها لكي تُنتِج وسوم HTML: system_info() { echo "<h2>System release info</h2>" echo "<p>Function not yet implemented</p>" } ترجمة -وبتصرّف- للمقالَين Shell Functions و Some Real Work لصاحبهما William Shotts.

وقعتُ أخيرًا بالصدفة على اقتباس من مطور في مشروع Mozilla عن التوتر الكامن في إنشاء المعايير القياسية: ابقِ هذه المقولة في عقلك، ولنشرح كيف أصبحت HTML5 على ما هي عليه. أنواع MIME هذه السّلسلة تتحدث حول HTML5، وليس عن إحدى إصدارات HTML السابقة أو أي إصدارٍ من XHTML، لكن لفهم تاريخ HTML5 والدوافع خلف إنشائها تمامًا، فعليك أن تستوعب بعض التفاصيل التقنية أولًا، تحديدًا أنواع MIME. في كل مرة يطلب فيها متصفح الويب صفحةً، فسيُرسِل الخادوم "ترويسات" (headers) قبل أن يرسل شيفرة الصفحة نفسها، وهذه الترويسات غير ظاهرة عمومًا على الرغم من توفر أدوات تطويرية تمكنك من رؤيتها إن كنت مهتمًا بها. لكن الترويسات مهمة لأنها تُخبر المتصفح كيف يُفسِّر الشيفرات الموجودة في الصفحة، أحد أهم تلك الترويسات هو Content-Type وهو يبدو كما يلي: Content-Type: text/html "text/html" يدعى "Content Type" أو نوع المحتوى أو نوع MIME، هذه الترويسة هي الشيء الوحيد الذي يُحدِّد طبيعة المورد المُحدَّد وكيف يجب عرضه. فالصورة لها أنواع MIME خاصة بها (image/jpeg لصور JPEG، و image/png لصور PNG، وهلمَّ جرًا)؛ ولملفات JavaScript نوع MIME خاص بها، وكذلك الأمر لصفحات الأنماط CSS، فلكل شيء في الويب له نوع MIME خاص به. وبالطبع الواقع معقَّد أكثر من هذا، فالجيل الأول من خواديم الويب (وهنا أتكلم عن خواديم الويب في 1993) لم تكن تُرسِل ترويسة Content-Type لأنها لم تكن موجودةً في ذاك الوقت (إذ لم تُستعمَل إلا في 1994)، وكانت بعض المتصفحات الشهيرة تتجاهل ترويسة Content-Type في بعض الظروف لأسبابٍ لها علاقة بالتوافقية (وهذا يسمى "content sniffing")، لكن كقاعدة عامة، كل شيء يمكنك الحصول عليه على الويب (كصفحات HTML، والصور، والسكربتات، والفيديو، وملفات PDF، وكل شيء له رابط URL) يجب أن يُخدَّم بإضافة نوع MIME المناسب في ترويسة Content-Type. خزِّن المعلومات السابقة في عقلك، وسنعود إليها لاحقًا. شرح مسهب لكيفية إنشاء المعايير لماذا لدينا عنصر <img>؟ لن تسمع مثل هذا السؤال كل يوم. بكل تأكيد أنشأه أحدهم، إذ لم تظهر تلك الأشياء من العدم، فكل عنصر وكل خاصية (attribute) وكل ميزة من ميزات HTML التي استخدمتها من قبل قد أنشأها أحدهم وقرر كيف يجب أن تعمل وكتب كل ذلك، هؤلاء الأشخاص الذين كتبوا المعايير ليسوا خارقين وإنما مجرد بَشَر ولكنهم أذكياء. أحد الأشياء الرائعة عن المعايير هي أنها طُوِّرَت على الملأ، أي أنَّك تستطيع العودة في الزمن والإجابة عن ذاك النوع من الأسئلة؛ إذ أنَّ النقاشات كانت تُجرى في القوائم البريدية، التي أُرشِفَت وأصبحت متاحةً للعموم كي يبحثوا فيها؛ لذلك قررت أن "أنقِّب" في رسائل البريد الإلكتروني كي أحاول الإجابة عن السؤال السابق: "لماذا لدينا عنصر <img>؟"، كان علي البدء في حقبةِ قبل إنشاء منظمة باسم "رابطة الشبكة العالمية" (World Wide Web Consortium اختصارًا W3C)، ذهبت إلى الأيام الأولى للويب، حيث كنتَ تستطيع عدّ صفحات الويب على أصابع اليدين. في 25 شباط/فبراير من عام 1993، كتب Marc Andreessen: كانت صيغتا Xbm و Xpm صيغتَا رسوميات شهيرتان في أنظمة يونكس. "Mosaic" كان من أوائل متصفحات الويب ("X Mosaic" كان الإصدار الذي يعمل على أنظمة يونكس)، عندما كتب Marc Andreessen رسالته في بدايات 1993، لم يكن قد أسس الشركة التي جعلته مشهورًا (شركة Mosaic Communications Corporation)، ولم يكن بدأ العمل على المنتج الرائد في تلك الشركة: "Mosaic Netscape" (ربما تعرفها بأسمائها الحديثة "Netscape Corporation" و "Netscape Navigator"). عبارته "ربما أنواع MIME" كانت تُشير إلى ميزة Content negotiation في HTTP، حيث يُخبر العميل (أي متصفح الويب) الخادوم (أي خادوم الويب) ما هي أنواع الوسائط التي يدعمها (مثل image/jpeg) ومن ثم سيُرسِل الخادوم الوسائط إلى العميل بالصيغة التي يُفضلِّها. عُرِّفَت الصيغة الأصلية من HTTP في 1991 (وهي النسخة الوحيدة التي كانت موجودةً في شباط/فبراير 1993) ولم تكن توفِّر طريقةً للعملاء لأن يخبروا الخواديم ما هي صيغ الصور التي يدعموها، وهذه هي المعضلة التي واجهها Marc. بعد عدِّة ساعات، ردِّ Tony Johnson: Midas هو متصفح آخر من فترة بدايات الويب، وكان منافسًا لمتصفح X Mosaic، وكان متعدد المنصات، إذ كان يعمل على أنظمة يونكس و VMS. أما "SLAC" فهي تُشير إلى Stanford Linear Accelerator Center التي أصبح اسمها الآن "SLAC National Accelerator Laboratory" التي استضافت أول خادوم ويب في الولايات المتحدة (وفي الواقع، أول خادوم ويب خارج أوروبا). عندما كتب Tony هذه الرسالة، كانت SLAC من المحاربين القدامى في الشبكة العالمية، التي استضافت خمس صفحات على خادوم الويب الخاص بها لمدة 441 يومًا. أكمل Tony قائلًا: قصد ببروتوكول "HTTP2" بروتوكول HTTP الأساسي المُعرِّف في 1992، الذي لم يُطبَّق تطبيقًا كاملًا في بدايات 1993، وعُرِفَت المسودة باسم HTTP2 ثم أصبحت معيارًا قياسيًا باسم "HTTP 1.0" (بالرّغم من أن الأمر قد تم ذلك بعد ثلاثة أعوام)، تضمَّن بروتوكول HTTP 1.0 ترويسات طلبات لتحديد صيغة المحتوى (request headers for content negotiation)، أي أنواع MIME. أكمل Tony: لم يُطبَّق اقتراحه أبدًا، إلا أنَّ فكرة توفير نص إن لم تتوفر الصورة هي تقنية مهمة لتسهيل الوصول التي كانت ناقصة من اقتراح Marc الأولي لوسم <IMG>. استعملت هذه الميزة في خاصية <img alt>، التي أساء متصفح Netscape معاملتها باعتبارها تلميحًا (tooltip). بعد عدِّة ساعات من إرسال Tony لرسالته، ردَّ Tim Berners-Lee عليها: لم يُطبَّق هذا الاقتراح مطلقًا، لكن خاصية rel ما زالت موجودةً. أضاف Jim Davis: لم يُطبَّق هذا الاقتراح قط، لكن أضاف متصفح Netscape لاحقًا دعمًا لتضمين عناصر الوسائط المتعددة باستعمال عنصر <embed>. سأل Jay C. Weber: ردَّ Marc Andreessen: أجاب Jay C. Weber له قائلًا: أدركنا بعد فوات الأوان أنَّ مخاوف Jay كان لها أساسٌ من الصحة لكن ذلك استغرق فترةً طويلةً، فقد أضافت HTML5 أخيرًا عنصرَيّ <video> و <audio>. ردًا على رسالة Jay الأصلية، قال Dave Raggett: لاحقًا في 1993، اقترح Dave Raggett معيار HTML+‎ الذي كان تطويرًا لمعيار HTML. لكن لم يُطبَّق اقتراحه مطلقًا، ثم حلَّت HTML 2.0 محله التي أعطت طابعًا رسميًا للميزات شائعة الاستعمال: "هذا المعيار يضفي توضيحًا وطابعًا رسميًا لمجموعة من ميزات HTML التي كانت شائعة الاستعمال قبل حزيران/يونيو عام 1994". كتب Dave لاحقًا معيار HTML 3.0 المبني على مسودة HTML+‎ التي كتبها سابقًا، وذلك خارج إطار W3C للمعايير (المسمى Arena)؛ لكن لم تُطبَّق HTML 3.0 أبدًا، وحلَّت محلها HTML 3.2، التي رسَّمَت الميزات كالإصدار السابق HTML 2.0: "أضافت HTML 3.2 الميزات شائعة الاستخدام مثل الجداول، و applets والتفاف النص حول الصور، بالإضافة إلى توافقيتها مع معيار HTML 2.0". شارك Dave لاحقًا بوضع معيار HTML 4.0، وطوَّر HTML Tidy، وشارك في المساعدة بتطوير XHTML، و XForms، و MathML، وغيرها من معايير W3C الحديثة. بالعودة إلى 1993، رد Marc على Dave: Intermedia هو مشروعٌ من جامعة Brown، طوِّر من عام 1985 إلى 1991 وكان يعمل على نظام A/UX، الذي هو نظام شبيه بِيونكس (Unix-like) لحواسيب ماكنتوش في ذاك الوقت. راجت فكرة "لغة لتوصيفِ الرسومات ذاتُ غرضٍ عام"، وذلك بدعم المتصفحات الحديثة لصيغة SVG (لغة توصيفية يمكن دمج السكربتات معها)، و <canvas> (واجهة برمجية [API] إجرائية [procedural] مباشرة)، على الرغم من أن الأخيرة بدأت كإضافة مملوكة (proprietary extension) قبل أن يتم ترسيمُها من WHATGW. ردBill Janssen: "Andrew" هو إشارة إلى Andrew User Interface System (إلا أنه كان يسمى في ذاك الوقت Andrew Project). في ذاك الحين، وجد Thomas Fine فكرةً مختلفةً: "Display Postscript" هي تقنية لعرض Postscript على الشاشة طوِّرَتها كل من Adobe و NeXT. لم يُطبَّق هذا الاقتراح أبدًا، لكن الفكرة أنَّ أفضل طريقة لحل مشاكل HTML هي استبدال شيءٍ ما آخر بها ما زالت تظهر من وقتٍ لآخر. قال Tim Berners-Lee في الثاني من آذار/مارس عام 1993: HyTime كان نظام مستندات قديم مبني على SGML، وقد أثَّرَ كثيرًا في النقاشات الأولية للغة HTML، ولاحقًا لغة XML. لم يُطبَّق اقتراح Tim لوسم <INCLUDE> مطلقًا، لكنك تجده صداه واضحًا في عناصر <object> و <embed> و <iframe>. في النهاية، قال Marc Andreessen في الثاني عشر من آذار/مارس عام 1993: ترجمة -وبتصرّف- لفصل A Quite Biased History of HTML5 من كتاب Dive Into HTML5 لمؤلفه Mark Pilgrim. اقرأ أيضًا المقال التالي: نظرة على تاريخ HTML - الجزء الثاني المقال السابق: خمسة أشياء عليك معرفتها عن HTML5 النسخة الكملة لكتاب نحو فهم أعمق لتقنيات HTML5

سنشرح في هذا الدرس كيف نوزِّع شيفرات على عدِّة ملفات وكيف نُضمِّن شيفرات من ملفات أخرى. توفِّر PHP أربع دوال لتضمين الشيفرات من الملفات الأخرى: include include_once require require_once الدالة include تُستعمَل include لتضمين الملفات الخارجية إلى الملف الحالي، حيث تنسخ النص من الملف الخارجي وتلصقه مكان وجودها، وإن حدثت أيّة أخطاء فستتجاوز هذه الدالة عملية تضمين الملف وسيُستكمَل التنفيذ مع إظهار تحذير (warning) دون إظهار خطأ (error). على سبيل المثال، لدي ملفان هما tutorials.php و tutorials2.php في نفس المجلد. الملف tutorials2.php: <?php /** * this is another class in file tutorial2.php */ class Bird { function __construct() { echo "class Bird included"; } } ?> الملف tutorials.php: <?php include 'tutorial2.php'; // كما يُمكن أن نكتبه على النّحو التّالي include('tutorial2.php'); $obj = new Bird(); ?> الناتج: class Bird included الدالة include_once هذه الدالة شبيهة بالدالة include لكن الاختلاف أنها تُضمِّن الملف مرةً واحدةً فقط؛ مثلًا، إن كان لديك ملفُ آخرٌ يُضمِّن كلا الملفين السابقين باستخدام include فسيُضمَّن الصنف Bird مرتين وسينتج عن ذلك خطأ لأنه لا يُسمَح بإعادة تعريف الصنف مرةً أخرى. وهذا الأمر يحدث كثيرًا في المشاريع أو التطبيقات الكبيرة، لذا يكون البديل هو استخدام include_once التي ستُضمِّن tutorial2.php مرةً واحدةً فقط. الدالة require تعمل require كعمل include إلا أنها تعطي خطأً (بدلًا من تحذير) عندما يحدث خطأ في تضمين الملف، ويتوقّف البرنامج عن التّنفيذ. الدالة require_once وهي تعمل أيضًا بشكلٍ شبيهٍ بالدالة include_once إلا أنها تعطي خطأً بدلًا من تحذير كما في require، ويتوقّف البرنامج أيضًا. مسار التضمين كان لدينا في المثال السابق كلا الملفين في نفس المجلد ثم ضمَّنا الملف tutorial2.php مباشرةً، وهذا ما يدعى "بالمسار النسبي"؛ لكن كيف يمكننا أن نضمِّن ملفًا من مجلدٍ آخر؟ يمكننا تمثيل المسار إلى الملف بطريقتين: المسارات النسبية المسارات المطلقة المسارات المطلقة وهي مسار الملف بدءًا من مجلد الجذر؛ الذي يكون في لينكس (وغيره من الأنظمة الشبيهة بِيونكس) كالآتي: include_once( '/var/www/html/findalltogether/tutorial2.php' ); أما في ويندوز، فسيبدأ المسار المطلق بحرف القرص (مثل C:\www\html\tutorial2.php)، لاحظ أنَّ الشرطة المائلة الخلفية (\) هي التي تستعمل في المسارات في ويندوز. المسارات النسبية وهي مسار الملف نسبةً إلى الملف الحالي (أي الملف الذي يجري عملية التضمين)؛ حيث يمكن أن يكون الملف في ثلاثة أماكن نسبية: أن يكون في نفس مجلد الملف الذي يجري عملية التضمين أن يكون ضمن مجلد في نفس مجلد الملف الذي يجري عملية التضمين أن يكون المجلد الأب (parent) أو في مجلدٍ موجودٍ في المجلد الأب لنتناول شرح كل حالةٍ على حدة: لقد استعملنا مسبقًا الحالة الأولى، ولقد وضعنا اسم الملف مباشرةً إن كان في نفس المجلد 2. أما في الحالة الثانية، فعلينا أن نضيف اسم المجلد؛ فمثلًا إن كان الملف موجودًا في مجلدٍ باسم folder فسيكون سطر التضمين هو: ‎include('folder/tutorial2.php');‎ أما لو كان هنالك أكثر من مجلد فرعي، فسنحتاج إلى كتابة أسمائها أيضًا: ‎include('first/second/third/tutorial2.php');‎ 3. في الحالة الأخيرة، سنستعمل "‎../‎" (نقطتين ثم خط مائل) كي ننتقل إلى المجلد السابق؛ وبفرض أنَّ الملف الحالي موجودٌ في ‎/var/www/html/tutorials/include/tutorials.php ونريد تضمين الملف ‎/var/www/html/another/tutorial2.php، فسنستعمل: ‎include('../../another/tutorial2.php');‎ لتضمينه، إذ أنَّ ‎../‎ تعني أننا ننتقل إلى الخلف مجلدًا واحدًا فقط. مجالات الأسماء في المشاريع الكبيرة، من الممكن (وهذا يحدث عادةً) أن يكون لدينا دالتان أو صنفان لهما نفس الاسم في مكتبتين أو ملفين مختلفين؛ ونحتاج أحيانًا أن نضمن كلا الملفين في نفس الملف، مما يؤدي إلى حدوث خطأ لأنه لا يجوز أن نعيد تعريف دالة أو صنف أكثر من مرة واحدة؛ لذا جاءت مجالات الأسماء (namespaces) للمساعدة في تجنب تلك التضاربات. مجالات الأسماء كالمجلدات، حيث لا نستطيع أن نضع ملفين بنفس الاسم في نفس المجلد، وبالمثل لا نستطيع تعريف دالتين أو صنفين في نفس مجال الأسماء، لكن نستطيع فعل ذلك في مجال أسماءٍ مختلف. لنفترض مثلًا أننا نبرمج نظامًا للتسوق، ولدينا دالتَا عرض مختلفتين، واحدة في ملف car.php كي تُظهِر عربة التسوق والأخرى في checkout.php لتظهر معلومات الدفع؛ ونريد تضمين هاتين الدالتين في ملفٍ سينفِّذ الدالة ‎display()‎ من ملف checkout.php إن ضغط المستخدم على زر "checkout"، وسيستدعي الدالة display()‎ من ملف cart.php فيما عدا ذلك. علينا هاهنا أن نستعمل مجالًا للأسماء، حيث سنُعرِّف كل دالة بمجال أسماءٍ مختلف كي لا تظهر أيّة أخطاء عند تضمين كلا الملفين سويةً. ملف checkout.php: <?php namespace Checkout; function display() { // code for display function echo "dispay in checkout"; } ?> ملف cart.php: <?php namespace Cart; function display() { //code of dispay function in cart echo "display in cart"; } ?> ملف tutorials.php: <?php // including files in different namespace require 'checkout.php'; require 'cart.php'; // checking condition if ( $action == "checkout" ) { // calling from checkout namespace Checkout\display(); } else { // calling from cart namespace Cart\display(); } ?> لاحظ ما يلي في الأمثلة السابقة: تُنشَأ مجالات الأسماء بكتابة namespace NamespaceName;‎ بعد وسم ‎<?php نستطيع استدعاء الدوال والأصناف من مجالات أسماء معيّنة بكتابة NamespaceName\functionName()‎ و NamespaceName\classname‎ على التوالي وبالترتيب مجالات الأسماء الفرعية والكلمة المفتاحية use يمكننا تعريف مجال فرعي كما لو كنا ننشِئ مجلدًا فرعيًا، الشكل العام لتعريفه هو ‎namespace NamespaceName/subNamespaceName/anotherSubNamespace;‎ وطريقة استعمال مجالات الأسماء الفرعية مماثلة تمامًا لاستعمال مجالات الأسماء العادية؛ وعندما يكون المشروع كبيرًا ويحتوي الكثير من مجالات الأسماء الفرعية، فسيصبح من المزعج أن نكتب نفس الاسم مرارًا وتكرارًا، لذا توفِّر لغة PHP الكلمة المحجوزة «use» لهذا الغرض، إذ تُسنِد use اسم مجال الأسماء الفرعي بأكمله إلى اسمٍ ذي كلمةٍ وحيدة. use longNamespaceName as shortName; يمكنك بعد ذلك أن تستعمل الاسم القصير لمجال الأسماء بدلًا من كتابة كل الاسم، يدعى الاسم القصير بالاسم البديل (alias). <?php require "checkout.php"; // نعرف اسمًا أقصر للاسم الأطول use Namespace\SubNamespace\FrontEnd\Checkout as NewCheckout; NewCheckout\display(); ? > التحميل التلقائي للأصناف العديد من المبرمجين الذين يكتبون برامج كائنية التوجه يُنشئون ملفًا لكل صنف، ومن أكثر الأشياء التي تزعجهم هي كتابة قائمة طويلة من الملفات التي يجب تضمينها في بداية كل ملف. لم يعد ذلك ضروريًا في PHP 5، فأصبحت هنالك طريقة لتضيمن الأصناف تلقائيًا عند الحاجة إليها. يمكننا استعمال التحميل التلقائي للأصناف عبر الدالةspl_autoload_register()‎، وهذه الدالة مرنة جدًا، وتسمح باستخدام أكثر من محمل تلقائي (autoloader)، هذا مثالٌ عن استخدامها: <?php spl_autoload_register(function ($class_name) { include $class_name.'.php'; }); $obj = new MyClass1(); $obj2 = new MyClass2(); ?> تقبل دالة spl_autoload_register وسيطًا هو الدالة التي ستضمن ملفات الأصناف، فإما أن تُعرِّف الدالة ثم تمرر اسمها إلى دالة spl_autoload_register، أو أن تعرف دالة مجهولة مباشرةً داخل الدالة spl_autoload_register كما في المثال السابق. مثالٌ عن الحالة الأولى: <?php function my_autoloader($class_name) { include $class_name.'.php'; } spl_autoload_register('my_autoloader'); ?> في هذه الحالة ولدى محاولة استخدام صنف غير مُعرّف في نفس الملف مثل: $car = new Car; سيقوم PHP بمحاولة تحميل الملف Car.php (يبحث في المُجلّد الحالي) وإن وجده يقوم بإنشاء مُتغير جديد من صنف Car. التحميل التلقائي في Composer شاع استعمل Composer لإدارة حزم المكتبات البرمجية في PHP، إن أردت الاطلاع على المزيد من المعلومات حوله، فانظر إلى مقالة ما هو Composer ولماذا يجب على كل مطور PHP استخدامه. يُنشِئ Composer الملف vendors/autoloader.php الذي يتيح تضمين المكتبات الضرورية لعمل مشروعك تلقائيًا دون الحاجة إلى فعل ذلك يدويًا، وذلك عبر تضمين ذاك الملف في شيفرات PHP: <?php require_once "vendors/autoloader.php"; أسهل طريقة هي تحديد كل صنف على حدة، وسنُعرِّف لهذا الغرض مصفوفةً تحتوي على مسارات الملفات التي نريد تحميلها تلقائيًا في ملف composer.json، ربما تستفيد من هذه الطريقة في تضمين الملفات التي تحوي دوال PHP التي لا يمكن تحميلها تلقائيًا: { "autoload": { "files": ["src/MyLibrary/functions.php"] } } أو عبر PSR-4، التي تسمح لك بربط مجالات الأسماء إلى مسارات نسبية (relative paths) لجذر الحزمة، فعند التحميل التلقائي لصنف مثل Foo\\Bar\\Abz، فإن سابقة (prefix) مجال الأسماء Foo\\‎ التي تشير إلى المجلد src/‎ تعني أن آلية التحميل التلقائي ستبحث عن ملف باسم src/Bar/Baz.php وتضمِّنه إن كان موجودًا: { "autoload": { "psr-4": { "Monolog\\": "src/", "Vendor\\Namespace\\": "" } } } ولو أردت أن تبحث عن نفس السابقة في أكثر من مجلد، فعليك تحديد تلك المجلدات في مصفوفة كالآتي: { "autoload": { "psr-4": { "Monolog\\": ["src/", "lib/"] } } } وتستطيع توفير مجلد افتراضي إن لم يُعرَّف مجال الأسماء للصنف الذي يراد تحميله تلقائيًا، وذلك بترك مكان السابقة فارغًا: { "autoload": { "psr-4": { "": "src/" } } } المصادر مقال Distribute code in files in PHP لصاحبه Harish Kumar توثيق Composer صفحات include و require و Autoloading Classes و spl_autoload_register و ‎‎__autoload

رأينا في الدرس السابق كيف كتبنا سكربتًا يولِّد صفحة HTML، لكن هذا ليس كافيًا لنا، فلنقم ببعض التعديلات. #!/bin/bash # sysinfo_page - A script to produce an HTML file cat <<- _EOF_ <html> <head> <title> My System Information </title> </head> <body> <h1>My System Information</h1> </body> </html> _EOF_ هل لاحظت كيف أنَّ العبارة "My System Information" مكررة مرتين في السكربت السابق؟ لنُحسِّنها هكذا: #!/bin/bash # sysinfo_page - A script to produce an HTML file title="My System Information" cat <<- _EOF_ <html> <head> <title> $title </title> </head> <body> <h1>$title</h1> </body> </html> _EOF_ أضفنا سطرًا إلى بداية السكربت ووضعنا ‎$title بدلًا من العبارة "My System Information". المتغيرات ما فعلناه في الأعلى سيمهد لنا الطريق لشرح فكرة أساسية جدًا موجودة في جميع لغات البرمجة تقريبًا: المتغيرات (variables). المتغيرات هي أماكن في الذاكرة يمكن أن تُستعمَل لتخزين المعلومات، ويُشار إليها باسمٍ مُميِّزٍ لها. أنشأنا في السكربت السابق متغيرًا اسمه title ووضعنا العبارة "My System Information" في الذاكرة، ثم استخدمنا ‎$title لإخبار الصَدَفة أننا نريد إجراء "توسعة المعاملات" (parameter expansion) ونضع محتوى المتغير بدلًا من اسمه. عندما ترى الصَدَفة كلمةً تبدأ برمز $ فستحاول معرفة إذا كانت تُشير تلك الكلمة إلى متغير، ثم ستضع القيمة المُخزَّنة فيه -أي المتغير- مكان ورود تلك الكلمة. كيفية إنشاء متغير كل ما عليك فعله لإنشاء متغير هو وضع اسم المتغير في سطرٍ مستقل متبوعًا برمز المساواة (=) دون أيّة فراغات، ثم كتابة المعلومات التي تريد إسنادها بعد رمز المساواة. أسماء المتغيرات حسنًا، أنت من يُسمي المتغيرات، لكن هنالك بعض القواعد التي عليك مراعاتها: يجب أن تبدأ أسماء المتغيرات بحرف. يجب ألّا يحتوي اسم المتغير على فراغات. استخدم الشرطات السفلية (_) بدلًا منها. لا تستطيع استخدام علامات الترقيم. كيف أثر المتغير على السكربت الذي نكتبه سهَّلت إضافة المتغير title الأمر علينا من ناحيتين: الأولى هي تقليل مقدار الكتابة الذي نحتاجه، والثانية (وهي المهمة) هي أننا جعلنا صيانة السكربت أسهل. كلما ازدادت خبرتك في كتابة سكربتات الشِل (أو أي لغة برمجة أخرى)، فستتعلم أنَّك لا تنتهي من كتابة البرنامج في خطوة واحدة، فهنالك تعديلات وتحسينات من قبِل كاتب البرنامج أو من غيره؛ وهذا هو حجر الأساس لعملية تطوير البرمجيات مفتوحة المصدر. فلنقل مثلًا أنَّك تريد تغيير العبارة "My System Information" إلى "Linuxbox System Information"، فكنت تحتاج -في النسخة القديمة من السكربت- إلى تغيير تلك العبارة في مكانين منفصلين، أما في النسخة الجديدة التي فيها المتغير title فلا حاجة إلى تغيير تلك العبارة إلا في مكانٍ وحيد. قد تظن أنَّ هذا التغيير تافه أو ليس له فائدة حقيقية، لكن ذلك لأنَّ السكربت الذي نكتبه ما يزال بسيطًا وقصيرًا؛ لكن التنظيم أساسيٌ جدًا في السكربتات الكبيرة والمعقدة. متغيرات البيئة Environment Variables هنالك بعض المتغيرات المضبوطة في جلسة الصَدَفة من قِبل ملفات البدء التي رأيناها سابقًا. استعمل الأمر printenv لرؤية جميع المتغيرات الموجودة في البيئة عندك؛ يحتوي أحد تلك المتغيرات "اسم المضيف" (hostname) لنظامك؛ ونستطيع أن نُضيف ذاك المتغير إلى السكربت كالآتي: #!/bin/bash # sysinfo_page - A script to produce an HTML file title="System Information for" cat <<- _EOF_ <html> <head> <title> $title $HOSTNAME </title> </head> <body> <h1>$title $HOSTNAME</h1> </body> </html> _EOF_ أصبح السكربت الآن يضع اسم الحاسوب الذي نعمل عليه في صفحة HTML الناتجة. لاحظ أنَّ أسماء متغيرات البيئة (وفق التقاليد البرمجية) تُكتَب بأحرفٍ كبيرة. تعويض الأوامر سنحاول الآن تحسين السكربت بوضع ناتج من أحد الأوامر فيه. كانت آخر نسخة من السكربت قادرةً على إنشاء صفحة HTML تحتوي على أسطر نصية بسيطة تتضمن اسم المضيف لجهازنا المأخوذ من متغير البيئة المسمى HOSTNAME، سنُحدِّث السكربت الآن لإضافة بصمة وقت إلى الصفحة لكي تُشير إلى آخر تحديث لها، مع ذكر اسم المستخدم الذي قام بالتحديث. #!/bin/bash # sysinfo_page - A script to produce an HTML file title="System Information for" cat <<- _EOF_ <html> <head> <title> $title $HOSTNAME </title> </head> <body> <h1>$title $HOSTNAME</h1> <p>Updated on $(date +"%x %r %Z") by $USER</p> </body> </html> _EOF_ كما لاحظت، استعملنا متغير بيئة جديد هو USER لكي نحصل على اسم المستخدم؛ واستعملنا تعبيرًا غريب المظهر: $(date +"%x %r %Z") المحارف ‎$()‎ تقول "يجب وضع ناتج الأمر المُحاط بالأقواس هنا". وأردنا في السكربت السابق وضع ناتج الأمر date +"%x %r %Z"‎ الذي يطبع التاريخ والوقت الحاليين. لدى الأمر date ميزاتٌ وخياراتُ تنسيقٍ كثيرة، نستطيع إلقاء نظرة عليها كالآتي: $ date --help | less لاحظ أنَّ هنالك صيغة قديمة بديلة عن (‎$(command هي استخدام علامة الاقتباس الخلفية "`"، هذه الصيغة القديمة متوافقة مع صَدَفة Bourne Shell الأصلية (sh)؛ لكنني لا أنوي استخدام الشكل القديم لأنني أشرح استخدام bash الحديثة وليس sh. تدعم صَدَفة bash جميع السكربتات المكتوبة لـ sh، ولهذا تكون الصيغتان الآتيتان متكافئتين: $(command) `command` إسناد ناتج أحد الأوامر إلى متغير يمكننا أيضًا إسناد ناتج أحد الأوامر إلى متغير: right_now=$(date +"%x %r %Z") نستطيع أيضًا وضع متغير داخل متغير آخر كما يلي: right_now=$(date +"%x %r %Z") time_stamp="Updated on $right_now by $USER" الثوابت كما يوحي اسم "المتغيرات": قيمة المتغير قابلة للتبديل، وهذا يعني أنَّه من المحتمل أثناء تنفيذ السكربت أن تُعدَّل قيمة المتغير نتيجةً لعمليةٍ قمتَ بها. في المُقابل، هنالك قيم يجب ألّا تتغير بعد ضبطها، وتسمى "الثوابت" (constants). سبب ذكري لهذا الموضوع هو أنَّ مفهوم الثوابت شائعٌ في البرمجة، وتدعمها أغلبية لغات البرمجة، لكن لكي أكون صريحًا معك، لم أشاهد استعمالًا عمليًا لها. فلو كان من المفترض أن تبقى قيم المتغير ثابتةً فسيسمى المتغير بأحرفٍ كبيرة لتذكير المبرمج أنَّ قيمة المتغير ثابتة. تُعتبَر متغيرات البيئة ثوابتَ لأنها نادرًا ما تتغير؛ وتُعطى الثوابت أسماءً ذات أحرفٍ كبيرة عادةً. سأستعمل العرف الآتي في هذا السكربت: الأحرف الكبيرة للثوابت والأحرف الصغيرة للمتغيرات. يبدو السكربت الذي نعمل عليه كالآتي حاليًا: #!/bin/bash # sysinfo_page - A script to produce an HTML file title="System Information for $HOSTNAME" RIGHT_NOW=$(date +"%x %r %Z") TIME_STAMP="Updated on $RIGHT_NOW by $USER" cat <<- _EOF_ <html> <head> <title> $title </title> </head> <body> <h1>$title</h1> <p>$TIME_STAMP</p> </body> </html> _EOF_ ترجمة -وبتصرّف- للمقالَين Variables و Command Substitution And Constants لصاحبهما William Shotts.

قد تكون عملية نقل المحتوى من موقع ووردبريس إلى آخر عمليةً تُضيّع الوقت وتُسبِّب الصداع، إذ لا تستطيع ببساطة نقل الملفات وقاعدة البيانات؛ لا تعمل ووردبريس هكذا! لحسن الحظ، هنالك أداة "استيراد" (Import) و"تصدير" (Export) في ووردبريس، لكن تلك الأدوات -لسوء الحظ- بسيطة جدًا ويلزم تطويرها لكي تلبي احتياجاتك الأخرى. سأشرح في هذا المقال خطوةً بخطوة كيفية نقل ووردبريس من مكانٍ إلى آخر. قبل أن نبدأ: خذ نسخة احتياطية من موقعك قد تكون هنالك خصوصيات لبعض حالات تثبيت ووردبريس ستؤدي إلى عرقلة عملية نقل المحتوى؛ وعلى الرغم من أنَّ هذه المقالة ستتعامل مع بعض الحالات الخاصة (عملية نقل جزء من محتوى ووردبريس تحديدًا)، لكن لا توجد ضمانة أنَّ الخطوات الموضحة هنا ستعمل بسلاسة لكل حالات التثبيت. ومن الغني عن الذكر أنَّك مسؤولٌ وحدك عن موقعك، حتى لو اتبعت هذا الدليل حتى النهاية؛ هنالك أيضًا بعض العمليات التي عليك إجراؤها على قاعدة البيانات اعتمادًا على ما الذي تريد فعله؛ وإذا أخطأتَ وحذفتَ كمية كبيرةً من البيانات فلا تلومن إلا نفسك! أنصحك بتوخي الحذر كثيرًا في هذا الصدد. أنشأتُ نسختين منفصلتين من ووردبريس مثبتتين على الخادوم المحلي لكي أوفر لك صورًا لكل خطوة من الخطوات. ربما قد ترغب في نقل محتواك إلى موقع تجريبي كبداية لتتحقّق من أن العملية ستتم كما هو مخطّط له. في النهاية، أنصحك أن تأخذ نسخةً احتياطيةً لكل الموقع في هذه المرحلة؛ لكنك بالطبع تفعل ذلك بشكلٍ دوري، صحيح؟ (إن لم تكن تأخذ نسخًا احتياطية، فأنصحك بفعل ذلك فورًا). إذا أردت القيام بعملية النقل يدويًا، فتذكر أن تُضمِّن قاعدة البيانات الخاصة بك بالإضافة إلى ملفات الموقع (وذلك لأنها تتضمن الملفات التي رفعتها على موقعك). نسخ الملفات احتياطيا يمكنك إنشاء وتنزيل نسخة ZIP من موقعك عبر FTP؛ وهذا يختلف باختلاف عميل FTP الذي تستخدمه، لكن العملية بسيطة وسهلة التطبيق. تأكد أنَّك تنزل وتحفظ ملف النسخة الاحتياطية المضغوط بشكل آمن، مثَلهُ كَمَثَلِ أيّ نسخةٍ احتياطيةٍ أخذتها سابقًا. نسخ قاعدة البيانات احتياطيا سجل دخولك إلى حسابك في phpMyAdmin واختر قاعدة البيانات التي ثبتت فيها ووردبريس. اضغط على Export في القائمة العلوية، ثم اختر Quick الذي يكون ملائمًا لأغلبية الحالات، لكن إن كان عندك جداول لأكثر من نسخة من ووردبريس في نفس قاعدة البيانات، فاضغط على Custom واختر الجداول التي تريد أخذ نسخة احتياطية منها؛ اترك جميع الخيارات البقية على حالها، وفي النهاية اضغط على Go لتنزيل ملف النسخ الاحتياطي لقاعدة بياناتك (بصيغة sql). إذا جرت الأمور كما هو متوقع، فلن نحتاج إلى النسخة الاحتياطية، لكن من المُستحسن دائمًا أخذ نسخة احتياطية قبل الإقدام على إجراء عملية كالتي سنفعلها. وإن كان في الموقع الذي ستنقل المحتوى إليه بعض المقالات، فيجب أخذ نسخة احتياطية له كذلك. لنبدأ العمل بعد أخذ الاحتياطات اللازمة. تغيير عنوان URL موقع ووردبريس: نقل موقع كامل إذا كنت تفكر في تغيير رابط URL لموقعك أو تريد نقل كل شيء من نسخة إلى أخرى، فاعلم أنَّك قد انتقيت أسهل خيار؛ فأدوات ووردبريس للتصدير (Export) والاستيراد (Import) ستفي تمامًا بالغرض، وليس عليك القيام بأي عمليات معقدة. إليك طريقة نقل جميع محتويات موقع ووردبريس من صفحات وصور وملفات ومنشورات …إلخ. إلى موقع جديد. من الأسهل أن تُنشِئ نسخة ووردبريس جديدة على خادومك الجديد (أو في مكانٍ آخر في نفس الخادوم) ثم تستخدم التصدير/الاستيراد بدلًا من نقل ملفات الضبط. يجب أن تكون نسخة ووردبريس عندك محدثةً إلى آخر إصدار، وإن لم تكن محدَّثةً فعليك ترقيتها أولًا؛ وإن لم تستطع الترقية لسببٍ من الأسباب -مثل الحاجة إلى استخدام إضافة معينة لا تعمل على الإصدارات الحديثة- فيمكن أن تُثبِّت إصدارًا قديمًا، لكن ذلك ليس مستحسنًا لاحتمال وجود مشكلات أمنية في الإصدارات القديمة من ووردبريس. أولا: التصدير من الموقع القديم افتح لوحة التحكم في ووردبريس واضغط على Export (تصدير) من قائمة Tools (أدوات). أبقِ على خيار All content (كل المحتوى) مُفعَّلًا لأنك تريد تصدير كل شيء، ثم اضغط على Download Export File (تحميل ملف التصدير). سيتم إنشاء ملف XML. أبقه في مكانٍ آمن ريثما تنقله إلى الموقع الجديد. ثانيا: تثبيت إضافة الاستيراد تثبيت إضافة WordPress Importer: الآن في موقع ووردبريس الجديد الذي تريد الانتقال إليه، اذهب مرةً أخرى إلى Tools (الأدوات) لكن هذه المرة اختر Import (استيراد). ستظهر لك قائمة بآليات الاستيراد المتوفرة، التي عليك أن تختار WordPress من بينها. اضغط على Install Now ثم انتظر تنزيل وتثبيت الإضافة. عليك بعدها -إن جرت الأمور على ما يرام- أن تضغط على Activate Plugin & Run Importer في الصفحة التي ستظهر لك. يجب أن تكون قادرًا في هذه المرحلة على استيراد ملف XML الذي أنشأتَه في الخطوة السابقة. ثالثا: رفع المحتوى اضغط على Choose File (اختر ملف) واختر ملف XML الذي أنشأتَه في موقعك القديم. اضغط بعدها على زر Upload file and import (رفع الملف واستيراده). رابعا: اختيار المحتوى ستُعطى خيارًا لإسناد المحتوى الذي سيتم استيراده إلى مستخدمين موجودين في موقعك الجديد (إذا كان لديك حساب مستخدم في الموقع القديم والجديد، فيمكنك إسناد مقالاته في الموقع القديم إلى حسابه في الموقع الجديد)، أو يمكنك إنشاء المستخدمين إما بأن تكون لهم نفس أسمائهم القديمة أو أن تُنشِئ واحدًا جديدًا تختاره أنت، وهذا يضمن أنَّ كل المحتوى الذي سيتم استيراده سيُسنَد إلى حساب مستخدمٍ ما موجود في الموقع الجديد. إذا كانت لديك أيّة صور أو ملفات تريد نقلها إلى الموقع الجديد، فعليك بكل تأكيد أن تختار الخيار Download and import file attachments (تنزيل واستيراد المرفقات)، لاحظ أنَّه ليس مفعلًا افتراضيًا. اضغط على زر Submit لإكمال عملية الاستيراد. قد يكون تحميل الصفحة أطول من المعتاد بسبب إنشاء سجلات جديدة في قاعدة البيانات، لكن سينتهي تحميلها حكمًا. انتظر بصبر إلى أن تكتمل العملية وبعدها ستجد أنَّ جميع محتوى موقعك السابق قد تم استيراده إلى موقعك الجديد الذي دبَّت فيه الحياة! نقل جزئي للمحتوى حسنًا، ما سبق كان سهلًا للغاية، لكن إن كنت تتطلع نحو تصدير بعض محتويات موقعك، فللأسف لن تكون أدوات ووردبريس وحدها كافيةً بالنسبة إليك. اختيار All content (كل المحتوى) هو الطريقة الوحيدة لتصدير المرفقات (أي الملفات التي تظهر في قسم Media أو الوسائط)؛ أي لو أردت نقل أجزاء مُحدَّدة من المحتوى بالإضافة إلى الصور المرتبطة بتلك الأجزاء، فأنت هنا أمام خيارين: إما أن تنقل كل المحتوى ثم تحذف الأجزاء التي لا تريدها (وهذه مضيعةٌ للوقت، خصوصًا في المواقع الكبيرة)، أو أن تحاول نقل الملفات وقاعدة البيانات يدويًا، وهذا ما سأريك إياه الآن. سأشرح عملية تصدير وتعديل SQL التي سأريك إياها لغرض ألا وهو نقل المرفقات؛ لكن يمكنك استخدام طريقة مماثلة لها بنقل قاعدة البيانات كلها، وهذا مفيدٌ إذا أردت نقل كل المحتوى لكن ملف XML الناتج كبيرٌ للغاية ولا يمكن رفعه عبر أداة الاستيراد. أولا: اختيار المحتوى الذي تريد تصديره اذهب مرةً أخرى إلى Tools (الأدوات) ثم Export (تصدير). بعد اختيارك للمحتوى الذي تريد تصديره، اضغط على Download Export File. إذا كنت تريد اختيار أكثر من مستخدم على سبيل المثال، أو أكثر من مجال زمني، أو جميع الصفحات (pages) وجميع المنشورات من مستخدم معيّن، فيمكنك العودة إلى هذه الصفحة وإنشاء عدِّة ملفات تصدير. ثانيا: استيراد الملفات المصدرة بعد أن تصبح لديك جميع ملفات WXR XML التي تريد استيرادها، فانتقل إلى الموقع الجديد وثبِّت إضافة WordPress Importer كما رأيت سابقًا. يمكنك رفع ملفات (ملف في كل مرة) كما في الفقرة السابقة وستتم إضافة المحتوى الموجود فيها إلى الموقع الجديد. لكن هذه ليس النهاية، لأنك ستلاحظ عدم وجود أيّة مرفقات (الصور المرفقة على سبيل المثال) في موقعك الجديد. نسخ ملفات الوسائط انتقل إلى مجلد /wp-content/uploads/ في موقعك القديم عبر عميل FTP. سأستخدم هنا مستكشف ملفات ويندوز 10 عميلًا لبروتوكول FTP، لكن أغلبية تطبيقات FTP قادرة على ضغط وتنزيل الملفات. نزِّل ملف ZIP الذي ولَّدته ثم ارفعه إلى موقعك الجديد عبر FTP (أو انسخ الملف والصقه في عميل FTP إن استطعت الوصول إلى كلا الموقعين منه [أي العميل]). يمكنك الآن استخراج جميع الملفات من المجلد المضغوط في مجلد Uploads. لسوء الحظ، هذه ليست آخر خطوة؛ فعلى الرغم من أنَّ الملفات في مكانها الصحيح، لكن ووردبريس لا تعلم عنها شيئًا لأنَّ بيانات تلك المرفقات لم تُنسَخ من قاعدة البيانات. رابعا: تصدير بيانات المرفقات من قاعدة البيانات اذهب إلى phpMyAdmin في موقعك القديم وابحث عن جدول wp_posts (ضع البادئة المناسبة بدلًا من wp_‎). عليك الآن العثور على بيانات المرفقات (أي بيانات الوسائط)، ولهذا استخدم تعليمة SQL الآتية (لا تنسَ تغيير بادئة الجدول إن لزم الأمر) ثم اضغط على Go. SELECT * FROM wp_posts WHERE post_type = “attachment” مرِّر إلى أسفل نتائج الطلبية ثم اضغط على Show all لكي تظهر جميع السجلات ثم اضغط على Check All لاختيارها جميعًا ثم Export لتصديرها. ستتعقد بعض الأمور عند هذه النقطة، لكن لن تواجهك مشكلاتٌ إن تابعت الخطوات بحذافيرها. اختر Custom لإظهار كل الخيارات الممكنة. مرِّر إلى الأسفل إلى قسم Format-specific Options. اختر data. اترك كل شيءٍ على حاله ثم اضغط على Go. خامسا: تعديل ملف SQL هذه الخطوة ضرورية إن كان لقاعدة بيانات موقعك الجديد بادئة مختلفة عن قاعدة بيانات الموقع القديم الذي صدَّرتَ ملف SQL منه. عدِّل ملف ‎.sql الناتج باستخدام محرر نصي مثل Notepad++‎ وابحث عن البادئة القديمة وضع البادئة الحديثة بدلًا عنها. يمكنك تجاهل هذه الخطوة إن كانت بادئة قاعدتَي البيانات متماثلة (أي أنَّ كلا الجدولين هما wp_posts). سادسا: استيراد بيانات المرفقات اذهب إلى قاعدة البيانات للموقع الجديد واعثر على جدول wp_posts (أو ما يكافؤه) ثم اضغط على Import. اضغط على Choose File -اضغط ولا تسحب وتُفلِت، لعدم توفر هذه الميزة في phpMyAdmin- ثم اختر ملف SQL الذي صدَّرتَه. اترك بقية الخيارات على حالها ثم اضغط على Go لتنفيذ الطلبية، ثم سترى رسالة تخبرك أنَّ الطلبية قد نُفِّذَت بنجاح، وسترى حينها المرفقات ظاهرةً في صفحة الوسائط، لكن هنالك خطوة إضافية عليك اتباعها حتى تظهر الصور بشكلٍ صحيح. سابعا: تصدير البيانات الوصفية للمنشورات بشكلٍ مشابه لما فعلناه سابقًا في قاعدة البيانات: اعثر على جدول wp_postmeta في قاعدة بيانات الموقع القديم ثم اضغط على Export. اختر Custom ثم اختر data بدلًا من structure and data كما سبق معنا. عليك هذه المرة العثور على قسم Data Creation Options واختيار REPLACE لخيار function to use when dumping data. اضغط الآن على GO لإنشاء وتنزيل ملف SQL. ثامنا: تعديل ملف SQL أكرر مرةً أخرى أنَّ عليك تعديل البادئة في ملف SQL إن اختلفت بادئة جداول قاعدة البيانات الجديدة عن القديمة. عليك أيضًا البحث عن روابط URL القديمة واستبدال الجديدة بها. تاسعا: استيراد البيانات الوصفية للمنشورات اذهب إلى جدول wp_postmeta (أو أيًّا كانت بادئة الجدول) في قاعدة بيانات الموقع الجديد، ثم استورد ملف SQL المُعدَّل كما سبق. يجب أن تكون مكتبة الوسائط جاهزةً عندك تمامًا، وقادرةً على الاندماج مع المحتوى الذي نقلته سابقًا. خاتمة تهانينا إذا نجحتَ بالمرور عبر كل تلك الخطوات، هذه طريقة التفافية لنقل بعض الصور الخاصة بمنشورات معيّنة. لكن ما تزال هنالك بعض المشكلات الصغيرة مع هذه الطريقة: لو أردت نقل بعض الصور، فعليك اختيار المجلدات يدويًا عند رفعها (أرجو أن تكون الصور التي تريدها مصنفةً حسب التاريخ، وإلا فستأخذ منك هذه المهمة وقتًا طويلًا جدًا!)؛ وقد تواجه بعض المشاكل بتكرار المفاتيح الرئيسية (primary keys) عند نقل جدول wp_posts إن كانت عندك منشوراتٌ في الموقع الجديد. من الجلي أنَّه يجب تطوير عملية التصدير/الاستيراد في الإصدارات المستقبلية من ووردبريس بدلًا من هذه الجلبة بتعديل قاعدة البيانات يدويًا. لكن استعن بالخطوات السابقة إلى أن يحين ذاك الوقت. إن كانت لديك أيّة أفكار أو طرق حول نقل أجزاء من موقع ووردبريس إلى آخر، فأرجو أن تشاركنا إياها بالتعليقات. ولا تتردد بالسؤال عن أيّة مشكلة تواجهك عند تنفيذ الخطوات السابقة، نحن موجودون دائمًا للمساعدة. هل ترغب في امتلاك موقع ووردبريس سريع وآمن؟ احصل على موقع ووردبريس احترافي بالاستعانة بأفضل خدمات الووردبريس على خمسات أنشئ موقع ووردبريس الآن ترجمة -وبتصرّف- للمقال A Step By Step Guide to Moving Content From One WordPress Site to Another لصاحبه Tom Ewer.

سنشرع في بناء تطبيق مفيد بدءًا من هذا الدرس، سيُنتِج هذا التطبيق مستند HTML يحتوي على معلومات عن نظامك. قضيتُ وقتًا طويلًا في التفكير حول الطريقة التي عليّ اتباعها لشرح برمجة سكربتات الصدفة، ووجدت أنَّ الطريقة التي اعتمدتها مختلفة عن أغلبية الشروحات التي رأيتها، فالأغلبية تُفضِّل شرحًا هيكليًا لمختلف ميزات الصَدَفة bash، ويفترضون أنَّ لديك معرفة مسبقة مع إحدى لغات البرمجة؛ وعلى الرغم من أنني لا أعتبر أنَّ لديك خلفية برمجية، إلا أنني مدرك أنَّ نسبة كبيرة من الأشخاص العاملين في مجال التقنية يعرفون البنية الأساسية لصفحات HTML، لذلك سيُنتِج برنامجنا صفحة ويب. سنكتشف ميزات الصَدَفة bash أثناء بنائنا للسكربت، وسنتعرف على الأدوات اللازمة لحل المشكلات التي ستواجهنا. كتابة ملف HTML باستخدام سكربت كما تعلم، تكون بنية ملف HTML كالآتي: <html> <head> <title> The title of your page </title> </head> <body> Your page content goes here. </body> </html> بأخذ ذلك بعين الاعتبار، يمكننا أن نكتب سكربتًا يمكنه إخراج المحتوى السابق: #!/bin/bash # sysinfo_page - A script to produce an html file echo "<html>" echo "<head>" echo " <title>" echo " The title of your page" echo " </title>" echo "</head>" echo "" echo "<body>" echo " Your page content goes here." echo "</body>" echo "</html>" يمكن أن يُستخدم السكربت كالآتي (تذكَّر أنَّ الرمز < هو رمز إعادة توجيه المخرجات، وهنا سنعيد توجيه المخرجات إلى ملف باسم sysinfo_page.html): $ sysinfo_page > sysinfo_page.html قيل أنَّ أعظم المبرمجين قدرًا هم أكسلهم! حيث يكتبون برامج ليريحوا أنفسهم من بعض الأعمال؛ وبالمثِل: عندما يكتب المبرمجون الأذكياء برنامجًا، فإنهم يحاولون تقليل مقدار الكتابة التي يكتبونها. أول تحسين سنفعله للسكربت هو التخلص من الاستعمال المتكرر لأمر echo والاستعاضة عنه بأمرٍ واحد (سنحيط كامل مستند HTML بعلامات اقتباس): #!/bin/bash # sysinfo_page - A script to produce an HTML file echo "<html> <head> <title> The title of your page </title> </head> <body> Your page content goes here. </body> </html>" أصبح من الممكن احتواء الأسطر الجديدة في النص داخل علامتَي الاقتباس، وبهذا يمكن أن يمتد الوسيط (argument) المُمرَّر إلى الأمر echo على أكثر من سطر. بغض النظر أنَّ ما سبق تحسينٌ واضحٌ، إلا أنَّ فيه قصورًا لأنَّ شيفرات HTML تحتوي عادةً على علامات اقتباس، مما يجعلها تتعارض مع علامات الاقتباس المحيطة بالوسيط، لكن يمكننا "تهريب" (escape) علامة الاقتباس بوضع شرطة خلفية مائلة \ قبلها. لكننا نريد تجنب كتابة المزيد من الأحرف! إذًا علينا البحث عن طريقة أفضل لطباعة النص. لحسن الحظ توفر لنا الصَدَفة bash طريقةً لفعل ذلك اسمها here script. #!/bin/bash # sysinfo_page - A script to produce an HTML file cat << _EOF_ <html> <head> <title> The title of your page </title> </head> <body> Your page content goes here. </body> </html> _EOF_ here script (يُسمى أحيانًا here document) هو شكل من أشكال إعادة توجيه المخرجات، الذي يوفِّر طريقةً لتضمين محتوى سيُمرِّر إلى مجرى الدخل القياسي (standard input stream) لأحد الأوامر. مُرِّرَت -في المثال السابق- كتلةٌ نصيةٌ إلى مجرى الدخل القياسي للأمر cat. الشكل العام لإنشاء here script: command << token content to be used as command's standard input token يمكن اختيار أي سلسلة نصية لكي تكون العلامة الرمزية (token)، لكنني استخدمت __EOF__ ‏(EOF هو اختصارٌ شهير للعبارة End Of File أي نهاية الملف) لشيوعها، لكنك تستطيع استخدام أي سلسلة تشاء، لطالما أنَّها لا تتعارض مع كلمةٍ محجوزةٍ في bash. العلامة الرمزية التي تُنهي here script يجب أن تُطابِق تمامًا تلك التي بدأته، وإلا فستعامل محتويات السكربت المتبقية على أنَّها دخل قياسي للأمر المُحدَّد. هنالك خدعة إضافية يمكنك استخدامها مع here script تسمح لك بمحاذاة (indent) المحتوى المُمرَّر عبر here script لتحسين قابلية قراءة السكربت. يمكنك فعل ذلك بتعديل السكربت كالآتي: #!/bin/bash # sysinfo_page - A script to produce an HTML file cat <<- _EOF_ <html> <head> <title> The title of your page </title> </head> <body> Your page content goes here. </body> </html> _EOF_ تبديل علامة ‎>> إلى ‎<<-‎ سيؤدي إلى تجاهل مسافات الجدولة (tab) البادئة (لكن لن يتم تجاهل الفراغات) في here script؛ لن يحتوي ناتج الأمر cat على أيّة مسافات جدولة بادئة. حسنًا، لنُعدِّل محتويات ملف HTML لكي نبيّن ما الغرض من صفحة الويب: #!/bin/bash # sysinfo_page - A script to produce an HTML file cat <<- _EOF_ <html> <head> <title> My System Information </title> </head> <body> <h1>My System Information</h1> </body> </html> _EOF_ سنجعل السكربت في الدرس القادم يُظهِر معلومات حقيقة من نظامنا. ترجمة -وبتصرّف- للمقال Here Scripts لصاحبه William Shotts.

حمل عام 2015 حدثًا مهمًا لمجتمع PHP، فبعد أحد عشر عامًا بعد إصدار PHP 5.0 تم إطلاق الإصدار الرئيسي الجديد ألا وهو PHP 7. وسنتحدث في هذا الدرس عمّا حمله هذا الإصدار من تغييرات وإضافات. لكن أين اختفى إصدار PHP 6؟ إذا لم تعمل منذ فترة على PHP، فربما تتساءل ما الذي حدث لإصدار PHP 6، لماذا قفزوا مباشرةً من PHP 5 إلى PHP 7؟ الجواب باختصار هو الفشل الذريع في PHP 6. فالميزة الأساسية للإصدار 6 هي الدعم المُضمّن لمحارف يونيكود وذلك لأنَّ PHP تُستخدَم بشكل رئيسي في تطوير الويب، وسنحتاج إلى استخدام محارف يونيكود في الويب، ولهذا كان التوجه الأساسي هو جلب دعم محارف يونيكود إلى PHP. للأسف، واجهت تلك الخطة الطموحة مشاكل أكبر من تلك المتوقعة، فكان من المفترض تحويل جزء كبير من الشيفرة البرمجية لكي تدعم محارف يونيكود في أساس اللغة وفي الإضافات (extensions) المهمة، لكن تلك المهمة كانت مملة وصعبة؛ وهذا ما أبطأ من تطوير الميزات الأخرى في اللغة، مما أزعج الكثير من مطوري PHP. وبعد فترة ظهرت عقباتٌ أخرى أدّت إلى تقليل الاهتمام بتطوير دعم مُضمّن (أي مدمج في اللغة) لمحارف يونيكود؛ مما أدى في النهاية إلى إيقاف العمل على المشروع. لكن كُتِبَت مقالات وكتب عن PHP 6 ودعمها لمحارف يونيكود قبل إيقاف المشروع، لهذا سُمِّي الإصدار الجديد PHP 7 لرفع الالتباس. حسنًا، لنترك الماضي الحزين وراء ظهورنا ولننظر ما الذي أتت به PHP 7. تحسينات في الأداء أحد أكبر الأسباب التي تجعلك تستعمل PHP 7 في خودايمك هو تحسينات الأداء التي أتت PHP 7 بها، حيث أشارت الإحصائيات الرسمية إلى أنَّ أغلبية التطبيقات العملية التي تستعمل PHP 5.6 ستعمل أسرع بضعفين على الأقل فيما لو استخدمت PHP 7. يمكنك إلقاء نظرة على العرض الذي قدمه Rasmus Lerdorf لتفاصيل أكثر عن الإحصائيات حول الأداء، هذه صورة مأخوذة من ذاك العرض التي تُظهِر نتائج تشغيل ووردبريس على مختلف إصدارات PHP: تستطيع PHP 7 معالجة ضعف الطلبيات في الثانية تقريبًا، الذي يُمثِّل عمليًا تحسينًا قدره 100% في الأداء في المواقع التي تستعمل ووردبريس. هنالك تحسينات أيضًا في مقدار استهلاك PHP 7 للذاكرة، حيث أنَّ تحسين البنى الداخلية للغة كان أحد الأسباب التي أدت إلى تحسين الأداء وتقليل استخدام الذاكرة لتفسير الشيفرات. المشاكل في التوافقية مع الإصدارات السابقة حدثت عدِّة تغييرات في بنية PHP في الإصدار السابع، التي يؤدي بعضها إلى عدم توافقية مع ما سبقها من الإصدارات. أهم تلك التغييرات هي حذف الدوال والعناصر المهملة (deprecated) خصيصًا وسوم البداية والنهاية التي تشبه ASP (أي ‎<%‎ و ‎<%=‎ و ‎%>‎) حيث حُذِفَت بالإضافة إلى وسم <script language="php"‎>، تأكد أنَّك تستعمل الوسم ‎<?php بدلًا عنهما. الدوال التي أُهمِلَت في الإصدارات السابقة تم حذفها في PHP 7 مثل الدالة split، والدوال التي تتبع للإضافة ereg (أي جميع الدوال التي تبدأ بالسابقة ereg_‎). يجب استخدام الدوال التي تتبع للإضافة PCRE بدلًا عنها (أي الدوال التي تبدأ بالسابقة preg_‎) والتي توفر ميزات أكثر. وحُذِفَت جميع دوال الإضافة mysql أيضًا (أي الدوال التي تبدأ بالسابقة mysql_‎) والتي أهمِلَت منذ الإصدار 5.5؛ عليك استخدام دوال إضافة mysqli التي تبدأ بالسابقة mysqli_‎ بدلًا منها. طُبِّقَت أيضًا السياسة الموحدة لتفسير المتغيرات، التي حلّت العديد من المشاكل التي تتعلق بالتعابير التي تحتوي على متغيرات. الميزات الجديدة هذا هو الجزء المسلي هنا، لنتحدث عن أكثر الميزات إثارةً التي ستحصل عليها عند التحديث إلى PHP 7. معاملين جديدين يمكن استخدام معامل spaceship (<=> أو معامل المقارنة المدمج) لجعل تعبير المقارنة أقصر ما يمكن. انظر إلى هذا المثال: a<=>b ستكون نتيجة التعبير السابق 1- إن كان ‎a$ أصغر من ‎$b، و 0 إذا كان ‎$aيساوي ‎$b، و 1 إذا كان ‎$a أكبر من ‎$b. ويمكن اعتباره اختصارًا للتعبير الآتي: (a < b)? -1 : ((a > b) ? 1 : 0)) تحديد أنواع المعاملات والقيم المُعادة إحدى أهم الميزات الجديدة المنتظرة التي أتت بها PHP 7 هي تحديد أنواع معاملات (parameters) للدوال. التي تعني أنَّنا تستطيع تحديد ما هو نوع المعامل الذي ستقبله الدالة والذي سيكون إما int (للأعداد الصحيحة) أو float (للأعداد العشرية) أو string (للسلاسل النصية) أو bool (للقيم المنطقية true أو false أو ما يكافئها). لا يكون الالتزام بأنواع المعاملات المُحدَّدة إجباريًا افتراضيًا، أي non-strict، وهذا يعني لو مررت (int(1 إلى دالة تتطلب عددًا عشريًا (float) فستصبح قيمة الوسيط الممرر (float(1.0 تلقائيًا، أما لو مررت (float(1.5 إلى دالة تتطلب عددًا صحيحًا (int)، فعندها ستصبح القيمة (int(1. ميزات أخرى متفرقة أصبحت PHP 7 تدعم محرف تهريب (escaping) جديد هو ‎\u الذي يسمح لنا باستعمال محارف يونيكود (بالنظام الست عشري) داخل سلاسل PHP النصية، ويستعمل بالشكل {‎\u{CODE، المثال الآتي يُظهِر رمز القلب: echo “\u{1F49A}”; أضيفت أيضًا ميزة إنشاء أصناف مجهولة (Anonymous classes) التي تُفيد في حال أردنا إنشاء كائن وحيد من الصنف فقط: الإصدارات قبل PHP 7 class Logger { public function log(msg { echomsg; } } $util->setLogger(new Logger()); في الإصدار PHP 7 $util->setLogger(new class { public function log($msg) { echo $msg; } }); المصادر لمزيدٍ من المعلومات حول الإضافات التي حدثت في PHP 7، راجع التدوينة Getting Ready for PHP 7 لصاحبتها Erika Heidi. والتدوينة Introduction To PHP 7: What’s New And What’s Gone لصاحبها Vilson Duka، وصفحة New PHP 7 features في دليل PHP. إذا أردت شرحًا لما حُذِفَ في PHP 7، فانظر إلى صفحة Backward incompatible changes في دليل PHP هنالك مرجع كامل لتغيرات PHP موجودٌ في الصفحة الآتية على github، وانظر كذلك إلى PHP RFC.

تحفظ ووردبريس نسخًا من منشوراتك، فلا حاجة أن تفعل ذلك يدويًا! أُضيفت ميزة المراجعات منذ إصدار ووردبريس 2.6، وكان غرضها الرئيسي هو حفظ محتوى منشوراتك بترتيبٍ زمني كي تستطيع العودة إلى الوراء إلى مراجعات قديمة عندما يحدث طارئ (مثل انقطاع التيار الكهربائي، أو انهيار المتصفح). تلك ميزةٌ مفيدةٌ جدًا للكُتّاب، فإذا كنتَ تعمل على مقالة وحذفت بالغلط جزءًا من النص، فيمكنك العودة إلى المسودات القديمة والتراجع عن أيّة تغييرات. سأريك في هذا الدرس كيف تستعمل المراجعات، وكيف تديرها، وكيف تعطل استخدامها. استخدام محرر المراجعات ستعمل ميزة المراجعات عملها عندما تُنشِئ منشورًا جديدًا في ووردبريس، وستُخزِّن في سجلها كل مسودة أو تحديث للمنشور. يمكنك الوصول إلى الإصدارات القديمة من منشورك ومقارنة المراجعات؛ وذلك بالضغط على زر "Browse" (أو "تصفّح" في الواجهة العربية) في صفحة التحرير (انظر إلى الصورة أعلاه)؛ ثم يمكنك رؤية التغيرات التي حدثت في كل نسخة عبر تحريك المزلاج، أو باستخدام الزرين "Previous" و "Next" (انظر الصورة الآتية). سترى في هذا المثال كيف تغير العنوان، وتضيف محتوى جديد إلى المنشور. إذا كنت معتادًا على استخدام أدوات إظهار الفروقات بين ملفين نصيين (diff)، فستكون الواجهة السابقة مألوفةً لديك حيث يَظهَر الإصدار القديم على اليسار والإصدار الجديد على اليمين، ويتم توضيح الاختلافات بشكلٍ مرئي. يمكن أيضًا استعادة النسخة السابقة كليًا عوضًا عن مشاهدة الفروقات فقط. يمكنك أيضًا مشاهدة الفروقات بين أيّ نسختين منفصلتين من المقالة عبر الضغط على مربع "Compare any two revisions" (أو "مقارنة بين أي مراجعتين" في الواجهة العربية)، ثم استخدم المزلاج لاختيار النسختين اللتان تريد مقارنتهما. سنقارن في المثال الآتي نسختين غير متتاليتين من المقالة: أما من ناحية الإجراءات التي يمكنك القيام بها على نسخ المراجعات، فالخيار أمامك محصورٌ بين "استعادة المراجعة" أو عدم استعادتها. أكبر مشكلة في قابلية الاستخدام التي قد تواجهها هي أنَّك غير قادرٍ عن نسخ النص من إحدى المراجعات مباشرةً من واجهة المقارنة، وذلك لأنَّ النص المُحدَّد سيكون من كلا النسختين اللتان تتم مقارنتهما. تفعيل المراجعات إذا كنتَ تضبط ووردبريس من الصفر، فيجب أن تكون المراجعات مفعّلةً تلقائيًا في موقعك مع الضبط الافتراضي لتخزين كل مراجعة للمنشورات. أما لو لم ترَ خيار المراجعات في صفحة تحرير المنشورات، فهذا يعني أنَّها مُعطّلة يدويًا من الضبط؛ أول خطوة في معرفة ما الخطب هي فتح ملف wp-config.php والبحث عن السطر الآتي: define( ‘WP_POST_REVISIONS’, false ); لديك ثلاثة خيارات رئيسية عند تحديد قيمة إلى WP_POST_REVISIONS: true أو 1-: هذا هو الخيار الافتراضي في ووردبريس الذي يُخزِّن كل نسخة من المراجعات لكل منشور. false أو 0: تعطيل ميزة المراجعات تعطيلًا تامًا والإبقاء على آخر نسخة محفوظة تلقائيًا فقط. رقم أكبر من الصفر: تحديد عدد المراجعات إلى هذا الرقم وحذف المراجعات القديمة تلقائيًا. هنالك أمران تجدر الإشارة إليهما في هذه المرحلة: عليك أن تضبط هذه القيمة في أعلى مكان تعريف الثابت ABSPATH في ملف الضبط، بالإضافة إلى امتلاكك لخيارٍ للتحكم بالحفظ التلقائي باستخدام الثابت AUTOSAVE_INTERVAL كما في الصورة أدناه. إذا لم تستطع الوصول إلى ملف wp-config.php، أو ما زلت تواجه بعض المشاكل في هذه المرحلة، فيجدر بك التواصل مع مزود الخدمة. على سبيل المثال، يُعطِّل موقع WP Engine المراجعات افتراضيًا وعليك التواصل معهم لتفعيل ذاك الخيار. التحكم في مراجعات كل منشور إذا لم تكن لديك مشكلة في كتابة بعض الشيفرات للتحكم بموقعك، فعليك أن تستغل المُرشِّح (filter) المسمى wp_revisions_to_keep للتحكم في كيفية التعامل مع المراجعات في كل منشور. من السهل نسبيًا تطبيق هذا المُرشِّح الذي يتطلب ببساطة تمرير معاملَين (parameters) هما عدد المراجعات التي تريد الإبقاء عليها وكائن (object) من نوع WP_Post يُمثِّل المنشور الذي تريد ضبط عدد المراجعات فيه: add_filter( ‘wp_revisions_to_keep’, ‘filter_function_name’, 10, 2 ); function filter_function_name($num, $post) { return $num; } تستطيع -بكل تأكيد- أن تُحدِّد نوع المنشور بالطريقة التي تريدها في الدالة السابقة، لطالما أعادت الدالة كائنًا سليمًا. تعطيل أو وضع حد للمراجعات ميزة المراجعات مهمة ومفيدة جدًا للبعض، لكنها غير ملائمة للجميع خصوصًا إذا كانت لديك قاعدة بيانات ذات مساحة تخزينية محدودة أو كنتَ -ببساطة- لا تحتاج إلى الحفظ التلقائي لمنشوراتك. أضف السطر الآتي إلى ملف wp-config.php لتعطيل المراجعات تمامًا في موقعك: define(‘WP_POST_REVISIONS’, false); وإن أردت إعادة تفعيل المراجعات مرةً أخرى، فاضبط القيمة السابقة إلى true. أما إذا أردت أن تضع حدًا لعدد المراجعات لكل منشور، فيمكنك ضبط قيمة الثابت السابقة إلى رقم معيّن كما في المثال الآتي: define(‘WP_POST_REVISIONS’, 10); إضافة السطر السابق إلى ملف wp-config.php ستؤدي إلى إنشاء 10 مراجعات كحد أقصى لكل منشور، بالإضافة إلى مراجعة أخرى لغرض الحفظ التلقائي للمنشور. ستُحذَف المراجعات القديمة تلقائيًا عند إضافة نسخ حديثة من المنشور. المخاطر المحتملة عند استخدام المراجعات في موقع إنتاجي بغض النظر عن المساعدة الكبيرة التي تقدِّمها المراجعات للكُتّاب والمحررين، وبغض النظر عن عدم معارضة تفعيلها تلقائيًا، إلا أنَّ الانتقادات الموجهة إليها تكون بسبب الأداء في المواقع الإنتاجية. ولأن كل نسخة من المراجعات ستُخزَّن في سجل خاص بها في قاعدة البيانات، فهنالك احتمالٌ أن تُسبِّب بحِملٍ غير ضروري يؤدي إلى تقليل أداء قاعدة البيانات في المواقع الكبيرة. من الصعب إعطاء مؤشر عن التأثير السلبي لميزة المراجعات على أداء المواقع، لكن عملية تحسين قاعدة البيانات ستصبح ضروريةً كلما ازداد حجم الموقع. لننتقل الآن إلى شرح بعض الإضافات التي يمكنك استخدامها لتنظيم موقعك وتقليل التأثير على قاعدة البيانات. استخدام الإضافات لحذف المراجعات إذا استوعبتَ مفهوم المراجعات في ووردبريس، فربما ستتساءل عن كيفية تنظيم المراجعات الموجودة في موقعك. أنت تعلم أنَّه بعد نشر مقالة ما التي مرت بمرحلة التحرير والتعديل، فلن يكون للمراجعات المُخزَّنة أيّة قيمة. سأدلّك الآن على أربع إضافاتٍ يمكنك استخدامها لحذف المراجعات التي لم تعد بحاجةٍ إليها؛ ولمّا كانت هذه الإضافات ستُعدِّل على قاعدة بياناتك، فأنا أنصحك وبشدة أن تكون لديك نسخةٌ احتياطيةٌ من قاعدة البيانات قبل تجربة هذه الإضافات. Optimize Database after Deleting Revisions إضافة Optimize Database after Deleting Revisions تمنحك طريقةً لحذف المراجعات برمجيًا وإبقاء مساحة قاعدة البيانات صغيرةً قدر الإمكان. يمكن استدعاء الإضافة يدويًا أو يمكن أن تُشغَّل كمهمة مجدولة، التي ستُنشِئ ملفات السجل الخاصة بها ليتم تحليلها لاحقًا، ولتمكينك من اختيار عدد المراجعات الحديثة التي ستُستثنى من الحذف. WP-Sweep تؤدي إضافة WP-Sweep وظائف أكثر شمولًا لكنها تسمح لك في الوقت نفسه بحذف المراجعات. ستستفيد من هذه الإضافة بتتبع بعض الأمور مثل التعليقات والمسودات والمراجعات. WP-Optimize كما في إضافة WP-Sweep، تمكِّنك إضافة WP-Optimize من حذف بعض الأشياء غير الضرورية من قاعدة بيانات ووردبريس وحذف المراجعات التي لست بحاجةٍ إليها. يمكنك إنشاء مهام مجدولة تُعيّن متى تريد تشغيل هذه الإضافة، وستساعدك هذه الإضافة بالتخلص من أمورٍ مثل المسودات والتعليقات المحذوفة وغيرها. Better Delete Revision إضافة Better Delete Revision تختص في حذف بيانات المراجعات فقط، لكنها تفعل ذلك بإتقان وستحذف كل البيانات الوصفية (meta information) والوسوم (tags) المرتبطة بمراجعة معيّنة أثناء حذفها. يُنصَح باستخدام هذه الإضافة ذات 60000 تنزيل وتقييم قريب من 5 نجوم، لكن من الجدير بالذكر أنَّها لم تُحدَّث منذ قرابة السنة، لذلك جربها بحذر إذا كانت لديك نسخة ووردبريس حديثة. تحقيق أقصى استفادة من المراجعات المراجعات هي إحدى الأدوات التي ستلوم نفسك إن لم تكن تستخدمها من قبل. لنلخص النقط الرئيسية التي عليك أخذها بعين الاعتبار عند استخدام المراجعات في موقعك: يمكنك بسهولة ضبط خيارات المراجعات عبر الثابت WP_POST_REVISIONS في ملف wp-config.php. يمكنك أن تتحكم برمجيًا بالمراجعات لكل منشور على حدة برمجيًا باستخدام المُرشِّح wp_revisions_to_keep. هنالك إضافات مثل WP-Sweep تساعد في تقليل مساحة قاعدة البيانات وإبقاء الأمور تعمل بسلاسة خلف الكواليس. هل تستخدم المراجعات كجزءٍ من آلية التحرير عندك أم تُفضِّل استخدام أدوات أخرى؟ هل تعتبر المراجعات أساسيةً في تجربتك في الكتابة أم أنها مضيعة للوقت؟ أخبرنا رأيك في التعليقات. ترجمة -وبتصرّف- للمقال How to Manage WordPress Post Revisions and Control Your Past لصاحبه Tom Ewer.

قبل أن تبدأ في كتابة سكربتات جديدة، عليّ أن أشير إلى أنَّك تملك بعض السكربتات الموجودة مسبقًا، وضِعَت هذه السكربتات في مجلد المنزل الخاص بك عندما أُنشِئ حسابك، وتُستعمل لضبط سلوك جلسات سطر الأوامر في حاسوبك؛ تستطيع تعديل هذه السكربتات لتغيير بعض الأمور. سنلقِي نظرةً على سكربتَين من هذه السكربتات في هذا الدرس لكي نتعلم بعض المفاهيم الجديدة والمهمة عن الصَدَفة. يُبقي النظام على مجموعة من المعلومات حول جلستك تدعى "البيئة" (environment)، تحتوي البيئة على أشياء مثل المجلدات التي سيتم البحث فيها عن البرمجيات (PATH)، واسم المستخدم، واسم الملف الذي سيُحفَظ فيه بريدك الإلكتروني، وغير ذلك. يمكنك رؤية قائمة كاملة لضبط البيئة بالأمر set. هنالك نوعان من الأوامر التي تحتويها البيئة، وتُعرَف بالاختصارات (aliases) ودوال الصّدفة (shell functions). ما هو منشأ البيئة؟ تبدأ صَدَفة bash عندما تُسجِّل دخولك إلى النظام، وتقرأ سلسلة من ملفات الضبط تُسمى "ملفات بدء التشغيل" أو "ملفات البدء" (startup files) التي تُعرِّف البيئة الافتراضية التي يتشارك فيها جميع المستخدمين؛ ثم ستقرأ ملفات بدء إضافية موجودة في مجلد المنزل الخاص بك التي تُعرِّف بيئتك الشخصية. يختلف الترتيب بحسب نوع جلسة سطر الأوامر التي بدأتها، إذ أنَّ هنالك نوعان: جلسة تحتاج إلى تسجيل دخول (login shell session) وجلسة لا تحتاج إلى تسجيل دخول (non-login shell session). الجلسة التي تحتاج إلى تسجيل دخول هي الجلسة التي تسألك عن اسم المستخدم وكلمة المرور، وذلك عندما تستعمل إحدى الطرفيات الوهمية (virtual console) على سبيل المثال. أما الجلسات التي لا تحتاج إلى تسجيل دخول فهي تحدث عادةً عندما تُشغِّل محاكي الطرفية داخل الواجهة الرسومية. تقرأ الصَدَفة التي تحتاج إلى تسجيل دخول ملف بدء أو أكثر كما هو موضَّح هنا: ‎/etc/profile: سكربت الضبط العام الذي يُطبَّق على جميع المستخدمين. ‎~/.bash_profile: ملف بدء خاص بالمستخدم، يمكن أن يُستعمل لضبط خياراتٍ أخرى غير موجودة في سكربت الضبط العام، أو لتجاوز بعضها وإعادة تعريفها. ‎~/.bash_login: إن لم يكن الملف ‎~/.bash_profile موجودًا فستحاول الصَدَفة bash قراءة هذا السكربت. ‎~/.profile: إن لم يكن الملف ‎~/.bash_profile أو ‎~/.bash_login موجودًا فستحاول الصَدَفة bash قراءة هذا الملف. هذا هو السلوك الافتراضي في التوزيعات المبنية على دبيان مثل أوبنتو. أما الصَدَفة التي لا تحتاج إلى تسجيل دخول، فتقرأ ملفات البدء الآتية: ‎/etc/bash.bashrc: سكربت ضبط عام يُطبَّق على جميع المستخدمين. ‎~/.bashrc: ملف بدء خاص بالمستخدم، يمكن أن يُستعمل لضبط خياراتٍ أخرى غير موجودة في سكربت الضبط العام، أو لتجاوز بعضها وإعادة تعريفها. إضافةً إلى قراءة ملفات الضبط السابقة، ترث الجلساتُ التي لا تحتاج إلى تسجيل دخول البيئةَ من العملية الأب (parent process) التي تكون عادةً جلسة تحتاج إلى تسجيل دخول. ألقِ نظرةً على نظامك لترى ما هي ملفات البدء التي عندك، لكن لاحظ أنَّ أغلبية الملفات السابقة تبدأ بنقطة (مما يعني أنها مخفية)، لذا عليك استخدام الخيار ‎-aمع الأمر ls. ls -a ملف ‎~/.bashrc هو أهم ملف بدء من وجه نظر المستخدم العادي لأنه يُقرَأ دائمًا. حيث تقرأه الجلسات التي لا تحتاج إلى تسجيل دخول افتراضيًا، وأغلبية ملفات البدء الخاصة بالجلسات التي تحتاج إلى تسجيل دخول تقرأ ملف ‎~/.bashrc أيضًا. إذا ألقيت نظرةً داخل ملف ‎.bash_profile‎ (الملف الآتي مأخوذ من توزيعة CentOS)، فسيبدو شبيهًا بالآتي: # .bash_profile # Get the aliases and functions if [ -f ~/.bashrc ]; then . ~/.bashrc fi # User specific environment and startup programs PATH=$PATH:$HOME/bin export PATH تذكَّر أنَّ الأسطر التي تبدأ برمز # هي تعليقات ولا تُفسَّرها الصَدَفة؛ حيث أُضيفت هذه الأسطر لشرح الشيفرة لمن يقرأها من البشر. ستجد في السطر الرابع أول الأشياء المثيرة للاهتمام: if [ -f ~/.bashrc ]; then . ~/.bashrc fi هذه هي عبارة if الشرطية، التي سنشرحها بالتفصيل في درسٍ لاحق، لكنني سأفسرها لك كالآتي: إذا كان الملف ‎~/.bashrc موجودًا، فنفِّذ محتويات ‎~/.bashrc. يمكننا أن نرى أنَّ الشيفرة القصيرة السابقة هي التي تجعل الجلسات التي تحتاج إلى تسجيل الدخول تقرأ محتويات الملف ‎.bashrc. الخطوة التالية في ملف البدء هي ضبط المتغير PATH وإضافة ‎~/bin إلى قائمة المجلدات التي سيتم البحث فيها عن الملفات التنفيذية للأوامر. وفي نهاية الملف: export PATH وظيفة الأمر export هي إخبار الصَدَفة أنَّ عليها جعل محتويات المتغير PATH متاحةً للعمليات التي تنحدر منها (الأبناء). الاختصارات aliases الاختصارات (aliases) هي طريقة سهلة لإنشاء أمر جديد يعمل اختصارًا لأمرٍ أطول. لها الشكل العام الآتي: alias name=value حيث name هو اسم الأمر الجديد و value هي السلسلة النصية التي ستُنفَّذ عند إدخال name في سطر الأوامر. لنُنشِئ اختصارا اسمه l (حرف L صغير) ولنجعله اختصارًا للأمر ls -l (أي عرض محتويات المجلد بالصيغة التفصيلية). تأكَّد أنَّ مجلد العمل الحالي هو المنزل، ثم افتح ملف ‎.bashrc باستخدام محررك النصي المُفضَّل وأضف السطر الآتي إلى نهاية الملف: alias l='ls -l' عند إضافتك للأمر alias إلى الملف، فستُنشِئ أمرًا جديدًا اسمه l الذي يكافئ ls -l. أغلِق جلسة الطرفية الحالية وابدأ واحدة جديدة لتجربة الاختصار التي أنشأناه، وذلك لإعادة قراءة محتويات الملف ‎.bashrc. يمكنك باستخدام هذه التقنية إنشاء أي عدد من الاختصارات المُخصصة لاستعمالك الشخصي، هذه إحداها: alias today='date +"%A, %B %-d, %Y"' سيُنشِئ السطر السابق اختصارا جديدا اسمه today الذي سيُظهِر تاريخ اليوم بتنسيقٍ جميل. بالمناسبة، الأمر alias هو أمر مُضمَّن في الصَدَفة (shell builtin)، أي أنَّك تستطيع إنشاء الأوامر البديلة مباشرةً من سطر الأوامر؛ لكن يجب أن تعلم بأنَّ تلك الأوامر ستزول عند إغلاقك لجلسة الطرفية الحالية. مثال: $ alias l='ls -l' دوال الصدفة ستستفيد من أمر alias عند إنشاء اختصارات لأوامر بسيطة، لكن ماذا لو أردت إنشاء شيءٍ أكثر تعقيدًا؟ عليك حينها أن تجرِّب شيئًا يسمى "دوال الصدفة" (shell functions)، التي يمكنك اعتبارها أنهَّا "سكربتات داخل سكربتات"، أو سكربتات فرعية صغيرة. لنجرب واحدةً منها! افتح ملف ‎.bashrc بمحررك وضع ما يلي بدلًا عن الاختصار today: today() { echo -n "Today's date is: " date +"%A, %B %-d, %Y" } صدِّق أو لا تصدِّق، () هو أمر مضمَّن بالصدفة أيضًا مثَلُهَ كَمَثَلِ الأمر alias، حيث يمكنك أيضًا إدخال دوال الصدفة مباشرةً من سطر الأوامر. $ today() { > echo -n "Today's date is: " > date +"%A, %B %-d, %Y" > } $ لكن تلك الدوال -مثلما هو عليه الحال مع الأمر alias- ستزول عند إغلاق جلسة الطرفية الحالية. ترجمة -وبتصرّف- للمقال Editing The Scripts You Already Have لصاحبه William Shotts.

إذا كنتَ تعد موقعًا ليستخدمه أشخاصٌ غير متخصصين في التقنية، فسيساعد تخصيص لوحة تحكم ووردبريس في تسهيل إدارتهم لموقعهم ولتعاملهم مع المحتوى. أغلبية المواقع التي أُنشئها تكون لعملاء ليسوا معتادين على التعامل مع ووردبريس وليس لديهم الوقت الكافي لتعلمه كي يديروا موقعهم، لذلك أجنح إلى تخصيص لوحة التحكم لتسهيل عملهم. وعادةً أضيف علامتي التجارية إلى لوحة التحكم كي أذكرهم مَن الذي طوّر الموقع لهم. التعديلات والتخصيصات التي أجريها تختلف بناءً على احتياجات كل عميل، لكنها تتضمن عادةً واحدًا أو أكثر من ما يلي: إضافة علامتي التجارية إلى صفحة تسجيل الدخول بوضع الشعار الخاص بي. إضافة علامتي التجارية إلى صفحات لوحة التحكم، بدءًا من أشياءٍ بسيطة مثل تغيير نص الترويسة (header) أو التذييل (footer) مرورًا بتغيير الألوان وتخطيط الصفحات. إزالة "الودجات" (widgets) التي لا يحتاج لها العميل، وإضافة أخرى تُقدِّم تمهيدًا إلى الموقع، وما الذي عليهم معرفته للبدء باستعمال الموقع. إزالة عناصر من قائمة لوحة التحكم التي لا يحتاج العميل إلى الوصول إليها، وإضافة أخرى إن لزم الأمر. إضافة حقول مخصصة (custom fields) لتسهيل إضافة البيانات من قِبل العملاء. توفر ووردبريس عددًا من الدوال وما نسميه "hooks" التي تساعدك إن أردت كتابة الشيفرات يدويًا، وهذا ما أفعله عادةً (أضع كل شيء في إضافة مخصصة)، لكن إن لم تكن ترغب بالخوض في البرمجة وكتابة الشيفرات أو كنتَ على عجل، فقد تكون الإضافات هي الطريق الأيسر والأسرع لتحقيق مبتغاك. لنبدأ بكبيرها! Ultimate Branding تملك إضافة Ultimate Branding كل ما تحتاج له عندما يأتي الأمر إلى تخصيص لوحة التحكم، فلا تسمح لك بتخصيص صفحات لوحة التحكم فحسب، وإنما تعطيك خياراتٍ تتعلق بتخصيص الواجهة الأمامية (front end) إلى نفس نمط شبكتك من المواقع إن كُنت تستخدم نسخة مُتعدّدة المواقع من ووردبريس wordpress multisite. لكن إضافة Ultimate Branding ليست مفيدة فقط لشبكات المواقع، إذ يمكنك استعمالها عند تثبيت ووردبريس بشكلٍ قياسي لكي تضع علامتك التجارية في الصفحات الإدارية، وتخصص صفحة تسجيل الدخول، وتحذف عناصر القائمة التي لا تريدها وتغير ترتيب بعضها، وتُنشِئ شريط لوحة التحكم الخاص بك، والكثير. يمكن تفعيل أو تعطيل كل تلك الميزات من لوحة التحكم، لذلك تستطيع أن تستعمل منها ما تشاء لموقعك، كما ترى في لقطة الشاشة الآتية: White Label CMS إضافة White Label CMS هي أشهر إضافة مجانية لتخصيص لوحات التحكم، حيث تسمح لك بإضافة شعار في صفحة الدخول، وإضافة وحذف ودجات لوحة التحكم، وإخفاء بعض الصناديق في صفحات التحرير، وإزالة بعض عناصر قائمة لوحة التحكم، وإضافة أنماط CSS في الأماكن التي تريد. ليست ميزات هذه الإضافة بقوة الإضافة Ultimate Branding، وقد يُربِك المستخدمَ وجود كل الإعدادات المتعلقة بهذه الإضافة في صفحةٍ وحيدةٍ، لكنها مجانية وتملك وظائف تشمل تقريبًا كل وظائف الإضافات المجانية المتوفرة. Admin Menu Editor إذا كان ما تريده هو إضافة أو حذف أو إعادة ترتيب أو تعديل عناصر قائمة لوحة تحكم ووردبريس، فإضافة Admin Menu Editor تُسهِّل عليك الأمر. الميزة التي أحبها كثيرًا هي السماح لك بتعديل النص لكل عنصر من قائمة لوحة التحكم، فلو كنت تبني موقعًا لعميلٍ سيستعمل "المقالات" لنشر الأخبار، فيمكنك تغيير كلمة "مقالات" في قائمة لوحة التحكم إلى "أخبار". تعمل هذه الإضافة بشكلٍ مشابه كثيرًا لصفحة "تحرير القوائم" في ووردبريس. يمكنك أيضًا إعادة ترتيب عناصر القائمة، أو إخفاؤها من المستخدمين الذين لا يملكون الامتيازات اللازمة للدخول إليها. تسمح لك النسخة المدفوعة من الإضافة بنقل عناصر القوائم الفرعية إلى قوائم رئيسية أخرى، وهذا قد يفيدك إن كنت تحذف الكثير من عناصر قائمتين رئيسيتين وتريد دمج ما تبقى منهما. Post Type Archive Link أحد الأشياء التي تزعجني في ووردبريس هو مدى صعوبة إضافة رابط إلى أرشيف نوعٍ مخصصٍ من المنشورات (custom post type) إلى قوائم التنقل. الطريقة الوحيدة لفعل ذلك هي معرفة رابط URL لأرشيف النوع المخصص من المنشورات ثم إضافته كرابط مخصص… لكن ذلك صعبٌ عليك إن لم تكن تألف طريقة توليد ووردبريس للروابط. تحل إضافة Post Type Archive Link هذه المشكلة، إذ تضيف مكانًا لنوع المنشورات المخصص إلى قائمة لوحة التحكم، مما يسمح لك بإضافة رابط لكل نوع منشورات في قائمة التنقل. إن كنتَ تستعمل ووردبريس كنظام إدارة محتوى ولديك عدِّة أنواع مخصصة من المنشورات، فستفيدك هذه الإضافة كثيرًا. Media Library Assistant إذا احتوى موقعك على الكثير من ملفات الوسائط التي عليك إدارتها بطريقةٍ أكثر فعاليةً من الطريقة الافتراضية، فستساعدك إضافة Media Library Assistant في ذلك. حيث تسمح لك بإضافة تصنيفات ووسوم إلى ملفات الوسائط وتعرض أيضًا معلومات حول كل ملف وسائط في صفحة "مكتبة الوسائط"، مثل أيّة منشورات تستعمل الصورة كصورة بارزة، مع رابط للمنشور. قد تستفيد من هذه الإضافة في حال احتجت إلى تبديل أو إزالة صورة وكنتَ تعرف اسم ملف الصورة لكنك لم تذكر أين رفعتها. Login Logo هذه الإضافة بسيطة للغاية، وقد برمجها أحد مطوري ووردبريس نفسها (Mark Jaquith)، تسمح إضافة Login Logo لك بتغيير الشعار في صفحة تسجيل الدخول الخاصة بووردبريس بنسخ ملف اسمه login-logo.png إلى مجلد wp-content. كل ما عليك فعله هو تفعيل الإضافة، ثم رفع الملف وسيظهر شعارك بدلًا من شعار ووردبريس. عندما تحاول الوصول إلى هذه الإضافة في “دليل الإضافات”، فستجد تحذيرًا يقول لك أنَّ هذه الإضافة لم تُحدَّث منذ أكثر من سنتين، لا تقلق من ذلك: فهذه الإضافة بسيطة جدًا ولا حاجة لتحديثها، وقام بتطويرها -كما أشرنا-مطوِّر يمكنك أن تثق به. Dashboard Widget Order قد تكون "ودجات" لوحة التحكم مفيدةً للغاية، فهي تعطي المستخدمين معلوماتٍ حول موقعهم، وتسهِّل لهم إنشاء محتوى جديد، وتساعدهم في البدء باستخدام ووردبريس. لكن أحد الأشياء التي أجدها مزعجةً هو أنَّك لا تستطيع تحديد الترتيب الافتراضي لتلك الودجات. يمكنك حذفها أو إضافتها، لكنك لن تستطيع إعادة ترتيبها ما لم تكتب شيفراتٍ معقدة. تحل إضافة Dashboard Widget Order هذه المشكلة، لكنها تعمل في بيئة متعددة المواقع لكنها تسمح لك بسرعة أن تعيد ترتيب الودجات في لوحة التحكم، وهذا يعني أنَّه في كل مرة يُنشَأ فيها مستخدمٌ جديدٌ في شبكتك، فستعلم تمامًا كيف ستبدو لوحة التحكم بالنسبة إليهم. Dashboard Feeds إذا كنتَ تُنشِئ مواقع لعملاء ليسوا مطوري ويب وليسوا مهتمين بووردبريس، فهنالك احتمالٌ كبيرٌ أنَّك ستحذف ودجت "أخبار ووردبريس"، لكن تستطيع فعل ما هو أكثر فائدةً، ألا وهو وضع ودجت أخبار أخرى! تسمح لك إضافة Dashboard Feeds بفعل ذلك: أضف ما تشاء إضافته من تغذية RSS وستملأ هذه الإضافةُ لوحةَ التحكم بودجت لكلٍ منها. إذا كنتَ تُنشِئ موقعًا ذا مجالٍ معيّن، فربما تُضيف أخبارًا من نفس المجال. أو إذا أردت أن تحمِّس مستخدمين وعملائك بتصفح محتوى الموقع، فيمكنك إضافة تغذية RSS من موقعك نفسه! الخلاصة يُسهِّل تخصيص لوحة تحكم ووردبريس العمل كثيرًا للعملاء والمستخدمين، ويمكن أن يساعدك في نشر علامتك التجارية، وذلك بعرض معلوماتٍ عنها، أو إظهار محتوى من موقعك. إن استعملتَ الإضافات السابقة، ستتمكن من إنشاء لوحة تحكم رائعة لمستخدميك وعملائك التي تعكس مدى احترافية عملك في تعديل مواقعهم. هل خصصت لوحة التحكم في موقعك؟ ما هي التغييرات التي تجريها عادةً؟ هل هنالك تخصيصات تفعلها لعملاء محددين؟ أخبرنا ذلك في التعليقات. ترجمة -وبتصرّف- للمقال Customizing the WordPress Admin Experience for Novice Clients لصاحبه Rachel McCollin.

هذه السلسلة عبارة عن ترجمة لكتاب Dive Into HTML5 لمؤلفه Mark Pilgrim والتي سنتعلم من خلالها أساسيات HTML5 وكيفية الإنتقال إليها من نسخ HTML أقدم مع مراعاة دعم المتصفحات المختلفة. قبل البدء باستخدام HTML5 سنتطرق في هذا الدرس الأول إلى خمسة أشياء عليك معرفتها حول HTML5. 1. HTML5 ليست شيئا واحدا كبيرا ربما تتساءل: "كيف يمكنني البدء باستعمال HTML5 إن لم تكن تدعمها المتصفحات القديمة؟" لكن السؤال نفسه سيُضلِّلُكَ، HTML5 ليست شيئًا واحدًا كبيرًا، وإنما مجموعة من الميزات المنفصلة عن بعضها، أي أنَّك لن تحاول اكتشاف "دعم HTML5" في المتصفح، لأن ذلك غير منطقي؛ وإنما يمكنك اكتشاف الدعم للمزايا المختلفة مثل التخزين المحلي، أو عرض الفيديو، أو الحصول على الموقع الجغرافي. ربما تظن أنَّ HTML هي مجموعة من الوسوم وتلك الأقواس التي تشبه الزاوية… إن هذا جزءٌ مهمٌ منها، لكنه لا يمثلها كلها. إذ تُعرِّف مواصفات HTML5 كيف تتفاعل تلك الوسوم مع لغة JavaScript وذلك عبر ما يُعرَف بالمصطلح "DOM" (اختصار للعبارة Document Object Model). فلا تُعرِّف HTML وسمًا باسم <video> فقط، وإنما هنالك واجهة برمجية للتعامل مع كائنات الفيديو عبر DOM. يمكنك استعمال تلك الواجهة البرمجية (أي API) لكي تكتشف الدعم لمختلف صيغ الفيديو، ولكي تبدأ المقطع أو توقفه مؤقتًا، أو أن تكتم صوته، أو أن تعرف ما هو المقدار الذي نُزِّل (downloaded) من الفيديو، وكل شيءٍ آخر يلزمك لبناء تجربة مستخدم رائعة عند استعمال وسم <video> لعرض المقاطع. 2. ليس عليك التخلي عن كل شيء شئت أم أبيت، لا تستطيع أن تنكر أنَّ HTML 4 هي أنجح لغة توصيف (markup) على الإطلاق. بُنيَت HTML5 على هذا النجاح، وليس عليك أن تتخلى عن الشيفرات التي كتبتها، وليس عليك إعادة تعلم أشياء تعرفها من قبل، فإن كان تطبيقك يعمل البارحة باستخدام HTML 4، فسيبقى يعمل اليوم في عصر HTML5. لكن إن أتيت لتحسين تطبيق الويب الخاص بك، فقد أتيت إلى المكان الصحيح. هذا مثالٌ واقعي: تدعم HTML5 كل عناصر النماذج (forms) في HTML 4، لكنها تتضمن عناصر جديدة أخرى. كنا ننتظر إضافة بعض تلك العناصر بفارغ الصبر، مثل المزلاج (slider) ومنتقي التاريخ (date picker)؛ بعضها الآخر ذو ميزاتٍ خفية. فحقل email مثَلَهُ كمَثَلِ حقل الإدخال النصي العادي، إلا أنَّ متصفحات الهواتف الذكية ستخصص لوحة المفاتيح الظاهرة على الشاشة لتسهيل كتابة عناوين البريد الإلكتروني. بعض المتصفحات القديمة لا تدعم حقل email وستعامله على أنَّه حقل نصي عادي، وسيبقى النموذج يعمل دون تعديلات في الشيفرة أو استخدام أساليب ملتوية عبر JavaScript. هذا يعني أنك تستطيع تحسين النماذج في صفحاتك اليوم، حتى لو كان زوارك يستعملون IE 6. 3. من السهل البدء باستعمالها يمكن أن يكون "التحديث" إلى HTML5 بسيطًا لدرجة أنَّ كل ما عليك فعله هو تعديل doctype، الذي يجب أن يكون أول سطر من كل صفحة HTML. تُعرِّف الإصدارات السابقة من HTML الكثير من أنواع doctype، وكان من الصعب اختيار النوع المناسب؛ لكن هنالك نوع doctype وحيد في HTML5: <!DOCTYPE html> لن يضر التحديث إلى نمط doctype في HTML5 شيفراتك المكتوبة، لأنَّ جميع الوسوم (tags) المُعرَّفة في HTML 4 ما تزال مدعومةً في HTML5، لكنها ستسمح لك باستعمال –والتحقق من صحة صياغة– العناصر التنظيمية الجديدة مثل <article> و <section> و <header> و <footer>، سنتحدّث عن هذه العناصر الجديدة في مقال قادم. 4. إنها تعمل بالفعل سواءً كنت تريد الرسم عبر canvas، أو تشغيل مقطع فيديو، أو تصميم نماذج أفضل، أو بناء تطبيقات ويب تعمل دون اتصال؛ فستجد أنَّ HTML5 مدعومةً دعمًا جيدًا، حيث يوجد دعمٌ لخاصية canvas في Firefox و Safari و Chrome و Opera ومتصفحات الهواتف الذكية وتشغيل الفيديو وتحديد المواقع والتخزين المحلي والمزيد. تدعم غوغل (في متصفحها) البيانات الوصفية الخاصة (microdata)، وحتى مايكروسوفت –المشهورة بتأخرها عن اللحاق بركب دعم المعايير القياسية– تدعم أغلبية ميزات HTML5 في متصفح "Internet Explorer 9". يتضمن كل درس من هذه السلسلة جداول لتوافقية المتصفحات الشهيرة للميزة المشروحة، ولكن الأهم من ذلك أنَّ كل درس يتضمن نقاشًا عن خياراتك إن كنت تحتاج إلى دعم المتصفحات القديمة. تم توفير ميزات في HTML5 مثل تحديد الموقع الجغرافي وتشغيل الفيديو في السابق عبر إضافات للمتصفح مثل Gears أو Flash. الميزات الأخرى، مثل canvas، تستطيع محاكاتها بشكلٍ تام باستعمال JavaScript. ستتعلم من خلال هذه السّلسلة (التي تقرأ الآن درسها الأول) كيف تستهدف المتصفحات ذات الدعم المدمج لتلك الميزات، دون أن تترك خلفك المتصفحات القديمة. 5. HTML5 ستبقى وستتطور اخترع "Tim Berners-Lee" الشبكة العنكبوتية في بدايات التسعينات من القرن الماضي، ثم أنشَأ جمعية W3C لكي تكون المرجع في معايير الويب، وهذا ما فعلته تلك الجمعية لأكثر من 20 عامًا. هذا ما قالته W3C عن مستقبل معايير الويب في تموز/يوليو عام 2009: ستبقى HTML5 في المستقبل، لنبدأ بتعلمها. ترجمة -وبتصرّف- لفصل Introduction من كتاب Dive Into HTML5 لمؤلفه Mark Pilgrim. اقرأ أيضًا المقال التالي: نظرة على تاريخ HTML - الجزء الأول النسخة الكاملة من كتاب نحو فهم أعمق لتقنيات HTML5

التصنيفات (categories) والوسوم (tags) هما النوعان الأساسيان من الفئات (taxonomies) التي توفرها ووردبريس لتنظيم المحتوى، لكن كيفية استخدامهما بفعالية هو موضوعٌ شائكٌ لمدراء المواقع. كان هنالك جدلٌ كبيرٌ حول مزايا كلٌ منهما على مر السنين، وحتى المستخدمين الخبراء كانوا يضيعون أوقاتهم بتفصيلات غير ضرورية، خصيصًا عندما يأتي الحديث عن موضوع SEO. سنشرح في هذا الدرس بطريقةٍ مباشرة كيف تستعمل التصنيفات والوسوم بفعالية، مع وضع المحتوى وقابلية الاستخدام في قائمة أولوياتنا. لمحة عن أساسيات التصنيفات والوسوم كانت التصنيفات هي الفئة الوحيدة المتاحة للمستخدمين، ثم أُضيفت الوسوم لاحقًا في الإصدار 2.3؛ ومن المؤكد أنَّك تعاملت معهما بعد ذاك الإصدار مئات المرات. قبل أن ندخل بالتفصيل في كليهما، لنأخذ نظرةً على الأساسيات: مكان الاستخدام: افتراضيًا، يمكن استعمال التصنيفات (categories) والوسوم (tags) في المنشورات (posts) فقط، وليس في الصفحات (pages) الاستخدام: يجب أن يملك كل منشور تصنيفًا واحدًا على الأقل، أما استعمال الوسوم فهو اختياري الهيكلية: يمكن وضع التصنيفات في هيكليةٍ ذات عدِّة مستويات (levels)، أما الوسوم فهي ذات مستوى وحيد ربما أسهل طريقة للتفكير بالاستخدامات المثلى للتصنيفات والوسوم هو أن نأخذ مثالًا ألا وهو "الكتاب". يمكن أن نعتبر أنَّ التصنيفات هي "الفصول" التي تجمع المواضيع المتشابهة، أما الوسوم فهي أشبه بالفهرس. لنأخذ مثالًا أكثر تحديدًا: إذا كان لديك موقعٌ عن الطبخ، فربما تستعمل التصنيفات (categories) لتُجمِّع المأكولات التي تنتمي لنفس الدولة (الطعام الإيطالي، أو الفرنسي، أو الهندي)؛ وقد تود إنشاء تصنيفات فرعية إن شئت. أما على الجانب الآخر، قد ترغب بتحديد المأكولات التي تستعمل مكونات معيّنة (أي تلك المعلومات التي تتوفر في أكثر من تصنيف)، وستكون الوسوم خيارًا ممتازًا لفعل ذلك. فالضغط على وسم "الطماطم" سيُظهِر لك الوصفات التي تعتمد على الطماطم في جميع أنحاء العالم. إعداد التصنيفات قبل أن نبدأ بإنشاء التصنيفات، من المفيد قضاء بعض الوقت بالتفكير حول هيكليها. ستتوسَّع قائمة التصنيفات مع مرور الزمن، وستصبح التصنيفات الفرعية أمرًا ضروريًا، لكن تريد أن تكون الأمور منظمةً هنا. تخيل التصنيفات على أنها فصولٌ في كتابٍ التي عليك أن تبدأ بها، فإن وجدتَ نفسك تبدأ بخمسة عشر تصنيفًا فعليك أن تُعيد التفكير في الأمر. في حين أنك قادرٌ على إضافة تصنيفات جديدة من واجهة تحرير المنشورات، لكن الواجهة الرئيسية لإضافتها هي في: المقالات > التصنيفات التي تُظهِر قائمةً بالتصنيفات الموجودة حاليًا مع عدد المقالات المُصنَّفة تحتها، وتمنحك طريقةً سهلةً لإضافة تصنيفات جديدة. لنشرح باختصار الخيارات الظاهرة في الصورة عند إنشاء التصنيف: الاسم (Name): هو ما ستراه في موقعك اعتمادًا على القالب (theme) الذي تستعمله، اختر أسماءً واضحةً والتي تُفهَم بسهولة من قِبل مستخدميك، والتي يمكن أن تحتوي على كلمة مفتاحية (keyword)، وأبق الأسماء مختصرة قد الإمكان. الاسم اللطيف (Slug): هو نسخة من الاسم تلائم روابط URL التي ستظهر في أرشيف التصنيفات وفي روابط منشوراتك إن كنت تستعمل الروابط الدائمة المخصصة (سنشرح كلا الأمرين لاحقًا بالتفصيل)؛ لكن كل ما عليك تذكره الآن هو أن تستعمل الشرطات "-" (dashes) لفصل الكلمات، وأن تحذف كلمات الوصل، وأن تتجنب حشو الكلمات المفتاحية أب (Parent): استخدم هذا الحقل لإضافة تصنيف فرعي، أو أبقه مشيرًا إلى "بدون" (أو None في الواجهة الإنكليزية) لإنشاء تصنيف رئيسي الوصف (Description): ربما يُستعمَل هذا الوصف في أي مكان في الموقع اعتمادًا على القالب الذي تستخدمه، أو ربما تطلب عرض الوصف يدويًا يمكن إسناد أكثر من تصنيف إلى منشورٍ ما، لكن عليك أن تبقي الأمور منظمة جدًا كيلا تثير حيرة المستخدمين. حاول أن يكون العدد الأقصى للتصنيفات لمنشورٍ ما هو تصنيفان (ويُفضَّل أن يكون تصنيفًا وحيدًا)؛ وإذا أردت أن تُشير إلى معلوماتٍ إضافية موجودة في مكانٍ آخر في موقعك، فاستخدم الوسوم. اعتمادًا على طبيعة موقعك، ربما تجد أنَّ التصنيف الافتراضي "غير مُصنَّف" (Uncategorized) ليس مفيدًا جدًا، وربما تود إسناد اسم مثل "أفكار عامة" على سبيل المثال، تستطيع فعل ذلك عبر تعديل التفاصيل في صفحة "التصنيفات" التي شاهدناها سابقًا. التصنيفات والروابط الدائمة كما شرحنا سابقًا في درسنا عن الروابط الدائمة (permalinks)، يمكنك تضمين أسماء التصنيفات في روابط URL عبر استخدام الروابط الدائمة المخصصة. وذلك بزيارة: إعدادات > روابط دائمة في لوحة التحكم ثم تستعمل الوسم البنيوي %category% جزءًا من البنية المُخصَّصة (Custom Structure). هذا مثالٌ عن ذلك: لقد قررنا استخدام التركيبة category/postname (أي اسم التصنيف يليه اسم المنشور) كتركيبة مخصصة للروابط في موقعنا؛ فلو كان عندما منشورٌ اسمه اللطيف (slug) هو my-music-post والاسم اللطيف للتصنيف هو classical، فسيبدو الرابط كما في الصورة الآتية: أبقِ في بالك أنَّ عليك اختيار تركيبة الروابط الدائمة في بدايات عمل الموقع لتجنب الفوضى الناتجة عن إعادة التوجيه. على الرغم من أنك سترى بعضهم يقول أنَّ استعمال التصنيفات في الروابط الدائمة مفيدٌ لتقييم SEO، لكنه ليس عاملًا حاسمًا أبدًا؛ فكر في استخدام التصنيفات في الروابط الدائمة إن رأيت فائدةً لمستخدميك بدلًا من محاولة جذب محركات البحث. ضبط تركيبة التصنيف إن أكملت معنا بزيارة: إعدادات > روابط دائمة في القسم السابق، لوجدت خيارًا تحت عنوان "اختياري" (Optional) للتحكم بما يُسمى "تركيبة التصنيف" (Category base). يعطيك هذا الخيار القدرة على تغيير ما يأتي قبل أسماء التصنيفات في صفحات الأرشيف الخاصة بها، ففي المثال الآتي، قمت بتغيير تركيبة التصنيف إلى "music" التي ستراها قبل اسم التصنيف "classical" في رابط صفحة الأرشيف. قرارك باستخدام تركيبة مخصصة للتصنيفات هو بعيدٌ جدًا لأن يكون القرار الوحيد الذي عليك اتخاذه فيما يتعلق بصفحات أرشيف التصنيفات؛ لكن عليك أيضًا تقرير كيف تستطيع إبراز تلك الصفحات فيما يتعلق بـ SEO أو إذا ما كنت تريد تخصيص محتواها. التعامل مع صفحات أرشيف التصنيفات هنالك الكثير من الكلام حول موضوع صفحات أرشيف التصنيفات على الويب، لكن يمكن اختصار الخيارات المتاحة أمامك إلى خيارين: تريد إبراز صفحات التصنيف الرئيسي: تتحمل عناء تخصيص المحتوى، وتفهرس الصفحة الرئيسية (وليس صفحات الأرشيف الفرعية)، وتسمح بتتبع (follow) الروابط لا تريد إبراز صفحات التصنيف الرئيسي: ستضع noindex و nofollow على جميع صفحات الأرشيف ماذا يعني ما سبق عمليًا؟ إذا كنت تُحضِّر لمعاملة صفحات أرشيف التصنيف الرئيسي عندك كصفحات هبوط (landing pages)، فعليك اتباع الخيار الأول؛ فلنقل أنَّ لديك صفحة أرشيف لتصنيفٍ ما في http://www.example.com/topics/restaurant-seo وأردت أن تكون الصفحة الرئيسية لذاك الموضوع على موقعك. ففي الحالة السابقة، عليك حتمًا أن تُخصِّص مظهر صفحة الأرشيف نفسها، وتجعلها محببة للمستخدمين؛ وهذا يتضمن عرض نص إضافي (مثلًا: وصف التصنيف الذي تحدثنا عنه سابقًا)، أو توفير قوالب مختلفة لمختلف التصنيفات، وعرض مقتبسات من المنشورات بدلًا من عرض المنشورات كلها. وستود أيضًا التحكم في كيفية معاملة محركات البحث لتلك الصفحة؛ ففي هذا المثال، ربما تريد أن تتأكد أنَّ الصفحة الرئيسية الموجودة في ‎/topics/restaurant-seo مُفهرسة وسيتم اتباع جميع الروابط فيها، وعليك أن تتأكد أنَّ الصفحات الفرعية مثل ‎/topics/restaurant-seo/2 غير مفهرسة. وبهذا ستحصل على أفضل نتيجة: إذ أنَّ مستخدميك قادرون على تصفحك ما يشاؤون، وستُبرِز محركات البحث المحتوى الذي تريد. إضافات SEO القوية مثل All in One SEO Pack تمنحك الكثير من الخيارات للتحكم بإعدادات nofollow و noindex، بالإضافة إلى تحكم دقيقة بآلية توليد خريطة الموقع (sitemap). إن لم تكن تريد أن تُخصِّص مجهودًا لصفحات أرشيف التصنيف، فاستعمل خيارَي noindex و nofollow لكي تجعل محتوى موقعك الرئيسي يجذب محركات البحث دون "مساعدة". إدارة الوسوم أولى الأمور التي يجب الإشارة إليها فيما يتعلق بالوسوم هي أنَّك لستَ مُجبرًا على استعمالها في كل منشور، العامل الحاسم الحاكم لاستعمالها هو القيمة التي تظن أنَّها ستقدمها لزوار موقعك، دون أن تحاول "العبث" مع محركات البحث. اتبع الإرشادات الآتية عند إضافة الوسوم إلى المحتوى: قلل عدد الوسوم في كل منشور إلى خمسة فقط: تُربِك الوسوم الكثير الزوار. فكر مليًا في كل وسم على حدة وتأكد أنَّه يشير إلى شيءٍ محدَّدٍ ومفيد. لا تكرر الأسماء في التصنيفات والوسوم: وذلك لتنظيم الموقع، ولتبسيط الأمر على المستخدمين. أبقِ أسماء الوسوم قصيرةً: حاول أن تكون ثلاث كلمات على الأكثر. استعمل نمطًا موحدًا من الأحرف الكبيرة: مثلًا، Hsoub Academy ليست مثل hsoub academy، وهذه المشكلة تخرج عن السيطرة في المواقع الكبيرة، لذلك عليك تحديد نمط معيّن والالتزام به دومًا. تأكد أنَّ الوسوم مستخدمة: فلن تستفيد من وسم مستخدم في منشور وحيد؛ يجب أن يكون هنالك من ثلاثة إلى خمسة منشورات يمكن إضافة الوسم إليها قبل إنشاءه. وكما في التصنيفات، يمكنك إضافة الوسوم عند تحرير المنشورات، أو تستطيع إدارتها مباشرةً عبر الصفحة: المقالات > الوسوم وكما ترى في الصورة السابقة، لديك خياراتٌ مشابهة لخيارات إدارة التصنيفات. أمر صفحات أرشيف الوسوم مشابهٌ لما جاء في صفحات أرشيف التصنيفات، ربما تستعمل إضافةً مثل All in One SEO Pack للتحكم في الفهرسة والتتبع. الخلاصة قد يكون موضوع التصنيفات والوسوم مربكًا لك في البداية، لكنك ستستطيع بعد فترةٍ أن تستعملها بسهولة عبر التفكير المنطقي بوظيفتها. يمكنك استعمال التصنيفات لإضافة هيكلية إلى منشوراتك ولإعطاء المستخدمين فكرة واضحة عن المكان الذي سيعثرون فيه عن محتوى مشابه. استعمل الوسوم للإشارة إلى بعض الأمور المشتركة بين منشوراتٍ مختلفة الموضوع. عندما يأتي الأمر إلى المخاوف من SEO، فلا تُدخِل نفسك في دوامة، اتخذ قرارًا حول تحضيرك لإبراز صفحات الأرشيف ثم عدِّل القوالب، واستعمل الوسوم بحكمة لإضفاء طابع من التناغم. إن كانت لديك أيّة أسئلة أو استفسارات حول التصنيفات والوسوم، فاترك تعليقًا وسنحاول جاهدين مساعدتك. ترجمة -وبتصرّف- للمقال Using Categories and Tags Effectively in WordPress لصاحبه Tom Ewer.

شريط أدوات الإدارة في ووردبريس هو ذاك الشريط الرفيع الأسود التي يظهر في أعلى الصفحة في موقعك، ويحتوي على قوائم وروابط تُشير عادةً إلى صفحاتٍ معيّنة في لوحة التحكم مثل تعديل المنشورات، وصفحة حساب المستخدم، وتخصيص القوالب والمزيد. بغض النظر عن الميزات المفيدة لشريط الأدوات، لكن قد يصبح مزعجًا وخصيصًا عندما لا تريد منح جميع المستخدمين وصولًا إلى لوحة التحكم، أو لأنك لا تحب وجود مستطيل أسود أثناء تصفحك لموقعك. لكن شريط الأدوات هو جزءٌ مهم لمدير ووردبريس ويمكن أن يكون مفيدًا جدًا بعد تخصيصه بشكلٍ ملائم لكي يوفر وصولًا سريعًا إلى أقسام الموقع وإلى معلومات محددة. سأريك كيف تُدير شريط أدوات ووردبريس، عبر إزالته لمستخدمين معينين، أو إضافة روابط وقوائم جديدة، أو تخصيص مظهره. إزالة شريط أدوات الإدارة قد تود في بعض الأحيان أن تُزيل شريط الأدوات من واجهة موقعك، إذ تستطيع إخفاءه لجميع المستخدمين أو لمستخدمين أولي دورٍ (role) محدد. السطر الآتي عندما تُضيفه إلى ملف functions.php (ولا تنسَ أن تستعمل قالبًا فرعيا child theme) سيحذف شريط الأدوات لجميع مستخدمي الموقع: <?php show_admin_bar( false ); ?> يجب على الدالة show_admin_bar أن تستدعى مباشرةً عند تحميل الإضافة ولا حاجة إلى استدعائها من دالة مرتبطة (hooked) بالحدث (action) المسمى init. الحالة الأكثر شيوعًا هي إخفاء شريط الأدوات بناءً على امتيازات أو دور المستخدم. ستخفي الشيفرة الآتية شريط الأدوات لكل المستخدمين ما عدا المدراء والمحررين: <?php /** * Remove WordPress Toolbar for subscribers */ function myplugin_remove_admin_bar() { if ( ! current_user_can( 'publish_posts' ) ) { show_admin_bar( false ); } } add_action( 'plugins_loaded', 'myplugin_remove_admin_bar' ); ذكرتُ قبل قليل أنَّه لا يُشترَط أن تستدعى الدالة show_admin_bar عبر دالة مرتبطة بحدثٍ ما. ولهذا قد تتساءل لماذا أضفناها إلى الحدث plugins_loaded؟ إن لم نفعل ذلك في هذه الحالة، فستُظهِر ووردبريس رسالة الخطأ الآتية: Fatal error: Call to undefined function wp_get_current_user() أما لو كنتَ تستدعي الدالة current_user_can()‎ من داخل ملف functions.php في قالبٍ ما، فعليك أن تربط (hook) تلك الدالة بحدث after_setup_theme. هذا المثال مشابه كثيرًا للمثال السابق إلا أنَّه يعمل في القوالب: <?php /** * Remove WordPress Toolbar for all users except admins and editors * */ function mytheme_remove_admin_bar() { if ( ! current_user_can( 'publish_posts' ) ) { show_admin_bar( false ); } } add_action( 'after_setup_theme', 'mytheme_remove_admin_bar' ); إذا أردت أن تكون الشيفرة السابقة قابلة لإعادة الاستخدام، فمن المفضل ربط الدالة إلى الحدث after_setup_theme دائمًا. منذ الإصدار 3.1، وفَّرَت ووردبريس المُرشِّح (show_admin_bar (filter، لذلك أصبحت لدينا طريقة أخرى لأداء نفس المهمة. فلو أردنا مثلًا إخفاء شريط الأدوات من جميع المستخدمين بسطرٍ وحيد: <?php add_filter( 'show_admin_bar', '__return_false' ); ?> وهو مماثل تمامًا للأسطر الآتية: <?php /** * Remove WordPress Toolbar for all users * */ function myplugin_remove_admin_bar(){ return false; } add_filter( 'show_admin_bar' , 'myplugin_remove_admin_bar' ); يمكنك أيضًا إظهار أو إخفاء شريط الأدوات بناءً على امتيازات المستخدم: <?php /** * Remove WordPress Toolbar for users not allowed to publish posts * * @param bool $show_admin_bar Whether the admin bar should be shown */ function myplugin_remove_admin_bar( $show_admin_bar ) { if( current_user_can( 'publish_posts' ) ){ return $show_admin_bar; } else{ return false; } } add_filter( 'show_admin_bar' , 'myplugin_remove_admin_bar' ); سيَظهَر شريط الأدوات -في المثال السابق- إلى المدراء والمحررين فقط (الذين يستطيعون النشر publish_posts). هذا كل ما عليك معرفته إن أحببت إزالة الشريط، لكن ماذا لو أردت أن تستخدم شريط الأدوات لإضافة ميزاتٍ جديدةٍ إليه؟ تخصيص شريط الأدوات الصنف WP_Admin_Bar يتحكم في شريط الأدوات، وعبره نستطيع إضافة أو حذف عناصر القائمة أو مجموعات من العناصر. سنستخدم الدوال الثلاث الآتية في أمثلتنا القادمة: ()add_node ()add_group get_node()‎ تُعرَّف القوائم الافتراضية في ملف ‎/wp-includes/admin-bar.php، وبعض تلك القوائم متوفرة لجميع المستخدمين الذين سجلوا دخولهم، مثل قائمة "شعار ووردبريس" (التي فيها بعض الروابط التعليمية)، وقائمة "حسابي (التي تُظهِر بعض الروابط المتعلقة بالمستخدم الحالي)، وقائمةٌ باسم الموقع (التي توفر روابط سريعة للوحة التحكم). لكن ووردبريس تعطينا القدرة على إضافة قوائم مخصصة وروابط إضافية ومعلومات نصية وحقول للنماذج (forms). لن أشرح هنا طريقة إضافة العناصر إلى شريط الأدوات، لكنني سأريك مثالين عمليين لكيفية تخصيص الشريط، وسأبدأ بتحديثٍ بسيطٍ لقائمة "حسابي". كيفية إضافة عناصر جديدة إلى قائمة موجودة مسبقا عندما يكون هدفنا هو إضافة عناصر جديدة إلى شريط الأدوات بناءً على امتيازات المستخدم، فعلينا تمرير مُعامل (argument) إلى الدالة التي ستُستدعى ألا وهو نسخةٌ من كائن WP_Admin_Bar. يمكن أن ترتبط الدالة بالحدث admin_bar_menu كما هو موضَّح في المثال الآتي: <?php function myplugin_customize_toolbar( $wp_admin_bar ){ // your code here } add_action( 'admin_bar_menu', 'myplugin_customize_toolbar', 999 ); ذكرتُ سابقًا في هذه المقالة أننا نستطيع بناء قوائم جديدة بالإضافة إلى إضافة روابط إلى قوائم موجودة مسبقًا. سنتيح للمستخدم -في المثال الآتي- رابطًا سريعًا إلى موقعه الإلكتروني وذلك بإضافة عقدة (node) جديدة إلى قائمة "حسابي". عندما يتم تحميل الملف admin-bar.php، فستُنشَأ مجموعةٌ جديدةٌ من العقد (nodes) باسم user-actions التي ستُضاف إلى قائمة my-account، هذه المجموعة هي المجموع الرئيسية التي ستُضاف إليها أيّة روابط لتظهر في تلك القائمة الفرعية. وظيفة الشيفرة الآتية هي إضافة رابط إلى المجموعة: <?php /** * Customize WordPress Toolbar * * @param obj $wp_admin_bar An instance of the global object WP_Admin_Bar */ function myplugin_customize_toolbar( $wp_admin_bar ){ $user = wp_get_current_user(); if ( ! ( $user instanceof WP_User ) ){ return; } $my_account = $wp_admin_bar->get_node( 'my-account' ); if( ! empty( $user->user_url ) && $my_account ){ $wp_admin_bar->add_node( array( 'parent' => 'user-actions', 'id' => 'user-url', 'title' => '<span class="user-url">' . __( 'My Website' ) . '</span>', 'href' => esc_url( $user->user_url ) ) ); } } add_action( 'admin_bar_menu', 'myplugin_customize_toolbar', 999 ); في البداية، حصلنا على كائن ‎‎$current_user‎ ثم تحققنا أنَّه نسخةٌ من صنف WP_User، ثم حصلنا على كائن العقدة my-account، الذي يُشير إلى قائمة "حسابي" الموجودة على الجانب الأيسر من شريط الأدوات (أو الجانب الأيمن إن لم تكن تستخدم النسخة العربية من ووردبريس). في النهاية نتحقق من وجود الحقل user_url وتوفر كائن العقدة، ثم سنضيف user-url إلى القائمة. الدالة السابقة ستولد شيفرة HTML الآتية: <li id="wp-admin-bar-user-url"> <a class="ab-item" href="http://example.com"> <span class="user-url">My Website</span> </a> </li> القائمة الناتجة موضحة في الصورة الآتية: مثال متقدم: قوائم شرطية، وأنواع مقالات مخصصة والمزيد تتوفر بعض قوائم شريط الأدوات في صفحاتٍ معيّنة فقط، على سبيل المثال، قائمة "تحرير المقالة" (Edit post) التي توفر رابطًا سريعًا لتعديل صفحة المنشور (post) أو الفئة (taxonomy) الحالية تظهر فقط في صفحات المنشورات وأرشيفات الفئات. وقد يوحي ما سبق لنا بفكرةً ألا وهي إظهار عناصر القائمة في شروطٍ معينة، الشرط في المثال الآتي يعتمد على امتيازات المستخدم. قد نود إظهار قائمة لمحرري الموقع تحتوي على مجموعة من الروابط التي تُشير إلى صفحات في لوحة التحكم التي تحتوي على المنشورات التي تنتظر النشر (رابط لكل نوع من أنواع المنشورات). ستستفيد المواقع التي فيها أكثر من محرر كثيرًا من مثل هكذا قائمة، وذلك عندما يكتب المستخدمون مقالاتٍ (أو منشورات مخصصة) متوقعين أن تتم مراجعتها للنشر. لنعد الآن إلى دالتنا ولنضف الشيفرة الآتية: <?php /** * Customize WordPress Toolbar * * @param obj $wp_admin_bar An instance of the global object WP_Admin_Bar */ function myplugin_customize_toolbar( $wp_admin_bar ){ $user = wp_get_current_user(); if ( ! ( $user instanceof WP_User ) ){ return; } $my_account = $wp_admin_bar->get_node( 'my-account' ); // Add a custom link to My Account menu if( ! empty( $user->user_url ) && $my_account ){ $wp_admin_bar->add_node( array( 'parent' => 'user-actions', 'id' => 'user-url', 'title' => '<span class="user-url">' . __( 'My Website' ) . '</span>', 'href' => esc_url( $user->user_url ) ) ); } if( current_user_can( 'editor' ) ){ // Add a new node to the Toolbar // The link points to the pending posts admin page $wp_admin_bar->add_node( array( 'id' => 'editor-menu', 'title' => '<span class="ab-icon"></span><span class="ab-label">' . __( 'Pending posts' ) . '</span>', 'href' => admin_url( 'edit.php?post_status=pending' ) ) ); // Add group of links $wp_admin_bar->add_group( array( 'parent' => 'editor-menu', 'id' => 'editor-actions' ) ); // Get post types $cpts = (array) get_post_types( array( 'show_in_admin_bar' => true ), 'objects' ); foreach ( $cpts as $cpt ) { if ( ! current_user_can( $cpt->cap->publish_posts ) ) continue; // Get pending posts and post types $posts = get_posts( array( 'post_type' => $cpt->name, 'post_status' => 'pending' ) ); $num = count( $posts ); $title = $num . ' ' . $cpt->label; // Add a new link for each post type $wp_admin_bar->add_node( array( 'parent' => 'editor-actions', 'id' => 'edit-' . $cpt->name, 'title' => $title, 'href' => admin_url( 'edit.php?post_status=pending&post_type=' . $cpt->name ) ) ); } } add_action( 'admin_bar_menu', 'myplugin_customize_toolbar', 999 ); أولًا تحققنا إن كان المستخدم الحالي محررًا، فإن كان الأمر كذلك، فستُضاف القائمة الرئيسية editor-menu، ثم سنضيف المجموعة editor-actions مع ضبط أنها ستكون قائمة فرعية للقائمة الرئيسية editor-menu. هنا يأتي الجانب المسلي: الدالة get_post_types تولد مصفوفة بكائنات أنواع المنشورات المخصصة ثم سنتحقق إن كان المستخدم الذي سجل دخوله له امتيازات التحرير على كل نوع منشورات مخصص (أي أنَّ المستخدم قادر على نشر المنشورات publish_posts) ثم سنحصل على مصفوفة لكل المنشورات التي تنتظر النشر في نوع المنشورات المخصص ونحصي عددهم. في النهاية، سنضيف عقدة (أو عنصر) إلى مجموعة editor-actions. وسيُشير كل رابط في تلك المجموعة إلى صفحة تحرير المنشورات التي تنتظر النشر. وإذا أردت أن تخصص طريقة عرض القائمة بإضافة أيقونة من مجموعة، فأضف الشيفرة الآتية إلى إضافتك (plugin) أو إلى ملف functions.php: <?php /** * Prints style element */ function myplugin_custom_css() { $output = '<style> wpadminbar wp-admin-bar-editor-menu .ab-icon:before { content: "\f322"; top: 2px; } </style>'; echo $output; } add_action( 'wp_head', 'myplugin_custom_css' ); ربطنا الدالة السابقة إلى الحدث المسمى wp_head التي -أي الدالة- ستطبع عنصر <style> في ترويسة (head) الصفحة. أعلم أنَّ هذه ليست أفضل طريقة عند تضمين ملفات الأنماط في مستند، لكننا نضيف هنا سطرًا وحيدًا، ولن يكون تحميل ملف CSS كامل خيارًا عمليًا. لكن إن كنت تريد أن يبدو شريط الأدوات كباقي موقعك، فعليك أن تعيد تعريف الأنماط الموجودة في ‎/wp-includes/css/admin-bar.css ثم تُضمِّن الأنماط الخاصة بك. الخلاصة إذا تركت شريط الأدوات كما هو، فقد يبدو لك غير ضروري وأنَّه شيءٌ قبيحٌ قابعٌ في أعلى صفحات موقعك، لكن إن فكرت في إمكانية الاستفادة منه بعد تخصيصه، فسيصبح أداةً مهمةً ومفيدةً ومرنةً، سواءً لمالكي الموقع أو للمستخدمين الذين يشاركون به. هل تستخدم شريط الأدوات في مواقعك؟ هل أضفت قوائم جديدة أو وظائف متقدمة له من قبل؟ هل لديك أيّة أفكار أحببت تطبيقها عليه لكن لم تفعل ذلك بعد؟ شاركنا بذلك في التعليقات. ترجمة -وبتصرّف- للمقال Customizing (or Removing) the WordPress Admin Toolbar لصاحبه Carlo Daniele.

تتوفر آلاف الأوامر لمستخدمي سطر أوامر لينُكس، لكن كيف تستطيع تذكرها جميعًا؟ الجواب هو أنَّك لا تحتاج إلى ذلك؛ فالقوة الحقيقية للحاسوب تظهر عندما يقوم بالعمل عوضًا عنك، وذلك باستخدام سكربتات الصدفة (Shell Scripts) لأتمتة المهام. ما هي سكربتات الصدفة؟ بأبسط تعريفٍ لها: سكربت الصّدفة هو ملف يحتوي على سلسلة من الأوامر التي تقرأها الصَدَفة (shell) وتنفِّذ الأوامر التي فيها كما لو أنها أُدخِلَت مباشرةً من سطر الأوامر. الصَدَفة هي برمجية فريدة من نوعها، وذلك لأنها توفر واجهة سطرية (أي من سطر الأوامر) للتعامل مع النظام مع كونها مُفسِّر (interpreter) للسكربتات. وكما سنرى لاحقًا، أيّ شيء يمكنك القيام به في سطر الأوامر يمكن فعله في سكربتات الصدفة، وأغلبية الأشياء التي تستطيع كتابتها في سكربتات الصدفة يمكن تنفيذها مباشرةً في سطر الأوامر. سنُركِّز في هذه السلسلة على الميزات التي تُستخدم عادةً عند كتابة السكربتات. كتابة أول سكربت لك يجب أن تفعل ثلاثة أشياء لكي تكتب سكربت شِل: كتابة السكربت السماح للصَدَفة (shell) بتنفيذه (أي إعطاؤه إذن التنفيذ x) وضعه في مكانٍ تستطيع الصَدَفة العثور عليه فيه سكربت الصّدفة ما هو إلا ملف يحتوي على نص عادي؛ فلا يلزمك إلا محرر نصي لكتابة سكربتات الصدفة. "المحرر النصي" هو برنامج -يشبه برامج التحرير المكتبي- يستطيع قراءة وكتابة ملفات ASCII النصية. هنالك الكثير من المحررات النصية المتوفرة على نظام لينُكس سواءً كانت سطريةً (أي تعمل من سطر الأوامر) أم رسوميةً؛ هذه قائمة تحتوي على أشهرها: vi أو vim: المحرر النصي السطري الشهير في نظام يونكس المعروف بصعوبة فهم بنية الأوامر فيه؛ لكنه -على الكفة الأخرى- محرر كفؤ وقوي جدًا وخفيف وسريع. سيؤتي تعلم vi أُكله لأنه متوفر على جميع الأنظمة الشبيهة بِيونكس (Unix-like). النسخة الموجودة من vi في أغلبية توزيعات لينُكس هي النسخة المُحسَّنة التي تدعى vim. Emacs: كبير المحررين في عالم النصوص الذي برمَجَه ريتشارد ستالمان. يحتوي محرر Emac (أو يستطيع أن يحتوي) على كل ميزة يمكن أن تتواجد في أي محرر نصي على الإطلاق! يجدر بالذكر أنَّ مستخدمي vi و Emacs يشتبكون مع بعضهم (على الإنترنت بالطبع!) محاولين إثبات أنَّ محررهم هو الأفضل. nano: هو برنامج سطري شبيه بالمحرر النصي المضمَّن مع عميل البريد الإلكتروني pine، وهو سهل الاستخدام لكن ميزاته قليلة. أنصح عادةً باستخدام nano لمَن يتعامل مع سطر الأوامر لأول مرة. gedit: هو محرر رسومي يأتي مع سطح مكتب غنوم (Gnome). kate: هو محرر رسومي ذو ميزات متقدمة تُسهِّل كتابة السكربتات ويأتي مع حزمة برمجيات كدي (KDE). افتح الآن محررك النصي المفضَّل واكتب فيه أول سكربت لك: !/bin/bash My first script echo "Hello World!" إذا كنتَ سريع البديهة، فمن المرجح أنَّك عرفت كيف تلصق النصوص في المحرر النصي الذي اخترته. إذا فتحت أيّ كتابٍ عن البرمجة من قبل، فستتعرف مباشرةً على برنامج "Hello World" التقليدي الذي يُجسِّده المثال السابق. احفظ الملف باسمٍ ذي معنى (ربما hello_world). أول سطر في الملف مهمٌ وله تأثيرٌ خاص، إذ يُسمى "shebang" وسيخبر الصَدَفة أيّ مُفسِّر عليها استدعاؤه لتفسير هذا السكربت، الذي هو في حالتنا ‎/bin/bash. تستعمل لغات السكربتات الأخرى مثل perl و awk و tcl و php و python هذه الآلية. السطر الثاني في الملف هو تعليق. أيّ شيء يأتي بعد علامة يُعتبر تعليقًا وستتجاهله الصَدَفة تمامًا. لكن عندما يزداد تعقيد برامجك فستصبح التعليقات مهمة جدًا، إذ يستعملها المبرمجون لشرح ما حولها لتسهيل فهم الآخرين له. آخر سطر في السكربت السابق هو الأمر echo الذي يطبع ما يليه على الشاشة. ضبط الأذونات علينا الآن إعطاء إذن التنفيذ لسكربت الصّدفة الذي كتبناه، وذلك بالأمر chmod كما يلي: $ chmod 755 hello_world الإذن "755" سيسمح لك بالقراءة والكتابة والتنفيذ، بينما سيتمكن بقية المستخدمين من قراءة وتنفيذ السكربت فقط. أما إذا أردت أن يكون السكربت خاصًا بك (أي أنَّك الوحيد الذي تستطيع قراءته وتنفيذه) فضع "700" بدلًا من "755". راجع درس مبادئ أذونات الملفات على لينكس للمزيد من المعلومات. وضع الملف في المكان الصحيح تستطيع عند هذه المرحلة تشغيل السكربت كما يلي: $ ./hello_world يجب أن تشاهد العبارة "Hello World!‎" على الشاشة، وإن لم ترها فانظر أين حفظت السكربت، وانتقل إلى ذاك المجلد (بالأمر cd) ثم جرب مرِّة أخرى. علينا الآن أن نتوقف قليلًا ونتحدث عن المسارات. عندما تكتب اسم أحد الأوامر فلن يبحث النظام (أو بالأحرى "الصَدَفة") عن ذاك البرنامج في جميع مجلدات حاسوبك لأن ذلك سيستغرق وقتًا طويلًا؛ ولكنك لاحظت أيضًا كيف أنَّك لا تحتاج إلى تحديد المسار الكامل للبرامج التي تريد تشغيلها وستظن أنَّ الصَدَفة تعرف أين تجدها. حسنًا، أنت محق: الصَدَفة تعرف أين تجد البرمجيات، لأنها -أي الصَدَفة- تحتوي على قائمة بالمجلدات التي تتواجد فيها الملفات التنفيذية (أي البرامج)، وستبحث داخل المجلدات في تلك القائمة عن البرامج، فإن لم تجد ما تبحث عنه في أحد تلك المجلدات فستظهر رسالة الخطأ الشهيرة command not found. يمكنك أن ترى تلك القائمة بكتابة الأمر الآتي: $ echo $PATH الذي سيطبع قائمة مفصولة بنقطتين رأسيتين للمجلدات التي سيتم البحث فيها عن البرامج إذا لم يُحدَّد مسارها الكامل. لاحظ كيف أننا حدَّدنا المسار (‎./‎) عند محاولتنا تشغيل السكربت سابقًا. يمكنك إضافة مجلدات إلى تلك القائمة باستخدام الأمر الآتي، حيث directory هو مسار المجلد الذي تريد إضافته: $ export PATH=$PATH:directory لكن من المستحسن أن تُعدِّل ملف ‎.bashrc‎ أو ‎.profile (اعتمادًا على توزيعتك) لتضمين الأمر السابق فيه، وبهذا سيُنفَّذ في كل مرّة تُسجِّل دخولك فيها. تسمح بعض توزيعات لينُكس بإنشاء مجلد خاص بكل مستخدم ليضع فيه برامجه الشخصية، ويدعى ذاك المجلد bin وهو مجلد فرعي موجود في مجلد المنزل (home) الخاص بك. إن لم يكن موجودًا، فتستطيع إنشاءه بالأمر: $ mkdir bin انقل السكربت إلى مجلد bin (ربما تستخدم الأمر mv) ثم اكتب: $ hello_world وسيعمل السكربت. لاحظ أنَّك قد تحتاج في بعض التوزيعات (مثل أوبنتو) إلى بدء جلسة (session) جديدة حتى تتعرَّف الصَدَفة على المجلد bin. ترجمة -وبتصرّف- للمقال Writing Your First Script And Getting It To Work لصاحبه William Shotts.