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

هل سبق لك أن وجدت على موقع ووردبريس الخاص بك رابطا أو مجموعة من الروابط التي تؤدي إلى خطأ 404 (“404” error) سيء السمعة؟ إن كان الأمر كذلك حاول أن لا تنزعج فحدوث هذا الأمر وارد جدا، كل ما في الأمر أنك وجدت رابطا لا يؤدي إلى المكان المُفترض به. تتميز الروابط المعطلة المعروفة أيضا باسم الروابط الميتة (dead links) بانتشارها الكبير وتكرر حدوثها، يعمل متصفحك من خلال الخطأ 404 (404 error) على إخبارك بأن الرابط المعني يؤدي إلى مكان لا يوجد فيه شيء. يعتبر الحفاظ على فاعلية روابط موقعك أمرا حساسا كونها تعتبر جزءا أساسيا من مصداقية موقعك، قد يسعدك سماع أن إصلاح الروابط المعطلة يعد أمرا غايةً في السهولة، بعد قراءة هذا الموضوع ستتعرف عن كثب عن ماهية الروابط المعطلة، أخذ نظرة حول بعض أفضل أدوات فحص الروابط (link-checking) ثم تتعلّم كيفية القيام بإصلاح وحذف هذه الروابط باستعمال ملحق Broken Link Checker. ما هي الروابط المعطلة؟ على عكس الروابط التي تشتغل بشكل عادي، تقوم الروابط المعطلة بالتوجيه إلى الخطأ 404 عند الضغط عليها، ما يحدث غالبا بسبب محاولة تحويل الزوار إلى صفحة مفقودة أو إلى مصدر غير موجود. توجد الروابط المعطلة كنتيجة لمجموعة من الأسباب، أحد أكثرها حدوثا هو الرّابط URL بالتوجيه إلى نطاق لم يعد موجودا، يتوفر على إعدادات جدار ناري غير قياسية، تعرض للقرصنة أو فشل في الحفاظ على استضافة مناسبة. عدا هذا، قد تنتج الروابط المعطلة أحيانا عن الكتابة غير الصحيحة لعناوين URL الخاصة بإعادة التوجيه (redirecting URLs). فعلى سبيل المثال لدى إضافة رابط إلى تدوينة جديدة وإذا لم تُضف //:http إليها (كما في الصّورة التّالية) فإنّه سينتج عنه رابط ميّت. أين يتجلى بالضبط الخطأ في القيام بذلك؟ توجد في الواقع مجموعة كبيرة من الأخطاء. عند القيام بكتابة عنوان URL الخاص بجوجل (Google URL) بهذه الطريقة يتم دفع المتصفح إلى البحث على: google.com داخل موقعك (شيء ما من قبيل http://www.yoursite.com/google.com). سواء كنت تقوم بصياغة (creating) أو تثبيت (fixing) رابط ما تذكر دوما الإشارة إلى عنوان URL كاملا، الأمر الذي يمكنك القيام به من خلال إضافة "http://www" إلى الصفحة المعنية التي تريد إعادة التوجيه إليها (http://www.google.com/maps على سبيل المثال). حلول فحص الروابط على ووردبريس بعد أن أصبح بإمكانك التعرف على الروابط المعطلة، عليك الآن بتحديدها ثم القيام بالتعديل عليها أو حذفها. رغم أن القيام بتحديد أماكن الروابط المعطلة قد يبدو أمرا سهلا إلا أنه أصعب مرحلة في هذه العملية، تتغير طريقة إيجادك للروابط المعطلة على موقعك بتغير وتيرة نشرك وكثافة محتوى موقعك، إن كنت تملك موقعا صغير الحجم نسبيا بعدد روابط قليل قد تتمكن من القيام بتجريبها يدويا مرة في الشهر وإصلاح المعطلة منها. هل يمكنك تخيل استعمال هذه العملية اليدوية مع موقع كبير الحجم؟ من أجل سلامتك العقلية لا تقم بذلك. رغم أن تكبد عناء القيام بتجربة كل الروابط على موقع كبير الحجم قد يساعد في صقل الشخصية إلا أن القيام باستعمال أداة فحص الروابط يسمح لك بتقليص ساعات أو حتى أيام من العمل إلى مجرد بضع ثوان، فضلا عن أن استعمال البرنامج المناسب يساعد على توفير الوقت، يوجد أيضا عدد كبير من الخيارات لفحص الروابط على ووردبريس، يمكن الحصول على أغلبها بشكل مجاني. يجدر بك بطبيعة الحال القيام بالموازنة بين إيجابيات وسلبيات الأدوات التي تضعها بعين الاعتبار قبل القيام بالاختيار، إن كنت نصبت مسبقا أدوات مشرفي المواقع الخاصة بجوجل (Webmaster Tools) فأنت على أتم الاستعداد لقيام المفهرسات التلقائية (crawlers) بفحص موقعك، أما إن كنت تفضل بدأ بحثك الخاص فعليك باستعمال بعض المواقع مثل: iWebTool Broken Link Checker و Online Broken Link Checker للقيام بفحص سريع لموقعك. Broken Link Checker رغم أنه ليس الخيار الوحيد إلا أن Broken Link Checker يعتبر ملحقا جيدا للقيام بفحص روابط ووردبريس. يُقَدِّرُ الكثيرون بخصوص هذا الملحق روتينَ قيامه بالفحوصات، طريقةَ تنظيمه للروابط المعطلة في جدول سهل الاستعمال، اكتشاف الصور الناقصة فضلا عن معلمةِ مقاطع فيديو يوتيوب الناقصة. حتى وإن كان هذا الملحق لا يتوافق مع غيره من الملحقات ويسبب بعض البطء في الاستعمال ما يؤدي إلى شكاوى المستعملين إلا أنه تم تنصيبه على 000 400 موقع إلى حدود الساعة. تجدر الإشارة إلى أن الهدف من هذا المقال ليس القيام بالترويج لملحق ما على حساب الآخر، يمكن أن تجد عددً كبيرًا من الملحقات على الصفحة الرسمية للموقع WordPress directory، بعد قراءتك لهذا الموضوع قد تقرر أن ملحقا آخر هو الحل الأنسب لمتطلباتك، بما أن التعليمات التالية لفحص الروابط لا يمكن شرحها إلا على ملحق واحد سنقوم باستعمال Broken Link Checker كمثال تطبيقي، كما أنه المفضل لدي. كيفية القيام بإصلاح أو حذف الروابط المعطلة باستعمال Broken Link Checker بمجرد القيام بتنصيب وتفعيل Broken Link Checker سيقوم بمباشرة بفحص موقعك، يمكنك التّحقّق من تقدم البحث من خلال الذهاب إلى: Settings > Link Checker على لوحة التحكم الخاصة بووردبريس: يمكنك القيام بتغيير عدد من الإعدادات من على نفس الصفحة، بما فيها التالي: تغيير وتيرة فحص الروابط الموجودة (يتم فحص الروابط الجديدة بشكل مباشر). إعداد التنبيه بوجود الروابط المعطلة باستعمال رسالة إلكترونية. استعمال تنسيق خاص للروابط المعطلة و/أو المحذوفة. منع محركات البحث من اتباع الروابط المعطلة. يمكن لك استعمال الإعدادات المتقدمة من خلال تبويب Advanced . عند استعدادك للقيام بإصلاح بعض الروابط، قم بالضغط على رابط Found (x) broken links أعلى نافذة الملحق. يدل العدد المشار إليه على تعداد الروابط المعطلة لديك، سيتم تقديم قائمة روابط لك على الشكل التالي: يوجد الكثير من المعلومات لاستيعابها هنا، من الجيد أن الواجهة تتميز بكونها سهلة الاستعمال، من اليسار إلى اليمين نجد: عنوان URL الخاص بالرابط المعطل، حالة الرابط المعطل، النص المنشور الخاص بالرابط المعطل ثم المصدر (أي الصفحة، المنشور أو التعليق الذي يوجد الرابط المعطل فيه). إن التعامل مع الروابط المعطلة أمر في غاية السهولة ، فقط قم بوضع مؤشر الفأرة (دون الحاجة إلى الضغط) على الرابط لإظهار خياراتك: تشرح الخيارات الظاهرة هنا نفسها بنفسها: Edit URL: التعديل على عنوان URL أي القيام بتصحيحه. Unlink: القيام بإلغاء الرابط (مع الإبقاء على النص المنشور). Not broken: القيام بتعليم الرابط على أنه غير معطل (بعد الضغط على هذه الخاصية سيختفي الرابط). Dismiss: إخفاء الرابط (سيتم وضع الرابط في صنف Dismissed (الروابط التي يتم تجاهلها)) Recheck: القيام بإعادة فحص الرابط إن كنت تعتقد أنه يعمل الآن. هذا كل ما في الأمر، تجوّل في الروابط واتخذ الخيارات التي تراها مناسبة. هنالك المزيد مما يمكن لهذا الملحق القيام به، لكن استنادا إلى مبدأ باريتو (Pareto Principle) أود أن أشارك معكم نصيحة واحدة فعالة. من خلال تجربتي، تأتي معظم الروابط المعطلة من قسم التعليقات، غالبا على شكل روابط لمواقع المعلقين تم إدخالها بشكل خاطئ أو فقط لم تعد موجودة. عادة ما سترغب بالاهتمام بشكل أكبر لإلغاء، إصلاح وحذف الروابط المعطلة الموجودة في المنشورات أو الصفحات عوض القيام بالتنقل بين العشرات (أو حتى المئات) من تلك الموجودة في التعليقات. لذا عوض تضيع الوقت في التعامل مع كل من هذه الأخيرة على حدة يمكنك القيام باستعمال خاصية التصفية الخاصة بـ Broken Link Checker للقيام بإلغاء كل هذه الروابط (Unlink) دفعة واحدة. قم أولا بالذهاب إلى: Tools > Broken Links في لوحة تحكم ووردبريس ثم اضغط على زر Search: قم بتحديد Broken من قائمة الاختيارات المنسدلة Link status و Links used in Comments من قائمة الاختيارات المنسدلة Link type، ثم قم بالضغط على زر Search Links ما سيعطيك قائمة بالروابط المعطلة المتواجدة في قسم التعليقات فقط. إن كنت مثلي فستحصل على الكثير من هذه الروابط، قبل حذفها كلها دفعة واحدة قم بالضغط على تبويب Screen Options وقم بالرفع من عدد Show on screen ليساوي أو يتعدى عدد الروابط المعطلة: قم بالضغط على Apply عندما تكون مستعدا، قد تستغرق العملية ثانية أو ثانيتين إن قمت باختيار عدد كبير (استغرق الأمر ثانيتين عند اختيار 260). لم يتبقى إلا القيام بفك هذه الروابط المعطلة، فقط قم بتحديد كل المنشورات من خلال الضغط على مربع الاختيار الرئيسي (‘master 'checkbox ) أعلى القائمة. قم بتحديد Unlink من قائمة الاختيارات المنسدلة Bulk Actions، ستظهر لك علبة تأكيد قم بالموافقة عليها. بعد ذلك عليك بالانتظار قد يستغرق الأمر بعض الثّواني لأن على الملحق القيام ببعض العمل، بمجرد الانتهاء سيتم تقديم شاشة تأكيد بسيطة. تم الحذف بنجاح. خلاصة إن كنت قد تابعت حتى هذه النقطة فستكون تعرفت على كيفية تحديد، تعديل أو حذف الروابط المعطلة. في حين توجد العديد من الخيارات لإيجاد الروابط المعطلة، تعتبر الملحقات التي تخول برمجة عمليات الفحص أفضل من مواقع فحص الروابط التي تتطلب منك القيام بالعملية بشكل يدوي في كل مرّة. تتميز الفحوصات الأوتوماتيكية والمبرمجة بكونها أكثر حيوية، ذلك أن الروابط تتعطل عندما لا تتوقع ذلك وهو غالبا ما يحدث. من المُؤكّد أن لا شيء أفضل من استثمار بعض الوقت في إعداد ملحق أوتوماتيكي وعدم الحاجة للتفكير في هذا الأمر بعد ذلك إلى أن تتلقى رسالة تنبيه إلكترونية تشير إلى عطل في أحد الروابط. حتى وإن لم يكن الحفاظ على عمل روابطك سببا في إغداق المديح عليك، سبق لنا جميعا التواجد في مواقع حيث لا يمكن الولوج إلى روابط تتضمن معلومات حيوية، فلنحاول أن نكون أفضل من هذا. تذكر دوما أن الوقت والجهد اللذان تستثمرس في الحفاظ على عمل روابطك ليس مجرد تحسين لموقعك بل يتعدى ذلك ليكون عملية وضع الأساس لبناء تجربة مستخدم قَيِّمَةٍ. ترجمة -وبتصرّف- للمقال: HOW TO FIX (OR REMOVE) BROKEN LINKS ON YOUR WORDPRESS WEBSITE لصاحبه: TOM EWER.

