تنظیمات وردپرس ذخیره نمی شود + راه حل قطعی و سریع

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

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

ذخیره‌نشدن تنظیمات دقیقاً چه معنایی دارد؟

وقتی در وردپرس روی دکمه‌ی ذخیره‌ی یک صفحه‌ی تنظیمات کلیک می‌کنید، یک زنجیره‌ی فنی مشخص در پشت صحنه اجرا می‌شود. مرورگر یک درخواست POST به سرور می‌فرستد؛ PHP این درخواست را دریافت و پردازش می‌کند؛ وردپرس با استفاده از تابع update_option مقدار جدید را در جدول wp_options دیتابیس ذخیره می‌کند؛ و در نهایت پاسخ موفقیت به مرورگر برگردانده می‌شود. اگر در هر یک از این گام‌ها اختلالی رخ دهد، تنظیمات ذخیره نمی‌شود. مباحث پایه‌ای ساختار وردپرس در وردپرس چیست و چگونه شروع کنیم باز شده است.

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

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

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

ده ریشه‌ی اصلی ذخیره‌نشدن تنظیمات در وردپرس

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

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

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

ریشه‌ی دوم: جدول wp_options پر یا آسیب‌دیده

اگر جدول wp_options به‌دلیل ترنزینت‌های زیاد، رکوردهای یتیم یا خرابی داخلی سنگین شده باشد، ذخیره‌ی مقادیر جدید ممکن است با شکست مواجه شود. این سناریو در سایت‌های چندساله شایع‌تر است.

ریشه‌ی سوم: کش سرور یا کش افزونه

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

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

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

ریشه‌ی پنجم: محدودیت max_input_vars

مقدار max_input_vars در PHP، حداکثر تعداد متغیرهای ورودی در یک درخواست POST را مشخص می‌کند. اگر فرم تنظیمات شما بیش از این مقدار فیلد داشته باشد، بخشی از داده‌ها اصلاً به سرور نمی‌رسد و ذخیره‌ی تنظیمات ناقص انجام می‌شود. این سناریو در تنظیمات ووکامرس، صفحه‌سازها و سایت‌های چندزبانه شایع‌تر است.

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

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

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

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

ریشه‌ی هشتم: مشکل در جدول wp_options و autoload

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

ریشه‌ی نهم: مشکل در session و nonce

وردپرس برای حفاظت از فرم‌های تنظیمات، از nonce استفاده می‌کند. اگر nonce منقضی یا نامعتبر باشد، وردپرس درخواست ذخیره را رد می‌کند و پیام Are you sure you want to do this? می‌دهد. این سناریو در سایت‌هایی که سشن‌های طولانی یا چند سرور دارند، شایع‌تر است.

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

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

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

اگر همین حالا با مشکل ذخیره‌نشدن تنظیمات مواجه هستید و می‌خواهید سریعاً مشکل را حل کنید، این پنج حرکت را به همین ترتیب اجرا کنید:

1. پاک‌سازی کش: کش مرورگر، کش افزونه و در صورت دسترسی، کش سرور را پاک کنید. این حرکت ساده، شایع‌ترین دلیل ذخیره‌نشدن تنظیمات را برطرف می‌کند.
2. تست در حالت Incognito: سایت را در پنجره‌ی ناشناس باز کنید و تنظیمات را ذخیره کنید. اگر در حالت ناشناس تنظیمات ذخیره شد، ریشه در کش مرورگر است.
3. غیرفعال‌سازی موقت افزونه‌های کش: اگر افزونه‌ی کش فعال است، موقتاً آن را غیرفعال کنید و تست کنید.
4. بررسی max_input_vars: از پیشخوان، مسیر ابزارها > سلامت سایت را باز کنید و مقدار max_input_vars را ببینید. اگر کمتر از ۳۰۰۰ است، باید افزایش یابد.
5. بررسی مجوزهای دیتابیس: از phpMyAdmin، مجوز کاربر دیتابیس را بررسی کنید و مطمئن شوید دسترسی نوشتن روی جدول wp_options دارد.

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

تشخیص دقیق با DevTools و لاگ‌ها

ابزارهای تشخیصی، دقیق‌ترین راه پیدا کردن ریشه‌ی ذخیره‌نشدن تنظیمات هستند. دو ابزار کلیدی که در پروژه‌ها زیاد از آن‌ها استفاده می‌کنم:

DevTools مرورگر

در مرورگر، ابزار DevTools را باز کنید (کلید F12) و به تب Network بروید. فرم تنظیمات را ذخیره کنید و درخواست POST را بررسی کنید:

