Composer والتحميل التلقائي في PHP

Composer واحد من أهم الأدوات في تطوير PHP الحديث. فهو يساعد المطورين على تثبيت الحزم، وإدارة اعتماديات المشروع، وتحميل الأصناف تلقائياً دون الحاجة إلى استدعاء كل ملف يدوياً.

قبل أن يصبح Composer شائعاً، كان مطورو PHP يستخدمون كثيراً من عبارات require وinclude لتحميل الملفات. كان هذا مناسباً للمشاريع الصغيرة، لكنه يصبح صعب الإدارة عندما تكبر التطبيقات.

يشرح هذا المقال Composer والتحميل التلقائي في PHP بالتفصيل، بما في ذلك ما هو Composer، وملف composer.json، وتثبيت الحزم، ومجلد vendor، والتحميل التلقائي، وPSR-4، ومساحات الأسماء، واستخدام حزم vendor، وComposer scripts، وكيف يجهز Composer المطورين لأطر مثل Laravel وSymfony.

ما هو Composer؟

Composer هو مدير اعتماديات للغة PHP. والاعتمادية هي حزمة أو مكتبة يحتاجها مشروعك حتى يعمل.

على سبيل المثال، قد يحتاج مشروع PHP إلى حزمة لإرسال البريد الإلكتروني، أو التعامل مع متغيرات البيئة، أو إنشاء ملفات PDF، أو العمل مع التواريخ، أو التحقق من البيانات، أو تنفيذ طلبات HTTP. يستطيع Composer تثبيت هذه الحزم وتتبع إصداراتها.

يسمح Composer للمطورين بـ:

• تثبيت حزم PHP.

• إدارة إصدارات الحزم.

• تحديث الاعتماديات.

• إزالة الحزم.

• تحميل الأصناف تلقائياً.

• تنظيم مشاريع PHP الحديثة.

• استخدام حزم المجتمع من Packagist.

يُستخدم Composer في كثير من أطر وأدوات PHP الحديثة، مثل Laravel وSymfony وPHPUnit وPHPMailer وGuzzle وCarbon وMonolog وغيرها.

لماذا Composer مهم؟

Composer مهم لأن تطوير PHP الحديث يعتمد كثيراً على الحزم القابلة لإعادة الاستخدام. بدلاً من كتابة كل شيء من الصفر، يستطيع المطور استخدام مكتبات مجربة أنشأها مجتمع PHP.

على سبيل المثال، بدلاً من كتابة مكتبة بريد إلكتروني خاصة بك، يمكنك تثبيت حزمة جاهزة. وبدلاً من بناء HTTP client كامل يدوياً، يمكنك تثبيت حزمة مثل Guzzle. وبدلاً من تحميل كل ملف صنف يدوياً، يستطيع Composer تحميلها تلقائياً.

كما يجعل Composer المشاريع أكثر قابلية للنقل. عندما يقوم مطور آخر بتنزيل مشروعك، يمكنه تثبيت كل الحزم المطلوبة بأمر واحد.

composer install

يقرأ هذا الأمر ملفات اعتماديات المشروع ويثبت كل ما يحتاجه المشروع حتى يعمل.

بدون Composer، ستكون إدارة مشاريع PHP الكبيرة أصعب بكثير وأقل تنظيماً.

تثبيت Composer

قبل استخدام Composer، يجب تثبيته على جهازك أو الخادم. بعد التثبيت، يمكنك التأكد من توفر Composer بتشغيل هذا الأمر في الطرفية:

composer --version

إذا كان Composer مثبتاً بشكل صحيح، ستعرض الطرفية إصدار Composer المثبت.

عادة يُستخدم Composer من سطر الأوامر. تفتح مجلد المشروع في الطرفية ثم تشغل أوامر Composer من هناك.

على سبيل المثال، لتهيئة Composer داخل مشروع PHP جديد، يمكنك تشغيل:

composer init

يساعد هذا الأمر على إنشاء ملف composer.json، وهو الملف الذي يصف مشروعك واعتمادياته.

composer.json

ملف composer.json هو ملف الإعداد الرئيسي لـ Composer. يخزن معلومات المشروع، والحزم المطلوبة، وإعدادات التحميل التلقائي، والسكربتات، وخيارات إعداد أخرى.

قد يبدو ملف composer.json بسيط بهذا الشكل:

