Основные и продвинутые возможности конфигурации сайта с помощью wp-config.php
Основные подходы к конфигурации WordPress через wp-config.php
Как обеспечить базовую безопасность и производительность в production-среде?
Наиболее эффективным решением для production-окружения является комбинация настроек, которая отключает отладку, устанавливает уникальные ключи и соли, запрещает редактирование файлов через админку и включает кэширование. Ниже представлен фрагмент wp-config.php с оптимальными значениями.
// Отключение отладки и показа ошибок
define('WP_DEBUG', false);
define('WP_DEBUG_DISPLAY', false);
define('WP_DEBUG_LOG', false);
// Уникальные ключи и соли (генерируются на https://api.wordpress.org/secret-key/1.1/salt/)
define('AUTH_KEY', '...');
define('SECURE_AUTH_KEY', '...');
define('LOGGED_IN_KEY', '...');
define('NONCE_KEY', '...');
define('AUTH_SALT', '...');
define('SECURE_AUTH_SALT', '...');
define('LOGGED_IN_SALT', '...');
define('NONCE_SALT', '...');
// Запрет редактирования файлов напрямую из панели администратора
define('DISALLOW_FILE_EDIT', true);
// Включение кэширования (используется плагинами кэширования)
define('WP_CACHE', true);
// Ограничение количества ревизий записи
define('WP_POST_REVISIONS', 5);
Wp settings php (настройки wordpress (wp-config.php или settings.php))
Пояснения:
- WP_DEBUG выключен - ошибки не выводятся на экран.
- DISALLOW_FILE_EDIT предотвращает модификацию файлов темы и плагинов через админку, что повышает безопасность.
- WP_CACHE сообщает плагинам, что кэширование активно.
Типичная проблема: после копирования готового файла wp-config.php с другого сайта забывают заменить ключи и соли, что делает сайт уязвимым.
Решение: всегда генерировать новую пару ключей через официальный генератор WordPress. Также можно автоматически подставлять ключи через переменные окружения (например, в среде Docker).
Как включить режим отладки и логирование ошибок?
Для разработки или диагностики проблем полезно активировать детальную запись ошибок. Ниже приведён вариант, который пишет все предупреждения и ошибки в файл wp-content/debug.log, но не отображает их на экране.
define('WP_DEBUG', true);
define('WP_DEBUG_LOG', true);
define('WP_DEBUG_DISPLAY', false);
@ini_set('display_errors', 0);
Помимо этого, можно включить логирование медленных запросов к базе данных:
define('SAVEQUERIES', true);
Назначение: SAVEQUERIES сохраняет все SQL-запросы в массиве $wpdb->queries для последующего анализа.
Типичная ошибка: забывают отключить WP_DEBUG в production - сайт начинает выводить чувствительные данные на экран.
Решение: использовать разные файлы конфигурации для разных сред (local, stage, production) или управлять константами через переменные окружения.
Как настроить мультисайт (WordPress Multisite)?
Активация сети сайтов требует добавления константы WP_ALLOW_MULTISITE и последующей установки через админку. После завершения установки в wp-config.php добавляются дополнительные параметры.
// Включить поддержку мультисайта
define('WP_ALLOW_MULTISITE', true);
// После установки сети автоматически добавляются строки (пример для поддоменов):
define('MULTISITE', true);
define('SUBDOMAIN_INSTALL', true);
define('DOMAIN_CURRENT_SITE', 'example.com');
define('PATH_CURRENT_SITE', '/');
define('SITE_ID_CURRENT_SITE', 1);
define('BLOG_ID_CURRENT_SITE', 1);
Важно: если используется схема с поддоменами, необходимо настроить DNS и веб-сервер для приёма запросов на любые поддомены (wildcard).
Типичная проблема: после включения мультисайта административные ссылки перестают работать из-за неправильного COOKIE_DOMAIN.
Решение: добавить константу для общих кук:
define('COOKIE_DOMAIN', false);
Если проблема сохраняется, указать домен явно.
Как настроить кэширование и сжатие ресурсов?
Для ускорения загрузки frontend можно включить сжатие CSS/JS и объединение скриптов (но эти функции устарели и не рекомендуются к использованию, предпочтительнее плагины кэширования). Однако в wp-config.php можно задать поведение.
// Включение сжатия CSS и JS
define('COMPRESS_CSS', true);
define('COMPRESS_SCRIPTS', true);
// Включение объединения файлов
define('CONCATENATE_SCRIPTS', true);
define('ENFORCE_GZIP', true);
Более современный подход - использование констант для управления кэшированием объектов (например, Redis или Memcached).
// Включение кэширования объектов через Redis (требует установки плагина)
define('WP_REDIS_HOST', '127.0.0.1');
define('WP_REDIS_PORT', 6379);
define('WP_CACHE_KEY_SALT', 'unique_salt');
Как ограничить используемую память?
WordPress может потреблять много памяти при обработке медиафайлов или обновлении. Установка лимита через wp-config.php:
// Максимум памяти для WP (до 256M или 512M при работе с большими файлами)
define('WP_MEMORY_LIMIT', '256M');
// Лимит для административной панели (обычно выше)
define('WP_MAX_MEMORY_LIMIT', '512M');
Обратите внимание: PHP также имеет собственные лимиты (memory_limit), которые могут переопределить эти значения.
Типичная проблема: после установки лимита в wp-config.php ошибка «Allowed memory size exhausted» всё равно появляется - значит, хостинг блокирует переопределение.
Решение: попробовать увеличить лимит через php.ini или .htaccess, либо обратиться к хостеру.
Как настроить автоматические обновления?
Можно полностью отключить автоматические обновления или разрешить только минорные.
// Полное отключение всех автоматических обновлений
define('AUTOMATIC_UPDATER_DISABLED', true);
// Отключить только обновления ядра (минорные остаются)
define('WP_AUTO_UPDATE_CORE', false);
// Разрешить только обновления для плагинов и тем (если не отключено глобально)
// Этот вариант требует дополнительных фильтров.
Также можно настроить email-уведомления об обновлениях:
define('AUTOMATIC_UPDATER_DISABLED', false); // не отключаем
define('WP_CRON_LOCK_TIMEOUT', 60);
// Через фильтр можно отключить письма
add_filter('auto_core_update_send_email', '__return_false');
Как изменить пути к папкам (content, plugins, themes, uploads)?
Иногда требуется вынести загрузки или контент за пределы стандартной структуры.
// Смена корневой директории загрузок
define('UPLOADS', 'myfiles');
// Перемещение wp-content в другой каталог
define('WP_CONTENT_DIR', dirname(__FILE__) . '/custom-content');
define('WP_CONTENT_URL', 'https://cdn.example.com/custom-content');
// Перемещение только плагинов
define('WP_PLUGIN_DIR', dirname(__FILE__) . '/my-plugins');
define('WP_PLUGIN_URL', 'https://cdn.example.com/my-plugins');
При смене путей следует убедиться, что веб-сервер имеет доступ к новым директориям, а в БД не остались старые ссылки.
Как настроить соединение с базой данных для высокой нагрузки?
Помимо базовых параметров, можно задать persistent-соединение, набор символов и коллацию.
define('DB_HOST', 'localhost');
define('DB_NAME', 'mydb');
define('DB_USER', 'user');
define('DB_PASSWORD', 'pass');
define('DB_CHARSET', 'utf8mb4');
define('DB_COLLATE', 'utf8mb4_unicode_ci');
// Включить постоянные соединения (только для опытных пользователей)
define('WP_USE_PERSISTENT_CONNECTIONS', true);
Для больших проектов используют отдельные хосты для чтения и записи, что требует дополнительных плагинов (например, HyperDB).
Как принудительно включить SSL для админки и логина?
Для защиты сессий и данных.
define('FORCE_SSL_ADMIN', true);
define('FORCE_SSL_LOGIN', true); // устарело, FORCE_SSL_ADMIN перекрывает
// Дополнительно: задать основной URL с https
define('WP_HOME', 'https://example.com');
define('WP_SITEURL', 'https://example.com');
Если SSL-сертификат настроен некорректно, после включения этих констант администратор может потерять доступ к сайту.
Типичная ошибка: зацикливание редиректов при смешанном содержимом.
Решение: проверить, что сервер отдаёт заголовки Strict-Transport-Security, а все ссылки в базе данных обновлены до https.
Как защитить файл wp-config.php от несанкционированного доступа?
Самый простой способ - изменить права доступа:
# В командной строке на сервере
chmod 600 wp-config.php
chown www-data:www-data wp-config.php
Также можно переместить файл на уровень выше корня сайта, WordPress автоматически ищет файл в родительской директории.
// Если wp-config.php находится на один уровень выше публичной папки,
// никаких изменений в коде не требуется.
Дополнительная защита через .htaccess (если сервер Apache):
<Files wp-config.php>
order allow,deny
deny from all
</Files>
Расширенные примеры использования wp-config.php
Ниже приведены более сложные сценарии с детальным кодом и выводом результатов.
1. Настройка отладки с полным логированием и трассировкой запросов к БД
// Включаем отладку, лог в файл, отображаем на экране только в админке
define('WP_DEBUG', true);
define('WP_DEBUG_LOG', true);
define('WP_DEBUG_DISPLAY', true);
@ini_set('display_errors', 1);
// Собираем все SQL-запросы
define('SAVEQUERIES', true);
// Записываем время выполнения запросов
define('SCRIPT_DEBUG', true);
// Дополнительно: отключаем кэширование объектов для точной отладки
define('WP_OBJECT_CACHE_DROPIN', false);
Результат: в файл wp-content/debug.log попадают все ошибки и предупреждения PHP, а также медленные запросы SQL. Администратор может вывести массив запросов в подвале сайта:
// Пример вывода в теме или плагине
global $wpdb;
if (!empty($wpdb->queries)) {
echo '<pre>'; print_r($wpdb->queries); echo '</pre>';
}
Результат (сокращённо):
Array
(
[0] => Array
(
[0] => SELECT * FROM wp_options WHERE option_name = 'siteurl'
[1] => 0.002
[2] => require('wp-includes/plugin.php'), ...
)
...
)
Важно: никогда не оставляйте SAVEQUERIES включённым на production - это сильно снижает производительность.
2. Настройка мультисайта с поддоменами и дополнительными константами для сансетинга
define('WP_ALLOW_MULTISITE', true);
// После установки сети добавляем:
define('MULTISITE', true);
define('SUBDOMAIN_INSTALL', true);
define('DOMAIN_CURRENT_SITE', 'example.com');
define('PATH_CURRENT_SITE', '/');
define('SITE_ID_CURRENT_SITE', 1);
define('BLOG_ID_CURRENT_SITE', 1);
// Разрешаем использовать только поддомены определённого домена
define('SUNRISE', true); // включает загрузку sunrise.php для продвинутых правил
// Настраиваем куки для всех поддоменов
define('COOKIE_DOMAIN', '.example.com');
define('ADMIN_COOKIE_PATH', '/');
define('COOKIEPATH', '/');
define('SITECOOKIEPATH', '/');
Результат: при входе пользователя на site1.example.com сессия действует на всех поддоменах сети.
3. Перенос загрузок на отдельный сервер (CDN) с изменением путей
// Перемещаем папку uploads в корне сайта, но URL указываем на CDN
define('UPLOADS', 'my_uploads');
define('WP_CONTENT_DIR', dirname(__FILE__) . '/custom_content');
define('WP_CONTENT_URL', 'https://cdn.example.com/custom_content');
// Чтобы ядро не переопределяло пути, используем фильтр
define('WP_PLUGIN_DIR', WP_CONTENT_DIR . '/plugins');
define('WP_PLUGIN_URL', WP_CONTENT_URL . '/plugins');
Результат: файлы медиа загружаются по адресу вида https://cdn.example.com/custom_content/my_uploads/2025/01/image.jpg. Необходимо настроить репликацию загружаемых файлов на CDN.
4. Использование собственных таблиц для пользовательских данных
Иногда требуется хранить данные пользователей в отдельных таблицах, например, при миграции с другой системы.
define('CUSTOM_USER_TABLE', 'my_users');
define('CUSTOM_USER_META_TABLE', 'my_usermeta');
Результат: WordPress будет извлекать пользователей и их мета-данные из указанных таблиц, а не из стандартных wp_users и wp_usermeta. Перед использованием убедитесь, что структура таблиц совпадает.
5. Полное отключение cron и запуск через системный планировщик
// Отключаем встроенный планировщик WP-Cron
define('DISABLE_WP_CRON', true);
Затем в crontab сервера добавляем команду:
* * * * * wget -q -O - https://example.com/wp-cron.php?doing_wp_cron >/dev/null 2>&1
Результат: задания выполняются по реальному времени, не нагружая посетителя.