1. کد وضعیت پاسخ: اگر ۲۰۰ باشد ولی تنظیمات ذخیره نشود، ریشه در سرور است. اگر ۴۰۳ یا ۴۰۶ باشد، ریشه در mod_security یا فایروال است. اگر ۵۰۰ باشد، ریشه در PHP است.
2. محتوای پاسخ: اگر پاسخ شامل پیام خطای PHP بود، ریشه در همان خطا است.
3. داده‌های ارسالی: در تب Payload، می‌توانید ببینید که تمام فیلدهای فرم به‌درستی ارسال شده‌اند یا بعضی‌ها حذف شده‌اند. اگر بخشی از فیلدها در Payload نیستند، ریشه در max_input_vars است.

لاگ PHP و لاگ دیتابیس

اگر خطای PHP در ذخیره‌ی تنظیمات رخ دهد، در لاگ PHP ثبت می‌شود. برای فعال‌سازی، در wp-config.php مقادیر WP_DEBUG و WP_DEBUG_LOG را تنظیم کنید. لاگ در wp-content/debug.log ذخیره می‌شود. روش دقیق خواندن لاگ در بررسی خطاهای سرور در لاگ‌ها باز شده است.

در لاگ دیتابیس MySQL (در صورت فعال‌سازی)، می‌توانید کوئری‌های UPDATE wp_options را ببینید و مطمئن شوید که این کوئری‌ها با موفقیت اجرا می‌شوند یا خطا می‌دهند.

مشکل مجوزها و جدول wp_options

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

مجوزهای کاربر دیتابیس

کاربر دیتابیس وردپرس باید دسترسی SELECT، INSERT، UPDATE و DELETE روی تمام جدول‌های دیتابیس داشته باشد. اگر یکی از این مجوزها نباشد، ذخیره‌ی تنظیمات با شکست مواجه می‌شود. برای بررسی و اصلاح:

GRANT SELECT, INSERT, UPDATE, DELETE ON your_database.* TO 'your_user'@'localhost';
FLUSH PRIVILEGES;

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

حجم جدول wp_options

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

SELECT table_name, table_rows, data_length, index_length
FROM information_schema.tables
WHERE table_schema = 'your_database_name'
  AND table_name = 'wp_options';

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

DELETE FROM wp_options WHERE option_name LIKE '_transient_%';

قبل از اجرای این کوئری، بکاپ کامل دیتابیس بگیرید.

مشکل autoload در wp_options

مقدار autoload رکوردهای wp_options تعیین می‌کند که کدام تنظیمات در حافظه بارگذاری شوند. اگر مقدار این ستون اشتباه تنظیم شده باشد، ممکن است ذخیره‌ی تنظیمات با تأخیر یا شکست مواجه شود. برای بررسی:

SELECT SUM(LENGTH(option_value)) AS autoload_size
FROM wp_options
WHERE autoload = 'yes';

اگر مقدار این مجموع از ۱ مگابایت بیشتر است، باید بخشی از رکوردها را از autoload خارج کنید. مباحث مرتبط در تأثیر دیتابیس بر سرعت سایت باز شده است.

کش سرور، کش افزونه و کش مرورگر

کش، شایع‌ترین دلیل ظاهری ذخیره‌نشدن تنظیمات است. شما تنظیمات را در دیتابیس ذخیره می‌کنید ولی نسخه‌ی قدیمی را می‌بینید. سه لایه‌ی کش که باید بررسی شوند:

کش مرورگر

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

کش افزونه

افزونه‌های کش مثل WP Rocket یا LiteSpeed Cache، صفحات را کش می‌کنند. اگر این افزونه‌ها، صفحه‌ی تنظیمات ووکامرس یا تنظیمات سایت را هم کش کنند، تغییرات را نمی‌بینید. راه‌حل: صفحه‌های پیشخوان و تنظیمات را از کش مستثنی کنید. مباحث مرتبط در بهترین افزونه‌های کش وردپرس باز شده است.

کش سرور

در بعضی هاست‌ها، کش سرور (مثل Varnish یا LiteSpeed Cache سرور) فعال است. اگر این کش تنظیمات را هم ذخیره کند، تغییرات اعمال نمی‌شود. راه‌حل: از پنل هاست، کش سرور را پاک کنید یا بخش پیشخوان را از کش مستثنی کنید. مباحث مرتبط در نقش CDN در سرعت سایت باز شده است.

mod_security و فایروال وب‌سرور

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

نشانه‌های مداخله‌ی mod_security

