دموی رایگان

۱۵ اشتباه رایج در به‌روزرسانی نسخهٔ PHP و راه‌حل هرکدام

آرزو مقدم خواندن ~۷ دقیقه نگهداری، مهاجرت و خطاها
۱۵ اشتباه رایج در به‌روزرسانی نسخهٔ PHP و راه‌حل هرکدام
به‌روزرسانی PHP وردپرس معمولاً در دکمهٔ آپدیت نمی‌بُرد؛ در اشتباه‌های اطرافش می‌بُرد: پشتیبان‌نگرفتن، آپدیت هم‌زمان افزونه‌ها، تست‌نکردن روی سایت آزمایشی، لاگ خطا نخواندن و نداشتن مسیر رول‌بک. در این راهنما ۱۵ اشتباه رایج را در چهار گروه می‌بینید — قبل، حین و بعد از آپدیت و خطاهای پرتکرار پس از آن — و برای هرکدام راه‌حل کوتاه و عملی؛ از بازگرداندن نسخهٔ قبلی PHP از پنل هاست تا خواندن اولین ردیف لاگ.

این مقاله با راهنمای زندهٔ همین خوشه جفت است: به‌روزرسانی PHP وردپرس؛ آموزش گام‌به‌گام امن در ۱۴۰۵ مسیر سالم را قدم‌به‌قدم باز می‌کند و مقالهٔ حاضر کاتالوگ اشتباه‌هاست — چه چیزی خراب می‌شود و راه‌حل هرکدام. طبق آمار W3Techs، وردپرس حدود ۴۳ درصد همهٔ وب‌سایت‌ها را پشتیبانی می‌کند (تاریخ گردآوری: آبان ۱۴۰۵)؛ یعنی هر تغییر نسخهٔ PHP، میلیون‌ها سایت را هم‌زمان وارد آزمون سازگاری می‌کند و سهم اشتباه‌های قابل پیش‌بینی هم همیشه در میدان است.

دو نکته پیش از شروع: اول، هیچ‌کدام از این ۱۵ اشتباه «خطای برنامه‌نویس حرفه‌ای» نیست؛ همه در تیم‌های کوچک و بزرگ دیده می‌شود و راه‌حل هرکدام هم بیشتر نظم می‌خواهد تا تخصص. دوم، ترتیب چهار گروه مهم است؛ اشتباهی که در گروه «قبل از آپدیت» رخ می‌دهد، سرش را در گروه «خطاهای رایج بعد از آپدیت» نشان می‌دهد.

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

چون سه لایه به هم گره خورده‌اند: هستهٔ وردپرس، افزونه‌ها و قالب. هر افزونه حداقل نسخهٔ PHP خودش را دارد و قالب هم توابعی به کار می‌برد که در نسخه‌های جدید تغییر رفتار می‌دهند. آپدیت PHP خودش معمولاً سالم است؛ خطا معمولاً از ناهماهنگی این سه لایه می‌آید — افزونه‌ای که سازنده‌اش آن را رها کرده، قالبی که هفت سال به‌روز نشده یا کشی که نسخهٔ قدیمی را در حافظه نگه داشته است.

نکتهٔ دوم، بی‌صدایی خطاست: بعضی خرابی‌ها با صفحهٔ سفید خودشان را نشان می‌دهند و بعضی بی‌سروصدا کار می‌کنند — فرم ثبت‌نام ارسال نمی‌شود یا پرداخت نیمه‌کاره می‌ماند — و تا هفته‌ها بعد از آپدیت هم کسی متوجه نمی‌شود. برای همین در این فهرست، دو اشتباه مستقیم به تست مسیرهای کلیدی و خواندن لاگ اختصاص دارد.

اشتباه‌های قبل از آپدیت؛ شمارهٔ ۱ تا ۵

پنج شرط پیش از دکمهٔ آپدیت
این پنج شرط، نیمی از خطاهای گروه بعد را حذف می‌کنند.

۱) پشتیبان‌نگرفتن قبل از آپدیت — رایج‌ترین و پرهزینه‌ترین اشتباه. راه‌حل: قبل از هر حرکت، بکاپ کامل فایل‌ها و پایگاه داده بگیرید و یک‌بار ریستور آزمایشی را هم تمرین کنید؛ مسیر کامل بازیابی در راهنمای ریستور بکاپ وردپرس آمده است.

۲) آپدیت هم‌زمان افزونه‌ها — وقتی PHP، هفت افزونه و قالب را در یک روز جلو می‌برید و چیزی بشکند، مقصر را حدس می‌زنید. راه‌حل: پله‌ای جلو بروید؛ اول افزونه‌ها را دانه‌دانه آپدیت و تست کنید، بعد نسخهٔ PHP را. فاصلهٔ بین هر پله، امکان تفکیک مقصر می‌دهد.

۳) تست‌نکردن روی سایت آزمایشی — آپدیت مستقیم روی سایت اصلی یعنی کاربران شما تستر شما هستند. راه‌حل: یک نسخهٔ کپی در زیردامنه یا هاست آزمایشی بسازید، آپدیت را آن‌جا اجرا کنید و مسیرهای کلیدی را همان‌جا ببندید، بعد روی سایت اصلی بیاورید.

