آموزش ارتقای نسخه PHP وردپرس؛ بررسی سازگاری، تست و رفع خطاهای ووکامرس

ارتقای نسخه PHP وردپرس یکی از مهم‌ترین کارهای نگهداری فنی سایت است، اما نباید مانند یک تغییر ساده در پنل هاست با آن برخورد کرد. PHP موتور اجرای WordPress، WooCommerce، قالب و افزونه‌هاست. تغییر نسخه آن می‌تواند امنیت و کارایی را بهتر کند، اما اگر افزونه قدیمی، قالب ناسازگار، Extension گمشده، کد سفارشی یا تنظیم متفاوت PHP وجود داشته باشد، نتیجه ممکن است Critical Error، خطای 500، توقف Cron، خرابی Checkout یا پردازش ناقص فایل باشد.

روش حرفه‌ای این است که ابتدا نسخه فعال PHP در Web و CLI شناسایی شود، سپس سازگاری هسته، WooCommerce، WoodMart، درگاه و افزونه‌های سفارشی بررسی گردد. بعد تغییر روی Staging انجام شود، Logها خوانده شوند، مسیرهای واقعی فروشگاه تست شوند و فقط با Backup و Rollback آماده، نسخه جدید روی Production فعال گردد.

در این راهنما، تفاوت نسخه پیشنهادی و حداقل، چرخه پشتیبانی PHP، روش تشخیص نسخه، Extensionها، OPcache، PHP-FPM، تنظیمات حافظه و Timeout، تست سازگاری، تغییر نسخه از cPanel و Plesk، Smoke Test، خطاهای رایج و Rollback را مرحله‌به‌مرحله بررسی می‌کنیم.

PHP چه نقشی در وردپرس دارد؟

هنگامی که کاربر صفحه‌ای را باز می‌کند، وب‌سرور درخواست را به PHP می‌دهد. PHP فایل‌های WordPress را اجرا می‌کند، افزونه و قالب را بارگذاری می‌کند، از دیتابیس داده می‌خواند و پاسخ HTML یا JSON تولید می‌کند.

در WooCommerce، PHP در این مسیرها نقش مستقیم دارد:

• نمایش محصول و قیمت
• مدیریت Session و سبد خرید
• اعتبارسنجی Checkout
• ساخت سفارش و کاهش موجودی
• ارتباط با درگاه و Callback
• ارسال ایمیل تراکنشی
• ساخت لینک دانلود
• اجرای Cron و Action Scheduler
• Import محصول و پردازش PDF

بنابراین خطای PHP می‌تواند فقط یک صفحه را خراب کند یا کل جریان درآمد سایت را متوقف سازد.

تفاوت نسخه حداقل و نسخه پیشنهادی PHP

نسخه حداقل پایین‌ترین نسخه‌ای است که نرم‌افزار ممکن است روی آن اجرا شود. نسخه پیشنهادی خط پایه مدرن‌تری برای امنیت، کارایی و پشتیبانی محسوب می‌شود.

در سال ۲۰۲۶، WordPress نسخه 8.3 یا بالاتر را پیشنهاد می‌کند. WooCommerce نیز PHP 8.3 یا بالاتر را توصیه می‌کند. بااین‌حال، «پیشنهاد هسته» به معنی سازگاری قطعی تمام افزونه‌ها و قالب‌های یک سایت خاص نیست.

برای dev-source.ir انتخاب نسخه باید براساس این اجزا تأیید شود:

• WoodMart و WoodMart Core
• افزونه درگاه پرداخت
• WooCommerce Persian
• LiteSpeed Cache
• Rank Math
• افزونه‌های Import و PDF
• Royal MCP و APIهای سفارشی
• کدهای Child Theme یا Snippetها

کدام نسخه PHP در سال ۲۰۲۶ منطقی‌تر است؟

انتخاب باید میان پشتیبانی رسمی، سازگاری اکوسیستم و نیاز عملی سایت تعادل ایجاد کند.

• PHP 8.2: در سال ۲۰۲۶ فقط پشتیبانی امنیتی محدود دارد و به پایان دوره پشتیبانی نزدیک است.
• PHP 8.3: خط پایه محافظه‌کارانه و پیشنهادی WordPress و WooCommerce است.
• PHP 8.4: نسخه جدیدتر و پشتیبانی‌شده است، اما افزونه و قالب باید روی آن تست شوند.
• PHP 8.5: WordPress 7.0 آن را پشتیبانی می‌کند، اما برای فروشگاه دارای افزونه سفارشی باید سازگاری کل Stack جداگانه تأیید شود.

برای سایت عملیاتی، انتخاب نسخه‌ای که همه اجزای حیاتی آن آزمایش شده‌اند بهتر از انتخاب صرفاً بالاترین عدد است.

