آپدیت خودکار وردپرس شکست خورده است؛ مقصر در کدام لایه پنهان شده؟

آپدیت خودکار وردپرس شکست خورده است و این یکی از خطرناک‌ترین خطاهایی است که می‌تواند ماه‌ها بی‌سروصدا روی سایت شما باقی بماند. برخلاف خطاهایی مثل ۵۰۰ یا ۴۰۴ که فوراً کاربر را متوقف می‌کنند، شکست بروزرسانی خودکار در سکوت رخ می‌دهد: هسته‌ی وردپرس روی نسخه‌ی قدیمی می‌ماند، افزونه‌های امنیتی آپدیت نمی‌شوند و سایت شما در برابر آسیب‌پذیری‌های شناخته‌شده بی‌دفاع می‌شود. سال‌هاست روی سرورهای وردپرسی با این خطا مواجه می‌شوم و در تجربه‌ام، بیشترین آسیب از تأخیر در تشخیص می‌آید، نه از خود شکست.

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

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

وردپرس از سال‌ها پیش، سیستم بروزرسانی خودکار را به‌عنوان بخشی از هسته‌ی خود معرفی کرده است. این سیستم به‌طور پیش‌فرض فقط برای بروزرسانی‌های امنیتیِ نسخه‌های فرعی (minor) فعال است و برای بروزرسانی‌های نسخه‌ی اصلی (major) به‌طور پیش‌فرض غیرفعال می‌ماند. همچنین، بسته به تنظیمات، می‌توانید بروزرسانی خودکار افزونه‌ها و قالب‌ها را نیز فعال کنید. توضیح تکمیلی این مفهوم در ویکی‌پدیا موجود است، ولی جان ماجرا در این نکته است که این فرآیند در پشت صحنه، از مجموعه‌ای از APIها، کرون‌ها و درخواست‌های HTTP تشکیل شده است که هرکدام می‌توانند نقطه‌ی شکست باشند.

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

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

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

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

شکست‌های بروزرسانی خودکار در وردپرس، پیام‌ها و نشانه‌های متنوعی دارند که هرکدام به ریشه‌ی متفاوتی اشاره می‌کنند:

در تجربه‌ی چندساله‌ام، چهار نشانه‌ی اول شایع‌تر هستند و در هفتاد درصد موارد، با بازنشانی مالکیت و بررسی cron حل می‌شوند. بقیه‌ی موارد، نیازمند عیب‌یابی دقیق‌تر در لایه‌ی اتصال یا محدودیت PHP است.

ده ریشه‌ی اصلی شکست بروزرسانی خودکار

در عیب‌یابی شکست بروزرسانی خودکار روی سایت‌های وردپرسی، این ده ریشه بیش از بقیه تکرار می‌شوند:

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

شایع‌ترین دلیل. برای بروزرسانی، وردپرس باید فایل‌های جدید را در پوشه‌های مختلف جایگزین کند. اگر مجوز پوشه‌ها 755 نباشد یا مالکیت آن‌ها با کاربر PHP-FPM هماهنگ نباشد، بروزرسانی با خطای «عدم دسترسی به فایل» شکست می‌خورد. این سناریو معمولاً بعد از مهاجرت سرور یا آپلود دستی فایل‌ها رخ می‌دهد. مباحث مرتبط در خطای دسترسی به فایل‌ها در وردپرس باز شده است.

ریشه‌ی دوم: مسدود بودن اتصال خروجی به سرورهای وردپرس

وردپرس برای دریافت بروزرسانی‌ها، به سرورهای api.wordpress.org، downloads.wordpress.org و core.svn.wordpress.org متصل می‌شود. اگر سرور شما این اتصالات را مسدود کند (به‌دلیل فایروال، محدودیت هاست یا تحریم)، بروزرسانی هرگز انجام نمی‌شود. راه‌حل: بررسی اتصال خروجی و در صورت لزوم استفاده از پروکسی.

ریشه‌ی سوم: کرون وردپرس اجرا نمی‌شود

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

ریشه‌ی چهارم: غیرفعال بودن آپدیت خودکار در wp-config

