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

مقدّمة يعدّ Composer أحد أكثر الأدوات شيوعا بين مطّوري PHP، فهو مستخدم لإدارة الاعتمادات Dependency management إذ يُسهّل كثيرا من تثبيت وتحديث المكتبات البرمجيّة التي يحتاجها المشروع قيد التطوير. يتحقّق Composer من المكتبات التي يعتمد عليها المشروع ويثبّت الإصدار المناسب منها لمتطلّبات المشروع. يشرح هذا المقال كيفية تثبيت Composer واستخدامه على توزيعة أوبونتو 16.04. سنفترض في هذا المقال أن لديك خادوما يعمل بالإصدار المذكور، إضافة إلى مستخدم أعلى Super user. تثبيت الاعتمادات ينبغي أن نتأكّد أولا، قبل تنزيل Composer، أن حزم البرامج التي يحتاجها موجودة على نظام التشغيل لدينا. نبدأ بتحديث فهرس الحزم: sudo apt-get update ثم نثبّت الحزم المطلوبة: sudo apt install curl php-cli php-mbstring git unzip نحتاج curl لتنزيل Composer وphp-cli لتثبيته وتشغيله. ستكون الحزمة php-mbstring مطلوبة لاستخدام دوال تحتاجها مكتبة سنستخدمها لاحقا. بالنسبة لـ git فيحتاجه Composer لتنزيل اعتمادات المشاريع؛ أما unzip فيُستخدَم لاستخراج ملفات Zip. تنزيل Composer وتثبيته يوفّر Composer برنامج تثبيت مكتوبا بـ PHP. تأكّد من أنك موجود في المجلّد الشخصي للمستخدم ثم احصُل على ملف التثبيت بالأمر curl على النحو التالي: cd ~ curl -sS https://getcomposer.org/installer -o composer-setup.php ينزّل الأمر السابق ملف التثبيت ويحفظه في المجلد الشخصي باسم composer-setup.php. سنتأكّد من أن الملف الذي نزّلناه يوافق التجزئة Hash الخاصة بالملف على موقع Composer للتأكد من سلامته. افتح الصفحة التاليّة وانسخ سلسلة المحارف تحت العنوان Installer Signature (SHA-384) المكوّنة من 96 محرفا مكان SHA-384 في السكربت أدناه، بين الظفرين: php -r "if (hash_file('SHA384', 'composer-setup.php') === '**SHA-384**') { echo 'Installer verified'; } else { echo 'Installer corrupt'; unlink('composer-setup.php'); } echo PHP_EOL;" ينبغي أن يطبع السكربت الجملة التالية: Installer verified نثبّت Composer على النحو التالي ليكون متاحا على أي مجلّد في النظام” sudo php composer-setup.php --install-dir=/usr/local/bin --filename=composer ينزّل اﻷمر أعلاه Composer ويجعل الأمر composer متاحا على كامل النظام: All settings correct for using Composer Downloading 1.4.1... Composer successfully installed to: /usr/local/bin/composer Use it: php /usr/local/bin/composer للتحقّق من التثبيت نفّذ الأمر composer بدون تمرير معطيات. تظهر النتيجة التالية: ______ / ____/___ ____ ___ ____ ____ ________ _____ / / / __ \/ __ `__ \/ __ \/ __ \/ ___/ _ \/ ___/ / /___/ /_/ / / / / / / /_/ / /_/ (__ ) __/ / \____/\____/_/ /_/ /_/ .___/\____/____/\___/_/ /_/ Composer version 1.4.1 2017-03-10 09:29:45 Usage: command [options] [arguments] Options: -h, --help Display this help message -q, --quiet Do not output any message -V, --version Display this application version --ansi Force ANSI output --no-ansi Disable ANSI output -n, --no-interaction Do not ask any interactive question --profile Display timing and memory usage information --no-plugins Whether to disable plugins. -d, --working-dir=WORKING-DIR If specified, use the given directory as working directory. -v|vv|vvv, --verbose Increase the verbosity of messages: 1 for normal output, 2 for more verbose output and 3 for debug Available commands: (...) يعني هذا أن Composer ثُبِّت بنجاح على نظامك. يمكنك كذلك أن تبقي على ملفات Composer تنفيذية خاصّة بكل مشروع بدلا من أن يكون الأمر composer متاحا على كامل النظام. تفيد هذه الطريقة أيضا مفيدة إذا كان المستخدم لا يملك صلاحيات تثبيت الأداة على كامل النظام. في هذه الحالة يكون التثبيت بتنفيذ الأمر التالي بعد تنزيل ملف التثبيت والتحقق منه: php composer-setup.php سيولّد الأمر أعلاه ملف composer.phar في المجلد الذي نُفِّذ فيه الأمر. لتشغيل Composer بعد التثبيت بهذه الطريقة نفّذ الأمر من داخل مجلّد التثبيت: ./composer.phar توليد ملف composer.json ثبّتنا Composer ونحن الآن جاهزون لاستخدامه. أولّ ما يجب علينا فعله لاستغلال إمكانيّات Composer هو إنشاء ملف composer.json. دور ملف composer.json هو إخبار Composer بالمكتبات البرمجيّة التي يحتاجها المشروع الذي نعمل عليه (الاعتمادات)، مع تحديد الإصدارات المطلوبة. من المهمّ جدا تحديد الإصدارات بحيث تتناسق مع مشروعك وتتجنّب تثبيت إصدارات غير مستقرّة قد تؤثّر سلبا على ما تعمل عليه. ليس ضروريّا إنشاءُ ملف composer.json يدويّا، بل إن ذلك يجعل احتمال الأخطاء المطبعيّة في الصياغة أكبر. يولّد Composer ملف composer.json تلقائيا عند إضافة متطلّبات جديدة إلى المشروع بالأمر composer require. يمرّ استخدامُ Composer لتثبيت اعتماد جديد عادة على الخطوات التاليّة: تحديد نوع المكتبة البرمجيّة التي يحتاجها مشروعك. البحث عن مكتبة مناسبة على الموقع Packagist.org، وهو المستودع الرسمي لحزم Composer. اختيار المكتبة البرمجية التي تريد استخدامها في مشروعك. استعمال الأمر composer require لإضافة المكتبة إلى الملف composer.json. تثبيت الحزمة. سنعرض في ما يلي تطبيقا تجريبيا نطبّق من خلاله هذه الخطوات. سيكون الهدف من التطبيق تحويل جملة معيّنة إلى سلسلة محارف تصلح لتكون جزءا من رابط URL، ضمن ما يُعرَف بـ Slug. تُستخدَم هذه الطريقة كثيرا لجعل عنوان صفحة رابطا لها +(تنطبق هذه الملاحظة على المقال الذي تقرأه الآن). نبدأ بإنشاء مجلّد للمشروع نسمّيه slugify ضمن المجلّد الشخصي للمستخدم: cd ~ mkdir slugify cd slugify البحث عن حزم مكتبات على Packagist حان الآن موعد البحث عن مكتبة على Packagist.org لاستخدامها في توليد Slug في مشروعنا. إن بحثت على الموقع عن الكلمة المفتاحية slug فستجد نتائج تشبه التالي. يظهر عددان في الجانب الأيمن لكلّ حزمة في قائمة نتائج البحث. يدلّ العدد الأعلى على مرات تثبيت الحزمة، أما العدد الأسفل فيعني عدد المرات التي حصلت فيها الحزمة على نجمة على Github. يمكنك إعادة ترتيب الحزم حسب هذين العدديْن. عموما، كل ما كانت التثبيتات والنجوم أكثر كلّ ما دلّ ذلك على ثبات الحزمة؛ إلا أن من المهمّ قراءة وصف الحزمة حتى تتأكد من موافقتها لما تريد. نحتاج لمكتبة بسيطة تحوّل الجمل إلى سلسلة محارف لاستخدامها في الروابط. يبدو من أوصاف الحزم في نتائج البحث أن الحزمة cocur/slugify (لا تظهر في لقطة الشاشة أعلاه) مناسبة لنا، كما أن عدد مرات تثبيتها ونجومها مقبول، لذا سنختارها. ربما لاحظت أن أسماء الحزم على Packagist تتضمّن خانتين مفصولتين بشريط مائل. تحيل الخانة الأولى إلى الشركة أو الشخص المطوِّر للحزمة Vendor (وهو cocur في الحزمة التي اخترناها)، أما الخانة الثانيّة فهي اسم الحزمة (slugify). تشكّل الخانتان فضاء أسماء خاصًّا بالحزمة، وهو ما سنمرّره للأمر composer require عند طلب إضافة الحزمة إلى اعتمادات مشروعنا. جعل حزمة من متطلبات المشروع نعرف الآن ماهي الحزمة البرمجيّة التي نريد الاعتماد عليها في مشروعنا. الخطوة المواليّة هي إخبار Composer أن هذه الحزمة مطلوبة لمشروعنا؛ لذا سننفّذ الأمر composer require ونمرّر له فضاء الأسماء الخاصّ بالحزمة: composer require cocur/slugify تظهر مُخرجات الأمر التالية: Using version ^2.5 for cocur/slugify ./composer.json has been created Loading composer repositories with package information Updating dependencies (including require-dev) Package operations: 1 install, 0 updates, 0 removals - Installing cocur/slugify (v2.5): Downloading (100%) Writing lock file Generating autoload files يقرّر Composer تلقائيا، كما يظهر في المخرجات أعلاه، أي إصدار من الحزمة البرمجية سيُثبِّت. إن تحقّقت الآن من مجلّد المشروع فستجد ملفّيْن جديديْن هما composer.json وcomposer.lock ومجلدًّا فرعيّا جديدا باسم vendor: ls -l النتيجة: total 28 -rw-rw-r-- 1 zeine77 zeine77 59 Apr 10 15:15 composer.json -rw-rw-r-- 1 zeine77 zeine77 2901 Apr 10 15:15 composer.lock drwxrwxr-x 4 zeine77 zeine77 4096 Apr 10 15:15 vendor يُستخدَم الملفّ composer.lock لحفظ معلومات عن إصدارات المكتبات البرمجيّة المثبّتة، والتأكّد من استخدام نفس الإصدارات عندما ينسخ مطوّر آخر مشروعك للعمل عليه. تُخزَّن في المجلّد vendor ملفّات المكتبات البرمجيّة. يجب ألّا يودَع Commit المجلّد vendor في نظام إدارة النسخ، بل يُكتفى بإيداع الملفيْن composer.lock وcomposer.json. عند تثبيت مشروع يحتوي على ملفّ composer.json ستحتاج إلى تنفيذ الأمر composer install من أجل تنزيل اعتمادات المشروع. فهم القيود على إصدارات الاعتمادات فلنطبع محتوى الملف composer.json: cat composer.json تظهر النتيجة التاليّة (قد يختلف الإصدار قليلا لديك): { "require": { "cocur/slugify": "^2.5" } } ربّما لاحظت المحرف الخاصّ ^ أمام رقم الإصدار في الملفّ composer.json. يدعم Composer صيغًا وشروطا مختلفة لتحديد الإصدارات المطلوبة من الحزم والمكتبات البرمجيّة، من أجل الحفاظ على ثبات المشروع مع السماح بمرونة أكبر حسب الحاجة. يُنصَح بالعامل ^، المستخدَم عند توليد الملف composer.json تلقائيًّا، للحصول على أعلى قدر من الاستقرار. يعني استخدام ^ أن الإصدار 2.5 هو الإصدار الأدنى المتوافق مع المشروع، مع السماح بتحديث الحزمة في المستقل إلى أي إصدار يقلّ عن3.0. لن تحتاج في أغلب الحالات للتدخلّ وتحرير الملف composer.json لتعديل متطلّبات الإصدار يدويّا؛ إلا أنه توجد حالات يكون فيها هذا الأمر ضروريّا، كأن يُعلَن عن إصدار مهمّ من الحزمة يوفّر ميزات ترغب في الاستفادة منها أو عندما لا تتبع الحزمة التي تستخدمها ترقيما ذا دلالة متعارف عليه). يوضّح الجدول التالي أمثلة على تعريف القيود على الإصدارات في الملف composer.json. يظهر في العمود الأول القيدُ، وفي الثاني دلالة القيد وفي العمود الثالث أمثلة على إصدارات يسمح بها هذا القيد. Constraint Meaning Example Versions Allowed ^1.0 >= 1.0 < 2.0 1.0, 1.2.3, 1.9.9 ^1.1.0 >= 1.1.0 < 2.0 1.1.0, 1.5.6, 1.9.9 ~1.0 >= 1.0 < 2.0.0 1.0, 1.4.1, 1.9.9 ~1.0.0 >= 1.0.0 < 1.1 1.0.0, 1.0.4, 1.0.9 1.2.1 1.2.1 1.2.1 1.* >= 1.0 < 2.0 1.0.0, 1.4.5, 1.9.9 1.2.* >= 1.2 < 1.3 1.2.0, 1.2.3, 1.2.9 يحوي التوثيق الرسمي على شرح مفصّل حول طريقة طتابة القيود في الملف composer.json. تضمين سكربتات تُحمَّل تلقائيا يتيح Composer إمكانيّة التحميل التلقائي لسكربتات PHP، فيتولّى تحميل الأصناف Classes التي ترغب بتوفرها تلقائيا في تطبيقك. يجعل هذا الأمر من التعامل مع الاعتمادات وإنشاء فضاءات أسماء خاصّة بك أسهل كثيرا. كلّ ما تحتاجه لتحميل حزمة تلقائيا هو تضمين الملف vendor/autoload.php في سكربت PHP قبل استهلال Instantiation الصنف (لحظة إنشاء الكائن). نعود للتطبيق المثال slugify. سنستخدم محرر النصوص nano لإنشاء ملفّ باسم test.php داخل مجلّد المشروع الذي أنشأناه سابقا، من أجل استخدام cocur/slugify: nano test.php نضع المحتوى التالي في الملف test.php: <?php require __DIR__ . '/vendor/autoload.php'; use Cocur\Slugify\Slugify; $slugify = new Slugify(); echo $slugify->slugify('Hello World, this is a long sentence and I need to make a slug from it!'); يمكنك تشغيل السكربت من الطرفية على النحو التالي: php test.php تظهر نتيجة التنفيذ التالية: hello-world-this-is-a-long-sentence-and-i-need-to-make-a-slug-from-it تحديث اعتمادات المشروع يُستخدَم الأمر التالي لتحديث اعتمادات المشروع: composer update سيتحقّق الأمر من وجود إصدارات جديدة من المكتبات البرمجيّة المطلوبة لمشروعك، فإن وجد إصدارا جديدا يتوافق مع القيود المعرَّفة ضمن الملف composer.json فسيضعه مكان الإصدارات المثبتة. سيُحدَّث الملف composer.lock ليوافق التغييرات الجديدة. يمكنك كذلك تحديد مكتبات لتحديثها، دون أن تحدّث كامل المشروع، وذلك بتمريرها إلى الأمر composer update: composer update vendor1/package1 vendor2/package2 خاتمة أصبح استخدام Composer شائعا بين المطوّرين لدرجة أنه صار عمليًّا معيارا لتشارك المكتبات البرمجيّة واسكتشافها ممّا يعني أنه أداة ضروريّة لتكون من مجموعة الأدوات التي تعتمد عليها. ترجمة - بتصرّف - للمقال How To Install and Use Composer on Ubuntu 16.04 لصاحبه Brennen Bearnes.

