Composer برای مدیریت وابستگی وردپرس

در پروژه‌های وردپرسی که با آن‌ها کار کرده‌ام، بزرگ‌ترین تفاوت بین یک تیم حرفه‌ای و یک تیم آماتور در شیوه مدیریت وابستگی‌هاست. تیم حرفه‌ای هرگز افزونه‌ای را با کلیک روی دکمه نصب، در محیط تولید قرار نمی‌دهد. آن‌ها یک زنجیره قابل بازتولید می‌سازند. Composer دقیقاً همان ابزاری است که این زنجیره را ممکن می‌کند.

Composer چیست و چه مسئله‌ای را حل می‌کند؟

Composer یک ابزار مدیریت وابستگی برای PHP است. این ابزار از سال ۲۰۱۲ میلادی به‌عنوان راه‌حل استاندارد برای مدیریت کتابخانه‌های PHP شناخته شده و در پروژه‌هایی مانند Laravel، Symfony و Drupal به‌طور پیش‌فرض استفاده می‌شود.

مسئله‌ای که Composer حل می‌کند، ساده اما حیاتی است: وقتی یک پروژه به چند کتابخانه وابسته است، و آن کتابخانه‌ها خودشان به کتابخانه‌های دیگری وابسته‌اند، چگونه می‌توان نسخه‌های سازگار را تضمین کرد؟ روش سنتی، دانلود دستی هر کتابخانه و قرار دادن آن در پوشه پروژه است. این روش چند مشکل جدی دارد:

• نسخه کتابخانه‌ها مشخص نیست و در هر پروژه متفاوت است.
• به‌روزرسانی هر کتابخانه یک عملیات دستی و پرخطاست.
• تداخل نسخه‌ها (Version Conflict) به‌سختی قابل تشخیص است.
• انتقال پروژه به ماشین دیگر نیازمند کپی کل پوشه‌هاست.
• وابستگی‌های تودرتو (Transitive Dependencies) مدیریت نمی‌شوند.

Composer این مشکلات را با یک فایل پیکربندی به نام composer.json و یک فایل قفل به نام composer.lock حل می‌کند. در composer.json، توسعه‌دهنده وابستگی‌ها را با محدوده نسخه اعلام می‌کند. در composer.lock، نسخه دقیق هر وابستگی و وابستگی‌های تودرتوی آن ثبت می‌شود. با اجرای composer install، هر ماشینی که به این دو فایل دسترسی داشته باشد، می‌تواند دقیقاً همان مجموعه وابستگی‌ها را بازسازی کند.

Composer یک ابزار نصب نیست؛ یک قرارداد است. قراردادی که می‌گوید «هر محیط، دقیقاً همان وابستگی‌ها را خواهد داشت.»

تفاوت Composer با npm و pip

برای توسعه‌دهندگانی که با اکوسیستم‌های دیگر آشنا هستند، مقایسه Composer با npm (Node.js) یا pip (Python) مفید است. جدول زیر این تفاوت‌ها را نشان می‌دهد:

هرچند این ابزارها از نظر مفهومی مشابه‌اند، Composer تفاوت مهمی دارد: در اکوسیستم PHP، Composer معمولاً بخشی از پروژه است و نه یک ابزار سیستمی. این یعنی هر پروژه می‌تواند نسخه متفاوتی از وابستگی‌ها داشته باشد، بدون آنکه با پروژه‌های دیگر تداخل کند.

چرا وردپرس به Composer نیاز دارد؟

وردپرس به‌طور تاریخی بر مدیریت دستی افزونه‌ها و قالب‌ها بنا شده است. این رویکرد برای کاربران مبتدی مناسب است، اما در پروژه‌های حرفه‌ای چندین مشکل ایجاد می‌کند:

• عدم بازتولیدپذیری: اگر سرور از بین برود، بازسازی دقیق همان پیکربندی افزونه‌ها و نسخه‌ها زمان‌بر و پرخطاست.
• عدم کنترل نسخه: فایل‌های افزونه در سیستم مدیریت نسخه (Version Control System) قرار نمی‌گیرند، یا اگر بگیرند، حجم مخزن را بی‌دلیل بالا می‌برند.
• عدم تست خودکار: در CI/CD، نمی‌توان به‌راحتی وابستگی‌ها را نصب و تست کرد.
• عدم امکان تعریف وابستگی بین افزونه‌ها: اگر افزونه A به کتابخانه B نیاز داشته باشد، این وابستگی به‌صورت دستی مدیریت می‌شود.
• عدم استفاده از کتابخانه‌های استاندارد PHP: بسیاری از افزونه‌ها از کتابخانه‌هایی مانند Guzzle، Monolog یا Symfony Components استفاده می‌کنند، اما آن‌ها را به‌صورت کپی‌شده در بسته قرار می‌دهند.

Composer این مشکلات را حل می‌کند. با Composer، می‌توان:

• افزونه‌های وردپرس را با نسخه دقیق مشخص کرد.
• کتابخانه‌های PHP را به‌عنوان وابستگی اعلام کرد.
• وابستگی‌های تودرتو را به‌صورت خودکار مدیریت کرد.
• در محیط تولید، فقط وابستگی‌های اصلی را نصب کرد (بدون dev dependencies).
• در CI/CD، محیطی قابل بازتولید برای تست ساخت.