اگر در فایل wp-config.php مقادیر AUTOMATIC_UPDATER_DISABLED یا WP_AUTO_UPDATE_CORE نادرست تنظیم شده باشند، بروزرسانی خودکار غیرفعال می‌شود. این سناریو در سایت‌هایی که مدیر سایت آگاهانه آپدیت خودکار را غیرفعال کرده ولی بعداً فراموش کرده، شایع است.

ریشه‌ی پنجم: محدودیت‌های PHP و زمان اجرا

برای بروزرسانی هسته یا افزونه‌های بزرگ، PHP به حافظه و زمان کافی نیاز دارد. اگر مقدار memory_limit یا max_execution_time پایین باشد، فرآیند بروزرسانی نیمه‌کاره متوقف می‌شود. راه‌حل: افزایش این مقادیر به ۲۵۶ مگابایت و ۳۰۰ ثانیه. مباحث مرتبط در راه‌حل خطای Memory Limit در PHP باز شده است.

ریشه‌ی ششم: مداخله‌ی افزونه‌های امنیتی

افزونه‌های امنیتی مثل Wordfence یا Solid Security، گاهی درخواست‌های بروزرسانی را به‌عنوان فعالیت مشکوک تلقی می‌کنند و مسدود می‌کنند. این سناریو در سایت‌هایی که قواعد امنیتی سختگیرانه دارند، شایع‌تر است. راه‌حل: بررسی لاگ افزونه‌ی امنیتی و سفید کردن درخواست‌های بروزرسانی. مباحث مرتبط در افزونه‌های امنیتی وردپرس باز شده است.

ریشه‌ی هفتم: مداخله‌ی mod_security

ماژول mod_security در آپاچی، گاهی درخواست‌های بروزرسانی را به‌عنوان حمله مسدود می‌کند. این سناریو در سرورهایی با قواعد امنیتی سختگیرانه شایع‌تر است. راه‌حل: بررسی لاگ mod_security و سفید کردن درخواست‌های مسیر بروزرسانی.

ریشه‌ی هشتم: محدودیت‌های سهمیه‌ی دیسک

اگر سهمیه‌ی دیسک هاست شما پر شده باشد، وردپرس نمی‌تواند فایل‌های جدید را ذخیره کند و بروزرسانی شکست می‌خورد. این سناریو معمولاً با پیام «Disk quota exceeded» همراه است. راه‌حل: پاک‌سازی فایل‌های اضافی یا ارتقای پلن هاست. مباحث مرتبط در رفع خطای پرشدن هارد سرور باز شده است.

ریشه‌ی نهم: تداخل با CDN یا پراکسی معکوس

اگر سایت شما پشت CDN مثل Cloudflare باشد، درخواست‌های بروزرسانی ممکن است به‌دلیل تنظیمات CDN مسدود شوند. همچنین اگر سایت پشت پراکسی معکوس باشد، درخواست‌های خروجی ممکن است به‌درستی عبور نکنند. راه‌حل: بررسی تنظیمات CDN و پراکسی معکوس. مباحث مرتبط در نقش CDN در سرعت سایت باز شده است.

ریشه‌ی دهم: مشکل در API وردپرس یا نسخه‌ی PHP

اگر نسخه‌ی PHP شما قدیمی باشد، ممکن است API وردپرس از طریق HTTPS نتواند کار کند. همچنین اگر گواهی SSL سرور شما منقضی یا ناقص باشد، درخواست‌های بروزرسانی رد می‌شوند. راه‌حل: بررسی نسخه‌ی PHP و گواهی SSL. مباحث مرتبط در رفع خطای SSL در سرور باز شده است.

پروتکل واکنش سریع در بحران

اگر سایت شما همین حالا با شکست بروزرسانی خودکار مواجه است و نگران امنیت هستید، این پنج حرکت را به همین ترتیب اجرا کنید:

1. تعیین دامنه‌ی خطا: سریع تست کنید که آیا مشکل فقط در هسته است یا در افزونه‌ها هم. اگر هسته آپدیت می‌شود ولی افزونه‌ها نه، ریشه در تنظیمات افزونه‌ها است.
2. فعال‌سازی لاگ وردپرس: در wp-config.php مقادیر WP_DEBUG و WP_DEBUG_LOG را فعال کنید و لاگ را بررسی کنید.
3. اجرای دستی بروزرسانی: از پیشخوان، بروزرسانی را به‌صورت دستی اجرا کنید. اگر دستی هم شکست خورد، ریشه در محدودیت‌های سرور است.
4. بازنشانی مالکیت و مجوز: با chown و chmod، مالکیت و مجوز فایل‌ها را بازنشانی کنید.
5. غیرفعال‌سازی موقت افزونه‌ی امنیتی: اگر افزونه‌ی امنیتی فعال است، موقتاً آن را غیرفعال کنید و تست بگیرید.

