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

تعلمنا في الدرسين السابقين كيف نوصِّف الأشخاص والمنظمات، وسنتناول في هذا الدرس الأحداث والمراجعات توصيف الأحداث تحدث بعض المناسبات في أوقاتٍ معيّنة، ألن يكون من الجميل أن تستطيع إخبار محركات البحث متى ستقع تلك المناسبات تحديدًا؟ هنالك طريقةٌ لفعل هذا في HTML5. لنبدأ بإلقاء نظرة على الجدول الزمني الخاص بالمحاضرات والكلمات التي سألقيها. <article> <h1>Google Developer Day 2009</h1> <img width="300" height="200" src="http://diveintohtml5.org/examples/gdd-2009-prague-pilgrim.jpg" alt="[Mark Pilgrim at podium]"> <p> Google Developer Days are a chance to learn about Google developer products from the engineers who built them. This one-day conference includes seminars and “office hours” on web technologies like Google Maps, OpenSocial, Android, AJAX APIs, Chrome, and Google Web Toolkit. </p> <p> <time datetime="2009-11-06T08:30+01:00">2009 November 6, 8:30</time> – <time datetime="2009-11-06T20:30+01:00">20:30</time> </p> <p> Congress Center<br> 5th května 65<br> 140 21 Praha 4<br> Czech Republic </p> <p><a href="http://code.google.com/intl/cs/events/developerday/2009/home.html">GDD/Prague home page</a></p> </article> جميع المعلومات التي تخص الحدث موجودةٌ في عنصر <article>، وهو المكان الذي نريد وضع خاصيتي itemtype و itemscope فيه. <article itemscope itemtype="http://schema.org/Event"> رابط URL لنوع الاصطلاحات Event هو http://schema.org/Event، الذي يحتوي أيضًا على جدولٍ يصف خاصيات هذه النوع من الاصطلاحات؛ التي ذكرتُ بعضها في هذا الجدول. الخاصية الشرح name اسم الحدث url رابط لصفحة تفاصيل الحدث location الموقع الذي سيُجرى فيه الحدث الذي يمكن أن يُمثَّل بنوع الاصطلاحات PostalAddress أو Place description وصفٌ قصيرٌ للحدث startDate تاريخ بدء فعاليات الحدث بصيغة ISO endDate تاريخ انتهاء فعاليات الحدث بصيغة ISO duration المدة الزمنية لفعاليات الحدث بصيغة ISO image صورة تعبيرية متعلقة بالحدث اسم الحدث موجودٌ في عنصر <h1>، ووفقًا للنموذج الهيكلي للبيانات الوصفية في HTML5، عنصر <h1> ليس له معالجةٌ خاصةٌ، وستكون قيمة خاصية البيانات الوصفية هي المحتوى النصي للعنصر <h1>، لذا كل ما نحتاج له هو إضافة الخاصية itemprop لكي نُصرِّح أنَّ هذا العنصر يحتوي على اسم الحدث. <h1 itemprop="name">Google Developer Day 2009</h1 نقول بالعربية: «اسم هذا الحدث هو Google Developer Day 2009». يحتوي الحدث على صورة، التي يمكن توصيفها باستخدام الخاصية image، وكما تتوقع، تُعرَض الصورةُ عبر عنصر <img>، وكما في خاصية image في نوع الاصطلاحات Person، الصورة في نوع الاصطلاحات Event هي رابط URL، ولأن النموذج الهيكلي للبيانات الوصفية يقول أنَّ قيمة الخاصية الموجودة في العنصر <img> هي قيمة خاصية src، فكل ما علينا فعله هو إضافة الخاصية itemprop إلى العنصر <img>. <img itemprop="image" width="300" height="200" src="http://diveintohtml5.org/examples/gdd-2009-prague-pilgrim.jpg" alt="[Mark Pilgrim at podium]"> نقول بالعربية: «إحدى الصور المتعلقة بهذا الحدث موجودٌ في رابط http://diveintohtml5.org/examples/gdd-2009-prague-pilgrim.jpg» يأتي بعد الصورة وصفٌ مختصرٌ للحدث، وهو فقرةٌ نصيةٌ من الكلام العادي. <p itemprop="description">Google Developer Days are a chance to learn about Google developer products from the engineers who built them. This one-day conference includes seminars and “office hours” on web technologies like Google Maps, OpenSocial, Android, AJAX APIs, Chrome, and Google Web Toolkit.</p> المعلومة التي تلي الوصف جديدةٌ علينا. تقع الأحداث عمومًا في تواريخ مُحدَّدة وتبدأ وتنتهي في أوقاتٍ معيّنة. يجب أن نضع الأوقات والتواريخ في HTML5 في عنصر <time>، وهذا ما فعلناه. لذا سيُصبِح السؤال الآن: كيف سنتمكن من إضافة خاصيات البيانات الوصفية إلى عناصر <time> السابقة؟ بالنظر مرةً أخرى إلى النموذج الهيكلي للبيانات الوصفية في HTML، سنلاحظ أنَّ هنالك معالجةٌ خاصةٌ للعنصر <time>. فقيمة خاصية البيانات الوصفية هي قيمة خاصية datetime في العنصر <time>. لكن مهلًا، أليست الصيغة المعيارية لخاصيات البيانات الوصفية startDate و endDate هي ISO، مَثَلُهَا كمَثَلِ خاصية datetime في العنصر <time>. وأكرر مرةً أخرى كيف تتوافق ةتتناغم البُنى الهيكلية من أساس HTML مع البُنى الهيكلية التي نُضيفها من نوع الاصطلاحات الخاص بالبيانات الوصفية. عملية توصيف تواريخ بداية ونهاية الحدث عبر البيانات الوصفية سهلةٌ وتتم كالآتي: استخدام HTML استخدامًا صحيحًا في المقام الأول (باستخدام عناصر <time> للوقت والتاريخ)، ومن ثم إضافة خاصية itemprop <p> <time itemprop="startDate" datetime="2009-11-06T08:30+01:00">2009 November 6, 8:30</time> &ndash; <time itemprop="endDate" datetime="2009-11-06T20:30+01:00">20:30</time> </p> بالعربية: «هذا الحديث يبدأ في November 6, 2009 الساعة 8:30 صباحًا، ويستمر إلى November 6, 2009 الساعة 20:30 (بتوقيت مدينة براغ المحلي، GMT+1)». ثم ستأتي خاصية location، التي تقول عنها صفحة تعريف نوع الاصطلاحات Event أنها قد تكون من نوع PostalAddress أو Place. وفي حالتنا، سيُقام الحدث في مكانٍ متخصصٍ بالمؤتمرات، وهو Congress Center في مدينة براغ. وإمكانية توصيفه على أنَّه «مكان» (Place) ستسمح لنا بتضمين اسمه بالإضافة إلى عنوانه. لنبدأ بالتصريح أنَّ العنصر <p> الذي يحتوي على العنوان هو خاصية location لنوع الاصطلاحات Event، وهذا العنصر يحتوي على خاصياتٍ تابعةٍ لنوع الاصطلاحات http://schema.org/Place. <p itemprop="location" itemscope itemtype="http://schema.org/Place"> ثم سنُعرِّف اسم المكان بوضعه في عنصر وإضافة الخاصية itemprop إليه. <span itemprop="name">Congress Center</span><br> وبسبب قواعد المجالات (scoping rules) في البيانات الوصفية، خاصية itemprop=”name”‎ السابقة تُعرِّف اسم المكان في نوع الاصطلاحات Place وليس في نوع الاصطلاحات Event. وذلك لأنَّ العنصر <p> السابق قد صرَّح عن بداية خاصيات المكان (Place)، ولمّا يُغلَق عنصر <p> بعدُ عبر وسم <‎/p>. أيّة خاصيات نُعرِّفها والتي تَتبَع للبياناتِ الوصفيةِ تكونُ من خصائصِ آخرِ نوعِ اصطلاحاتٍ دخلَ المجالَ. يمكن أن تتداخل أنواع الاصطلاحات مثل المكدس (stack). لم نحذف إلى الآن آخر عنصر من المكدس، وهذا يعني أننا ما زلنا ضمن مجال نوع الاصطلاحات Place. في الحقيقة، سيلزمنا إضافة نوع اصطلاحات ثالث إلى المكدس: عنوانٌ (Address) للمكان (Place) الذي سيُقام به الحدث (Event). <span itemprop="address" itemscope itemtype="http://schema.org/PostalAddress"> مرةً أخرى، علينا أن نضع كل جزء من العنوان كخاصية بيانات وصفية مستقلة، لذلك علينا أن نُضيف عددًا من عناصر <span> لكي نضع خاصيات itemprop فيها (إذا رأيتني أشرح الأمور بسرعة هنا، فأنصحك بالعودة إلى الأقسام السابقة وقراءة كيفية توصيف العنوان للأفراد وكيفية توصيف العنوان للمنظمات). <span itemprop="address" itemscope itemtype="http://schema.org/PostalAddress"> <span itemprop="streetAddress">5th května 65</span><br> <span itemprop="postalCode">140 21</span> <span itemprop="addressLocality">Praha 4</span><br> <span itemprop="addressCountry">Czech Republic</span> </span> لا توجد خاصيات إضافية للعنوان، لذا لنغلق عنصر <span> الذي بدأ المجال الخاص بنوع الاصطلاحات Address. </span> علينا الآن إضافة الخاصية geo لتمثيل الموقع الفيزيائي للحدث. سنستخدم نفس نوع الاصطلاحات (GeoCoordinates) الذي استعملناه في القسم السابق لتحديد موقع المنظمة. سنحتاج إلى عنصر <span> لكي يعمل كحاوية، والذي يملك الخاصتين itemtype و itemscope. وضمن العنصر <span> سنضع عنصرَي <meta>، واحدٌ لتحديد إحداثيات العرض (الخاصية latitude) والآخر لتحديد إحداثيات الطول (الخاصية longitude). <span itemprop="geo" itemscope itemtype="http://schema.org/GeoCoordinates"> <meta itemprop="latitude" content="50.047893" /> <meta itemprop="longitude" content="14.4491" /> </span> بعد إغلاقنا لعنصر <span> الذي يحوي خاصيات الموقع الجغرافي، سنعود إلى مجال Place، لكن لم تعد هنالك أيّة خاصيات لإضافتها إلى Place، لذا سنُغلِق العنصر <p> الذي بدأ مجال نوع الاصطلاحات Place، وبهذا سنعود إلى تعريف الخاصيات التابعة لنوع الاصطلاحات Event. </p> وأخيرًا وليس آخرًا، بقيت الخاصية url، التي يجب أن تكون مألوفةً لك. تُضاف روابط URL المتعلقة بالأحداث بنفس طريقة إضافة الروابط للأشخاص وطريقة إضافة روابط للمنظمات. إذا كنتَ تستعمل HTML استعمالًا صحيحًا (أي وضع الروابط في عنصر <a href>)، فآلية التصريح أنَّ الروابطَ تُمثِّلُ خاصيةَ url في البيانات الوصفية بسيطةٌ جدًا وذلك بإضافة خاصية itemprop إلى تلك العناصر فقط. <p> <a itemprop="url" href="http://code.google.com/intl/cs/events/developerday/2009/home.html"> GDD/Prague home page </a> </p> </article> يجدر بالذكر أنَّك تستطيع توصيف أكثر من حدث في نفس الصفحة. المقتطفات المنسقة من جديد! وفقًا لأداة اختبار البيانات المنظمة من Google، المعلومات التي تحصل عليها عناكب محرك البحث من صفحة الحدث السابقة هي: كما لاحظتَ، جميع البيانات التي وصَّفناها موجودةٌ هنا. لاحظ كيف تُظهِر أداة اختبار البيانات الهيكلية تشعّب أنواع الاصطلاحات؛ هذا التمثيل الرسومي سيساعدك كثيرًا على تخيّل الوضع. هذا رسمٌ توضيحيٌ للطريقة المتوقعة لتمثيل الصفحة في نتائج بحث Google (أكرر مرةً أخرى أنَّ هذا مجرد مثال، فقد يُغيّر Google طريقة تنسيق نتائج البحث في أيّ وقت، ولا توجد هنالك ضمانة أنَّ Google ستُفسِّر البيانات الوصفية في صفحتك من الأساس!). بعد عنوان الصفحة والمُقتطف المولَّد تلقائيًا، سيبدأ محرك Google باستعمال البيانات الوصفية التي أضفناها إلى الصفحة لعرض جدول المحتويات. لاحظ طريقة تنسيق التاريخ «Fri, Nov 6». لم ترد هذه السلسلة النصية في أيّ مكانٍ في عناصر HTML أو خاصيات البيانات الوصفية. لكننا استخدمنا سلسلتين نصيتين هما التاريخ بصيغةٍ معياريةٍ (‎2009-11-06T08:30+01:00 و ‎2009-11-06T20:30+01:00). أخذ Google هاذين التاريخين وعَرِفَ أنَّهما في نفس اليوم، وقرر عرض تاريخٍ وحيدٍ بصيغةٍ قراءتها أسهل. انظر الآن إلى العنوان الفيزيائي. اختار Google أن يعرض اسم المكان + البلدة (locality) + الدولة، لكنه لم يعرض عنوان الشارع المُفصَّل. أصبح هذا ممكنًا لأننا قسّمنا العنوان إلى خمسِ خاصياتٍ مستقلةً –streetAddress وaddressLocality و addressRegion و postalCode و addressCountry– استفاد Google من هذا لعرض عنوانٍ مختصرٍ للمكان. قد يختار مستهلكونَ آخرونَ للمعلوماتِ التي توفرُها عبر البيانات الوصفية استخدامها بطرائقَ مختلفةٍ، إذ سيقررون ما الذي سيَعرضوه وما الذي لن يعرضوه. لا يوجد خيارٌ صائب وخيارٌ خاطئ هنا. عليكَ أن توفرَ أكبرَ قدرٍ من البيانات الهيكلية، وبأكبر دقةٍ ممكنةٍ، واترك الباقي على الآخرين ليفسروه كيفما يشاؤون. توصيف المراجعات هذا مثالٌ آخر عن كيفية جعل الويب (وربما نتائج البحث) أفضل عبر استخدام البيانات الوصفية: مراجعات (reviews) الشركات والمنتجات. هذه مراجعةٌ قصيرةٌ كتبتُها لأحد مطاعم البيتزا المُفضَّلة لدي (بالمناسبة، هذا المطعم حقيقي). لننظر أولًا إلى الشيفرة الأصلية قبل إضافة البيانات الوصفية: <article> <h1>Anna’s Pizzeria</h1> <p>★★★★☆ (4 stars out of 5)</p> <p>New York-style pizza right in historic downtown Apex</p> <p> Food is top-notch. Atmosphere is just right for a “neighborhood pizza joint.” The restaurant itself is a bit cramped; if you’re overweight, you may have difficulty getting in and out of your seat and navigating between other tables. Used to give free garlic knots when you sat down; now they give you plain bread and you have to pay for the good stuff. Overall, it’s a winner. </p> <p> 100 North Salem Street<br> Apex, NC 27502<br> USA </p> <p>— reviewed by Mark Pilgrim, last updated March 31, 2010</p> </article> هذه المراجعة موجودةٌ ضمن عنصر <article>، الذي علينا وضع خاصيتي itemtype و itemscope فيه. رابط URL لمجال أسماء نوع الاصطلاحات الذي سنستعمل هو http://schema.org/Review. <article itemscope itemtype="http://schema.org/Review"> ما هي الخاصيات الموجودة في نوع الاصطلاحات Review؟ أنا ممتنٌ لسؤالك. الخاصية الشرح itemReviewed اسم العنصر الذي ستتم مراجعته. يمكن أن يكون منتجًا أو خدمةً أو شركةً… إلخ. reviewRating التقييم الذي أعطاه المُراجِع للعنصر. يُمثَّل بنوع الاصطلاحات Rating ‏(http://schema.org/Rating) author اسم الشخص الذي كتب المراجعة datePublished تاريخ نشر المراجعة بصيغة ISO name عنوان مختصر للمراجعة reviewBody الوصف الذي كتبه المُراجِع للعنصر أولُ خاصيةٍ بسيطةٌ: itemReviewed هي نصٌ عاديٌ، وقيمتها موجودةٌ في عنصر <h1>، لذا سنضع تلك الخاصية في ذاك العنصر. <h1 itemprop="itemReviewed">Anna’s Pizzeria</h1> سأتجاوز حاليًا قسم التقييم وسأعود إليه لاحقًا في النهاية. الخاصيتان التاليتان سهلتان وبسيطتان. خاصية name هي عنوانٌ مختصرٌ للمراجعة، وخاصية reviewBody هي النص الذي كتبه المراجع لوصف العنصر المُراجَع. <p itemprop="name">New York-style pizza right in historic downtown Apex</p> <p itemprop="reviewBody"> Food is top-notch. Atmosphere is just right for a “neighborhood pizza joint.” The restaurant itself is a bit cramped; if you’re overweight, you may have difficulty getting in and out of your seat and navigating between other tables. Used to give free garlic knots when you sat down; now they give you plain bread and you have to pay for the good stuff. Overall, it’s a winner. </p> يجب أن يكون توصيف العنوان وإحداثيات الموقع الجغرافي مألوفًا لديك الآن (إذا لم تكن تتابع معنا منذ بداية هذه الدروس، فراجع آلية توصيف عنوان شخص، وآلية توصيف عنوان منظمة، وآلية توصيف إحداثيات الموقع الجغرافي من الدروس السابقة). <p itemprop="contentLocation" itemscope itemtype="http://schema.org/Place"> <span itemprop="address" itemscope itemtype="http://schema.org/PostalAddress"> <span itemprop="streetAddress">100 North Salem Street</span><br> <span itemprop="addressLocality">Apex</span>, <span itemprop="addressRegion">NC</span> <span itemprop="postalCode">27502</span><br> <span itemprop="addressCountry">USA</span> </span> <span itemprop="geo" itemscope itemtype="http://schema.org/GeoCoordinates"> <meta itemprop="latitude" content="50.047893" /> <meta itemprop="longitude" content="14.4491" /> </span> </p> في آخر سطرٍ مشكلةٌ شائعة: يحتوي على معلومتين في عنصرٍ وحيدٍ. اسم الشخص الذي كتب المراجعة هو Mark Pilgrim، وتاريخ المراجعة هو March 31, 2010. كيف نستطيع توصيف هاتين الخاصيتين المستقلتين؟ ضعهما في عنصرَين منفصلين وضع خاصية itemprop في كلٍ عنصرٍ. يجدر بنا في هذا المثال أن نضع التاريخ في عنصر <time>، لكي يوفر لنا طريقةً سليمةً لوضع خاصية itemprop المناسبة. لكن اسم المُراجِع يمكن أن يُحتوى في عنصرٍ ليس له قيمةٌ دلاليةٌ مثل <span>. <p>— <span itemprop="author">Mark Pilgrim</span>, last updated <time itemprop="datePublished" datetime="2010-03-31"> March 31, 2010 </time> </p> </article> حسنًا، لنتحدث عن التقييمات. أصعب جزء في توصيف المراجعة هو التقييم. افتراضيًا، التقييمات في نوع الاصطلاحات Rating تكون على مقياس من 1 إلى 5، حيث 1 هو «سيء جدًا» و5 هو «رائع». لكنك ما تزال قادرًا على توصيف التقييم إذا كنت تستخدم مقياسًا مختلفًا، لكن دعنا نناقش المقياس الافتراضي أولًا. <p>★★★★☆ (<span itemprop="reviewRating">4</span> stars out of 5)</p> إذا كنتَ تستعمل مقياسًا افتراضيًا من 1 إلى 5، فالخاصية الوحيدة التي عليك توصيفها هي التقييم نفسه (4 في مثالنا). لكن ماذا لو كنتَ تستعمل مقياسًا مختلفًا؟ كل ما عليك فعله هو التصريح عن حدود المقياس الذي تستعمل. على سبيل المثال، إذا أردت أن تستعمل مقياسًا من 0 إلى 10، فما يزال عليك التصريح عن خاصية itemprop=”rating”‎ لكن بدلًا من إعطاء قيمة التقييم مباشرةً، سيتوجب عليك استخدام نوع http://schema.org/Rating لتعيين أقل قيمة وأعلى قيمة في مقياسك المُخصَّص بالإضافة إلى تحديد قيمةٍ للتقييم الفعلي ضمن ذاك المقياس. <p itemprop="reviewRating" itemscope itemtype="http://schema.org/Rating"> ★★★★★★★★★☆ (<span itemprop="ratingValue">9</span> on a scale of <span itemprop="worstRating">0</span> to <span itemprop="bestRating">10</span>) </p> بالعربية: «هذا المنتج الذي أكتب مراجعةً عنه يملك تقييمًا قيمته 9 في مقياسٍ من 0 إلى 10». هل ذكرتُ لك أنَّ البيانات الوصفية المُضافة للمراجعات قد تؤثر على نتائج البحث؟ هذه هي البيانات التي تستيطع أداة اختبار البيانات المنظّمة استخلاصها من مراجعتنا: وهذه صورةٌ توضيحيةٌ لكيف يمكن أن تبدو المراجعة عند عرضها في نتائج البحث: أليس هذا مُبهرًا؟ مصادر إضافية مصادر عن البيانات الوصفية (Microdata): مواصفة Microdata في HTML5 صفحة Microdata في ويكيبيديا مصادر عن المقتطفات المنسقة: صفحة Rich Snippets أداة اختبار البيانات المنظمة موقع schema.org الذي يحتوي معلوماتٍ عن أنواع الاصطلاحات المختلفة التي ذكرناها في هذا دروس هذه السلسلة. ترجمة -وبتصرّف- لفصل «Microdata» من كتاب Dive Into HTML5 لمؤلفه Mark Pilgrim. اقرأ أيضًا المقال السابق: توصيف المنظمات/الشركات باستخدام microdata في HTML5 النسخة العربية الكاملة من كتاب نحو فهم أعمق لتقنيات HTML5

