ارتقای PHP برای دریافت اصلاحات امنیتی و حفظ سازگاری نرم‌افزارهای سایت اهمیت دارد، اما جدیدترین شماره به‌تنهایی بهترین انتخاب برای هر پروژه نیست. نسخه‌ای را انتخاب کنید که هم تحت پشتیبانی باشد و هم هسته، افزونه‌ها، قالب و کتابخانه‌های برنامه با آن سازگار باشند. تغییر PHP بدون آزمون می‌تواند خطای بحرانی، اختلال فرم یا ازکارافتادن پرداخت ایجاد کند.
وضعیت نسخه را درست تفسیر کنید
پشتیبانی فعال، پشتیبانی امنیتی و پایان عمر سه وضعیت متفاوت‌اند. هنگام بازبینی این راهنما، شاخه‌های 8.0 و 8.1 دیگر انتخابی با پشتیبانی رسمی PHP برای نصب تازه نیستند. جدول رسمی PHP را در روز تصمیم بررسی کنید؛ پشتیبانی یک توزیع لینوکس از بسته backportشده نیز موضوع جداگانه‌ای است و باید از همان توزیع تأیید شود.
نسخه واقعی سایت را پیدا کنید
در وردپرس، بخش ابزارها ← سلامت سایت ← اطلاعات، نقطه شروع مناسبی است. در هاست دارای چند نسخه PHP، نسخه انتخاب‌شده برای دامنه را نیز از پنل بررسی کنید. خروجی خط فرمان لزوماً نشان‌دهنده نسخه‌ای نیست که درخواست مرورگر را اجرا می‌کند.
php --version
php --ini
php -mاین دستورها محیط CLI را نشان می‌دهند. ممکن است وب‌سایت از PHP-FPM دیگری استفاده کند. نسخه، افزونه‌های فعال و فایل تنظیمات وب‌سرور باید جداگانه کنترل شوند. فایل phpinfo را در دسترس عمومی رها نکنید.
مراحل ارتقای کم‌ریسک
- از فایل‌ها و دیتابیس بکاپ قابل بازیابی تهیه کنید و نسخه فعلی PHP و extensionها را ثبت کنید.
- هسته، قالب، افزونه و کدهای اختصاصی را از نظر پشتیبانی نسخه هدف بررسی کنید؛ افزونه رهاشده را صرفاً با کاهش PHP حفظ نکنید.
- در محیط آزمایشی نسخه هدف را فعال کنید و لاگ خطا را در حالت غیرعمومی بررسی کنید. اخطار deprecated با خطای fatal یکسان نیست، اما هر دو برای نگهداری مهم‌اند.
- ورود، آپلود، جستجو، فرم‌ها، cron و در فروشگاه، سبدخرید و پرداخت آزمایشی را کنترل کنید.
- در بازه کم‌ترافیک، نسخه دامنه اصلی را تغییر دهید و پس از گرم‌شدن کش، رفتار و لاگ را پایش کنید.
در cPanel یا سرور اختصاصی چه تفاوتی وجود دارد؟
در cPanel، انتخاب PHP ممکن است از MultiPHP Manager یا ابزار ارائه‌شده توسط میزبان انجام شود؛ دو ابزار انتخاب نسخه را بدون شناخت پشته با هم ترکیب نکنید. در سرور اختصاصی، تغییر CLI با update-alternatives الزاماً PHP-FPM متصل به Nginx را عوض نمی‌کند. socket، pool و extensionهای نسخه هدف باید هماهنگ باشند.
اگر پس از ارتقا سایت از کار افتاد
ابتدا تغییر را در همان دامنه و همان لایه برگردانید و خطای دقیق را ثبت کنید. بازگشت کوتاه‌مدت برای بازیابی سرویس با ماندن دائمی روی نسخه منقضی فرق دارد. اگر افزونه‌ای ناسازگار است، نسخه سازگار یا جایگزین نگهداری‌شده انتخاب کنید. نسخه PHP را چندباره و تصادفی عوض نکنید؛ هر آزمون باید یک فرضیه روشن داشته باشد.
آیا ارتقای PHP سرعت را تضمین می‌کند؟
خیر. نتیجه به برنامه، دیتابیس، کش، منابع هاست و الگوی درخواست بستگی دارد. زمان پاسخ و نرخ خطا را پیش و پس از تغییر با شرایط مشابه بسنجید. ارتقای موفق یعنی نسخه پشتیبانی‌شده با عملکرد صحیح، نه صرفاً عدد بزرگ‌تر در پنل.
مطالعه مرتبط
منابع و مستندات
بازبینی محتوا و منابع: ۲۶ مهر ۱۴۰۵. دستورهای نمونه برای محیط مشخص‌شده‌اند؛ پیش از استفاده روی سرویس عملیاتی، سازگاری محیط و نسخه پشتیبان را بررسی کنید.