نکته‌ی میدانی: در بحران، هیچ‌گاه برای بروزرسانی هسته، عجله نکنید. اگر سایت شما هفته‌ها یا ماه‌ها روی نسخه‌ی قدیمی است، یک روز دیگر تفاوت چندانی نمی‌کند ولی بروزرسانیِ عجولانه بدون بکاپ، می‌تواند سایت را کامل از کار بیندازد. همیشه قبل از هر بروزرسانیِ دستی، بکاپ کامل بگیرید.

تشخیص دقیق با لاگ‌ها و کوئری‌ها

ابزارهای تشخیصی، دقیق‌ترین راه پیدا کردن ریشه‌ی شکست بروزرسانی خودکار هستند. سه ابزار کلیدی:

لاگ PHP و لاگ وردپرس

در wp-config.php مقادیر WP_DEBUG و WP_DEBUG_LOG را تنظیم کنید. لاگ در wp-content/debug.log ذخیره می‌شود. پیام‌هایی مثل Failed to connect to api.wordpress.org، Permission denied، یا Maximum execution time exceeded در این لاگ دیده می‌شود. روش دقیق خواندن لاگ در بررسی خطاهای سرور در لاگ‌ها باز شده است.

لاگ کرون

اگر سایت شما cron سرور را فعال کرده باشد، می‌توانید اجرای wp-cron.php را در لاگ ببینید. اگر در بازه‌های زمانی مشخص، این فایل اجرا نشده، ریشه در کرون است. راه‌حل: بررسی cron jobها با دستور crontab -l و بررسی تنظیمات وردپرس با DISABLE_WP_CRON.

کوئری‌های دیتابیس

چند کوئری می‌تواند در تشخیص کمک کند:

بررسی تنظیمات آپدیت خودکار:

SELECT option_name, option_value FROM wp_options
WHERE option_name IN ('auto_update_core_major', 'auto_update_core_minor', 'auto_update_plugins', 'auto_update_themes');

بررسی نسخه‌ی فعلی وردپرس:

SELECT option_value FROM wp_options WHERE option_name = 'db_version';
SELECT option_value FROM wp_options WHERE option_name = 'wp_version';

بررسی آخرین بروزرسانی موفق:

SELECT option_name, option_value FROM wp_options
WHERE option_name LIKE '%_update_%' OR option_name LIKE '%last_checked%';

قبل از اجرای این کوئری‌ها، بکاپ کامل دیتابیس بگیرید. مباحث مرتبط در پشتیبان‌گیری از سایت وردپرس باز شده است.

تست اتصال خروجی به سرورهای وردپرس

با دستور زیر، اتصال سرور خود را به سرورهای وردپرس تست کنید:

curl -I https://api.wordpress.org/
curl -I https://downloads.wordpress.org/

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

مجوز فایل، مالکیت و کاربر PHP

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

مجوزهای ضروری برای بروزرسانی

پوشه‌های ضروری برای بروزرسانی باید مجوز 755 داشته باشند و فایل‌ها باید 644 باشند. پوشه‌های مهم:

• wp-content/plugins: برای بروزرسانی افزونه‌ها
• wp-content/themes: برای بروزرسانی قالب‌ها
• wp-content/upgrade: پوشه‌ی موقت برای بروزرسانی هسته
• wp-admin و wp-includes: برای بروزرسانی هسته
• ریشه‌ی سایت: برای بروزرسانی فایل‌های ریشه

بازنشانی اصولی مجوز و مالکیت

cd /path/to/wordpress

# بازنشانی مالکیت
chown -R username:username /path/to/wordpress

# بازنشانی مجوز پوشه‌ها
find . -type d -exec chmod 755 {} \;