۴) نادیده‌گرفتن حداقل نسخهٔ PHP افزونه‌ها — صفحهٔ هر افزونه در مخزن، بخش «Requires PHP» دارد؛ افزونه‌ای که نسخهٔ مقصد را پشتیبانی نمی‌کند، اولین مقصر خرابی فردا است. راه‌حل: فهرست افزونه‌ها را از همین بخش چک کنید و افزونهٔ رهاشده را قبل از آپدیت با جایگزین فعال عوض کنید.

۵) فراموشی سازگاری قالب — قالب‌های قدیمی و نسخه‌های دست‌کاری‌شدهٔ قالب والد، زیر PHP جدید توابع منسوخ صدا می‌زنند. راه‌حل: سازگاری قالب را با سایت سازنده یا گزارش تغییراتش چک کنید و اگر قالب‌فرزند دارید، تغییرات دستی را پیش از آپدیت مستند کنید.

اشتباه‌های حین آپدیت؛ شمارهٔ ۶ تا ۹

۶) آپدیت در ساعت پیک — خرابی حتی یک‌درصدی، در ساعت اوج فروش و بازدید چند برابر می‌شود. راه‌حل: پنجرهٔ کم‌ترافیک را از دادهٔ خودتان انتخاب کنید — اول صبح هفته معمولاً امن‌ترین است — و اگر فروشگاه دارید، بنر تعمیر کوتاه آماده کنید.

۷) جهش چند نسخهٔ اصلی در یک حرکت — پریدن از نسخهٔ ۷٫۴ مستقیم به ۸٫۲ یعنی سه نسل تغییر رفتار در یک لحظه و لاگی که دیگر خوانا نیست. راه‌حل: پله‌ای جلو بروید — به نسخهٔ بعدی، تست، بعد پلهٔ بعد — تا خطای هر پله جدا بماند و مقصر سریع پیدا شود.

۸) نداشتن طرح رول‌بک — آپدیت را شروع می‌کنید بدون آنکه بدانید چطور برمی‌گردید. راه‌حل: قبل از شروع، نسخهٔ فعلی PHP و وضعیت افزونه‌ها را ثبت کنید و مسیر برگشت را باز نگه دارید؛ در بیشتر پنل‌های هاست، انتخاب نسخهٔ PHP چندثانیه‌ای است و همان مسیر رول‌بک شماست.

۹) عقب‌انداختن مداوم آپدیت — هشدار «PHP Update Required» را می‌بینید و می‌گذارید برای ماه بعد؛ هر ماه تأخیر یعنی امنیت و سرعتِ از دست رفته و فاصلهٔ بیشتر با نسخهٔ مقصد. راه‌حل: یک تقویم فصلی برای بازبینی نسخهٔ PHP بگذارید و بیش از دو فصل از نسخهٔ پایدار عقب نمانید.

اشتباه‌های بعد از آپدیت؛ شمارهٔ ۱۰ تا ۱۲

۱۰) لاگ خطا نخواندن — سایت بالا می‌آید و همه فرض می‌کنند سالم است؛ در حالی که لاگ پر از هشدار است. راه‌حل: فایل error_log هاست و حالت رفع اشکال وردپرس را باز کنید؛ معمولاً اولین ردیف، نام افزونه یا فایل مقصر را می‌گوید و نیم ساعت صرفه‌جویی می‌کند.

۱۱) پاک‌نکردن کش — کش افزونه، کش سرور و کش مرورگر نسخهٔ قدیمی را نگه می‌دارند و «خرابیِ خیالی» می‌سازند. راه‌حل: بعد از هر آپدیت، هر سه لایهٔ کش را به ترتیب خالی کنید و سایت را در حالت ناشناس مرورگر بازبینی کنید تا نتیجهٔ واقعی را ببینید.

۱۲) تست‌نکردن مسیرهای کلیدی — فرم تماس، ثبت‌نام، سبد خرید و پرداخت باید با یک سفارش یا ارسال واقعی آزمایش شوند؛ خطای بی‌صدای فرم پرداخت، فروش را می‌بُرد نه رتبه را. راه‌حل: فهرست چهار پنج مسیر حیاتی سایت را از قبل آماده کنید و بعد از آپدیت، هرکدام را سرِ خودشان تست کنید.

خطاهای رایج پس از آپدیت؛ شمارهٔ ۱۳ تا ۱۵

مسیر رول‌بک در سه قدم
رول‌بک چندثانیه‌ای است؛ بحران‌ها از ندانستن همین مسیر ساخته می‌شوند.

۱۳) صفحهٔ سفید مرگ — بعد از آپدیت، صفحه سفید و بی‌متن است. راه‌حل: از فایل‌منیجر هاست یا FTP به پوشهٔ افزونه‌ها بروید و نام پوشهٔ افزونه‌ها را موقتاً تغییر دهید تا همه غیرفعال شوند؛ اگر سایت برگشت، پوشه‌ها را یکی‌یکی برگردانید تا مقصر پیدا شود.