چرخه پشتیبانی PHP چگونه است؟

هر شاخه PHP ابتدا پشتیبانی فعال دارد؛ در این دوره Bug و مشکلات امنیتی اصلاح می‌شوند. سپس وارد دوره Security Fixes Only می‌شود و فقط آسیب‌پذیری‌های بحرانی اصلاح می‌گردند. پس از پایان این دوره، نسخه End of Life می‌شود.

استفاده از نسخه EOL خطرهای زیر را ایجاد می‌کند:

• آسیب‌پذیری‌های جدید بدون Patch می‌مانند.
• افزونه‌های جدید پشتیبانی را حذف می‌کنند.
• کتابخانه‌ها و Composer Packageها نصب نمی‌شوند.
• هاست ممکن است نسخه را ناگهانی حذف کند.
• دریافت پشتیبانی فنی دشوارتر می‌شود.

بهتر است پیش از نزدیک‌شدن به پایان پشتیبانی، ارتقا برنامه‌ریزی شود؛ نه بعد از اجبار شرکت هاست.

چگونه نسخه فعلی PHP را پیدا کنیم؟

روش اول: Site Health

از مسیر Tools → Site Health → Info → Server، نسخه PHP و بعضی اطلاعات محیط را مشاهده کنید.

روش دوم: WooCommerce System Status

در WooCommerce → Status، بخش Server Environment نسخه PHP، Memory Limit، Time Limit، Max Input Vars، cURL و جزئیات مرتبط را نمایش می‌دهد.

روش سوم: پنل هاست

در cPanel معمولاً MultiPHP Manager یا Select PHP Version و در Plesk بخش PHP Settings نسخه دامنه را نشان می‌دهد.

روش چهارم: WP-CLI

wp --info
php -v

این دو خروجی را مقایسه کنید. ممکن است WP-CLI با PHP متفاوتی از وب‌سایت اجرا شود.

چرا نسخه PHP وب و CLI ممکن است متفاوت باشد؟

وب‌سایت می‌تواند با PHP-FPM 8.3 اجرا شود، اما دستور php در SSH به PHP 8.1 اشاره کند. در این حالت:

• WP-CLI رفتار متفاوتی از سایت دارد.
• Cron خط فرمان با نسخه اشتباه اجرا می‌شود.
• Composer وابستگی ناسازگار نصب می‌کند.
• Import دستی در SSH خطا می‌دهد، درحالی‌که Frontend سالم است.

در پنل هاست مسیر Binary صحیح را پیدا کنید؛ نمونه‌ها ممکن است شبیه این باشند:

/usr/local/bin/php
/opt/cpanel/ea-php83/root/usr/bin/php
/opt/plesk/php/8.3/bin/php

مسیرها نمونه‌اند و باید از شرکت هاست تأیید شوند.

phpinfo را چگونه امن استفاده کنیم؟

فایل phpinfo() اطلاعات زیادی درباره مسیرها، Extensionها، Environment Variable و تنظیمات سرور نشان می‌دهد و نباید عمومی باقی بماند.

اگر شرکت هاست روش دیگری ندارد، فایل موقت را فقط برای چند دقیقه و با دسترسی محدود ایجاد کنید:

<?php phpinfo();

پس از بررسی فوراً فایل را حذف کنید. بهتر است از Site Health، System Status یا دستور خط فرمان استفاده شود.

قبل از ارتقای PHP چه چیزهایی را مستند کنیم؟

• نسخه فعلی PHP وب و CLI
• نسخه WordPress، WooCommerce و قالب
• فهرست افزونه‌های فعال و غیرفعال
• Extensionهای PHP
• Memory Limit، Time Limit و Max Input Vars
• Handler فعلی: FPM، LSAPI یا CGI
• OPcache و Object Cache
• آخرین Fatal Errorهای PHP
• آخرین سفارش سالم
• روش Rollback در پنل هاست

این Snapshot کمک می‌کند بعد از تغییر بدانید چه چیزی واقعاً عوض شده است.

مرحله اول: Backup و Rollback

قبل از تغییر نسخه PHP:

1. از دیتابیس Backup تازه بگیرید.
2. فایل‌های WordPress و wp-content را ذخیره کنید.
3. فایل php.ini، .user.ini و تنظیمات پنل را ثبت نمایید.
4. روش بازگرداندن نسخه قبلی PHP را آزمایش کنید.
5. Backup را خارج از هاست نگه دارید.

تغییر PHP معمولاً دیتابیس را مستقیماً عوض نمی‌کند، اما افزونه پس از اجرا روی نسخه جدید ممکن است Migration انجام دهد. بنابراین Backup دیتابیس ضروری است.

