البحث في الموقع

واحدة من أبرز قوى ووردبريس مكتباته التي تحتوي على المئات من دوال PHP، وهذه الدوال لديها وظائف متعددة من كتابة روابط التدوينات والمشاركات داخل الإضافة إلى استرجاع اسم مستخدم كاتب التدوينة والاستعلام عنه في قاعدة البيانات. فإذا لم تفهمهم، ستكون العناصر الأساسية للووردبريس مثل the_post غريبة بالنسبة لك، وسيكون الكود التي تكتبه مليئا بالأخطاء والغرابة. وفي نفس الوقت، عند محاولة استعمال المئات من الدوال ذات أسماء غير نظامية يمكن أن يسبب الإرباك لقارئها، لذا سأقوم اليوم بإعطائك مبدأين أساسيين لفهم دوال ووردبريس. هذه المبادئ المنطقية تطبق بشكل واسع (إذا لم يكن عالميا) على مكتبات الدوال، والتي سوف تعطيك نظرة خاطفة على وظيفة دالة ووردبريس معينة. 1. دوال _get تقوم بإرجاع أشياء و دوال _the تطبع أشياءهذا ملخص بسيط لآلية عمل هذين الدالتين: دوال _get تقوم بإرجاع قيمة، مما يسمح لك بالتعامل معها في تعليمات برمجية لاحقة. دوال _the تقوم بطباعة قيمة في صفحة HTML في المكان الذي تم استدعاؤها فيها.ولتوضيح ذلك، لنلق نظرة على الكود المصدري لدالتين، دالة ()the_ID و دالة ()get_the_ID: function get_the_ID() { post = getpost(); return !empty(post ) ? $post->ID : false; } function the_ID() { echo get_the_ID(); }باختصار، إن دالة ()get_the_ID تقوم بإرجاع مُعرف الرقمي للتدوينة، وأما return فهي تعني: قُم بإعطاء القيمة لمن طلبها”، وعندما تحصل على هذه القيمة، يمكنك القيام بأي شيئ بها، مثلا تقوم بضربها في 3، قسمتها على 2، وغيرها حسب البرنامج، (بالمناسبة إذا كنت تتساءل على بقية الشِفرة البرمجية فإن معناها قُم بإرجاع المُعرف، أو قُم بإرجاع false إذا لم تجد التدوينة التي يجب أن تحصل على مُعرفها). لنفترض أنك ترد تعديل صفحة php، لنأخذ ملف index.php للقالب على سبيل المثال، وتريد أن تقوم بطباعة عنوان التدوينة في الصفحة، هذه بعض الخيارات لتفعل ذلك: <h1><?php get_the_title(); ?></h1> <!-- لن يتم طباعة أي شيئ --> <h1><?php the_title(); ?></h1> <!-- طباعة عنوان التدوينة داخل عنصر h1 --> <h1><?php echo get_the_title(); ?></h1> <!-- طباعة عنوان التدوينة داخل عنصر h1 --> <h1><?php echo 'My title: ' . get_the_title(); ?></h1> <!-- طباعة ": My title" وعنوان التدوينة داخل عنصر h1 -->سيكون مفيدا أن تعرف هذه العلاقة التي تُعقد عبر مكتبة دالة ووردبريس مع استثناء أن ()the_post تقوم بشيء مهم لكنها لا تطبع أي شيئ. 2. داخل أو خارج الحلقة التكراريةالحلقة التكرارية هي النواة التقنية الأساسية لووردبريس، بعض الدوال يجب أن يتم استدعاؤها داخل الحلقة التكرارية، وبعضها لا يجب ذلك، فمثلا هذا المثال يوضح لك ما معناه "دالة داخل الحلقة": //خارج الحلقة التكرارية if ( have_posts() ) : while ( have_posts() ) : the_post(); // داخل الحلقة التكرارية، محتويات التدوينة تكون هنا endwhile; endif; // خارج الحلقة التكرارية مرة أخرىللتمييز بين “دالة داخل الحلقة” و “دالة خارج الحلقة”، سنقوم باستخدام التشبيه لتفسير مكان الحلقة داخل الووردبريس: لنتخذ ووردبريس كمصنع سيارات! ووردبريس هو مصنع السيارات. المشاركات والتدوينات هي السيارات. الحلقة التكرارية هي خط التجميع في المصنع.دعونا نشرح العلاقة بين هذه المصطلحات بمزيد من التفاصيل: خط التجميع تدخل داخله أجزاء السيارات خامة لتخرج سيارة كاملة. بنفس الطريقة، الحلقات التكرارية هي مواد المشاركات الخامة (محتوى المشاركة والبيانات التعريفية) تدخل لتخرج صفحة HTML جاهزة.والآن دعونا نشرح الجزء المهم: كل عملية تقوم بتغيير أو تقوم باسترداد معلومات حول السيارات يجب أن تكون في خط التجميع، ويجب أن يتم الإعلان عن أية سيارة ستعمل بطريقة أخرى، فالعمليات التي لا تعمل على السيارات يجب أن لا تكون في خط التجميع. وبالمثل، كل دالة تقوم باسترداد أو تغيير أو عرض لخصائص التدوينة أو المشاركة يجب أن تكون إما داخل الحلقة التكرارية أو يجب أن يتم إعطاء معرف التدوينة أو المشاركة للتعامل معها كمعامل (paramter) للدالة. الدوال التي لن تعمل عن التدوينات/المشاركات لا يجب أن تكون داخل الحلقة التكرارية. عمليا هذا يعني: إن دوال _the وأغلب دوال _get_the تفترض معرفة التدوينة/المشاركة الحالية لذا سيعملون فقط داخل الحلقة التكرارية. أما في خارج الحلقة التكرارية، يجب إخبار دوال _get_the على أية تدوينة ستعمل، أي يجب تمرير معرفة التدوينة. الدوال التي لا تستخدم لاسترداد أو تغيير أو عرض لخصائص التدوينة/المشاركة يجب أن لا يتم استدعاؤها في الحلقة التكرارية.على خط التجميع: دالة _the_title التي تعمل فقط في الحلقات التكرارية. بالنسبة لآلة الطلاء فإنه يجب على الآلة أن تعرف الكثير من المعلومات حول السيارات قبل البدء بطلائه، ولهذا السبب ستجد هذه الآلة في خط التجميع تحصل على معلومات السيارة الحالية بهذه الطريقة و سوف تكون في المكان الصحيح لطلاء السيارة في الوقت المناسب في المصنع. آلة الطلاء في هذه الحالة هي دالة _the_title، فهي تعمل فقط داخل الحلقة التكرارية، وهي تقوم بطلاء الموقع الذي صممه المصنع لعمل عنوان التدوينة الحالية. لتكون قادرا على الإشارة إلى عنوان تدوينة في موقع ربما يمتلك أكثر من 1000 تدوينة ومشاركة يجب أن نعلم أية تدوينة نريدها بالضبط، والدالة التي تقوم ببساطة بطباعة عنوان التدوينة (بدون خيارات أخرى) لن تؤثر كثيرا خارج سياق الصفحة التي صممت من تلك التدوينة. لذلك فالطريقة الوحيدة لتعمل دالة ()the_title هو وضعها داخل الحلقة التكرارية، مثل الآلة الطلاء التي لا يجب أن تكون في بهو المصنع. داخل أو خارج خط التجميع: ()get_the_title، دالة داخل أو خارج الحلقة التكرارية. دعونا نفترض أنك تريد معرفة لون طلاء لسيارة، وهذا الأمر سيكون ذا أهمية داخل خط التجميع، وفي هذه الحالة سوف تقوم ببناء آلة تقوم بإعطائك لون السيارة التي تمر من أمامها. لكن قد ترغب أيضا بإرسال فريق مراقبة الجودة إلى منطقة الشحن للحصول على لون سيارة معينة، لذلك سوف يحتاج الفريق إلى معرفة أية سيارة سيقومون بتفقدها، وإلا لن يستطيعوا إخبارك بأي شيئ. بكلمات أخرى، يمكنك فعل هذا داخل أو خارج خط التجميع، لكن إذا كنت في الخارج، يجب عليك أن تقوم بخطوة إضافية لتحديد أية سيارة أنت مهتم بها. فمثلا دالة ()get_the_title التي تعمل داخل الحلقة التكرارية بدون إدخال معطيات، أو خارج الحلقة مع إدخال مُعرف التدوينة، كما يلي: get_the_title(); // يتم استدعاؤها داخل الحلقة التكرارية، تقوم بإعطائك عنوان التدوينة الحالية. // استدعاؤها خارج الحلقة لن يفيد. get_the_title(‘121’); // داخل أو خارج الحلقة التكرارية، تقوم بإعطائك عنوان التدوينة مع المُعرف 121.خارج خط التجميع: ()wp_enqueue_script، دالة خارج الحلقة التكرارية. حتى الآن تحدثنا كثيرا حول خط التجميع في المصنع، ومع ذلك، قد يحتوي المصنع أيضا على مستودع ومكتب الاستقبال وقسم الشحن والمكاتب الإدارية وغيرها. ولا أي إدارة من هذه الإدارات تحتاج إلى معرفة أية سيارة يتم العمل عليه الآن، وأنت بالتأكيد لا تريد وضع المكاتب الإدارية مع خط التجميع. وهذا هو نفس الحال مع دالة ()wp_enqueue_script التي لا تفيد داخل الحلقة التكرارية، فهذه الدالة تستعمل لمعرفة أن صفحة ما تم صنعها بواسطة مصدر خاص للووردبريس أو لا. ملفات جافاسكريبت ليست جزءً من التدوينة تم صنعه بواسطة الحلقة التكرارية، فهو لا يتفاعل مع التدوينات بنفس الطريقة التي لا يتفاعل فيها مكتب الحسابات مع السيارات، فعندما توجد شحنة سيارات جاهزة، سوف يتأكد هذا القسم من أن الشحنة لديها فاتورة ملتصقة بها، لكنه بالتأكيد لا يعقل أن يتم إلصاق الفاتورة على أرض المصنع. لذلك لا تقم باستخدام دالة ()wp_enqueue_script في الحلقة التكرارية، وسيكون أفضل لو وضعتها في ملف functions.php للقالب أو للإضافة. قم بالبرمجةحسنا حاولت تسهيل هذا الأمر عن طريق استعمال جميع معرفتي عن مصانع السيارات، و من الأرجح أنني قمت بتوسيع منطقة التشبيهات داخل دماغي، لكن أرجو أنني علمتكم بعض المفاتيح الرئيسية التي سوف تمكنك من الدخول إلى عالم دوال ووردبريس وأنت مطمئن، وإذا كان لديك أي سؤال أو تعليق، فيسرنا أن نسمعه في التعليقات في الأسفل، وإذا أعجبك هذا المقال، أرجو أن تقوم بمشاركتها مع أصدقاءك. ترجمة -وبتصرف- للمقال: Two Key Principles for Understanding WordPress Functions لصاحبه Fred Meyer. حقوق الصورة البارزة: Business vector designed by Freepik.