# بازنشانی مجوز فایل‌ها
find . -type f -exec chmod 644 {} \;

# مجوز سختگیرانه برای wp-config.php
chmod 600 wp-config.php

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

مشکل خاص: پوشه‌ی upgrade مسدود است

اگر پوشه‌ی wp-content/upgrade وجود ندارد یا مجوز آن نادرست است، وردپرس نمی‌تواند فایل‌های موقت را در آن ذخیره کند و بروزرسانی شکست می‌خورد. راه‌حل: ساخت این پوشه با مجوز 755:

mkdir -p wp-content/upgrade
chmod 755 wp-content/upgrade

محدودیت‌های PHP و زمان اجرا

بروزرسانی هسته و افزونه‌های بزرگ، نیازمند منابع قابل توجهی از PHP است. سه محدودیت کلیدی:

memory_limit

برای بروزرسانی هسته، PHP به حافظه‌ی زیادی نیاز دارد. اگر مقدار memory_limit پایین باشد، فرآیند نیمه‌کاره متوقف می‌شود. راه‌حل: افزایش این مقدار به ۲۵۶ مگابایت یا بیشتر:

memory_limit = 256M

max_execution_time

بروزرسانی هسته می‌تواند چند ثانیه طول بکشد. اگر مقدار max_execution_time پایین باشد، اسکریپت قبل از اتمام کار متوقف می‌شود. راه‌حل: افزایش این مقدار به ۳۰۰ ثانیه یا بیشتر. مباحث مرتبط در رفع خطای Maximum execution time در PHP باز شده است.

max_input_vars و post_max_size

در بعضی بروزرسانی‌های پیچیده، حجم داده‌ی ارسالی به سرور می‌تواند بالا باشد. راه‌حل: تنظیم این مقادیر روی مقدار کافی:

max_input_vars = 5000
post_max_size = 64M
upload_max_filesize = 64M

روش بررسی این مقادیر در پیشخوان: مسیر ابزارها > سلامت سایت > اطلاعات را باز کنید و بخش Server را ببینید. تمام این مقادیر در این بخش نمایش داده می‌شوند.

کرون وردپرس و زمان‌بندی آپدیت

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

مکانیزم کرون وردپرس

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

غیرفعال بودن کرون وردپرس

اگر در wp-config.php مقدار DISABLE_WP_CRON روی true تنظیم شده باشد، کرون وردپرس غیرفعال می‌شود و باید به‌جای آن از cron سرور استفاده کنید. اگر این تنظیم فعال شده ولی cron سرور پیکربندی نشده، بروزرسانی‌ها هرگز اجرا نمی‌شوند. راه‌حل: بررسی wp-config.php و پیکربندی cron سرور.

پیکربندی cron سرور

اگر از cron سرور استفاده می‌کنید، این خط باید در crontab اضافه شود:

*/15 * * * * wget -q -O - https://yourdomain.com/wp-cron.php?doing_wp_cron >/dev/null 2>&1

این خط، هر ۱۵ دقیقه یک‌بار wp-cron.php را اجرا می‌کند و اجازه می‌دهد بروزرسانی‌های خودکار فعال شوند. توجه داشته باشید که اجرای مکرر این اسکریپت می‌تواند بار سرور را افزایش دهد؛ در سایت‌های پربازدید، فواصل طولانی‌تر (مثلاً هر ۳۰ یا ۶۰ دقیقه) مناسب‌تر است.

پاک‌سازی cron jobهای معوق

گاهی cron jobهایی که به‌دلیل خطا در اجرا معوق مانده‌اند، در دیتابیس انباشته می‌شوند و اجرای بروزرسانی را مسدود می‌کنند. راه‌حل: پاک‌سازی cron jobهای معوق با افزونه‌های تخصصی یا با کوئری:

DELETE FROM wp_options WHERE option_name = 'cron';

هشدار: این کوئری، تمام cron jobها را حذف می‌کند و وردپرس در بازدید بعدی، آن‌ها را دوباره می‌سازد. قبل از اجرا، بکاپ بگیرید.

اتصال به سرورهای وردپرس و CDN

وردپرس برای دریافت بروزرسانی‌ها، به سرورهای خود متصل می‌شود. اگر این اتصال مسدود باشد، بروزرسانی شکست می‌خورد:

سرورهای ضروری وردپرس

وردپرس به چند سرور برای بروزرسانی نیاز دارد:

• api.wordpress.org: برای بررسی نسخه‌های جدید
• downloads.wordpress.org: برای دانلود فایل‌های بروزرسانی
• core.svn.wordpress.org: برای برخی بروزرسانی‌های خاص
• translations.wordpress.org: برای دانلود بسته‌های ترجمه

تست اتصال خروجی

با دستور curl، اتصال سرور خود را تست کنید:

curl -I https://api.wordpress.org/
curl -I https://downloads.wordpress.org/
curl -I https://translations.wordpress.org/

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

مسدودسازی به‌دلیل تحریم

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

تداخل با CDN و پراکسی معکوس

اگر سایت شما پشت CDN مثل Cloudflare باشد، درخواست‌های بروزرسانی ممکن است به‌دلیل تنظیمات CDN مسدود شوند. راه‌حل: بررسی تنظیمات CDN و اطمینان از اینکه درخواست‌های مسیر پیشخوان از CDN مستثنی هستند. مباحث مرتبط در نقش CDN در سرعت سایت باز شده است.

تداخل افزونه‌های امنیتی و کش

افزونه‌های امنیتی و کش، لایه‌ی بعدی ریشه‌های شکست بروزرسانی خودکار هستند:

افزونه‌های امنیتی

افزونه‌هایی مثل Wordfence، Solid Security یا Sucuri، گاهی درخواست‌های بروزرسانی را به‌عنوان فعالیت مشکوک تلقی می‌کنند و مسدود می‌کنند. نشانه‌ی این سناریو: درخواست بروزرسانی به‌نظر می‌رسد اجرا شده ولی با خطای مبهم شکست می‌خورد. راه‌حل: بررسی لاگ افزونه‌ی امنیتی و سفید کردن درخواست‌های مسیر بروزرسانی. مباحث مرتبط در افزونه‌های امنیتی وردپرس باز شده است.

افزونه‌های کش

افزونه‌های کش مثل WP Rocket یا LiteSpeed Cache، اگر تنظیمات استثنا به‌درستی انجام نشود، می‌توانند اجرای wp-cron.php را مسدود کنند. راه‌حل: مستثنی کردن مسیر wp-cron.php از کش. مباحث مرتبط در بهترین افزونه‌های کش وردپرس باز شده است.

افزونه‌های مدیریت بروزرسانی

گاهی افزونه‌های مدیریت بروزرسانی مثل Easy Updates Manager، خودشان تنظیمات بروزرسانی را به‌درستی اعمال نمی‌کنند و باعث تضاد می‌شوند. راه‌حل: بررسی تنظیمات این افزونه‌ها یا حذف آن‌ها.

روش تشخیص افزونه‌ی مقصر

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

بروزرسانی دستی و بازیابی نسخه

اگر شکست بروزرسانی خودکار به‌دلیل محدودیت‌های سرور است، می‌توانید بروزرسانی را به‌صورت دستی انجام دهید:

بروزرسانی دستی هسته

برای بروزرسانی دستی هسته:

1. از سایت و دیتابیس، بکاپ کامل بگیرید.
2. آخرین نسخه‌ی وردپرس را از wordpress.org/download دانلود کنید.
3. فایل zip را در ریشه‌ی هاست آپلود و استخراج کنید.
4. پوشه‌ی wp-content قدیمی را نگه دارید و بقیه پوشه‌ها را جایگزین کنید.
5. پوشه‌ی wp-content جدید را حذف کنید (چون داده‌های شما در پوشه‌ی قدیمی است).
6. سایت را تست کنید.

بروزرسانی دستی افزونه

برای بروزرسانی دستی افزونه:

1. از افزونه بکاپ بگیرید.
2. آخرین نسخه را از مخزن رسمی دانلود کنید.
3. از پیشخوان، افزونه‌ی فعلی را حذف کنید (داده‌های آن در دیتابیس باقی می‌ماند).
4. نسخه‌ی جدید را آپلود و فعال کنید.

استفاده از WP-CLI

اگر به SSH دسترسی دارید، WP-CLI سریع‌ترین راه برای بروزرسانی دستی است:

wp core update
wp plugin update --all
wp theme update --all
wp core update-db

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

بازیابی نسخه در صورت خرابی

اگر بروزرسانی باعث خرابی سایت شد، بازیابی از بکاپ اولین راه‌حل است. اگر بکاپ ندارید، می‌توانید:

1. نسخه‌ی قبلی وردپرس را از wordpress.org/download/releases دانلود کنید.
2. فایل‌ها را به‌جای نسخه‌ی فعلی جایگزین کنید.
3. کوئری wp core update-db را با WP-CLI اجرا کنید تا دیتابیس با نسخه‌ی قبلی هماهنگ شود.

مباحث مرتبط در پشتیبان‌گیری از سایت وردپرس باز شده است.

بازگردانی و اولویت‌بندی

بعد از پیدا کردن ریشه، نوبت به بازگردانی بروزرسانی خودکار می‌رسد. ترتیب اولویت‌بندی من در پروژه‌های واقعی:

1. بازنشانی مالکیت و مجوز: اگر ریشه در مجوز یا مالکیت است، این قدم سریع‌ترین راه است.
2. افزایش محدودیت‌های PHP: اگر ریشه در محدودیت حافظه یا زمان اجرا است، افزایش مقادیر مشکل را حل می‌کند.
3. رفع مشکل اتصال خروجی: اگر ریشه در مسدودی اتصال به سرورهای وردپرس است، با پشتیبانی هاست یا با پروکسی حل کنید.
4. بررسی و پیکربندی کرون: اگر ریشه در کرون است، cron سرور را فعال کنید.
5. غیرفعال‌سازی موقت افزونه‌ی مقصر: اگر ریشه در افزونه است، موقتاً غیرفعال کنید و تست بگیرید.
6. بروزرسانی دستی: اگر ریشه در محدودیت‌های سرور است، بروزرسانی دستی راه‌حل موقت است.

پایش مستمر و پیشگیری

بعد از رفع، مهم‌تر از رفع، پیشگیری است. پنج سطح پایش توصیه می‌کنم:

سطح اول: پایش دوره‌ای نسخه‌ها

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

سطح دوم: پایش لاگ بروزرسانی

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

سطح سوم: پایش امنیتی

سایت‌هایی که بروزرسانی نمی‌شوند، در معرض آسیب‌پذیری‌های شناخته‌شده هستند. ابزارهایی مثل WPScan یا سرویس‌های پایش امنیت می‌توانند آسیب‌پذیری‌ها را در نسخه‌های قدیمی شناسایی کنند. مباحث مرتبط در راهنمای امنیت وردپرس برای مبتدیان باز شده است.

سطح چهارم: پایش cron و زمان‌بندی

ماهی یک‌بار، وضعیت کرون وردپرس را با افزونه‌های مدیریت cron بررسی کنید. اگر cron jobهایی در صف باقی مانده‌اند یا اجرا نمی‌شوند، ریشه را پیدا کنید.

سطح پنجم: بکاپ منظم قبل از تغییرات

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

پرسش‌های پرتکرار درباره شکست بروزرسانی خودکار وردپرس

چرا بروزرسانی خودکار وردپرس انجام نمی‌شود؟

این الگو معمولاً به یکی از سه دلیل برمی‌گردد: کرون وردپرس اجرا نمی‌شود، اتصال خروجی به سرورهای وردپرس مسدود است، یا مجوز و مالکیت فایل‌ها با کاربر PHP-FPM هماهنگ نیست. بررسی لاگ PHP و تست اتصال خروجی، سریع‌ترین راه تشخیص است.

آیا بروزرسانی خودکار هسته به‌طور پیش‌فرض فعال است؟

بروزرسانی خودکار برای نسخه‌های فرعی امنیتی (minor) به‌طور پیش‌فرض فعال است. برای نسخه‌های اصلی (major)، به‌طور پیش‌فرض غیرفعال است و باید به‌صورت دستی فعال شود. برای بروزرسانی خودکار افزونه‌ها و قالب‌ها، باید به‌صورت دستی از پیشخوان فعال کنید.

آیا غیرفعال کردن بروزرسانی خودکار می‌تواند سایت را ناامن کند؟

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

چطور بفهمم شکست بروزرسانی از کدام افزونه است؟

