learn

PHP 8.0 در Ubuntu؛ مسیر ارتقا و نصب نسخه تحت پشتیبانی

PHP 8.0 پایان‌عمر است؛ روش بررسی نسخه وب و CLI، انتخاب PHP سازگار و انتقال آزمایشی برنامه از Ubuntu قدیمی به محیط تحت پشتیبانی را بخوانید.

PHP 8.0 از ۲۶ نوامبر ۲۰۲۳ به پایان عمر بالادستی رسیده است و برای نصب تازه انتخاب مناسبی نیست. اگر برنامه‌ای هنوز به آن وابسته است، ابتدا نسخه سازگار برنامه را آماده کنید و ارتقا را روی محیط آزمایشی انجام دهید؛ افزودن مخزن قدیمی برای ادامه نصب، راه‌حل بلندمدت نیست.

اول نسخه سیستم و PHP را مشخص کنید

cat /etc/os-release
php -v
php --ini
apt-cache policy php php-fpm

خروجی بالا برای خط فرمان است. دامنه ممکن است از PHP-FPM یا Apache module دیگری استفاده کند. نسخه وب، افزونه‌ها و مقدارهای مهم مانند memory_limit را از پنل یا گزارش همان سایت ثبت کنید. cron، queue worker و ابزار Composer را نیز در نظر بگیرید.

کدام نسخه را انتخاب کنیم؟

انتخاب از تقاطع سه عامل به دست می‌آید: پشتیبانی نرم‌افزار، وضعیت امنیتی PHP و بسته قابل نگهداری روی سیستم‌عامل. جدیدترین شاخه بدون بررسی افزونه تجاری، ionCube یا framework ممکن است سایت را از کار بیندازد. صفحه Supported Versions در PHP.net و جدول سازگاری برنامه را هم‌زمان ببینید.

پایان پشتیبانی upstream با پایان وصله‌های یک بسته توزیع یکسان نیست؛ توزیع ممکن است وصله را backport کند. برای Ubuntu 18.04 و 20.04 وضعیت Ubuntu Pro، مخزن و بسته تحت پوشش باید مشخص باشد. صرف وجود یک نسخه در APT، پوشش امنیتی آن را ثابت نمی‌کند.

نصب پایه روی Ubuntu تحت پشتیبانی

روی سرور تازه و بدون کنترل‌پنل، بسته‌های رسمی Ubuntu نقطه شروع مناسبی هستند. فرمان زیر نسخه پیش‌فرض همان انتشار را نصب می‌کند و نباید به عنوان دستور اختصاصی نصب PHP 8.0 تعبیر شود:

sudo apt update
sudo apt install php-cli php-fpm php-mysql php-curl php-mbstring php-xml php-zip
php -v
php -m

برای پردازش تصویر یا نیازهای برنامه، بسته‌هایی مانند php-gd و php-intl را طبق پیش‌نیاز واقعی اضافه کنید. روی پشته دارای پنل، مدیریت PHP را از مسیر همان پنل انجام دهید و پشته موازی APT نسازید.

تغییر نسخه وب با تغییر نسخه CLI فرق دارد

در Nginx، مقدار fastcgi_pass باید به سوکت FPM نسخه هدف اشاره کند. در Apache، انتخاب میان FPM و mod_php و ماژول فعال اهمیت دارد. تغییر update-alternatives برای php فقط binary خط فرمان را عوض می‌کند و دلیل کافی برای تغییر نسخه سایت نیست.

آزمون قبل از انتقال

  1. از فایل‌ها و دیتابیس بکاپ بگیرید و امکان بازیابی را تست کنید.
  2. برنامه و dependencyها را روی کپی جدا اجرا کنید.
  3. ورود، فرم، آپلود، ایمیل، پرداخت آزمایشی و کارهای زمان‌بندی‌شده را تست کنید.
  4. خطاهای Fatal و Deprecated را ثبت و علت را برطرف کنید.
  5. در پروژه Composer، سازگاری محیط را بررسی کنید.
composer check-platform-reqs

این فرمان جای تست کاربردی را نمی‌گیرد، اما نبودن extension یا نسخه ناسازگار PHP را آشکار می‌کند. نصب مستقیم dependency جدید روی سایت فعال برای «رفع هشدار» ممکن است تغییر ناسازگار ایجاد کند.

انتقال نهایی و بازگشت

نسخه قبلی فایل‌ها، پیکربندی FPM و نگاشت دامنه را ثبت کنید. بعد از جابه‌جایی، پاسخ سایت و لاگ سرویس را ببینید. اگر تغییر دیتابیس هم رخ داده، بازگشت فقط با عوض‌کردن PHP کامل نمی‌شود؛ فایل و داده باید با هم سازگار باشند.

پرسش‌های رایج

آیا نصب از PPA همیشه اشتباه است؟

خیر؛ مخزن شخص ثالث ممکن است نیاز مشخصی را برطرف کند، اما مسئول نگهداری، امضای بسته و سیاست وصله آن باید معلوم باشد. برای همه سرورها یک PPA را بدون بررسی توصیه نمی‌کنیم.

آیا PHP جدید حتماً سایت را سریع‌تر می‌کند؟

سرعت به برنامه و پیکربندی وابسته است. ارتقای نسخه را با تست عملکرد و بررسی OPcache همراه کنید و نتیجه را اندازه بگیرید.

منابع رسمی

بازبینی منابع: ۱۸ اکتبر ۲۰۲۶.

راهنماهای مرتبط

مطالب مرتبط

ارسال نظر

فهرست مطالب