راهنمای کامل: آموزش بکاپ و بازیابی وردپرس.

مرحله دوم: Staging مشابه Production بسازید

Staging باید از نظر PHP Handler، Extensionها، نسخه دیتابیس، وب‌سرور، Cache و افزونه‌ها به Production نزدیک باشد. آزمایش PHP 8.4 روی لپ‌تاپ با Apache، درحالی‌که Production با LiteSpeed و PHP-FPM اجرا می‌شود، نتیجه کاملاً قابل اتکا نمی‌دهد.

در Staging:

• ایمیل به Sandbox هدایت شود.
• درگاه Test Mode یا غیرفعال باشد.
• Webhookهای واقعی متوقف شوند.
• داده مشتری محدود یا ناشناس شود.
• Basic Authentication و Noindex فعال باشند.

راهنما: آموزش ساخت Staging وردپرس.

مرحله سوم: سازگاری WordPress و WooCommerce را بررسی کنید

نسخه فعلی WordPress و WooCommerce را با مستندات رسمی مقایسه کنید. فقط حداقل نسخه را نبینید؛ بخش Tested Up To و گزارش‌های سازگاری نسخه موردنظر PHP نیز مهم‌اند.

WordPress 7.0 پشتیبانی کامل PHP 8.5 را اعلام کرده است. WooCommerce PHP 8.3 یا بالاتر را پیشنهاد می‌کند، اما افزونه‌های جانبی درگاه، حمل‌ونقل، مالیات و Checkout چرخه پشتیبانی مستقل دارند.

مرحله چهارم: قالب و افزونه‌ها را ممیزی کنید

برای هر افزونه و قالب این موارد را بررسی کنید:

• آخرین نسخه منتشرشده
• تاریخ آخرین Update
• PHP Requirement
• گزارش سازگاری با نسخه مقصد
• Issueهای Fatal Error یا Deprecated
• وجود نسخه اصلاح‌شده
• امکان Rollback

افزونه‌ای که سال‌ها به‌روزرسانی نشده است را فقط با یک Compatibility Checker امن فرض نکنید.

افزونه PHP Compatibility Checker کافی است؟

اسکن Static می‌تواند بعضی Syntaxها و تابع‌های حذف‌شده را پیدا کند، اما محدودیت دارد:

• همه مسیرهای Runtime را اجرا نمی‌کند.
• کد رمزگذاری‌شده یا Vendor را ناقص می‌بیند.
• خطای منطق، Type یا API خارجی را تشخیص نمی‌دهد.
• ممکن است False Positive ایجاد کند.
• Checkout و Callback واقعی را آزمایش نمی‌کند.

اسکن فقط یکی از ورودی‌های تصمیم است؛ تست عملی روی Staging ضروری است.

مرحله پنجم: افزونه‌های سفارشی را با ابزار توسعه بررسی کنید

برای کد سفارشی می‌توان از PHP_CodeSniffer و استاندارد PHPCompatibility استفاده کرد. نمونه کلی:

phpcs --standard=PHPCompatibility --runtime-set testVersion 8.3- your-plugin/

نسخه و Standard نصب‌شده باید با پروژه هماهنگ باشد. خروجی اسکن را توسعه‌دهنده بررسی کند؛ رفع خودکار همه هشدارها توصیه نمی‌شود.

در سایت فعلی، افزونه‌های Import، PDF، Product Scanner و Checkout باید جداگانه بررسی شوند، زیرا عملیات فایل، Cron و WooCommerce CRUD دارند.

تغییرات رایج PHP 8 که باعث ناسازگاری می‌شوند

• TypeError سخت‌گیرانه‌تر
• ارسال null به تابعی که String می‌خواهد
• دسترسی به Offset روی مقدار نامعتبر
• تابع‌ها یا رفتارهای Deprecated
• Dynamic Propertyهای بدون تعریف
• امضای ناسازگار متدها
• Named Argument و نام پارامتر
• تفاوت Error Reporting

بعضی Warningها در نسخه جدید به Error یا Exception تبدیل می‌شوند. به همین دلیل سایتی که روی نسخه قدیمی «ظاهراً کار می‌کند» ممکن است روی نسخه جدید متوقف شود.

مرحله ششم: Extensionهای ضروری PHP

WordPress و WooCommerce به مجموعه‌ای از Extensionها وابسته‌اند. فهرست دقیق به قابلیت‌ها و افزونه‌ها بستگی دارد، اما موارد رایج عبارت‌اند از:

• curl
• dom
• exif
• fileinfo
• filter
• gd یا imagick
• hash
• intl
• json
• mbstring
• mysqli
• openssl
• pcre
• sodium
• xml
• zip