تخيل معي الوضع التالي: أنت مُطور PHP، لديك مشروع تود تطويره، قد تختار إطار عمل مُعين لهذه المهمة، لكنك ستحتاج إلى بضعة مكتبات إضافية للقيام بذلك، تخيل بأنك تود أن يقوم تطبيقك بنشر تحديثات مُعينة على حساب المُستخدم على تويتر، وجدت المكتبة التي ترغب في استخدامها لكنها مكتبة تعتمد على مكتبة أخرى. مُطور PHP من العصر الحجري سيقوم بالتالي: سيقوم بتحميل نُسخة من إطار العمل، ومن ثم يقوم بإنشاء مُجلد يضع فيه المكتبات الإضافية التي يحتاجها ومن ثم يُحاول فهم آلية عملها ليربطها ببعضها البعض. قد تؤتي هذه الطريقة أكلها، وقد تسمح لك بتطوير مشروعك "من دون أية مشاكل"، لكن ماذا يحدث مثلا لو تم إطلاق تحديث لأي من المكتبات التي تعتمد عليها؟ هل ستقوم بإعادة تحميلها من جديد واستبدال الإصدار القديم بالجديد؟ هل يُمكن أن تفعل ذلك لو كنت تستخدم أكثر من مكتبة يعتمد بعضها على بعض؟ لست متأكدا من ذلك. لكن ما هو البديل؟ إن سبق لك أن استخدمت لُغات برمجة أخرى كـ javascript مع node.js أو ruby فإنه سبق لك أن تعاملت مع ما يُطلق عليه اسم مدير الحزم Package manager، حيث يتم استخدام npm مع node مثلا لتنصيب حزم وإضافات لـ node. يُمكن القول بأن موضع composer من PHP هو موضع npm من node.js، حيث يُتيح composer تحميل المكتبات التي تحتاجها في مشروعك والإبقاء عليها مُحدثة دون الحاجة إلى تحميلها ونقلها يدويا. رغم كل ذلك يُشير موقع composer الرسمي بأنه لا يُمكن أن نُطلق عليه اسم مُدير حزم بحكم أنه لا يقوم بتنصيب هذه الحزم بشكل عام على النظام global بل تتم إدارة الحزم داخل كل مشروع بشكل محلي، ولهذا يُطلق عليه وصف مُدير الاعتمادات Dependency Manager. تنصيب composer دعونا من الجانب النظري ولنقم بتنصيب composer ولنلق نظرة على كيفية استخدامه. بالرغم من أنه يُمكن تنصيبه بشكل محلي داخل كل مشروع إلا أنه يُفضل تنصيبه بشكل عام على النظام. على أنظمة Linux/Unix يكفي تنفيذ الأمرين التاليين لتنصيب composer: $ curl -sS https://getcomposer.org/installer | php $ mv composer.phar /usr/local/bin/composer قد تحتاج إلى إضافة sudo قبل الأمر الثاني إن احتجت إلى صلاحيات مدير النظام لتنفيذ الأمر. أما على أنظمة Windows فيكفي تحميل وتنصيب التطبيق الرسمي الخاص به. يُمكنك التحقق من إذا ما تم تنصيب composer بشكل صحيح على النظام بتنفيذ أمر composer في سطر الأوامر والذي من شأنه أن يُظهر المساعدة الخاصة به. استخدام Composer الآن وبعد أن قمنا بتنصيب composer سنحتاج إلى إنشاء ملف composer.json نقوم من خلاله بإعلام composer بالحزم التي نود إرفاقها والاعتماد عليها في مشروعنا الجديد، كما أنه يُمكن لهذا الملف أن يحتوي على بيانات أخرى سنحتاجها في بناء المشروع. يكون ملف composer.json في شكله الأبسط على النحو التالي: { "require": { "monolog/monolog": "1.0.*" } } في هذا المثال فإننا نعتمد على الإصدار 1.0.* من مكتبة monolog . بطبيعة الحال يُمكن الاعتماد على أكثر من مكتبة في مشروعنا الحالي، حيث يكفي إضافة سطر جديد لكل مكتبة ما بين حاضنتي require ويتكون كل سطر من اسم المكتبة (الذي عادة ما يحتوي على اسم الجهة المُنتجة لها متبوعة باسمها، وعادة ما يكون نفس الاسم مُكررا مرتين) إضافة إلى رقم الإصدار الذي نرغب فيه. يُمكن إيجاد هذه المكتبات وآليات إضافتها إلى مشروعك الخاص بالبحث على موقع https://packagist.org/. الآن وبعد أن حددنا المكتبات التي نرغب فيها يكفي أن نقوم بتنفيذ الأمر composer install أو php composer.phar install في حال ما إذا لم تقم بنقل composer.phar إلى مُجلد مساره موجود في مُتغير PATH الخاص بالنظام. سيقوم composer بتحميل جميع تلك المكتبات ووضعها داخل مُجلد vendor الذي سيتم إنشاؤه داخل مُجلد المشروع الحالي. Autoloading ولتجنيب المُطور من اللجوء إلى استدعاء هذه المكتبات واحدة واحدة لدى كتابته لمشروعه، يقوم composer بإنشاء ملف vendors/autoloader.php الذي يتولى إدارة ذلك حيث يكفي استدعاء هذا الملف لتتمكن من استخدام المكتبات التي حملتها من دون الحاجة إلى القيام بذلك يدويا: <?php require_once "vendors/autoloader.php"; تحديث المكتبات لدى صدور تحديث جديد للمكتبة التي تعتمد عليها فإنه يكفي تنفيذ الأمر للحصول عليها: composer update بطبيعة الحال إن كنت قد حددت إصدارا مُعينا في ملف composer.json فإنك لن تحصل على الإصدارات الأحدث ما لم تقم بتحديد الإصدار بشكل يسمح بالترقية الآلية. بعبارة أخرى إذا كنت تستعمل مثلا إطار عمل Laravel وقمت بإضافته باستخدام السطر التاليينlaravel/framework": "4.1.* فإنه سيتم التحديث إلى إصدار في التفرع 4.1 ولن يتم المرور إلى الإصدارات 4.2 أو التي تليها. Packagist Packagist عبارة عن موقع يتم تجميع فيه مكتبات PHP مفتوحة المصدر المتوفر للاستعمال من طرف الجميع باستخدام composer. حسب التوثيق الرسمي لـ composer فإنه لا يُشترط في المكتبة أن تكون على Packagist ليتم استدعاؤها من طرف Composer إلا أنه يُفضل إن أردت توفير مكتبتك للجميع أن تُسجلها على هذا الموقع. خلاصة إن كنت مُطور PHP وكنت تود أن تتطور مع تطور هذه اللغة وأن لا تبقى حبيس الإصدارات القديمة منها (الإصدار 4؟) فإنه يجب عليك أن تتبع أسلوبا مُختلفا في التطوير عن أسلوب مُطور PHP من العصر الحجري. من بين أولى الخطوات التي ستخطوها للوصول إلى ذلك هو الاستعانة بـ composer في جميع مشاريعك التي تعمل عليها حيث يُعتبر الغراء الذي يُلصق مُكونات مشروعك بعضها ببعض ويُسهل عليك مهمة التطوير. للمزيد حول composer وحول مُختلف المكتبات التي يُمكن الاستعانة بها في مشروعك قم بزيارة موقعه الرسمي وموقع Packagist.