{
    "name": "adnan/php-learning",
    "description": "A simple PHP learning project",
    "type": "project",
    "require": {
        "php": ">=8.1"
    }
}

يعرّف حقل name المشروع. ويصف حقل description المشروع. أما حقل type فيوضح هل الحزمة مشروع أو مكتبة أو plugin أو نوع آخر.

يعرض قسم require الحزم التي يحتاجها المشروع. في هذا المثال، يحتاج المشروع إلى PHP بإصدار 8.1 أو أحدث.

عندما تثبت الحزم، يقوم Composer بتحديث composer.json تلقائياً لإضافة تلك الاعتماديات.

تثبيت الحزم

يستطيع Composer تثبيت الحزم باستخدام أمر composer require.

على سبيل المثال، لتثبيت مكتبة Carbon الخاصة بالتواريخ، يمكنك تشغيل:

composer require nesbot/carbon

بعد تشغيل هذا الأمر، يقوم Composer بتنزيل الحزمة وإضافتها إلى composer.json.

{
    "require": {
        "nesbot/carbon": "^3.0"
    }
}

ينشئ Composer أيضاً ملف composer.lock أو يحدثه. يخزن هذا الملف الإصدارات الدقيقة المثبتة في المشروع.

تثبيت الحزم باستخدام Composer يسمح لك باستخدام مكتبات خارجية دون تنزيل الملفات يدوياً أو إدارتها بنفسك.

مجلد vendor

عندما يثبت Composer الحزم، يضعها داخل مجلد vendor. يحتوي هذا المجلد على كل الاعتماديات المنزلة وملفات التحميل التلقائي الخاصة بـ Composer.

بعد تثبيت الحزم، قد يبدو مشروع بسيط بهذا الشكل:

project/
├── composer.json
├── composer.lock
├── index.php
└── vendor/
    ├── autoload.php
    ├── composer/
    └── nesbot/
        └── carbon/

لا يُفترض عادة تعديل مجلد vendor يدوياً. Composer يديره نيابة عنك.

في كثير من المشاريع، لا يتم رفع مجلد vendor إلى Git. بدلاً من ذلك، يتم رفع composer.json وcomposer.lock، ويشغل المطورون الآخرون composer install لإعادة إنشاء مجلد vendor.

أهم ملف داخل vendor هو vendor/autoload.php. هذا الملف يسمح لمشروعك باستخدام التحميل التلقائي من Composer.

التحميل التلقائي في Composer

التحميل التلقائي يعني تحميل أصناف PHP تلقائياً عند استخدامها. بدون التحميل التلقائي، يجب تضمين ملفات الأصناف يدوياً باستخدام require أو include.

على سبيل المثال، بدون التحميل التلقائي من Composer، قد تكتب:

<?php
require "app/Models/User.php";
require "app/Controllers/UserController.php";
require "app/Services/MailService.php";
?>

يصبح هذا الأسلوب فوضوياً عندما يكبر المشروع. يحل Composer هذه المشكلة من خلال إنشاء autoloader.

لاستخدام التحميل التلقائي من Composer، قم بتضمين هذا الملف مرة واحدة في بداية التطبيق:

<?php
require __DIR__ . "/vendor/autoload.php";
?>

بعد ذلك يستطيع Composer تحميل أصناف الحزم وأصناف مشروعك تلقائياً إذا كانت إعدادات التحميل التلقائي صحيحة.

استخدام حزم vendor

بعد تثبيت حزمة عبر Composer، يمكنك استخدامها من خلال استدعاء autoloader الخاص بـ Composer واستيراد صنف الحزمة.

على سبيل المثال، بعد تثبيت Carbon، يمكنك استخدامها بهذا الشكل:

<?php
require __DIR__ . "/vendor/autoload.php";

use Carbon\Carbon;

echo Carbon::now();
echo Carbon::now()->addDays(7);
?>

تستورد عبارة use مساحة اسم الصنف، ويقوم Composer بتحميل الصنف تلقائياً.

هذه إحدى الفوائد الأساسية لـ Composer. لا تحتاج إلى البحث عن ملفات الحزمة وتضمينها يدوياً. Composer يتولى عملية التحميل.

