ESC را فشار دهید تا بسته شود

Autoload وردپرس چیست؟ رفع هشدار Site Health و سبک‌کردن wp_options

فهرست

اگر Site Health وردپرس درباره «autoloaded options» هشدار می‌دهد، راه‌حل درست حذف تصادفی رکوردهای wp_options نیست. ابتدا باید بفهمید چه گزینه‌هایی در هر درخواست بارگذاری می‌شوند، مالک هر گزینه کدام افزونه یا قالب است، سپس فقط داده‌های واقعاً بلااستفاده را حذف یا Autoload آن‌ها را با روش امن تغییر دهید. در این راهنما مسیر تشخیص، بکاپ، بررسی با SQL و WP-CLI، اصلاح و تست بعد از تغییر را قدم‌به‌قدم انجام می‌دهیم.

Autoload در وردپرس چیست و چرا سایت را کند می‌کند؟

وردپرس برای کاهش تعداد Queryها، بخشی از تنظیمات جدول wp_options را در شروع هر درخواست به‌صورت یکجا بارگذاری می‌کند. این رفتار برای گزینه‌های کوچک و پراستفاده مفید است؛ اما وقتی افزونه‌ها یا قالب‌های قدیمی حجم زیادی داده را Autoload کنند، همان داده در درخواست‌های متعدد وارد حافظه می‌شود و می‌تواند زمان پردازش PHP و مصرف حافظه را بالا ببرد. WordPress Core از نسخه 6.6 نیز رفتار Options API را برای جلوگیری از Autoload شدن گزینه‌های بزرگ بهبود داده است.

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

پیش‌نیاز: قبل از هر تغییر بکاپ بگیرید

تغییر اشتباه در wp_options می‌تواند تنظیمات افزونه، قالب یا حتی آدرس سایت را مختل کند. قبل از شروع، از دیتابیس Export بگیرید. با WP-CLI:

wp db export before-autoload-cleanup.sql

برای بازیابی در صورت نیاز:

wp db import before-autoload-cleanup.sql

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

مرحله ۱: حجم کل گزینه‌های Autoload را اندازه بگیرید

پیشوند جدول همیشه wp_ نیست؛ نام واقعی جدول options را از wp-config.php یا دیتابیس بررسی کنید. برای نصب‌های جدید وردپرس، چند مقدار مختلف می‌توانند به معنی Autoload فعال باشند. Query زیر مجموع تقریبی داده‌های Autoload را نشان می‌دهد:

SELECT ROUND(SUM(LENGTH(option_value))/1024, 2) AS autoload_kb
FROM wp_options
WHERE autoload IN ('yes','on','auto-on','auto');

عدد بالا به‌تنهایی حکم حذف نیست. مهم‌تر از یک Threshold ثابت، روند رشد، تعداد گزینه‌ها و وجود چند رکورد بسیار بزرگ است.

مرحله ۲: بزرگ‌ترین گزینه‌های Autoload را پیدا کنید

SELECT option_name,
       autoload,
       ROUND(LENGTH(option_value)/1024, 2) AS size_kb
FROM wp_options
WHERE autoload IN ('yes','on','auto-on','auto')
ORDER BY LENGTH(option_value) DESC
LIMIT 30;

خروجی را بر اساس option_name بررسی کنید. معمولاً Prefix نام گزینه سرنخی از افزونه یا قالب سازنده می‌دهد. اما صرفاً به دلیل بزرگ بودن یک Option آن را حذف نکنید.

مرحله ۳: مالک Option را پیدا کنید

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

grep -R "نام_option" wp-content/plugins wp-content/themes -n

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

مرحله ۴: با WP-CLI گزینه‌ها را بررسی کنید

WP-CLI برای مشاهده Optionها بدون ورود مستقیم به phpMyAdmin مفید است:

wp option list --autoload=on --fields=option_name,autoload,size_bytes --format=table

اگر نسخه WP-CLI شما فیلد size_bytes را پشتیبانی نکرد، از Query SQL مرحله قبل استفاده کنید. برای دیدن یک مقدار مشخص:

wp option get option_name

برای داده‌های حساس، خروجی کامل Option را در ترمینال مشترک یا تیکت عمومی کپی نکنید.

مرحله ۵: حذف Option بلااستفاده، فقط پس از Verify