هنگام تغییر نسخه، ممکن است Extensionهای نسخه قبلی خودکار برای نسخه جدید فعال نشوند. مثال: imagick روی PHP 8.2 نصب است، اما روی PHP 8.4 وجود ندارد.

Extensionهای مهم برای سایت فعلی

• mbstring و intl: متن فارسی و فرمت‌های بین‌المللی
• curl و openssl: درگاه، API، SMTP و سرویس خارجی
• zip: نصب افزونه و آرشیو
• fileinfo: تشخیص نوع فایل
• gd یا imagick: تصویر و تبدیل PDF به Thumbnail
• mysqli: اتصال دیتابیس
• sodium: عملیات رمزنگاری مدرن

برای افزونه PDF ممکن است ابزار سیستمی مانند Ghostscript نیز لازم باشد که Extension PHP محسوب نمی‌شود.

چگونه Extensionها را مقایسه کنیم؟

در خط فرمان:

php -m
php --ini

برای نسخه مقصد، Binary دقیق همان نسخه را اجرا کنید. در پنل هاست نیز بخش Extensions یا PHP Selector را بررسی نمایید.

فهرست قبل و بعد را ذخیره و Diff کنید. فقط فعال‌بودن نام Extension کافی نیست؛ نسخه Library مانند cURL، OpenSSL یا ImageMagick نیز می‌تواند تفاوت ایجاد کند.

مرحله هفتم: تنظیمات PHP را مقایسه کنید

تغییر نسخه ممکن است فایل تنظیمات جداگانه‌ای فعال کند. این گزینه‌ها را مقایسه کنید:

• memory_limit
• max_execution_time
• max_input_time
• max_input_vars
• post_max_size
• upload_max_filesize
• max_file_uploads
• default_socket_timeout
• session.save_path
• date.timezone

اگر سایت پس از تغییر نسخه نمی‌تواند فایل بزرگ Upload کند یا محصول متغیر را کامل ذخیره کند، ممکن است تنظیمات نسخه جدید پایین‌تر باشند.

PHP Memory Limit با WP_MEMORY_LIMIT چه تفاوتی دارد؟

memory_limit سقف PHP است. WP_MEMORY_LIMIT درخواست WordPress برای حافظه Frontend و WP_MAX_MEMORY_LIMIT برای بعضی عملیات مدیریتی است. WordPress نمی‌تواند همیشه از سقف سخت PHP یا محدودیت هاست عبور کند.

define( 'WP_MEMORY_LIMIT', '256M' );
define( 'WP_MAX_MEMORY_LIMIT', '512M' );

این عددها مثال‌اند. افزایش حافظه بدون پیدا‌کردن Query، Loop یا فایل بزرگ راهکار نهایی نیست.

max_input_vars چه اثری دارد؟

این مقدار تعداد متغیرهای ورودی یک Request را محدود می‌کند. مقدار پایین می‌تواند باعث ذخیره ناقص شود:

• منوی بزرگ
• تنظیمات قالب
• محصول متغیر با Variation زیاد
• فرم‌های پیچیده
• فیلدهای Checkout

اگر بعد از تغییر PHP بخشی از تنظیمات بدون خطای واضح ذخیره نمی‌شود، این مقدار را با نسخه قبلی مقایسه کنید.

مرحله هشتم: OPcache را بررسی کنید

OPcache Bytecode کامپایل‌شده PHP را در حافظه نگه می‌دارد و کارایی را بهتر می‌کند. پس از تغییر نسخه یا Deploy ممکن است Cache قدیمی، تنظیم کم‌حجم یا Restart ناقص مشکل ایجاد کند.

موارد مهم:

• فعال‌بودن OPcache
• Memory و تعداد Scriptها
• Revalidation
• Restart پس از تغییر نسخه
• همخوانی با PHP-FPM Pool

پاک‌کردن Page Cache با Resetکردن OPcache یکسان نیست. این عملیات را از پنل هاست یا با کمک مدیر سرور انجام دهید.

PHP-FPM، LSAPI و CGI چیستند؟

این‌ها Handlerهای اجرای PHP هستند. تغییر نسخه گاهی Handler را نیز عوض می‌کند و روی Performance، Worker، Permission و Timeout اثر می‌گذارد.

• PHP-FPM: Poolهای Process مستقل و رایج در Nginx و Apache
• LSAPI: Handler بهینه برای LiteSpeed
• CGI/FastCGI: مدل‌های دیگر اجرا

برای dev-source.ir که LiteSpeed Cache دارد، لازم است مشخص شود Origin واقعاً LiteSpeed و LSAPI است یا افزونه فقط برای قابلیت‌های Cache نصب شده است.

مرحله نهم: نسخه مقصد را روی Staging فعال کنید

