به‌روزرسانی PHP وردپرس؛ آموزش گام‌به‌گام امن در ۱۴۰۵
این مقاله یک لایهٔ مشخص از نگهداری وردپرس است: خودِ زبان اجرای سایت، یعنی PHP. لایهٔ بالاترش — چرخهٔ منظم آپدیت هسته و افزونه‌ها — در چرخهٔ آپدیت هسته و افزونههای وردپرس گام‌به‌گام آمده و لایهٔ کنارش، تنظیم حافظه، در افزایش حافظهٔ PHP در وردپرس باز شده. این سه را قاطی نکنید: نسخهٔ PHP زیرساخت است، آپدیت هسته لایهٔ نرم‌افزار است و حافظه تنظیمات همان زیرساخت. هر کدام تقویم و ریسک خودش را دارد.
ترتیب خواندن این متن هم مسیر اجراست: اول بفهمید کجا ایستاده‌اید، بعد آماده شوید، بعد در محیط امن تست کنید، بعد روی هاست اعمال کنید و آخر پایش کنید. هیچ قدمی را جا نیندازید؛ به تجربهٔ ما قدم‌های «ساده» همان‌هایی هستند که وقتی جا می‌افتند، کل یک روز سایت را می‌گیرند.
به‌روزرسانی PHP وردپرس چرا نمیشود تعویقش کرد؟
سه دلیل که این کار را تعویق‌ناپذیر می‌کند. اول امنیت: نسخه‌هایی که پشتیبانی امنیتی‌شان پایان یافته دیگر وصله نمی‌گیرند و هر آسیب‌پذیری کشف‌شده در آن‌ها برای همیشه باز می‌ماند. دوم سازگاری رو به جلو: قالب‌ها و افزونههای مدرن برای نسخه‌های جدید PHP ساخته می‌شوند و هر چه نسخهٔ شما عقب‌تر بماند، فهرست افزونه‌هایی که نصبشان امن است کوچک‌تر میشود. سوم کارایی: نسخه‌های جدید معمولاً همان کد را با منابع کمتری اجرا میکنند و در سایت‌های پرترافیک، اثرش روی سرعت محسوس است.
اندازهٔ مسئله را هم بگوییم: وردپرس حدود ۴۳٪ کل وب‌سایت‌های جهان را قدرت می‌دهد (تاریخ گردآوری: آبان ۱۴۰۵)؛ یعنی سؤال «نسخهٔ PHP سایت من چیست؟» برای میلیون‌ها سایت هم‌زمان مطرح است و سمت هاستینگ، پشتیبانی نسخه‌های قدیمی را کم‌کم جمع می‌کند. به تجربهٔ ما تعویق معمولاً نه از دانش می‌آید و نه از هزینه؛ از ترس خراب‌شدن می‌آید. ترس منطقی است، اما جوابش ترتیب امن اجراست، نه انتظار بی‌پایان. بقیهٔ لایه‌های نگهداری را هم در هاب نگهداری، مهاجرت و خطاها یک‌جا مرتب نگه داشته‌ایم.
نسخهٔ فعلی را از کجا بفهمیم؛ سه روش سریع
روش اول، ابزار سلامت سایت داخل پیشخوان وردپرس است: در بخش ابزارها، تب اطلاعات، نسخهٔ PHP را کنار نسخهٔ وردپرس نشان می‌دهد؛ سریع‌ترین راه و بدون دسترسی به هاست. روش دوم، پنل هاست: در صفحهٔ اصلی اکثر پنل‌ها بخش انتخاب نسخهٔ PHP یا اطلاعات سرور نسخهٔ فعلی دامنه را نشان می‌دهد. روش سوم، یک فایل موقتی اطلاعات‌نگار در ریشهٔ سایت که بعد از دیدن نسخه باید حتماً حذف شود — این فایل اطلاعات سرور را در معرض نمایش می‌گذارد و رهاکردنش خودش یک ریسک است.
کنار نسخهٔ فعلی، دو عدد دیگر هم یادداشت کنید: نسخهٔ وردپرس و لیست افزونه‌ها با نسخه‌هایشان. این یادداشت، نقشهٔ قبل و بعد شماست؛ بعد از آپدیت، مقایسهٔ همین برگه مشخص می‌کند چه چیزی عوض شد و اگر مشکلی پیش آمد، شک را از کجا شروع کنید. یک برگهٔ ساده کاغذی یا فایل متنی کافی است — مهم این است که قبل از تغییر نوشته شده باشد، نه بعد از آن.
پیش از آپدیت؛ چکلیست سازگاری و بکاپ کامل
چهار قلم پیش از هر آپدیتی. قلم اول، بکاپ کامل: هم فایل‌ها هم دیتابیس؛ بکاپِ ناقص، بکاپ نیست. قلم دوم، فهرست سازگاری: صفحهٔ هر افزونه و قالب را ببینید و نسخهٔ PHP پشتیبانی‌شدهٔ آن را یادداشت کنید؛ اگر یک افزونهٔ حیاتی نسخهٔ هدف را پشتیبانی نمی‌کند، مسیر شما اول پیدا کردن جایگزین یا نسخهٔ جدیدتر آن افزونه است، نه اعمال آپدیت و امیدوارماندن. قلم سوم، بررسی لاگ خطاهای فعلی: خطاهایی که الان در لاگ هست، بعد از آپدیت با مشکلات جدید قاطی می‌شوند و تشخیص را سخت میکنند.
قلم چهارم، برنامهٔ بازگشت مکتوب: در پنل هاست کدام مسیر برای برگشت به نسخهٔ قبلی وجود دارد و چه کسی مسئول اجرای آن است؟ به تجربهٔ ما تیم‌هایی که برنامهٔ بازگشت دارند، در بحران دو دقیقه‌ای تصمیم می‌گیرند؛ تیم‌هایی که ندارند، ساعت‌ها بحث میکنند و سایت همان‌قدر پایین می‌ماند. همین چهار قلم، فاصلهٔ بین آپدیت امن و آپدیت شانسی است. اگر بکاپ‌گیریدن خودکار منظم در دسترس ندارید، اول این زیرساخت را حل کنید و بعد سراغ آپدیت بروید؛ ترتیب برعکس یعنی ساختن روی زمین لرزان.
آپدیت در محیط تست؛ چرا از سایت زنده شروع نمی‌کنیم
محیط تست نسخهای از سایت شماست که تغییرات در آن اعمال میشود بدون آنکه بازدیدکننده ببیند. چرا از این‌جا شروع می‌کنیم؟ چون خرابی‌های PHP به‌ندرت در صفحهٔ اصلی ظاهر می‌شوند؛ در فرم‌ها، در پرداخت، در صفحهٔ عضویت، در ایمیل‌های سیستمی. در محیط تست، همین نقاط پرریسک را بی‌هزینه می‌شکنید و می‌بینید کدام افزونه صدا می‌کند. اگر هاست شما امکان ساخت نسخهٔ تست را دارد، از همان استفاده کنید؛ بیشتر هاست‌های مدیریت‌شده این قابلیت را از پنل می‌دهند.
و اگر محیط تست در دسترس نیست؟ صادقانه بگوییم: ریسک بالاتر می‌رود. حداقل کار این است که آپدیت را در کم‌ترافیک‌ترین ساعت هفته اعمال کنید، بکاپ کامل آماده باشد و نیم ساعت اول را کسی پشت سایت بماند و نقاط پرریسک را دستی امتحان کند. به تجربهٔ ما همین «حداقلِ ممکن» هم بهتر از آپدیت نیمه‌شبِ بدون مراقبت است؛ چیزی که نباید انجام شود، اعمال آپدیت در ساعت شلوغ با بکاپ قدیمی است.
اجرای آپدیت روی هاست؛ مسیر پنل و پشتیبانی
روی هاست، مسیر معمول از پنل مدیریت است: در پنل‌های رایج، بخشی به نام انتخاب نسخهٔ PHP یا مدیریت PHP وجود دارد که دامنه یا زیردامنه را انتخاب می‌کنید و نسخهٔ هدف را اعمال می‌کنید. تغییر چند دقیقه‌ای اعمال میشود و سایت با نسخهٔ جدید بالا می‌آید. اگر گزینه‌ها قفل بودند یا نسخهٔ هدف در فهرست نبود، این یکی از موارد قانونی تیکت پشتیبانی است: نسخهٔ فعلی، نسخهٔ هدف و دلیل — سازگاری افزونه‌ها — را صریح بنویسید؛ پشتیبانی هاست این درخواست را هر روز می‌بیند.
قاعدهٔ نسخهای را هم رعایت کنید: یکیدو پله بالاتر از فعلی بروید، نه پرش بزرگ از نسخهٔ خیلی قدیمی به آخرین نسخه. پرش بزرگ، هم‌زمان چندین تغییر زبان را به کد شما تحمیل می‌کند و اگر خرابی بیاید، نمی‌فهمید از کدام تغییر است. فاصله‌های کوچک، مراحل تست را تکرارپذیر و بازگشت را ارزان نگه می‌دارد؛ سرعت این مسیر از تعداد مراحل می‌آید نه از بزرگی پرش.
بعد از آپدیت؛ پنج آزمون سلامت سایت
پنج آزمون سلامت، به همین ترتیب. آزمون اول، ورود و خروج پیشخوان: اگر ورود کار نمی‌کند، ماجرا جدی است و همین اول معلوم میشود. آزمون دوم، چرخهٔ انتشار: یک برگهٔ آزمایشی بسازید، پیش‌نمایش بگیرید و منتشر کنید؛ این کار ویرایشگر، قالب و سیستم ذخیره را یک‌جا امتحان می‌کند. آزمون سوم، فرم‌ها: فرم تماس و اگر فروشگاه دارید، چرخهٔ پرداخت در حالت تست؛ خرابی فرم بعد از آپدیت PHP شایع‌ترین حادثه‌ای است که هفته‌ها دیر دیده میشود. آزمون چهارم، لاگ خطا: خطاهای تازه را با برگهٔ «قبل» مقایسه کنید. آزمون پنجم، سرعت صفحات کلیدی: نسخهٔ جدید معمولاً سریع‌تر است؛ اگر کندتر شد، یک افزونه ناسازگار است.
نتیجهٔ هر پنج آزمون را کنار همان برگهٔ قبل ثبت کنید: تاریخ، نسخهٔ جدید، وضعیت هر آزمون. این ثبت بعد از چند بار آپدیت به سابقهٔ نگهداری سایت تبدیل میشود؛ برگه‌ای که موقع فروش سایت یا تحویل به تیم بعدی، پرسش‌های نصفه را جواب می‌دهد و اعتماد می‌سازد.
خطاهای رایج بعد از آپدیت و مسیر بازگشت
خطای رایج اول، صفحهٔ سفید یا خطای بحرانی: عجله نکنید؛ لاگ خطا را باز کنید و نام فایل افزونه یا قالب را پیدا کنید. خطای رایج دوم، افزونهٔ قدیمی که با نسخهٔ جدید نمی‌سازد: از پیشخوان غیرفعالش کنید؛ اگر پیشخوان باز نمیشود، تغییر نام پوشهٔ همان افزونه در مدیریت فایل، عملاً آن را غیرفعال می‌کند و سایت برمی‌گردد. خطای رایج سوم، اختلال عملکرد بدون خطای نمایشی: این همان چیزی است که آزمون فرم‌ها می‌گیرد؛ لاگ و نسخهٔ افزونه را چک کنید.
مسیر بازگشت همیشه باز است: از پنل هاست نسخهٔ قبلی PHP را دوباره اعمال کنید و سایت به حالت قبل از آپدیت برمی‌گردد — همان برنامهٔ بازگشت سکشن چهارم. اگر بعد از بازگشت هم مشکل بود، مسئله از خود آپدیت نبوده و بکاپ وارد بحث میشود. جمع‌بندی: به‌روزرسانی PHP وردپرس وقتی ترسناک است که بدون بکاپ، بدون تست و با پرش بزرگ انجام شود؛ با همین ترتیب پنج‌قدمی، یک روال نگهداری معمولی است که دو بار در سال در تقویم می‌نشیند. اگر می‌خواهید همین روال‌ها را به‌صورت خودکار و سطح‌بندی‌شده با توقف اضطراری و بازگردانی مدیریت کنید، توضیح اتوماسیون نگهداری و انتشار پلتفرم نقطهٔ شروع است؛ و برای دیدن اینکه زیرساخت فعلی سایت چه شکاف‌هایی دارد، ممیزی رایگان دامنه را اجرا کنید.
رصد ما، رشد شما.
سؤالات پرتکرار
نسخهٔ PHP مناسب وردپرس کدام است؟
آخرین نسخهٔ پایداری که همهٔ افزونههای حیاتی شما آن را پشتیبانی میکنند؛ به تجربهٔ ما یکیدو پله بالاتر از نسخهٔ فعلی هدف خوبی است و پرش بزرگ نسخهای توصیه نمیشود.
بدون بکاپ میتوان نسخهٔ PHP را آپدیت کرد؟
نمیتوانیم توصیه کنیم. بکاپ کامل فایل و دیتابیس اولین قلم چکلیست است؛ بدون آن، مسیر بازگشت در صورت خرابی افزونهای یا قالبی بسته میشود.
چطور بفهمم کدام افزونه بعد از آپدیت مشکل‌ساز شده؟
لاگ خطا را باز کنید؛ نام فایل افزونه معمولاً در خطای PHP دیده میشود. اگر پیشخوان باز نمیشود، تغییر نام پوشهٔ افزونه در مدیریت فایل آن را غیرفعال می‌کند و سایت برگشت.
آپدیت PHP چه فرقی با آپدیت وردپرس دارد؟
دو لایهٔ جدا هستند: PHP زبان اجرای سرور است و از پنل هاست اعمال میشود؛ هسته و افزونههای وردپرس از پیشخوان. تقویم و ریسک هر کدام جداست و بهتر است با هم قاطی نشوند.
چند وقت یک بار باید نسخهٔ PHP را بررسی کنیم؟
در چرخهٔ فصلی نگهداری، چند دقیقه کافی است: نسخهٔ فعلی را با نسخه‌های پشتیبانی‌شدهٔ هاست مقایسه کنید و وصله‌های امنیتی نسخهٔ هدف را از اعلان هاست دنبال کنید.