يسألني الناس أينما ذهبت - في المؤتمرات، المحاضرات، لدى وكالات تطوير المواقع وغيرها - عن ملف composer.lock. يبدو وكأن الأمر يتعلّق بلغز يزرع الشكوك حول المعمورة! أقدّم لك هذا المقال لتوضيح ماهية هذا الملف وفكّ اللغز الذي يمثّله. يعدّ Composer أداة تدير الإصدارات الخاصة بمكتبات PHP التي يستخدمها المطوّرون في مشاريعهم البرمجية. سأفترض - لأغراض هذا المقال - أنه سبق لك استخدام Composer في مشاريع سابقة. فلنفترض أن لدينا مشروع PHP جديدا ندير اعتماديّاته Dependencies عن طريق Composer. نبدأ بملف composer.json الذي يُستخدَم لإعداد لائحة بالاعتماديّات التي نريد تثبيتها. يبدو الملف على النحو التالي: { "require": { "assassins/ezio": "1.1.0", "assassins/edward": "1.1.2", "templars/shay": "1.1.*", } } عرّفنا بوضوح الإصدارات التي نحتاجها بالنسبة للحزمتين الأولى والثانية؛ إلا أن الأمر مختلف قليلا يالنسبة للحزمة الثالثة templars/shay التي حدّدنا لها بطريقة أكثر مرونة فلم نعرّف إصدار الترقيع Patch version؛ وبالتالي سيكون أي ترقيع للإصدار 1.1 مناسبا للمشروع. تنبغي ملاحظة أن هذه الأسماء المذكورة في الشفرة أعلاه هي أسماء مفترضة لحزم وليست حزما حقيقية يمكن تثبيتها. يمكن القول إن ملف composer.json هو دليل “تقريبي” للإصدارات التي نريد تثبيتها؛ فاستخدام ماسك المكان * يجعل إصدارات عدّة متوافرة لاستخدامها. بمعنى آخر، يحدّد الملف هامشا مقبولا لهرميّة الاعتماديّات في التطبيق. لا يوجد لدينا لحدّ الساعة، أي في بداية المشروع، ملفّ composer.lock؛ إلا أنه سيظهر بعد تنفيذنا للأمر composer install. نجد مباشرة بعد تنفيذ الأمر composer install ملفّا غريبا باسم composer.lock في المجلّد الجذر للمشروع. إن ألقيت نظرة على ما بداخله فستجد أنه كبير نوعا ما. حان الوقت الآن لكشف اللّغز. في الواقع؛ الملف composer.json هو دليل تقريبي - كما قلنا - لإصدارات الاعتماديّات التي يتوجّب على Composer تثبيتها، بينما الملف composer.lock هو تسجيل دقيق بالإصدارات التي ثُبِّتت عند تنفيذ الأمر composer install. أي أنه يسجّل ما ثبّته Composer من مكتبات لمشروعك. في ما يلي مثال بسيط: "source": { "type": "git", "url": "https://github.com/templars/shay.git", "reference": "98c313c831e5d99bb393ba1844df91bab2bb5b8b" }, هل ترى سلسلة المحارف الطويلةَ تلك؟ هذا هو المعرّف الدقيق لإيداع Commit الإصدار المثبّت عندما اتّبع Composer تعليمات composer.json. يحتفظ الملف composer.lock كذلك بجميع إصدارات الاعتماديّات التي تتطلّبها اعتماديّات المشروع؛ والمكتبات التي تقوم عليها اعتماديّات اعتمديّات المشروع.. وهكذا دواليك. يعني هذا أن الملف composer.lock يحوي التسلسل الهرمي الكامل لاعتماديّات التطبيق. في ماذا يفيد وجود التسلسل الهرمي لاعتماديّات المشروع في الملف composer.lock؟ حسنا؛ يمكن أن تجرّب حذف المجلّد الذي توجد به اعتماديّات المشروع، مثلا vendor في Laravel؛ ثم تنفيذ الأمر composer install من جديد. سيجد Composer هذه المرة أن لديك ملفّ composer.lock وبدلا من البحث عن إصدارات متوافقة مع تعليمات الملف composer.jsonفسيلجأ إلى الإصدارات الدقيقة المذكورة في الملف composer.lock ويثبّتها. يعني هذا أننا سنحصُل على نفس المكتبات التي حذفناها بحذف مجلّد الاعتماديّات. سؤال آخر.. هل يجب تضمين الملف composer.lock في مستودع Git؟ يجب أن تكون الإجابة الآن واضحة. إن أردت تسجيل الإصدارات الدقيقة للاعتماديّات التي استخدمتها في المشروع فالإجابة هي نعم؛ وهذا هو الواقع في أغلب المشاريع. إن كنت تعمل ضمن فريق مطوّرين فإن جعل الملف composer.lock في المستودع يضمن أن الجميع يستخدم نفس الإصدارات؛ الأمر الذي يمكن أن يكون مفيدا في تنقيح Debugging الأخطاء التي تظهر لدى مطوّر واحد فقط من الفريق. إن كنت توزّع تطبيقك عبر Git فإن تضمين الملف composer.lock في المستودع سيضمن أن إصدارات الاعتماديّات التي استخدمتها في التطوير وأجريت عليها الاختبارات هي نفسها المستخدمة في بيئة الإنتاج. لماذا من المهم استخدام نفس إصدارات الاعتماديّات؟ فلنفترض أن Git يتجاهل وجود الملف composer.lock. تنفّذ الأمر composer install، يبحث Composer عن آخر ترقيع للإصدار 1.1 من الحزمة templars/shay فيجد الإصدار 1.1.4 ويثبّته. تعمل على المشروع باستخدام الإصدار 1.1.4، وفي هذه الأثناء يقدّم فريق الحزمة templars/shay الإصدار 1.1.5 الذي - لسوء الحظ - يتضمّن علة برمجيّة Bug حرجة. عندما تنشُر مشروعك على بيئة الإنتاج يثبّت Composer - بالاعتماد على تعليمات الملف composer.json - الإصدار 1.1.5 من الحزمة الذي يحوي علّة تمنع تطبيقك من العمل على النحو الذي تريده. يمكنك استنتاج أنه لو كان الملف composer.json في المستودع لأدّى تنفيذ الأمر composer install في بيئة الإنتاج إلى تثبيت الإصدار 1.1.4 من الحزمة templars/shay الذي سبق لك اختبار التطبيق معه. باختصار: في الأخير.. متى يتغيّر الملف composer.lock ولأي سبب؟ أرى طوال الوقت مطورين ينفّذون الأمر composer update كلّما حدّثوا الملف composer.json، للحصول على الحزم الجديدة التي أضافوها إلى الملف. في الواقع هذا الأمر خاطئ! يجب أن تستخدم الأمر composer install بدلا من ذلك، إذ أنه يثبّت الحزم الجديدة دون تحديث إصدارات الحزم الأخرى؛ هذه الطريقة آمن كثيرا. في ما يلي لائحة بإجراءات تتسبّب في تحديث الملف composer.lock: تنفيذ الأمر composer install للمرة الأولى. يُنشَأ الملف composer.lock لتسجيل الإصدارات الدقيقة للاعتماديّات المثبّتة. تنفيذ الأمر composer install بعد إضافة حزم جديدة. يُضاف الإصدار الدقيق للحزمة إلى الملف composer.lock. تنفيذ الأمر composer update. تُحدَّث إصدارات جميع الحزم إلى الترقيع الأخير بما يتوافق مع تعليمات الملف composer.json، وهو ما ينتُج عنه تحديث الإصدارات الدقيقة في الملف composer.lock. تنفيذ الأمر composer update package/name لتحديث الحزمة المذكورة إلى آخر ترقيع، بما يتوافق مع تعليمات الملف composer.json، وبالتالي يُحدَّث الملف composer.lock ليعكس التغيير الحاصل في إصدار الحزمة. يعني ما سبق أن composer install أمر “آمن”، ولن ينتُج عنه سوى إضافة حزم جديدة إلى الملف composer.lock (وليس تحديث حزم موجودة مسبقا). في حين أن الأمر composer update أمر “خطِر”، إذ أنه يتسبّب في تغيير مباشر على الإصدارات الدقيقة الموجودة في الملف composer.lock . أرجو أن يكون الملف اللغز composer.lock قد اتّضح لك بعد قراءة هذا المقال. إن كنت تعلّمت شيئا أو اثنين من هذا المقال فأرجو أن تشاركه مع أصدقائك حتى يعرفوا هم أيضا سر الملف العظيم. ترجمة - بتصرّف - للمقال PHP: The Composer Lock File لصاحبه Dayle Rees. حقوق خلفية الصورة البارزة محفوظة لـ Freepik

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