سنلقي في هذا الدرس نظرةً إلى آلية التعامل مع الأخطاء و الإشارات أثناء تنفيذ السكربتات. يُقاس الفرق بين البرمجة الجيدة والتعيسة عادةً بمدة استقرار البرنامج ومرونته، أي قابلية تعامل البرنامج مع الحالات التي لا تسير فيها الأمور على ما يرام. حالة الخروج تتذكر من دروسنا السابقة أنَّ كل برنامج مكتوب بطريقة جيدة سيُعيد حالة خروج عندما ينتهي تنفيذه؛ فإذا انتهى تنفيذ البرنامج بنجاح، فستكون حالة الخروج مساويةً للصفر، وإن كانت حالة الخروج مساوية لقيمة مختلفة عن الصفر، فهذا يدلّ أنَّ البرنامج قد واجهة مشكلةً ما منعته من إتمام مهمته. من المهم جدًا التحقق من حالة خروج البرامج التي تستدعيها في سكربتاتك، ومن المهم أيضًا أن تُعيد سكربتاتك حالة خروج مفيدة عندما تنتهي. لقد مرّ عليّ مدير أنظمة يونكس قد كتب سكربتًا لنظام إنتاجي يحتوي على السطرين الآتيين: # Example of a really bad idea cd $some_directory rm * هذه طريقة سيئة جدًا لكتابة البرامج، لأنها تعمل بشكلٍ جيد لو لم يحدث أيّ خطأ. فالسطر الأول ينقل مجلد العمل الحالي إلى المسار الموجود في المتغير ‎$some_directory ثم يحذف جميع الملفات الموجودة في ذاك المجلد؛ وهذه هي الحالة الطبيعية لتنفيذ السكربت، لكن ماذا يحدث لو لم يكن المسار الموجود في المتغير ‎$some_directory موجودًا؟ سيفشل -في هذه الحالة- تنفيذ الأمر cd ثم سيُنفِّذ السكربتُ الأمرَ rm في مجلد العمل الحالي، وهنا ستقع الكارثة! بالمناسبة، واجه سكربت مدير الأنظمة البائس هذه المشكلة ودمَّر جزءًا كبيرًا مهمًا من النظام الإنتاجي؛ لا تدع ذلك يحدث لك! مشكلة السكربت السابق أنَّه لم يتحقق من حالة خروج الأمر cd قبل الاستمرار وتنفيذ الأمر rm. التحقق من حالة الخروج هنالك عدِّة طرائق تستطيع فيها الحصول على حالة الخروج والتصرف وفقًا لها. أول طريقة هي معاينة محتويات متغير البيئة ‎$?‎، الذي يحتوي على حالة خروج آخر أمر مُنفَّذ. يمكنك رؤية ذلك في المثال الآتي: $ true; echo $? 0 $ false; echo $? 1 تذكَّر أنَّ الأمرَين true و false لا يفعلان شيئًا سوى الانتهاء بحالة خروج تساوي 0 و 1 على التوالي وبالترتيب. وعبر استخدامهما سنرى كيف يُعيد المتغير ‎$?‎ حالة الخروج لآخر أمر مُنفَّذ. نستطيع كتابة السكربت بهذه الطريقة بعد التحقق من حالة الخروج: # Check the exit status cd $some_directory if [ "$?" = "0" ]; then rm * else echo "Cannot change directory!" 1>&2 exit 1 fi تفحصنا محتوى الأمر cd، وإن كان لا يساوي الصفر، فسيطبع رسالة خطأ في مجرى الخطأ القياسي (standard error stream) وسينتهي تنفيذه مع ضبط حالة الخروج إلى 1. صحيح أنَّ النسخة السابقة تقدِّم حلًا لمشكلتنا، إلا أنَّ هنالك طرائق أفضل ستقلل مقدار الكتابة التي نحتاج لها. سنستخدم في المثال الآتي العبارة الشرطية if مباشرةً، لأنَّها تحقق من حالة خروج الأمر الذي يليها ثم تتصرف وفقًا لذلك. يمكننا إعادة صياغة السكربت كالآتي: # A better way if cd $some_directory; then rm * else echo "Could not change directory! Aborting." 1>&2 exit 1 fi تحققنا هنا أنَّ تنفيذ الأمر cd قد نجح، وبعد ذلك سينُفّذ الأمر rm؛ أو ستظهر رسالة خطأ فيما عدا ذلك وينتهي البرنامج بحالة خروج تساوي 1، مما يشير إلى حدوث مشكلة أثناء التنفيذ. دالة خروج عند حدوث خطأ لمّا كنّا نتحقق من الأخطاء مرارًا وتكرارًا في برامجنا، فمن المعقول أن نكتب دالةً لإظهار الأخطاء، مما يوفِّر علينا بعض الكتابة ويُنمّي إحساس الكسل لدينا :-) . # An error exit function error_exit() { echo "$1" 1>&2 exit 1 } # Using error_exit if cd $some_directory; then rm * else error_exit "Cannot change directory! Aborting." fi معاملات التحكم: "و" AND وَ "أو" OR يمكننا تبسيط السكربت كثيرًا باستخدام معاملَي التحكم "AND" و "OR"، وسأقتبس الفقرة الآتية من صفحة دليل bash لشرح آلية عملهما: سنستعمل الأمرَين true و false مجددًا لكي نشاهد آلية التعامل مع AND و OR عمليًا: $ true || echo "echo executed" $ false || echo "echo executed" echo executed $ true && echo "echo executed" echo executed $ false && echo "echo executed" $ باستخدام هذه التقنية، يمكننا إعادة كتابة نسخة مختصرة أكثر من السكربت السابق: # Simplest of all cd $some_directory || error_exit "Cannot change directory! Aborting" rm * إن لم يكن إنهاء البرنامج مطلوبًا، فيمكننا كتابة السكربت بالصيغة الآتية: # Another way to do it if exiting is not desired cd $some_directory && rm * صحيحٌ أننا أخذنا جميع الاحتياطات الممكنة في مثال cd، إلا أنني أود أن أشير أنَّ الشيفرة يمكن أن تتعرض للمشاكل البرمجية الشائعة، خصوصًا إذا كُتِبَ اسم المتغير الذي يحتوي على مسار المجلد الذي نريد حذف محتوياته بشكلٍ خاطئ. ففي هذه الحالة ستضع الصَدَفة قيمةً فارغةً بدلًا من اسم المتغير وسينتج تنفيذ الأمر cd، لكنه سينتقل إلى مجلد المنزل للمستخدم الحالي، ثم سيحذف كل ما فيه! تحسين دالة الخروج عند حدوث خطأ هنالك عددٌ من التحسينات التي نستطيع إجراءها على الدالة error_exit، أود أن أضع اسم البرنامج في رسالة الخطأ كي أوضِّح من أين تأتي رسالة الخطأ؛ وذلك مهمٌ خصوصًا في السكربتات الكبيرة والمعقدة التي تُستدعى فيها سكربتات داخل سكربتات… لاحظ أيضًا تضمين متغير البيئة LINENO الذي سيساعد في تحديد السطر الذي حدثت فيه المشكلة. #!/bin/bash # A slicker error handling routine # I put a variable in my scripts named PROGNAME which # holds the name of the program being run. You can get this # value from the first item on the command line ($0). PROGNAME=$(basename $0) error_exit() { # ---------------------------------------------------------------- # Function for exit due to fatal program error # Accepts 1 argument: # string containing descriptive error message # ---------------------------------------------------------------- echo "${PROGNAME}: ${1:-"Unknown Error"}" 1>&2 exit 1 } # Example call of the error_exit function. Note the inclusion # of the LINENO environment variable. It contains the current # line number. echo "Example of error with line number and message" error_exit "$LINENO: An error has occurred." استخدام الحاضنات ({}) داخل الدالة error_exit هو مثالٌ عن "توسعة المعاملات" (parameter expansion)، يمكنك وضع حاضنات حول اسم المتغير (كما في {‎${PROGNAME) إذا أردت عزل المتغير عمّا حوله من نصوص. يُفضِّل البعض وضع الحاضنات حول كل متغير، وهذا الأمر منوطٌ بك. الشيء الآخر الذي أريد الإشارة إليه هو {"‎${1:- "Unknown Error الذي يعني أنَّه لو لم يكن المعامل 1 (أي ‎$1) مُعرَّفًا، فضع السلسلة النصية "Unknown Error" مكانه. يمكن إجراء الكثير من عمليات معالجة النصوص باستخدام توسعة المعاملات. الإشارات Signals لا تستطيع اعتبار أنَّ الأخطاء هي المُسبِّب الوحيد لإنهاء البرنامج على نحوٍ غير متوقع، فعليك أن تحتاط من الإشارات (signals) أيضًا. ليكن لديك المثال الآتي: #!/bin/bash echo "this script will endlessly loop until you stop it" while true; do : # Do nothing done بعد أن تُشغِّل هذا السكربت، فسيبدو وكأنَّه علّق، لكنه -مثل أغلبية البرامج التي تُعلِّق- قد دخل في حلقة تكرار ولم يخرج منها. فالسكربت في مثالنا ينتظر أن يُعيد الأمر true حالة خروج لا تساوي الصفر، وهذا لن يحدث أبدًا. وسيستمر تنفيذ السكربت إلى أن تُرسِل الصَدَفة bash إشارةً له لإيقافه. يمكنك إرسال إشارة بالضغط على Ctrl+c التي تُسمى SIGINT (مختصرة من SIGnal INTerrupt). إنهاء البرامج التي تستقبل إشارات بشكل سليم حسنًا، يمكن أن تأتي إشارة وتؤدي إلى إنهاء تنفيذ السكربت، لكن لماذا نهتم بذلك؟ لا يؤدي إنهاء السكربت عبر الإشارات في العديد من الحالات إلى مشاكل، لكنها تحتاج إلى معالجة في بعض الحالات. لننظر إلى مثالٍ آخر: #!/bin/bash # Program to print a text file with headers and footers TEMP_FILE=/tmp/printfile.txt pr $1 > $TEMP_FILE echo -n "Print file? [y/n]: " read if [ "$REPLY" = "y" ]; then lpr $TEMP_FILE fi يُعالِج السكربت السابق ملفًا نصيًا مُمَرَّرًا كوسيط في سطر الأوامر عبر الأمر pr الذي يُخزِّن الناتج في ملف مؤقت (temporary file)، ثم سيسأل المستخدم عمّا إذا كان يريد طباعة الملف، فلو وافق المستخدم عبر كتابة y فسيُمرَّر الملف المؤقت إلى الأمر lpr للطباعة (يمكنك وضع الأمر less بدلًا من lpr إذا لم تكن لديك طابعة موصولة بحاسوبك). عليّ أن أعترف لك أنَّ السكربت السابق فيه العديد من المشاكل التصميمية؛ وعلى الرغم من استخدامه لاسم الملف المُمرَّر عبر سطر الأوامر، لكنه لا يتحقق أنَّ القيمة فارغة، ولا يتحقق إن كان الملف موجودًا فعلًا. لكن الفكرة التي أريد التركيز عليها هي أنَّه عندما ينتهي تنفيذ السكربت، فسيُبقي خلفه ملفًا مؤقتًا. من المستحسن أن نحذف الملف المؤقت ‎$TEMP_FILE عند انتهاء تنفيذ السكربت، ويتم هذا بسهولة بإضافة السطر الآتي في نهاية السكربت: rm $TEMP_FILE قد تظن أننا حللنا المشكلة، لكن ماذا سيحدث لو ضغط المستخدم على Ctrl+c عندما تظهر الرسالة "Print file? [y/n]:‎" سينتهي تنفيذ السكربت عند الأمر read ولن يُنفَّذ الأمر rm أبدًا. سنحتاج إذًا إلى طريقة لمعالجة الإشارات مثل SIGINT عندما يضغط المستخدم على Ctrl+c. لحسن الحظ، توفِّر bash طريقةً لتنفيذ الأوامر فيما إذا استقبِلَت إشارةٌ ما. الأمر trap يسمح لك الأمر trap بتنفيذ أمر عندما يستقبل سكربتك إشارةً. يعمل هذا الأمر كالآتي: trap arg signals حيث signals هي قائمة بالإشارات التي تريد «اعتراضها» أو معالجتها، و arg هو الأمر التي سيُنفَّذ عندما تُستقبَل واحدة من الإشارات المُحدَّدة. يمكننا التعامل مع الإشارات في سكربت الطباعة السابق كما يلي: #!/bin/bash # Program to print a text file with headers and footers TEMP_FILE=/tmp/printfile.txt trap "rm $TEMP_FILE; exit" SIGHUP SIGINT SIGTERM pr $1 > $TEMP_FILE echo -n "Print file? [y/n]: " read if [ "$REPLY" = "y" ]; then lpr $TEMP_FILE fi rm $TEMP_FILE أضفنا الأمر trap الذي سيُنفِّذ الأمر rm $TEMP_FILE إذا استقبل السكربت إحدى الإشارات المذكورة، التي هي أكثر الإشارات التي ستواجهها، لكن هنالك المزيد منها التي تستطيع ذكرها أيضًا. انظر ناتج الأمر trap -l لرؤية القائمة الكاملة. يمكنك أيضًا ذكر الإشارات بأرقامها بدلًا من أسمائها. الإشارة 9 التي لا ترحم! هنالك إشارة لا تستطيع التعامل معها داخل السكربت: إشارة SIGKILL أو الإشارة رقم 9. ستُنهي النواة أيّ عملية تُرسَل لها هذه الإشارة مباشرةً دون العودة إلى البرنامج أو السماح له بإجراء أيّ عملية لمعالجة الإشارة. ولأنه هذه الإشارة تُنهي البرامج التي تُعلِّق أو لا تستجيب، فربما تظن أنَّها أسهل طريقة لإنهاء برنامج ما. وقد ترى الأمر الآتي عندما يأتي ذكر الإشارة SIGKILL: kill -9 وعلى الرغم من أنَّ هذه الإشارة تُتِمُّ عملها بسرعة وسهولة، لكن تذكَّر أنَّ البرنامج لن يستطيع معالجة هذه الإشارة، ولا بأس في ذلك في بعض الحالات؛ لكن قد يُسبِّب مشاكل في بعضها الآخر. حيث تُنشِئ بعض البرامج المعقدة (وحتى بعض البرامج غير المعقدة) ملفات اسمها lock files لمنع تشغيل عدِّة نسخ من نفس البرنامج في نفس الوقت. فعندما تُرسَل إشارة SIGKILL إلى برنامج يستخدم lock files، فلن يكون لديه فرصة لحذف ذاك الملف؛ وسيؤدي وجود ذاك الملف إلى منع تشغيل البرنامج إلى أن يُحذَف يدويًا. استعمل SIGKILL كملاذٍ أخيرٍ لك. دالة clean_up صحيحٌ أنَّ الأمر trap حلّ المشكلة، لكننا لاحظنا بعض المحدوديات؛ خصوصًا أنَّه لا يقبل إلا سلسلةً نصيةً وحيدةً تحتوي الأمر الذي سيُنفَّذ عندما تُستقبَل الإشارة. يمكنك الالتفاف على هذه المحدودية بوضع ; بين عدِّة أوامر، إلا أنَّ هذه الطريقة بشعة المظهر. فمن الأفضل إنشاء دالة ستُستدعى عندما ينتهي تنفيذ السكربت. أُسميّ هذه الدالة عادةً clean_up. #!/bin/bash # Program to print a text file with headers and footers TEMP_FILE=/tmp/printfile.txt clean_up() { # Perform program exit housekeeping rm $TEMP_FILE exit } trap clean_up SIGHUP SIGINT SIGTERM pr $1 > $TEMP_FILE echo -n "Print file? [y/n]: " read if [ "$REPLY" = "y" ]; then lpr $TEMP_FILE fi clean_up يمكن استعمال دالة clean_up في البُنى التي تهتم بمعالجة الأخطاء. فيجب على أيّة حال أن "تُنظِّف" ما خلّفه السكربت بعد انتهائه (لأي سببٍ كان). هذه هي النسخة النهائية من برنامجنا التي حسّنّا فيها معالجة الأخطاء والإشارات: #!/bin/bash # Program to print a text file with headers and footers # Usage: printfile file # Create a temporary file name that gives preference # to the user's local tmp directory and has a name # that is resistant to "temp race attacks" if [ -d "~/tmp" ]; then TEMP_DIR=~/tmp else TEMP_DIR=/tmp fi TEMP_FILE=$TEMP_DIR/printfile.$$.$RANDOM PROGNAME=$(basename $0) usage() { # Display usage message on standard error echo "Usage: $PROGNAME file" 1>&2 } clean_up() { # Perform program exit housekeeping # Optionally accepts an exit status rm -f $TEMP_FILE exit $1 } error_exit() { # Display error message and exit echo "${PROGNAME}: ${1:-"Unknown Error"}" 1>&2 clean_up 1 } trap clean_up SIGHUP SIGINT SIGTERM if [ $# != "1" ]; then usage error_exit "one file to print must be specified" fi if [ ! -f "$1" ]; then error_exit "file $1 cannot be read" fi pr $1 > $TEMP_FILE || error_exit "cannot format file" echo -n "Print file? [y/n]: " read if [ "$REPLY" = "y" ]; then lpr $TEMP_FILE || error_exit "cannot print file" fi clean_up الطريقة المثالية لإنشاء ملفات مؤقتة هنالك عدِّة إجراءات يمكننا اتخاذها لتأمين الملف المؤقت الذي استخدمه السكربت. من تقاليد نظام يونكس استخدام المجلد ‎/tmp لتخزين الملفات المؤقتة التي تستعملها البرامج. يمكن للجميع الكتابة إلى ذاك المجلد، وقد يُسبِّب ذلك لك بعض المخاوف الأمنية. تجنّب كتابة الملفات في مجلد ‎/tmp إن كان ذلك ممكنًا. التقنية المُستحسنة هي كتابة الملفات إلى مجلد محلي مثل ‎~/tmp (أي مجلد tmp الموجود في مجلد المنزل للمستخدم المُنفِّذ للسكربت)؛ وإن كان لا بُد، فعليك اتخاذ بعض الخطوات للتأكد أن أسماء الملفات المُخزَّنة في مجلد ‎‎/tmp غير متوقعة؛ حيث تسمح أسماء الملفات المتوقعة للمخترقين أن يُنشِئوا وصلات رمزية إلى ملفات أخرى التي يريدون منك أن تكتب فوقها. الاسم الجيد للملف المؤقت هو الاسم الذي يسمح لك بمعرفة مَن الذي كتب الملف، ولكنه ليس متوقعًا بشكلٍ كامل. استخدمنا السطر الآتي في السكربت أعلاه لإنشاء اسم الملف المؤقت ‎$TEMP_FILE: TEMP_FILE=$TEMP_DIR/printfile.$$.$RANDOM سيحتوي المتغير ‎$TEMP_DIR على ‎‎/tmp أو ‎~/tmp اعتمادًا على توفر المجلد ~/tmp، ومن الشائع تضمين اسم البرنامج في اسم الملف، وهذا هو سبب وضعنا للكلمة "printfile". ثم استخدمنا متغير الصَدَفة $$ لتضمين مُعرِّف العملية (PID) الخاص بالبرنامج. وهذا سيُحدِّد تمامًا ما هي العملية المسؤولة عن الملف. وبالطبع لا نستطيع أن نعتبر أنَّ رقم العملية كافٍ لجعل اسم الملف غير متوقع؛ لهذا أضفنا متغير الصَدَفة ‎$RANDOM لتضمين رقم عشوائي في اسم الملف. وبالآلية السابقة، أنشأنا اسمًا لملفٍ مؤقتٍ سهلُ التعرف وغير متوقع. خاتمة حسنًا، لقد أنهينا هذه السلسلة، أرجو أن تكون قد وجدتها مفيدةً ومسلية في آن واحد. وأنصحك بإكمال مسيرتك في سطر الأوامر وسكربتات الصَدَفة بقراءة كتاب سطر أوامر لينُكس لمترجمه عبد اللطيف ايمش. ترجمة -وبتصرّف- للمقالين Errors And Signals And Traps (Oh My!) - Part 1 و Errors And Signals And Traps (Oh, My!) - Part 2 لصاحبهما William Shotts.

