دکمه تغییر نسخه PHP در سی پنل پیدا است، اما یک نگرانی جدی باقی می ماند: اگر بعد از تغییر، درگاه پرداخت یا صفحه ساز از کار افتاد چه کنیم؟ برای آپدیت PHP وردپرس، اول نسخه فعلی و سازگاری اجزای سایت را مشخص کنید، تغییر را روی نسخه آزمایشی انجام دهید و بعد سراغ سایت اصلی بروید. داشتن بکاپ لازم است؛ داشتن راه برگشتی که سفارش های تازه را از بین نبرد، لازم تر است.
این راهنما برای سایتی است که اکنون کار می کند و قرار است محیط اجرای آن ارتقا پیدا کند. هدف فقط عوض شدن یک عدد در کنترل پنل نیست. باید مطمئن شوید همان کارهایی که کاربر دیروز انجام می داد، بعد از ارتقا هم درست انجام می شوند.
کدام نسخه PHP را انتخاب کنیم؟
بالاترین عدد فهرست، لزوما انتخاب آماده برای سایت شما نیست. نسخه هدف باید هم در دوره پشتیبانی رسمی PHP باشد، هم با نسخه وردپرس، قالب، افزونه ها و کد اختصاصی سایت سازگار باشد. موجود بودن یک نسخه در پنل هم به تنهایی نشانه پشتیبانی امنیتی آن نیست.
در زمان بررسی این مطلب در اکتبر ۲۰۲۶، شاخه های 8.2 تا 8.5 در جدول رسمی نسخه های پشتیبانی شده PHP قرار دارند؛ پشتیبانی امنیتی 8.2 در پایان ۲۰۲۶ تمام می شود. هنگام اجرای کار، همین جدول را دوباره ببینید. انتخاب نسخه ای که به پایان پشتیبانی نزدیک است، شاید فقط یک توقف کوتاه در مسیر ارتقا باشد.
نیازمندی های فعلی وردپرس و جدول سازگاری نسخه های وردپرس و PHP نقطه شروع هستند. نتیجه این جدول درباره هسته وردپرس است؛ افزونه قدیمی ارسال پیامک یا قالب سفارشی شما همچنان باید جدا بررسی شود. حداقل نسخه قابل اجرا را هم با نسخه مناسب برای نگهداری بلندمدت یکی نگیرید.
پیش از تغییر، یک برگه وضعیت بسازید
از مسیر ابزارها، سلامت سایت، اطلاعات، بخش سرور، نسخه PHP مورد استفاده وب سایت را بخوانید. نسخه وردپرس، قالب فعال، افزونه های حیاتی و تاریخ آخرین تغییر را کنارش بنویسید. مشخص کنید فروشگاه سفارش می گیرد، کاربران فایل می فرستند یا عضویت تازه ثبت می شود؛ این اطلاعات برای زمان تغییر و تصمیم بازگشت لازم اند.
در سی پنل هم نام دامنه، ریشه پوشه آن و نسخه انتخاب شده را ثبت کنید. روی حسابی که چند دامنه دارد، تغییر اشتباه دامنه آزمایشی و اصلی آسان است. اگر نسخه روی Inherit قرار دارد، وضعیت وراثت را به پشتیبانی اعلام کنید تا انتخاب فعلی با نسخه پیش فرض سرور اشتباه نشود.
| وضعیت سایت | کار لازم پیش از ارتقا | نشانه آمادگی |
|---|---|---|
| قالب و افزونه ها پشتیبانی فعال دارند | بررسی مستندات سازگاری و آزمون نسخه آزمایشی | مسیرهای اصلی بدون خطای تازه اجرا می شوند |
| افزونه حیاتی قدیمی است | گرفتن پاسخ سازنده، اصلاح یا یافتن جایگزین | وابستگی ناسازگار تعیین تکلیف شده است |
| فروشگاه سفارش زنده دارد | تعیین بازه تغییر و برنامه حفظ داده جدید | مسئول تصمیم و راه برگشت مشخص است |
| نسخه هدف در پنل نیست | پرسش از میزبان درباره دسترسی و افزونه های PHP | محیط مقصد و امکان بازگشت تایید شده است |
نسخه آزمایشی باید به سایت اصلی شبیه باشد
یک کپی آزمایشی یا staging با فایل ها و پایگاه داده هماهنگ تهیه کنید. افزونه ها، تنظیمات مهم PHP و امکانات سرور تا حد ممکن مشابه محیط اصلی باشند. آزمایش روی یک نصب خالی وردپرس، سازگاری فروشگاهی را که سال ها افزونه و کد سفارشی جمع کرده ثابت نمی کند.
دسترسی این کپی را محدود کنید، جلوی ایندکس شدنش را بگیرید و ارسال پیامک، ایمیل واقعی، وب هوک و پرداخت زنده را مطابق امکانات هر سرویس به محیط تست منتقل یا مهار کنید. کپی فروشگاه ممکن است کارهای زمان بندی شده خود را هم اجرا کند. داده مشتریان را بی دلیل در محیطی با دسترسی باز تکثیر نکنید.
اگر وردپرس و افزونه ها هم نیاز به آپدیت دارند، آن تغییرها را جدا ثبت و بررسی کنید؛ یک بار همه چیز را عوض نکنید و بعد دنبال مقصر بگردید. توضیحات انتشار سازنده درباره نسخه PHP هدف را بخوانید. ابزار بررسی سازگاری می تواند سرنخ بدهد، ولی جای اجرای واقعی فرم، خرید و کارهای پس زمینه را نمی گیرد.
بکاپ و راه برگشت را قبل از Apply آماده کنید
نسخه پشتیبان باید هم فایل ها و هم پایگاه داده را پوشش دهد. دانلود پوشه public_html به معنی داشتن بکاپ دیتابیس نیست. راهنمای پشتیبان گیری وردپرس این دو بخش را جدا توضیح می دهد. زمان مجموعه بکاپ، محل نگهداری و فردی که می تواند آن را بازیابی کند مشخص باشد؛ بهتر است قابلیت بازیابی در یک محیط جدا امتحان شده باشد.
پیشاپیش بپرسید آیا نسخه قبلی PHP بعد از تغییر همچنان در اختیار شما خواهد بود. محدودیت حساب یا تصمیم مدیر سرور ممکن است برگشت از داخل پنل را ناممکن کند. همچنین دسترسی سی پنل را بررسی کنید؛ وقتی خود وردپرس باز نمی شود، باید راهی مستقل برای برگشت یا خواندن لاگ داشته باشید.
یک مثال فرضی: ساعت ۱۰ بکاپ گرفته اید، ساعت ۱۰:۱۵ ارتقا انجام شده و تا ۱۰:۳۰ پنج سفارش ثبت شده است. بازگردانی کامل دیتابیس ساعت ۱۰ ممکن است آن سفارش ها را حذف کند. تغییر PHP به تنهایی معمولا نیاز به بازگرداندن دیتابیس ندارد؛ اما اگر همراهش افزونه ای آپدیت شده و ساختار داده را تغییر داده، نسخه قدیمی کد هم شاید با داده جدید کار نکند. اینجا باید سازگاری فایل و دیتابیس و حفظ سفارش های تازه را با مسئول فنی بررسی کرد.
تغییر نسخه PHP در cPanel
پس از موفقیت آزمون، بازه کم رفت و آمدی انتخاب کنید و به افراد مرتبط خبر بدهید. در سی پنل وارد Software و سپس MultiPHP Manager شوید. فقط دامنه مورد نظر را انتخاب کنید، نسخه تایید شده را از PHP Version بردارید و Apply را بزنید. طبق مستندات MultiPHP Manager، نسخه های قابل انتخاب به نصب و دسترسی همان حساب وابسته اند.
بعضی میزبان ها ابزار متفاوتی مانند Select PHP Version ارائه می کنند. هم زمان در دو ابزار یا با افزودن دستورهای تصادفی به .htaccess نسخه را تغییر ندهید. اگر رابط کاربری متفاوت است، نام ابزار و دامنه را برای پشتیبانی بفرستید. نسخه را پس از اعمال دوباره از اطلاعات سرور وردپرس بخوانید؛ ظاهر پنل به تنهایی معیار پایان نیست.
نسخه وب با نسخه خط فرمان یکی فرض نشود
اگر cron، صف پردازش یا فرمان نگهداری با PHP اجرا می شود، مفسر همان فرمان را هم بررسی کنید. خروجی php -v در ترمینال لزوما نسخه ای نیست که درخواست مرورگر را اجرا می کند. در cPanel مسیر مفسر و روش انتخاب آن اهمیت دارد؛ راهنمای ea-php-cli رفتار ابزارهای خط فرمان را توضیح داده است.
php -v
php --ini
php -mاین فرمان ها نسخه، فایل تنظیمات و ماژول های محیط خط فرمان را نشان می دهند. نتیجه را فقط برای همان محیط تفسیر کنید. مسیر مفسر در cron را از میزبان بگیرید؛ کپی کردن یک مسیر شامل شماره نسخه از آموزشی دیگر ممکن است کار زمان بندی شده شما را متوقف کند.
آزمونی که صفحه اصلی از آن خبر نمی دهد
صفحه اصلی ممکن است از کش نمایش داده شود. ورود، جستجو، ذخیره نوشته، بارگذاری عکس و فرم تماس را هم بررسی کنید. در فروشگاه، افزودن به سبد، کد تخفیف، محاسبه ارسال و مسیر پرداخت آزمایشی مهم اند. رسید ایمیل، پیامک و نتیجه کارهای پس زمینه را جدا ببینید؛ نمایش پیام موفقیت همیشه به معنی انجام شدن کار در مقصد نیست.
یک فرم نماینده با همان داده تست قبل از ارتقا ارسال کنید و خروجی را مقایسه کنید. اگر پردازش تصویر خراب شده یا کلاس خاصی پیدا نمی شود، ماژول مورد نیاز در نسخه جدید PHP را با محیط قبلی تطبیق دهید. بالا بردن حافظه یا زمان اجرا بدون دیدن خطا، سازگاری کد را اصلاح نمی کند.
لاگ PHP را در همان دقیقه آزمون بررسی کنید. برای بررسی دقیق تر در staging، ابزارهای اشکال زدایی وردپرس در دسترس اند. پیام خطا را به بازدیدکننده نشان ندهید و لاگ شامل اطلاعات حساس را عمومی نگذارید. خطای Fatal، هشدار تکرارشونده و پیام Deprecated پیامد یکسان ندارند؛ نام فایل، شماره خط و عملیات مرتبط را برای توسعه دهنده ثبت کنید.
اگر سایت خراب شد، چه چیزی را برگردانیم؟
اگر تنها تغییر، نسخه PHP بوده و بعد از آن خطای مشخصی شروع شده، برگشت به نسخه قبلی در دسترس یک اقدام موقت قابل بررسی است. پس از برگشت، همان عملیات خراب را تکرار کنید. سالم شدن سایت، سرنخ ارتباط مشکل با محیط جدید است؛ دلیل کافی برای رها کردن دائمی ارتقا نیست. وابستگی ناسازگار باید اصلاح شود.
اگر فایل یا دیتابیس هم تغییر کرده، بازیابی را بدون بررسی داده های جدید شروع نکنید. ممکن است برگشت محدود یک افزونه، نصب نسخه اصلاح شده یا کمک سازنده، از بازگردانی کامل فروشگاه مناسب تر باشد. برای هماهنگی این تغییرها می توانید محدوده مدیریت و پشتیبانی سایت را بررسی کنید.
سه پرسش پیش از بستن کار
آیا آپدیت PHP حتما سرعت سایت را بیشتر می کند؟
نتیجه به کد و گلوگاه سایت وابسته است. یک درخواست کند به API یا کوئری نامناسب ممکن است همچنان کند بماند. عملکرد را با صفحه و شرایط یکسان، پیش و پس از تغییر بسنجید؛ عدد نسخه معیار اندازه گیری سرعت نیست.
اگر نسخه جدید در هاست ارائه نشده باشد چه کنیم؟
نسخه هدف، ماژول های لازم و زمان نیازتان را به میزبان اعلام کنید. هنگام مقایسه هاست لینوکس برای وردپرس هم امکان انتخاب نسخه و پشتیبانی وابستگی های پروژه را مشخص کنید.
چه وقت ارتقا را تمام شده بدانیم؟
وقتی نسخه واقعی وب تایید شده، آزمون های حساس موفق اند، cron لازم کار می کند و خطای تازه مرتبط در لاگ باقی نمانده است. نتیجه، نسخه قبلی و جدید و مشکل های اصلاح شده را ثبت کنید تا تغییر بعدی از نقطه روشن تری شروع شود.
سرویس‌های مرتبط با این مطلب
برای بررسی راهکار مناسب، مشخصات و شرایط این خدمات را ببینید.
پرسش‌ها و دیدگاه‌های شما
سؤال یا تجربه مرتبط با این مطلب دارید؟ با ما و خوانندگان مجله آفاق هاست در میان بگذارید.