اگر با اطمینان مشخص شد Option متعلق به افزونه‌ای است که حذف شده و دیگر استفاده نمی‌شود، ابتدا همان رکورد را Export یا مقدارش را ذخیره کنید. سپس می‌توانید از WP-CLI استفاده کنید:

wp option delete option_name

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

مرحله ۶: آیا Autoload را خاموش کنیم؟

برای Optionی که لازم است باقی بماند اما در هر درخواست نیاز نیست، تغییر Autoload می‌تواند مفید باشد؛ ولی این تصمیم باید بر اساس رفتار افزونه انجام شود. WordPress Core توصیه می‌کند توسعه‌دهنده هنگام ساخت Option مشخص کند آیا باید Autoload شود و در نسخه‌های جدید برای Optionهای بزرگ محدودیت‌های هوشمندتری دارد.

برای کد سفارشی، به‌جای دستکاری مستقیم SQL بهتر است از Options API استفاده شود:

update_option( 'my_option', $value, false );

آرگومان سوم false یعنی این Option در مجموعه Autoload قرار نگیرد. برای Optionهای متعلق به افزونه شخص ثالث، قبل از تغییر رفتار Autoload مستندات یا کد همان افزونه را بررسی کنید.

مرحله ۷: کش را پاک و نتیجه را دوباره اندازه‌گیری کنید

پس از تغییر، Object Cache و Page Cache را پاک کنید و دوباره Query اندازه‌گیری را اجرا کنید. سپس چند صفحه عمومی، wp-admin، Cron، REST API و فرایندهای مهم مثل فرم یا پرداخت را تست کنید.

wp cache flush

اگر Redis/Memcached یا کش سمت هاست دارید، پاک‌سازی آن را نیز طبق تنظیمات سرویس انجام دهید. برای درک بهتر اثر دیتابیس بر عملکرد، راهنمای بهینه‌سازی عملکرد پایگاه داده هم مفید است.

خطاهای رایج در پاک‌سازی wp_options

  • حذف بر اساس اندازه: Option بزرگ لزوماً اضافی نیست.
  • اجرای DELETE مستقیم بدون بکاپ: Rollback را دشوار می‌کند.
  • تغییر همزمان چند ده Option: اگر سایت خراب شود پیدا کردن علت سخت می‌شود.
  • نادیده گرفتن Object Cache: ممکن است بعد از تغییر هنوز داده قدیمی را ببینید.
  • فرض اینکه همه نصب‌ها فقط yes/no دارند: WordPress جدید مقادیر Autoload بیشتری دارد.

Rollback و Recovery

اگر بعد از تغییر خطا دیدید، اولین انتخاب بازگرداندن Option تغییرکرده است. اگر چند تغییر انجام شده و منشأ مشکل مشخص نیست، دیتابیس را از Export قبل از کار Restore کنید:

wp db import before-autoload-cleanup.sql
wp cache flush

سپس وضعیت سایت را دوباره تست کنید. در سایت Production، Restore کامل دیتابیس ممکن است داده‌های جدید کاربران را هم برگرداند؛ بنابراین اگر فاصله زمانی زیادی گذشته، بازیابی انتخابی Option امن‌تر است.

چه زمانی مشکل از هاست است، نه Autoload؟

اگر حجم Autoload منطقی است ولی TTFB همچنان بالاست، PHP workers، CPU/RAM، دیتابیس، Object Cache، افزونه‌های سنگین و I/O را بررسی کنید. در سایت‌های پرترافیک، زیرساخت مناسب نیز مهم است؛ برای پروژه وردپرسی می‌توانید مشخصات هاست وان‌سرور را با نیاز واقعی سایت مقایسه کنید.

جمع‌بندی

برای رفع هشدار Autoload در WordPress، هدف «کم کردن عدد به هر قیمت» نیست. ابتدا اندازه بگیرید، بزرگ‌ترین Optionها را پیدا کنید، مالک هر مورد را Verify کنید، بکاپ بگیرید، تغییر کوچک انجام دهید و نتیجه را دوباره تست کنید. این روش هم ریسک خرابی را کم می‌کند و هم مشخص می‌کند آیا واقعاً wp_options عامل کندی سایت بوده است یا نه.

منابع فنی: WordPress Core Options API و مستندات رسمی تغییرات Autoload در WordPress 6.6.

Rate this post
اشتراک گذاری نوشته در:

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

نشانی ایمیل شما منتشر نخواهد شد. بخش‌های موردنیاز علامت‌گذاری شده‌اند *