تُستخدم حزم vendor في مشاريع حقيقية كثيرة لمهام مثل إرسال البريد الإلكتروني، وتسجيل الأخطاء، والتعامل مع التواريخ، وإنشاء ملفات PDF، وقراءة ملفات البيئة، وتنفيذ طلبات HTTP، وتشغيل الاختبارات.

composer.lock

يخزن ملف composer.lock الإصدارات الدقيقة للحزم المثبتة في المشروع. هذا الملف مهم لأنه يجعل التثبيت متطابقاً بين الأجهزة المختلفة.

على سبيل المثال، قد يسمح composer.json بإصدار حزمة بهذا الشكل:

"nesbot/carbon": "^3.0"

هذا يعني أن Composer قد يثبت إصدارات متوافقة حسب قاعدة الإصدار. لكن composer.lock يسجل الإصدار المثبت بدقة.

عندما يشغل مطور آخر:

composer install

يستخدم Composer ملف composer.lock لتثبيت الإصدارات نفسها. هذا يساعد على تجنب الاختلافات غير المتوقعة بين بيئات التطوير والاختبار والإنتاج.

في معظم التطبيقات، يجب رفع composer.lock إلى Git. أما في المكتبات القابلة لإعادة الاستخدام، فقد يختلف القرار حسب استراتيجية الحزمة.

composer install مقابل composer update

أمران شائعان في Composer هما composer install وcomposer update. يبدوان متشابهين، لكن سلوكهما مختلف.

يقوم أمر composer install بتثبيت الاعتماديات بناءً على composer.lock إذا كان موجوداً.

composer install

يُستخدم هذا الأمر عادة عند إعداد مشروع لأول مرة، أو النشر إلى خادم، أو تثبيت الاعتماديات تماماً كما حددها ملف lock.

أما أمر composer update فيحدث الحزم حسب قواعد الإصدارات في composer.json، ثم يكتب الإصدارات الجديدة داخل composer.lock.

composer update

استخدم composer update بحذر لأنه قد يرفع إصدارات الحزم ويدخل تغييرات. في الإنتاج، يُفضل عادة استخدام composer install من أجل نشر قابل للتوقع.

التحميل التلقائي PSR-4

PSR-4 معيار لتحميل أصناف PHP تلقائياً بناءً على مساحات الأسماء وبنية المجلدات. وهو مستخدم على نطاق واسع في مشاريع PHP الحديثة.

مع PSR-4، يتم ربط بادئة مساحة اسم بمجلد. على سبيل المثال، يمكن ربط مساحة الاسم App\ بمجلد app/.

في composer.json، يمكن إعداد PSR-4 بهذا الشكل:

{
    "autoload": {
        "psr-4": {
            "App\\": "app/"
        }
    }
}

هذا يعني أن الصنف المسمى App\Models\User يجب أن يكون موجوداً في:

app/Models/User.php

بعد تغيير إعدادات autoload، شغل:

composer dump-autoload

هذا يخبر Composer بإعادة توليد ملفات التحميل التلقائي.

يجعل PSR-4 تحميل الأصناف متوقعاً ومنظماً. وهو المعيار الذي تستخدمه كثير من أطر وحزم PHP.

مساحات الأسماء مع Composer

تساعد مساحات الأسماء على تنظيم الأصناف ومنع تعارض الأسماء. يعمل التحميل التلقائي في Composer بشكل وثيق مع namespaces.

على سبيل المثال، أنشئ ملف صنف:

app/Services/GreetingService.php

يمكن أن يستخدم الصنف مساحة الاسم App\Services:

<?php
namespace App\Services;

class GreetingService
{
    public function sayHello(string $name): string
    {
        return "Hello, " . $name;
    }
}
?>

بعد إعداد PSR-4 وتشغيل composer dump-autoload، يمكن استخدام الصنف هكذا:

<?php
require __DIR__ . "/vendor/autoload.php";

use App\Services\GreetingService;

$service = new GreetingService();

echo $service->sayHello("Adnan");
?>

لا تحتاج إلى استدعاء GreetingService.php يدوياً. Composer يحمله تلقائياً بناءً على مساحة الاسم ومسار الملف.

composer dump-autoload

يعيد أمر composer dump-autoload توليد ملفات التحميل التلقائي الخاصة بـ Composer. يُستخدم كثيراً بعد إضافة أو تغيير إعدادات autoload في composer.json.

composer dump-autoload