این رویکرد به‌ویژه در تیم‌های توسعه که چند نفر روی یک پروژه کار می‌کنند، حیاتی است. برای مطالعه بیشتر درباره ساختار پروژه‌های حرفه‌ای وردپرس، مقاله چگونه یک پروژه توسعه وردپرس را ساختاربندی کنیم را ببینید.

نصب و راه‌اندازی Composer

نصب Composer چند روش دارد که بسته به سیستم‌عامل متفاوت است. در ادامه، روش‌های اصلی بررسی می‌شود.

نصب روی لینوکس و مک

روش توصیه‌شده نصب Composer روی لینوکس و مک، استفاده از اسکریپت رسمی است:

php -r "copy('https://getcomposer.org/installer', 'composer-setup.php');"
php -r "if (hash_file('sha384', 'composer-setup.php') === '...') { echo 'Installer verified'; } else { echo 'Installer corrupt'; unlink('composer-setup.php'); } echo PHP_EOL;"
php composer-setup.php
php -r "unlink('composer-setup.php');"

پس از اجرای این دستورات، فایل composer.phar در پوشه جاری ساخته می‌شود. برای دسترسی سراسری، این فایل را به مسیری در $PATH منتقل کنید:

sudo mv composer.phar /usr/local/bin/composer
composer --version

پس از این مرحله، دستور composer در هر نقطه از ترمینال قابل اجراست.

نصب روی ویندوز

روی ویندوز، ساده‌ترین روش استفاده از فایل نصب رسمی (Composer-Setup.exe) است که از سایت getcomposer.org قابل دانلود است. این نصب‌کننده، Composer را در مسیر PHP نصب می‌کند و متغیر محیطی PATH را به‌روز می‌کند.

روش جایگزین، استفاده از مدیر پکیج Chocolatey است:

choco install composer

یا در PowerShell:

Set-ExecutionPolicy Bypass -Scope Process -Force
[System.Net.ServicePointManager]::SecurityProtocol = [System.Net.ServicePointManager]::SecurityProtocol -bor 3072
iex ((New-Object System.Net.WebClient).DownloadString('https://getcomposer.org/installer'))

نصب سراسری در مقابل محلی

Composer می‌تواند به‌صورت سراسری (Global) یا محلی (Local) نصب شود. نصب سراسری برای اجرای دستور composer در هر پروژه مفید است. نصب محلی، یعنی قرار دادن فایل composer.phar در پوشه پروژه و اجرای آن با دستور php composer.phar.

در پروژه‌های تیمی، توصیه می‌شود که نسخه Composer در مستندات پروژه ثبت شود تا همه اعضای تیم از نسخه یکسان استفاده کنند. برخی تیم‌ها فایل composer.phar را در مخزن پروژه قرار می‌دهند تا اطمینان حاصل کنند که همه از نسخه مشخصی استفاده می‌کنند.

برای آشنایی با ابزارهای ضروری توسعه وردپرس، مقاله بهترین ابزارهای توسعه وب را ببینید.

ساختار فایل composer.json

فایل composer.json قلب پیکربندی Composer است. این فایل با فرمت JSON نوشته می‌شود و شامل بخش‌های مختلفی است. در ادامه، بخش‌های کلیدی بررسی می‌شود.

بخش require و require-dev

بخش require وابستگی‌های اصلی پروژه را تعریف می‌کند. این وابستگی‌ها در محیط تولید نیز نصب می‌شوند.

{
  "require": {
    "php": ">=8.0",
    "johnpbloch/wordpress-core": "^6.5",
    "wpackagist-plugin/woocommerce": "^9.0",
    "wpackagist-plugin/advanced-custom-fields": "^6.2",
    "guzzlehttp/guzzle": "^7.8"
  }
}

بخش require-dev وابستگی‌هایی را تعریف می‌کند که فقط در محیط توسعه نصب می‌شوند. این وابستگی‌ها در تولید نصب نمی‌شوند و بنابراین حجم پکیج نهایی را کاهش می‌دهند.

{
  "require-dev": {
    "phpunit/phpunit": "^10.0",
    "squizlabs/php_codesniffer": "^3.8",
    "wp-coding-standards/wpcs": "^3.0",
    "phpstan/phpstan": "^1.10"
  }
}

برای مطالعه بیشتر درباره استانداردهای کدنویسی وردپرس، مقاله استانداردهای کدنویسی وردپرس چیست را ببینید.

بخش repositories

بخش repositories مخازن اضافی را تعریف می‌کند. این بخش برای استفاده از WPackagist یا مخازن خصوصی ضروری است.

{
  "repositories": [
    {
      "type": "composer",
      "url": "https://wpackagist.org"
    },
    {
      "type": "vcs",
      "url": "https://github.com/my-company/my-private-plugin"
    }
  ]
}

ترتیب مخازن مهم است. Composer ابتدا مخازن تعریف‌شده در این بخش را بررسی می‌کند و سپس به Packagist پیش‌فرض می‌رود.

بخش autoload

