اذهب إلى المحتوى

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

الأعضاء
 عرض الملف الشخصي  تصفح المحتوى

  • المساهمات

    1395

  • تاريخ الانضمام

  • تاريخ آخر زيارة

  • عدد الأيام التي تصدر بها

    63

 نوع المحتوى 

ريادة الأعمال

البرمجة

التصميم

DevOps

التسويق والمبيعات

العمل الحر

البرامج والتطبيقات

آخر التحديثات

قصص نجاح

أسئلة وأجوبة

كتب

دورات

كل منشورات العضو عبد اللطيف ايمش

  1. عبد اللطيف ايمش
    مزيد من المعلومات حول "استخدام الدوال في سكربات الصدفة (Shell Scripts)"
    عندما يزداد طول البرامج وتعقيدها، فستزداد صعوبة تصميمها وبرمجتها وصيانتها؛ لذا من المفيد عادةً تقسيم المهام الكبيرة إلى سلسلة من المهام الأصغر. سنُقسِّم في هذا الدرس السكربت الذي كنا نعمل عليه إلى عدد من الدوال (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.
  2. عبد اللطيف ايمش
    مزيد من المعلومات حول "نظرة على تاريخ HTML - الجزء الأول"
    وقعتُ أخيرًا بالصدفة على اقتباس من مطور في مشروع 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
  3. عبد اللطيف ايمش
    مزيد من المعلومات حول "توزيع شيفرات PHP على عدة ملفات"
    سنشرح في هذا الدرس كيف نوزِّع شيفرات على عدِّة ملفات وكيف نُضمِّن شيفرات من ملفات أخرى. توفِّر 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
  4. عبد اللطيف ايمش
    مزيد من المعلومات حول "المتغيرات والثوابت وتعويض الأوامر في سكربتات الصدفة (Shell Scripts)"
    رأينا في الدرس السابق كيف كتبنا سكربتًا يولِّد صفحة 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.
  5. عبد اللطيف ايمش
    مزيد من المعلومات حول "كيفية نقل المحتوى من موقع ووردبريس إلى موقع آخر خطوة بخطوة"
    قد تكون عملية نقل المحتوى من موقع ووردبريس إلى آخر عمليةً تُضيّع الوقت وتُسبِّب الصداع، إذ لا تستطيع ببساطة نقل الملفات وقاعدة البيانات؛ لا تعمل ووردبريس هكذا! لحسن الحظ، هنالك أداة "استيراد" (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.
  6. عبد اللطيف ايمش
    مزيد من المعلومات حول "إعادة توجيه المخرجات مع here scripts لدى كتابة سكربات الصدفة (Shell Scripts)"
    سنشرع في بناء تطبيق مفيد بدءًا من هذا الدرس، سيُنتِج هذا التطبيق مستند 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.
  7. عبد اللطيف ايمش
    مزيد من المعلومات حول "تعرف على الإصدار الجديد PHP7 من PHP"
    حمل عام 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.
  8. عبد اللطيف ايمش
    مزيد من المعلومات حول "كيف تدير المراجعات (Revisions) في ووردبريس"
    تحفظ ووردبريس نسخًا من منشوراتك، فلا حاجة أن تفعل ذلك يدويًا! أُضيفت ميزة المراجعات منذ إصدار ووردبريس 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.
  9. عبد اللطيف ايمش
    مزيد من المعلومات حول "تعديل سكربتات الصدفة (Shell Scripts) الموجودة على حاسوبك"
    قبل أن تبدأ في كتابة سكربتات جديدة، عليّ أن أشير إلى أنَّك تملك بعض السكربتات الموجودة مسبقًا، وضِعَت هذه السكربتات في مجلد المنزل الخاص بك عندما أُنشِئ حسابك، وتُستعمل لضبط سلوك جلسات سطر الأوامر في حاسوبك؛ تستطيع تعديل هذه السكربتات لتغيير بعض الأمور. سنلقِي نظرةً على سكربتَين من هذه السكربتات في هذا الدرس لكي نتعلم بعض المفاهيم الجديدة والمهمة عن الصَدَفة. يُبقي النظام على مجموعة من المعلومات حول جلستك تدعى "البيئة" (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.
  10. عبد اللطيف ايمش
    مزيد من المعلومات حول "تخصيص لوحة تحكم ووردبريس لملائمة العملاء المبتدئين"
    إذا كنتَ تعد موقعًا ليستخدمه أشخاصٌ غير متخصصين في التقنية، فسيساعد تخصيص لوحة تحكم ووردبريس في تسهيل إدارتهم لموقعهم ولتعاملهم مع المحتوى. أغلبية المواقع التي أُنشئها تكون لعملاء ليسوا معتادين على التعامل مع ووردبريس وليس لديهم الوقت الكافي لتعلمه كي يديروا موقعهم، لذلك أجنح إلى تخصيص لوحة التحكم لتسهيل عملهم. وعادةً أضيف علامتي التجارية إلى لوحة التحكم كي أذكرهم مَن الذي طوّر الموقع لهم. التعديلات والتخصيصات التي أجريها تختلف بناءً على احتياجات كل عميل، لكنها تتضمن عادةً واحدًا أو أكثر من ما يلي: إضافة علامتي التجارية إلى صفحة تسجيل الدخول بوضع الشعار الخاص بي. إضافة علامتي التجارية إلى صفحات لوحة التحكم، بدءًا من أشياءٍ بسيطة مثل تغيير نص الترويسة (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.
  11. عبد اللطيف ايمش
    مزيد من المعلومات حول "خمسة أشياء عليك معرفتها عن HTML5"
    هذه السلسلة عبارة عن ترجمة لكتاب 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
  12. عبد اللطيف ايمش
    مزيد من المعلومات حول "استخدام التصنيفات والوسوم بفعالية في ووردبريس"
    التصنيفات (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.
  13. عبد اللطيف ايمش
    مزيد من المعلومات حول "تخصيص (أو إزالة) شريط أدوات الإدارة في ووردبريس"
    شريط أدوات الإدارة في ووردبريس هو ذاك الشريط الرفيع الأسود التي يظهر في أعلى الصفحة في موقعك، ويحتوي على قوائم وروابط تُشير عادةً إلى صفحاتٍ معيّنة في لوحة التحكم مثل تعديل المنشورات، وصفحة حساب المستخدم، وتخصيص القوالب والمزيد. بغض النظر عن الميزات المفيدة لشريط الأدوات، لكن قد يصبح مزعجًا وخصيصًا عندما لا تريد منح جميع المستخدمين وصولًا إلى لوحة التحكم، أو لأنك لا تحب وجود مستطيل أسود أثناء تصفحك لموقعك. لكن شريط الأدوات هو جزءٌ مهم لمدير ووردبريس ويمكن أن يكون مفيدًا جدًا بعد تخصيصه بشكلٍ ملائم لكي يوفر وصولًا سريعًا إلى أقسام الموقع وإلى معلومات محددة. سأريك كيف تُدير شريط أدوات ووردبريس، عبر إزالته لمستخدمين معينين، أو إضافة روابط وقوائم جديدة، أو تخصيص مظهره. إزالة شريط أدوات الإدارة قد تود في بعض الأحيان أن تُزيل شريط الأدوات من واجهة موقعك، إذ تستطيع إخفاءه لجميع المستخدمين أو لمستخدمين أولي دورٍ (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.
  14. عبد اللطيف ايمش
    مزيد من المعلومات حول "مدخل إلى كتابة سكربتات الصدفة Shell Scripts"
    تتوفر آلاف الأوامر لمستخدمي سطر أوامر لينُكس، لكن كيف تستطيع تذكرها جميعًا؟ الجواب هو أنَّك لا تحتاج إلى ذلك؛ فالقوة الحقيقية للحاسوب تظهر عندما يقوم بالعمل عوضًا عنك، وذلك باستخدام سكربتات الصدفة (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.
  15. عبد اللطيف ايمش
    مزيد من المعلومات حول "التجريد (Abstraction) والواجهات (Interfaces) والسمات (Traits) في PHP"
    التجريد – Abstraction نعلم أنَّ الصنف المُشتَق يأخذ خاصياته من الصنف الأب لكن الصنف المُشتَق مستقل تمامًا عن الصنف الأب؛ وقد يكون في بعض الأحيان من الجيد أن نرسم خطوطًا عريضة لآلية سلوك الصنف الابن، وهذه هي مهمة الأصناف والدوال المجردة. إذ أنَّ الصنف المجرد يحتوي على دوال غير مكتملة (أي مجردة) التي يجب أن يملأها الابن لكي يكون صنفًا وعدا ذلك سيكون صنفًا مجردًا أيضًا. بكلامٍ آخر، الصنف المُجرَّد (Abstract Class) هو صنف يحتوي على أسماء دوال دون كتابة الشيفرات المسؤولة عن عملها وتسمى تلك الدوال بالدوال المجردة، وقد يحتوي أيضًا على دوال كاملة اعتيادية تؤدي وظيفتها تمامًا. انظر إلى المثال الآتي لمزيدٍ من الإيضاح: <?php // تعريف صنف مجرد abstract class AbsClass { function __construct() { echo "this is an abstract class <br>"; } // دالة مجردة abstract public function abs_function(); function full_function() { echo "this is not an abstract function <br>"; } } class SubClass extends AbsClass { function __construct() { echo "this is child class <br>"; parent::full_function(); } // تعريف الدالة المجردة public function abs_function() { echo "this is completed abstract function <br>"; } } $obj = new SubClass(); $obj->abs_function(); ?> نستعمل الأصناف المجردة عندما يلزمنا إنشاء طريقة محددة للتعامل مع عدِّة أصناف مُشتقَّة، التي قد تتشارك ببعض الوظائف. ملاحظة: لا يمكن إنشاء كائن من صنف مجرد، حيث لا يمكن إلا اشتقاق تلك الأصناف. يستعمل الصنف المجرد لتقييد عمل الصنف الابن. الواجهات interfaces من بين الحالات التي نستعمل فيها الواجهات (interfaces) هي عندما نريد تطبيق التعددية الشكلية أي أن تكون طريقة تعاملنا متشابهة مع عدِّة أصناف. الواجهة هي مجموعة من الدوال المجردة أي أنك تعرف اسم الدالة مع المعاملات التي تقبلها لكن دون تحديد طريقة عمل الدالة، ويمكن للصنف أن يستعمل أكثر من واجهة، لكن يجب أن يعيد تعريف كل الدوال الموجودة في تلك الواجهة، انظر إلى المثال الآتي لأخذ فكرة عن الواجهات: <?php // تعريف واجهة interface MyInterface { // abstract functions // all must be public public function display(); public function another($argument); } // واجهة أخرى interface AnotherInterface { public function complete_it(); public function one_more(); } class Parent { function parent_fun() { echo "parent function"; } } // صنف يشتق صنفًا آخر ويستعمل واجهة class Demo extends Parent implements MyInterface, AnotherInterface { public function display() { echo "display complete"; } public function another($argument) { #code } public function complete_it() { #code } public function one_more() { #code } } ?> نستعمل الواجهات عندما نريد إنشاء طريقة موحدة للتعامل مع عدِّة أصناف، فمثلًا، نُنشِئ واجهة اسمها Database فيها دوال مجردة مثل select و insert وغيرها، ثم نستعمل تلك الواجهة في صنف MySQL وفي صنف SQLite، ونعيد تعريف الدوال الموجودة في الواجهة بما يلائم طريقة عمل كل نوع من أنواع قواعد البيانات. وبهذه الطريقة نستطيع أن نستعمل قواعد بيانات MySQL أو SQLite بنفس الآلية تمامًا. ملاحظة: يجب أن تكون جميع الدوال داخل الواجهة عامةً، يمكن أن يرث صنفٌ ما صنفًا آخر ويستعمل واجهة بنفس الوقت، لكن يجب أن يكون تعريف الاشتقاق قبل الواجهات. السمات Traits قدم الإصدار 5.4.0 من PHP ميزة السّمات Traits، وهي طريقة تسمح بإعادة استعمال الشيفرات في اللغات التي لا تسمح بالوراثة المتعددة، وهي تقلل من المحدوديات الناتجة عن عدم السماح بالوراثة المتعددة عن طريق إتاحة استعمال مجموعة من الدوال في عدة أصناف. أي لو كانت عندك مجموعة من الدوال العامة، وترغب في مشاركتها بين أكثر من صنف، فضعها في Trait ثم استعملها (use) في تلك الأصناف. يُعرف Trait عبر ذكر الكلمة المحجوزة trait متبوعةً باسمه، ثم تُعرَّف الدوال داخله. وتُستعمل الكلمة use عند تعريف صنف يستعمل Trait معين كما في المثال الآتي: <?php trait HelloWorld { public function sayHello() { echo 'Hello World!'; } } class World { use HelloWorld; } $obj = new World(); $obj->sayHello(); // ستُطبع عبارة Hello World! ?> يمكن إعادة تعريف الدوال داخل الأصناف التي تستعمل Trait معيّن، كما في المثال الآتي: <?php trait HelloWorld { public function sayHello() { echo 'Hello World!'; } } class World { use HelloWorld; } class NewWorld { use HelloWorld; public function sayHello() { echo 'Hello Universe!'; } } $obj1 = new World(); $obj1->sayHello(); // ستُطبع عبارة Hello World! $obj2 = new NewWorld(); $obj2->sayHello(); // ستُطبع عبارة Hello Universe! ?> يمكن استعمال أكثر من Trait في نفس الصنف عبر ذكر أسمائهم في عبارة use مفصولًا بينهم بفاصلة، لاحظ أنه إذا عُرِّفَت دالتين بنفس الاسم في أكثر من Trait، ثم استعملناها في صنف، فسيحدث تضارب وتظهر رسالة خطأ fetal error، ويمكنك حل مشكلة التضارب في الأسماء عبر استعمال المعامل insteadof أو عبر as كما في المثال الآتي: <?php trait A { public function smallTalk() { echo 'a'; } public function bigTalk() { echo 'A'; } } trait B { public function smallTalk() { echo 'b'; } public function bigTalk() { echo 'B'; } } class Talker { // لدينا في A و B دالتين اسمهما bigTalk و smallTalk // ما يلي سيجعل الصنف يستعمل الدالة smallTalk من B عوضًا عن مثيلتها في A // و bigTalk من A عوضًا عن B use A, B { B::smallTalk insteadof A; A::bigTalk insteadof B; } } class Aliased_Talker { use A, B { B::smallTalk insteadof A; A::bigTalk insteadof B; // لاحظ كيف استعملنا as لتغير اسم الدالة في الصنف B::bigTalk as talk; } } ?> مصادر مقالة Abstraction and Interface in PHP لصاحبها Harish Kumar فصل Objects في كتاب Practical PHP Programming فصل البرمجة غرضية التوجه في كتاب تعلم البرمجة بلغة PHP صفحات Object Interfaces و Traits في دليل PHP وغيرها.
  16. عبد اللطيف ايمش
    مزيد من المعلومات حول "نقل ووردبريس من بيئة التطوير المحلية إلى خادوم إنتاجي بسهولة وسرعة"
    ستوفِّر قدرًا كبيرًا من الوقت عندما تطوِّر مواقع ووردبريس على خادوم محلي؛ فالتطوير على خادوم محلي له عدِّة مزايا أهمها أنه أكثر أمانًا وأسرع من لو أنَّك سترفع ملفاتك إلى الخادوم البعيد بشكل مستمر. المشكلة الوحيدة هي أنَّ نقل موقع ووردبريس إلى خادوم إنتاجي سيُسبِّب لك الصداع، فلا يحب أحدٌ أن يعبث مع جداول قاعدة البيانات. لحسن الحظ، عملية النقل أسهل مما تتصور ولن تأخذ من وقتك إلا القليل إن اتبعت الخطوات التي سنووردها في هذا الدرس. سأريك في هذا الدرس كيف تستعمل إضافة "Duplicator" لنسخ موقع ووردبريس يعمل على خادوم محلي إلى استضافة خارجية بسرعة وسهولة. هنالك طرقٌ مختلفة لنقل مواقع ووردبريس، لكن أسهلها هو استخدام إضافة Duplicator؛ وهذه الإضافة مشهورة جدًا في مستودع إضافات ووردبريس، بتقييم 4.9 من 5 وبأكثر من 700‎ 000 تنزيل. سأشرح -وسأريك- في الخطوات الآتية كيفية نقل ووردبريس من الخادوم المحلي عبر Duplicator، لكن قد تختلف بعض الخطوات اعتمادًا على الخادوم الإنتاجي الذي ستنقل إليه الموقع. ستحتاج إلى عميل FTP مع بيانات الدخول لخادومك الإنتاجي لكي تتبع الخطوات التي سنشرحها في هذا الدرس. من الجدير بالذكر أنَّك لا تحتاج إلى تثبيت ووردبريس على الخادوم الإنتاجي قبل اتباع هذه الخطوات، إذ سينسخ Duplicator كل ملفات ووردبريس اللازمة تلقائيًا. الخطوة الأولى: تحزيم موقعك باستخدام Duplicator نزِّل وثبِّت Duplicator على موقعك المحلي. هذه الإضافة مجانية ومتاحة في مستودع إضافات ووردبريس، لذا تستطيع أن تبحث عنها في صفحة الإضافات. بعد تثبيت وتفعيل الإضافة، اضغط على "Duplicator" في شريط أدوات لوحة التحكم، وستظهر شاشة "Duplicator Packages". ولأننا ثبتنا Duplicator منذ قليل فلن تكون هنالك أيّة حزم. حسنًا، ما هي الحزمة؟ تحتوي الحزمة على أرشيف لموقعك (الصيغة الافتراضية هي ZIP) وملف تثبيت مهمته أتمتة عملية ضبط الموقع المؤرشف على الخادوم الجديد. اضغط على Create New لإنشاء حزمة. ستسألك الصفحة التالية عن اسم الحزمة وتسمح لك بإضافة ملاحظات. الاسم الذي تمنحه لموقعك ليس ذا أهمية كبيرة، لكن عليك أن تعطيه اسمًا قابلًا للتذكر إن كنت تنوي أن تُنشِئ عدِّة حزم. أضف ملاحظاتك إن شئت. هنالك إعدادات اختيارية متعلقة بالأرشيف والمُثبِّت، لكنك تستطيع تجاهلها الآن. تسمح لك إعدادات الأرشيف بترشيح (filter) قاعدة البيانات الخاصة بك، بينما تسمح لك خيارات المُثبِّت بملء خيارات التثبيت التي كانت ستظهر لك عند تثبيت الحزمة المؤرشفة، مما يوفر عليك بعض الوقت في المستقبل. اضغط على Next للمتابعة. سيتفحَّص Duplicator نظامك ليتأكد أنَّ عملية بناء الحزمة ستتم بسلاسة دون مشاكل. يمكن أن تُساعد هذه الخطوة في تحديد أيّة مشاكل محتملة الوقوع؛ واجتياز هذا الخطوة يعني أنَّه ليس عليك فعل أيّ شيء لبناء الحزم، بينما يعني ظهور "تحذيرات" (Warn) أنَّك ستواجه مشاكل أثناء عملية بناء وتثبيت الحزمة. لم يكشف الفحص الذي أجراه Duplicator على الموقع الذي نحاول نقله في مثالنا عن أيّة مشاكل، سوى أنَّ المساحة التخزينية لملفات الصور كبيرة، لكنني سأتجاهل ذلك لأنه من غير المحتمل أن تُسبِّب الصور أيّة مشاكل في الخطوات المقبلة. اضغط الآن على Build لإنشاء الحزمة، وعندها ستبدأ الإضافة بأخذ نسخة احتياطية من موقعك. وكما ذكرتُ سابقًا، ستُنتِج إضافة Duplicator ملفين: أرشيف لموقعك (كملف ZIP مضغوط) وملف تثبيت (بصيغة PHP). حمّل كلا الملفين إلى سطح المكتب عندك. الخطوة الثانية: نسخ المثبت والأرشيف إلى الخادوم الإنتاجي علينا الآن نسخ ملفَي الأرشيف والتثبيت اللذان أنشأتهما إضافة Duplicator إلى الخادوم الإنتاجي لكي نستطيع البدء بعملية التثبيت. سأستخدم هنا برنامج Filezilla لنقلهما عبر FTP. عليك تسجيل الدخول إلى خادومك عبر FTP، ثم التنقل إلى مجلد public_html (أو أيًّا كان اسم المجلد الجذر لموقعك) ونسخ ملفَي الأرشيف والمُثبِّت من سطح مكتبك إلى ذاك المجلد؛ ربما ستأخذ هذه العملية بعضًا من الوقت، خصوصًا إذا كان ملف الأرشيف كبيرًا جدًا. الخطوة الثالثة: تثبيت الموقع على خادومك الإنتاجي الخطوة التالية هي تثبيت الموقع على الخادوم الإنتاجي، وعليك الوصول إلى ملف التثبيت الذي نسخته إلى خادومك بإضافة ‎/installer.php إلى اسم النطاق الخاص بك. مثلًا http://example.com/installer.php. ستظهر صفحة المُثبِّت أمامك طالبةً منك إدخال تفاصيل الدخول لقاعدة بيانات MySQL. إذا كنتَ ستستبدل موقع ووردبريس موجود مسبقًا (أي أنَّك تريد تحديث نسختك الحالية من الموقع) فعليك إدخال تفاصيل قاعدة البيانات الموجودة مسبقًا. أما إذا كنتَ تُنشِئ موقعًا جديدًا، فاضغط على Create New وأدخِل تفاصيل قاعدة البيانات الفارغة. لاحظ أنَّ بعض شركات الاستضافة لا تسمح باستخدام خيار إنشاء قاعدة البيانات، وهذا يعني أنَّ عليك إنشاء قاعدة البيانات يدويًا. هذه هي خطوات إنشاء قاعدة بيانات في لوحة تحكم cPanel: افتح MySQL Database أنشِئ قاعدة بيانات بالاسم الذي يحلو لك أنشِئ مستخدمًا جديدًا أضف المستخدم الجديد إلى قاعدة البيانات التي أنشَأتها امنح مستخدمك جميع امتيازات الوصول إلى قاعدة البيانات ثم اضغط على Make Changes املأ تفاصيل الدخول إلى قاعدة البيانات في صفحة التثبيت (لإضافة Duplicator) ثم اضغط على زر Test Connection لتتأكد أنَّ المُثبِّت يملك وصولًا إلى قاعدة البيانات الخاصة بك تأكد أنَّك ستحصل على رسالة Success لاختبارَي Server Connected (أي تم العثور على الخادوم) و Database Found (أي تم العثور على قاعدة البيانات) قبل أن تنتقل إلى الخطوة الآتية. وبهذا ستضمن عدم مواجهة مشاكل أثناء عملية التثبيت. اضغط على Close، ثم ضع إشارة "صح" على بند I have read all warnings and notices في أسفل الصفحة ثم اضغط على Run Deployment. سيبدأ المُثبِّت الآن بتثبيت موقعك على الخادوم الإنتاجي، لكن قد تستغرق هذه الخطوة بعض الوقت إن كان موقعك كبيرًا. سيسألك Duplicator أثناء التثبيت أن تتأكد من تفاصيل موقعك القديمة… اضغط على Run Update بعد أن تتأكد منها. الخطوات الأخيرة سيطلب Duplicator منك إكمال أربع خطوات قصيرة لكنها مهمة: Install Report (تقرير التثبيت): هذا تقريرٌ عن تفاصيل الأخطاء التي قد واجهت عملية التثبيت (أرجو أن لا تكون هنالك أيّة أخطاء!) وعدد الجداول والسجلات التي أنُشِئت (أو حُدِّثَت) في قاعدة البيانات كي تتأكد أنَّ إضافة Duplicator قد نسخت كل معلومات قاعدة البيانات التي تريدها. Save Permalinks (حفظ إعدادات الروابط الدائمة): اضغط على Save Permalinks لكي تؤخذ إلى موقعك الجديد حيث تستطيع ضبط إعدادات الروابط الدائمة. Test Site (اختبار الموقع): اضغط على Test Site وستُظهر لك واجهة الموقع على الخادوم الإنتاجي لكي تتحقق من أنَّ كل شيءٍ يعمل على ما يرام. File Cleanup (حذف ملفات التثبيت): هذه الخطوة مهمة جدًا وغرضها هو حذف ملف التثبيت وأيّة ملفات أخرى مرتبطة فيه التي أنشِئت أثناء عملية التثبيت وذلك لضروراتٍ أمنية. اضغط على File Cleanup لحذف تلك الملفات تلقائيًا. اختبر موقعك الجديد على الخادوم الإنتاجي هذا كل ما في الأمر، يجب أن تحصل الآن على نسخة مماثلة لموقعك الذي كنت تطوره على الخادوم المحلي. هل استخدمتَ Duplicator لنقل المواقع من قبل؟ إن لم تكن تستخدمه، فما هي أفضل طريقة لنقل المواقع برأيك؟ شاركنا تجربتك في التعليقات. ترجمة -وبتصرّف- للمقال The Quick and Easy Guide to Migrating a Local WordPress Installation to a Live Site لصاحبته Raelene Morey.
  17. عبد اللطيف ايمش
    مزيد من المعلومات حول "البرمجة كائنية التوجه (Object Oriented Programming) في PHP"
    كان الغرض من البرمجة الكائنية (Object oriented programing اختصارًا OOP) هو السماح للمبرمجين بتسهيل تقسيم البرامج حسب وظيفتها؛ فالمبرمجون يُنشؤون "كائنات" ويضبطون بعض الخاصيات ثم يطلبون من تلك الكائنات أن تقوم بأشياءٍ معيّنة. مثلًا لدينا "الأكواب" عبارة عن كائنات، وتلك الأكواب لها خاصيات معيّنة مثل المادة المصنوعة منها (زجاج، أو بلاستيك، أو معدن) والسعة القصوى لها، كما يمكن إجراء عمليات عليها مثل ملء كوب. لكن عمومًا تنطوي كل تلك الأنواع تحت لواء "الأكواب" وإن اختلفت خاصياتها. أنُشِئت الأصناف (classes) في PHP لغرض التجريد (abstraction) والتغليف (encapsulation). والصنف هو مجموعة من المتغيرات والدوال التي تؤدي وظيفة مشابهة؛ وتساعد الأصناف في تجنب المشاكل الأمنية وذلك بفصل الواجهة (interface) عن طريقة التطبيق (implementation)، وتضيف الأصناف قيودًا إلى الوصول إلى المتغيرات والدوال. يُعرَّف الصنف بكتابة الكلمة المحجوزة class يليها اسم الصنف، ومن المستحسن اتباع طرق الكتابة التقليدية في أسماء الأصناف، حيث يبدأ اسم الصنف بحرفٍ كبير؛ هذا مثالٌ عن تعريف صنف بسيط: <?php class SimpleClass { // التعليمات البرمجية } ?> الشيفرة الموجودة ضمن الصنف لا تنفذ مباشرةً، إذ علينا أولًا أن قومة بإنشاء بإشاء كائن (object) من ذاك الصنف، الكائن هو نسخة من الصنف تكون جميع متغيرات ودوال ذاك الصنف جزءًا من خاصياتها (properties). يمكن إنشاء كائن من صنف كالآتي: object_name = new ClassName(); الخاصيات والدوال المتغيرات التي تكون عضوًا بالصنف تسمى خاصيات (properties)، وتُعرَّف عبر استخدام إحدى محددات الوصول public (عام) أو protected (محمي) أو private (خاص)، ويأتي بعدها التعريف الاعتيادي للمتغيرات، ويمكن أن تُسنَد القيم إليها مباشرةً، لكن يجب أن تكون تلك القيم ثابتة، أي لا تحتوي تعابير رياضية أو قيم معادة من دوال. أما الدوال الأعضاء في الأصناف، فتسمى توابع methods، وتُعرَّف كغيرها من الدوال، لكن مع الانتباه إلى ضرورة تحديد مجال الدالة (عامة أو محمية أو خاصة) كما في المثال الآتي: <?php class SimpleClass { // تعريف متغير أو خاصية public $var = 'a default value'; // تعريف دالة public function displayVar() { echo $this->var; } } ?> المتغير ‎$this متوفر داخل دوال الصنف تلقائيًا (أي ليس عليك إنشاؤه)، وهو يشير إلى الكائن الذي قام بإنشاء نسخة من الصنف، ويُستعمل للوصول إلى الخاصيات أو الدوال الموجودة في الصنف. لاحظ عدم وجود رمز الدولار ($) قبل اسم المتغير عند الوصول إليه عبر ‎$this. مثالٌ عن ما سبق: <?php class ClassName { // تعريف متغير public public $class_variable; // الدالة البانية function __construct() { $this->class_variable = 60 * 60; echo "this is the constructor <br>"; } // إعادة متغير في الصنف function get_global() { return $this->class_variable; } // تعديل متغير في الصنف function set_global($value) { $this->class_variable = $value; } // إظهار قيمة متغير في الصنف public function reset_display() { $this->private_function(); echo $this->get_global()." <br>"; } // دالة خاصة private function private_function() { $this->class_variable = 60 * 60; } } $object_name = new ClassName(); echo $object_name->get_global()."<br>"; $object_name->set_global(231); echo $object_name->get_global()."<br>"; $object_name->reset_display(); ?> لاحظ المفاهيم الآتية في المثال السابق التي شرحنا بعضها أعلاه: المتغير الذي يكون متاحًا للوصول في كل الصنف (‎$class_variable) يُعرَّف بالكلمة المحجوزة public؛ أما المتغيرات المحلية المُعرَّفة داخل دالة لا يمكن الوصول إليها إلا من تلك الدالة. يمكن الوصول إلى متغيرات أو دوال الصنف باستخدام ‎$this->variable_name;‎ و ‎$this->function_name();‎ على التوالي وبالترتيب. إذ أنَّ ‎$this يُشير إلى الصنف نفسه. الدالة البانية (constructor) هي دالة ذات معنى خاص في الأصناف؛ حيث تُشغَّل هذه الدالة عندما نُنشِئ كائنًا من ذاك الصنف، ويمكن أيضًا إرسال وسائط إلى الدالة البانية. سنشرح الدالة البانية والهادمة لاحقًا. ناتج السكربت السابق: it is constructor 3600 231 3600 ملاحظة: لا يُنصح بتعديل قيم خاصيات الفئات يدويًا، وإنما استعمل دوالًا خاصةً لهذا الغرض، فمثلًا لو كان عندك صنفٌ وظيفته حساب كمية الماء اللازمة لمدينة ما، ولديك خاصية اسمها population تُمثِّل عدد سكان المدينة، فلا تسمح بالوصول إليها مباشرةً، وإنما اكتب دالةً اسمها setPopulation مثلًا، واجعلها تُعدِّل قيمة عدد السكان وكل ما يتعلق بها من الحسابات تلقائيًا: $obj->setPopulation(200000); الوراثة نحاول دومًا عندما نبرمج ألّا نعيد كتابة الشيفرة مرارًا وتكرارًا، وأن نفصل بين تطبيق الشيفرة والواجهة (interface) لأسباب تتعلق بالحماية. الخيار الجديد المتاح أمامنا الآن هو استعمال الوراثة للقيام بالأمور السابقة بكفاءة. الوراثة في البرمجة كالوراثة في حياتنا، إذ يرث والدك بعض الخاصيات من جدك ويُعدِّلها أيضًا، وأنت أيضًا ترث بعض الخاصيات من والدك وتعدلها وتضيف غيرها. تسمى هذه العملية في البرمجة بالمصطلح inheritance. يمكن لأي صنف أن يوسِّع أو يشتق (extend) أصنافًا أخرى ويمكنه أن يصل إلى المتغيرات والدوال العامة والمحمية فيها فقط (أي لا يستطيع أن يصل إلى الدوال الخاصة private). <?php /** * الوراثة في PHP */ class Grandfather { // متغير عام public $global_variable; // الدالة البانية للصنف grandfather function __construct() { $this->global_variable = 56; echo "I am grandfather <br>"; } function default_function() { echo "this is default function in grandfather <br>"; } private function private_function() { echo "this is private function in grandfather <br>"; } protected function protected_function() { echo "this is protected function in grandfather <br>"; } public function public_function() { echo "this is public function in grandfather <br>"; } } /** * هذا صنف فرعي مشتق من الصنف Grandfather * وسيرث كل خاصياته عدا الخاصة (private) منها */ class Father extends Grandfather { // متغير عام public $father_var; function __construct() { // السطر الآتي مساوٌ للسطر => parent::__construct(); Grandfather::__construct(); $this->father_var = 256; echo "I am father <br>"; } public function display_all() { $this->default_function(); $this->protected_function(); $this->public_function(); echo "I am father's display_all <br>"; parent::public_function(); } } /** * هذا الصنف الابن يرث من الصنف الأب * ويرث أيضًا (بشكلٍ غير مباشر) من الصنف الجد */ class Child extends Father { // الدالة البانية في الصنف الابن function __construct() { Grandfather::__construct(); echo "I am child <br>"; } // يُعدِّل الابن في دالة موجودة في الأب // تسمى هذه العملية «إعادة تعريف الدوال» function display_all() { echo "function from father<br>"; // استدعاء دالة من الصنف الأب parent::display_all(); echo "new added in child<br>"; } } $obj = new Father(); $obj->display_all(); echo "<br><br><br>Child object call<br><br>"; $obj2 = new Child(); $obj2->display_all(); ?> الناتج: I am grandfather I am father this is default function in grandfather this is protected function in grandfather this is public function in grandfather I am father's display_all this is public function in grandfather Child object call I am grandfather I am child function from father this is default function in grandfather this is protected function in grandfather this is public function in grandfather I am father's display_all this is public function in grandfather new added in child يعطي المثال السابق صورةً كاملةً عن الوراثة، لنحاول فهمه: الصنف Child يرِث من الصنف Father، الذي بدوره يرث الصنف Grandfather؛ وهذا يُسمى الوراثة متعددة المستويات. الصنف الفرعي (subclass أي الصنف الذي يقوم بالوراثة) يمكنه الوصول إلى جميع الخاصيات غير الخاصة (private) للصنف الموروث (يسمى أيضًا superclass). يمكن للصنف الفرعي أن يستدعي دوال الصنف الموروث عبر استعمال الصيغة الآتية parent::function_name()‎ (يمكن استعمالها لمستوى وراثة وحيد فقط، أي يمكن للصنف Child أن يستعملها لاستدعاء دوال الصنف Father، ويمكن للصنف Father أن يستعملها للصنف Grandfather؛ لكن لا يمكن أن يستعملها الصنف Child لاستدعاء دوال الصنف Grandfather.) أو الصيغة الآتية SuperClass_name:function_name()‎ التي يمكن استعمالها لاستدعاء دوال الصنف Grandfather من الصنف Child. يمكن أن يُعدِّل الصنف الفرعي في دوال الصنف الأب، وذلك يُعرَف بإعادة التعريف (overriding). لا تدعم لغة PHP الوراثة المتعددة؛ أي لا يمكن للصنف أن يرث أكثر من صنف واحد. محددات الوصول لقد تطرقنا سابقًا إلى موضوع محددات الوصول بشكل مبسط، حان الوقت الآن لشرحها بالتفصيل. هنالك كلماتٌ محجوزةٌ تسمى محددات الوصول توضع قبل تعريف المتغيرات أو الدوال الأعضاء في الصنف، وتعيّن مَن الذي يستطيع الوصول إلى ذاك المتغير أو الدالة، وهي: public (عام): ذاك المتغير أو الدالة يمكن الوصول إليه من داخل الصنف أو من خارجه private (خاص): لا يمكن الوصول إلى المتغير أو الدالة إلا من داخل الصنف نفسه protected (محمي): يسمح بالوصول إلى المتغير أو الدالة من الصنف نفسه والصنف المُشتَق منه فقط final (نهائي): هذه الدالة لا يمكن إسناد قيمة أخرى إليه أو تعريفها في الأصناف المُشتقَة (لا يمكن استخدام final مع الخصائص/المُتغيّرات). نستعمل عادةً المُحدِّد public للخاصيات أو الدوال التي تريد الوصول إليها من خارج الصنف، أما private فتستعمل للأجزاء الداخلية التي لا يلزم الوصول إليها من خارج الصنف، أما protected فهي للخاصيات التي تستعمل في بنية الصنف (كما في private) لكن من المقبول توريثها إلى أصنافٍ أخرى كي يعدلوها بما يلائم. فمثلًا، لو كنا نكتب صنفًا للاتصال بقاعدة البيانات، فسيكون مقبض الاتصال (connection handle) لقاعدة البيانات مخزنًا في متغير خاص، لأنه يستعمل داخل الصنف فقط، ولا يجب أن يكون متوفرًا لمستخدم هذا الصنف؛ أما عنوان الشبكة لمضيف خادوم قواعد البيانات، فهو خاص بالصنف، ولا يجب على المستخدم تعديله، لكن من المقبول تعديله من صنفٍ يرث هذا الصنف. أما الطلبيات التي تُجرى على قاعدة البيانات، فيجب أن تكون عامة، كي يستطيع مستخدم الصنف الوصول إليها. الدالة البانية والدالة الهادمة ذكرنا الدالة البانية سابقًا ومررنا عليها سريعًا، وقلنا وقتها أنَّ الدالة البانية تُنفَّذ عند إنشاء كائن من الصنف، وهي مناسبة لعمليات تهيئة المتغيرات وإعطائها قيمةً ابتدائيةً. تحمل هذه الدالة اسم ‎__construct. يجدر بالذكر أنَّ الدالة البانية للصنف الأب لا تستدعى تلقائيًا عند إنشاء كائن للصنف الابن، ويجب استدعاؤها يدويًا عبر parent::__construct()‎ ضمن الدالة البانية للصنف الابن. لكن إن لم تُعرَّف دالة بانية للصنف الابن، فسيرث الدالة البانية للصنف الأب تلقائيًا. مثالٌ عليها سيوضح ما سبق: <?php class BaseClass { function __construct() { print "In BaseClass constructor\n"; } } class SubClass extends BaseClass { function __construct() { parent::__construct(); print "In SubClass constructor\n"; } } class OtherSubClass extends BaseClass { // سيرث هذا الصنف الدالة البانية للصنف الأب } // ستنفذ الدالة البانية للصنف BaseClass $obj = new BaseClass(); // ستنفذ الدالة البانية للصنف BaseClass // وستنفذ الدالة البانية للصنف SubClass $obj = new SubClass(); // ستنفذ الدالة البانية للصنف BaseClass $obj = new OtherSubClass(); ?> أما الدالة الهادمة، فهي الدالة التي تُنفَّذ عندما لا يعود الكائن موجودًا، وتُعرَّف -كما الدالة البانية- بذكر اسمها ‎__destruct، ولا تستدعى الدالة الهادمة للصنف الأب إن أُعيد تعريفها في الصنف الابن. <?php class MyDestructableClass { function __construct() { print "In constructor\n"; $this->name = "MyDestructableClass"; } function __destruct() { print "Destroying " . $this->name . "\n"; } } $obj = new MyDestructableClass(); // الناتج: In constructor echo "We will destroy \$obj \n"; unset($obj); // الناتج: Destroying MyDestructableClass echo '$obj Destroyed'; ?> معرفة نوع الكائنات لقد رأيت كيف أنَّ الوراثة هي أمرٌ مهمٌ في البرمجة الكائنية، ولكن قد تختلط عليك الكائنات، ولن تدري لأي صنفٍ تنتمي. يأتي الحل مع الكلمة المحجوزة instanceof التي يمكن استعمالها كأحد المعاملات، فستُعيد TRUE إن كان الكائن المذكور اسمه على يسارها تابعًا لصنفٍ ما أو لصنفٍ مشتقٍ من الصنف المذكور على يمينها. على سبيل المثال: $obj = new SubClass(); if ($obj instanceof SubClass) { } if ($obj instanceof BaseClass) { } ناتج العبارتان الشرطيتان السابقتان هو TRUE لأن ‎$obj هو كائنٌ ينتمي إلى الصنف SubClass (أول عبارة شرطية)، وينتمي إلى صنفٍ مشتقٍ من BaseClass (العبارة الشرطية الثانية). أما لو أردت أن تعلم إن كان الكائن ينتمي إلى صنفٍ مشتقٍ من الصنف المذكور، فاستعمل الدالة is_subclass_of()‎، الذي تقبل وسيطين، أولهما هو الكائن الذي سنختبره، والثاني هو اسم الصنف الأب. <?php class BaseClass {} class SubClass extends BaseClass {} $obj = new SubClass(); if ($obj instanceof SubClass) { echo 'instanceof is TRUE'; } if (is_subclass_of($obj, 'SubClass')) { echo 'is_subclass_of is TRUE'; } ?> ستجد أن instanceof في المثال السابق ستعطي TRUE، بينما ستعطي is_subclass_of()‎ القيمة FALSE، لأن ‎$obj ليس كائنًا لصنف مشتق من الصنف SubClass، وإنما هو من الصنف SubClass نفسه. تحديد الصنف في معاملات الدوال لنقل أنك تريد تمرير كائن من صنف معيّن إلى دالة، ولا تريد السماح بتمرير سلسلة نصية أو رقم لها بدلًا من الكائن ذي الصنف المحدد؛ تستطيع فعل ذلك بذكر اسم الصنف قبل المعامل أثناء تعريف الدالة، كما يلي: <?php class Numbers { public function print_random() { echo rand(, 10); } } class Chars {} function random (Numbers $num) { $num->print_random(); } $char = new Chars(); random($char); // fatal error: Argument 1 passed to random() must be an instance of Numbers ?> الدوال "السحرية" عندما تشاهد دالةً يبدأ اسمها بشرطتين سفليتين، فاعلم أنها دالة سحرية (Magic function)، وهي متوفرة من PHP، وتحجز PHP جميع أسماء الدوال التي تبدأ بشرطتين سفليتين على أنها دالة سحرية، لذا يُنصَح بتجنب استعمال هذا النمط من التسمية لتلافي حدوث تضارب في المستقبل مع الدوال السحرية التي قد تعرفها الإصدارات الحديثة من PHP. لقد رأينا سابقًا الدالتين البانية ‎__construct()‎ والهادمة ‎__destruct()‎، وسنتحدث هنا عن الدوال ‎__get()‎ و ‎__set()‎ و ‎__call()‎ و ‎__toString()‎. تُعرَّف الدالتان ‎__get()‎ و ‎__set()‎ داخل الأصناف، تستعمل الدالة ‎__get()‎ عندما تحاول قراءة متغير غير مُعرَّف من متغيرات الصنف، وتُستعمَل الدالة ‎__set()‎ عند محاولة إسناد قيمة لمتغير غير موجود، انظر إلى المثال الآتي: <?php class MagicClass { public $name = 'Magic'; private $age = 123; public function __get($var) { echo "getting: $var "; echo $this->$var; } public function __set($var, $value) { echo "setting: $var to $value"; $this->$var = $value; } } $obj = new MagicClass(); echo $obj->name; // الناتج: Magic $obj->age = 123; // أصبح بإمكاننا -باستعمال الدوال السحرية المُعرفة في الصنف- الوصول إلى متغير ذي وصولٍ خاص، لا يجدر بنا فعل ذلك عمومًا. echo $obj->age; // الناتج: getting: age 123 echo $obj->last_name; // ستحاول الدالة __get الحصول على قيمة الخاصية last_name، لكنها غير موجودة، وسيظهر خطأ من مرتبة Notice لإشارة إلى ذلك. ?> قد نستفيد من الدالتين ‎__get()‎ و ‎__set()‎ بإظهار رسالة خطأ عند محاولة الوصول إلى عناصر غير موجودة (أو لا يُمسَح لنا بالوصول إليها). أما دالة ‎__call()‎ فغرضها مشابه لغرض ‎__get()‎ إلا أنها تُستعمَل عند محاولة استدعاء دالة غير موجودة. ستستدعى الدالة السحرية ‎__toString()‎ في حال تمت محاولة طباعة الكائن كسلسلة نصية. هذه الدالة بسيطة جدًا وتعمل كما يلي: <?php class MagicClass { public function __toString() { return "I'm Magical! :-)"; } // ... } $obj = new MagicClass(); echo $obj; ?> مصادر مقالات Classes in PHP و Inheritance in PHP لصاحبها Harish Kumar.فص ل Objects في كتاب Practical PHP Programming. فصل البرمجة غرضية التوجه في كتاب تعلم البرمجة بلغة PHP. صفحات Introduction و The Basics و Constructors and Destructors و Visibility و Object Inheritance و Magic Methods و Type Hinting في دليل PHP وغيرها.
  18. عبد اللطيف ايمش
    مزيد من المعلومات حول "الدليل الشامل للروابط الدائمة (Permalinks) في ووردبريس"
    الروابط الدائمة (permalinks) ذات المظهر الجميل هي الخيار الافتراضي لعناوين URL في مواقع ووردبريس، لكن ما الذي يجعل تلك الروابط "جميلةً"؟ وإذا كنتَ حديث العهد بووردبريس، فربما تتساءل: ما هي الروابط الدائمة؟ الروابط الدائمة، أو permalinks، هي عناوين URL للصفحات (pages) وللمنشورات (posts) وللتصنيفات (categories) وللأرشيفات (archives) في موقعك، وهي لا تتغير أبدًا، لذا تُستعمَل كرابط دائم للوصول إلى المحتوى الذي تُقدِّمه. الروابط الدائمة ذات البنية الجيدة مفيدة في جذب المستخدمين إلى موقعك بتسهيل تنقل الزوار ومحركات البحث في موقعك وإشارتهم إلى المحتوى الذي تقدمه. سنشرح في هذا الدرس كيف تعمل الروابط الدائمة في ووردبريس، وكيف تستطيع إدارة الإعدادات في لوحة التحكم لتحسين SEO، وبعض الإعدادات المتقدمة للتأكد أنَّ الروابط الدائمة ستعمل عملًا سليمًا على خادومك. الروابط الدائمة في ووردبريس هنالك ثلاثة أنواع رئيسية من الروابط الدائمة المتوفرة: الروابط الدائمة "القبيحة" وهذا هو الخيار الافتراضي في ووردبريس وتأخذ شكل عنوان URL للموقع ويليه عبارة تحتوي على مُعرِّف المنشور (post ID)، على سبيل المثال: http://www.example.com/?p=138 هذه الصيغة غير مقروءة للبشر (أي أنَّها تحوي أرقامًا بدلًا من كلماتٍ)، ولهذا سُمِّيت "القبيحة". الروابط الدائمة "نصف الجميلة" تُعرَف أيضًا باسم "PATHINFO permalinks"، وهي نسخةٌ مطوَّرةٌ من الروابط الدائمة القبيحة، حيث تتضمن السلسلة النصية index.php بعد اسم النطاق متبوعةً بُمعرِّف يُحدِّد المنشور الهدف؛ على سبيل المثال: http://www.example.com/index.php/yyyy/mm/dd/post-name/ ‎ الروابط الدائمة "الجميلة" هي تلك الروابط شائعة الاستعمال في المواقع العصرية، والتي تألف رؤيتها في ووردبريس وغيرها؛ وفي هذه الحالة، سيُتبَع اسم النطاق بسلسلةٍ نصيّةٍ واضحة تُحدِّد منشورًا معيّنًا، مثلًا: http://www.example.com/2016/01/09/my-new-post تغيير تركيبة الروابط الدائمة اذهب إلى: Settings > Permalinks (إعدادات > روابط دائمة) في لوحة التحكم للوصول إلى خيارات الروابط الدائمة، يمكنك الاختيار من أحد أكثر تركيبات الروابط الدائمة شيوعًا أو يمكنك إدخال تركيبة مُخصَّصة في حقل Custom Structure (تركيبة مخصّصة). هنالك خياراتٌ ستة لتنتقي منها: افتراضي: هذه هي الروابط الدائمة "القبيحة" اليوم + عنوان المقالة: تستعمل هذه التركيبة الصيغة "اليوم/الشهر/السنة" متبوعةً بعنوان المقالة؛ يُقصَد بعنوان المقالة هنا "الاسم اللطيف" (slug) للمنشور الشهر + عنوان المقالة: كما في الخيار السابق، لكن دون ذكر اليوم رقمي: يستعمل هذا الخيار مُعرِّف المقالة (post ID) من السطر الموافق لها من جدول wp_posts في قاعدة البيانات تركيبة مخصصة: يسمح لك هذا الحقل بتعريف تركيبة مخصصة تستطيع أن تستعمل فيها كل الوسوم البنيوية في ووردبريس الخيار الأول هو الخيار الافتراضي الذي يكون مُفعَّلًا بعد تثبيت ووردبريس. إنشاء روابط دائمة مخصصة توفر ووردبريس عشرة وسوم بنيوية لتعريف تركيبة خاصة بك. ستمر عليك أول سبعة من تلك الوسوم كثيرًا: %postname%: الاسم اللطيف (slug) للمنشور %post_id%: المُعرِّف الفريد للمنشور %category%: التصنيف الرئيسي للمنشور %monthnum%: الشهر الذي نُشِرَ فيه المنشور %day%: اليوم (بصيغة رقمية) الذي نُشِرَ فيه المنشور %author%: قد تستفيد منه في المواقع الشبيهة بالمجلات، التي فيها أكثر من كاتب إذا أردتَ أن تكون دقيقًا للغاية فيما يتعلق بالوقت في روابطك الدائمة، فيمكنك استعمال الوسوم %hour% و %minute% و %second%؛ لكن يصعب التفكير بمثال عملي تكون فيه الخيارات الثلاثة السابقة مفيدة. أبقِ في ذهنك أنَّه عليك أثناء تشكيل تركيبة مخصصة لروابطك الدائمة تضمين الوسم %postname% أو %post_id% لكي تستطيع تعيين منشور مُحدَّد؛ لأن هذين الوسمين هما الوحيدان اللذان يضمنان توليد مُعرِّفات فريدة. مع كل ما سبق من معلومات، لو أردت مثلًا أن تكون روابطك الدائمة محتويةً على مُعرِّفات المنشورات (post IDs) وأسمائها، فيمكنك استعمال الصيغة الآتية: ‎/%post_id%/%postname%/‎. من الجدير بالذكر أنَّك تستطيع تغيير تركيبة روابط التصنيفات والوسوم في موقعك في نفس المكان في لوحة التحكم في القسم "اختياري". الروابط الدائمة الملائمة لمحركات البحث و SEO الروابط الدائمة وبنية الروابط هما أمران مهمان من وجهة نظر محركات البحث، وعلى الرغم من وجود كمٍ كبيرٍ من المعلومات حول هذا الأمر على مر السنين، إلا أن توجيهات Google حول بنية URL تبقى واضحةً ومباشرة: أبقها –أي الروابط– بسيطةً قدر الإمكان وأن تكون مفهومةً للبشر. يُعطى المستخدمون في نتائج بحث Google أربعة أنواع من المعلومات: العنوان، والوصف، والتاريخ، والرابط الدائم. تُعطي هذه التفاصيل للمستخدم مؤشرًا عمّا إذا كانت تحتوي الصفحة ما يبحثون عنه. فمثلًا، لو كانت لديك مقالة عن الماعز الجبلي وتركت إعدادات الرابط الدائم الافتراضية، فسيبدو URL كالآتي: http://www.example.com/?p=135 أما لو فعّلتَ إظهار اسم المنشور في الروابط الدائمة، فسيكون URL كالآتي: http://www.example.com/mountain-goats/‎ الذي هو أسهل للقراءة والفهم. وبهذا نجد أنَّ الروابط الدائمة القبيحة لها تأثيرٌ سلبيٌ على SEO وليست صديقةً للمستخدم. أشارت مقالةٌ حديثةٌ في Moz.com حول هذا الموضوع إلى بعض الأمور الأخرى في هذا الخصوص، لكن الأساسيات ليست صعبة الفهم والتطبيق: أبقِ الروابط مختصرةً قدر الإمكان (ربما أقل من 100 محرف) استخدم الكلمات المفتاحية في الروابط في حدود المنطق، ولا تحاول حشرها أزل الخاصيات الديناميكية (التي تتغير مع مرور الوقت) من الروابط استعمل الشرطات (-) فواصلًا بين الكلمات، واحذف أدوات الربط مثل "and" و "or" و "but" و "of" وغير ذلك اختيار البنية المثالية للروابط الدائمة لموقعك لقد شرحنا إلى حد الآن الخيارات الأساسية لكيفية التحكم بالروابط الدائمة، لكننا لم نستوعب ما هي البنية المثالية للروابط الدائمة لموقع ووردبريس بعد. الإجابة المختصرة: الأمر نسبيٌ، إذ لن يستفيد كل موقع من نفس البنية، لكن هنالك بعض الأمور العامة لتأخذها بعين الاعتبار. أولها هو ضرورة تضمين اسم المنشور في الروابط الدائمة، حيث سيستفيد منها المستخدمون ومحركات البحث خير الاستفادة، وهذا غالبًا كل ما تحتاج فعله. أما لو كان موقعك إخباريًا، فربما تود تضمين معلومات التاريخ في الروابط الدائمة، وإلا فليس من المنطقي وضعها. إذا أردت تضمين معلومات التاريخ للقارئ، فمن الأفضل أن تضمنها في البيانات الوصفية للمنشور، مما يجعل التعرف عليها أسهل. تضمين معلومات عن التصنيفات في الروابط الدائمة هو أمرٌ معقولٌ إذا كان موقعك مُقسّمًا إلى أقسامٍ معيّنة، أبقِ في بالك أنك إذا كنتَ تستعمل أكثر من تصنيف لمنشورٍ ما، فسيُعرَض أحدها فقط في الرابط الدائم، وتكون الأولوية للتصنيف الذي يأتي أولًا بالترتيب الهجائي؛ أما إذا أردت تحكمًا كاملًا حول هذا الموضوع، فربما عليك استعمال إضافة "WP Category Permalink". مثالٌ على هذا النوع من الروابط الدائمة هو الروابط الدائمة في أكاديمية حسوب. لطالما كنت تُضمِّن عنوان المنشور في الروابط الدائمة، فلن يكون هنالك تأثيرٌ كبيرٌ لاختيارك أحد الأمور السابق ذكرها. كانت هنالك مشكلة في النسخ التي سبقت نسخة 3.3 من ووردبريس، وهي مشاكل في الأداء عند استخدام عنوان المنشور في الروابط الدائمة، لكن قد حُلَّت المشكلة لحسن الحظ. وكما أشار Matt Cutts، الرئيس السابق لفريق مكافحة spam في Google، سيكون اختيارك لبنية الروابط الدائمة متعمدةً على تفضيلك الشخصي بعد أن تُلم بالمعلومات الأساسية حولها. تفعيل الروابط الدائمة الجميلة اعتمادًا على خصوصيات الاستضافة عندك، ربما تحتاج إلى تفعيل بعض الإعدادات على الخادوم لكي تعمل الروابط الدائمة عملًا صحيحًا. بأسلوبٍ مبسط: يجب أن يملك خادوم الويب عندك طريقةً ما لتحويل الروابط الدائمة إلى شيءٍ يستطيع تنفيذه؛ وهذا يختلف بناءً على نوع خادوم الويب الذي تستعمله. لاحظ أنَّ أغلبية موفري الاستضافة يهتمون بهذه التفاصيل ولا داع لخوضك فيها، لكن ربما تجد نفسك مضطرًا إلى ذلك بين الحين والآخر. سنشرح أشهر الطرق لإعداد الخواديم، لكن إن وجدت نفسك تمر بمأزقٍ ما، فانظر إلى صفحة Fixing Permalink Problems في دليل مطوري ووردبريس المسمى Codex. استعمال الروابط الدائمة في أباتشي عادةً ما يكون خادوم الويب المستعمل لأغلبية مواقع ووردبريس هو أباتشي (Apache)، إن كان هذا هو الحال عندك، فعليك أن تتأكد من وجود بعض المتطلبات الأولية، ومن صحة ضبطها. أولًا، يجب تثبيت وتفعيل واحدة mod_rewrite في أباتشي؛ ويلزمك في تفعيل خيار FollowSymLinks في ضبط المجلد الذي يحتوي ووردبريس، وأن يُسمَح بخيار FileInfo. يجب أن يكون هنالك ملف ‎.htaccess تستطيع ووردبريس استعماله، وإن لم يكن موجودًا فستحاول ووردبريس إنشاءه عندما تُفعِّل الروابط الدائمة "الجميلة" ويجب أن تملك ووردبريس امتيازات الكتابة عليه أيضًا. محاولة تعديل وإصلاح ملف ‎.htaccess هو أمرٌ متعبٌ وشاق، لذلك لا ننصحك بذلك إلا إن كانت لك خبرةٌ سابقةٌ عن هذا الموضوع. يمكنك العثور على معلومات تفصيلية حول كيفية تنصيب وإعداد خادوم ويب أباتشي في الدروس المتعلقة بأباتشي في أكاديمية حسوب. بفرض أنَّ ضبط ما سبق صحيح، فيجب أن تتمكن من إدارة خصائص الروابط الدائمة من لوحة تحكم ووردبريس. استخدام الروابط الدائمة في خواديم الويب الأخرى أباتشي ليس خادوم الويب الوحيد الذي شاع استعماله، هنالك بدلاءٌ عنه مثل Nginx و Lighttpd. يمكنك العثور على معلومات حول تنصيب وإعداد خادوم ويب Nginx. تغيير تركيبة الروابط الدائمة في موقع حي من الناحية المثالية، يجب أن تُقرِّر ما هي تركيبة الروابط الدائمة التي تُفضِّلها قبل إطلاقك للموقع، ثم لا تغيرها بعد ذلك. لكن ربما ستجري بعض التعديلات على الموقع في مرحلةٍ ما. أبقِ في بالك أنَّ هذه الخطوة لها وقعٌ كبيرٌ إن أجريتها على كامل الموقع، وأنت تخاطر باللعب بالنار عندما يصل الأمر إلى تقييمات SEO والروابط الخارجية التي تُشير إلى صفحات موقعك. عمل التغيرات في لوحة تحكم ووردبريس هو أمرٌ بسيطٌ، لكن عليك أنَّ تستعمل إعادة التوجيه (301) لكل الروابط القديمة للتأكد أنَّك لن تزعج المستخدمين ومحركات البحث على حدٍ سواء؛ ابدأ بجمع قائمة كاملة لكل الروابط السابقة، وما هي الروابط الجديدة التي يجب أن يُعيدوا التوجيه إليها. ربما تستعمل إضافة مثل Redirection أو SEO Redirection للتأكد من أنَّ الروابط القديمة ستُشير إلى المقالات بشكلٍ صحيح. الخلاصة تقرير ما هي بنية الروابط الدائمة هو من أول القرارات التي عليك أن تتخذها عند إنشاء موقع ووردبريس جديد. من وجهة نظر SEO: من الأفضل عدم استخدام الضبط الافتراضي "القبيح" وإنما يجب استعمال الروابط الدائمة "الجميلة" لأنها قابلة للفهم من البشر، ومن المهم أخذ قواعد Google للروابط بعين الاعتبار عند ضبط "الأسماء اللطيفة" (slugs) لصفحات ومقالات موقعك. في النهاية، إن قررت تغيير بنية الروابط الدائمة في موقعٍ حي، فافعل ذلك بقدرٍ كبيرٍ من الحذر وتأكد أنك تستعمل أدوات مناسبة للتعامل مع إعادة التوجيه. إن كانت لديك أيّة أسئلة أو استفسارات حول الروابط الدائمة، فاترك تعليقًا وسنحاول جاهدين مساعدتك. ترجمة -وبتصرّف- للمقال The Ultimate Guide to WordPress Permalinks لصاحبه Tom Ewer.
  19. عبد اللطيف ايمش
    مزيد من المعلومات حول "مخططات الفئات (Class Diagram) في لغة النمذجة الموحدة UML"
    مخطط الفئات (classes) هو جزءٌ مهمٌ جدًا من لغة النمذجة الموحدة UML، وهو مخطط هيكلي مهمته عرض الفئات بنظامٍ معيّن مع جميع العلاقات التي تربط بينها، وهو -برأيي- أشهر نوع من المخططات في هندسة البرمجيات. يساعدك رسم مخطط الفئات على رؤية المشكلة بأفقٍ أوسع؛ وعندما تكتبها، فستفرِّغ مساحةً في رأسك للأفكار الجديدة. وتُسهِّل أيضًا فهم هيكلية الفئات من الآخرين عندما تناقش المشكلة معهم. الفكرة هي أنني أنسى عادةً بنية المخططات عندما أحاول قراءة أحد المخططات التي رسمها غيري، فلهذا قررت كتابة هذه المقالة لعلها تذكرني بها في المستقبل. دورة علوم الحاسوب دورة تدريبية متكاملة تضعك على بوابة الاحتراف في تعلم أساسيات البرمجة وعلوم الحاسوب اشترك الآن الفئة – Class المكون الأساسي لهذه المخططات هو مخطط الفئة، التي تَظهَر على شكل عقدة (node) وعادةً كصناديق (boxes)، يمكن أن يُعرَّف لكل صنف دوال (methods) وخاصيات (attributes)، كما هو موضَّح بالشكل أدناه: الوراثة – Inheritance وراثة الفئات -في ما يتعلق بمخططات UML- هي علاقة تعميم (generalization) التي تمثل علاقة "هو" (is a) على مستوى الفئة، المخطط الآتي يُظهِر كيفية رسم التعميم. التطبيق – Realization هنالك علاقة مختلفة في UML للواجهات (interfaces)، فالوراثة من واجهة تسمى "implementation" التي هي علاقة "تطبيق" (realization) في مخططات UML. تمثيلها الشكلي مشابه للوراثة، إلا أنَّ الخط مقطّع (dashed)، ويجب تحديد أنَّ الواجهة هي «مجرَّدة» (abstract) – أي أنَّ اسمها مكتوبٌ بخطٍ مائل؛ كما هو مبيّن في هذا الرسم. الارتباط – Association شكل آخر من أشكال العلاقات في مخططات الفئات هو الارتباط (association)، وهو علاقة على مستوى الكائنات (object-level) أي أنه يحدث بين كائناتٍ لأصنافٍ مرتبطةٍ؛ لذا تُمثَّل كل العلاقة كعائلة من الوصلات (links). هنالك عدة أنواع من الارتباط مُحدَّدة أكثر (التجميع aggregation و التألف composition). التجميع – Aggregation التجميع هو شكل أكثر تحديدًا وتخصيصًا من الارتباط. وهو علاقة "لديه" (has a)؛ التمثيل الرسومي لهذه العلاقة هو الآتي: التألف – Composition شكل أكثر تخصيصًا من التجميع هو التألف (composition) فبدلًا من علاقة "لديه" (has a) تكون العلاقة هي "يملك" (owns a). وهذا ملائمٌ للعلاقات التي لا يمكن أن يتواجد فيها كائن إلا كجزءٍ من كائنٍ آخر. على سبيل المثال، إن كنت هنالك طائرة تملك جناحًا فهذا تألف، فماذا ستفعل بالجناح لوحده؟ لكن إن كانت هنالك بركة فيها بعض البط فهذا تجميع، لأنه يملك للبط أن يعيش دون بركة (وإن لم يكن سعيدًا بذلك)، والبركة ستبقى بركة حتى لو لم يكن فيها بط؛ التمثيل الرسومي لعملية التألف هو مثل التجميع، لكن المُعيَّن مملوء وليس مُفرَّغ. الاعتمادية – Dependency آخر نوع من العلاقات هو "الاعتمادية" (dependency) وهو أضعف من الارتباط (association) ويقول: إن كانت الفئة تستعمل فئةً أخرى، فهي تعمد عليها. يكون من المناسب استعمالها في حالات تكون نسخةٌ من الفئةِ مخزنةً في متغيرٍ محلي في دالة فئة أخرى، أو إذا استعمِلَت دالةٌ ثابتةٌ (static method)؛ لذا لن تكون الفئات مرتبطةً، لكن واحدة تعتمد على الأخرى. خلاصة صممت كل الأمثلة السابقة باستخدام محرر مفتوح المصدر باسم Dia، وأنا أنصح باستخدامه. ولأنه محرر رائع، فهذه صورة شاملة لجميع أنواع العلاقات إن أحببت طباعتها. ترجمة -وبتصرّف- للمقال UML Class Diagram لصاحبه Radek Pazdera.
  20. عبد اللطيف ايمش
    مزيد من المعلومات حول "كيف تنمي المجتمع الخاص بمشروعك مفتوح المصدر"
    هل لدى مشروعك مجتمعٌ نشطٌ، لكن هنالك الكثير من العمل الذي لا يستطيع ذاك المجتمع تحمل عبئه؟ هذه آخر مقالة من سلسلة المقالات حول التسويق للمشاريع مفتوحة المصدر، وقد حان الوقت للتركيز حول كيفية تنمية المجتمع. الدروس السابقة في هذه السلسلة: الجمهور المستهدف وصفحة الهبوط كيف تجعل الوصول مشروعك المفتوح المصدر أسهل طرق التعريف بمشروعك المفتوح المصدر كيفية تحويل مستخدمي مشروعك مفتوح المصدر إلى مساهمين كيف تنمي المجتمع الخاص بمشروعك مفتوح المصدر (هذا الدرس) السبب وراء تنمية المجتمع إن بدَأ مجتمعك بالنشوء بنجاح، لكنه لم ينمو كما كنتَ متوقعًا، فربما هنالك العديد من الأسباب المُمكنة لذلك، وعليك معرفتها ولتكن واقعيًا حولها. ستنتمي تلك المسببات إلى أحد هذين التصنيفين: الأشياء التي يمكنك فعل شيءٍ حيالها الأشياء خارج نطاق قدرتك هل أصبح متتبع العلل issue tracker لديك مزدحمًا بعد ازدياد عدد الأشخاص العاملين عليه؟ ألم يزدد وقت استجابتك لاستفسارات المساهمين الجدد لأنك تقضي وقتًا أطول لمناقشة الأمور مع الأشخاص الموجودين ضمن مجتمعك؟ هل تبقي التوثيق محدثًا دومًا؟ هل مضت سنتان منذ آخر مرة نشرتَ فيها تدوينةً حول المشروع؟ ليس من الصعب نسيان هذه الأمور الصغيرة عندما يصبح المجتمع الخاص بمشروعك كبيرًا ولا يتوقف عن الحركة والعمل ويتطلب منك اهتمامًا دائمًا. لكن نسيان تلك الأمور قد تسبب توقف نمو مشروعك في المستقبل؛ فكلما كبر مشروعك، كلما أصبح معقدًا بعمليات ونقاشات كثيرة يجب على القادمين الجدد أن يعتادوا عليها، مما يؤدي إلى تصعيب انضمام المساهمين من جديد. إن كانت المسببات من التصنيف الثاني، فهذا مُشكل كبيرٍ لك، خصيصًا للمشاريع الصغيرة، فقد لا يكون المجتمع كبيرًا ليحتوي عددًا كافيًا من المساهمين؛ فربما هنالك عشرة أشخاص في هذه الكوكب مهتمين بمشروعك وقادرين على المساهمة فيه، وخمسة منهم يساهمون فيه من قبل، وثلاثة لديهم عقود عمل تجعل من الصعب عليهم المساهمة في المشاريع، واثنين آخرين يفضلون قضاء وقت فراغهم مع أولادهم الصغار. يتطور عالم التقنية بوتيرة عالية، ألم تلاحظ عدم وجود نشاط كبير في مكتبة COBOL التي كتبتَها في السنوات القليلة الماضية؟ ربما تقوم بكل شيءٍ بشكلٍ صحيح، لكن الآخرين ينتقلون إلى أشياءٍ جديدة. فعندما بدأتَ كنتَ تستبدل تقنيات قديمة بهذه المكتبة الجديدة، وهذا ما يحدث اليوم لمكتبتك. الخيارٌ عائدٌ إليك إن كنتَ تريد متابعة العمل على ما هو قديم، أم "القفز" من السفينة كما يفعل الباقون. بعد أن شرحنا المشاكل المحتملة، سنعرض كيفية حلها. حسن باستمرار أمعن النظر بمدى سهولة الانضمام إلى المشروع للوافدين الجدد، وجرِّب سلوكياتٍ وتقنياتٍ مختلفة لترى أيها أصلح لك. يتطلب الحفاظ على مجتمعك وتوسعته جهدًا كبيرًا كما هو الحال عند بناءه، لكنك لست وحدك هذه المرة. اجعل بعض العادات الجيدة في إدارة المجتمع جزءًا من خطة سير العمل. هل سبب أحدهم مشكلة في الواجهة؟ عليهم أيضًا تحسين التوثيق. شجِّع الذين أضافوا ميزات كبيرة أن يكتبوا تدوينةً عنها؛ فهذا عملهم وعليهم أن يفخروا به. اشرح كل ما تفعله في سلسلة من التدوينات على صفحة مشروعك، كي يتطلع الآخرون إلى مساعدتك؛ شاور مجتمعك في أمور المشروع، واعطِ الأعضاء الموثوقين امتيازات وصول كاملة إلى المستودع؛ وبهذا ستصنع "آلة" ذات اكتفاءٍ ذاتي تستطيع أن تعمل دون استهلاك كامل طاقتك ووقتك الفارغ. اعرض مشروعك في أحد المؤتمرات هنالك الكثير من المؤتمرات التي تُركِّز على مختلف جوانب الحواسيب حول العالم. إن أردت أن يظهر مشروعك أمام العالم، فسجِّل كي تلقي كلمةً حوله في أحد المؤتمرات؛ وستتاح لك فرصٌ عديدةً إن لم يكن منتجك تجاريًا. يمكن أيضًا عرضه على الأشخاص الذين قد يرونه مفيدًا في اللقاءات والاجتماعات المحلية المختصة بتقنية المعلومات. أحد أكبر المؤتمرات هو FOSDEM في بروكسل، سجل مشروعك لمؤتمر السنة القادمة، حتى لو كنت ستتحدث عنه للتعريف به فقط (وليس لشرح تفاصيله). اعمل مع المطورين الأقل خبرة تتوجه معظم النصائح التي قدمناها في هذه السلسلة إلى الأشخاص الذين لديهم باع طويل في مجالاتهم، أي أنهم مطورون أولي خبرةٍ متوسطة إلى متقدمة، والذين يبرمجون لفترةٍ لا بأس بها. لكن المشكلة أن لديهم عملًا بدوامٍ كامل، وربما لديهم عائلة ومشاريع فرعية عليهم العمل عليها. خصص جزءًا من وقتك كي تسهل على المساهمين الأقل خبرةً أن يعملوا على مشروعك، وهذا يساعدك في كسب مجموعة كبيرة من الأناس المتحمسين الذين يودون الحصول على الخبرة بالعمل معك؛ وهذا يتضمن الطلاب، والأشخاص الذين يغيرون مهنتهم... إلخ. ضع بذهنك أنهم لن يبقوا قليلي الخبرة إلى الأبد، فقد تحصل على أعضاءٍ رائعين في مجتمعك في المستقبل إن أقمت علاقاتٍ بناءةٍ معهم. ادفع مالا للمساهمين لن يكون هذا الخيار واقعيًا للمشاريع التي يقوم عليها أشخاص، لكنه فعالٌ جدًا للشركات. إن استعملت مواقع مثل BountySource، فيمكنك تحديد سعر للميزات التي تريد إضافتها وربما يأتي أحدهم ويقبل عرضك. خيارٌ أخرٌ هو إنشاء مسابقات حيث يعمل فيها الآخرون على مشروعك لقاء مبلغٍ مالي أو شكل من أشكال التقدير الشخصي. تختار العديد من الشركات تمويل الأشخاص المهمين في المجتمع وتدفع راتب عملٍ بدوامٍ كامل لهم ليعملوا على المشروع. هذا مثالٌ ممتاز يبيّن كيف أنَّ العمل على المشاريع مفتوحة المصدر لا يعني أنَّه بالمجان. خاتمة فتح مصدر مشروعك هو بداية جيدة، لكن ستزداد المتعة عندما يبدأ الآخرون باستعماله والمشاركة فيه؛ وحتى ولو كان أغلبنا مبرمجون، فإننا نجد أنَّ المصدر المفتوح أشبه "بمؤسسة اجتماعية". هذه آخر مقالة من سلسلة "التسويق للمشاريع مفتوحة المصدر"، شكرًا لبقائك معنا حتى النهاية، أرجو أن تكون قد وجدتها مفيدةً :-) . ترجمة -وبتصرّف- للمقال Growing the community around your open-source project لصاحبه Radek Pazdera.
  21. عبد اللطيف ايمش
    مزيد من المعلومات حول "كيف تحول مستخدمي مشروعك مفتوح المصدر إلى مساهمين"
    يجعل المساهمون من المشاريع مفتوحة المصدر مرحةً، فالسماح للآخرين باستعمال، وإعادة استعمال، وتحسين الشيفرات الخاصة بك وتحويلها إلى شيءٍ جديد لم تكن تتخيله، هو أمرٌ رائع؛ لكن -كغيره من الأمور في هذه الحياة- لن يتشكل المجتمع من العدم. ونحن نمر في هذه السلسلة من المقالات بعدة استراتيجيات لمساعدتك في بناء مجتمع حول مشروعك المفتوح المصدر؛ وركَّزت آخر ثلاث مقالات على جذب المستخدمين، وسنلقِ نظرةً هذه المرة على كيفية تحويلهم إلى مساهمين. الدروس السابقة في هذه السلسلة: الجمهور المستهدف وصفحة الهبوط كيف تجعل الوصول إلى مشروعك مفتوح المصدر أسهل التعريف بمشروعك مفتوح المصدر كيف تحول مستخدمي مشروعك مفتوح المصدر إلى مساهمين (هذا الدرس) كيف تنمي المجتمع الخاص بمشروعك مفتوح المصدر وضح أن تطبيقك مفتوح المصدر إن جعلت تطبيقك سهل التثبيت بإنشاء مُثبِّت أو حزمة، فهنالك احتمالٌ كبيرٌ ألّا يفتح المستخدمون صفحة الهبوط أو المستودع؛ ولا بأس في ذلك في أغلبية الأوقات، لكن عليك أن تضع أنَّ تطبيقك مفتوح المصدر في مكان ما فيه لأولائك الذين يريدون التواصل ومعرفة المزيد من المعلومات حول تطبيقك. قد تستعمل خيارًا في سطر الأوامر، أو مربع حوار "حول" أو "About" إن كان لتطبيقك واجهةٌ رسوميةٌ؛ وضع رابطًا لصفحة الهبوط وربما لمتتبع العِلل الخاص بك (المكان الذي يُبلِّغ الناس فيه عن المشكلات التي تواجههم). ومن المحتمل أنَّ نكتةً في التطبيق ستدفع المستخدم إلى زيارة الرابط الموجود فيها. مكانٌ جيدٌ لتضع فيه طرق التواصل معك هو عبر رسائل الخطأ ومربعات الحوار التي تظهر عند انهيار التطبيق؛ أخبر فيها المستخدمين كيف يبلغون عن المشكلة، وهذه هي أكثر الطرق شيوعًا للمشاركة في تطوير المشاريع؛ حيث يحاولون فعل شيءٍ ما، لكنه لا يعمل وسيمدون يد العون في إصلاح المشكلة. المزايا المرتقبة إحدى طرق دفع الآخرين للمشاركة هي استعمال الميزات غير المكتملة؛ ربما تدمج الميزات التي تود إضافتها للتطبيق في المستقبل إلى واجهة المستخدم وتُظهِر رسالة تشرح أن هذه الميزة لم تتم، وتدعو الآخرين إلى مساعدتك في إكمال العمل عليها. قد تستعمل خيارًا إضافيًا في سطر الأوامر الذي يعرض رسالةً (بدلًا من الميزة المطلوبة)، ويمكن فعل المثل بمربعات الحوار في التطبيقات الرسومية. ضع ببالك أن هذا قد يصبح مزعجًا بشكل سريع؛ ولهذا عليك استعماله مع الميزات غير الأساسية في مشروعك؛ فلن يُسعَد مستخدموك إن نزَّلوا مكتبتك الجديدة عن الفرز (sort) ليجدوا أنَّ الفرز السريع (quick sort) ليس مُبرمجًا بعد. اكتب توثيقا منفصلا للمطورين يجب أن يكون لمشروعك توثيقٌ من نوعٌ ما للمطورين مع لمحة من مكان تواجد الأجزاء الرئيسية من البرنامج، ومرجع للواجهات البرمجية (APIs) يمكن البحث فيه. من الأفضل أن يتم توليد ذاك التوثيق من الشيفرات المصدرية بأدواتٍ مثل doxygen، أو JSDoc، أو YARD. يساعدك وجود التوثيق مع الشيفرات بتسهيل التعديلات البرمجية على المشروع. وهنالك مواقع مثل RubyDoc يسمح لك بتوليد واستضافة التوثيق مجانًا. لا يوجد أبسط من هذا! إن كتبت لمحة للمطورين عن المشروع وأبقيتها مختصرة ومحددة، فليس من المحتمل أن تحتاج إلى إعادة كتابتها بين الحين والآخر، إلا إن كنت تعيد هيكلة المشروع بأكمله. وضح ما الذي يجب فعله من المحتمل أن يتمحور تطوير تطبيقك حول مُتتبع العلل، فستأتي العلل وسيحاول المساهمون تتبعها وحلها، وفي حال استمرت هذه العملية، فسيمسي من السهل أن يتحول إلى كومة مربكة من الأشياء التي لن يستطيع أحد غيرك أنت وبعض أفراد فريق المساهمين فهم طريقة تنظيمها. لكن كيف سيتمكن المساهمون الجدد من البدء في العمل؟ حاول أن يكون متتبع العلل منظمًا بشكلٍ جيد وكأنك ستتجه غدًا إلى العمل مزارعًا في الحقل، ولن تدخل إلى الإنترنت بعد ذاك اليوم أبدًا، وسيأتي أحدهم ليكمل ما بدأتَه. أبقِ قائمةً بالمهام البسيطة والمحددة للمساهمين الجدد ليفعلوها عندما يأتون لأول مرة، حتى لو كنت تستطيع تنفيذها أنت بخمس دقائق، ربما يأخذ تفصيلُ شرحِ مشكلةٍ ما في متتبع العلل وقتًا لا بأس به، لكنه سيؤتي أكله إن ساعدتْ تلك العلة بتثبيت مساهم جديد في المشروع. كن متجاوبا عندما يحصل مشروعك على أول المستخدمين أو حتى أول المساهمين، فستبدأ باستقبال أسئلة، وطلبات للميزات، وتبليغات عن العلل وحتى سيصلك حلولٌ لتلك العلل؛ حاول أن تستجيب وتساعد الآخرين بمشاكلهم في إطار زمني محدد، حتى لو كنت مشغولًا وتقوم بتطوعك في وقت فراغك. فستؤدي استجابتك لطلبات pull requests بعد شهر إلى فقدان المساهمين لحماسهم. أجب حتى وإن لم تستطع إنجاز ما طُلِبَ مباشرةً، فمن الأفضل أن تقول "لا" وتضع الطلب في قائمة الأعمال غير المنجزة من أن تتركه معلقًا في الهواء أو أن تعد بشيءٍ لا تستطيع تلبيته. لكن بدلًا من ذلك، ضع الطلب في متتبع العلل لعل أحدهم ينجزه؛ هذا هو جمال البرمجيات مفتوحة المصدر. أصبح مساهما إن كنت حديث العهد بهذا العالم المُربك من البرمجيات الحرة والمفتوحة المصدر، أو ربما كان مشروعك خارج "البيئة" التي نشأت بها واستخدمتها من قبل، فجرب المساهمة في مشاريع مشابهة وانظر إن كان من السهل البدء من التوثيق الذي كتبوه، وأين بدأت تواجه مشاكل معه. هل أجاب أحدهم عن تساؤلك أو قَبِلَ الرقعة (patch) التي أرسلتها؟ استخدم خبرتك من هذه التجربة لتقديم مشروعك بأفضل صورة ممكنة لتسهل انضمام المساهمين الجدد. ما التالي؟ لقد أرسيتَ أساسات مشروعك، وأعداد مستخدميه والمساهمين فيه تزداد باطراد، فما الخطوة الآتية؟ هذا ما سيكون موضوع آخر المقالات في هذه السلسلة. ترجمة -وبتصرّف- للمقال Turning users into contributors لصاحبه Radek Pazdera.
  22. عبد اللطيف ايمش
    مزيد من المعلومات حول "طرق التعريف بمشروعك مفتوح المصدر"
    حتى لو لم تكن تطلب من الأشخاص مالًا لقاء استعمالهم لتطبيقك، لكن ما يزال علينا التسويق قليلًا له قبل أن يسطع نجمه. كيف إذًا سيعلم الآخرون عنه؟! الناس مشغولون هذه الأيام التي أصبحت فيها المشاريع مفتوحة المصدر لا تُعد ولا تحصى، وأصبحت المنافسة قوية جدًا على المساهمين في المشاريع. عرفنا -في آخر مقالين من هذه السلسلة- الجمهور الهدف لمشرعنا ثم تأكدنا أنه متاحٌ -وبسهولة- لمن شاء أن يستعمله؛ هذا الدرس هو القسم الثالث من سلسلة التسويق للمشاريع مفتوحة المصدر وسيركِّز على كيفية التعريف بمشروعك. أقسام هذه السلسلة: الجمهور المستهدف وصفحة الهبوط كيف تجعل الوصول إلى مشروعك مفتوح المصدر أسهل طرق التعريف بمشروعك مفتوح المصدر (هذا الدرس) كيف تحول مستخدمي مشروعك مفتوح المصدر إلى مساهمين كيف تنمي المجتمع الخاص بمشروعك مفتوح المصدر الفكرة بسيطةٌ للغاية: عليك أن تعرض المشروع على الأشخاص المناسبين في الوقت الملائم (عندما يحتاجون إلى التعرف على مشروعك)؛ كل برنامج له وظائف معيّنة تجعله مفيدًا لمجموعة بسيطة من المستخدمين. لا ترسل رسائل عشوائية لأكبر عدد تستطيعه من الأشخاص؛ لكن وجِّه جهودك إلى المجتمعات التي ستستفيد من المعرفة عن مشروعك. لنقل أنَّك برمجت إطار عملٍ مثل ExpressJS، عمومًا ستكون جهودك موجهة نحو الأشخاص الذين يطورون مواقع الويب؛ وربما تود أن تستهدف أولاءك الذين "يفكرون" في صنع موقع إلكتروني لكن لم يبدؤوا بعد، أما البقية فسيقولون "هذا رائع!" لكنهم سيواصلون استعمال Sinatra أو Flask لأن الشيفرات التي كتبوها تعتمد عليها. حل المشكلات وهذا ما يبرع المبرمجون بفعله. لِمَ لا تستعمل ذلك لصالحك؟ لقد أنشأت مشروعك لحل مشكلة واجهتك ومن المحتمل أنَّ الآخرين يحاولون حل نفس المشكلة. أنشِئ محتوى حول المشاكل التي يحلها مشروعك، وما الذي يفعله بشكلٍ جيد. وهذا يعني أنَّ عليك كتابة مقالات، أو صنع مقاطع فيديو، أو تسجيل بودكاست، أو حتى إلقاء محاضرات أو التعليم في دورات تدريبية، أيها تُفضِّل. لكن النص يبقى هو الأفضل لأنه دائم وقابل للبحث. يمكنك نشر تلك المواد في عددٍ من الأماكن، مثل مدونتك الشخصية أو أن تنشر منشورًا على مدونة خاصة بالمجتمع التقني الذي ينتمي إليه مشروعك. ثم شارك ذاك المقال مع مَن تظن أنهم سيجدونه مفيدًا. وهذا يتضمن منتديات النقاش، والمجموعات البريدية، وقنوات Gitter، و Reddit أو Hacker News. تأكد أنَّ ذاك المجتمع سيرحب بذلك (بعض الأقسام الفرعية من Reddit [يسمونها subreddits]) لا تسمح بنشر روابط)، وكن حذرًا جدًا بالتعامل مع القوائم البريدية، فراعي أنَّ رسالتك ستصل إلى البريد الوارد لكثيرٍ من الأشخاص. إن كانت هنالك العديد من قنوات التواصل لجمهورك المستهدف، فلا تُرسِل الرسائل إليها جميعًا، اختر قناتين أو أكثر منهم فقط، وإن أُعجِبَ الجمهور بمشروعك فسيتنشر تلقائيًا. اجعل تواتر نشرك للمقالات في حدود المعقول وعدِّلها بناءً على ردة فعل القراء، فإن أعجبتهم، فذاك أمرٌ حسن، وأتبعها أخرى في الأسبوع القادم؛ وإن لم يكونوا متحمسين، فحاول شيئًا جديدًا في المرة القادمة، وستكون الردود على مشروعك أفضل إن كنت تشارك في المجتمع مشاركةً فعالةً (بجانب مشاركتك لدعايتك إلى مشروعك). الإجابة عن الأسئلة إن كان مشروعك يحل مشكلة مخصصة جدًا، فربما من المفيد أن تراقب المواقع التي يسأل الناس فيها عادةً عنها، مثل StackOverflow أو Reddit، وأن تساعدهم في الأمر. وعندما تُجيب، حاول دائمًا أن تسهب في الموضوع قليلًا لإعطاء مجال لتشرح كيف يعمل حلّك للمشكلة، ولا بأس أن تُعدِّد الخيارات الأخرى المتاحة. ربما ذلك يستهلك وقتًا أكثر من إعطاء مجموعة روابط، لكن ربما تستفيد من سؤالك بتحويله إلى تدوينة لاحقًا. تلك المواقع هي مولدات أفكار رائعة؛ فإن أردت أن تعرف ما هي المشاكل التي يعاني منها الناس، فألقِ نظرةً على الأسئلة التي يسألونها. العمل مع الآخرين لا يتواجد مشروعك في الفراغ، وإنما بُنِيَ باستعمال بعض المكتبات الأخرى، وهنالك أشياءٌ أخرى يمكن أن تُدمَج أو تتعاون معه. أخبر الناس كيف يستطيعون استعمال مكتباتك وأرهم كيف يدمجون مشروعك مع الأدوات الأخرى. قدِّم ما لديك لأعضاء المجتمعات التي تلتف حول تلك المشاريع، وسينظرون إليها إن وجدوها مفيدةً؛ وعلى الرغم من أنك تعتمد على شعبية مشروع قائم، إلا أنك تساهم في نشره في نفس الوقت. وما لم يثر المحتوى الذي تقدم جدلًا، فلا يوجد سببٌ يمنع أصحاب تلك المشاريع من الترحيب لكتابتك عن مشاريعهم، وربما يشاركون ما كتبتَ أيضًا: "رائع! أحدهم أنشأت روبوتًا باستخدام مكتبتي". كن لطيفا لا تقلل من شأن عمل غيرك لكي تعلي من شأن عملك. ربما تظن أن مشروعك هو الأفضل، صحيح؟ هذا لأنك من أنشأه وقد يكون هذا صحيحًا، ولا بأس من عمل مقارنات، لكن لا تقل أشياءً مثل "على عكس مكتبة RottenWatermelon JS، هذا الإطار يحتوي على sane API" أو "اضطررت على مر السنين أن أتعامل مع الخردة المسماة ‎OMG++‎، لكنني أتيت اليوم لأفتح مصدر اللغة Gobbledygook: لغة البرمجة للقرن الحادي والعشرين". قد يلفت الجدار النظر إليك، لكنه لن يُنشِئ بيئةً صحية وودودةً لكي ينمو بها المجتمع المحيط بمشروعك؛ تذكر أنه في خمس سنين سيصبح مشروعك تقنيةً قديمةً جدًا ولن يستعملها أحد. ما التالي؟ أصبح مشروعك موجودًا وأصبح يحصل على أول مستخدميه؛ عليك الاستمرار في جهودك وسيؤتي عملك أُكله، سننظر في المقالة التالية كيف نحول المستخدمين إلى مساهمين. ترجمة -وبتصرّف- للمقال Spreading the word about your open-source project لصاحبه Radek Pazdera.
  23. عبد اللطيف ايمش
    مزيد من المعلومات حول "كيف تجعل الوصول إلى مشروعك مفتوح المصدر أسهل"
    أصبحت المشاريع مفتوحة المصدر شيئًا عظيمًا؛ لكن بالتزايد الكبير لأعداد المشاريع مفتوحة المصدر، ازدادت صعوبة جذب المساهمين. وتدعم الشركات الكبرى -مثل فيسبوك و تويتر- عددًا كبيرًا من تلك المشاريع، مما جعل الجميع يتنافس لنيل مساهمات المُبرمجين ولفت انتباههم. هذا ثاني درس في هذه السلسلة من المقالات التي سترشدك إلى كيفية بناء مجتمع حول مشروعك. الجمهور المستهدف وصفحة الهبوط كيف تجعل الوصول إلى مشروعك مفتوح المصدر أسهل (هذا الدرس) طرق التعريف بمشروعك مفتوح المصدر كيف تحول مستخدمي مشروعك مفتوح المصدر إلى مساهمين كيف تنمي المجتمع الخاص بمشروعك مفتوح المصدر تحدث الدرس السابق عن الفئة المستهدفة وكيف تُقدِّم مشروعك إليهم؛ وفي هذه المرة سننظر إلى جعل الوصول إليه سهلًا. عندما يرى المستخدم أنَّ مشروعك يفي باحتياجاته، فسيبحث عن تعليمات حول كيفية استعماله وطريقة عمله؛ ومن المفيد لك أن تجعل عملية التثبيت أسهل ما يمكن لتجنب خسارة الأشخاص على الطريق، وهذه هي طريقة فعل ذلك: ابن حزمة يأتي المشروع الاعتيادي مع مجموعة من الخطوات لبناءه وتثبيته، لكن من الأفضل اختصار تلك المجموعة إلى خطوة وحيدة: تثبيت حزمة. هل ستجرب مشروعًا يحتاج تثبيته إلى أمر sudo apt-get install وحيد، أم ستجرب مشروعًا يحتاج إلى إعداد بيئة لبناء البرامج، وتثبيت عدد هائل من الاعتماديات، ثم البناء من المصدر؟ حزم التوزيعات أول خيار أمامك هو إنشاء حزمة خاصة بنظام التشغيل، ربما لتوزيعة لينُكس (حزم deb، أو rpm، أو pacman) أو لنظام OS X باستعمال Homebrew. أو تستطيع إنشاء حزمة على مستوى اللغة البرمجية (language-level) إن كان هذا الخيار متوفرًا للتقنية التي بنيت مشروعك بها. الحزم الموجودة في مستودعات التوزيعات هي أكثر الحلول راحةً للمستخدم، سامحةً لهم بتثبيت البرمجيات التي تُوفرها من مصدرٍ موثوق. عملية تعلم إضافة حزمة مشروعك إلى المستودعات هي عمليةٌ مرهقةٌ وصعبة وعليك المرور على عشرات الصفحات من التوثيق حتى تُقبَل حزمتك في المستودعات؛ لكن ذلك العمل سيؤتي أُكله، فسيصبح تثبيت مشروعك يتطلب تنفيذ أمرٍ وحيدٍ من المستخدم؛ وذلك يستحق كل هذا الجهد لوجود الملايين من مستخدمي نفس نظام التشغيل. الحزم على مستوى اللغة أو يمكنك إنشاء حزمة على مستوى اللغة البرمجية -إن كان هذا الخيار متوفرًا للتقنية التي تستعملها- مثل PyPI، و Rubygems، و npm وغيرها. وإنشاء تلك الحزم أبسط، وتُخَلِّصُكَ من قراءة عشرات الصفحات من التوثيق التي عليك المرور بها كي تُقبَل حزمتك في مستودعات توزيعةٍ ما. وقد تكون هذه الطريقة أفضل بناءً على فئتك المستهدفة. إنشاء حزمة على مستوى اللغة هي ضرورة مُلِحَّة للمشاريع التي ستُستعمَل من بقية المطورين مثل المكتبات. فلمطوري روبي أو JS، لن تكون مكتبةٌ ما خيارهم المفضَّل إن لم يكن لديها حزمة gem أو npm. سينتشر مشروعك أكثر عندما تضعه في تلك المستودعات، إذ سيظهر عندما يبحث المبرمجون في تلك المستودعات عن المكتبات المفيدة. ربما يكون هنالك -في بعض الأحيان- أدوات أو خوارزميات لتحويل حزمة على مستوى اللغة إلى حزمة نظام، وبهذا تستطيع أخذ حزمة مشروعك على مستوى اللغة وإعادة استعمالها في توزيعاتٍ عدِّة؛ فيتمكن Debhelper -مثلًا- من بناء تطبيق بايثون تلقائيًا إن كان يأتي مع ملف setup.py. سكربت إعداد تلقائي إن لم تسطع توفير حزمة لمشروعك، فعليك -على الأقل- أن توفِّر سكربت لبناء وتثبيت البرمجية. وهذا السكربت قد يمثل بديلًا للحزمة لأنه يوفر طريقةً سهلةً للتثبيت. هذه بعض المشاريع الأخرى الشهيرة التي تستعمل سكربتات الإعداد: oh-my-zsh rvm لا يثق بعض الأشخاص في تلك السكربتات، وهم على حق في بعض الأوقات. أنت سيد قرارك هنا، فليس لديك أداة إدارة حزم موثوقة لتضمن أمان الحزمة. كن حذرًا جدًا وتأكد أن ما تضعه في السكربت لن يضر بأنظمة المستخدمين أو بياناتهم؛ خصيصًا عندما تفعل أشياءً تتطلب امتيازات الجذر (root – أي الامتيازات الإدارية)؛ لن يساعدك خسارة عدد كبير من الأشخاص لبياناتهم بسبب تطبيقك في حملتك التسويقية له. اكتب دليلا لاستعمال تطبيقك تمكن الآن المستخدمون من تثبيت مشروعك بسهولة، وعليك الآن أن تريهم طريقة استعماله. حان الوقت الآن لكتابة دليل المستخدم؛ وليس من الضرورة أن يكون هذا الدليل طويلًا ومفصلًا؛ فيجب أن يشرح الواجهة الأساسية، ويشير إلى أيّة حدود للتطبيق. لا تكتب كثيرًا من المعلومات التقنية وركِّز على ما يحتاج المستخدم الاعتيادي إلى معرفته. لا تجاهد لكي يكون الدليل مفصلًا وكاملًا من البداية؛ ابدأ من أهم النقاط ثم أكمل الباقي أثناء تطويرك للمشروعك، وستستفيد من أسئلة المستخدمين الجدد الذين يحاولون استعمال مشروعك في كتابة محتوى الدليل. أفضل بنية وأدوات لكتابة الدليل تعتمد على طبيعة وحجم مشروعك، وعمّا إذا كنت تولِّد الدليل من الشيفرة المصدرية أم كنت تكتبه بنفسك بأكمله يدويًا. يجب أن يَسهُل البحث في الدليل النهائي (حتى لو وضعت كل المعلومات في صفحة وحيدة واستعملت خاصية البحث في المتصفح). لا تنس الرخصة خطأٌ شائعٌ يقلل كثيرًا من استعمال مشروعك هو عدم وجود رخصة مفتوحة المصدر؛ تأكد أن شيفراتك تأتي مع رخصة معترف بها من FSF أو OSI؛ راجع الدرس كيف تختار رخصة مفتوحة المصدر لبرامجك لمزيدٍ من المعلومات حول هذا الصدد. ما التالي؟ أصبح مشروعك الآن جاهزًا للاستعمال من المستخدمين، فحان الوقت لنشره، وهذا هو موضوع المقالة القادمة. ترجمة -وبتصرّف- للمقال Make your open-source project accessible لصاحبه Radek Pazdera.
  24. عبد اللطيف ايمش
    مزيد من المعلومات حول "صفحة الهبوط والجمهور المستهدف عند التسويق للمشاريع مفتوحة المصدر"
    هل سبق وأن نشرتَ مشروعًا مفتوح المصدر ولم تشاهد حشدًا كبيرًا من الناس آتين لتنزيله بالآلاف، مما يعطل الخواديم في أول ليلة بعد إصداره؟ حسنًا، لا تتشكل أغلبية المجتمعات (communities) بين ليلةٍ وضحاها؛ وأصبح من الصعب جذب المساهمين -بوجود العدد الكبير من المشاريع المتوفرة في أيامنا هذه- دون القيام ببعض التسويق. لكن أغلبنا -معشرَ المبرمجين- لسنا معتادين على التسويق أو مرتاحين بفعله؛ وبذلك ستبقى الشيفرات التي نكتبها تقبع مهجورةً بالمستودعات ولا يأبه أحدٌ بأمرها، فما الحل؟ هذه السلسلة من المقالات ستأخذنا برحلةٍ عبر عددٍ من الأمور التي عليك فعلها كي تساعد باكتشاف مشروعك ولتُسهِّل على الآخرين الاشتراك به. هذا الدرس هو القسم الأول من سلسلة التسويق للمشاريع مفتوحة المصدر وسيركِّز على كيفية التعريف بمشروعك. الجمهور المستهدف وصفحة الهبوط (هذا الدرس) كيف تجعل الوصول إلى مشروعك مفتوح المصدر أسهل طرق التعريف بمشروعك مفتوح المصدر كيف تحول مستخدمي مشروعك مفتوح المصدر إلى مساهمين كيف تنمي المجتمع الخاص بمشروعك مفتوح المصدر يبدأ المجتمع بالمستخدمين السؤال الذي يبدأ الأشخاص بسؤاله عادةً هو "كيف أتمكن من جعل الآخرين يساهمون في مشروعي؟" وهذا السؤال -في غالب الأحيان- سابقٌ لأوانه. فقبل التفكير بالمساهمين، عليك التفكير بالمستخدمين. فدون أن يكون لديك قاعدة مستخدمين كبيرة (نسبيًا)، سيكون من الصعب جذب أيّة مساهمين على الإطلاق. فهل تساهم أنت في مشاريع لم تستعملها قط؟ ربما لا، وكذلك سيفعل البقية. سأفترض أنك أنشأت مشروعك ليحل مشكلةً واجَهتك من قبل، وربما تواجه الكثيرين غيرك، كل ما عليك فعله هو أن تجدهم. اكتشف من هم جمهورك المستهدف تعتبر أصغر المشاريع "منتجاتٍ"، فهي تحل مشكلة أو تلبي حاجة ما؛ فما هي المشكلة التي يحلها مشروعك؟ ومَن الذي سيراه مفيدًا؟ سيساعدك التفكير بهذين السؤالين على توجيه جهودك والتركيز على من يهتمون دون أن "تزعج" من لا يأبهون بمشروعك بتاتًا. هل أنشأت إضافةً لمحرر vim (محرر سطري مشهور جدًا على الأنظمة الشبيهة بيونكس)؟ ربما أنت تبحث عن الأشخاص الذين يستعملون vim، وقد لا يكون وضع تلك الإضافة في "emacs subreddit" أفضل شيءٍ تفعله. ابحث عن أولائك الأشخاص وتواصل معهم وانضم إليهم، تنجذب مجموعات من ذوي الاهتمامات المتشابهة نحو أماكن معينة أو قنوات اتصال مخصصة، وربما لديهم اجتماعات محلية أو subredits خاصة بهم. بينما مثالنا عن vim السابق بسيط، لكن الأمر ليس بهذا الوضوح خصيصًا بجمهورٍ شغوفٍ ومتحمسٍ كالمبرمجين، فيمكن أن توقع نفسك بنقاشاتٍ محتدمة (يسميها معشر المبرمجين بالمصطلح "flame wars")، وفي بعض الأحيان لا يكتفون بتجاهلك وإنما سينالون من هيبة مشروعك؛ فاستهداف الأشخاص الصحيحين يعني أيضًا أنك لن تزعج أولاءك الذين لا يشاركونك رأيك. إعداد صفحة هبوط (Landing page) قبل إخبار الناس عن مشروعك، عليك أن تهيّء مكانًا لترسلهم إليه يحتوي كل ما يحتاجونه للبدء باستعمال مشروعك؛ وهذا المكان قد يكون ملف README على Github، أو تدوينة، أو موقع مخصص لذلك. يجب على تلك الصفحة أن تلخص ماذا يفعل مشروعك، ومن أين ستحصل عليه، وكيف تجعله يعمل، وقد تنتهي (اختياريًا) بمرجع مُبسَّط وسريع حول المهام أو المشاكل الشائعة؛ فعليك تبيان الحدود القصوى لمشروعك، لكن لا تعرضها في البداية، بل ركز على ما يبرع تطبيقك بفعله ودع تلك الحالات لتكتبها في التوثيق. إن كان يعطي تطبيقك مخرجاتٍ مرئيةً من أي نوع، أو كانت له واجهةٌ رسومية، فلا تنسَ أن تضيف لقطاتٍ للشاشة، وإن لم تكن مخرجاته مرئيةً، لا بأس من أخذ لقطات للطرفية (مكان إظهار نواتج الأوامر) أو عمل صور متحركة (gifs) لها؛ ضع بعين الاعتبار أنَّ الناس سيفهمون تطبيقك أسرع "بمشاهدته" أكثر من مجرد القراءة عنه. في النهاية، يجب أن توفر صفحة الهبوط طرقًا للتواصل معك أو للمجتمع المحيط بالمشروع ليحصلوا على الدعم؛ جهّز قائمةً بريديةً، أو قناة IRC، أو غرفة على Gitter ووفرها لهم؛ أما للمشاريع الصغيرة، فقد يكفي وضع بريدك الإلكتروني. عليك أن تراعي عادات الفئة المستهدفة، فلن يُسعَد ثلةٌ من خبراء أمن المعلومات بالتسكع في مجموعتك على فيس بوك. عليك بعد أن تجهز صفحتك أن تنشرها في مختلف أماكن تواجد المبرمجين مثل موقع Hacker News و r/programming (على reddit)؛ لكن جهودك تلك ليست موجهة لفئة معيّنة، وتعتمد على الحظ كثيرًا؛ سأتحدث عن طرقٍ أفضل لنشر مشرعك في مقالاتٍ قادمة من هذه السلسلة، ابقَ معنا! عندما تصل إلى مرحلة إنشاء الصفحة، تذكر أنَّه لا يهم شكلها بقدر أهمية محتواها؛ وفي الواقع، عليك أن تقضي وقتًا أطول بالتفكير بمحتواها أكثر من بقية الأمور. هل أنت مطور واجهات محترف يتمكن من تصميم موقع مصمم تصميمًا رائعًا في ساعتين؟ هذا جميل اذهب وصمم أجمل ما تستطيع، لكن لا تنفق ثلاثة أشهر وأنت تضيع وقتك على كم يجب أن تكون قيمة الهامش لعناوين الصفحة مثلا فالأمر لا يستحق كل ذلك العناء. ملف README على GitHub سيكون كافيًا عادةً. ما التالي؟ سنتحدث في المقالة القادمة عن جعل مشروعك أكثر قابليةً للوصول للمستخدمين. فالأسوأ من عدم القدرة على فهم ما الذي يفعله المشروع هو تضييع ثلاث ساعات لمحاولة جعله يعمل! ترجمة -وبتصرّف- للمقال Marketing for open-source projects لصاحبه Radek Pazdera.
  25. عبد اللطيف ايمش
    مزيد من المعلومات حول "الدوال (Functions) في PHP"
    عندما نكتب برنامجًا طويلًا جدًا، فإن الشيفرة ستوزَّع في عددٍ من الملفات والأصناف (classes) والدوال (functions)؛ الدوال هي مجموعة من التعليمات التي تنجز مُهمِّة معيّنة وهدفها ألا تكرر الشيفرات التي تكتبها؛ فمثلًا في نظام للاستيثاق، يكون هنالك دوال لتسجيل الدخول (login) والتسجيل (register) وتسجيل الخروج (logout). أبسط أشكال الدوال إن الشكل العام لأبسط دالة هو: <?php function function_name() { // الشيفرة } ?> وكما في المتغيرات، تستطيع إسناد أي اسم إلى الدالة (أعطينا الدالة في المثال السابق الاسم function_name). تُكتَب الشيفرة التي ستنفذها الدالة عندما يتم استدعاؤها بين أقواس معقوفة ({})؛ نستطيع استدعاء الدالة عبر كتابة اسمها ويليه أقواس عادية () كما في المثال الآتي: <?php // يمكنك أن تستدعي الدالة هنا قبل تعريفها // تعريف دالة ذات الاسم say_hello function say_hello() { // كل ما تفعله هذه الدالة هو طباعة hello echo "hello"; } // استدعاء الدالة say_hello(); ?> الدوال ذات الوسائط يمكننا تمرير المعلومات الإضافية (مثل اسم المستخدم وكلمة المرور) إلى الدوال باستخدام الوسائط (arguments)، وعلينا تعريف المعاملات (parameters). ملاحظة: الوسائط هي البيانات التي نمررها إلى الدالة عندما نستدعيها، أما المعاملات فهي المتغيرات التي نُعرِّفها عندما نكتب الشيفرة الخاصة بالدالة. يمكننا أن نعتبر أن المعاملات هي حاويات والوسائط هي البيانات التي نضعها في تلك الحاويات. <?php // دالة تسجيل الدخول ذات وسيطين function login($user, $pass) { // تطبع هذه الدالة اسم المستخدم وكلمة المرور echo "hello, username is $user and password is $pass"; } // استدعاء الدالة login("user1","UsEr!p@$$W0rD"); // استدعاء الدالة مرةً أخرى login("user2","simplepassword"); ?> المعاملات ذوات القيم الافتراضية يمكننا أن نعطي قيمًا افتراضية للمعاملات لكي يمكن تجاوز تحديد قيمتها عند استدعاء الدالة. <?php // دالة تسجيل الدخول ذات ثلاثة وسائط function login($user, $pass, $active = "not active") { // تعرِض هذه الدالة اسم المستخدم وكلمة مروره وحالته echo "hello, username is $user and password is $pass and user is $active"; } // استدعاء الدالة login('user1','UsEr!p@$$W0rD'); // استدعاء الدالة مرةً أخرى login('user2','simplepassword', 'active'); ?> ملاحظة: إن أردت ألّا تُحدِّد قيمةً لوسيطٍ ما عند استدعاء الدالة، فيجب أن يكون المعامل الموافق لذاك الوسيط في آخر القائمة كما في المثال السابق. ويملك المعامل افتراضيًا القيمة "null". الدوال ذات المعاملات متغيرة العدد يمكن أن تملك الدوال عددًا متغيرًا من المعاملات؛ وفي الواقع، تستطيع تمرير إي عدد من الوسائط إلى دالة؛ استعمل الدوال المُضمَّنة في PHP الآتية للوصول إلى تلك الوسائط: الدالة func_get_args()‎: تُعيد مصفوفة بجميع الوسائط المُمرَّرة الدالة func_num_args()‎: تُعيد العدد الإجمالي للوسائط المُمرَّرة. الدالة func_get_arg(argument_number)‎: تُعيد المتغير ذو الرقم argument_number سنظهِر -في المثال الآتي- مجموع الأرقام المُمرَّرة إلى الدالة كوسائط بالإضافة إلى عرضها. <?php function sum() { // سنستعمل func_get_args() للحصول على كل المعاملات على شكل مصفوفة $ary = func_get_args(); print_r($ary); echo "<br>"; $sum = 0; // سنستعمل func_num_args للحصول على العدد الكلي للمعاملات for($i = 0; $i < func_num_args(); $i++) { // سنستعمل func_get_arg(index) للحصول على قيمة معامل معيّن echo func_get_arg($i).'<br>'; $sum+= func_get_arg($i); } echo "sum is $sum <br><br>"; } sum(1,2,3,4); sum(23,2343,54,2,1,6); ?> ناتج تنفيذ السكربت السابق هو: Array ( [0] => 1 [1] => 2 [2] => 3 [3] => 4 ) 1 2 3 4 sum is 10 Array ( [0] => 23 [1] => 2343 [2] => 54 [3] => 2 [4] => 1 [5] => 6 ) 23 2343 54 2 1 6 sum is 2429 إعادة القيم من الدوال لاحظ أننا في المثال السابق طبعنا السلسلة النصية مباشرةً، لكن ماذا لو أردنا أن نجعل الدالة تُعيد قيمةً ما؟ نستعمل العبارة البرمجية return لإعادة قيمة من الدالة، وتُسبِّب هذه العبارة بإنهاء تنفيذ الدالة مباشرةً وإعادة القيمة إلى مكان استدعاء الدالة، لنرى مثالًا عن دالة تُعيد مربَّع العدد المُمرَّر إليها: <?php function square ($num) { return $num * $num; } // الناتج هو 16 echo square (4); ?> لاحظ أنك لا تستطيع إعادة أكثر من قيمة من الدالة، لكن يمكنك إعادة مصفوفة التي تؤدي نفس الدور تقريبًا. <?php function powers ($num) { return array ($num, $num * $num, $num * $num * $num); } // الناتج هو: Array ( [0] => 4 [1] => 16 [2] => 64 ) print_r(powers (4)); ?> مجالات تعريف الدوال تستطيع أن تستدعي الدوال المُعرَّفة في الأمثلة السابقة قبل مكان تعريفها، لأن مجالها (scope) هو المجال العام، يجدر بالذكر أنَّك تستطيع تعريف الدوال داخل جملة شرطية (if) لكن لا يمكنك استدعاؤها إن لم يتحقق الشرط كما في المثال الآتي: <?php $str = 'create the function'; global_function(); // لا يمكننا استدعاء الدالة not_global هاهنا، لأن المفسر لا يعتبرها موجودةً إن لم تتحقق الجملة الشرطية الآتية if ($str == 'create the function') { function not_global() { echo 'I don\'t exist until program execution reaches me'; } } // نستطيع الآن استدعاء الدالة not_global بعد اختبار أن السلسلة $str مساوية للقيمة اعلاه، لتجنب إظهار خطأ if ($str == 'create the function') not_global(); function global_function() { echo 'I exist immediately upon program start'; } ?> الأمر سيان لآلية تعريف دالة داخل دالة أخرى: <?php function global_function() { function not_global() { echo 'I don\'t exist until global_function() is called'; } } // لا يمكننا استدعاء not_global هنا، إذ علينا استدعاء global_function أولًا global_function(); // نستطيع الآن استدعاء الدالة not_global، لأن استدعاء global_function قد جعلها متاحةً للمفسر not_global(); ?> المتغيرات في الدوال مجال المتغيرات (variable scope) هو "المجال" الذي يبقى فيه المتغير مُعرَّفًا، أي بكلامٍ آخر، المتغيرات المُعرَّفة داخل الدوال لا يمكن الوصول إليها من خارج تلك الدوال؛ أما المتغيرات المُعرَّفة في المجال العام (global scope) يمكن الوصول إليها من أي جزء من البرنامج في المجال العام؛ ربما أربكك الشرح السابق لكن انظر إلى هذا المثال للتوضيح: <?php // المتغير $a في المجال العام $a = 1; function test() { echo $a; // لا يمكن الوصول إلى المتغير $a لأنه في المجال العام } // لن يظهر أي شيء ﻷن المتغير $a ليس ضمن مجال الدالة test(); // سيظهر الرقم 1، لأن المجال هو العام echo $a; ?> لن تظهر مخرجات عند استدعاء الدالة test()‎ لأن الدالة echo داخلها تُشير إلى نسخة محلية من المتغير ‎$a التي لم تُسنَد لها قيمة في ذاك المجال. يمكن الوصول إلى المتغيرات في المجال العام من داخل الدوال باستخدام الكلمة المحجوزة global كما يلي: <?php $a = 1; $b = 2; function sum (){ // أصبح بإمكاننا الوصول إلى المتغيرين في مجال الدالة الخاص، وتعديل قيمتهما مباشرةً global $a, $b; $b = $a + $b; } sum(); echo $b; ?> نوعٌ أخيرٌ هو المتغيرات الثابتة (static variables) التي يُسمَح بوجودها في مجال الدوال الخاص فقط، لكنها لا تفقد قيمتها عند انتهاء تنفيذ الدالة، انظر إلى المثال الآتي لتوضيح الأمور: <?php function test() { $a = 0; echo $a; $a++; } ?> الدالة السابقة عديمة الفائدة لأنها في كل مرة تُستدعى فيها ستضبط قيمة المتغير ‎$a إلى 0، ثم ستُظهِر قيمة ذاك المتغير (التي هي صفر)، وأخيرًا لن نستفيد من زيادة قيمة المتغير (‎$a++‎) لانتهاء تنفيذ الدالة ولن يعود المتغير ‎$a موجودًا. أما لو عرَّفنا المتغير ‎$a على أنه ثابت، فلن يفقد قيمته بعد انتهاء تنفيذ الدالة: <?php function test() { static $a = 0; echo $a; $a++; } ?> ستتم تهيئة المتغير ‎$a في أول مرة تُستدعى فيها الدالة، وستُطبَع قيمة المتغير وستزداد قيمته في كل مرة تستدعى فيها الدالة مرةً أخرى. <?php function test() { static $a = 0; echo $a; $a++; } //الناتج 0 test(); //الناتج 1 test(); //الناتج 2 test(); ?> ملاحظة: يجب إسناد قيم بسيطة إلى المتغيرات الثابتة عند تعريفها، إذ لا يجوز استعمال التعابير الرياضية أو إسناد القيم المُعادة من الدوال إليها. المعاملات المرجعية رأينا كيف أنَّ جميع الدوال السابقة تعيد قيمة ما بناءً على العمليات التي تُجرى فيها، لكنها لا تستطيع تعديل قيم الوسائط المُمرَّرة إليها، لكن "التمرير بالمرجعية" (pass by reference) يسمح للدوال بتعديل قيم الوسائط مباشرةً، لنأخذ مثالًا بسيطًا يوضِّح هذا الأمر: <?php function test(&$var) { $var++; // لاحظ عدم استعمال عبارة return هنا } $a = 5; test($a); echo $a; // الناتج هو 6 ?> الاختلاف الوحيد الذي يجعل الوسائط تُمرَّر بمرجعيتها هو وضع محرف «&» قبل اسم الوسيط عند تعريف الدالة. الدوال المجهولة الدوال المجهولة (anonymous functions) التي تُعرَف أيضًا بالمصطلح "closures" تسمح بإنشاء دالة ليس لها اسم محدد، وإنما تُسند مباشرةً إلى متغير مَثَلُها كَمَثَلِ أيّةِ عملية إسنادٍ أخرى، وتنتهي عملية الإسناد أيضًا بفاصلة منقوطة؛ هذا مثالٌ عنها: <?php $square = function ($num) { echo $num * $num; }; $square(2); // الناتج 4 $square(15); // الناتج 225 ?> نستطيع أن نُمرِّر إلى الدوال المجهولة أي متغير موجود في مجال المتغيرات الأعلى منها وذلك باستخدام الكلمة المحجوزة use، تأمّل في المثال الآتي وفي تعليقاته: <?php $message = 'hello'; // لم نستعمل الكلمة المفتاحية use هنا $example = function () { echo $message; }; $example(); // لن تَظهَر أيّة قيمة (أو بالتحديد، سيظهر خطأ Notice ﻷن المتغير غير مُعرَّف) // تمرير المتغير $message $example = function () use ($message) { echo $message; }; $example(); // الناتج: hello // القيمة المُمرّرة تؤخذ قبل تعريف الدالة، وليس قبل استدعائها $message = 'world'; $example(); // الناتج: hello // إعادة قيمة المتغير إلى قيمته الأصلية $message = 'hello'; // الوراثة بالمرجعية (inherit by-reference) $example = function () use (&$message) { echo $message; }; $example(); // الناتج: hello // إذا تغيرت قيمة المتغير الآن، فستتأثر الدالة المجهولة بها $message = 'world'; $example(); // الناتج: world // استعمال الوسائط العادية $example = function ($arg) use ($message) { echo $arg . ' ' . $message; }; $example("hello"); // الناتج: hello world ?> تمرين اكتب دالةً تقبل وسيطين أولهما هو طول المستطيل والآخر هو عرض المستطيل، وستعيد هذه الدالة أربع قيم تُمثِّل إحداثيات نقاط التقاء أضلاعه على فرض أنَّ مركزه يقع على مبدأ الإحداثيات. المصادر مقال Functions in php لصاحبه Harish Kumar. مقالتي Functions و Closures لصاحبهما Dayle Rees. صفحات Functions و Anonymous functions و User-defined functions في دليل php وغيرها.
×
×
  • أضف...