نکات تکمیلی تنظیمات wp-config.php

در نوشته قبلی با عنوان راهنمای کاربردی فایل wp-config.php، یاد گرفتیم که اطلاعات اتصال به پایگاه داده، کلیدهای امنیتی، پیشوند جداول و تعداد زیادی ثوابت مورد استفاده برای تغییر رفتار وردپرس در این فایل قرار می‌گیرند. اما بخش قابل توجهی از تنظیمات wp-config.php فراتر از اطلاعات اتصال به پایگاه داده یا تعیین آدرس سایت است. وردپرس مجموعه‌ای از ثوابت دیگر را برای این فایل تعریف کرده که با آنها می‌توان رفتار عیب‌یابی (Debugging)، به‌روزرسانی (Updating)، انجام عملیات تکراری (Cron)، مدیریت حافظه، مدیریت محیط‌ها (Environment)، قابلیت‌های ویرایش فایل‌ها و حتی درخواست‌های HTTP خارجی را کنترل کرد.

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

تعیین محیط استفاده

وردپرس برای تعیین محیطی که داخل آن در حال اجراست، ثابت WP_ENVIRONMENT_TYPE را ارائه می‌کند:

define('WP_ENVIRONMENT_TYPE', 'staging');

چهار مقدار معتبر برای آن وجود دارد:

local
development
staging
production

اگر مقدار معتبری در تنظیمات wp-config.php تعیین نشود، وردپرس آن را production در نظر می‌گیرد.

مقدار local برای نسخه‌ای از سایت است که معمولاً روی کامپیوتر توسعه‌دهنده و برای کدنویسی و آزمایش اجرا می‌شود؛ staging به محیطی شبیه سایت اصلی گفته می‌شود که برای تست تغییرات، افزونه‌ها و به‌روزرسانی‌ها پیش از انتشار استفاده می‌شود و production همان سایت واقعی و در دسترس کاربران است که باید تنظیمات پایدار و مناسب محیط عملیاتی داشته باشد. وردپرس علاوه بر این سه مورد، مقدار development را نیز پشتیبانی می‌کند که برای محیط توسعه‌ای در نظر گرفته شده است.

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

نکته مهم این است که در وردپرس، اگر WP_ENVIRONMENT_TYPE روی development باشد و WP_DEBUG را صراحتاً تعریف نکرده باشید، وردپرس WP_DEBUG را فعال می‌کند؛ این رفتار به‌صورت خودکار برای local اعمال نمی‌شود.

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

wp_get_environment_type();

عیب‌یابی با WP_DEBUG

رایج‌ترین ثابت فایل wp-config.php مربوط به عیب‌یابی سیستم یا Debugging احتمالاً این است:

define('WP_DEBUG', true);

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

برای کنترل دقیق‌تر فرآیند عیب‌یابی وردپرس، معمولاً ثوابت دیگری هم مطرح می‌شوند:

define('WP_DEBUG', true);
define('WP_DEBUG_LOG', true);
define('WP_DEBUG_DISPLAY', false);

در این حالت از تنظیمات wp-config.php، عیب‌یابی فعال است و خطاها می‌توانند لاگ شوند، اما قرار نیست مستقیماً به بازدیدکننده نمایش داده شوند. فایل پیش‌فرض لاگ عیب‌یابی در حالت معمول در این مسیر است:

wp-content/debug.log

چرا نمایش خطا در پروداکشن مشکل دارد؟

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

define('WP_DEBUG', false);

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

قابلیت SCRIPT_DEBUG

یکی از ثابت‌های کمتر شناخته شده تنظیمات wp-config.php، همین SCRIPT_DEBUG است:

define('SCRIPT_DEBUG', true);

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

برای یک سایت زنده عادی معمولاً دلیلی برای فعال نگه داشتن SCRIPT_DEBUG وجود ندارد!

غیرفعال کردن ادیتور پیشخوان

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