بخش autoload نحوه بارگذاری خودکار کلاس‌ها را تعریف می‌کند. این بخش برای پروژه‌هایی که کد PHP سفارشی دارند، حیاتی است.

{
  "autoload": {
    "psr-4": {
      "MyCompany\\MyPlugin\\": "src/"
    },
    "classmap": ["includes/"],
    "files": ["helpers.php"]
  }
}

استاندارد PSR-4 رایج‌ترین روش autoloading در پروژه‌های مدرن PHP است. برای مطالعه بیشتر درباره Autoload و تأثیر آن بر عملکرد، مقاله Autoload و تأثیر آن بر سرعت وردپرس را ببینید.

بخش scripts

بخش scripts دستورات سفارشی را تعریف می‌کند که با composer run-script اجرا می‌شوند. این بخش برای اتوماسیون کارهای تکراری مفید است.

{
  "scripts": {
    "test": "phpunit",
    "lint": "phpcs --standard=WordPress src/",
    "fix": "phpcbf --standard=WordPress src/",
    "analyze": "phpstan analyse src/ --level=5",
    "post-install-cmd": [
      "@php -r "file_exists('.env') || copy('.env.example', '.env');""
    ]
  }
}

با این پیکربندی، توسعه‌دهنده می‌تواند با دستور composer test تست‌ها را اجرا کند یا با composer lint کد را بررسی کند. این رویکرد، همکاری تیمی را ساده‌تر می‌کند.

هرچه منطق بیشتری در composer.json تعریف شود، ورود اعضای جدید به پروژه ساده‌تر می‌شود. ابزار باید تیم را آموزش دهد، نه اینکه اعضای تیم ابزار را حفظ کنند.

فایل composer.lock و اهمیت آن

فایل composer.lock پس از اجرای composer install یا composer update ساخته می‌شود. این فایل نسخه دقیق هر وابستگی و وابستگی‌های تودرتوی آن را ثبت می‌کند.

تفاوت composer install و composer update حیاتی است:

• composer install: وابستگی‌ها را بر اساس فایل composer.lock نصب می‌کند. اگر فایل قفل وجود نداشته باشد، آن را می‌سازد.
• composer update: وابستگی‌ها را بر اساس composer.json به‌روزرسانی می‌کند و فایل قفل را بازنویسی می‌کند.

در محیط تولید، همیشه باید composer install اجرا شود، نه composer update. زیرا composer update ممکن است نسخه وابستگی‌ها را تغییر دهد و رفتار پروژه را ناخواسته عوض کند.

آیا فایل composer.lock باید در مخزن باشد؟

پاسخ کوتاه: بله، برای پروژه‌های کاربردی (Applications) و وردپرس، باید در مخزن Git قرار گیرد. برای کتابخانه‌های عمومی (Libraries)، معمولاً قرار نمی‌گیرد. دلیل این تفاوت این است که پروژه‌های کاربردی باید محیط قابل بازتولید داشته باشند، اما کتابخانه‌ها باید با محدوده‌های نسخه انعطاف‌پذیر کار کنند.

# In .gitignore for libraries but NOT for applications
# /composer.lock

WPackagist و مدیریت افزونه‌ها

WPackagist یک آینه (Mirror) از مخزن افزونه‌ها و قالب‌های وردپرس است که آن‌ها را به‌صورت پکیج‌های Composer در دسترس قرار می‌دهد. این سرویس، پل بین اکوسیستم وردپرس و Composer است.

نصب افزونه‌های وردپرس با Composer

برای نصب افزونه‌های وردپرس با Composer، ابتدا باید مخزن WPackagist را به composer.json اضافه کرد. سپس افزونه‌ها با پیشوند wpackagist-plugin/ نصب می‌شوند:

{
  "repositories": [
    {
      "type": "composer",
      "url": "https://wpackagist.org"
    }
  ],
  "require": {
    "wpackagist-plugin/woocommerce": "^9.0",
    "wpackagist-plugin/contact-form-7": "^5.9",
    "wpackagist-plugin/wordpress-seo": "^23.0"
  },
  "extra": {
    "installer-paths": {
      "wp-content/plugins/{$name}/": ["type:wordpress-plugin"]
    }
  }
}

بخش extra.installer-paths تعیین می‌کند که افزونه‌ها در کدام مسیر نصب شوند. این پیکربندی نیازمند نصب پکیج composer/installers است:

composer require composer/installers

برای مطالعه بیشتر درباره ساختار استاندارد افزونه، مقاله ساختار استاندارد افزونه وردپرس را ببینید.

نصب قالب‌ها با Composer

قالب‌ها نیز به‌طریق مشابه نصب می‌شوند، با پیشوند wpackagist-theme/:

{
  "require": {
    "wpackagist-theme/twentytwentyfour": "^1.0",
    "wpackagist-theme/astra": "^4.6"
  },
  "extra": {
    "installer-paths": {
      "wp-content/themes/{$name}/": ["type:wordpress-theme"]
    }
  }
}

برای مطالعه بیشتر درباره توسعه قالب، مقاله راهنمای توسعه قالب وردپرس از صفر را ببینید.

مدیریت هسته وردپرس با Composer