Composer هو أداة لإدارة الاعتماديات في لغة PHP، تخيل أنّك تعمل على مشروع يتضمن العديد من الاعتماديات التابعة لمشاريع أو مكتبات أخرى. سيدير Composer بالطرق التالية: تحميل مكتبة الاعتمادية من مستودعاتها إلى مشروعك بصورة تلقائية. يمكنك وبكلّ سهولة تحديث مكتبتك عند ظهور إصدار جديد منها. عند تحميل مكتبة الاعتمادية يتحقّق composer من المتطلبات الدنيا للخادوم. سينشئ Composer ملف autoloader.php لجميع المكتبات المحمّلة وسيحمّل الاعتمادية كاملةً في المشروع الذي تعمل عليه. ماذا سيحصل إن لم تستخدم Composer؟ ستضطرّ إلى تحميل مكتبة الاعتمادية يدويًّا. يجب عليك التحقّق من الإصدارات الجديدة للمكتبات دوريًّا، وتحميل الملفات إلى المشروع يدويًّا. يجب عليك تحميل جميع المكتبات إلى مشروعك باستخدام دالتي require أو include. إليك المثال التالي لتوضيح ما سبق: لديك مشروع تعمل عليه باستخدام إطار عمل Cakephp أو Laravel، وترغب في إضافة خاصية إرسال الرسائل إلكترونية إلى المشروع وتحتاج إلى اتصال من نوع SMTP. ستقوم حينها بتحميل إحدى المكتبات المتخصّصة في هذا المجال مثل Phpmailer أو Swiftmailer. إن استخدمت composer للحصول على هذا المكتبات، فسيكون بميسورك تحميل المكتبة المطلوبة مباشرة إلى مجلد vendor ضمن المشروع. وإن حصلت هذه المكتبة على تحديث جديد، يكفي أن تنفّذ أمرًا واحدًا في سطر الأوامر، ولن تكون بحاجة إلى التحقّق ممّا إذا كان التحديث متوافقًا مع الإصدار 5.4 أو 5.3 من php. سيتّضح الأمر أكثر فأكثر من خلال الأمثلة التالية. كيف يتم تثبيت Composer في النظام قبل تثبيت composer يجب التحقّق من أنّك تعمل على الإصدار 5.4 وما بعده من لغة PHP. إن كنت من مستخدمي نظام ويندوز فيمكنك تحميل الملف التنفيذي الخاص بتثبيت Composer وذلك من الرابط: https://getcomposer.org/، وتنصيب Composer في نفس المجلد الذي قمت بتثبيت php.exe فيه. (C:\wamp\bin\php\php5.5.12 مثلاً). أما مستخدمو نظامي Linux و Mac فيمكنهم فتح الطرفية وكتابة الأمر التالي فيها: curl -sS https://getcomposer.org/installer | php سيقوم هذا الأمر بتحميل ملف composer.phar (phar تعني php archive) بواسطة الأداة curl، وللوصول إلى composer من أي مكان في حاسوبك يجب عليك نقل هذا الملف إلى المجلد /usr/bin/composer، وذلك بتنفيذ الأمر التالي في الطرفية: sudo mv composer.phar /usr/bin/composer للتحقق من وجود Composer يكفي الدخول إلى سطر الأوامر في ويندوز أو الطرفية في Linux و Mac وكتابة كلمة composer والضغط على زر الإدخال Enter. إن كان Composer مثبّتًا في جهازك ستظهر شاشة الترحيب التالية إضافة إلى جميع ا لأوامر المستخدمة في composer. تطبيق عملي لاستخدام مكتبة Composer سيبحث Composer عن الملف composer.json حيث سندرج جميع الاعتماديات التي نحتاج إليها في المشروع. لننشئ مجلّدًا جديدًا بواسطة الأمر التالي: mkdir composer_example ادخل إلى المجلد: cd composer_example أنشئ ملف composer.json هنا، وأضف إليه ما يلي: { "require": { "jdorn/sql-formatter": "1.3.*@dev" } } هنا jdorn هو اسم صاحب الحزمة sql-formatter التي نرغب في تثبيتها ضمن المشروع. ولكن قد تتسائل من أين سيأتي Composer بهذه الحزمة. في الواقع هناك موقع إلكتروني آخر هو Packagist يتضمّن جميع المكتبات الشائعة ويمكن تصفّحها من خلال الموقع. مكتبة sql-formatter عبارة عن صنف php صغير الحجم يعمل على تنسيق عبارات SQL حيث يضبط الإزاحات في بداية العبارة تلقائيًا كما يدعم تلوين الكلمات المفتاحية. بعد أن أعددنا ملف composer.json يمكننا تحميل وتنصيب الملفات المطلوبة في مجلد المشروع بواسطة الأمر: composer install سيتم تحميل جميع الملفات المطلوبة ومن ضمنها ملفات autoload إلى المجلد composer_example/vendor. والآن أنشئ ملفًّا باسم index.php في المجلد composer_example واجلب فيه الملف autoload.php باستخدام الدالة require وبذلك سيتمّ تحميل جميع الاعتماديات في هذا الملف. إليك المثال التالي: <?php require "vendor/autoload.php"; $query = "SELECT count(*),`Column1`,`Testing`, `Testing Three` FROM `Table1` WHERE Column1 = 'testing' AND ( (`Column2` = `Column3` OR Column4 >= NOW()) ) GROUP BY Column1 ORDER BY Column3 DESC LIMIT 5,10"; echo SqlFormatter::format($query); ?> لاحظ مدى سهولة وسرعة التعامل مع الاعتماديات بواسطة Composer. لننشئ مشروعًا آخر لنفترض أننا نرغب في إضافة إطار عمل Codeigniter بواسطة Composer. لن نستخدم هذه المرّة الأمر composer install بل سنستخدم الأمر composer create-project لإنشاء مشروع جديد. توجّه إلى موقع Packagist وابحث عن مكتبة Codeigniter، ثم حمّل نسخة من إطار العمل إلى مجلد المشروع الذي تعمل عليه: composer create-project codeigniter/framework مجلد المشروع بعد اكتمال العملية ستجد ملف composer.json في مجلد المشروع، ويمكن إضافة المزيد من الاعتماديات إلى مشروعك بواسطة هذا الملف. لنفترض أنّك ترغب في استخدام حزمة sql-formatter في مشروعك هذا. توجّه إلى ملف composer.json وعدّله ليصبح بالصورة التالية: { "description" : "A way to install CodeIgniter via composer", "name" : "rogeriopradoj/codeigniter", "license": "OSL-3.0", "require": { "php": ">=5.2.4", "jdorn/sql-formatter": "1.3.*@dev" } } ثمّ حدّث الاعتماديات بواسطة الأمر: composer update والآن إن كنت ترغب في رفع هذا المشروع إلى Github أو مشاركته مع أحد الأصدقاء، لن تكون بحاجة إلى إرسال مجلد vendor، بل يكفي أن ترسل الملف composer.json وسيكون بميسور صديقك تحميل جميع الاعتماديات المطلوبة والمستخدمة في المشروع. عليك بتجربة composer، إذ تستخدمه معظم أطر عمل php المعروفة مثل Laravel، Symfony 2 و Yii إضافة إلى بعض حزم php الرائعة التابعة لـ Phpleague. فماذا تنتظر إذًا؟ ترجمة - وبتصرّف - للمقال Composer easy tutorial – php dependency management tool لصاحبه Arkaprava Majumder.

