بهترین نسخه PHP برای وردپرس نسخه ای است که در چرخه پشتیبانی قرار داشته باشد، با نسخه هسته و اجزای سایت شما سازگار باشد و روی هاست به شکل درست نگهداری شود. در تاریخ بررسی این راهنما، 10 نوامبر 2026، توصیه عمومی WordPress.org استفاده از PHP 8.3 یا بالاتر است. برای یک سایت به روز، PHP 8.4 یا 8.5 می تواند وارد آزمون شود؛ انتخاب نهایی به نسخه وردپرس، قالب، افزونه ها و کدهای اختصاصی شما بستگی دارد.
اگر سایت با PHP قدیمی هنوز باز می شود، این به معنی مناسب بودن آن برای ادامه کار نیست. از طرف دیگر، تغییر مستقیم به بالاترین عدد پنل بدون آزمون هم تصمیم دقیقی نیست. در این مقاله، یک روش عملی برای انتخاب نسخه، بررسی سازگاری و ارتقای قابل بازگشت ارائه می کنیم تا فرم ها، ورود کاربران و کار روزانه سایت سالم بمانند.
چرا انتخاب نسخه PHP برای وردپرس مهم است؟
PHP کد سمت سرور وردپرس و بخش زیادی از قالب ها و افزونه ها را اجرا می کند. تفاوت نسخه می تواند روی رفتار کد، پیام های خطا، امکانات زبان و نگهداری امنیتی اثر بگذارد. برای مدیر سایت، مهم ترین نتیجه این است که زیرساختی قابل نگهداری داشته باشد و سایت در مسیرهای ضروری مانند ثبت فرم، ویرایش نوشته و ورود کاربر درست کار کند.
نسخه زبان تنها یکی از اجزای میزبانی است. سهم پردازنده، حافظه، پایگاه داده، کش و شبکه نیز در کیفیت پاسخ اثر دارند. هنگام انتخاب هاست وردپرس ارومیا سرور، علاوه بر فهرست نسخه های قابل انتخاب، درباره روند نصب وصله، محیط تست و روش بازگشت سوال کنید. در یک سرویس مناسب، صرفا وجود یک عدد جدید در پنل کافی نیست.
تفاوت حداقل لازم، نسخه توصیه شده و سازگاری واقعی
حداقل لازم یعنی نسخه مشخصی از وردپرس هنوز امکان اجرا در آن محیط را دارد. توصیه عمومی وردپرس، محیط مناسب تری برای نگهداری به روز معرفی می کند. سازگاری واقعی سایت یک قدم دیگر است: هسته، قالب، افزونه ها و کدهای اختصاصی باید کنار هم آزمایش شوند. ممکن است هسته با یک نسخه PHP سازگار باشد اما یک افزونه قدیمی در همان محیط خطا بدهد.
جدول رسمی سازگاری را با ردیف نسخه نصب شده خود بخوانید. برای نمونه، جدول فعلی وردپرس برای هسته 7.1، نسخه های PHP 8.3، 8.4 و 8.5 را سازگار نشان می دهد؛ در ردیف وردپرس 6.8، برای PHP 8.5 علامت عدم سازگاری آمده است. پس جمله کلی «وردپرس از این نسخه پشتیبانی می کند» بدون مشخص کردن نسخه هسته، راهنمای کاملی نیست. جدول نیز درباره هسته است و سلامت افزونه های شما را تایید نمی کند.
جدول انتخاب نسخه PHP در نوامبر 2026
| شاخه PHP | وضعیت در تاریخ بررسی | پایان پشتیبانی امنیتی رسمی | اقدام پیشنهادی |
|---|---|---|---|
| 8.1 و قدیمی تر | خارج از پشتیبانی بالادستی | پایان یافته | برای خروج از شاخه قدیمی برنامه مشخص تهیه کنید |
| 8.2 | فقط اصلاحات امنیتی | 31 دسامبر 2026 | مهاجرت را به آخرین روز موکول نکنید |
| 8.3 | فقط اصلاحات امنیتی | 31 دسامبر 2027 | با وصله جاری و تایید سازگاری قابل استفاده است |
| 8.4 | پشتیبانی فعال تا پایان 2026 | 31 دسامبر 2028 | گزینه مناسب برای آزمون ارتقای سایت سازگار |
| 8.5 | پشتیبانی فعال | 31 دسامبر 2029 | نسخه هسته و تمام وابستگی ها را پیش از انتخاب کنترل کنید |
تاریخ های جدول مربوط به پروژه PHP هستند. اگر میزبان برای نسخه قدیمی پشتیبانی تمدید شده تجاری ارائه می کند، دامنه اصلاحات و مدت آن را جدا بررسی کنید. این خدمت، سازگاری یک افزونه رهاشده را تضمین نمی کند. نسخه های آزمایشی مانند RC نیز مبنای انتخاب معمول برای سایت اصلی نیستند؛ برای محیط زنده، انتشار پایدار و سازگار را ارزیابی کنید.
PHP 8.3، 8.4 یا 8.5؛ کدام برای سایت شما مناسب است؟
سایت شرکتی یا محتوایی به روز
اگر هسته و اجزای سایت به روز هستند، نسخه های 8.4 و 8.5 را متناسب با جدول سازگاری هسته در محیط جدا بررسی کنید. افق پشتیبانی طولانی تر مزیت است، اما نتیجه آزمون منو، فرم تماس، جستجو و ویرایشگر را هم در تصمیم لحاظ کنید. صرف باز شدن صفحه اصلی، معیار کافی برای تایید نیست. نتیجه را با نسخه دقیق قالب و افزونه ها ثبت کنید تا تغییر بعدی قابل پیگیری باشد.
سایت دارای افزونه یا قالب قدیمی
ابتدا وابستگی مانع ارتقا را مشخص کنید. آیا سازنده نسخه سازگار منتشر کرده است؟ آیا کد اختصاصی به اصلاح نیاز دارد؟ آیا جایگزین قابل انتقال وجود دارد؟ اگر ماندن موقت روی 8.3 وصله شده لازم شد، برای رفع مانع زمان و مسئول تعیین کنید. بازگرداندن محیط پس از خطا می تواند اقدام موقت باشد، اما نگهداری نامحدود یک وابستگی ناسازگار مشکل را به آینده منتقل می کند.
فروشگاه و سامانه عضویت
در سایت هایی که سفارش، اشتراک یا اطلاعات اختصاصی کاربران دارند، آزمون جریان های پویا اهمیت بیشتری دارد. نسخه PHP را با درگاه، حمل، تمدید اشتراک و وظایف پس زمینه هماهنگ بررسی کنید. برای جزئیات فروشگاهی، راهنمای بهترین نسخه PHP برای ووکامرس را بخوانید؛ این مقاله روی تصمیم عمومی وردپرس، سایت محتوایی و نگهداری محیط تمرکز دارد.
نسخه PHP فعلی را از کجا پیدا کنیم؟
در پیشخوان وردپرس به «ابزارها، سلامت سایت» و سپس بخش اطلاعات سرور بروید. نسخه گزارش شده برای اجرای وب را همراه تاریخ یادداشت کنید. پنل هاست نیز ابزار انتخاب نسخه دارد، اما تنظیم هر دامنه ممکن است مستقل باشد. هنگام تغییر، مطمئن شوید همان دامنه هدف را انتخاب کرده اید و تنظیم سایر سایت های حساب تغییر نمی کند.
نسخه PHP در ترمینال ممکن است با محیط وب متفاوت باشد. اگر کار زمان بندی شده، فرمان WP-CLI یا اسکریپت اختصاصی دارید، مفسر همان مسیر هم باید بررسی شود. از پشتیبانی بخواهید نحوه اعمال تنظیم دامنه و اجرای کارهای پس زمینه را توضیح دهد. راهنمای سی پنل یا دایرکت ادمین برای وردپرس کمک می کند ابزار پنل را از کیفیت و تنظیم واقعی سرویس جدا ارزیابی کنید.
برنامه ارتقای قابل بازگشت در 5 مرحله
1. وضعیت موجود را ثبت کنید
نسخه PHP، هسته، قالب، افزونه های فعال و کدهای اختصاصی را فهرست کنید. مسیرهای مهم را بنویسید: صفحه اصلی، نوشته، جستجو، ورود، فرم و مدیریت محتوا. تنظیمات حافظه، افزونه های PHP لازم و برنامه های زمان بندی شده را نیز نگه دارید. این اطلاعات به شما اجازه می دهد علت تغییر رفتار را با محیط قبلی مقایسه کنید.
2. بکاپ قابل بازیابی و محیط تست داشته باشید
از فایل ها و دیتابیس نسخه هماهنگ بگیرید و راه بازیابی را پیش از شروع روشن کنید. یک کپی محافظت شده برای آزمون بسازید و ارسال ایمیل، پیامک و عملیات بیرونی واقعی را در آن کنترل کنید. دسترسی عمومی و ایندکس شدن نسخه آزمایشی را محدود کنید. اگر این خدمات را به میزبان می سپارید، دامنه مسئولیت را در هاست وردپرس مدیریت شده بررسی کنید؛ نام سرویس به تنهایی نوع آزمون را مشخص نمی کند.
3. همان ترکیب نرم افزار را روی نسخه مقصد آزمایش کنید
نسخه PHP را در محیط آزمایشی تغییر دهید و تغییرهای دیگر را ثبت کنید. اگر لازم است افزونه یا هسته نیز به روز شود، ترکیب نهایی را یکجا در آزمون تایید کنید. به جای حدس زدن از روی ظاهر صفحه، عملیات واقعی را اجرا کنید. ذخیره یک نوشته، ارسال فرم و ورود با نقش کاربری معمولی ممکن است خطایی را آشکار کند که در بازدید مهمان دیده نمی شود.
4. تغییر سایت اصلی را کنترل شده انجام دهید
زمان کم ترافیک انتخاب کنید، بکاپ تازه داشته باشید و مسئول بررسی نتیجه را مشخص کنید. تنظیم نسخه دامنه را از ابزار مورد تایید میزبان اعمال کنید. سپس نسخه گزارش شده در سلامت سایت را دوباره ببینید و مسیرهای کلیدی را آزمایش کنید. اگر کاربران در لحظه داده ثبت می کنند، برنامه تغییر باید از از دست رفتن یا دو بار پردازش شدن آن داده جلوگیری کند.
5. پس از تغییر پایش کنید
چند ساعت بعد و در زمان اجرای کارهای زمان بندی شده، گزارش خطا و عملکرد را دوباره بخوانید. یک آزمون فوری همه عملیات دوره ای را پوشش نمی دهد. اگر مشکل پیدا شد، ابتدا تغییر تنظیم محیط و علت خطا را بررسی کنید. ریستور کامل دیتابیس قدیمی بدون توجه به ثبت نام، فرم یا سفارش های تازه می تواند داده های جدید را از بین ببرد؛ راه بازگشت باید متناسب با نوع تغییر باشد.
چک لیست آزمون بعد از تغییر PHP
| بخش | آزمون لازم |
|---|---|
| نمایش عمومی | صفحه اصلی، نوشته، آرشیو، جستجو و صفحه خطای 404 |
| تعامل موبایل | منو، دکمه ها، فرم و بخش های دارای جاوااسکریپت |
| عضویت | ورود، بازیابی رمز و مشاهده محتوای مجاز هر نقش |
| مدیریت محتوا | ذخیره نوشته، صفحه ساز، بارگذاری تصویر و ساخت اندازه های رسانه |
| عملیات بیرونی | ایمیل، پیامک، API و اتصال های ضروری در شرایط کنترل شده |
| کارهای پس زمینه | اجرای وظایف زمان بندی شده و نبود خطای تازه مرتبط |
برای هر آزمون، نتیجه و زمان را ثبت کنید. اگر یک فرم پیام موفقیت می دهد، رسیدن داده به مقصد را هم بررسی کنید. اگر ورود مدیر کار می کند، ورود کاربر عادی را جدا امتحان کنید. آزمون هدفمند با چند مسیر نماینده، اطلاعات بهتری از باز کردن مکرر صفحه اول می دهد و مسئول فنی را سریع تر به علت خطا می رساند.
اگر بعد از ارتقا خطای مهم وردپرس دیدیم
زمان رخداد و عملیاتی را که خطا ساخته یادداشت کنید. خطاهای Fatal، هشدارها و پیام های Deprecated شدت و معنای یکسانی ندارند؛ گزارش باید تفسیر شود. ابزارهای اشکال زدایی وردپرس برای ثبت جزئیات مفید هستند، اما نمایش عمومی خطا روی سایت اصلی مناسب نیست. گزارش ها را با دسترسی محدود و برای مدت لازم نگه دارید و جزئیات حساس را در اختیار بازدیدکننده قرار ندهید.
ممکن است مشکل از کد ناسازگار باشد یا افزونه مورد نیاز PHP در محیط جدید فعال نباشد. در قالب ها یا افزونه های کدگذاری شده، سازگاری Loader و فایل را از سازنده و میزبان بپرسید. کمبود حافظه یا تنظیم متفاوت نیز می تواند پس از تغییر ظاهر شود. بر اساس گزارش، علت را رفع کنید؛ افزایش تصادفی محدودیت ها یا غیرفعال کردن گسترده افزونه ها روی سایت اصلی روش دقیقی نیست.
آیا PHP جدیدتر همیشه سایت را سریع تر می کند؟
بهبود عملکرد به کد و گلوگاه فعلی بستگی دارد و ضریب ثابتی برای همه سایت ها وجود ندارد. صفحه کش شده را از درخواست پویا جدا اندازه بگیرید و قبل و بعد را با داده، محل آزمون و تنظیمات مشابه مقایسه کنید. اگر نسخه PHP، منابع و کش هم زمان تغییر کرده اند، بهبود را به کل محیط نسبت دهید؛ سهم هر عامل بدون مقایسه کنترل شده مشخص نمی شود.
در سایت پرترافیک، نرخ خطا و ثبات پاسخ هم مهم است. راهنمای هاست وردپرس پرترافیک برای سنجش ظرفیت کاربرد دارد. اگر انتظار اصلی از دیسک یا کوئری باشد، مقایسه NVMe و SSD برای وردپرس بخشی از بررسی خواهد بود. ارتقای زبان جای بهینه سازی قالب یا تحلیل پایگاه داده را نمی گیرد.
از میزبان چه اطلاعاتی بخواهیم؟
نسخه شاخه و وضعیت وصله بسته، روش انتخاب نسخه هر دامنه، افزونه های PHP قابل ارائه و امکان محیط تست را بپرسید. شماره اصلی زبان همه اطلاعات اصلاح امنیتی یک بسته تجاری را نشان نمی دهد؛ در صورت استفاده از وصله های ارائه دهنده، اعلامیه و مشخصات بسته باید بررسی شود. نگهداری امنیتی سرور را نیز از سازگاری کد سایت جدا کنید؛ هر دو لازم هستند.
هزینه سرویس را با امکان بازیابی، دسترسی به گزارش و کمک فنی مقایسه کنید. برای همین منظور، مقایسه هاست وردپرس ارزان و حرفه ای را کنار مشخصات پلن بخوانید. سرویس مناسب باید اجرای نسخه انتخابی و نگهداری بعدی آن را ممکن کند، نه اینکه فقط نام نسخه در فهرست سفارش وجود داشته باشد.
پرسش های متداول
برای وردپرس PHP 8.4 بهتر است یا 8.5؟
8.5 افق پشتیبانی طولانی تری دارد، اما باید نسخه هسته و وابستگی های شما آن را پشتیبانی کنند. هر دو را با توجه به جدول رسمی و آزمون محیط واقعی ارزیابی کنید؛ عدد بالاتر به تنهایی تصمیم را تعیین نمی کند.
اگر سایت روی PHP 7.4 باز می شود، چرا تغییر بدهیم؟
اجرا شدن با دریافت اصلاح امنیتی یکسان نیست. برای نسخه خارج از پشتیبانی، باید برنامه خروج و رفع وابستگی قدیمی داشته باشید.
آیا تغییر PHP نوشته ها را حذف می کند؟
تغییر مفسر عملیات حذف محتوا نیست. خطر داده بیشتر به تغییر کد، اختلال پردازش یا بازیابی نادرست مربوط می شود؛ بکاپ و برنامه بازگشت لازم است.
آیا سازگاری هسته وردپرس برای همه افزونه ها کافی است؟
خیر. قالب، افزونه، کد اختصاصی و سرویس های متصل باید جدا بررسی شوند. تایید هسته فقط یک بخش از تصمیم است.
منابع رسمی و تاریخ بررسی
اطلاعات فنی در 10 نوامبر 2026 با نیازمندی های رسمی وردپرس، جدول سازگاری PHP و نسخه های وردپرس، چرخه پشتیبانی رسمی PHP، راهنمای ارتقای PHP وردپرس و مستندات اشکال زدایی وردپرس تطبیق داده شد. هنگام اجرای تغییر، نیازمندی نسخه نصب شده و اعلام سازگاری اجزای سایت را دوباره کنترل کنید.
هیچ نظری ثبت نشده است