هسته وردپرس نیز می‌تواند با Composer مدیریت شود. پکیج‌های مختلفی برای این کار وجود دارد:

• johnpbloch/wordpress-core: نسخه کامل وردپرس
• roots/wordpress: نسخه سبک‌تر بدون محتوای پیش‌فرض

{
  "require": {
    "johnpbloch/wordpress-core": "^6.5"
  },
  "extra": {
    "wordpress-install-dir": "wp",
    "installer-paths": {
      "wp-content/plugins/{$name}/": ["type:wordpress-plugin"],
      "wp-content/themes/{$name}/": ["type:wordpress-theme"]
    }
  }
}

با این پیکربندی، هسته وردپرس در پوشه wp نصب می‌شود و محتوای سفارشی در پوشه wp-content جدا می‌ماند. این ساختار به «Bedrock-like» معروف است و برای پروژه‌های حرفه‌ای توصیه می‌شود.

Autoloading در Composer و PSR-4

PSR-4 یک استاندارد برای autoloading کلاس‌های PHP است که توسط PHP-FIG (PHP Framework Interop Group) تعریف شده. Composer از این استاندارد پشتیبانی می‌کند و می‌تواند کلاس‌ها را به‌صورت خودکار بارگذاری کند.

وقتی Composer با پیکربندی PSR-4 کار می‌کند، یک فایل به نام vendor/autoload.php می‌سازد. با فراخوانی این فایل در ابتدای کد، تمام کلاس‌های تعریف‌شده در پیکربندی، به‌صورت خودکار بارگذاری می‌شوند.

require __DIR__ . '/vendor/autoload.php';

use MyCompany\\MyPlugin\\Services\\PaymentService;

$payment = new PaymentService();

این رویکرد مزایای متعددی دارد:

• نیازی به require یا include دستی کلاس‌ها نیست.
• نام‌گذاری کلاس‌ها ساخت‌یافته و قابل پیش‌بینی است.
• تداخل نام کلاس‌ها با استفاده از namespace حل می‌شود.
• ابزارهای تحلیل استاتیک (مثل PHPStan) می‌توانند کد را بهتر بررسی کنند.

برای مطالعه بیشتر درباره کدنویسی اصولی وردپرس، مقاله چگونه کدنویسی وردپرس را اصولی شروع کنیم را ببینید.

classmap و files

علاوه بر PSR-4، Composer از دو روش دیگر autoloading پشتیبانی می‌کند:

• classmap: Composer پوشه یا فایل‌های مشخصی را اسکن می‌کند و کلاس‌های یافت‌شده را در یک نقشه ذخیره می‌کند. این روش برای کد legacy مفید است.
• files: فایل‌های مشخصی در هر درخواست بارگذاری می‌شوند. این روش برای توابع سراسری (Global Functions) کاربرد دارد.

{
  "autoload": {
    "classmap": ["legacy/"],
    "files": ["src/helpers.php"]
  }
}

ترکیب این سه روش به پروژه‌های وردپرسی که بخشی از کد آن‌ها legacy است، اجازه می‌دهد به‌تدریج به معماری مدرن مهاجرت کنند.

مخازن خصوصی و پکیج‌های اختصاصی

در پروژه‌های حرفه‌ای، اغلب به مخازن خصوصی نیاز است. افزونه‌های اختصاصی شرکت، کتابخانه‌های داخلی یا پکیج‌هایی که در Packagist عمومی نیستند، باید از مخازن خصوصی نصب شوند.

مخازن VCS

Composer می‌تواند پکیج‌ها را مستقیماً از مخازن Git، Mercurial یا SVN نصب کند:

{
  "repositories": [
    {
      "type": "vcs",
      "url": "git@github.com:my-company/my-plugin.git"
    }
  ],
  "require": {
    "my-company/my-plugin": "^1.0"
  }
}

برای احراز هویت با مخازن خصوصی Git، باید کلید SSH یا توکن دسترسی تعریف شود. Composer از فایل auth.json برای ذخیره اطلاعات احراز هویت پشتیبانی می‌کند.

{
  "github-oauth": {
    "github.com": "ghp_xxxxxxxxxxxx"
  },
  "http-basic": {
    "private-repo.example.com": {
      "username": "user",
      "password": "pass"
    }
  }
}

فایل auth.json نباید در مخزن Git قرار گیرد. این فایل باید در .gitignore ثبت شود.

Private Packagist و Satis

Private Packagist یک سرویس تجاری است که مخزن خصوصی Composer را به‌صورت ابری ارائه می‌دهد. Satis یک ابزار متن‌باز است که می‌تواند یک مخزن Composer خصوصی روی سرور خودتان بسازد.

Satis با یک فایل پیکربندی JSON کار می‌کند و یک مخزن استاتیک از پکیج‌ها می‌سازد:

{
  "name": "my-company/repository",
  "homepage": "https://packages.example.com",
  "repositories": [
    { "type": "vcs", "url": "https://github.com/my-company/my-plugin" }
  ],
  "require-all": true
}

با اجرای satis build، فایل‌های JSON تولید می‌شوند که Composer می‌تواند از آن‌ها به‌عنوان مخزن استفاده کند.

Composer در CI/CD