تتميز خدمة Google Analytics بروعة أدائها في تتبع حركة مرور زوار موقع ما، دون الحاجة إلى أي إعدادات أو إضافات، إلا أنها لا تتتبع تحميل الملفات مثل: ملفات PDF ،MP3، مستندات Word أو مقاطع الفيديو نظرا لاعتمدها على JavaScript. آخِذِينَ ما سبق بعين الاعتبار، سنتطرق وإياكم في هذا الموضوع إلى كيفية استخدام الأحداث (events) في Google Analytics بغرض تتبع تحميل الملفات. سنتطرّق بشكل سريع إلى بعض الطّرق التي تصلح على جميع المواقع ثم سنختم بمجموعة مُلحقات خاصة بووردبريس. ما يجب أن تعرفه قبل الشروع في العمل بحكم أنّك تقرأ هذا الموضوع، سنفترض أنك تملك مسبقا حساب Google Analytics جاهزا للعمل، إن كنت حديث العهد بهذه الخدمة فمن الأفضل أن تلقي أوّلًا نظرة على سلسلة مدخل إلى Google Analytics هنا على أكاديمية حسوب. يجب عليك أيضا أن تتأكد من استخدامك لأحدث نسخة Universal Analytics من شفرة التتبع (tracking code)، سنفترض أنك فعلا تستخدمها، أما إن كنت بحاجة إلى ترقية نسخة السكربت، يوفر لك جوجل كما هائلا من الموارد لمرافقتك في تطبيق مختلف الخيارات خلال كل مراحل عملية الترقية. استعمال الأحداث (Events) في Google Analytics يعمل جوجل على توفير طريقة أكثر مرونة لقياس تفاعل المستخدمين مع موقعك وذلك من خلال الأحداث (Events) في خدمة Analytics دون الحاجة إلى التقيد بشكل كامل بعدد الزيارات (page loads). يمكنك الولوج إلى الأحداث (Events) على حسابك من خلال الذهاب إلى تبويب Reporting ثم اختيار Behavior < Events. قسم Events في Google Analytics قبل تفعيله يتميز تصميم الأحداث (Events) في Google Analytics بقابلية الإعداد والتهيئة حسب ما ترغب فيه، يتوفر كل حدث على أربع مكونات أساسية يمكنك التعديل عليها بكل حرية لتناسب احتياجاتك ومتطلباتك: Category (التصنيف): الوصف أو المصطلح الذي يعود على نوع محدد من الأحداث، يعطيك هذا الخيار إمكانية تجميع الأحداث المتشابهة مثلا الكتب الإلكترونية (e-book) أو ما كل ما يتعلق بمقاطع الفيديو. Action (الإجراء): النتيجة أو الهدف الذي ترغب في تَتَبّعَهُ، يمكن أن يكون تحميلا، ضغطة على زر مُعيّن أو أي نوع آخر من الإجراءات أو العمليات التي تود أن تستهدفها. Label (الوصف): يوفر لك خيار الوسوم هذا بعض المساحة الإضافية لإضافة أي معلومات أخرى قد تبدو لك ذات أهمية. هذا الحقل اختياري Value (القيمة): لنفترض على سبيل المثال أن العرض المجاني الذي تقدمه لزوارك مقابل التسجيل في موقعك هو تحميل كتاب إلكتروني ما ولنفترض أيضا أن معدل التحويل على هذا التحميل هو %10 من قيمة المنتوج التابع لهذا الكتاب والتي تبلغ 150 دولارا، يمكن إذا في هذه الحالة ربط كل تحميل بقيمة 15 دولارا. هذا الحقل اختياري أيضًا يمكنك الاطلاع على المزيد من التفاصيل فيما يخص الخيارات (options) المتوافرة لكل واحدة من المكونات السابقة على توثيق جوجل لأحداث خدمة Analytics. لننتقل الآن إلى الاستخدام الفعلي لخاصية الأحداث هذه بغرض تجميع البيانات. كيفية إنشاء حدث جديد قم أولا بتسجيل الدخول إلى حسابك، تحديد الموقع (من قسم property) ثم الضغط على رابط Admin أعلى الشاشة: اختر Goals من الخانات الثلاث الظاهرة. يمكنك الآن أن ترى ثلاث خانات كما في الصورة أعلاه، اضغط على رابط Goals في خانة View ثم New Goal لتبدأ بعملية الإعداد: إنشاء هدف الحدث (Event Goal) ما يأخذنا إلى الشاشة أعلاه حيث يمكن إدخال المعلومات التالية: name (الاسم) وgoal ID (المُعرف الخاص بالإجراء المستهدف) ثم اختر Event لتحديد نوع الإجراء المستهدف. إنشاء تفاصيل الإجراء المستهدف (goal) نصل أخيرا إلى مرحلة إدخال المكونات المشار إليها مسبقا، عند انتهائك من ذلك ومُراجعتك للإعدادات التي اخترتها ما عليك إلا أن تضغط Save لحفظ التغييرات ما ينهي هذه المرحلة من الإعداد. إضافة تتبع حدث (Event Tracking) أولي إلى الصفحة بعد الانتهاء من إعداد الحدث في خدمة Analytics، علينا الآن أن نصبح قادرين على تفعيله على الموقع، يعتبر استخدام حدث من نوع onclick أسهل طريقة لإضافة التتبع إلى صفحة معينة، حيث يتم إرسال المعلومات إلى Analytics بمجرد تفاعل المستخدم مع الإجراء المستهدف. على سبيل المثال، إذا أردنا تتبع أداء كتاب إلكتروني مجاني، يجب فقط إضافة الشيفرة التالية إلى الرابط المعني كما هو مبين أسفله: <a onclick="ga('send', 'event', 'Downloads', 'Click', 'E-book downloaded', '0');" href="http://mysamplesite.com/wp-content/uploads/2015/12/my-free-lead-magnet.pdf">Download Our Guide to Speeding up Your Site</a> يمكنك الاطلاع على التفصيل الكامل للمزيد من الخيارات على صفحة تتبع الأحداث (Event Tracking) في Google Developers. قد تكون إضافة هذا الكود يدويًا حلًا عمليًا لما يكون لديك حدث واحد لتتبّعه، أما إذا كنت ترغب في تتبّع العديد من الأحداث، فهنالك بعض الطرق البديلة التي يمكنك استخدامها. يُمكن مثلا الاستعانة بـ jQuery لإضافة آلية تتبّع الأحداث بشكل آلي، ويُمكن مثلًا أن نُحدّد الرّوابط التي نرغب في استهدافها عبر إضافة id خاص إليها. كما يُمكننا الاستعانة بـ Google Tag Manager لإدارة هذه الأحداث دون الحاجة إلى التّعديل على شيفرة الموقع. أما إذا كنت تستخدم ووردبريس كنظام إدارة مُحتوى على موقعك فهناك عدّة مُلحقات تسمح لك بالقيام بالأمر دون أيّ عناء. تتبع تحميل الملفات باستعمال ملحق ووردبريس إذا بدا لك أن ما أسلفنا الذكر من الطرق والتقنيات كثير التعقيد، فإليك مجموعة من الملحقات التي يمكنها أن تتكفل بتتبع وإدارة تحميل الملفات على ووردبريس، إليك فيما يلي ثلاثا من أكثرها شعبية وانتشارا: Google Analytics Dashboard for WP يعمل ملحق Google Analytics Dashboard for WP على إحضار بيانات موقعك مباشرة إلى ووردبريس كما يسمح لك بالاطلاع على المعلومات بخصوص التحميلات المسجلة كأحداث (events). تم تنزيل هذا المُلحق حوالي 600 000 مرة ويُقارب تقييمه الخمس نجمات. يعتبر هذا الملحق طريقة عملية لجلب قوة Analytics مباشرة إلى لوحة التحكم الخاصة بك. Download Monitor يَتَّبِعُ ملحق Download Monitor مقاربة مختلفة قليلا فيما يخص تحميل الملفات عن طريق وضعها على قدم المساواة مع المنشورات والصفحات على موقعك. يسمح لك هذا الملحق بتصنيف ووسم تحميلاتك، إضافة بيانات وصفية مخصصة لها فضلا عن تتبعها، كما يوفر خصائص متقدمة مثل التحميلات الخاصة بالأعضاء. يوفر الملحق أيضا مجموعة من الإضافات الرائعة إن أردت التحكم بشكل أفضل في تحميل الملفات على موقعك. WordPress Download Manager يوفر ملحق WordPress Download Manager خصائص عَدِّ التحميلات وإرسال التقارير إضافة إلى إمكانية الدمج السلس مع Google Drive ،Dropbox و Box.com كما توفر النسخة المدفوعة من الملحق الكثير من خيارات التجارة الإلكترونية. هل تقوم أنت بتتبع تحميل الملفات على موقعك؟ كيف تقوم بذلك؟ شاركنا في التعليقات أسفله نصائحك والحيل التي تتبعها كما يمكنك أن تطرح علينا أي أسئلة تراودك. ترجمة وبتصرف للمقال: Tracking File Downloads With Google Analytics And Wordpress لصاحبه: TOM EWER.