۱۴) پیام «وب‌سایت مشکل فنی جدی دارد» — وردپرس خودش خطا را در ایمیل به مدیر می‌فرستد. راه‌حل: ایمیل وردپرس را باز کنید؛ لینک حالت بازیابی را می‌دهد و همان‌جا می‌توانید افزونه یا قالب معیوب را غیرفعال کنید، بدون دست‌زدن به فایل‌ها.

۱۵) خطای اتصال پایگاه داده یا کارکرد نیمه‌کارهٔ افزونهٔ کش — سایت بالا نمی‌آید و زمان تنگ است. راه‌حل: اول از پنل هاست نسخهٔ PHP قبلی را برگردانید (همان رول‌بک چندثانیه‌ای) و سایت را نجات دهید؛ بعد با آرامش ریشهٔ خطا را از لاگ پیدا کنید. اگر برگشت هم ممکن نشد، بازسازی کامل سایت از بکاپ در راهنمای بازگردانی سایت پس از خطا گام‌به‌گام آمده است.

چک‌لیست چهارقدمی آپدیت بی‌دردسر

چهار قدم این فهرست را به عادت تبدیل کنید. اول، فصل‌بندی: هر سه‌ماهه یک نوبت بازبینی نسخهٔ PHP و افزونه‌ها؛ نه هر هفته و نه سالی یک‌بار. دوم، پله‌ای: همیشه به نسخهٔ بعدی بروید، نه به جدیدترین نسخهٔ موجود، و بین پله‌ها تست ببندید. سوم، تست مسیرها: همان چهار پنج مسیر حیاتی، هر بار و بدون استثنا. چهارم، ثبت نتیجه: نسخهٔ PHP، تاریخ آپدیت و افزونه‌های تغییرکرده را در یک سند بنویسید؛ دفعهٔ بعد از همین سند شروع می‌کنید.

این چهار قدم را اگر با آپدیت منظم خود وردپرس و افزونه‌ها گره بزنید — که راهنمای آن در هاب امنیت و پشتیبان‌گیری آمده — نگهداری سایت از رویداد اضطراری به روال قابل پیش‌بینی تبدیل می‌شود؛ و همین روال است که خطاهای نیمه‌شب را حذف می‌کند، نه سرعت عمل شما را.

جمع‌بندی؛ سه قاعدهٔ همیشگی

سه قاعده با خود ببرید. اول، بکاپ قبل از هر حرکت؛ بدون آن هیچ آپدیتی «کم‌ریسک» نیست. دوم، پله‌ای و در ساعت کم‌ترافیک؛ فاصلهٔ بین پله‌ها همان چیزی است که مقصر را تفکیک می‌کند. سوم، لاگ و مسیر برگشت آماده؛ وقتی رول‌بک چندثانیه‌ای باشد، خرابی به بحران تبدیل نمی‌شود.

اگر می‌خواهید این روند — آپدیت منظم، پایش و رفع خطا — بدون اتکا به حافظه و ساعت‌های اضافه اجرا شود، پلتفرم سوئیت انتشار و پایش را خودکار می‌کند و اپراتور پلن پیشرو روند را پیوسته رصد می‌کند؛ دمو را از صفحهٔ محصول ببینید. مسیر کامل بازیابی هم وقتی اتفاق افتاد، در مقاله‌های همین خوشه گام‌به‌گام باز شده است.

دموی رایگان پلتفرم

پلن پیشرو — ۷٫۹ میلیون تومان/ماه (انتشار خودکار + اپراتور)

دموی رایگان پلتفرم

رصد ما، رشد شما.

سؤالات پرتکرار

هر چند وقت یک‌بار باید نسخهٔ PHP وردپرس را به‌روز کرد؟

به تجربهٔ ما بازبینی فصلی سه‌ماهه برای نسخهٔ PHP و افزونه‌ها کافی است؛ بیش از دو فصل عقب‌ماندن از نسخهٔ پایدار یعنی فاصلهٔ آپدیت و ریسک بیشتر.

اگر بعد از آپدیت PHP سایت سفید شد چه کنیم؟

با تغییر نام پوشهٔ افزونه‌ها از فایل‌منیجر هاست همه را موقتاً غیرفعال کنید؛ اگر سایت برگشت، پوشه‌ها را یکی‌یکی برگردانید تا مقصر پیدا شود. اگر زمان تنگ است، از پنل هاست نسخهٔ PHP قبلی را برگردانید.

می‌شود مستقیم به جدیدترین نسخه پرید؟

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

حداقل نسخهٔ PHP افزونه‌ها را از کجا بفهمیم؟

صفحهٔ افزونه در مخزن یا سایت سازنده، بخش «Requires PHP» را نشان می‌دهد؛ افزونه‌ای که مدت‌ها به‌روز نشده و نسخهٔ مقصد را پشتیبانی نمی‌کند، کاندیدای جایگزینی است.

آپدیت PHP چه ربطی به سئو دارد؟

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