یکی از بزرگ‌ترین مزایای Composer، یکپارچگی با سیستم‌های CI/CD (Continuous Integration / Continuous Deployment) است. در هر اجرای pipeline، می‌توان محیط پروژه را با دقت بازسازی کرد.

# .github/workflows/deploy.yml
name: Deploy

on:
  push:
    branches: [main]

jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: shivammathur/setup-php@v2
        with:
          php-version: '8.2'
      - name: Install dependencies
        run: composer install --no-dev --optimize-autoloader
      - name: Run tests
        run: composer test
      - name: Deploy
        run: rsync -avz --delete ./ user@server:/var/www/site/

نکات مهم در این پیکربندی:

• --no-dev: وابستگی‌های dev نصب نمی‌شوند.
• --optimize-autoloader: نقشه autoload بهینه می‌شود.
• composer install (نه update): نسخه‌ها از فایل قفل خوانده می‌شوند.

گزینه‌های اضافی که در تولید توصیه می‌شوند:

composer install --no-dev --no-scripts --optimize-autoloader --classmap-authoritative

• --no-scripts: اسکریپت‌های تعریف‌شده در composer.json اجرا نمی‌شوند.
• --classmap-authoritative: Composer فقط از classmap استفاده می‌کند و در دیسک جستجو نمی‌کند.

برای مطالعه بیشتر درباره CI/CD در وردپرس، مقاله CI/CD برای پروژه‌های وردپرسی را ببینید.

ترکیب Composer با Docker

Docker و Composer ترکیبی قدرتمند برای توسعه وردپرس می‌سازند. در یک Dockerfile استاندارد، Composer می‌تواند وابستگی‌ها را در زمان ساخت image نصب کند.

FROM php:8.2-fpm-alpine

WORKDIR /var/www/html

# Install Composer
COPY --from=composer:latest /usr/bin/composer /usr/bin/composer

# Copy composer files first for better caching
COPY composer.json composer.lock ./

RUN composer install --no-dev --optimize-autoloader --no-scripts

# Copy application code
COPY . .

RUN chown -R www-data:www-data /var/www/html

نکته کلیدی در این Dockerfile، ترتیب کپی فایل‌هاست. کپی کردن composer.json و composer.lock پیش از کد اصلی، باعث می‌شود Docker از cache استفاده کند و در صورت تغییر نکردن وابستگی‌ها، نصب تکرار نشود.

برای مطالعه بیشتر درباره تجربه کار با Docker، مقاله تجربه کار با Docker در توسعه پروژه‌ها را ببینید.

Composer و Git در توسعه وردپرس

یکی از سؤالات رایج این است که پوشه vendor/ باید در مخزن Git قرار گیرد یا خیر. پاسخ به شرایط پروژه بستگی دارد:

در حالت کلی، برای پروژه‌های حرفه‌ای توصیه می‌شود vendor/ در .gitignore قرار گیرد و وابستگی‌ها در زمان استقرار نصب شوند. این رویکرد حجم مخزن را کاهش می‌دهد و امکان مدیریت دقیق نسخه‌ها را فراهم می‌کند.

# .gitignore
/vendor/
composer.phar
auth.json
.env

برای مطالعه بیشتر درباره Git در توسعه وردپرس، مقاله گیت در توسعه وردپرس را ببینید.

اشتباهات رایج در استفاده از Composer

Composer ابزاری قدرتمند است، اما استفاده نادرست از آن می‌تواند به مشکلات جدی منجر شود. برخی از رایج‌ترین اشتباهات:

1. اجرای composer update در محیط تولید: این کار ممکن است نسخه وابستگی‌ها را تغییر دهد و سایت را از کار بیندازد. همیشه از composer install استفاده کنید.
2. قرار دادن فایل composer.lock در .gitignore: این فایل باید در مخزن باشد تا محیط قابل بازتولید بماند.
3. استفاده از محدوده‌های نسخه بیش از حد باز: محدوده * یا >=1.0 می‌تواند به نصب نسخه‌های ناسازگار منجر شود. از محدوده‌های دقیق‌تر مانند ^1.2 یا ~1.2.3 استفاده کنید.
4. نادیده گرفتن security advisories: Composer دستور composer audit را برای بررسی آسیب‌پذیری‌های امنیتی ارائه می‌دهد. این دستور باید در CI اجرا شود.
5. عدم استفاده از --no-dev در تولید: نصب وابستگی‌های dev در تولید، حجم و سطح حمله را افزایش می‌دهد.
6. قرار دادن اطلاعات احراز هویت در composer.json: اطلاعات حساس باید در auth.json یا متغیرهای محیطی باشند.
7. عدم پاک‌سازی cache پس از تغییر پیکربندی: دستور composer clear-cache می‌تواند مشکلات عجیب را حل کند.
8. استفاده از WPackagist برای افزونه‌های پولی: WPackagist فقط افزونه‌های مخزن رسمی وردپرس را پوشش می‌دهد. افزونه‌های پولی باید از مخازن دیگر نصب شوند.
9. نادیده گرفتن هشدارهای Composer: هشدارهایی مانند «Package X is abandoned» یا «Package Y requires PHP Z» نشانه مشکلات آینده هستند.
10. عدم تست پس از به‌روزرسانی وابستگی‌ها: هر به‌روزرسانی باید با تست خودکار یا دستی تأیید شود.