إذا لم يستطع Composer العثور على صنف أنشأته، فالحل الشائع هو فحص مساحة الاسم ومسار الملف، ثم تشغيل composer dump-autoload.

للتحميل التلقائي المحسن في الإنتاج، يوفر Composer الأمر:

composer dump-autoload -o

الخيار -o يعني optimized autoloading. يمكنه تحسين الأداء عبر توليد class map.

في كثير من مسارات النشر، يُستخدم التحميل التلقائي المحسن لتطبيقات الإنتاج.

تحميل ملفات تلقائياً

يستطيع Composer أيضاً تحميل ملفات PHP محددة تلقائياً. هذا مفيد للدوال المساعدة العامة.

على سبيل المثال، أنشئ ملف helper:

app/helpers.php

ثم أضفه إلى composer.json:

{
    "autoload": {
        "psr-4": {
            "App\\": "app/"
        },
        "files": [
            "app/helpers.php"
        ]
    }
}

بعد تعديل composer.json، شغل:

composer dump-autoload

الآن سيتم تحميل ملف helper تلقائياً عندما يتم استدعاء autoloader الخاص بـ Composer.

يُستخدم هذا الأسلوب غالباً للدوال المساعدة الصغيرة، لكن يجب استخدامه بحذر. كثرة الدوال العامة قد تجعل المشروع أصعب في الصيانة.

اعتماديات التطوير

بعض الحزم نحتاجها أثناء التطوير فقط، وليس في الإنتاج. من أمثلتها أدوات الاختبار، ومنسقات الكود، والمحللات الساكنة، وحزم التصحيح.

يخزن Composer حزم التطوير داخل قسم require-dev.

لتثبيت حزمة كاعتمادية تطوير، استخدم:

composer require --dev phpunit/phpunit

قد يحتوي composer.json بعدها على:

{
    "require-dev": {
        "phpunit/phpunit": "^11.0"
    }
}

عند النشر إلى الإنتاج، يمكن تخطي حزم التطوير باستخدام:

composer install --no-dev

هذا يجعل تثبيت الإنتاج أصغر، ويتجنب تثبيت أدوات لا يحتاجها الخادم.

Composer Scripts

تسمح Composer scripts للمطورين بتعريف أوامر مخصصة داخل composer.json. يمكن لهذه السكربتات تشغيل مهام شائعة في المشروع مثل الاختبارات، والتنسيق، ومسح الكاش، أو أوامر الإعداد.

مثال على scripts في composer.json:

{
    "scripts": {
        "test": "phpunit",
        "serve": "php -S localhost:8000 -t public",
        "autoload": "composer dump-autoload"
    }
}

يمكنك تشغيل script بهذا الشكل:

composer test

أو:

composer serve

تساعد Composer scripts على توحيد أوامر المشروع بحيث يستطيع أعضاء الفريق تشغيل الأوامر نفسها بسهولة.

تستخدم أطر العمل والحزم أيضاً Composer scripts لتشغيل مهام إعداد تلقائية أثناء التثبيت أو التحديث.

قيود الإصدارات

يستخدم Composer قيود الإصدارات ليقرر أي إصدارات من الحزم مسموح بها. فهم هذه القيود يساعد على تجنب مشاكل الاعتماديات.

من الأمثلة الشائعة:

• ^3.0: يسمح بالإصدارات المتوافقة من 3.0 حتى ما قبل 4.0.

• ~3.1: يسمح بالإصدارات من 3.1 حتى ما قبل 4.0 حسب القاعدة.

• 3.2.1: يتطلب الإصدار 3.2.1 تحديداً.

• *: يسمح بأي إصدار، وهذا غير مستحسن غالباً.

مثال:

{
    "require": {
        "nesbot/carbon": "^3.0"
    }
}

استخدام قيود إصدارات مناسبة يساعد على إبقاء الحزم محدثة مع تجنب تغييرات رئيسية غير متوقعة.

إزالة الحزم

إذا لم تعد الحزمة مطلوبة، يمكن إزالتها باستخدام composer remove.

composer remove nesbot/carbon

يزيل هذا الأمر الحزمة من composer.json، ويحدث composer.lock، ويحذف ملفات الحزمة من مجلد vendor إذا لم تكن هناك اعتمادية أخرى تحتاجها.

إزالة الحزم غير المستخدمة عادة جيدة لأنها تجعل المشروع أصغر وأنظف وأسهل في الصيانة.