برمجية ووردبريس هي واحدة من أشهر أنظمة إدارة المحتوى مفتوحة المصدر في العالم، وصحيحٌ أنَّ غرضها الأساسي هو إنشاء مدونات، لكنها تطورت على مرّ السنين لتصبح منصةً مرنةً لإنشاء مواقع الويب، ولا نستطيع أن ننكر مدى ثباتها وموثوقيتها التي تطورت خلال خمسة عشر عامًا، لكن ما تزال بعض المشكلات تظهر بين الفينة والأخرى. إذا حاولت فتح موقعك الذي يعتمد على ووردبريس ورأيت رسالةً تُشير إلى خطأ في قواعد البيانات “خطأ في إنشاء اتصال بقاعدة البيانات” (Error Establishing Database Connection)، فمن المرجح أن يكون السبب بين القائمة الآتية: انهارت قاعدة البيانات، ربما بسبب نفاد الذاكرة المتاحة للخادوم معلومات الوصول إلى قاعدة البيانات الموجودة في ضبط ووردبريس غير صحيحة حدث ضرر في جداول قاعدة بيانات ووردبريس لنناقش المشاكل السابقة كلًّا على حدة لنعرف إن كان هو السبب فيما أصاب موقعك، مع ذكر طريقة حلها. المتطلبات المسبقة يفترض هذا الدرس: أنَّك تستعمل ووردبريس على خادوم يمكنك الوصول إلى سطر أوامر وتستطيع تشغيل الأوامر فيه بامتيازات الجذر عبر الأداة sudo. تعمل قاعدة البيانات على خادوم ووردبريس نفسه (وهذا شائع في مواقع ووردبريس المستضافة ذاتيًا، لكنه ليس شائعًا في مواقع ووردبريس المستضافة على استضافة مشتركة). أنَّك تعرف اسم المستخدم الذي يملك وصولًا إلى قاعدة البيانات مع كلمة مروره، واسم قاعدة البيانات الخاصة بورردبريس. يجب أن توفِّر هذه المعلومات عند ضبطك لبرمجية ووردبريس ضبطًا مبدئيًا. الخطوة الأولى: التحقق من الذاكرة المتاحة على الخادوم أوّل خطوة لمعرفة سبب المشكلة هي تسجيل الدخول إلى الخادوم لمعرفة إذا كان سليمًا وأنَّ خدمة MySQL تعمل دون مشاكل. سجِّل دخولك إلى الخادوم عبر SSH، وتذكر أن تضع اسم المستخدم واسم النطاق الخاصين بك في الأمر الآتي: ssh sammy@your_server_ip ملاحظة: إذا كنتَ متأكدًا أنَّ معلومات الاتصال الخاصة بك صحيحة لكنك تواجه مشاكل في تسجيل الدخول، فقد يكون السبب هو نفاد الذاكرة في خادومك أو أنَّه تحت حِملٍ شديد؛ وقد يكون ذلك بسبب كمية كبيرة من البيانات المُرسَلة إلى موقعك، وهذا يُفسِّر سبب الخطأ الذي حدث في ووردبريس… قد تحتاج إلى إعادة تشغيل خادومك قبل أن تتمكن من تسجيل الدخول إليه. بعد أن سجلنا دخولنا بنجاح إلى الخادوم، فيمكننا التأكد أنَّ قواعد MySQL تعمل دون مشاكل: sudo netstat -plt يعرض الأمر netstat معلوماتٍ حول الاتصالات الشبكية في نظامنا، وطلبنا من الأمر السابق أسماء البرامج ‎-p التي تستمع إلى الاتصالات ‎-l على مقابس TCP ‏‎-t؛ عليك الآن البحث عن السطر الذي تُذكر خدمة mysqld فيه: Active Internet connections (only servers) Proto Recv-Q Send-Q Local Address Foreign Address State PID/Program name tcp 0 0 localhost:mysql *:* LISTEN 1958/mysqld tcp 0 0 *:ssh *:* LISTEN 2205/sshd tcp 0 0 localhost:smtp *:* LISTEN 2361/master tcp6 0 0 [::]:http [::]:* LISTEN 16091/apache2 tcp6 0 0 [::]:ssh [::]:* LISTEN 2205/sshd tcp6 0 0 ip6-localhost:smtp [::]:* LISTEN 2361/master إذا كانت مخرجات الأمر السابق عندك مشابهةً لما سبق، فهذا يعني أنَّ خادوم MySQL يعمل ويستمع إلى الاتصالات القادمة؛ أما إذا لم ترَ خدمة MySQL مذكورةً في الناتج، فجرِّب تشغيلها يدويًا، وذلك باستعمال أمرٍ شبيهٍ بالأمر الآتي: sudo systemctl start mysql لاحظ أنَّ بعض توزيعات لينكس (وأشهرها CentOS) تستعمل mysqld بدلًا من mysql للإشارة إلى اسم الخدمة؛ لذا ضع الكلمة الملائمة لنظامك الذي تستعمله. يجب أن تبدأ خدمة MySQL الآن، وأعد تشغيل أمر netstat السابق للتأكد من ذلك، وابحث عن السطر الذي يحتوي على اسم خدمة MySQL. تحتاج قواعد بيانات MySQL وبرمجية ووردبريس إلى قدرٍ لا بأس به من الذاكرة لكي تعمل عملًا سليمًا؛ وإذا انهارت قواعد البيانات بسبب نفاد الذاكرة، فيجب أن نرى دليلًا على ذلك في سجل الأخطاء. لنلقِ نظرة: zgrep -a "allocate memory" /var/log/mysql/error.log* الأمر zgrep سيبحث في ملفات السجل، بما فيها ملفات السجل القديمة والتي ضُغِطَت لتوفير المساحة التخزينية؛ وحددنا في الأمر السابق أننا نبحث في أي سطر يحتوي على العبارة allocate memory في أي ملف error.log*‎ موجود في مجلد ‎/var/log/mysql/‎: 2017-04-11T17:38:22.604644Z 0 [ERROR] InnoDB: Cannot allocate memory for the buffer pool إذا رأيتَ سطرًا أو أكثر يشبه السطر السابق فهذا يعني أنَّ خادوم MySQL قد انهار بسبب عدم كفاية الذاكرة؛ وإذا وجدتَ سطرًا وحيدًا فقط فهذا يعني أنَّ الانهيار عَرَضي بسبب كمية مؤقتة كبيرة من البيانات، أما إذا كانت هنالك عدِّة أسطر تحوي الخطأ نفسه، فهذا يعني أنَّ الذاكرة الحالية لا تكفي خادومك. في كلا الحالتين السابقتين، الحل العملي لهذه المشكلة هو الانتقال إلى خادومٍ تتوافر فيه ذاكرة أكثر، والأمر بسيطٌ جدًا إذا كان خادومك مستضافًا على خدمةٍ سحابية، إذ تستطيع ترقية الخادوم دون انقطاع الخدمة لوقتٍ طويل. إذا لم تجد أيّة مخرجات بعد تنفيذ أمر zgrep السابق، فهذا يعني أنَّ الذاكرة تكفي خادومك، وإن بقي موقعك يُظهِر رسالة الخطأ، فانتقل إلى الخطوة التالية التي نلقي فيها نظرةً على ضبط ووردبريس ونتأكد أنَّ معلومات الدخول إلى قاعدة MySQL صحيحة. الخطوة الثانية: التحقق من معلومات الدخول إلى قاعدة البيانات إذا نقلتَ موقع ووردبريس إلى خادوم جديد أو إلى استضافة أخرى، فقد تحتاج إلى تحديث معلومات الاتصال بقاعدة البيانات، وهذه المعلومات مخزنة في ملف PHP على الخادوم باسم wp-config.php. لنعثر بدايةً على ملف wp-config.php: sudo find / -name "wp-config.php" الأمر السابق يبحث في كل النظام (بدءًا من المجلد الجذر /) عن أي ملف باسم wp-config.php، ثم سيعرض المسار الكامل للملف إن عُثِرَ عليه: /var/www/html/wp-config.php ملاحظة: إذا كنتَ تعلم مكان تثبيت برمجية ووردبريس، فيمكنك الانتقال إلى مسار تثبيتها مباشرةً وتخطي الخطوة السابقة لأنها تستهلك بعض الوقت. استعمل محرِّرك النصي المفضل لتعديل ملف الضبط، سنستعمل محرر nano في الأمر الآتي: sudo nano /var/www/html/wp-config.php ستشاهد أمامك ملفًا نصيًا مليئًا بخيارات الضبط مع بعض التعليقات التي تشرحها. لكنك ستجد قسمًا (في بداية الملف عادةً) فيه معلومات الاتصال إلى قاعدة البيانات: /** The name of the database for WordPress */ define('DB_NAME', 'database_name'); /** MySQL database username */ define('DB_USER', 'database_username'); /** MySQL database password */ define('DB_PASSWORD', 'database_password'); تأكد أن القيم الثلاث السابقة صحيحة بناءً على معلومات الاتصال المسجلة عندك؛ وإذا لم تكن صحيحةً فحدِّثها وفقًا لما تراه مناسبًا، ثم احفظ الملف واخرج من المحرر (بضغط Ctrl+o للحفظ ثم Ctrl+x للخروج، وذلك إذا كنتَ تستعمل محرر nano). حتى لو بدت لك معلومات الاتصال بقاعدة البيانات صحيحةً، فمن المفيد تجربة الاتصال إلى قاعدة البيانات من سطر الأوامر ليطمئن قلبك. انسخ المعلومات المذكورة في ملف الضبط السابق واستعملها في هذا الأمر: mysqlshow -u database_username -p عندما يُطلَب منك إدخال كلمة مرور فألصقها واضغط على زر Enter، وإن ظهر لك خطأ Access denied فهذا يعني أنَّ اسم المستخدم أو كلمة المرور خطأ، وإذا كانا صحيحين فسيعرض الأمر mysqlshow جميع قواعد البيانات التي يملك المستخدم وصولًا إليها: +--------------------+ | Databases | +--------------------+ | information_schema | | database_name | +--------------------+ تأكد أنَّ اسم إحدى قواعد البيانات يطابق تمامًا الاسم المذكور في ملف ضبط ووردبريس؛ وعندئذٍ ستعلم أنَّ ضبطك صحيح وأنَّ ووردبريس يجب أن تكون قادرةً على الاتصال بقاعدة البيانات بنجاح. ادخل إلى موقعك مجددًا لعل رسالة الخطأ تختفي، وإن بقيت موجودةً فلنحاول إصلاح قاعدة البيانات. الخطوة الثالثة: إصلاح قاعدة بيانات ووردبريس قد يحدث عطب في قاعدة بيانات ووردبريس في بعض الأحيان بسبب فشل الترقية أو انهيار قاعدة البيانات أو مشكلة في إحدى الإضافات، وقد تظهر هذه المشكلة على أنها خطأ في الاتصال بقاعدة البيانات، لذا إذا لم تكن المشكلة في خادوم MySQL ولا في ملف الضبط، فجرِّب إصلاح قاعدة البيانات. توفر ووردبريس أداةً مبنيةً داخلها لإصلاح قاعدة البيانات، وهي معطلة افتراضيًا لعدم وجود قيود مفروضة على من يستطيع الوصول إليها مما قد يسبب مشكلةً أمنيةً، لذا سنفعِّل هذه الميزة، ثم نُشغِّل أداة الإصلاح، ثم نعطلها. افتح ملف wp-config.php مرةً أخرى: sudo nano /var/www/html/wp-config.php ألصق ما يلي في سطرٍ جديد: define('WP_ALLOW_REPAIR', true); سيؤدي السطر السابق إلى تفعيل ميزة إصلاح قاعدة البيانات. احفظ الملف وأغلق المحرر النصي، وافتح العنوان الآتي في متصفحك، وتذكر أن تضع اسم النطاق الخاص بموقعك أو عنوان IP التابع له: http://www.example.com/wp-admin/maint/repair.php يجب أن تظهر صفحة الإصلاح: اضغط على زر «Repair Database» ويجب أن تنتقل إلى صفحة النتائج التي تستطع أن ترى فيها التحققات والإصلاحات التي تجريها ووردبريس في الوقت الحقيقي: بعد انتهاء هذه العملية، احرص على تعديل ملف wp-config.php وحذف السطر الذي أضفناه إليه آنفًا. هل لاحظت أيّة إصلاحات أجرتها الأداة؟ جرِّب الدخول إلى موقعك مجددًا وانظر هل اختفت رسالة الخطأ. إذا ظهرت مشاكل لا يمكن حلها فربما ستحتاج إلى استعادة قاعدة البيانات من نسخة احتياطية إذا توافرت عندك. إذا لم يُعثَر على مشاكل في قاعدة البيانات ولم تستطع أن تعرف ما أصل المشكلة، فمن المحتمل أن هنالك مشاكل أخرى لم تنتبه إليها. الخلاصة أغلبية أخطاء “خطأ في إنشاء اتصال بقاعدة البيانات” يمكن حلّها عبر اتباع الخطوات السابقة، لكن مع ذلك هنالك أخطاء أكثر تعقيدًا قد تظهر على شكل خطأ في الاتصال بقاعدة البيانات؛ لذا سأعرض لك قائمةً بالمقالات التي تساعدك في تَتَبُع وإصلاح مسبب المشكلة: أحد المسببات الشائعة للتراسل الكبير لموقع ووردبريس (وبالتالي انخفاض الأداء وحدوث أخطاء) هو هجمات brute-force ، وبالتالي يجب اتخاذ إجراءات للتخفيف من تأثيرها. يمكنك توفير بعض موارد الخادوم باستعمال التخزين المؤقت لصفحات ووردبريس؛ وهنالك عدد كبير من إضافات التخزين المؤقت البسيطة المتوافرة لها. ترجمة –وبتصرّف– للمقال How To Debug the Wordpress “Error Establishing Database Connection”‎ لصاحبه Brian Boucheron. حقوق الصورة البارزة محفوظة لـ Freepik