Composer یک ابزار است، نه یک راه‌حل جادویی. اگر اصول مدیریت وابستگی را ندانید، Composer فقط سرعت اشتباه کردن شما را افزایش می‌دهد.

پرسش‌های پرتکرار درباره Composer در وردپرس

در این بخش، به پرسش‌های متداول درباره Composer و کاربرد آن در وردپرس پاسخ می‌دهیم. این ساختار برای بهینه‌سازی محتوا برای موتورهای پاسخگو (Answer Engines) نیز مفید است.

آیا Composer برای همه پروژه‌های وردپرس مناسب است؟

خیر. برای سایت‌های شخصی کوچک یا پروژه‌هایی که مدیر آن‌ها با خط فرمان آشنا نیست، Composer می‌تواند پیچیدگی غیرضروری ایجاد کند. Composer برای پروژه‌های حرفه‌ای، تیمی و سایت‌هایی که نیاز به بازتولیدپذیری دارند، مناسب‌تر است.

تفاوت Composer با نصب معمولی افزونه‌ها چیست؟

نصب معمولی از طریق پیشخوان وردپرس، فایل‌ها را دانلود و در پوشه wp-content/plugins قرار می‌دهد. Composer، وابستگی‌ها را بر اساس فایل composer.json و composer.lock نصب می‌کند و امکان مدیریت نسخه دقیق و بازتولید محیط را فراهم می‌آورد.

آیا استفاده از Composer سرعت سایت را کاهش می‌دهد؟

خیر، برعکس. Composer می‌تواند با --optimize-autoloader و --classmap-authoritative سرعت autoloading را افزایش دهد. این گزینه‌ها نقشه autoload را بهینه می‌کنند و در دیسک جستجو نمی‌کنند.

چگونه افزونه‌های پولی را با Composer نصب کنیم؟

بسیاری از افزونه‌های پولی مخزن Composer اختصاصی دارند. برای افزونه‌هایی که مخزن ندارند، باید از نوع package در بخش repositories استفاده کرد یا فایل ZIP را در یک مخزن خصوصی قرار داد.

آیا Composer جایگزین مدیر پیشخوان وردپرس است؟

خیر، مکمل آن است. Composer برای مدیریت سطح پروژه طراحی شده، در حالی که پیشخوان وردپرس برای کاربران نهایی و مدیریت روزمره محتواست. در پروژه‌های حرفه‌ای، هر دو در کنار یکدیگر استفاده می‌شوند.

چگونه از آسیب‌پذیری‌های امنیتی در وابستگی‌ها مطلع شویم؟

دستور composer audit و سرویس Symfony Security Checker آسیب‌پذیری‌های شناخته‌شده را گزارش می‌دهند. این دستور باید در CI/CD و پیش از هر استقرار اجرا شود.

آیا Composer با PHP نسخه‌های قدیمی کار می‌کند؟

Composer 2.x نیازمند PHP 7.2.5 به بالا است. اگر پروژه روی PHP قدیمی‌تر اجرا می‌شود، باید از Composer 1.x استفاده کرد، اما این نسخه پشتیبانی نمی‌شود و توصیه نمی‌شود.

چگونه پروژه Composer را از صفر شروع کنیم؟

با اجرای composer init در پوشه پروژه، یک فایل composer.json اولیه ساخته می‌شود. سپس با composer require وابستگی‌ها اضافه می‌شوند. برای مطالعه بیشتر درباره شروع توسعه وردپرس، مقاله توسعه وردپرس چیست و از کجا باید شروع کنیم را ببینید.

آیا Composer با ووکامرس سازگار است؟

بله. ووکامرس خودش با Composer توسعه داده می‌شود و از طریق WPackagist قابل نصب است. افزونه‌های مرتبط با ووکامرس نیز معمولاً از Composer پشتیبانی می‌کنند.

چگونه وابستگی‌های استفاده‌نشده را حذف کنیم؟

با دستور composer remove vendor/package می‌توان یک وابستگی را حذف کرد. همچنین، composer why vendor/package نشان می‌دهد که چرا یک وابستگی نصب شده و چه پکیجی به آن وابسته است.

نکات پیشرفته برای مهندسان ارشد

برای مهندسان ارشد و توسعه‌دهندگان پلتفرم، Composer فراتر از یک ابزار نصب است. در این بخش، به نکات پیشرفته‌ای می‌پردازیم که در پروژه‌های بزرگ و پیچیده حیاتی می‌شوند.

تحلیل وابستگی‌ها با composer why-not و composer depends

در پروژه‌های بزرگ، درک روابط بین وابستگی‌ها حیاتی است. دستور composer depends نشان می‌دهد که کدام پکیج‌ها به یک پکیج خاص وابسته‌اند:

composer depends guzzlehttp/guzzle

دستور composer why-not نشان می‌دهد که چرا یک نسخه خاص از یک پکیج قابل نصب نیست:

composer why-not guzzlehttp/guzzle 8.0