أعلم أنَّه ليس من السهل الاعتراف بالأخطاء التي تقوم بها، لكن الخطأ هو جزءٌ رئيسي من كل عمليات التعليم، بدءًا من التعلم كيفية المشي إلى تعلم لغة برمجة جديدة مثل بايثون. هذه قائمة بثلاثة أخطاء التي وقعتُ فيها أثناء تعلمي لبايثون، عرضتها هنا لكي يحاول مبرمجو بايثون الجدد تفاديها وعدم الوقوع فيها، وهذه الأخطاء أدت إلى حدوث مشاكل كبيرة أخذت من وقتي ساعات حتى حللتها. الخطأ الأول: استخدام أنواع البيانات القابلة للتغير كوسائط افتراضية عند تعريف الدالة لنقل أنَّ لديك دالة صغيرة التي تبحث عن روابط في الصفحة الحالية وتستطيع إضافتها إلى قائمة (list) معيّنة. def search_for_links(page, add_to=[]): new_links = page.search_for_links() add_to.extend(new_links) return add_to لا يبدو أنَّ هنالك أيّ خطأ في الدالة السابقة، وهذا صحيح، فهي تعمل لكن هنالك مشاكل فيها؛ فلو مررنا قائمةً (list) إلى المعامل add_to فستعمل كما يجب، لكن ماذا يحدث لو تركنا القيمة الافتراضية دون تعديل؟ جرِّب تنفيذ الشيفرة الآتية: def fn(var1, var2=[]): var2.append(var1) print var2 fn(3) fn(4) fn(5) ستتوقع رؤية الناتج الآتي: [3] [4] [5] لكنك ستُفاجأ بالناتج الآتي: [3] [3, 4] [3, 4, 5] لماذا؟! يمكنك أن تستنتج أن القائمة (list) نفسها ستستعمل في كل مرة، فعندما نكتب دالة مثل الدالة السابقة في بايثون فسيتم تهيئة القائمة (list) كجزءٍ من تعريف الدالة، أي أنها لن تُهيّئ كل مرة تُستدعى فيها الدالة، وهذا يعني أنَّ الدالة ستحتفظ بكائن القائمة نفسه مرارًا وتكرارًا، ما لم تُحدِّد قيمةً أخرى له: fn(3, [4]) الناتج: [4, 3] الناتج يماثل ما قد توقعناه. الطريقة الصحيحة لفعل ذلك هي: def fn(var1, var2=None): if not var2: var2 = [] var2.append(var1) لنعد كتابة الدالة السابقة: def search_for_links(page, add_to=None): if not add_to: add_to = [] new_links = page.search_for_links() add_to.extend(new_links) return add_to نقلنا عملية التهيئة من مكان تعريف الدالة إلى داخلها مما يعني أنَّ عملية التهيئة ستتم في كل مرة تُشغَّل فيها الدالة. لاحظ أنَّ ذلك ليس ضروريًا إذا كنتَ تستعمل أنواع بيانات غير قابلة للتعديل مثل tuple أو string أو int. وهذا يعني أنَّك تستطيع تعريف دالة كما في الدالة الآتية دون إمكانية حدوث أخطاء غير متوقعة: def func(message="my message"): print message الخطأ الثاني: استخدام أنواع البيانات القابلة للتعديل كمتغيرات في الأصناف هذا الخطأ شبيهٌ كثيرًا بالخطأ السابق. تمعّن في الشيفرة الآتية: class URLCatcher(object): urls = [] def add_url(self, url): self.urls.append(url) الشيفرة السابقة تبدو طبيعية جدًا، فلدينا كائن لتخزين روابط URL، وعند استدعائنا للدالة add_url فسنمرر إليها رابط URL لتخزِّنه، صحيح؟ لنجرِّبها: a = URLCatcher() a.add_url('http://www.google.') b = URLCatcher() b.add_url('http://www.bbc.co.') الناتج: b.urls ['http://www.google.com', 'http://www.bbc.co.uk'] a.urls ['http://www.google.com', 'http://www.bbc.co.uk'] ما هذا؟! لم نتوقع ذلك. إذ أنشأنا كائنين منفصلين a و b، وأسندنا رابطًا للكائن a مختلفًا عن رابط الكائن b، فكيف امتلك كلا الكائنين الرابطين نفسهما؟ اتضح أنَّ هذه المشكلة شبيهة جدًا بالمشكلة في المثال الأول، فقائمة (list) عناوين URL قد تمت تهيئتها عند تعريف الصنف (class)، وبالتالي أمست جميع الكائنات المُنشَأة من ذاك الصنف تستعمل القائمة نفسها. هنالك بعض الحالات التي نستفيد فيها من هذه الميزة، لكنها ستضرك في أغلبية الأوقات، فلو أردتَ تخزين بيانات كل كائن على حدة فيمكنك تعديل الشيفرة لتصبح كما يلي: class URLCatcher(object): def __init__(self): self.urls = [] def add_url(self, url): self.urls.append(url) أصبحت قائمة urls تُهيّئ عند إنشاء الكائن، وعندما نُنشِئ كائنين فستُهيّئ قائمتان منفصلتان. الخطأ الثالث: عملية إسناد قيم إلى نوع بيانات قابل للتعديل هذا الخطأ أربكني لفترة حتى فهمته، دعنا نستعمل نوع بيانات قابل للتعديل مثل dict: a = {'1': "one", '2': 'two'} لنفترض أننا نريد أخذ قيمة المتغير a واستعمالها في مكانٍ آخر دون تعديل القيمة الأصلية: b = a b['3'] = 'three' أليس هذا بسيطًا؟ لننظر الآن إلى القيمة المخزّنة في المتغير a التي لم نُعدِّلها قط: {'1': "one", '2': 'two', '3': 'three'} ماذا؟! كيف ستبدو قيمة المتغير b إذًا؟ {'1': "one", '2': 'two', '3': 'three'} دعنا نعود خطوةً إلى الوراء وننظر ماذا يحدث لو استعملنا أنواع البيانات غير القابلة للتعديل، مثل tuple: c = (2, 3) d = c d = (4, 5) قيمة c هي: (2, 3) بينما قيمة d هي: (4, 5) لقد جرى كل شيءٍ على ما يرام، لذا ماذا حدث في مثالنا؟ عند استخدام أنواع البيانات القابلة للتعديل فسنحصل على شيءٍ شبيهٍ بالمؤشرات (pointers) في لغة C، فعندما قلنا أنَّ b = a في الشيفرة السابقة فهذا يعني أنَّ المتغير b أصبح يُشير إلى a، وكلا المتغيرين يشير إلى نفس الكائن في ذاكرة بايثون؟ هل هذا مألوف لديك؟ ذلك لأن هذه المشكلة شبيهة بالمشاكل السابقة، وكنتُ أنوي تسمية هذا الدرس باسم «المشاكل التي تحدث مع أنواع البيانات القابلة للتعديل». هل يحدث الأمر نفسه مع القوائم (list)؟ نعم. وكيف سنلتف على المشكلة؟ حسنًا، يجب أن نكتب الشيفرة الآتية التي تنسخ القائمة: b = a[:] السطر السابق سيؤدي إلى نسخ مرجعية كل عنصر من عناصر القائمة ووضعه في قائمة جديدة، لكن لنأخذ حِذرنا فإذا كان نوع بيانات أحد الكائنات الموجودة في القائمة قابلًا للتعديل فسيؤدي ذلك إلى الحصول إلى مرجعية لتلك الكائنات بدلًا من نسخها. تخيل وجود قائمة على قطعة من الورق، ففي المثال الأصلي كان ينظر الشخص A والشخص B إلى الورقة نفسها، فلو عدّل شخصٌ ما القائمةَ فسيرى كلا الشخصين التعديلات التي أجريت على القائمة، وعندما نسخنا المرجعيات فأصبح لكل شخصٍ قائمته الخاصة به، لكن لنفترض أنَّ تلك القائمة تحتوي على أماكن يمكن البحث فيها عن طعام، فلو كانت «الثلاجة» موجودة في القائمة فحتى لو نسخها الشخص A و B فما تزال تشير إلى الثلاجة نفسها؛ فلو أتى الشخص A وعدّل محتويات الثلاثة (لنفترض أنه أكل جميع الحلويات فيها) فسيلاحظ الشخص B أن الحلويات قد اختفت من الثلاثة. ولا توجد طريقة سهلة للالتفاف على هذه المشكلة، وهذا أمرٌ مهمٌ عليك تذكره عندما تبرمج لكي تكتب شيفرتك بطريقة لا تسبِّب أيّة مشاكل. تعمل أنواع dict بنفس الطريقة، ويمكنك إنشاء نسخة كاملة باستعمال الدالة copy()‎: b = a.copy() أكرِّر أنَّ ذلك سيُنشِئ متغيرًا جديدًا من نوع dict يُشير إلى نفس العناصر الموجودة في المتغير الأصلي، وبالتالي لو كان لدينا قائمتان متماثلتين وعدّلنا كائنًا قابلًا للتعديل مُشار إليه عبر مفتاح موجود في المتغير a فيمكن معرفة تلك التعديلات من داخل المتغير b. الإشكاليات التي تواجهنا مع أنواع البيانات القابلة للتعديل تكون نتيجةً لمرونة تلك الأنواع، حيث لا تُشكِّل أيٌّ مما سبق مشكلةً حقيقة، وإنما هي أمور ضرورية يجب أخذها بالحسبان لتنجب المشاكل. وعمليات النسخ الكاملة التي ذكرناها آنفًا لن تكون ضروريةً في 99% من الحالات، أي يجب تعديل برنامجك لكي لا يحتاج إلى استخدام تلك النسخ من الأساس. ترجمة –وبتصرّف– للمقال ‎3 mistakes to avoid when learning to code in Python لصاحبه Pete Savage