روش حذف تدریجی دقیق‌ترین راه است: ابتدا تمام افزونه‌های امنیتی و کش را غیرفعال کنید و تست کنید. سپس افزونه‌ها را یکی‌یکی فعال کنید تا مقصر پیدا شود. در لاگ افزونه‌ی امنیتی هم معمولاً پیام‌های مربوط به مسدودسازی ثبت می‌شود.

چرا بروزرسانی دستی کار می‌کند ولی خودکار نه؟

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

آیا شکست بروزرسانی می‌تواند ناشی از هک شدن سایت باشد؟

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

چطور WP-CLI را برای بروزرسانی دستی نصب کنم؟

WP-CLI از طریق SSH نصب می‌شود. در سرورهای لینوکسی، با دستور curl -O https://raw.githubusercontent.com/wp-cli/builds/gh-pages/phar/wp-cli.phar فایل را دانلود کنید و با chmod +x قابل اجرا کنید. سپس می‌توانید دستورات wp core update و wp plugin update --all را اجرا کنید.

آیا بروزرسانی خودکار روی سایت‌های پربازدید مشکلی ایجاد می‌کند؟

بروزرسانی خودکار می‌تواند سایت را در لحظه‌ی اجرا کمی کند کند، ولی در سایت‌های پربازدید با سرور خوب، این کندی محسوس نیست. اگر سرور شما ضعیف است، ممکن است بروزرسانی خودکار با timeout مواجه شود. راه‌حل: تنظیم زمان‌بندی بروزرسانی در ساعات کم‌ترافیک یا استفاده از بروزرسانی دستی.

چرا نسخه‌ی PHP من روی بروزرسانی خودکار اثر می‌گذارد؟

در نسخه‌های قدیمی PHP (مثل 7.0 یا 7.2)، ممکن است بعضی از APIهای وردپرس که برای بروزرسانی استفاده می‌شوند، به‌درستی کار نکنند. توصیه می‌شود از PHP 8.0 یا بالاتر استفاده کنید.

آیا می‌توانم بروزرسانی خودکار را برای افزونه‌های خاصی غیرفعال کنم؟

بله. بعضی افزونه‌ها مثل Easy Updates Manager یا افزونه‌های مشابه، امکان غیرفعال کردن بروزرسانی خودکار برای افزونه‌های خاص را می‌دهند. این کار برای افزونه‌هایی که با سایت شما تضاد دارند، مفید است.

چطور بفهمم آخرین بروزرسانی موفق چه زمانی بوده؟

در پیشخوان، بخش بروزرسانی‌ها، تاریخ آخرین بررسی را نشان می‌دهد. همچنین می‌توانید در دیتابیس، مقدار last_checked یا update_core در wp_options را بررسی کنید. اگر تاریخ چند ماه پیش است، ریشه در cron یا اتصال است.

نکته‌های میدانی از رفع شکست بروزرسانی

در پایان این مقاله، چند نکته‌ای را می‌گویم که در مستندات رسمی کم‌تر به آن‌ها اشاره می‌شود ولی در پروژه‌های واقعی بارها به کارم آمده:

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

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

سوم: WP-CLI را جدی بگیرید. این ابزار ساده، در بیش از نیمی از مواردی که بروزرسانی خودکار شکست خورده، توانسته سایت را به‌روز کند. اگر دسترسی SSH دارید، نصب WP-CLI را به‌عنوان یک عادت در پروژه‌ها قرار دهید. تجربه‌ی من نشان داده که دستورات ساده‌ای مثل wp core update و wp plugin update --all می‌توانند در بحران، ساعت‌ها زمان ذخیره کنند.

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

اگر روی سایت خود با نوعی از شکست بروزرسانی مواجه شده‌اید که در این مقاله پوشش داده نشده، یا اگر راه‌حل متفاوتی پیدا کرده‌اید که به کارتان آمده، برای من جالب است آن را بشنوم. مشخصاً اگر خروجی لاگ یا کوئری که ریشه‌ی واقعی را نشان داد، با خوانندگان دیگر به اشتراک بگذارید؛ این یادداشت‌های دقیق، برای صاحب سایت بعدی ساعت‌ها زمان صرفه‌جویی می‌کنند. 🔄