فحص الحزم المثبتة

يمكن لـ Composer عرض الحزم المثبتة باستخدام:

composer show

لعرض معلومات عن حزمة محددة:

composer show nesbot/carbon

يساعدك هذا على فحص إصدارات الحزم ووصفها واعتمادياتها ومعلومات أخرى.

يمكن لـ Composer أيضاً فحص الحزم القديمة:

composer outdated

يساعدك هذا الأمر على معرفة الحزم التي تتوفر لها إصدارات أحدث.

Composer وGit

عند استخدام Composer مع Git، من الشائع رفع composer.json وcomposer.lock، وعدم رفع مجلد vendor.

يتضمن ملف .gitignore عادة:

/vendor/

يمكن للمطورين الآخرين نسخ المشروع ثم تشغيل:

composer install

سيثبت هذا كل الحزم المطلوبة بناءً على composer.lock.

رفع composer.lock يساعد على ضمان استخدام كل المطورين والخوادم لإصدارات الحزم نفسها.

Composer في الإنتاج

عند نشر مشروع PHP إلى الإنتاج، يجب استخدام Composer بحذر. أمر التثبيت الشائع في الإنتاج هو:

composer install --no-dev --optimize-autoloader

الخيار --no-dev يتخطى حزم التطوير. والخيار --optimize-autoloader يحسن أداء التحميل التلقائي.

في الإنتاج، تجنب تشغيل تحديثات حزم عشوائية مباشرة على الخادم. الأفضل تحديث الحزم واختبارها في التطوير، ثم رفع composer.lock ونشر الإصدارات المختبرة.

كما يجب أن تحمي خوادم الإنتاج الملفات الحساسة مثل composer.json عند الحاجة، وملفات البيئة، والسجلات، وملفات الإعداد من الوصول العام.

مشاكل Composer الشائعة

قد يواجه المبتدئون بعض مشاكل Composer الشائعة. فهم الأسباب يجعل إصلاحها أسهل.

من المشاكل الشائعة:

• Class not found: قد تكون مساحة الاسم أو مسار الملف خاطئاً، أو تحتاج إلى dump-autoload.

• Package version conflict: قد تتطلب حزمتان إصدارات غير متوافقة.

• PHP version mismatch: قد تتطلب الحزمة إصدار PHP أحدث.

• Missing extension: قد تحتاج الحزمة إلى PHP extension غير مثبت.

• Permission issues: قد لا يستطيع Composer الكتابة داخل مجلدات vendor أو cache.

من الأوامر المفيدة لاستكشاف الأخطاء:

composer diagnose
composer dump-autoload
composer show
composer outdated

قراءة رسائل خطأ Composer بعناية مهمة لأنها عادة توضح أي حزمة أو إصدار PHP أو extension يسبب المشكلة.

Composer وبنية مشروع PHP الحديث

يشجع Composer على بنية مشروع أنظف. قد يبدو مشروع PHP بسيط مبني على Composer بهذا الشكل:

project/
├── app/
│   ├── Controllers/
│   ├── Models/
│   └── Services/
├── public/
│   └── index.php
├── tests/
├── vendor/
├── composer.json
└── composer.lock

يحتوي مجلد app على أصناف التطبيق. ويحتوي مجلد public على نقطة دخول الويب. ويحتوي مجلد vendor على حزم Composer. أما مجلد tests فيحتوي على الاختبارات الآلية.

مع PSR-4، يمكن تحميل الأصناف داخل مجلد app تلقائياً باستخدام namespaces.

هذه البنية قريبة من طريقة تنظيم التطبيقات في كثير من أطر PHP.

Composer وLaravel

يعتمد Laravel كثيراً على Composer. عندما تنشئ مشروع Laravel، يقوم Composer بتثبيت إطار Laravel وكل الاعتماديات المطلوبة.

يستخدم مشروع Laravel Composer من أجل:

• تثبيت حزم الإطار.

• إدارة اعتماديات vendor.

• تحميل أصناف التطبيق تلقائياً.

• تشغيل Composer scripts.

• تثبيت أدوات التطوير.

• إدارة package discovery.

يستخدم مجلد app في Laravel مساحات أسماء وتحميل Composer التلقائي. على سبيل المثال، يمكن لصنف داخل app/Services أن يستخدم مساحة الاسم App\Services.