فقط PHP را تغییر دهید و در همان مرحله WordPress، WooCommerce یا قالب را ارتقا ندهید. یک متغیر در هر تغییر باعث می‌شود علت خطا قابل تشخیص باشد.

پس از تغییر:

1. صفحه اصلی را باز کنید.
2. Site Health و System Status را ذخیره کنید.
3. Error Log را بررسی نمایید.
4. نسخه وب و CLI را تأیید کنید.
5. Extensionها و Limits را مقایسه کنید.
6. Cache و OPcache را Refresh کنید.

تست عمومی وردپرس روی PHP جدید

• ورود و خروج مدیر
• 2FA یا Recovery
• ایجاد و ویرایش نوشته
• آپلود تصویر و PDF
• ساخت Thumbnail
• جست‌وجو و دسته‌بندی
• REST API
• WP-Cron
• فرم تماس
• ایمیل بازیابی رمز

تست کامل WooCommerce روی PHP جدید

محصول

• محصول ساده و دانلودی
• محصول متغیر
• Attribute و Variation
• قیمت، تخفیف و موجودی
• فایل دانلودی و Permission

سبد و Checkout

• افزودن و حذف محصول
• کوپن
• خرید مهمان
• خرید حساب‌دار
• Checkout موبایل
• فیلدهای سفارشی

پرداخت و سفارش

• درگاه Sandbox
• Callback
• Transaction ID
• تغییر وضعیت سفارش
• کاهش موجودی
• ایمیل Processing و Completed
• Refund آزمایشی

پس‌زمینه

• HPOS
• Action Scheduler
• WooCommerce Analytics
• Cron
• Webhook
• Logهای درگاه

تست افزونه‌های سفارشی سایت

برای dev-source.ir این سناریوها باید جدا اجرا شوند:

• Import یک محصول نمونه
• پردازش PDF و ساخت WebP
• اسکن محتوای محصول
• ثبت مشخصات هوشمند
• Checkout مجازی
• Feed یا اتصال Torob
• Royal MCP و دسترسی API

هر تست باید Input، Output، زمان اجرا، Memory و Log داشته باشد.

مرحله دهم: Deprecatedها را مدیریت کنید

در نسخه جدید ممکن است سایت کار کند اما Log پر از Deprecated شود. این پیام‌ها را نادیده نگیرید، زیرا نشان می‌دهند کد در نسخه‌های بعدی ممکن است بشکند.

روند صحیح:

1. Source و Stack Trace را پیدا کنید.
2. نسخه جدید افزونه را بررسی نمایید.
3. Issue را به توسعه‌دهنده گزارش کنید.
4. کد سفارشی را اصلاح نمایید.
5. Log را بعد از Fix دوباره بررسی کنید.

نمایش Deprecated در Frontend باید خاموش باشد؛ ثبت کنترل‌شده در Staging کافی است.

مرحله یازدهم: Performance را قبل و بعد مقایسه کنید

ادعای «نسخه جدید سریع‌تر است» باید روی سایت واقعی اندازه‌گیری شود. Baseline بگیرید:

• TTFB صفحه بدون Cache
• زمان Checkout
• زمان Query و PHP
• Memory Peak
• زمان Import
• تعداد Worker اشغال‌شده
• CPU و Load

Page Cache می‌تواند تفاوت PHP را پنهان کند. صفحات پویا مانند Checkout و wp-admin برای مقایسه مهم‌ترند.

چرا بعد از ارتقا سرعت بهتر نمی‌شود؟

• گلوگاه دیتابیس یا API خارجی است.
• Page Cache بیشتر Requestها را پاسخ می‌دهد.
• OPcache غیرفعال است.
• Worker کم است.
• افزونه ناسازگار Warning پرتکرار تولید می‌کند.
• نسخه جدید تنظیمات Memory یا JIT متفاوت دارد.

ارتقای PHP یک جزء از Performance است، نه درمان همه مشکلات.

JIT برای وردپرس لازم است؟

JIT در بعضی پردازش‌های محاسباتی مفید است، اما WordPress و WooCommerce بیشتر به I/O، دیتابیس و شبکه وابسته‌اند. فعال‌سازی JIT معمولاً اولویت اصلی سایت فروشگاهی نیست و می‌تواند Memory اضافی مصرف کند.

ابتدا OPcache استاندارد، Query، Object Cache و Workerها را بهینه کنید.

مرحله دوازدهم: تغییر PHP در cPanel

نام گزینه‌ها براساس شرکت هاست متفاوت است.

MultiPHP Manager

1. دامنه را انتخاب کنید.
2. نسخه مقصد را تعیین نمایید.
3. Apply را بزنید.
4. نسخه را در Site Health تأیید کنید.
5. Error Log را بررسی نمایید.

