ارتقای PHP میتواند بخشی از نگه‌داری امن و بهینه وردپرس باشد، اما تغییر یک گزینه در پنل هاست تمام ماجرا نیست. فروشگاه به افزونه پرداخت، قالب، کد اختصاصی، کارهای زمان‌بندی‌شده و گاهی فایل‌های رمزگذاری‌شده وابسته است. اگر یکی از این اجزا با نسخه مقصد سازگار نباشد، ممکن است صفحه اصلی باز شود ولی پرداخت، ثبت سفارش یا ارسال پیام از کار بیفتد.
مسیر درست این است: نسخه و وابستگی‌ها را ثبت کنید، بکاپ قابل بازیابی داشته باشید، تغییر را روی نسخه آزمایشی امتحان کنید و فقط پس از عبور مسیرهای واقعی خرید، فروشگاه زنده را ارتقا دهید. این راهنما برای مدیر فروشگاه و توسعه‌دهنده نوشته شده است؛ هیچ درصد تضمینی برای افزایش سرعت وعده نمی‌دهد و بازگردانی دیتابیس را هم یک دکمه بی‌خطر فرض نمی‌کند.
هشدار جدید ووکامرس درباره PHP چه معنایی دارد؟
طبق اعلام رسمی ووکامرس، نیاز به PHP 8.1 برای WooCommerce 11.6 با برنامه انتشار در فوریه ۲۰۲۷ مطرح شده است. نسخه 11.3 برای محیط‌های قدیمی هشدار آمادگی نشان میدهد؛ این هشدار به معنی ازکارافتادن فوری فروشگاه نیست. زمان باقی‌مانده را برای بررسی سازگاری استفاده کنید، نه اینکه تغییر را به روز انتشار نسخه الزام‌آور موکول کنید.
حداقل نسخه موردنیاز با نسخه مناسب برای شروع تازه یکی نیست. یک نسخه ممکن است حداقل نرم‌افزار را برآورده کند ولی دوره پشتیبانی امنیتی آن پایان یافته باشد. پیش از انتخاب، جدول رسمی پشتیبانی PHP را با مستندات وردپرس، ووکامرس و افزونه‌های نصب‌شده تطبیق دهید. تاریخ‌های این مقاله بر مبنای بررسی ۲۰ اکتبر ۲۰۲۶ هستند و برنامه انتشار میتواند تغییر کند.
اگر فروشگاه هنوز روی نسخه قدیمی است، اولین اقدام حذف هشدار نیست. فهرست وابستگی ناسازگار را پیدا کنید و برای به‌روزرسانی یا جایگزینی آن برنامه بگذارید. ماندن موقت روی نسخه قبلی ممکن است برای آمادهسازی لازم باشد، ولی راهبرد دائمی نگه‌داری نیست. دلیل تأخیر، مسئول رفع و زمان بازبینی را مشخص کنید تا مشکل در میان کارهای روزانه فراموش نشود.
پیش از تغییر، وضعیت فعلی را ثبت کنید
نسخه PHP وب، نسخه وردپرس و ووکامرس، قالب فعال، افزونهها و افزونه‌های اجباری را ثبت کنید. نسخه خط فرمان PHP ممکن است با نسخهای که درخواست وب را اجرا میکند متفاوت باشد. بنابراین فقط خروجی php -v کافی نیست؛ اطلاعات محیط وردپرس و تنظیم runtime سرویس را هم بررسی کنید. مسیر ابزارها در هاست مدیریت‌شده ممکن است با سرور شخصی فرق داشته باشد.
برای فروشگاه ایرانی، نام و نسخه افزونه درگاه، پیامک، فاکتور، حمل‌ونقل و اتصال حسابداری را جدا بنویسید. مشخص کنید کدام بخش کد سفارشی دارد و چه کسی آن را نگه‌داری میکند. اگر افزونه‌ای از ionCube یا SourceGuardian استفاده میکند، هم فایل رمزگذاری‌شده و هم Loader باید با نسخه PHP مقصد سازگار باشند. فعال‌بودن یک Loader روی نسخه فعلی، سازگاری نسخه بعد را ثابت نمی‌کند.
# Read-only inventory; run in the site's directory if WP-CLI is available.
php -v
wp core version
wp plugin list --fields=name,status,version,update --format=table
wp theme list --fields=name,status,version,update --format=table
wp cron event list --fields=hook,next_run_gmt,recurrence --format=tableاین فرمان‌ها تغییر نسخه انجام نمی‌دهند. با این حال خروجی زمان‌بندی یا نام افزونه اختصاصی را عمومی منتشر نکنید؛ برای پشتیبانی فقط اطلاعات لازم را با حذف داده حساس بفرستید. اگر دسترسی خط فرمان ندارید، از اطلاعات سلامت سایت و گزارش وضعیت ووکامرس استفاده کنید. برای شروع، دسترسی بیشتر از نیاز یا دسترسی مدیر سرور لازم نیست.
بکاپ فقط یک فایل نیست؛ مسیر بازگردانی است
پیش از تغییر، از دیتابیس و فایل‌های لازم نسخه پشتیبان بگیرید و مطمئن شوید زمان آن مشخص است. فایل‌های بارگذاری‌شده، قالب و افزونه سفارشی و تنظیمات اتصال باید در طرح بازیابی لحاظ شوند. بکاپ روی همان فضای در معرض خرابی، تنها نسخه قابل اتکا نباشد. دسترسی به آن را محدود کنید؛ نسخه پشتیبان فروشگاه میتواند اطلاعات شخصی و اعتبارنامه داشته باشد.
در محیط جدا، بازگردانی را امتحان کنید. اینکه فایل دانلود می‌شود یا اندازه غیرصفر دارد، به معنی سالم‌بودن مسیر بازیابی نیست. بعد از بازگردانی، ورود، مشاهده محصول، نمایش رسانه و چند رکورد آزمایشی را بررسی کنید. زمان لازم برای این کار را ثبت کنید تا در روز تغییر بدانید واقعاً چه مدت برای بازگشت نیاز دارید.
نقطه حساس، سفارش‌های بعد از بکاپ است. اگر فروشگاه بعد از تهیه بکاپ همچنان سفارش می‌گیرد، Restore کامل دیتابیس میتواند آن سفارشها، وضعیت پرداخت و تغییر موجودی را حذف کند. برای همین، بازگشت runtime را از بازگردانی داده جدا طراحی کنید. در صورت نیاز به Restore، ابتدا توقف کنترلشده نوشتن و تطبیق تراکنش‌های جدید با درگاه و سیستم سفارش لازم است.
نسخه آزمایشی را واقعاً از تولید جدا کنید
نسخه آزمایشی یا Staging باید به فروشگاه شباهت کافی داشته باشد، اما نباید ایمیل، پیامک یا پرداخت واقعی تولید کند. اتصال درگاه را روی محیط تست معتبر تنظیم کنید و ارسال‌های خارجی، webhook و زمان‌بندی‌های دارای اثر واقعی را کنترل کنید. کپی دیتابیس production بدون این محدودیت‌ها میتواند باعث ارسال تکراری پیام به مشتری یا اجرای دوباره کار سفارش شود.
دسترسی نسخه آزمایشی را با احراز هویت محدود کنید و آن را از ایندکس عمومی خارج نگه دارید. noindex جای کنترل دسترسی نیست؛ موتور جستجو تنها مخاطب اینترنت نیست. در صورت امکان، داده‌های شخصی را پیش از استفاده آزمایشی پاک‌سازی یا ناشناس کنید. دامنه staging نیز نباید جای دامنه اصلی در لینک‌های canonical یا ایمیل مشتری قرار بگیرد.
در سرویس‌های مدیریت‌شده پاستا، امکانات کپی آزمایشی، نسخه PHP و ماژول‌ها را در پنل همان محصول و پلن بررسی کنید. وضعیت پشتیبانی در اکو و توربو، ظرفیت در دسترس و نوع عملیات اهمیت دارد. صرف وجود عنوان «مدیریت‌شده» به معنی سازگاری خودکار هر افزونه رمزگذاری‌شده نیست. اگر نسخه یا Loader موردنیاز در فهرست نیست، قبل از تغییر با پشتیبانی تطبیق دهید.