این دستورات در زمان حل تداخل نسخه‌ها بسیار مفیدند. در پروژه‌هایی با بیش از ۵۰ وابستگی، بدون این ابزارها عیب‌یابی تقریباً غیرممکن است.

Composer 2 و بهبود عملکرد

Composer 2 نسبت به Composer 1 بهبودهای چشمگیری در عملکرد دارد:

• استفاده از HTTP/2 برای دانلود موازی
• کش محلی هوشمندتر
• حل سریع‌تر وابستگی‌ها با الگوریتم جدید
• پشتیبانی از parallel downloads

در پروژه‌هایی با وابستگی‌های زیاد، Composer 2 می‌تواند زمان نصب را تا ۵۰٪ کاهش دهد.

استفاده از composer dump-autoload در زمان استقرار

دستور composer dump-autoload نقشه autoload را بازسازی می‌کند. در محیط تولید، این دستور با گزینه‌های زیر اجرا می‌شود:

composer dump-autoload --optimize --classmap-authoritative --no-dev

• --optimize: نقشه autoload بهینه می‌شود.
• --classmap-authoritative: Composer فقط از classmap استفاده می‌کند.
• --no-dev: کلاس‌های dev نادیده گرفته می‌شوند.

این ترکیب، سریع‌ترین حالت autoloading را فراهم می‌کند، اما باید توجه داشت که با هر تغییر در ساختار فایل‌ها، باید dump-autoload مجدداً اجرا شود.

مدیریت وابستگی‌های پلتفرم با composer.json

در بخش config.platform، می‌توان نسخه PHP و افزونه‌های آن را تعریف کرد. این پیکربندی برای تضمین سازگاری مفید است:

{
  "config": {
    "platform": {
      "php": "8.2.0",
      "ext-mysqli": "8.2.0",
      "ext-json": "8.2.0",
      "ext-curl": "8.2.0"
    }
  }
}

این پیکربندی اطمینان می‌دهد که Composer وابستگی‌هایی را نصب می‌کند که با نسخه PHP محیط تولید سازگارند، حتی اگر محیط توسعه PHP متفاوتی داشته باشد.

پیاده‌سازی Composer در معماری چندنودی

در معماری‌هایی که از Bedrock یا مشابه آن استفاده می‌کنند، Composer در سطح ریشه پروژه قرار می‌گیرد و وردپرس به‌عنوان وابستگی نصب می‌شود. این معماری مزایای متعددی دارد:

• جدا کردن کد سفارشی از هسته وردپرس
• استفاده از متغیرهای محیطی برای پیکربندی
• ساختار پوشه‌های قابل پیش‌بینی
• یکپارچگی بهتر با CI/CD

نمونه ساختار پوشه در Bedrock:

project/
├── composer.json
├── composer.lock
├── config/
│   ├── application.php
│   └── environments/
├── web/
│   ├── wp/           # WordPress core
│   ├── wp-content/
│   │   ├── plugins/  # managed by Composer
│   │   ├── themes/   # managed by Composer
│   │   └── mu-plugins/
│   └── index.php
└── vendor/

این ساختار، فایل‌های هسته وردپرس را از کد سفارشی جدا می‌کند و به‌روزرسانی و نگهداری را ساده‌تر می‌سازد.

استفاده از Prestissimo برای نصب موازی

Prestissimo یک پلاگین Composer است که نصب پکیج‌ها را به‌صورت موازی انجام می‌دهد. این پلاگین می‌تواند زمان نصب را در پروژه‌های بزرگ تا ۳ برابر کاهش دهد:

composer global require hirak/prestissimo

با این حال، از Composer 2 به بعد، بسیاری از قابلیت‌های Prestissimo در خود Composer ادغام شده و نیاز به این پلاگین کمتر شده است.

تحلیل امنیتی پیشرفته

دستور composer audit آسیب‌پذیری‌های شناخته‌شده را بر اساس پایگاه داده FriendsOfPHP بررسی می‌کند. در CI، می‌توان این دستور را به‌عنوان یک gate امنیتی تعریف کرد:

composer audit --format=json > audit-report.json
composer audit --no-dev --abandoned=fail

گزینه --abandoned=fail باعث می‌شود که اگر یک پکیج متروک شده باشد، دستور با خطا خارج شود. این رویکرد به تیم‌ها کمک می‌کند وابستگی‌های متروک را به‌موقع شناسایی و جایگزین کنند.

مدیریت نسخه‌های major، minor و patch

محدوده‌های نسخه در Composer با نشانه‌های خاصی تعریف می‌شوند. درک دقیق این نشانه‌ها برای مدیریت وابستگی‌ها حیاتی است:

قاعده کلی: در پروژه‌های تولیدی، از ^ برای کتابخانه‌های پایدار استفاده کنید. از ~ برای کتابخانه‌هایی که تغییرات minor آن‌ها می‌تواند شکننده باشد. از * پرهیز کنید.

استراتژی به‌روزرسانی وابستگی‌ها

به‌روزرسانی وابستگی‌ها در پروژه‌های بزرگ نیازمند استراتژی است. رویکرد توصیه‌شده:

1. به‌روزرسانی دوره‌ای: هفتگی یا دو‌هفتگی، وابستگی‌ها با composer update در شاخه توسعه به‌روزرسانی شوند.
2. تست خودکار: پس از هر به‌روزرسانی، تست‌های خودکار اجرا شوند.
3. بررسی امنیتی: با composer audit، آسیب‌پذیری‌های جدید بررسی شوند.
4. محدود کردن دامنه به‌روزرسانی: در هر مرحله، فقط یک یا چند وابستگی به‌روزرسانی شوند تا در صورت بروز مشکل، ریشه آن مشخص باشد.
5. مستندسازی: تغییرات مهم در CHANGELOG ثبت شوند.

دستور composer outdated نشان می‌دهد که کدام وابستگی‌ها نسخه جدیدتر دارند:

composer outdated --direct
composer outdated --strict

گزینه --direct فقط وابستگی‌های مستقیم را نشان می‌دهد و --strict فقط نسخه‌هایی که محدوده major تغییر کرده را نمایش می‌دهد.

ادغام Composer با WordPress Coding Standards

استانداردهای کدنویسی وردپرس را می‌توان از طریق Composer نصب و در CI اجرا کرد:

composer require --dev wp-coding-standards/wpcs dealerdirect/phpcodesniffer-composer-installer

پس از نصب، فایل phpcs.xml را در ریشه پروژه تعریف کنید:

<?xml version="1.0"?>
<ruleset name="WordPress Custom">
  <rule ref="WordPress"/>
  <rule ref="WordPress-Extra"/>
  <rule ref="WordPress-Docs"/>
  <file>./src</file>
  <exclude-pattern>./vendor/*</exclude-pattern>
</ruleset>

برای مطالعه بیشتر درباره به‌کارگیری استانداردها، مقاله استفاده از WordPress Coding Standards در پروژه‌ها را ببینید.

جمع‌بندی فنی و مسیر پیش‌رو

Composer در وردپرس یک تغییر پارادایم است. از مدیریت دستی فایل‌ها به مدیریت اعلانی وابستگی‌ها. از محیط‌های غیرقابل بازتولید به محیط‌های دقیقاً قابل بازسازی. از استقرار دستی به استقرار خودکار. این تغییر، پیش‌نیاز جدی برای پروژه‌های حرفه‌ای است.

با این حال، Composer یک ابزار نیست که یک‌شبه معجزه کند. نیازمند یادگیری، تنظیم دقیق و استراتژی است. تیم‌هایی که Composer را به‌درستی پیاده‌سازی می‌کنند، معمولاً تفاوت آن را در کاهش خطاها، سرعت استقرار و کیفیت کلی پروژه می‌بینند. تیم‌هایی که آن را نیمه‌کاره رها می‌کنند، معمولاً با پیچیدگی بیشتری مواجه می‌شوند بدون دریافت مزایا.

مسیر پیشنهادی برای شروع:

1. با composer init در یک پروژه جانبی شروع کنید.
2. افزونه‌های ضروری را با WPackagist نصب کنید.
3. فایل composer.lock را در Git ثبت کنید.
4. در CI، دستور composer install را اضافه کنید.
5. پس از تسلط، به سراغ مخازن خصوصی و ساختارهای پیشرفته بروید.

هر مرحله باید با تست و اندازه‌گیری همراه باشد. Composer فقط یک لایه از معماری است؛ بدون درک لایه‌های دیگر (سرور، دیتابیس، کش، امنیت)، اثر آن محدود می‌ماند.

برای مطالعه بیشتر درباره هوک‌ها و کدنویسی سفارشی، مقاله نحوه استفاده صحیح از هوک‌های وردپرس و چگونه کدهای سفارشی به وردپرس اضافه کنیم را ببینید.

آنچه در نهایت باید دانست

Composer برای وردپرس، نه یک انتخاب لوکس، بلکه یک ضرورت در پروژه‌های حرفه‌ای است. این ابزار مدیریت وابستگی را از حالت دستی به حالت اعلانی منتقل می‌کند، بازتولیدپذیری را تضمین می‌کند و یکپارچگی با CI/CD و Docker را ممکن می‌سازد.

نکات کلیدی که باید در خاطر بماند:

• composer.json قرارداد پروژه است؛ composer.lock تعهد به بازتولیدپذیری.
• در تولید همیشه composer install، هرگز composer update.
• WPackagist پل بین وردپرس و Composer است، اما افزونه‌های پولی به مخازن اختصاصی نیاز دارند.
• --optimize-autoloader و --classmap-authoritative عملکرد autoloading را در تولید افزایش می‌دهند.
• composer audit باید در CI به‌عنوان gate امنیتی اجرا شود.
• مخازن خصوصی با VCS یا Satis قابل پیاده‌سازی هستند.
• ترکیب Composer با Docker و Git، یک جریان کاری مدرن و قابل اعتماد می‌سازد.

اگر این فرآیند را در پروژه‌های خود پیاده‌سازی کرده‌اید، جالب است بدانم کدام بخش آن بیشترین چالش را ایجاد کرده است. تجربه خودتان را در دیدگاه‌ها بنویسید؛ به‌خصوص اگر راه‌حل متفاوتی برای مدیریت وابستگی‌ها در وردپرس پیدا کرده‌اید که می‌تواند برای دیگران مفید باشد.