Select PHP Version

در هاست‌های CloudLinux می‌توانید نسخه و Extensionها را انتخاب کنید. بعد از تغییر نسخه، Extensionهای قبلی را دوباره کنترل کنید.

اگر دامنه اصلی، Subdomain و Cron تنظیم جدا دارند، همه را بررسی نمایید.

تغییر PHP در Plesk

1. Websites & Domains را باز کنید.
2. PHP Settings را انتخاب نمایید.
3. نسخه و Handler را تعیین کنید.
4. Limits و Extensionها را مقایسه نمایید.
5. Apply کنید و Log را بررسی نمایید.

تغییر Handler هم‌زمان با نسخه می‌تواند نتیجه تست را مخدوش کند؛ در صورت امکان ابتدا فقط نسخه را تغییر دهید.

تغییر PHP در سرور مدیریت‌شده

در سرور اختصاصی، نصب نسخه جدید شامل Packageها، FPM Pool، وب‌سرور، Extensionها، OPcache، CLI و Cron است. این کار باید توسط مدیر سرور انجام شود.

نمونه مراحل مفهومی:

• نصب PHP و Moduleها
• ساخت Pool
• اتصال Virtual Host
• تست Configuration
• Reload کنترل‌شده
• مانیتور Log و Worker

دستور Package Manager وابسته به سیستم‌عامل است و نباید از یک راهنمای عمومی کورکورانه کپی شود.

مرحله سیزدهم: آماده‌سازی Production

• Maintenance Window تعیین کنید.
• Backup تازه بگیرید.
• Change Log و Rollback آماده باشد.
• نسخه قبلی PHP در پنل قابل انتخاب بماند.
• مانیتور و تیم مطلع باشند.
• در صورت ریسک، Checkout کوتاه‌مدت کنترل شود.

تغییر در ساعت کم‌ترافیک انجام شود، اما تیم فنی باید پس از آن در دسترس باشد.

مرحله چهاردهم: تغییر روی Production

1. نسخه PHP را تغییر دهید.
2. Extensionها را تأیید کنید.
3. OPcache و Cache را Refresh نمایید.
4. Site Health و System Status را ذخیره کنید.
5. PHP و WooCommerce Log را بخوانید.
6. Smoke Test را اجرا کنید.
7. Checkout را باز یا تأیید کنید.

در یک تغییر، نسخه PHP، WordPress، WooCommerce و قالب را هم‌زمان ارتقا ندهید.

Smoke Test پس از تغییر PHP

• صفحه اصلی و محصول باز می‌شوند.
• ورود مدیریت کار می‌کند.
• رسانه Upload و Thumbnail ساخته می‌شود.
• سبد و Checkout بدون خطا هستند.
• درگاه نمایش داده می‌شود.
• یک سفارش کنترل‌شده ثبت می‌شود.
• ایمیل و Download کار می‌کنند.
• Cron و Action Scheduler اجرا می‌شوند.
• Fatal Error جدید وجود ندارد.

مانیتورینگ ۲۴ تا ۷۲ ساعت پس از ارتقا

• خطای 500 و Critical Error
• Memory Exhausted
• Deprecated پرتکرار
• Failed Payment
• Actionهای Failed
• SMTP و API Error
• CPU، RAM و Worker
• TTFB و Checkout Time
• خطای فایل PDF یا Image Processing

راهنمای مانیتورینگ: آموزش بررسی لاگ‌های وردپرس.

Rollback چه زمانی لازم است؟

اگر یکی از این موارد رخ دهد و Fix سریع و مطمئن در دسترس نباشد:

• سایت یا wp-admin از دسترس خارج شده است.
• Checkout یا درگاه کار نمی‌کند.
• Import یا فایل دانلودی خراب شده است.
• Fatal Error پرتکرار و گسترده وجود دارد.
• مصرف منابع غیرعادی شده است.
• Extension حیاتی در نسخه جدید موجود نیست.

Rollback به معنی شکست پروژه نیست؛ بخشی از استقرار حرفه‌ای است.

روش Rollback PHP

1. در پنل هاست نسخه قبلی را فعال کنید.
2. Extensionهای قبلی را تأیید نمایید.
3. OPcache را Refresh کنید.
4. Cache را Purge نمایید.
5. Site Health و Log را بررسی کنید.
6. Checkout و سفارش را تست نمایید.

اگر افزونه در زمان اجرای PHP جدید دیتابیس را Migration کرده باشد، فقط بازگرداندن PHP ممکن است کافی نباشد. Change Log و Backup را بررسی کنید.

خطا: There has been a critical error

Recovery Email و PHP Error Log را بررسی کنید. نام افزونه یا قالب، TypeError، فایل و شماره خط معمولاً مشخص می‌شوند.