تظهر بعض الأخطاء الشائعة بكثرة عند محاولة رفع ملفات إلى خادوم باستخدام بروتوكول FTP، وتذهب الأسباب إلى أبعد من أن تكون نتيجة خطأ في إدخال عنوان الخادوم، اسم المستخدم، كلمة المرور أو رقم المنفذ. هذا المقال موجّه إليك إن كنت تستطيع الاتصال بـ FTP محليًّا فقط، أو كنت تواجه مشكلة انقطاع الاتصال باستمرار، حيث سنلقي نظرة على الطرق المتوفرة لإصلاح أكثر 3 أخطاء شيوعًا. 1. لا يمكن إجراء الاتصال إطلاقا قد يحصل أن يبقى الاتصال غير ممكنًا حتّى بعد التحقق من أنّ بيانات الاتصال صحيحة، وتكون الخطوة الأولى باتجاه الحل هي التحقّق من نمط الإرسال في الإعدادات، هل هو سلبي passive أم نشط active؟ سنستخدم FileZilla كمثال لتوضيح الفكرة، فبعد فتح البرنامج نضغط على "تحرير Edit" في القائمة العُلويّة، ونختار "إعدادات Settings". في النافذة التي ستظهر لنا، نقوم باختيار "FTP" ضِمن "الاتصال Connection" وذلك في شجرة الخيارات التي تظهر جانبًا، للتحقّق فيما إذا كان الاتصال في النمط passive أو active، فإن كان النمط سلبيّ passive (وهو الافتراضي) فقم بتغييره إلى النمط النشط active، أو العكس كما في الصورة: لنختر الآن العنصر المسمّى "النمط السلبي Passive mode" في القائمة، ونقوم بتفعيل خيار "رجوع كامل إلى النمط النشط Fall back to active mode"، فإن كان الخيار نشطًا، قم بتفعيل الخيار الثاني بدلًا عنه "استخدام عنوان IP الخارجي بدلًا من ذلك Use the server’s external IP address instead"، وتأكّد من ألّا تقوم بتفعيل الخيار الثاني المذكور إلّا إذا اخترت نمط الاتصال السلبيّ passive سابقًا، تبيّن الصورة التالية الخطوات المذكورة: لا تنس الضغط على زر "حسنًا OK" في الزاوية اليمنى السفلية لحفظ تغييراتك، ومن ثم حاول الاتصال بالخادوم مجدّدًا. 2. خطأ "العديد من الاتصالات Too Many Connections" إن كنت قادرًا على الاتصال بالخادوم دون مشاكل، لكنّ الاتصال يستمر بالانقطاع عند محاولة رفع أو تنزيل ملفّات، فقد يكون هناك عدة أسباب لذلك، ومنها ظهور خطأ يخبرك بوجود العديد من الاتصالات، فهو يرجّح غالبًا أنّ إعدادات خادومك لا تسمح إلا بعدد قليل من الاتصالات عبر FTP، وقبل أن نبادر إلى إصلاح الخطأ، تأكّد بأنّك قمت بإنهاء اتصالك الحالي عبر FTP قبل المتابعة وإلا ستمضي ساعات في محاولة إصلاحه. وبهدف التوضيح، سنستخدم لوحة تحكّم الخادوم WHM كمثال حول إصلاح هذه المشكلة. فبعد تسجيل الدخول في WHM، نتوجه من الصفحة الرئيسية إلى صفحة "إعدادات الخدمة Service Configuration"، ومنها إلى "إعدادات خادوم إف تي بي FTP Server Configuration"، حيث سنرفع عدد الاتصالات المسموحة في حقل الحدّ الأعلى للاتصالات وحقل الحدّ الأعلى للاتصالات لكل IP، وستكون الأمور بخير طالما أنّ هذين الرقمين أعلى مما كانوا عليه من قبل. عادة ما أقوم بوضع الرقم 100 في كل حقل لأكون بأمان، ولا تنس أن تضغط على "حفظ Save" في أسفل الصفحة لتخزين التغييرات. يتطلب دخول لوحة تحكم WHM أن تملك صلاحية مدير النظام root، فإن لم تملك هذه الصلاحية قم بالاتصال بمزوّد خدمة الاستضافة واشرح المشكلة لهم لمساعدتك. حان الوقت الآن لإيقاف الاتصالات الحاليّة يدويًا، وسنوضّح كيف يتم ذلك عبر لوحة تحكّم العميل cPanel. فبعد تسجيل الدخول إلى الّلوحة، نتوجّه إلى قسم الملفّات ونضغط زر "إدارة جلسات إف تي بي FTP Session Control". سنقوم في الصفحة التي تظهر لنا، بإغلاق جميع الاتصالات المعروضة بالضغط على زرّ × الأحمر الموجود على جانب كل سطر، وبعد الانتهاء نضغط زرّ إعادة التحميل reload لتحديث القائمة والتأكّد من عدم تبقّي أيّة اتصالات. هنا يكمن الجزء الذي يكون من المهمّ فيه أن تكون قد أنهيت اتصالك الحالي في البرنامج الذي تستخدمه للاتصال عبر FTP كما أشرت سابقًا، فلو لم تقم بذلك سلفًا، ستجد المزيد والمزيد من الاتصالات التي تظهر لديك في القائمة عند كل تحديث لها، الأمر الذي قد يضيع لك الكثير من الوقت قبل أن تكتشف السبب. وحتى لا تتفاجأ، فمن الطبيعيّ أن تجد العديد من الاتصالات التي ستضطر لإنهائها، خصوصًا إن كنت تواجه هذه المشكلة تحديدًا، لذا تأكّد من أنّك قمت بإنهاء جميع الاتصالات حتى آخر واحد منها. لنعد الآن إلى FileZilla ونضغط على "تحرير Edit" في القائمة، ومن ثمّ "إعدادات Settings" وأخيرًا نختار عنصر القائمة المسمّى "عمليات الإرسال Transfers"، ونتأكد من أنّ قيمة "أقصى عمليّات متزامنة للإرسال Maximum simultaneous transfers" ليست كبيرة وعادة ما تكون هذه القيمة إما 1 أو 2. لا تنس أن تقوم بحفظ أيّ تغييرات قد أجريتها أيضًا. يجب أن تكون الآن قادرًا على إجراء اتصال وتحميل أو تنزيل بعض الملفّات، ولكن إن بقيت تعاني من مشاكل، فعد مجدّدًا إلى "عمليات الإرسال Transfers" وتأكّد فيما إذا كان الحدّ من عمليات التحميل والرفع المتزامنة إلى حوالي 5 أو 10 سيساعد في حلّ المشكلة، فهو يساعد في بعض الحالات النادرة رغم أنّه غير ضروري عادةً. 3. خطأ في إرسال ملف أثناء رفعه إن كنت تستلم رسالة خطأ غريبة عادة عند محاولة رفع الملفات، فإنّ سببها معظم الوقت هو الوصول إلى الحدّ الأقصى لحجم الملف المسموح رفعه. لحسن الحظ فإنّ من السهل تصحيح هذه المشكلة إن كنت تملك صلاحية مدير للنظام ولكن إن لم تكن فسيتوجّب عليك الاتصال بمزوّد خدمة الاستضافة لإجراء التصحيح. لنرى كيف يتم التصحيح باستخدام لوحة تحكم WHM. نتوجّه أولًا إلى "إعدادات الخادوم Server Configuration" في القائمة ثمّ إلى صفحة "محرّر إعدادات بي اتش بي PHP Configuration Editor". بعدها نختار "النمط المتقدّم Advanced mode" في أعلى الصفحة لتظهر جميع الإعدادات المتاحة، كما في الصورة: سنجد إلى الأسفل قليلًا خيارين هما "post_max_size" و "upload_max_filesize"، سنقوم بزيادة الرقم الموجود في الحقلين إلى أيّ قيمة نرغب بها ولكن تذكّر فقط بأنه في حال وضع قيمة كبيرة جدًا فسنخاطر بأن نتجاوز مساحة التخزين المخصصة من مزوّد خدمة الاستضافة. أستخدم عادة القيمة 3000M (التي تعني 3000 ميغابايت) وأجدها مناسبة لي، لكنّي أعلم مسبقًا بأنّي أملك مساحة التخزين الكافية لها، لذا فإن استخدام القيمة 120M - 320M تبدو عمليّة أكثر بشكل عام. لا تنس ضغط زرّ "حفظ Save" في أسفل الصفحة عند الانتهاء، ومن ثمّ حاول مجدّدًا رفع ملفّاتك ويفترض أن تتم العمليّة بنجاح، ولكن في حال لم يحدث ذلك، فتأكّد مجدّدًا من أنّ حجم كلّ ملف من الملفات التي تحاول رفعها أقل من القيمة التي اخترتها. الخلاصة من المحتمل جدًّا أن تضطرّ إلى اتباع الخطوات الثلاثة السابقة للوصول إلى النتيجة المرجوّة، ولكن إن استمرت المشكلة، فإنّ هذا هو الوقت المناسب للاتصال بمزوّد خدمة الاستضافة لمساعدتك، فقد تكون المشكلة متعلّقة بالخادوم لديهم. من المهمّ جدًّا في حال رفع ملفّات موقع ويب، التحقّق فيما إذا كان الموقع يعمل عند طلبه عبر شبكة الإنترنت، فإن لم يكن كذلك فسيكون لديك مشاكل أخرى يتطلب معالجتها أولًا. فيما عدا ما ذكرناه، فقد أصبح لديك ما تحتاجه لنقل ملفّاتك عبر FTP دون أخطاء. ترجمة -وبتصرّف- للمقال 3Common WordPress FTP Upload Errors and How to Fix Them لصاحبته Jenni McKinnon.