define('DISALLOW_FILE_EDIT', true);

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

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

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

غیرفعال کردن آپدیت از پیشخوان

یکی از تنظیمات سخت‌گیرانه وردپرس، گزینه DISALLOW_FILE_MODS است:

define('DISALLOW_FILE_MODS', true);

این ثابت علاوه بر ادیتور پیشخوان، قابلیت نصب و به‌روزرسانی افزونه‌ها و پوسته‌ها از محیط ادمین وردپرس را نیز محدود می‌کند. چنین تنظیمی در پروژه‌هایی که استقرار آنها از طریق Git یا CI/CD یا فرآیند کنترل‌شده انجام می‌شود می‌تواند منطقی باشد. اما فعال کردن آن در تنظیمات wp-config.php سایتی که مدیر سایت انتظار دارد به‌روزرسانی‌ها را از پیشخوان انجام دهد، احتمالاً دردسر ایجاد می‌کند.

مدیریت حافظه

در تنظیمات wp-config.php امکان تعیین محدودیت حافظه مورد استفاده وردپرس نیز وجود دارد:

define('WP_MEMORY_LIMIT', '256M');

برای ناحیه ادمین سایت نیز ثابت دیگری وجود دارد:

define('WP_MAX_MEMORY_LIMIT', '512M');

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

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

کنترل وظایف زمان‌بندی شده

در وردپرس، وظایف زمان‌بندی شده یا Scheduled Tasks به کارهایی گفته می‌شود که باید در زمان مشخص یا به صورت دوره‌ای اجرا شوند و معمولاً توسط WP-Cron مدیریت می‌شوند. چند نمونه واقعی و رایج عبارت‌اند از:

• انتشار نوشته زمان‌بندی شده: مثلاً نوشته‌ای تنظیم شده ساعت ۱۰ صبح فردا منتشر شود.
• بررسی به‌روزرسانی‌ها: وردپرس به صورت دوره‌ای وجود نسخه جدید هسته، افزونه‌ها و پوسته‌ها را بررسی می‌کند.
• پاک‌سازی داده‌های موقت: حذف ترنزیت‌های منقضی‌شده و برخی داده‌هایی که دیگر مورد نیاز نیستند.
• اجرای کارهای دوره‌ای افزونه‌ها: افزونه‌ها می‌توانند رخدادهای اختصاصی WP-Cron داشته باشند؛ مثلاً یک افزونه بکاپ‌گیری ممکن است هر شب بکاپ بگیرد یا یک افزونه فروشگاهی، کارهای دوره‌ای خودش را اجرا کند.

در بعضی معماری‌های پروداکشن، ترجیح داده می‌شود اجرای وظایف زمان‌بندی شده از درخواست‌های معمولی سایت جدا شود و سرور دیگری مسئول فراخوانی آن باشد. در چنین شرایطی می‌توان WP-Cron داخلی را از تنظیمات wp-config.php غیرفعال کرد:

define('DISABLE_WP_CRON', true);

اما این خط به تنهایی یک بهینه‌سازی محسوب نمی‌شود! اگر WP-Cron را غیرفعال کنید و هیچ Cron Job جایگزینی روی سرور نسازید، وظایف زمان‌بندی شده سایت ممکن است در زمان مورد انتظار اجرا نشوند.

قابلیت WP_CACHE

ممکن است در تنظیمات wp-config.php این خط را دیده باشید:

define('WP_CACHE', true);

دیدن ثابت WP_CACHE به این معنا نیست که وردپرس با همین خط کد، ناگهان یک سیستم کش کامل برای سایت ایجاد کرده است. WP_CACHE یک فلگ در فرآیند بوت‌استرپ وردپرس است و معمولاً توسط راهکارهای کشینگ مورد استفاده قرار می‌گیرد. مقدار پیش‌فرض آن در وردپرس false است.