سنعرض في هذا الدرس كيفية تثبيت إطار عمل Laravel وطريقة إعداده ثم نكتشف المجلدات المكوِّنة للإطار. هذا الدرس جزء من سلسلة تعلم Laravel والتي تنتهج مبدأ "أفضل وسيلة للتعلم هي الممارسة"، حيث ستكون ممارستنا عبارة عن إنشاء تطبيق ويب للتسوق مع ميزة سلة المشتريات. يتكون فهرس السلسلة من التالي: مدخل إلى Laravel 5. تثبيت Laravel وإعداده على كلّ من Windows وUbuntu. (هذا الدرس) أساسيات بناء تطبيق باستخدام Laravel. إنشاء روابط محسنة لمحركات البحث (SEO) في إطار عمل Laravel. نظام Blade للقوالب. تهجير قواعد البيانات في Laravel. استخدام Eloquent ORM لإدخال البيانات في قاعدة البيانات، تحديثها أو حذفها. إنشاء سلة مشتريات في Laravel. الاستيثاق في Laravel. إنشاء واجهة لبرمجة التطبيقات API في Laravel. إنشاء مدوّنة باستخدام Laravel. استخدام AngularJS واجهةً أمامية Front end لتطبيق Laravel. الدوّال المساعدة المخصّصة في Laravel. استخدام مكتبة Faker في تطبيق Laravel لتوليد بيانات وهمية قصدَ الاختبار. يتكون جانب التثبيت في هذا الدرس من جزأين، الأول لنظام تشغيل وندوز وسيكون الاعتماد فيه على برنامج Laragon؛ أما الجزء الثاني فهو موجَّه لتوزيعة لينكس Ubuntu 14.04. وقع الاختيار على Laragon لسهولة العمل عليه إذ يأتي مضمَّنا بإطار عمل Laravel ولا يتطلب سوى إعدادات يسيرة، كما أنه يوفر واجهة أوامر Shell تتيح تنفيذ بعض أوامر Linux. يغطي الدرس المواضيع التالية: متطلبات تثبيت Laravel تثبيت Laravel باستخدام Composer التحقق من نجاح تثبيت Laravel بنية المجلدات في Laravel إعداد مشروع عمل جديد في Laravel متطلبات تثبيت Laravel يجب قبل البدء في تثبيت Laravel التأكد من توفر العناصر التالية: خادوم ويب (Apache). الإصدار 5.5.9 من PHP لتثبيت الإصدار 5.2 من Laravel. قاعدة بيانات (MySQL). أداة Composer. تفعيل الوحدات المطلوبة على كلّ من PHP (وهيّ OpenSSL، PDO ،Mbstring وTokenizer) وتعليمة mod_rewrite على Apache . بيئة تطوير IDE (اختياري). تتناول الفقرات التالية آلية تثبيت هذه العناصر على كل من نظام تشغيل Windows و توزيعة Ubuntu 14.04. ملحوظة: سنعتمد في هذه السلسلة على الإصدار 5.2 من إطار العمل Laravel. قد توجد اختلافات طفيفة مع الإصدارات اللاحقة؛ إلا أن المبدأ العام هو نفسه. تهيئة بيئة العمل على Windows توجد برامج عدة تمكن من الحصول على بيئة تطوير Apache PHP MySQL على Windows ومن أشهرها XAMPP وWAMP. يوجد أيضا خيار آخر وهو برنامج Laragon الذي يتضمن خدمات أخرى إضافة للثلاثة المذكورة، من بينها أداة Composer لإدارة الاعتماديات Dependencies والتي تسهل من تثبيت Laravel وإنشاء مشاريع تعمل عليه كما سنرى لاحقا. تثبيت Laragon نبدأ بتنزيل برنامج Laragon من الموقع الرسمي ثم تثبيته. اختر أثناء التثبيت مجلد عمل Laragon: سيقترح عليك المثبِّت تفعيل إنشاء المضيفات الافتراضية Virtual hosts تلقائيا. تمكّن هذه الميزة من إنشاء مضيف افتراضي لكل مجلد يُنشأ ضمن أصل المستند Document root (أي \C:\laragon\www في حالتنا). يعني هذا أنه عند إنشاء مجلد باسم wordpress على المسار \C:\laragon فإن مضيفا افتراضيا باسم wordpress.dev يحيل إلى هذا المجلد سيُعد تلقائيا. نكمل عملية التثبيت: بإكمال تثبيت Laragon نكون قد ثبّتنا كلّا من خادوم ويب Apache، قاعدة بيانات MySQL وأداة إدارة الاعتماديات Composer. نشغل الخدمات بالضغط على زر Start All. تظهر الخدمات المشغَّلة (خادوم ويب Apache وقاعدة بيانات MySQL) في الواجهة الرئيسية للبرنامج. يمكننا الآن إنشاء مشروع Laravel للعمل عليه. سنستخدم سطر الأوامر لهذا الغرض. توجد إمكانية إنشاء مشروع من واجهة البرنامج بالذهاب إلى قائمة: Menu -> Laravel -> Create project -> Laravel 5 اضغط على زر Shell لإظهار سطر الأوامر. تبدو واجهة سطر الأوامر على النحو التالي: إنشاء مشروع Laravel باستخدام أداة Composer تُستخدَم أداة Composer لإدارة الاعتماديات في برمجيات PHP. يقوم مبدأ عملها على التصريح بالمكتبات والعناصر اللازمة للمشروع وستتولى الأداة تثبيتها وإدارة تحديثاتها. اكتب الأمر التالي في نافذة سطر الأوامر: composer create-project --prefer-dist laravel/laravel larashop "5.2.*" ستحصُل على مخرجات مشابهة لما يلي: ننتظر اكتمال تثبيت Laravel وإنشاء مشروع larashop: يثبت الأمر السابق Laravel وينشئ مشروع Laravel باسم larashop في المجلد \C:\laragon\www الذي هو أصل المستند. ملحوظة: إذا كان إصدار Composer المضمّن في Laragon قديما فسيظهر لديك تحذير - قد يكون مصحوبا بخطأ في التثبيت - عند تنفيذ أمر Composer. للتخلّص من هذا التحذير، وتجاوز الخطأ، حدّث Composer بتنفيذ الأمر أدناه في نافذة سطر الأوامر: composer self-update نفعّل بعد اكتمال تثبيت Laravel وإنشاء مشروع larashop، خدمة PHP Server على المنفذ 8000 في واجهة Laragon بالذهاب إلى القائمة Menu ثم خيار Preferences ثم تبويب Services & Ports ثم التأشير على الصندوق المناسب كما في الصورة أدناه. ستلاحظ ظهور سطر جديد في واجهة البرنامج باسم الخدمة التي فعّلناها للتو. اختبار التثبيت يمكننا الآن التحقق من أن كل شيء جرى على ما يُرام؛ إما بالذهاب إلى واجهة Laragon ثم اختيار: Menu -> www -> larashop أو إدخال المسار التالي في شريط عنوان المتصفح: http://localhost/larashop/public/ أو اسم المضيف التالي (إن كنت تركت خيار إنشاء المضيفات الافتراضية تلقائيا أثناء تثبيت Laragon): http://larashop.dev يجب أن تظهر صفحة الويب التالية في المتصفّح دلالة على أن كل شيء وُضع في مكانه الصحيح: تهيئة بيئة العمل الخاصة بـLaravel على لينكس يتلخّص إعداد بيئة العمل الخاصة بـLaravel على لينكس بالخطوات التاليّة. تثبيت Apache، PHP وMySQL نبدأ بتثبيت حزم LAMP على أوبنتو. توجد خطوات التثبيت بالتّفصيل في درس كيف تُثبِّت حِزم MySQL، Apache، Linux :LAMP وPHP على Ubuntu 14.04. نشير هنا إلى أن الإصدر الموجود في المستودعات الرسمية لأوبنتو (5.6.11 أثناء كتابة هذه السطور) يفي بالمتطلبات (5.5.9 فما فوق). تثبيت المتطلبات الأخرى تثبَّت بعض الوحدات المطلوبة لتشغيل Laravel تلقائيا عند تثبيت PHP، في ما تحتاج أخرى لتثبيتها وتفعيلها. يثبت الأمر التالي هذه الوحدات وأدوات إضافية أخرى: sudo apt-get install -y php5-json openssl php5-mcrypt curl git-core أضفنا حزمتي curl و git-core التين تحتاجهما أداة Composer لتنزيل أرشيف Laravel إلى أمر التثبيت. نفعّل وحدة mcrypt على PHP: sudo php5enmod mcrypt نفعّل كذلك تعليمة mod_rewrite على خادوم ويب Apache: sudo a2enmod rewrite نعيد تشغيل خادوم الويب لاعتماد التعديلات: sudo service apache2 restart تثبيت Composer وإعداده نفذ الأمر التالي لتنزيل أداة Composer وتثبيتها: curl -sS https://getcomposer.org/installer | php نغيّر مكان الأداة ليصبح تنفيذها ممكنا دون الحاجة لذكر المسار الكامل للملف: sudo mv composer.phar /usr/local/bin/composer ثم نتأكد من سلامة تثبيت الأداة: composer يجب أن تشبه النتيجة ما يلي: تثبيت Laravel يمكننا الآن تنفيذ الأمر التالي لتثبيت Laravel باستخدام Composer: sudo composer create-project --prefer-dist laravel/laravel /var/www/html/larashop "5.2.*" يثبت الأمر Laravel (الإصدار 5.2) وينشئ مشروعا على المسار /var/www/html/larashop/. ننتظر حتى اكتمال التثبيت ثم نجعل الحساب الخاص بخادوم الويب مالكَ مجلد المشروع ونعطي إذن الكتابة لجميع المستخدمين حتى نتمكن من التعديل على ملفات المشروع: sudo chown -R www-data:www-data /var/www/html/larashop sudo chmod -R 777 /var/www/html/larashop الخطوة الأخيرة هي نقل ملكية المجلد composer./~ إلى المستخدم الحالي: sudo chown -R $USER $HOME/.composer عند الذهاب الآن إلى العنوان http://localhost/larashop/public/ ستظهر الشاشة التالية دلالة على نجاح عملية التثبيت: إنشاء مضيف افتراضي نقدم هنا باختصار طريقة إنشاء مضيف افتراضي Virtual host بحيث يمكننا الوصول إلى واجهة Laravel بكتابة اسم المضيف (اخترنا larashop.dev اسما للمضيف) فقط في المتصفح. للمزيد حول المضيفات الافتراضية راجع هذا الدرس. نفذ الأمر التالي: /etc/apache2/sites-available/larashop.dev.conf أضف المحتوى: <VirtualHost *:80> ServerName larashop.dev DocumentRoot /var/www/html/larashop/public/ <Directory /> Options FollowSymLinks AllowOverride None </Directory> <Directory /var/www/html/larashop/> AllowOverride All </Directory> ErrorLog ${APACHE_LOG_DIR}/error.log LogLevel warn CustomLog ${APACHE_LOG_DIR}/access.log combined </VirtualHost> أضف اسم المضيف إلى خادوم الويب: sudo a2ensite larashop.dev عطل اسم المضيف الافتراضي: sudo a2dissite 000-default أعد تحميل إعدادات Apache: sudo service apache2 reload افتح ملف المضيفات لتحريره: sudo nano /etc/hosts أضف السطر التالي مباشرة بعد السطر الأخير من الأسطر التي تبدأ بـ127.X.X.X: 127.0.1.1 larashop.dev يمكن الآن الوصول إلى واجهة Laravel الأمامية بالذهاب إلى العنوان larashop.dev في المتصفح. بنية مجلدات Laravel يلخص الجدول التالي أهم مجلدات Laravel التي تجب عليك معرفتها. app: يحتوي على الشفرة المصدرية للتطبيق. app/console: توجد أوامر artisan هنا. app/events: يحتوي على أصناف Classes الأحداث Events. app/exceptions: الأصناف التي تتعامل مع الاستثناءات Exceptions. app/Http: تحتوي على الأصناف الخاصة بالمتحكِّمات Controllers، المُرشِحات Filters والطلبات Requests. app/jobs: يحتوي هذا المجلد على الأشغال Jobs التي تمكن إضافتها إلى قائمة الانتظار Queue. app/listeners: يحتوي على الأصناف التي تعالج الأحداث. bootstrap: توجد هنا الأصناف التي يحتاجها إطار عمل Bootstrap. config: يحتوي هذا المجلد على ملفات الإعداد. database: توجد في المجلد أصناف التهجير Migration والبذر Seed الخاصتين بقاعدة البيانات. كما يحتوي المجلد على قاعدة بيانات SQLite. public: يحتوي على متحكمات الواجهة الأمامية للتطبيق وموارد أخرى مثل الصور، ملفات CSS، Javascript وغيرها. resources: يحوي العروض Views وملفات التوطين Localization. storage: يحتوي على قوالب blade المجمّعة Compiled، حقول الجلسات Sessions وأمور أخرى. tests: توجد به الاختبارات الأحادية Unit tests. vendor: يحتوي على اعتماديات Composer. إعداد مشروع Laravel جديد إعداد التطبيق توجد معلومات إعداد التطبيق في الملف config/app.php/ سنرى في هذه الفقرة: ضبط وضع التنقيح Debugging mode: يُستخدم وضع التنقيح لتحديد مقدار المعلومات الواجب إظهارها عند حدوث أخطاء في التطبيق. ضبط المنطقة الزمنية Time zone: يستخدم PHP هذا الإعداد في دوالّ الوقت والتاريخ. مفتاح التطبيق Application key: تُستخدَم هذه القيمة في التعميّة Encryption. وضع التنقيح افتح الملف config/app.php/ واعثر على السطر التالي: 'debug' => env('APP_DEBUG', false), عدّل السطر بحيث يصبح على النحو التالي: 'debug' => env('APP_DEBUG', true), تفعلّ التعليمة ('debug' => env('APP_DEBUG', true وضع التنقيح بإعطاء القيمة true للمتغيّر APP_DEBUG؛ وهو ما يعني أن Laravel سيظهر معلومات مفصَّلة عند حدوث أخطاء. تفيد المعلومات المفصَّلة كثيرًا في البحث عن مشاكل في التطبيق ومن ثم تصحيحها. المنطقة الزمنية ابحث في نفس الملف عن السطر التالي: 'timezone' => 'UTC', تعطي هذه التعليمة القيمة الافتراضيّة UTC للمتغيّر timezone. تشير UTC إلى التوقيت العالميّ الموّحّد؛ يمكنك إبدالها بالقيمة الموافقة لمنطقتك الزمنيّة المفضّلة. مفتاح التطبيق اعثر على السطر التالي: 'key' => env('APP_KEY', 'SomeRandomString'), وضع سلسلة محارف String من اختيارك مكان SomeRandomString: 'key' => env('APP_KEY', 'ines5@dinemwa8aw3bambuyabakoiwe'), اخترنا سلسلة محارف عشوائية من 32 محرفا Characters لاستخدامها في التعميّة. إعدادات أخرى توجد الكثير من الإعدادات الأخرى التي يمكن اكتشافها بتصفح الملف config/app.php. إعداد الاستيثاق توجد إعدادات الاستيثاق ضمن الملف config/auth.php/. سنترك الإعدادات بقيمها الافتراضية، يمكنك تغييرها بما يوافق احتياجاتك. إعداد قاعدة البيانات يوجد إعداد قاعدة البيانات ضمن الملف config/database.php/؛ تُستخدم قاعدة بيانات MySQL افتراضيّا. يمكن تعديل الملف لاستخدام نظام إدارة قواعد بيانات مختلف. سنستخدم قاعدة بيانات MySQL في هذا الدليل ونغيّر بضعة إعدادات: اسم قاعدة البيانات database، اسم المستخدم username، كلمة سر المستخدم. ابحث عن الأسطر التالية في ملف إعداد قاعدة البيانات: 'mysql' => [ 'driver' => 'mysql', 'host' => env('DB_HOST', 'localhost'), 'database' => env('DB_DATABASE', 'forge'), 'username' => env('DB_USERNAME', 'forge'), 'password' => env('DB_PASSWORD', ''), 'charset' => 'utf8', 'collation' => 'utf8_unicode_ci', 'prefix' => '', 'strict' => false, ], حدّث القيم لتصبح على النحو التالي: 'mysql' => [ 'driver' => 'mysql', 'host' => env('DB_HOST', 'localhost'), 'database' => env('DB_DATABASE', 'larashop'), 'username' => env('DB_USERNAME', 'root'), 'password' => env('DB_PASSWORD', 'melody'), 'charset' => 'utf8', 'collation' => 'utf8_unicode_ci', 'prefix' => '', 'strict' => false, ], تعد التعليمة ('database' => env('DB_DATABASE', 'larashop', التطبيق لاستخدام قاعدة بيانات larashop. يمكنك الذهاب إلى MySQL وإنشاء قاعدة بيانات خاوية باسم larashop في MySQL. تضبط التعليمة ('username' => env('DB_USERNAME', 'root', التطبيق لاستخدام الحساب root للوصول إلى قاعدة البيانات. يجب أن تستخدم حساب مستخدم صالحا في MySQL. التعليمة المواليّة ('password' => env('DB_PASSWORD', 'melody', تحدد كلمة سر الحساب المستخدم في التعليمة السابقة. خاتمة رأينا في هذا الدرس كيفية تثبيت Laravel ثم بنية المجلدات الموجودة في إطار العمل وإعدادات أساسية لمشروع Laravel. الخطوة التاليّة ستكون إنشاء أول تطبيق في Laravel. ترجمة -وبتصرّف- لمقال Laravel 5 Installation and Configuration لصاحبه Rodrick Kazembe.