فهم Composer يجعل Laravel أسهل في الفهم، لأن كثيراً من ميزات Laravel مبنية فوق إدارة الحزم والتحميل التلقائي في Composer.

أفضل ممارسات Composer

العادات الجيدة في Composer تساعد على إبقاء مشاريع PHP مستقرة وقابلة للصيانة.

من أفضل الممارسات المهمة:

• ارفع composer.json وcomposer.lock في التطبيقات.

• لا تعدل الملفات داخل مجلد vendor يدوياً.

• استخدم composer install عند النشر.

• استخدم composer update بحذر واختبر بعد التحديث.

• استخدم require-dev للحزم الخاصة بالتطوير فقط.

• استخدم PSR-4 لتحميل أصناف المشروع تلقائياً.

• شغل composer dump-autoload بعد تغيير إعدادات autoload.

• لا ترفع بيانات حساسة داخل ملفات Composer.

• أزل الحزم غير المستخدمة.

• حافظ على تحديث الاعتماديات بعد اختبار التوافق.

Composer أداة قوية، لكنها تحتاج إلى استخدام منظم. إدارة الاعتماديات الجيدة تجعل المشاريع موثوقة على المدى الطويل.

مثال كامل على Composer Autoload

يوضح المثال التالي مشروعاً بسيطاً يستخدم Composer مع PSR-4 autoloading.

بنية المجلدات:

project/
├── app/
│   └── Services/
│       └── GreetingService.php
├── public/
│   └── index.php
├── vendor/
├── composer.json
└── composer.lock

composer.json:

{
    "name": "adnan/php-composer-demo",
    "description": "Simple Composer autoloading demo",
    "type": "project",
    "require": {
        "php": ">=8.1"
    },
    "autoload": {
        "psr-4": {
            "App\\": "app/"
        }
    }
}

app/Services/GreetingService.php:

<?php
namespace App\Services;

class GreetingService
{
    public function message(string $name): string
    {
        return "Hello, " . $name . ". Welcome to Composer autoloading.";
    }
}
?>

public/index.php:

<?php
require __DIR__ . "/../vendor/autoload.php";

use App\Services\GreetingService;

$service = new GreetingService();

echo $service->message("Adnan");
?>

بعد إنشاء composer.json أو تعديله، شغل:

composer dump-autoload

يوضح هذا المثال كيف يستطيع Composer تحميل أصنافك تلقائياً باستخدام namespaces وPSR-4.

ملاحظات أمان حول Composer

يقوم Composer بتنزيل وتشغيل كود من حزم خارجية، لذلك أمان الاعتماديات مهم.

من الممارسات الأمنية المهمة:

• ثبت الحزم من مصادر موثوقة.

• راجع شعبية الحزمة وصيانتها وتوثيقها.

• حافظ على تحديث الاعتماديات بعد الاختبار.

• أزل الحزم غير المستخدمة.

• لا تضع أسراراً داخل composer.json أو scripts.

• كن حذراً مع Composer scripts من حزم غير معروفة.

• استخدم composer audit عند توفره لفحص الثغرات المعروفة.

يمكنك فحص المشاكل الأمنية المعروفة باستخدام:

composer audit

أمان الاعتماديات جزء من أمان التطبيق. الحزمة الضعيفة يمكن أن تؤثر على المشروع كله.

الخلاصة

Composer أداة أساسية في تطوير PHP الحديث. فهو يدير الاعتماديات، ويثبت الحزم، وينشئ ملفات التحميل التلقائي، ويدعم PSR-4، ويساعد على تنظيم مشاريع PHP احترافية.

يسمح التحميل التلقائي للمطورين باستخدام الأصناف دون استدعاء كل ملف يدوياً. يربط PSR-4 مساحات الأسماء ببنية المجلدات، مما يجعل المشاريع أنظف وأسهل في الصيانة.

بعد تعلم Composer والتحميل التلقائي، تكون الخطوة التالية هي التدريب عبر إنشاء مشروع PHP MVC صغير مبني على Composer، وتثبيت حزمة، وإعداد PSR-4، وكتابة أصناف namespaced، واستخدام Composer scripts. هذه المهارات أساسية قبل التعمق أكثر في Laravel وSymfony والاختبارات وتطوير PHP الاحترافي.