اگر با ذخیره‌ی تنظیمات، صفحه‌ی سفید یا پیام 406 Not Acceptable یا 403 Forbidden می‌بینید، احتمال مداخله‌ی mod_security جدی است. در لاگ آپاچی، پیام‌هایی مثل ModSecurity: Access denied with code 406 دیده می‌شود.

روش تشخیص

از طریق SSH یا پنل هاست، به لاگ mod_security دسترسی بگیرید. مسیر معمولاً /var/log/apache2/modsec_audit.log یا /var/log/modsec_audit.log است. اگر در لحظه‌ی ذخیره‌ی تنظیمات، خطای جدیدی در این لاگ ثبت شد، ریشه در mod_security است.

راه‌حل

سه راه‌حل:

1. غیرفعال‌سازی mod_security: در محیط استیجینگ، به‌طور موقت این ماژول را غیرفعال کنید و تست کنید. اگر مشکل رفع شد، ریشه در mod_security است. در محیط تولید، به‌جای غیرفعال‌سازی کامل، قواعدی که مشکل ایجاد می‌کنند را مستثنی کنید.
2. سفید کردن قاعده: در پیکربندی mod_security، می‌توانید قاعده‌ی خاصی را برای مسیر پیشخوان وردپرس غیرفعال کنید.
3. ارتباط با پشتیبانی هاست: در هاست‌های اشتراکی، ممکن است دسترسی مستقیم به mod_security نداشته باشید. در این حالت، از پشتیبانی بخواهید درخواست‌های مسیر /wp-admin/options.php را از mod_security مستثنی کنند.

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

محدودیت‌های PHP و max_input_vars

محدودیت‌های PHP، شایع‌ترین دلیل ذخیره‌نشدن تنظیمات پیچیده است. سه محدودیت کلیدی:

max_input_vars

این مقدار، حداکثر تعداد متغیرهای ورودی در یک درخواست POST را مشخص می‌کند. مقدار پیش‌فرض معمولاً ۱۰۰۰ است، ولی در فرم‌های تنظیمات پیچیده مثل ووکامرس یا صفحه‌سازها، این تعداد می‌تواند به بیش از ۲۰۰۰ برسد. اگر مقدار از سقف بیشتر شود، بخشی از فیلدها اصلاً به سرور نمی‌رسد. راه‌حل: افزایش این مقدار در php.ini یا .user.ini:

max_input_vars = 5000

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

post_max_size

این مقدار، حداکثر حجم یک درخواست POST را مشخص می‌کند. اگر فرم تنظیمات شما شامل داده‌های سنگین (مثل محتوای HTML یا کد CSS) باشد، ممکن است از سقف این مقدار بیشتر شود. راه‌حل: افزایش این مقدار به ۳۲ مگابایت یا بیشتر:

post_max_size = 32M

memory_limit

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

memory_limit = 256M

برای اعمال این تغییرات، می‌توانید از فایل php.ini، فایل .user.ini در ریشه‌ی سایت، یا از پنل مدیریت هاست استفاده کنید. در بعضی هاست‌ها، تغییر این مقادیر به‌صورت مستقیم از پنل ممکن نیست و باید با پشتیبانی درخواست دهید. مباحث مرتبط در راه‌حل خطای Memory Limit در PHP باز شده است.

تداخل افزونه‌ها و قالب

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

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

سه دسته افزونه بیشتر از بقیه مشکوک هستند:

1. افزونه‌های کش: اگر این افزونه‌ها صفحه‌ی تنظیمات را هم کش کنند، تغییرات را نمی‌بینید.
2. افزونه‌های امنیتی: افزونه‌هایی مثل Wordfence که درخواست‌های POST را بازبینی می‌کنند، ممکن است درخواست ذخیره‌ی تنظیمات را به‌عنوان فعالیت مشکوک مسدود کنند.
3. افزونه‌های شخصی‌سازی: افزونه‌هایی که فرم‌های تنظیمات را بازنویسی می‌کنند، ممکن است با سایر افزونه‌ها تضاد داشته باشند.

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

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

قالب و کد سفارشی

اگر در functions.php قالب یا در یک افزونه‌ی سفارشی، تابعی تعریف شده باشد که مقادیر تنظیمات را در لحظه‌ی خواندن بازنویسی کند، ممکن است ذخیره‌ی تنظیمات به‌نظر نرسد. برای تشخیص، قالب را موقتاً به یک قالب پیش‌فرض تغییر دهید و تست کنید. مباحث مرتبط با ساختار قالب در قالب چایلد وردپرس باز شده است.

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

بعضی تنظیمات وردپرس، به‌دلیل پیچیدگی خاص، بیشتر در معرض خطای ذخیره‌نشدن قرار دارند. سه سناریوی خاص:

تنظیمات پیوندهای یکتا

صفحه‌ی پیوندهای یکتا در وردپرس، با هر ذخیره، قواعد rewrite را در دیتابیس بازسازی می‌کند. اگر این بازسازی با شکست مواجه شود (به‌دلیل محدودیت منابع یا مجوزها)، تنظیمات ذخیره نمی‌شود. راه‌حل: بعد از ذخیره، از طریق FTP، فایل .htaccess را بررسی کنید که آیا قواعد جدید اعمال شده‌اند. مباحث مرتبط در ساختار URL و سئو باز شده است.

تنظیمات ووکامرس

صفحه‌ی تنظیمات ووکامرس، یکی از پیچیده‌ترین فرم‌های تنظیمات در وردپرس است. اگر تعداد فیلدهای آن از max_input_vars بیشتر شود، بخشی از تنظیمات ذخیره نمی‌شود. راه‌حل: افزایش max_input_vars به ۵۰۰۰ یا بیشتر. مباحث مرتبط در تنظیم روش‌های پرداخت در ووکامرس باز شده است.

تنظیمات سایت چندزبانه

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

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

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

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

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

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

سطح اول: پایش دوره‌ای تنظیمات

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

سطح دوم: پایش حجم جدول wp_options

ماهی یک‌بار، حجم جدول wp_options را بررسی کنید. اگر بیش از ۵۰ مگابایت شد، پاک‌سازی انجام دهید. مباحث مرتبط در تأثیر دیتابیس بر سرعت سایت باز شده است.

سطح سوم: پایش محدودیت‌های PHP

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

سطح چهارم: پایش لاگ mod_security

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

پرسش‌های پرتکرار درباره ذخیره‌نشدن تنظیمات وردپرس

چرا تنظیمات وردپرس ذخیره نمی‌شود ولی پیام خطایی نمایش داده نمی‌شود؟

این الگو معمولاً به یکی از سه دلیل برمی‌گردد: کش سرور یا مرورگر که نسخه‌ی قدیمی را نشان می‌دهد، محدودیت max_input_vars که بخشی از داده‌ها را حذف می‌کند، یا مشکل در دیتابیس که ذخیره را بی‌سروصدا شکست می‌دهد. بررسی DevTools و لاگ‌ها، سریع‌ترین راه تشخیص است.

آیا افزونه‌های کش می‌توانند باعث ذخیره‌نشدن تنظیمات شوند؟

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

چرا تنظیمات پیوندهای یکتا ذخیره نمی‌شود؟

این سناریو معمولاً به دو دلیل برمی‌گردد: مشکل در مجوز نوشتن فایل .htaccess یا مشکل در بازسازی جدول wp_options. بررسی مجوز فایل و حجم جدول، اولین گام است. مباحث مرتبط در ساختار URL و سئو باز شده است.

آیا تغییر قالب می‌تواند مشکل ذخیره‌نشدن تنظیمات را برطرف کند؟

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

چطور max_input_vars را افزایش دهم؟

سه روش: اول، از فایل php.ini در ریشه‌ی هاست. دوم، از فایل .user.ini در ریشه‌ی سایت. سوم، از پنل مدیریت هاست (در هاست‌های cPanel، از بخش MultiPHP INI Editor). اگر هیچ‌کدام ممکن نبود، از پشتیبانی هاست بخواهید مقدار را افزایش دهد. مباحث مرتبط در راه‌حل خطای Memory Limit در PHP باز شده است.

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

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

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

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

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

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

آیا ذخیره‌نشدن تنظیمات در هاست اشتراکی شایع‌تر است؟

بله، در هاست‌های اشتراکی، محدودیت‌های منابع مثل max_input_vars، memory_limit و post_max_size معمولاً پایین‌تر است و باعث بروز این خطا می‌شود. راه‌حل: ارتقا به پلن بالاتر یا درخواست افزایش منابع از پشتیبانی. مباحث مرتبط در بهترین هاست وردپرس باز شده است.

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

اگر بعد از رفع تمام محدودیت‌ها و بهینه‌سازی‌ها، هنوز مشکل ادامه دارد و ترند مصرف منابع نشان می‌دهد که به سقف نزدیک هستید، مهاجرت هاست اجتناب‌ناپذیر است. علائم کلیدی: مصرف مداوم حافظه بالای ۸۵ درصد، خطاهای max_input_vars مکرر، و تعداد زیاد فرم‌های پیچیده که در هاست فعلی کار نمی‌کنند.

نکته‌های میدانی از رفع این خطا

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

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

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

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

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

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