لم تعد الصور الرمزيّة لحسابات المستخدمين أمرًا جديدًا ويندر أن تجد برنامجًا لا يسمح لمستخدميه بعرض صورة للمستخدم في صفحته الشّخصية مثلًا أو نحو ذلك، وقد ظهرت من عدّة سنوات فكرة أن يكون للمستخدم صورة رمزية يمكنه استخدامها في الكثير من المواقع والخدمات دون أن يحتاج في كلّ مرّة إلى اختيارها ورفعها، وهذا ما تمّ فعلًا في مشروع أطلق عليه اسم Gravatar اختصارًا للصورة الرمزيّة المتعارف عليها عالميًّا Globally Recognized Avatar. إنّ إضافة صورة Gravatar إلى شريط التصفّح في مشروع مبني بـ Laravel من أكثر الأعمال سهولة فلا تتطلب العملية أكثر من 4 خطوات بسيطة، ويعود الفضل في هذا إلى فريق CreativeOrange، الذين يمكن زيارة صفحة مشروعهم لقراءة الإرشادات الأصليّة، فيما إذا طرأت تغييرات ما. الخطوة الأولى لنقم بتحميل نسخة من الحزمة المطلوبة باستخدام Composer عبر سطر الأوامر: composer require creativeorange/gravatar ~1.0 أو من الممكن التعديل على ملف composer.json وإضافة اسم الحزمة والإصدار المطلوب إلى لائحة الحزم المطلوبة: "require": { "creativeorange/gravatar": "~1.0" } وفي حال تعديل الملف، فيتوجّب علينا أن نقوم بتنفيذ الأمر التّالي من سطر الأوامر ليتمّ تحديث المشروع وتحميل الحزمة: composer update الخطوة الثانية نحتاج الآن لإضافة مزوّد خدمة Service Provider إلى ملف app/config/app.php في مصفوفة providers بالشّكل: 'providers' => [ // Other Service Providers // ... App\Providers\AppServiceProvider::class, // ... // Other Service Providers ], ملاحظة: لا تنس الفاصلة في نهاية السطر إن لم تدرج السطر في نهاية المصفوفة. نلاحظ فيما سبق بأننا استخدمنا الصيغة الخاصة بـ PHP 5.6 وهي الصيغة القياسية لمصفوفة providers في الإصدار 5.* من Laravel. الخطوة الثالثة لنقم الآن بإضافة إختصار في مصفوفة aliases في ملف app.php ذاته: 'aliases' => [ // ... 'Gravatar' => Creativeorange\Gravatar\Facades\Gravatar::class, // ... ], نلاحظ بأن كلّ ما احتجنا لإضافته في الخطوتين السابقتين هو سطر واحد فقط، وهذا من الأمور المميّزة في معمارية Laravel، حيث أنّ حزّم Service Providers كأحجار البناء في التطبيق البرمجيّ ويمكن ملاحظة مدى سهولة استخدامها في البرنامج، فلا يتطلّب الأمر أكثر من سطرين. أصبح الآن بالإمكان استخدام الصفّ Gravatar في البرنامج بسهولة من خلال الواجهة التي حصلنا عليّها، الأمر الذي يمكن القيام به على النحو التالي: use Gravatar; لكن لن نحتاج لاستخدامه بهذا الشكل في مثالنا. الخطوة الرابعة من المحتمل أن الاستخدام الأسهل للإضافة Gravatar يكون عبر إدراجها مباشرة في عرض View، كالصّفحة الرّئيسية كأن تكون عنصر قائمة في شريط التصفّح الرئيسي العلويّ. سنحتاج بداية للتحقّق فيما إذا قد تمّ تسجيل الدخول أولًا أم لا، ويمكن ذلك باستخدام ()Auth::check المتاحة للاستخدام دومًا عند الحاجة لها، كما في الشّكل: @if (Auth::check()) // أظهر العنصر @endif تستخدم الشّيفرة السابقة الصّيغة القياسية لنظام القوالب Blade والذي نحتاج لمعرفة استخدامه عند اختيار إطار العمل Laravel، وتسمح صيغة blade بالمزج ما بين شيفرات HTML و PHP بسهولة عند الاستخدام، دون الحاجة لاستخدام وسوم البدء الخاصّة بـ PHP، من خلال إدراج التعليمات ما بين الأقواس {{ .. }} كما يظهر في الكود البرمجيّ التالي: @if (Auth::check()) <li> <img src="{{ Gravatar::get(Auth::user()->email) }}" style="height:50px; width:50px; border-radius:50%;"> </li> @endif والآن لنأخذ الجزء الأهمّ ما بين الأقواس ولنقم بتوضيحه: Gravatar::get(Auth::user()->email) يؤدّي استدعاء التابع ()get من الصنفّ Gravatar إلى إعادة مسار نصيّ بصيغة URL لصورة gravatar بعد أن نقوم بتزويده ببريد إلكترونيّ، ونظرًا لأنّا نرغب بعرض صورة حساب المستخدم النشط في البرنامج فإنّ بالإمكان الحصول على البريد الإلكتروني للحساب من الكائن object الذي يعيده استدعاء التابع ()Auth::user الذي يحمل معلومات عن المستخدم صاحب جلسة العمل النشطة. قد لا يكون قياس الصّورة التي نحصل عليها مناسبًا لنا، ولحلّ هذه المشكلة يمكن تغيير القياس الافتراضيّ المطلوب من خلال تعديل قيمة المتغيّر size في المصفوفة default في الملف vendor/creativeorange/gravatar/config/gravatar.php: 'default' => array( 'size' => 80, 'fallback' => 'mm', 'secure' => false, 'maximumRating' => 'g', 'forceDefault' => false, 'forceExtension' => 'jpg', ), وهناك العديد من القيم الافتراضية التي يمكن تغييرها لتتناسب مع احتياجاتنا في هذا الملف، كالصّورة الافتراضيّة التي يتم عرضها في حال لم يكن للمستخدم صورة Gravatar، أو طلب الصورة بصيغة مختلفة عن JPG، وغير ذلك. ترجمة -وبتصرّف- للمقال Laravel 5.1 Gravatar Plugin لصاحبه Bill Keck.