راهنما: رفع Critical Error وردپرس.

خطا: Call to undefined function

معمولاً Extension یا Dependency بارگذاری نشده، فایل ناقص است یا افزونه به تابع حذف‌شده وابسته است.

• نام تابع را جست‌وجو کنید.
• Extension نسخه مقصد را بررسی نمایید.
• نسخه افزونه را تطبیق دهید.
• در صورت نیاز Rollback کنید.

خطا: Class not found

Autoloader، Composer Vendor، ترتیب Load یا فایل ناقص را بررسی کنید. ممکن است Deployment پوشه Vendor را منتقل نکرده باشد.

خطا: Allowed memory size exhausted

Memory Limit نسخه جدید را با قبل مقایسه کنید. اگر مقدار برابر است، کد یا داده‌ای که Memory بیشتری مصرف می‌کند پیدا نمایید. فقط افزایش Limit بدون تحلیل توصیه نمی‌شود.

خطا: محصول متغیر ناقص ذخیره می‌شود

max_input_vars، post_max_size و خطاهای AJAX را بررسی کنید. تغییر نسخه ممکن است فایل php.ini متفاوتی فعال کرده باشد.

خطا: تصویر یا PDF پردازش نمی‌شود

• GD یا Imagick نصب نیست.
• Ghostscript یا Binary خارجی در دسترس نیست.
• Memory و Timeout پایین است.
• Permission پوشه موقت مشکل دارد.
• Policy امنیتی ImageMagick محدودتر شده است.

خطا: درگاه به API متصل نمی‌شود

cURL، OpenSSL، CA Bundle، DNS، Firewall و TLS نسخه جدید را بررسی کنید. Log Request باید Secretها را Mask کند.

خطا: Cron وب کار می‌کند اما WP-CLI خطا می‌دهد

نسخه PHP CLI متفاوت است. مسیر Binary در Cron و SSH را اصلاح کنید و Extensionهای CLI را مقایسه نمایید.

خطا: Deprecatedها Log را پر کرده‌اند

افزونه یا قالب ناسازگار را به‌روزرسانی یا اصلاح کنید. Error Reporting را برای پنهان‌کردن علت دستکاری نکنید. Log Rotation نیز فعال باشد.

خطا: صفحه اصلی سالم است ولی Checkout 500 می‌دهد

Checkout مسیرهای PHP بیشتری اجرا می‌کند. درگاه، فیلد سفارشی، Session، Hookهای Order و WooCommerce Log را بررسی کنید. سفارش نیمه‌تمام و Transaction را قبل از تکرار پرداخت کنترل نمایید.

خطا: بعد از تغییر نسخه سایت هنوز PHP قبلی را نشان می‌دهد

• دامنه دیگری را در پنل تغییر داده‌اید.
• Subdomain یا Alias تنظیم جدا دارد.
• Proxy به Origin دیگری می‌رود.
• PHP-FPM Reload نشده است.
• صفحه Cache‌شده نمایش داده می‌شود.
• CLI و Web متفاوت‌اند.

آیا هم‌زمان با PHP باید WordPress را هم به‌روز کنیم؟

بهتر است ابتدا WordPress، قالب و افزونه‌ها را در نسخه فعلی PHP به نسخه سازگار برسانید، سپس PHP را جدا تغییر دهید. اگر سایت بسیار قدیمی است، پروژه باید چندمرحله‌ای باشد.

ترتیب پیشنهادی:

1. Backup و Staging
2. رفع افزونه‌های رهاشده
3. Update هسته و WooCommerce در نسخه PHP فعلی
4. تست
5. ارتقای PHP
6. تست مجدد

آیا Auto Update PHP وجود دارد؟

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

از شرکت هاست بپرسید:

• چه زمانی نسخه قدیمی حذف می‌شود؟
• Rollback تا چه مدت ممکن است؟
• Extensionها خودکار منتقل می‌شوند؟
• CLI و Cron نیز تغییر می‌کنند؟
• آیا Snapshot قبل از تغییر ساخته می‌شود؟

برنامه پیشنهادی برای dev-source.ir

1. نسخه PHP وب، CLI و Cron مستند شود.
2. WooCommerce System Status کامل ذخیره گردد.
3. فهرست Extensionها و Limits ثبت شود.
4. یک Staging با LiteSpeed و Stack مشابه ساخته شود.
5. WoodMart، درگاه و افزونه‌های سفارشی برای PHP 8.3 بررسی شوند.
6. Import، PDF، Checkout و Callback جدا تست شوند.
7. PHP 8.4 و سپس 8.5 فقط در محیط آزمایشی ارزیابی شوند.
8. نسخه‌ای انتخاب شود که همه مسیرهای حیاتی روی آن بدون Fatal Error کار کنند.
9. Production با Backup و Rollback فوری تغییر کند.
10. تا ۷۲ ساعت Log و Failed Payment مانیتور شوند.