يُعد إنجن إكس NginX خادوم ويب Web Server ذو أداء عالي وهو مسؤول عن معالجة العبء الواقع على بعض أكبر المواقع الإلكترونية Web Sites على الإنترنت Internet. وهو جيد خصوصًا في معالجة الكثير من الاتصالات المتزامنة concurrent ويتفوق في تخديم المحتوى الثابت static content. مع أنّ الكثير من المستخدمين يدركون قدرات Nginx، إلا أنه عادةً ما يحتار المستخدمين الجدد ببعض المصطلحات التي يجدونها في ملف إعدادات configuration خادوم Nginx. سنركّز في هذا الدليل على شرح البنية الأساسية لملف إعدادات Nginx بالإضافة لاستعراض بعض المبادئ guidelines في كيفية تصميم ملف الإعدادات. فهم سياقات الإعدادات في Nginxسيُغطي هذا الدليل البنية الأساسية الموجودة في ملف الإعدادات الرئيسي Nginx. قد يختلف مكان هذا الملف وفقًا للطريقة التي اتبعتها عند تثبيت البرمجية Software على الخادوم. إلا أنَّك سوف تجده في العديد من التوزيعات distributions على المسار التالي: /etc/nginx/nginx.confإنّ لم يكن موجودًا فقد تجده على المسار: /usr/local/nginx/conf/nginx.confأو المسار: /usr/local/etc/nginx/nginx.confإنّ أحد أول الأمور التي ينبغي عليك ملاحظتها عندما تنظر إلى ملف الإعدادات الرئيسي هي أنَّه منظَّم في بنيةٍ من ثلاثة أقسام تعرّف بداية ونهاية كلٍ منها بالقوسين } و {. تسمى الأقسام المعرّفة باستخدام القوسين سياقات contexts وفقًا للغة Nginx، وذلك لأنها تحوي على إعداداتٍ مُفَصَّلة وموزعة بين تلك الأقسام وفقًا للمجال الذي يُعنى به كل قسم. يقدم هذا التقسيم بشكل أساسي بنيةً منظّمة وفق بعض الشروط المنطقية التي تقرّر فيما إن كان ينبغي تطبيق الإعدادات التي يحويها القسم أو لا. وباعتبار أنه يمكن للسياقات أن تتداخل فيما بينها فإنNginx يقدم مستوًا من وراثة التعليمات directive inheritance. كقاعدةٍ عامة، إن كانت التعليمة صالحةً في عدّة مجالات scopes متدخلة فإنّ التصريح عنها في سياق أعلى boarder context سيُمرّر لأي سياقٍ أدنى (سياق ابن child context) كقيم افتراضية. يمكن للسياقات الأدنى أن يعيد تعريف override تلك القيم لاحقًا. جدير بالذكر أنّ عملية إعادة التعريف إلى أي مصفوفة-نوع array-type سينتج عنها استبدال القيم السابقة وليس إضافة append القيم الجديدة لها. يمكن أن تستخدم التعليمات Directives ضمن السياقات المصمّمة لها فقط، إذ أنّ Nginx سيُصدر خطأ عند قراءته لملف إعدادات يحوي على تعليمات مصرّح عنها في السياق الخاطئ. يحوي توثيق Nginx على معلومات حول كلّ تعليمة والسياقات التي تكون صالحة ضمنها لذلك يُعد مرجع رائع إن لم تكن متأكدًا من معلوماتك. سنناقش فيما يلي أكثر السياقات شيوعًا والتي قد تصادفها عند استخدامك Nginx. السياقات الأساسيةأول مجموعة سياقات سنشرحها هي السياقات الأساسية core contexts التي يستخدمها Nginx لإنشاء شجرة هرمية hierarchical tree وتوزيع الإعدادات - بحسب مهمّتها - في كتل Blocks منفصلة. تشكّل تلك السياقات البنية الأساسية لإعدادات Nginx. السياق الأساسيإن أكثر سياق عام هو السياق الأساسي Main Context، والذي يدعى أيضًا بالسياق العام Global Context. إذ أنه السياق الوحيد غير المحتوى ضمن كتل السياق القياسية والتي تبدو كما يلي: # السياق الأساسي يوجد هنا، السياقات الأخرى تكون خارجا . . . context { . . . }يمكن القول عن أيّة تعليمة موجودة خارج كل تلك الكتل بأنها تقع في السياق الأساسي. ضع في الحسبان أنه إن كانت إعدادات Nginx مضبوطةً على شكل وحدات modular فستحوي بعض الملفات على تعليماتٍ instructions تبدو وكأنها تقع خارج أقواس السياق إلا أنها ستُضمّن داخله عندما يتم دمج الإعدادات معًا. يمثّل السياق الأساسي أوسع بيئة حاضنة لإعدادات Nginx، وهي مستخدمة لضبط التفاصيل التي تؤثر على كامل التطبيق application في مستوى أساسي. وفي الوقت الذي تؤثر فيه التعليمات الموجودة في هذا القسم على السياقات الأدنى فإن العديد من تلك التعليمات لا توّرث، إذ أنه من غير الممكن إعادة تعريفها في مستوياتٍ أدنى. إن بعض التفاصيل الشائعة والتي تُهيّئ في السياق الرئيسي هي المستخدم user والمجموعة group التي ستُشغّل العمليات العاملة worker processes باسمهما، بالإضافة لعدد العمليات العاملة والملف الذي سيحتفظ بمعرّف العملية الرئيسية PID. يمكن أيضًا أن يُضبط ملف الأخطاء الافتراضي لكامل التطبيق ضمن هذا المستوى (كما يمكن أن يُعاد تعريف الملف ضمن سياقات مخصّصة أكثر). سياق الأحداثإنَّ سياق الأحداث Events Context يقع ضمن السياق الأساسي. وهو يستخدم لضبط الخيارات العامة التي تؤثّر على كيفية معالجة Nginx للاتصالات في مستوى عام. يمكن أن يُعرّف سياق أحداث واحد فقط ضمن إعدادات Nginx. سوف يبدو هذا السياق ضمن ملف الإعدادات كما يلي، خارج أقواس أي سياقٍ آخر: # السياق الأساسي events { # سياق الأحداث . . . }يستخدم Nginx وحدة معالجة اتصال مقادة بالأحداث event-based connection processing model لذلك فإن التعليمات المعرّفة داخل هذا السياق تحدّد كيف ينبغي على العمليات العاملة worker processes معالجة الاتصالات connections. تُستخدم التعليمات الموجودة هنا بشكل أساسي إما في اختيار الطريقة المستخدمة في معالجة الاتصال أو لتغيير كيفية تحقيق implement تلك الطرق methods. عادةً ما تُختار طريقة معالجة الاتصال تلقائيًا بالاعتماد على أكثر الخيارات - التي توفّرها منصّة العمل platform - فاعليةً. بالنسبة لأنظمة لينكس Linux، فعادةً ما تكون طريقة epoll هي الخيار الأفضل. هنالك عناصر أخرى يمكن ضبطها، كعدد الاتصالات التي يمكن لكل عملية عاملة أن تعالجها، وفيما إن كان على العملية أن تأخذ اتصالًا تلو الآخر أو أن تأخذ كل الاتصالات المنتظرة بعد أن يتم إعلامها بوجودها. وأيضًا فيما إن كان على العمليات العاملة أن تتناوب في الرد على الأحداث. سياق HTTPعند إعداد Nginx كخادوم ويب أو خادوم وكيل معكوس reverse proxy، فسيحتفظ سياق HTTP بغالبية الإعدادات. سيحتوي السياق على كل التعليمات والسياقات الأخرى الضرورية لتعريف كيفية معالجة البرنامج لاتصالات HTTP أو HTTPS. يُعد سياق HTTP أخًا لسياق الأحداث - أي أنهما يقعان في نفس المستوى - إذ أن كلاهما يُعد ابنًا للسياق الرئيسي، لذلك ينبغي أن يُدرجا جنبًا إلى جنب بدلًا من أن يتداخلا: # السياق الأساسي events { # سياق الأحداث . . . } http { # سياق HTPP . . . }فيما تختص السياقات الدنيا lower contexts في كيفية معالجات الطلبات، فإن التعليمات في هذا المستوى تتحكم بالقيم الافتراضية لكل الخواديم الافتراضية المعرّفة داخله. هنالك عدد كبير من التعليمات القابلة للضبط configurable ضمن هذا السياق والسياقات المحتواة ضمنه، يعتمد ذلك على طريقة التوريث inheritance التي ترغب أن يتم العمل وفقها. فيما يلي مجموعة من التعليمات التي يمكن أن تصادفها خلال ضبط إعدادات Nginx: تعليمات تتحكم بالمواقع الافتراضية لسجلات الوصول والأخطاء مثل (access_log و error_log).تعليمات تضبط عمليات القراءة والكتابة I/O غير المتزامنة asynchronous من وإلى الملفات مثل (aio و sendfile و directio)،تعليمات تضبط حالات الخادوم عندما تحدث الأخطاء مثل (error_page).تعليمات تضبط عملية الضغط compression مثل (gzip و gzip_disable).عمليات تحسّن fine-tune إعدادات اتصال TCP الحي TCP keep alive مثل (keepalive_disable و keepalive_requests و keepalive_timeout).القواعد rules التي يتبعها Nginx عندما يحاول تحسين optimize الحزم packets واستدعاءات النظام system calls مثل (sendfile و tcp_nodelay و tcp_nopush).تعليمات تضبط جذر المستندات document root وفهرس الملفات index files على مستوى التطبيق application-level مثل (root و index).تعليمات تهيّئ العديد من جداول المقابلة hash tables المستخدمة لتخزين أتماط مختلفة من البيانات مثل (*_hash_bucket_size و *_hash_max_size المستخدمتين مع server_names بالإضافة لـ types و variables).سياق الخادوميُعرّف سياق الخادوم Server Context ضمن سياق HTTP، ويُعد ذلك أوّل مثال لنا عن السياقات المتداخلة. كما أنّه أوّل سياق مرّ معنا يمكن تعريفه عدّة مرات. قد يبدو التنسيق العام لسياق الخادوم مشابهًا لما يأتي، تذكّر أنّ هذا السياق سيقع ضمن سياق HTTP: # السياق الأساسي http: { # سياق HTTP server { # سياق خادوم أول } server { # سياق خادوم ثاني } }يعود سبب السماح بوجود أكثر من تعريف لسياق الخادوم إلى أن كل غرض instance يعرّف خادومًا افتراضيًا لمعالجة طلبات المستخدم client. بإمكانك تعريف كتل الخادوم server blocks بقدر حاجتك، إذ أنّه بإمكان كل منها أن يعالج مجموعة فرعية محدّدة من الاتصالات. وبسبب امكانية وترجيح وجود عدة كتل خواديم، فإن هذا أوّل نوع من السياقات يحتّم على Nginx استخدام خوارزمية algorithm انتقاء لاتخاذ القرارات. إنّ كلّ طلب مستخدم سيُعالَج وفقًا للإعدادات المعرّفة في سياق خادوم وحيد، لذلك فإن على Nginx أن يقرّر أي سياق خادوم هو الأنسب وفقًا لتفاصيل الطلب. إنّ التعليمات التي تقرّر فيما إذا كانت كتلة الخادوم ستُستخدم أم لا هي: تعليمة التنصت listen: تُصمَّم كتلة الخادوم للرد على الطلبات الواردة من مصدر معرّف بثنائية عنوان الإنترنت IP / المنفذ Port. فإن ورد طلب request من مستخدم يطابق ذلك المصدر فمن المحتمل أن يتم اختيار تلك الكتلة لمعالجة الاتصال.تعليمة اسم الخادم server_name: هذه التعليمة هي المكوّن الآخر المستخدم في اختيار كتلة الخادوم التي ستقوم بالمعالجة. إن كان هنالك العديد من كتل الخادوم مزوّدةً بتعليمات تنصت مضبوطة بنفس القيم ويمكنها أن تعالج الطلب، فسيحلّل إنجن إكس ترويسة المُضيف Host header الخاصة بالطلب ويطابقها مع التعليمة.يمكن للتعليمات الموجودة ضمن هذا السياق أن تعيد تعريف العديد من التعليمات المعرّفة في سياق HTTP بما فيها تعليمات التسجيل logging، وجذر المستندات، والضغط، وإلى ما هنالك. وبالإضافة إلى التعليمات المأخوذة من سياق HTTP، فبإمكاننا أيضًا إعداد ملفات لمحاولة الرد على الطلبات عبر تعليمة (try_files)، وإصدار أمر لإعادة التوجيه وإعادة الكتابة (return و rewrite)، وضبط المتحولات عبر تعليمة (set). سياق الموقعالسياق التالي الذي ستتعرف عليه هو سياق الموقع location context وهو سياقٌ ستتعامل معه بشكل متكرّر. تتشارك سياقات الموقع العديد من الصفات مع سياقات الخادوم. فمثلًا، يمكن تعريف أكثر من سياق موقع، ويُستخدم كل منها لمعالجة نوع محدّد من طلبات المستخدم، ويتم اختيار كل موقع بناءًا على مطابقة تعريف الموقع مع طلب المستخدم باستخدام خوارزمية انتقاء. في الوقت الذي تُعرّف فيه التعليمات - التي تحدّد فيما إن كان سيتم اختيار كتلة خادوم - ضمن السياق الخادوم ذاته، فإن المكوّن component الذي يقرّر مدى قدرة الموقع على معالجة الطلب يقع ضمن تعريف الموقع نفسه. تبدو الصيغة العامة كما يلي: location match_modifier location_match { . . . }تقع كتل الموقع ضمن سياقات الخواديم، وعلى عكس كتل الخادوم، يمكن لكتل الموقع أن تتداخل فيما بينها. قد يفيد ذلك في إنشاء سياق موقع أعم ليلتقط مجموعة فرعية محدّدة من الطلبات المتناقلة traffic، لتكمل السياقات الإضافية الداخلية معالجتها بإسهاب أكبر وفقًا لمعايير أدق. # السياق الأساسي server { # سياق الخادوم location /match/criteria { # سياق موقع أول } location /other/criteria { # سياق موقع ثاني location nested_match { # موقع أول } location other_nested { # موقع ثاني } } }بينما يتم اختيار سياقات الخواديم وفقًا لثنائية عنوان IP / المنفذ المطلوبة ولاسم المضيف الموجود ضمن ترويسة المضيف، فإن كتل الموقع تقسّم معالجة الطلب ضمن كتلة الخادوم بالنظر إلى معرّف الموارد الموّحد URI الخاص بالطلب. إن معرّف URI الخاص بالطلب هو جزءٌ من الطلب يأتي بعد اسم النطاق domain name وثنائية عنوان IP / المنفذ. لذلك فإن طلب المستخدم http://www.example.com/blog على المنفذ 80، يستخدم العنوان http www.example.com والمنفذ 80 لتحديد كتلة الخادوم التي سيتم اختيارها. بعد اختيار الخادوم، سيُطابق الجزء /blog (المُمثّل لمعرّف URI الخاص بالطلب) مع المواقع المعرّفة لتحديد السياق الإضافي الذي ينبغي استخدامه ليرد على الطلب. إنّ العديد من التعليمات التي يمكن أن تراها في سياق الموقع متوفّرةٌ أيضًا في مستويات الآباء (المستويات الأعلى) parent levels. فيما يلي مجموعة جديدة من التعليمات المستخدمة ضمن هذا المستوى تسمح لك بالوصول إلى المواقع الواقعة خارج جذر المستندات (تعليمة alias)، وتحديد الموقع كموقع يمكن الوصول له من الداخل فقط (تعليمة internal)، وكوكيل لخواديم أو مواقع أخرى (باستخدام برتوكولات http، fastcgi، scgi، uwsgi) سياقات أخرىمع أنّ الأمثلة السابقة تمثّل السياقات الأساسية التي ستصادفها في Nginx، إلا أنه يوجد سياقات أخرى أيضًا. هنالك عدّة أسباب دعتنا لفصل السياقات التالية، فإما أنها تعتمد على الكثير من الوحدات الاختيارية، أو أنها تستخدم ضمن ظروف خاصة فقط، أو أنها تستخدم لوظائف لن يستخدمها معظم الأشخاص. لكننا لن نناقش كل السياقات المتوفّرة، ولن نخوض بشرح السياقات الآتية بالتفصيل: split_clients أُعد هذا السياق لتقسيم المستخدمين اللذين يستقبلهم الخادوم إلى فئات categories عبر عنونتهم بمتحولات تعتمد على النسبة المئوية. يمكن أن يُستخدم ذلك لاحقًا للقيام باختبار A/B عبر توفير محتويات content مختلفة لمُضيفين hosts مختلفين.perl / perl_set يُهيّئ هذين السياقين معالجات بيرل Perl للموقع الذي تتواجد ضمنه. تستخدم هذه السياقات للمعالجة باستخدام بيرل فقط.map يُستخدم هذا السياق لضبط قيمة متحول بالاعتماد على قيمة متحول آخر. إذ أنه يوفّر جدول مقابلة mapping لقيم المتحوّل الأول حتى يحدّد القيمة التي ينبغي ضبط المتحول الثاني بها.geo يُستخدم هذا السياق - مثل السياق السابق - في تحديد جدول مقابلة. إلا أنّ هذا الجدول يستخدم خصيصًا لتصنيف عناوين IP. يضبط هذا السياق قيمة متحول وفقًا لعنوان IP المتّصل.types يُستخدم هذا السياق أيضًا لجداول المقابلة. إذ أنه يُستخدم لمقابلة أنماط وسائط الإنترنت MIME بامتدادات (لواحق) extensions الملفات التي ينبغي ربطهم بها. يوفّر Nginx ذلك عادةً عبر ملف يُضمّن محتواه داخل ملف الإعدادات nginx.conf.charset_map يمثّل هذا السياق مثالًا آخر عن سياقات المقابلة، إذ أنه يُستخدم لإنشاء جدول مقابلة للتحويل conversion table من مجموعة محارف إلى مجموعة أُخرى. تضمّن كلا المجموعتين في ترويسة هذا السياق، ويضمّن جدول المقابلة في بنيته body.إنّ السياق التالي ليس شائعًا بقدر السياقات التي شرحناها حتى الآن، إلا أنّ التعرّف عليه يبقى مفيدًا. سياق مجموعة الخواديم العليايُستخدم سياق مجموعة الخواديم العليا upstream context لتعريف وإعداد الخواديم العليا upstream. يعرّف هذا السياق بشكل أساسي حوضًا pool معرّفًا باسم يحتوي على مجموعة الخواديم التي يستطيع Nginx أن يعمل كوكيل proxy عنها للطلبات. ستستخدم هذا السياق على الأرجح عندما تُعد وكلاءًا من مختلف الأنواع. يجب وضع سياق مجموعة الخواديم العليا ضمن سياق HTTP، وخارج كلِّ سياقات الخواديم. تبدو الصيغة العامة له كما يلي: # السياق الأساسي http { # سياق HTTP upstream upstream_name { # سياق مجموعة الخواديم العليا server proxy_server1; server proxy_server2; . . . } server { # سياق خادوم } }يمكن فيما بعد أن تتم الإشارة إلى سياق مجموعة الخواديم العليا باسمه ضمن الخادوم أو كتل الموقع لتمرير طلبات ذات نوع محدّد لحوض الخواديم الذي تمّ تعريفه. ستستخدم عندها مجموعة الخواديم خوارزميةً لتحديد الخادوم الذي ينبغي أن يسلم الطلب له، تستخدم خوارزمية راوند روبن round-robin بشكل افتراضي. يسمح هذا السياق لـNginx أن يعمل على موازنة الحمل load balancing عندما يعمل كوكيل للطلبات. سياق البريدبالرغم من أن Nginx يُستخدم عادةً كخادوم ويب أو خادوم وكيل معكوس، إلا أنه يعمل كخادوم وكيل للبريد mail proxy server بأداءٍ عالي جدًا. يسمّى السياق المستخدم لهذا النوع من التعليمات بالبريد mail. يعرّف سياق البريد The mail context ضمن السياق العام، أو السياق الأساسي (خارج سياق HTTP). الوظيفة الأساسية لسياق البريد هي توفير مجال لإعداد وكيل للبريد على الخادوم. يمكن لـNginx أن يعيد توجيه redirect طلبات المصادقة authentication لخادوم مصادقة خارجي authentication server. ويمكنه بعد ذلك أن يوفّر الوصول إلى خواديم البريد العاملة ببرتوكولات POP3 و IMAP لجلب بيانات البريد الفعلية. يمكن لسياق البريد أن يُعد أيضًا للاتصال بخادوم الترحيل العامل ببرتوكول SMTP (SMTP Relayhost) إن دعت الحاجة. عمومًا، قد يبدو شكل سياق البريد مشابهًا لما يلي: # السياق الأساسي events { # سياق الأحداث } mail { # سياق البريد }السياق الشرطييمكن أن يُنشئ السياق الشرطي if لتوفير معالجة شرطية للتعليمات المعرّفة بداخله. وكما هو حال عبارات الشرط if في لغات البرمجة التقليدية، فإن تعليمة if في Nginx ستنفذ التعليمات المتحواة ضمنها إن كان الشرط محقّقًا وأعاد القيمة الصحيحة True. يُقدَّم السياق if في Nginx من قِبل وحدة إعادة الكتابة rewrite module وهي الغاية الأساسية من استخدام هذا السياق. باعتبار أنّ Nginx سيختبر حالات الطلب باستخدام العديد من التعليمات الأخرى المعمولة لهذا الغرض، فلا ينبغي استخدام تعليمة if في أغلب حالات التنفيذ الشرطي. تُعد هذه الملاحظة هامةً لدرجة أنّ مجتمع Nginx أنشأ صفحةً وسمّاها if الشريرة. إنّ المشكلة الأساسية هي أنّ ترتيب المعالجة لدى Nginx قد يؤدي في كثير من الأحيان إلى نتائج غير متوقعة تظهر وكأنها تقلب معنى كتلة if رأسًا على عقب. تُعد تعليمتي إعادة التوجيه return وإعادة الكتابة rewrite التعليمتين الوحيدتين اللتين يعتبر استخدامهما آمنًا داخل هذه السياقات، إذ أنها أُنشئت لأجلهما. ضع في الحسبان أيضًا أنّه عند استخدام سياق if فإنّه يقدّم تعليمة try_files داخل نفس السياق بلا فائدة. غالبًا ما يتم استخدام if لتحديد فيما إنّ كان هنالك حاجة لتعليمة return أو تعلمية rewrite. وستقع غالبًا داخل كتل الموقع، لذلك فستبدو الصيغة العامة مشابهةً لما يلي: # السياق الأساسي http { # سياق HTTP server { # سياق خادوم location location_match { # سياق موقع if (test_condition) { # سياق شرطي if } } } }سياق تحديد الاستثناءاتيُستخدم سياق تحديد الاستثناءات Limit_except Context لتحديد استخدام طرق HTTP Methods محدّدة داخل سياق الموقع. فمثلًا، إن كان ينبغي لمجموعة محدّدة فقط من المستخدمين أن يصلوا إلى محتوى طريقة POST Method، أما البقيّة فينبغي أن يتمكّنوا من قراءة المحتوى، فيمكنك استخدام كتلة limit_except لتعريف تلك المتطلّبات. سيبدو المثال السابق مشابهًا لما يلي: . . . # سياق موقع أو خادوم location /restricted-write { # سياق موقع limit_except GET HEAD { # سياق تحديد الاستثناءات allow 192.168.1.1/24; deny all; } }ستطبق التعليمات الموجودة داخل السياق - والتي يقصد منها تقييد الوصول - عند مصادفة أيٍ من طرق HTTP باستثناء تلك المدرجة ضمن ترويسة السياق. إنّ نتيجة المثال السابق هي أنّه بإمكان أي مستخدم استخدام أفعال GET و HEAD، إلا أنّه يسمح فقط للمستخدمين المتصلين من الشبكة الفرعية subnet ذات العنوان 192.168.1.1/24 باستخدام طرق أخرى. قواعد عامة حول السياقات ينبغي اتباعهاالآن وبعد أن أصبح لديك فكرة عن السياقات الشائعة التي يمكن أن تصادفها أثناء استعراضك لإعدادات إنجن إكس، فبإمكاننا شرح بعض القواعد المُثلى التي يمكن اتباعها عند التعامل مع سياقات Nginx. تطبيق التعليمات في أعلى سياق متوفرإنّ العديد من التعليمات تكون صالحةً داخل أكثر من سياق واحد. فمثلًا، هنالك بضعة تعليمات يمكن وضعها داخل كل من سياقات HTTP والخادوم والموقع. يمنحنا ذلك مرونةً عند ضبط تك التعليمات. ولكن كقاعدة عامة، عادةً ما يكون من الأفضل تعريف التعليمات في أعلى سياق تقبل التعريف ضمنه، وإعادة تعريفها ضمن السياقات الأدنى عند الحاجة. يمكن ذلك بسبب وحدة الوراثة inheritance model التي تحقّقها إنجن إكس. هنالك العديد من الأسباب لاستخدام هذه الاستراتيجية. أولًا، إنّ التعريف ضمن أعلى مستوى يجنّبك تكرار نفس التعريف ضمن السياقات الأخوة. فمثلًا، في المثال التالي يعرّف كل موقع نفس جذر المستندات. http { server { location / { root /var/www/html; . . . } location /another { root /var/www/html; . . . } } }يمكنك نقل الجذر خارج كتلة الخادوم، أو حتى لكتلة HTTP كما يلي: http { root /var/www/html; server { location / { . . . } location /another { . . . } } }أغلب الأحيان، سيكون مستوى الخادوم ملائمًا أكثر، إلا أنّ التصريح declaring في مستوىً أعلى له محاسنه. إنّ ذلك لا يسمح بضبط التعليمة في أماكن أقل فحسب، وإنما سيسمح لك بتمرير القيمة الافتراضية لكل الأبناء، ما يمنع ظهور الحالات التي تصادف فيها خطأً لأنك نسيت تعليمةً ضمن مستوىً أدنى. يمكن أن يكون ذلك مشكلةً كبيرةً في الإعدادات الطويلة. إن التصريح في مستوىً عالي يوفّر لك قيمةً افتراضيةً صحيحة. استخدام عدة سياقات أشقاء عوضا عن المنطق الشرطي If في المعالجةعندما تريد معالجة الطلبات كل بشكل مختلف، اعتمادًا على بعض المعلومات التي يمكنك ايجادها ضمن طلب المستخدم، فعادةً ما يلجئ المستخدمون إلى سياق if ليحاولوا معالجتها شرطيًا. هنالك بعض المشاكل المترافقة مع ذلك كنا قد ذكرناها سابقًا بإيجاز. أول مشكلة هي أنّ تعليمة if عادةً ما تعيد نتائج لا تتوافق مع توقعات مدير النظام administrator. مع أنّ المعالجة ستُؤدي دائمًا إلى نفس النتائج عند توفير نفس المُدخلات، إلا أنّ الطريقة التي يتبعها Nginx في تفسير البيئة يمكن أن تختلف كثيرًا عما هو متوقع ما ام تخضع لاختبارات مكثّفة. السبب الثاني هو أنّ هنالك تعليمات معدّة لهذا الغرض بالتحديد، وهي مستخدمةٌ للعديد من تلك الأغراض. يستخدم Nginx خوارزمية انتقاء - ذات توثيق جيد - لاختيار كتل الخادوم وكتل الموقع. لذلك، يفضّل نقل الإعدادات المختلفة إلى الكتل المخصّصة لها إن كان ذلك ممكنًا، ما يسمح لتلك الخوارزمية بمعالجة منطق عملية الاختيار. فمثلًا، عوضًا عن الاعتماد على إعادة الكتابة rewrites للحصول على طلب المستخدم بالشكل format الذي ترغب بالعمل به، فعليك أن تجرّب إعداد كتلتين للطلب، أحدهما تمثّل الطريقة المرغوب بها، والأخرى تلتقط الطلبات العشوائية وتعيد توجيهها - وقد تعيد كتابتها - للكتلة الصحيحة. عادةً ما تكون النتائج أسهل للقراءة كما أنها تمتلك محاسن كونها ذات أداء عالي. لا تخضع الطلبات الصحيحة لأي معالجة إضافية وفي العديد من الحالات يمكن تجاوز الطلبات غير الصحيحة عبر تعليمة إعادة التوجيه عوضًا عن تعليمة إعادة الكتابة والتي ينبغي أنّ يكون عبء تنفيذها أقل. الخلاصةإلى هنا، ينبغي أن تكون قد حصلت على فهم جيّد لأكثر سياقات Nginx شيوعًا وللتعليمات التي تُنشئ الكتل التي تعرّف تلك السياقات. تحقّق دائمًا من توثيق Nginx للحصول على معلومات حول أي السياقات هو الأنسب لوضع تعليمة ما بداخله ولتقييم الموقع الأكثر فاعلية. إنّ الحرص أثناء إنشاء الإعدادات لن يسهل من عملية الصيانة فحسب، بل أنه سيرفع الأداء أيضًا في أغلب الآحيان. ترجمة -بتصرف- للمقال Understanding the Nginx Configuration File Structure and Configuration Contexts لكاتبه Justin Ellingwood.