Основные и продвинутые возможности конфигурации сайта с помощью wp-config.php

Раздел: Веб-разработка -> Работа с CMS

Основные подходы к конфигурации 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

Результат: задания выполняются по реальному времени, не нагружая посетителя.

Настройки WordPress (wp-config.php или settings.php) - comments

En
Wp settings php (php)