محتوای آموزشی وبلاگ نت‌آرام
در ۲۱ اکتبر ۲۰۲۶، تیم PHP دو نقص امنیتی مهم را اعلام و برای نسخه‌های پشتیبانی‌شده اصلاحیه منتشر کرد. این نقص‌ها با شناسه‌های CVE-2026-109618 و CVE-2026-109619 ثبت شده‌اند. هر دو امتیاز بحرانی ۹٫۲ از ۱۰ در CVSS نسخهٔ ۴ دارند و در شرایط مشخص می‌توانند به مهاجم راه دور امکان اجرای کد روی سرور بدهند. به همین دلیل، تیم PHP توصیه کرده است همهٔ نصب‌هایی که درخواست وب دریافت می‌کنند هرچه زودتر وصله شوند. اعلان امنیتی رسمی PHP
این خبر به‌تنهایی به معنی نفوذ به سایت شما نیست. کار درست، پیدا کردن نسخه‌ای است که واقعاً درخواست‌های سایت را اجرا می‌کند، نصب بستهٔ وصله‌شده از مخزن معتبر همان توزیع یا پنل و سپس راه‌اندازی دوبارهٔ پردازشگر PHP است. در ادامه، مسیر هر سیستم را مرحله‌به‌مرحله می‌خوانید.
پاسخ کوتاه: کاربران نت‌آرام چه کاری انجام دهند؟
سرویس‌های هاست اشتراکی نت‌آرام از سوی تیم فنی ما به‌روزرسانی شده‌اند. اگر سایت شما روی هاست اشتراکی نت‌آرام است، لازم نیست با دسترسی cPanel یا DirectAdmin بستهٔ سیستمی نصب کنید یا نسخهٔ PHP را برای رفع این خبر تغییر دهید. کارهای معمول سایت، مثل نصب به‌روزرسانی‌های وردپرس، افزونه‌ها و قالب‌ها و نگه‌داشتن نسخهٔ پشتیبان، طبق روال ادامه پیدا می‌کند.
اگر سرور مجازی یا اختصاصی را خودتان مدیریت می‌کنید، این مقاله را تا بخش مربوط به توزیع و کنترل‌پنل خود بخوانید. در هاست اشتراکی شرکت‌های دیگر هم مسئول نصب وصلهٔ PHP، مدیر سرور میزبان است؛ از پشتیبانی همان شرکت وضعیت نسخهٔ فعال را بپرسید.
این نقص‌ها چه کاری می‌کنند؟
PHP برنامه‌ای است که کد بسیاری از سایت‌ها، از جمله وردپرس و فروشگاه‌های اینترنتی، را روی سرور اجرا می‌کند. دو نقص اعلام‌شده در خود موتور PHP هستند؛ یعنی صرفاً با نصب نسخهٔ تازهٔ وردپرس یا افزونه برطرف نمی‌شوند. اگر PHP سرور آسیب‌پذیر باشد، اصلاح برنامهٔ سایت جای اصلاح موتور را نمی‌گیرد.
نقص اول، CVE-2026-109618، به مدیریت خطای کمبود حافظه مربوط است. در یک مسیر خاص، درخواست دست‌ساز می‌تواند PHP را هنگام آماده‌سازی داده‌های داخلی در وضعیت نیمه‌کاره متوقف کند. ادامهٔ پاک‌سازی آن درخواست ممکن است حافظه را نادرست بخواند و به اجرای کد برسد.
نقص دوم، CVE-2026-109619، به باقی‌ماندن وضعیت قدیمی میان دو درخواست مربوط است. یک پردازش PHP معمولاً درخواست‌های زیادی را پشت سر هم رسیدگی می‌کند. اگر وضعیت یک درخواست درست پاک نشود، پردازش بعدی ممکن است پیش از آماده‌سازی کامل، به داده‌ای دسترسی پیدا کند که دیگر معتبر نیست. قابلیت «پیشرفت بارگذاری نشست» PHP هم می‌تواند در یکی از مسیرهای تأییدشده نقش داشته باشد. جزئیات هر دو مورد در مشاورهٔ امنیتی PHP آمده است.
این مشکل محدود به یک نوع وب‌سرور نیست. نصب‌هایی که درخواست وب را با PHP-FPM، mod_php، php-cgi، LiteSpeed یا FrankenPHP اجرا می‌کنند باید نسخه و بستهٔ خود را بررسی کنند. PHP بیشترین ریسک تأییدشده را برای Apache با mod_php گزارش کرده، اما استفاده از PHP-FPM به‌تنهایی به معنی بی‌نیازی از وصله نیست. سطح دسترسی کد اجراشده نیز به کاربر و محدودیت‌هایی بستگی دارد که میزبان برای پردازش PHP تنظیم کرده است؛ اجرای کد روی PHP را نباید خودکار معادل دسترسی root دانست.
کدام نسخه‌ها اصلاح شده‌اند؟
در بسته‌های رسمی خود PHP، نسخه‌های زیر دو نقص را اصلاح می‌کنند:
| شاخهٔ PHP | نسخهٔ اصلاح‌شده |
| --- | --- |
| PHP 8.5 | 8.5.12 |
| PHP 8.4 | 8.4.27 |
| PHP 8.3 | 8.3.36 |
| PHP 8.2 | 8.2.35 |
اگر از یک توزیع لینوکس یا سرویس پشتیبانی بلندمدت استفاده می‌کنید، ممکن است شمارهٔ اصلی PHP پس از نصب وصله تغییر نکند. سازندهٔ توزیع می‌تواند اصلاح را به نسخهٔ قدیمی‌تر برگرداند؛ به این روش backport می‌گویند. بنابراین فقط دیدن مثلاً PHP 8.3 در خروجی دستور
php -v برای تشخیص وصله کافی نیست. باید شمارهٔ بستهٔ سیستم‌عامل یا کنترل‌پنل را با اعلان همان سازنده مقایسه کنید.شاخه‌های PHP 8.1 و قدیمی‌تر دیگر از تیم PHP نسخهٔ تازه دریافت نمی‌کنند. برخی توزیع‌ها یا شرکت‌های پشتیبانی بلندمدت ممکن است اصلاح را جداگانه به آن‌ها برگردانند، اما این موضوع برای همهٔ منابع نصب یکسان نیست. اگر هنوز از چنین شاخه‌ای استفاده می‌کنید، وضعیت مخزن خود را از سازنده بپرسید و برای انتقال به نسخهٔ پشتیبانی‌شده برنامه‌ریزی کنید. تغییر نسخهٔ سایت به‌تنهایی راه مطمئنی نیست؛ اول باید سازگاری برنامه و وصلهٔ شاخهٔ مقصد مشخص شود.
قبل از به‌روزرسانی، PHP فعال سایت را پیدا کنید
یک سرور ممکن است هم‌زمان چند نسخهٔ PHP داشته باشد: یکی برای خط فرمان، چند نسخه برای سایت‌های cPanel، یک نسخه برای PHP-FPM و نسخه‌هایی از CloudLinux PHP Selector. دستور
php -v معمولاً فقط PHP پیش‌فرض خط فرمان را نشان می‌دهد. ممکن است سایت شما با نسخهٔ دیگری اجرا شود.برای شروع، نام سیستم‌عامل را ببینید:
cat /etc/os-release
در سرورهای cPanel، نسخهٔ PHP هر دامنه را از بخش MultiPHP Manager و نسخه‌های نصب‌شده را در EasyApache 4 ببینید. در DirectAdmin، دستور
da build versions نسخه‌های مدیریت‌شده با CustomBuild را فهرست می‌کند. در CloudLinux، نسخهٔ انتخاب‌شده برای حساب را در PHP Selector نیز بررسی کنید.قبل از تغییر بزرگ، از فایل‌های سایت و پایگاه داده نسخهٔ پشتیبان بگیرید. اگر چند فروشگاه یا سایت پرترافیک دارید، به‌روزرسانی را در بازهٔ کم‌ترافیک انجام دهید و یک سایت آزمایشی را هم بررسی کنید. نصب وصلهٔ امنیتی معمولاً شاخهٔ PHP را عوض نمی‌کند؛ بنابراین بهتر است ابتدا همان بستهٔ فعلی را به نسخهٔ وصله‌شده برسانید و فقط در صورت نیاز سازگاری، مهاجرت شاخه را جداگانه آزمایش کنید.
Ubuntu: نصب اصلاحیه از مخزن رسمی
اعلان امنیتی اوبونتو می‌گوید یک به‌روزرسانی استاندارد سیستم، بسته‌های لازم را نصب می‌کند. برای سرورهایی که با APT مدیریت می‌شوند، با کاربر دارای دسترسی sudo اجرا کنید:
sudo apt update
sudo apt upgrade
اگر سیاست نگه‌داری شما فقط به‌روزرسانی بسته‌های نصب‌شدهٔ PHP را اجازه می‌دهد، ابتدا بسته‌های نصب‌شده را فهرست کنید:
dpkg-query -W 'php*' 2>/dev/null
بعد فقط نام‌هایی را که واقعاً نصب هستند به فرمان
apt install --only-upgrade بدهید. نمونه برای PHP 8.3:sudo apt install --only-upgrade php8.3-cli php8.3-fpm php8.3-cgi libapache2-mod-php8.3
اگر بعضی از این بسته‌ها نصب نیستند، نامشان را از فرمان حذف کنید. برای PHP 8.1 یا 8.5 هم نام بسته‌ها را مطابق نسخهٔ فعال خود تغییر دهید. اوبونتو برای هر نسخه، بسته‌های CLI، FPM، CGI و Apache را جداگانه ارائه می‌کند؛ به‌روزرسانی فقط CLI، پردازشگر وب‌سایت را وصله نمی‌کند.
پس از نصب، نسخهٔ بسته را با اعلان USN-8948-1 اوبونتو تطبیق دهید. این اعلان در زمان انتشار این مقاله حداقل نسخه‌های زیر را برای بسته‌های همان شاخه گزارش می‌کند:
| نسخهٔ اوبونتو | شاخهٔ PHP | حداقل نسخهٔ بسته |
| --- | --- | --- |
| 22.04 LTS | 8.1 | 8.1.2-1ubuntu2.28 |
| 24.04 LTS | 8.3 | 8.3.6-0ubuntu0.24.04.13 |
| 26.04 LTS | 8.5 | 8.5.4-0ubuntu1.5 |
| 26.10 | 8.5 | 8.5.9-0ubuntu2.1 |
برای بررسی بسته، مثلاً این دستور را اجرا کنید:
apt-cache policy php8.3-fpm
مقدار Installed باید برابر نسخهٔ اصلاح‌شده یا بالاتر باشد. نسخهٔ نصب‌شدهٔ سایت خودتان را جایگزین
php8.3-fpm کنید. اگر از PHP-FPM استفاده می‌کنید، سرویس همان شاخه را دوباره راه‌اندازی کنید؛ نام سرویس نمونه برای 8.3 چنین است:sudo systemctl restart php8.3-fpm
اگر Apache با mod_php درخواست‌ها را اجرا می‌کند، پس از نصب بستهٔ مربوط، سرویس Apache را طبق برنامهٔ نگه‌داری خود راه‌اندازی کنید:
sudo systemctl restart apache2
نام سرویس را حدس نزنید؛ قبل از restart، با مدیر سرور یا تنظیم وب‌سرور تأیید کنید که همان handler فعال است. فهرست نسخه‌ها و بسته‌های دقیق ممکن است با فعال‌بودن مخزن شخص ثالث تغییر کند؛ برای بستهٔ Remi، PPA یا مخزن اختصاصی، اعلان همان منبع ملاک است.
AlmaLinux: وصلهٔ backport و بررسی شمارهٔ بسته
تیم AlmaLinux بسته‌های اصلاح‌شده را برای شاخه‌های PHP این توزیع منتشر کرده است. دستور عمومی سازنده این است:
sudo dnf clean metadata
sudo dnf upgrade 'php*'
sudo systemctl restart php-fpm
اگر AlmaLinux 8 شما واقعاً از mod_php استفاده می‌کند، سرویس Apache را restart کنید:
sudo systemctl restart httpd
این فرمان‌ها را روی سروری که PHP را cPanel، CloudLinux یا مخزن دیگری مدیریت می‌کند کورکورانه اجرا نکنید؛ در آن حالت همان بستهٔ پنل یا فروشنده مسئول است. نصب بسته‌های AlmaLinux روی Rocky Linux یا توزیع دیگر هم راه‌حل عمومی نیست.
برای تطبیق، اعلان AlmaLinux دربارهٔ php2shell را باز کنید. این اعلان شمارهٔ حداقل بستهٔ اصلاح‌شده را به تفکیک نسخه و stream نوشته است. برای نمونه، PHP 8.2 در AlmaLinux 8 و 9 به
php-8.2.33 رسیده و نسخهٔ PHP 8.3 پیش‌فرض AlmaLinux 10 به php-8.3.33. شمارهٔ کامل RPM علاوه بر این عدد، شمارهٔ انتشار و شناسهٔ مخزن را هم دارد.در زمان تهیهٔ این راهنما، شماره‌های حداقل منتشرشده در اعلان AlmaLinux چنین‌اند:
| سیستم | شاخه | بستهٔ وصله‌شده یا بالاتر |
| --- | --- | --- |
| AlmaLinux 8 | PHP 7.2 | php-7.2.24-1.module_el8.10.0+4315+7b734bf3.alma.1 |
| AlmaLinux 8 | PHP 7.3 | php-7.3.20-1.module_el8.10.0+4316+90ea5fe5.alma.1 |
| AlmaLinux 8 | PHP 7.4 | php-7.4.33-8.module_el8.10.0+4321+cf5fd4bb |
| AlmaLinux 8 | PHP 8.0 | php-8.0.30-1.module_el8.10.0+4319+26f10322.alma.1 |
| AlmaLinux 8 | PHP 8.2 | php-8.2.33-1.module_el8.10.0+4320+c30d6dbb.alma.1 |
| AlmaLinux 9 | پیش‌فرض PHP 8.0 | php-8.0.30-8.el9_8.alma.1 |
| AlmaLinux 9 | PHP 8.1 | php-8.1.32-1.module_el9.8.0+326+528679fc.alma.1 |
| AlmaLinux 9 | PHP 8.2 | php-8.2.33-1.module_el9.8.0+327+37dfd4b4.alma.1 |
| AlmaLinux 9 | PHP 8.3 | php-8.3.33-1.module_el9.8.0+328+1fdeb728.alma.1 |
| AlmaLinux 10 | پیش‌فرض PHP 8.3 | php-8.3.33-1.el10_2.alma.1 |
| AlmaLinux 10 | PHP 8.4 | php8.4-8.4.24-1.el10_2.alma.1 |
شمارهٔ کامل RPM را دقیق با خروجی سرور مقایسه کنید؛ عددهای این جدول را به مخزن یا توزیع دیگری تعمیم ندهید.
بررسی بستهٔ سیستم:
rpm -q php-common
برای PHP 8.4 روی AlmaLinux 10، بستهٔ متناظر در اعلان
php8.4-common است:rpm -q php8.4-common
وصلهٔ backport ممکن است عدد PHP را در خروجی
php -v عوض نکند؛ نسخهٔ RPM را با فهرست AlmaLinux تطبیق دهید. اگر مخزن هنوز نسخهٔ وصله‌شده را نشان نمی‌دهد، ابتدا آینهٔ مخزن را کمی بعد دوباره بررسی کنید و مطمئن شوید stream درست فعال است. به‌روزرسانی از مخزن testing تاریخی دیگر روش پیشنهادی نیست؛ بسته‌ها به مخزن production منتقل شده‌اند.cPanel و EasyApache 4
در cPanel، چند نسخهٔ PHP می‌توانند هم‌زمان نصب باشند و هر دامنه با نسخهٔ خودش کار کند. بنابراین به‌روزرسانی نسخهٔ پیش‌فرض خط فرمان کافی نیست. مدیر سرور با دسترسی root باید وارد WHM → Software → EasyApache 4 شود، بخش Run System Update را اجرا کند و در قسمت بسته‌های نصب‌شده، نسخه‌های فعال PHP را بازبینی کند. اگر پنل برای بستهٔ PHP مورد استفاده به‌روزرسانی ارائه می‌کند، آن را از همین مسیر EasyApache نصب کند.
مستند cPanel دربارهٔ EasyApache 4 توضیح می‌دهد که EasyApache بسته‌های PHP و Apache را نصب و به‌روزرسانی می‌کند. برای به‌روزرسانی PHP خط فرمان cPanel می‌توان از
/usr/local/cpanel/scripts/upcp استفاده کرد، اما این فرمان را با بسته‌های PHP سایت‌های EasyApache یکی ندانید: خود cPanel برای Apache PHP مسیر EasyApache را مشخص می‌کند.پس از پایان به‌روزرسانی، در WHM → Software → MultiPHP Manager نسخهٔ تخصیص‌یافته به هر دامنه را ببینید و در EasyApache 4 → Currently Installed Packages بررسی کنید همهٔ نسخه‌هایی که کاربران واقعاً استفاده می‌کنند به‌روز شده‌اند. یک سرور ممکن است PHP 8.2، 8.3 و 8.4 را هم‌زمان داشته باشد؛ وصله‌کردن تنها یکی از آن‌ها کافی نیست اگر دامنه‌ای هنوز با نسخهٔ آسیب‌پذیر دیگری اجرا شود.
اگر گزینهٔ بستهٔ جدید را نمی‌بینید، به‌روزرسانی cPanel/EasyApache را بررسی کنید و وضعیت انتشار بسته را از یادداشت‌های انتشار cPanel یا پشتیبانی میزبان بپرسید. سیستم را با نصب دستی فایل PHP یا تعویض تصادفی handler اصلاح نکنید؛ ممکن است افزونه‌ها، FPM یا پیکربندی Apache از کار بیفتند.
DirectAdmin و CustomBuild
در DirectAdmin، اول نسخه‌ها و اجزای مدیریت‌شده را ببینید:
da build versions
در رابط گرافیکی DirectAdmin به Admin Level → CustomBuild → Updates بروید. این صفحه نسخه‌های تازه را نشان می‌دهد و می‌توانید PHP مورد استفاده را جداگانه انتخاب کنید. اگر خط فرمان را ترجیح می‌دهید، فرمان زیر همهٔ نرم‌افزارهای مدیریت‌شده با CustomBuild را به‌روزرسانی می‌کند؛ چون فقط PHP را هدف نمی‌گیرد، آن را در زمان نگه‌داری برنامه‌ریزی‌شده اجرا کنید:
da build update_versions
بعد دوباره فهرست نسخه‌ها را ببینید:
da build versions
در خروجی، PHPهای فعال و نسخهٔ هرکدام را بررسی کنید. مستند به‌روزرسانی سرویس‌ها در DirectAdmin CustomBuild می‌گوید Update All در CustomBuild نسخه‌های تازهٔ اجزای مدیریت‌شده را اعمال می‌کند. اگر نسخهٔ PHP را دستی در
custom_versions.txt ثابت نگه داشته‌اید، CustomBuild می‌تواند همان نسخهٔ قدیمی را حفظ کند؛ آن override را هم بررسی کنید.اگر نیاز باشد یک نسخهٔ PHP دوباره ساخته یا تنظیمش عوض شود، طبق راهنمای PHP در DirectAdmin همان شاخه را با تنظیم سازگار بازسازی و پیکربندی وب‌سرور را بازنویسی کنید. فرمان
da build php می‌تواند PHP تنظیم‌شده را بسازد، اما اول بررسی کنید فایل versions و تنظیم‌های CustomBuild به نسخهٔ اصلاح‌شده اشاره کنند؛ اجرای build با منبع قدیمی وصله را نصب نمی‌کند.CloudLinux و PHP Selector
در سرور CloudLinux، ممکن است دامنه از alt-PHP در PHP Selector استفاده کند، در حالی که PHP خود cPanel یا DirectAdmin جداگانه مدیریت می‌شود. مستند CloudLinux برای به‌روزرسانی PHP Selector این فرمان را پیشنهاد می‌کند:
yum groupupdate alt-php
این به‌روزرسانی نسخه‌های alt-PHP را از مخزن CloudLinux می‌گیرد. مدیر سرور باید مطمئن شود مخزن CloudLinux نسخهٔ وصله‌شده را برای شاخهٔ فعال منتشر کرده و هر دو مسیر استفاده‌شده، یعنی alt-PHP و PHP پنل، پوشش داده شده‌اند. انتخاب نسخه در PHP Selector صرفاً شاخهٔ اجرایی را عوض می‌کند و به‌تنهایی جای نصب بستهٔ اصلاح‌شده را نمی‌گیرد.
پس از نصب، واقعاً چه چیزهایی را بررسی کنیم؟
این چند مرحله جلوی اشتباه رایجِ «بسته نصب شد، پس همه‌چیز درست است» را می‌گیرد:
- بستهٔ درست را دیدید؟ در Ubuntu از
apt-cache policyو در AlmaLinux ازrpm -qخروجی بگیرید. در cPanel به فهرست بسته‌های EasyApache و در DirectAdmin بهda build versionsرجوع کنید. - همهٔ نسخه‌های فعال وصله شده‌اند؟ PHPهای قدیمی که فقط برای یک دامنه نصب شده‌اند هم مهم هستند. نسخهٔ خط فرمان، نسخهٔ PHP-FPM و نسخهٔ تخصیص‌یافته به هر دامنه را جداگانه بررسی کنید.
- workerهای PHP دوباره راه‌اندازی شده‌اند؟ اگر فایل اجرایی به‌روز شده اما پردازش قدیمی همچنان درخواست می‌گیرد، وضعیت سرویس را با
systemctl statusیا ابزار پنل بررسی کنید. سرویس درست را restart کنید. - سایت اصلی هنوز کار می‌کند؟ صفحهٔ اصلی، ورود مدیر، فرم تماس، بارگذاری فایل، cron وردپرس، ارسال ایمیل و اگر فروشگاه دارید مسیر سبد خرید و پرداخت را آزمایش کنید. خطای تازه را در گزارش وب‌سرور و PHP-FPM پیدا کنید.
- گزارش کار را نگه داشتید؟ زمان به‌روزرسانی، نسخهٔ بسته، نسخه‌های دامنه‌ها و نتیجهٔ آزمایش سایت را ثبت کنید. این کار دفعهٔ بعد مشخص می‌کند کدام PHP واقعاً فعال بوده است.
اگر سرویس پس از به‌روزرسانی خطا داد، اول خطا و نسخهٔ افزونه یا کد ناسازگار را پیدا کنید. برگشت دائم به PHP آسیب‌پذیر راه‌حل امنیتی نیست؛ سازگاری را روی نسخهٔ وصله‌شده رفع کنید. اگر ناچار به بازگشت موقت هستید، دسترسی عمومی را محدود و زمان بازگشت وصله را کوتاه کنید.
تا زمانی که بستهٔ سازنده در دسترس نیست
وصلهٔ منتشرشده راه‌حل کامل است. خاموش‌کردن نمایش خطا، تغییر
error_reporting یا اضافه‌کردن @ جلوی این دو نقص را نمی‌گیرد. تغییر نسخهٔ وردپرس هم موتور PHP را اصلاح نمی‌کند.در یک نصب خودمدیریت‌شده که هنوز بستهٔ vendor آماده نشده، از پشتیبانی توزیع، پنل یا ارائه‌دهندهٔ PHP زمان‌بندی روشن بگیرید و وب‌سرور را پشت محدودیت اندازهٔ درخواست و قواعد امنیتی موجود نگه دارید. برای مسیر تأییدشدهٔ مربوط به session upload progress، PHP توصیه می‌کند این قابلیت در تنظیم عمومی PHP-FPM یا
php.ini خاموش شود، اگر برنامه به آن نیاز ندارد. این تنظیم فقط بخشی از مسیرها را می‌بندد و جای وصله را نمی‌گیرد؛ قرار دادن آن در .user.ini یا تنظیم دیرهنگام برنامه هم برای این مسیر کافی نیست. تغییرات تنظیمات PHP باید با راهنمای پنل و restart کنترل‌شده انجام شود.از افزایش نامحدود حافظه، کپی‌کردن فایل PHP از یک سرور دیگر یا نصب RPM/DEB از مخزن نامرتبط به‌عنوان «راه سریع» استفاده نکنید. ممکن است مشکل امنیتی را باقی بگذارید و هم‌زمان سایت را از کار بیندازید.
چند پرسش رایج
آیا فقط سایت‌های وردپرسی آسیب‌پذیرند؟
خیر. نقص داخل موتور PHP است و به وردپرس محدود نمی‌شود. هر برنامهٔ PHP که از یک runtime آسیب‌پذیر درخواست وب می‌گیرد باید وضعیت بستهٔ همان runtime را بررسی کند. به‌روزرسانی وردپرس، جوملا یا افزونه‌ها کار خوبی است، اما جای وصلهٔ PHP را نمی‌گیرد.
اگر در cPanel نسخهٔ PHP دامنه را عوض کنم مشکل حل می‌شود؟
نه لزوماً. تغییر نسخه در MultiPHP Manager فقط handler دامنه را به شاخهٔ دیگری می‌برد. اگر شاخهٔ تازه هم بستهٔ اصلاح‌نشده داشته باشد، مشکل باقی می‌ماند. اول وضعیت بستهٔ آن نسخه را در EasyApache و اعلان سازنده تأیید کنید.
چرا php -v هنوز 8.2 یا 8.3 نشان می‌دهد؟
در بسته‌های Ubuntu و AlmaLinux ممکن است وصله به نسخهٔ قدیمی backport شده باشد تا سازگاری برنامه حفظ شود. به همین علت، شمارهٔ توزیع بسته را از
apt-cache policy یا rpm -q بررسی کنید. در cPanel و DirectAdmin هم نسخهٔ PHP وب‌سایت ممکن است با PHP خط فرمان فرق کند.آیا لازم است وردپرس را دوباره نصب کنم؟
خیر. برای اصلاح موتور PHP نیازی به نصب دوبارهٔ سایت نیست. از فایل‌ها و پایگاه داده نسخهٔ پشتیبان داشته باشید، وصلهٔ runtime را از مدیر میزبان یا مخزن رسمی بگیرید و سپس عملکرد برنامه را آزمایش کنید.
کاربر هاست اشتراکی چه کند؟
روی هاست اشتراکی نت‌آرام، به‌روزرسانی PHP از سوی تیم فنی انجام شده است؛ برای این مورد فرمان سیستمی اجرا نکنید و نسخهٔ PHP را به‌صورت تصادفی تغییر ندهید. اگر پیام خطایی پس از به‌روزرسانی می‌بینید، نام دامنه و متن خطا را برای پشتیبانی بفرستید تا handler همان دامنه بررسی شود.
منابع رسمی
اشتراک‌گذاری:
لینکدینتلگرامایکس
مقاله قبلی
مقاله قبلی وجود ندارد.
مقاله بعدی
دیدگاه‌ها (۰)
دیدگاه‌های تاییدشده و پاسخ‌های تیم نت‌آرام