بنابراین اضافه کردن تصادفی WP_CACHE بدون اینکه لایه کش مربوطه وجود داشته باشد، یک روش مستقل برای افزایش عملکرد سایت به حساب نمی‌آید!

قابلیت SAVEQUERIES

یکی از گزینه‌های جالب برای بررسی کوئری‌های پایگاه داده همین قابلیت SAVEQUERIES است:

define('SAVEQUERIES', true);

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

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

یکی از ثابت‌های بامزه تنظیمات wp-config.php ثابت زیر است که به شما اجازه می‌دهد مدت نگهداری آیتم‌ها در زباله‌دان وردپرس را تغییر دهید:

define('EMPTY_TRASH_DAYS', 14);

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

تعمیر خودکار پایگاه داده

وردپرس قابلیتی برای تعمیر و بهینه‌سازی جداول پایگاه داده دارد که می‌توان دسترسی به آن را با ثابت زیر فعال کرد:

define('WP_ALLOW_REPAIR', true);

پس از فعال شدن، صفحه مخصوص تعمیر پایگاه داده (Repair Database) قابل استفاده می‌شود. این صفحه به صورت پیش‌فرض در این آدرس قرار دارد:

example.com/wp-admin/maint/repair.php

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

مسدود کردن درخواست‌های خارجی

یکی از تنظیمات wp-config.php کمتر دیده شده، مربوط به مسدود کردن درخواست‌های HTTP خارجی است:

define('WP_HTTP_BLOCK_EXTERNAL', true);

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

define('WP_ACCESSIBLE_HOSTS', 'api.example.com,*.wordpress.org');

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

تنظیمات متفاوت محیط‌ها

یکی از مشکلات رایج در تنظیمات wp-config.php این است که همان فایل کانفیگ بین محیط‌های مختلف کپی می‌شود.

مثلاً تنظیمات مناسب محیط توسعه به صورت زیر است:

define('WP_ENVIRONMENT_TYPE', 'development');
define('WP_DEBUG', true);
define('WP_DEBUG_LOG', true);
define('SCRIPT_DEBUG', true);

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

define('WP_ENVIRONMENT_TYPE', 'production');
define('WP_DEBUG', false);
define('WP_DEBUG_DISPLAY', false);
define('SCRIPT_DEBUG', false);

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

اصول مهم تنظیمات wp-config.php

اولین اصل این است که اطلاعات محرمانه را محرمانه نگه دارید. فایل تنظیمات wp-config.php معمولاً شامل رمز عبور پایگاه داده و کلیدهای احراز هویت است و نباید محتوای واقعی آن در ریپازیتوری‌های عمومی قرار گیرد.

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

سوم، هر ثابت باید دلیل مشخصی داشته باشد. اگر نمی‌دانید چرا این خط در کانفیگ قرار گرفته است:

define('SOME_SETTING', true);

قبل از نگه داشتن آن مستندات رسمی وردپرس مربوط به همان ثابت را بررسی کنید.

همچنین دیباگینگ دائمی روی پروداکشن، فعال نگه داشتن ابزارهای تعمیر، تعیین محدودیت‌های غیرواقعی برای حافظه و کپی/پیست کردن کانفیگ‌های منتشر شده در فضای مجازی به عنوان «ترفندهای بهینه‌سازی وردپرس»، رویکرد مناسبی برای مدیریت سایت نیست.

پرسش‌های متداول

اهمیت فایل تنظیمات wp-config.php بیشتر زمانی مشخص می‌شود که وردپرس را به‌عنوان یک برنامه ببینیم، نه فقط یک CMS که از پیشخوان مدیریت می‌شود. این فایل بخشی از رفتار برنامه را متناسب با محیط مشخص می‌کند. حالت Development می‌تواند دیباگینگ بیشتری داشته باشد، Staging می‌تواند برای تست ادغام تنظیم شود و Production می‌تواند محدودیت‌های سخت‌گیرانه‌تری روی تغییر فایل‌ها داشته باشد.

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