اگر نسخه فعلی پایین‌تر از 8.3 است، PHP 8.3 معمولاً نقطه شروع محافظه‌کارانه‌تری است؛ اما تصمیم نهایی باید پس از آزمون واقعی گرفته شود.

چک‌لیست نهایی ارتقای PHP

• نسخه PHP وب و CLI مشخص است.
• چرخه پشتیبانی نسخه فعلی بررسی شده است.
• Backup و Restore معتبر وجود دارد.
• Rollback نسخه PHP ممکن است.
• Staging مشابه Production آماده است.
• WordPress، WooCommerce و WoodMart سازگارند.
• درگاه و افزونه‌های سفارشی تست شده‌اند.
• Extensionهای قبل و بعد مقایسه شده‌اند.
• Memory، Time Limit و Max Input Vars ثبت شده‌اند.
• OPcache و Handler بررسی شده‌اند.
• Checkout، Callback، ایمیل و Download تست شده‌اند.
• Cron و Action Scheduler سالم‌اند.
• PHP و WooCommerce Log بدون Fatal Error است.
• Performance قبل و بعد اندازه‌گیری شده است.
• Production در Maintenance Window تغییر کرده است.
• مانیتورینگ ۷۲ ساعته انجام می‌شود.

📌 همچنین بخوانید: نگهداری دوره‌ای وردپرس، انتقال وردپرس به هاست جدید و بهینه‌سازی دیتابیس وردپرس

پرسش‌های متداول

بهترین نسخه PHP برای وردپرس چیست؟

نسخه 8.3 یا بالاتر خط پایه پیشنهادی فعلی است، اما بهترین نسخه برای یک سایت نسخه‌ای است که WordPress، WooCommerce، قالب، درگاه و افزونه‌های سفارشی روی آن کامل تست شده باشند.

آیا PHP 8.5 برای WordPress 7.0 مناسب است؟

WordPress 7.0 پشتیبانی کامل آن را اعلام کرده است، اما اکوسیستم افزونه و قالب سایت باید جداگانه آزمایش شود.

آیا تغییر PHP اطلاعات سایت را حذف می‌کند؟

خود تغییر نسخه معمولاً داده را حذف نمی‌کند، اما اجرای افزونه ناسازگار یا Migration بعد از تغییر می‌تواند روی دیتابیس اثر بگذارد. Backup ضروری است.

آیا نسخه جدید PHP همیشه سایت را سریع‌تر می‌کند؟

اغلب بهینه‌تر است، اما سرعت نهایی به Query، Cache، هاست، Worker و افزونه‌ها وابسته است. نتیجه باید اندازه‌گیری شود.

چرا سایت روی PHP جدید فقط در مدیریت خطا می‌دهد؟

صفحات مدیریتی Hookها، Query و Memory متفاوتی دارند. افزونه Admin، Import یا Product Editor را بررسی کنید.

آیا می‌توان مستقیم از PHP 7.4 به 8.4 رفت؟

ممکن است، اما برای سایت قدیمی بهتر است افزونه‌ها و هسته ابتدا به‌روز شوند و سازگاری روی Staging بررسی گردد. جهش بدون تست پرریسک است.

پس از Rollback چه کنیم؟

Fatal Error را مستند، افزونه یا قالب ناسازگار را اصلاح و دوباره روی Staging تست کنید. ماندن دائمی روی نسخه EOL راهکار نهایی نیست.

جمع‌بندی

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

فرایند ایمن شامل Snapshot، Backup، Staging، تست افزونه و قالب، مقایسه Extensionها، فعال‌سازی نسخه مقصد، Smoke Test و Rollback آماده است. برای فروشگاه، Checkout، درگاه، Callback، HPOS، ایمیل، Download و Action Scheduler معیار اصلی موفقیت‌اند.

در dev-source.ir، وجود WoodMart و چند افزونه سفارشی باعث می‌شود PHP 8.3 یا هر نسخه جدیدتر فقط پس از آزمایش Import، PDF، درگاه و Checkout روی محیط مشابه Production فعال شود. ارتقای برنامه‌ریزی‌شده بسیار کم‌ریسک‌تر از تغییر اجباری و ناگهانی شرکت هاست است.

منابع رسمی

• WordPress Requirements
• PHP Compatibility and WordPress Versions
• WordPress PHP Support Clarification 2026
• WooCommerce Server Recommendations
• Update PHP and WordPress
• PHP Supported Versions
• Debugging in WordPress