wp-config.php в WordPress

wp-config.php - это один из самый важных файлов в WordPress - базовый конфигурационный файл. Он находится в корневом каталоге (обычно рядом с остальными файлами и папками движка).

Этот файл содержит настройки (конфигурации) WordPress.

/** Sets up WordPress vars and included files. */
require_once ABSPATH . 'wp-settings.php';

Как создать wp-config.php

Когда вы только скачали WordPress этого файла в папке нет, но есть wp-config-sample.php - это пример того как должен выглядеть wp-config.php.

Создать файл wp-config.php можно разными способами:

• Вручную. Для этого отредактируйте файл wp-config-sample.php и сохраните его как wp-config.php.

• Через WP CLI. Для этого используйте команду wp config create.

• Автоматически. При установке WP через браузер.

  Если в корне сайта нет файла wp-config.php и вы переходите на сайт в браузере, то вы увидите такое сообщение:

  

  Нажав на кнопку Создать файл настроек вы увидите форму в которой WP попросит вас ввести данные для генерации файла wp-config.php. В частности WordPress просит ввести информацию о подключении к базе данных:

  

  Все данные введенные в эту форму будут прописаны в файле wp-config.php в этих строках:

  define('DB_NAME', 'database_name_here');
  define('DB_USER', 'username_here');
  define('DB_PASSWORD', 'password_here');
  define('DB_HOST', 'localhost');
  
  $table_prefix  = 'wp_';

Как создавать и куда сохранять файл wp-config.php, думаю понятно. Теперь перейдем к конкретным константам и переменным, которые нужно или можно указать в wp-config.php.

База данных

Настройки подключения к базе данных вы получаете при создании базы данных в панели управления сервером или их передают вам администраторы сервера, если они создают базу данных за вас.

Открыв wp-config.php в каком-нибудь текстовом редакторе (я рекомендую sublime text), вы увидите подробное описание к каждой константе:

/** Параметры MySQL: Эту информацию можно получить у вашего хостинг-провайдера */
/** Имя базы данных для WordPress */
define( 'DB_NAME', 'database_name_here' );

/** Имя пользователя MySQL */
define( 'DB_USER', 'username_here' );

/** Пароль к базе данных MySQL */
define( 'DB_PASSWORD', 'password_here' );

/** Имя сервера MySQL */
define( 'DB_HOST', 'localhost' );

/** Кодировка базы данных для создания таблиц. */
define( 'DB_CHARSET', 'utf8' );

/** Схема сопоставления. Не меняйте, если не уверены. */
define( 'DB_COLLATE', '' );

DB_NAME

Содержит название вашей базы данных.

define( 'DB_NAME', 'my_database' );

DB_USER

Содержит имя пользователя вашей базы данных.

define( 'DB_USER', 'my_db_user' );

DB_PASSWORD

Содержит пароль пользователя вашей базы данных.

define( 'DB_USER', 'my_db_user_password' );

DB_HOST

Содержит домен, по которому нужно подключаться к Базе данных.

Разные хостинг-компании используют разные настройки подключения. Чаще всего эта константа равна localhost:

define( 'DB_HOST', 'localhost' );

Порт подключения к MySQL

Если в вашем хосте используется нестандартный порт для подключения к БД, то порт можно указать так.

Для localhost:

define( 'DB_HOST', '127.0.0.1:3307' );
// or
define( 'DB_HOST', 'localhost:3307' );

Для конкретного сервера:

define( 'DB_HOST', 'mysql.example.com:3307' );

Сокет или Pipe подключения к MySQL

define( 'DB_HOST', '127.0.0.1:/var/run/mysqld/mysqld.sock' );
// or
define( 'DB_HOST', 'localhost:/var/run/mysqld/mysqld.sock' );
// or
define( 'DB_HOST', 'example.tld:/var/run/mysqld/mysqld.sock' );

DB_CHARSET

По умолчанию: utf8 (Unicode UTF-8).

Содержит название кодировки для создаваемых таблиц Базы данных.

define( 'DB_CHARSET', 'utf8' );

Практически всегда utf8 - это лучший вариант. UTF-8 поддерживает любой язык. Обычно эту настройку не трогают и иногда меняют значение DB_COLLATE, подходящую для вашего языка.

Обычно нет причин менять значение DB_CHARSET по умолчанию. Если для вашего блога требуется другой набор символов, прочтите Наборы символов поддерживаемые MySQL, для получения информации о доступных значениях DB_CHARSET.

DB_COLLATE

По умолчанию: ''.

Содержит название сравнения (collation) для создаваемых таблиц Базы данных.

define( 'DB_COLLATE', '' );

Значение DB_COLLATE было добавлено для того, чтобы можно было указать collation базы данных (порядок сортировки набора символов).

В большинстве случаев это значение следует оставлять пустым (''). В этом случае MySQL сам определит нужный collate при создании таблицы на основе набора символов указанных DB_CHARSET.

Иногда нужно установить значение DB_COLLATE в одно из значений UTF-8. Это нужно когда, например для западноевропейского языка, отображается не тот символ который был введен. (См. также раздел Наборы символов Unicode в руководстве по SQL).

Примеры:

// UTF-8 Unicode General collation
define( 'DB_COLLATE', 'utf8_general_ci' );

// UTF-8 Unicode Turkish collation
define( 'DB_COLLATE', 'utf8_turkish_ci' );

$table_prefix

По умолчанию: wp_

Переменная $table_prefix - содержит базовый префикс для всех таблиц базы данных.

$table_prefix = 'wp_';

С префиксом wp_ полные названия таблиц выглядят как: wp_posts, wp_terms и т.д.

В значении допускается только a-z0-9_: латинские буквы (в нижнем регистре), цифры и знак подчеркивания _:

Это значение меняют:

• Когда устанавливаются несколько WordPress сайтов и для всех них используется одна база данных. Так делать не рекомендуется из-за безопасности.

• Когда хотят повысить безопасность путём изменения дефолтного названия таблиц. Я не думаю, что это как-то повысит безопасность сайта.

WP_DEBUG

По умолчанию: false

Включает дебаг режим.

define( 'WP_DEBUG', true );

Подробнее про дебаг режим и другие константы для дебага читайте здесь:

• WP_DEBUG_DISPLAY
• WP_DEBUG_LOG
• WP_DISABLE_FATAL_ERROR_HANDLER
• SAVEQUERIES
• SCRIPT_DEBUG
• CONCATENATE_SCRIPTS

WP_ENVIRONMENT_TYPE

По умолчанию: не установлена (соответствует типу production)

Определяет тип окружения для сайта. Возможные значения:

• local
• development
• staging
• production

Пример: Установим среду локальной разработки:

define( 'WP_ENVIRONMENT_TYPE', 'local' );

Далее в коде проверить текущую среду разработки, нужно через функцию wp_get_environment_type().

Если указано неправильное значение (не из списка возможных), то wp_get_environment_type() вернет значение по умолчанию: production.

Ключи безопасности (Security Keys)

Секретные ключи защищают ваш сайт от хакерских атак, усложняя пароли и другие секретные данные.

Четыре ключа обязательны и необходимы для повышения безопасности. Четыре соли рекомендуются, но не являются обязательными, поскольку WordPress сам сгенерирует их, если они не указаны. Их стоит указать в wp-config.php для удобства, чтобы они постоянно не менялись.

Ключи должны быть длинными, случайными и сложными. Чтобы не писать их вручную, воспользуйтесь онлайн-генератором: https://api.wordpress.org/secret-key/1.1/salt/.

Ключи можно изменить в любое время, чтобы аннулировать все существующие cookies. После изменения всем пользователям придется войти в систему заново.

Пример:

define( 'AUTH_KEY',         'rC$  `h-7|=FDvevE,tesQ4h< Ic2eB(e5n]y|wY*VN6pYAXo$qT#8Zj<R5-jzUK' );
define( 'SECURE_AUTH_KEY',  'iA8r9WU-.K<8jok|pnmPopVDN?-,=M&WfXK M+MB04M/qs<C`p0Ex}->{Ey|fhq8' );
define( 'LOGGED_IN_KEY',    ',HP.N3pL}D7M_b~1G6B|R:5Y=XgD(x oA|>:7Ex-q(y.m8!~,/&(wV.bF+3p_Hp+' );
define( 'NONCE_KEY',        'Ffv*n?P2J~8r0_)dHhK-n&oL1FKR;9t5sDL$|@#,HfwjMq~U{+d!;o58^~VxlbY!' );
define( 'AUTH_SALT',        'lrs5bgbq~7i3u1-ytlcnp6AqoFfoC20{kehs/]Np0OcV^%@Fm2,aL/@/c ]V^H92' );
define( 'SECURE_AUTH_SALT', '}[h&,wa,#YMk<$|j[pmUp`f5{A _|R?c]ewc-{a1_Xym9])y:G:.d;xkxUt0CBSI' );
define( 'LOGGED_IN_SALT',   '#r]cdwnTHqkM8+_;_]$pEabgA5CzmtEWoLz1XN~.[zOObbA58k-wIpcagvRh<D?-' );
define( 'NONCE_SALT',       '0?ToX=[EP%,p_5+xO=/K,|R)SCrD*LOf^%G(</%V>A@YFF6)N+[a&7-u+e92):cs' );

Более подробную информацию о технической стороне и разборе секретных ключей и безопасных паролей:

• Ryan Boren - SSL and Cookies in WordPress 2.6

• Объяснение взлома паролей в Википедии

• Lorelle VanFossen - Protect Your Blog With a Solid Password

• Instructables - Security Password Tips

• Huffington Post - 17 советов, которые вы можете сделать сегодня, чтобы защитить свои пароли в Интернете

Заметки

• Файл wp-config.php можно перемещать на одну директорию выше. Т.е. если файл находится в каталоге /public_html/wordpress/wp-config.php его можно переместить в каталог /public_html/wp-config.php при этом все будет работать как работало.

Остальные настройки

WP_SITEURL и WP_HOME

WP_SITEURL и WP_HOME переопределяют значение опции siteurl и home в таблице wp_options соответственно. Но они не изменяют эти значения в базе данных.

• siteurl - это URL адрес, по которому находятся ядро WordPress.
• home - это URL сайта (фронт-энд).

Обе эти константы должны начинаться с http:// и НЕ должны содержать / в конце.

define( 'WP_SITEURL', 'http://example.com' );
define( 'WP_HOME', 'http://example.com' );

define( 'RELOCATE', true );

Если WordPress установлен в директорию с именем "wp" для домена example.com, определите WP_SITEURL следующим образом:

define( 'WP_SITEURL', 'http://example.com/wp' );
define( 'WP_HOME', 'http://example.com' );

Динамическая установка на основе $_SERVER['HTTP_HOST']:

define( 'WP_SITEURL', 'https://' . $_SERVER['HTTP_HOST'] . '/path/to/wordpress' );
define( 'WP_HOME', 'https://' . $_SERVER['HTTP_HOST'] );

Примечание: HTTP_HOST создается PHP динамически на основе данных из запроса, что может привести к возникновению уязвимостей, связанных с включением файлов. SERVER_NAME также может создаваться динамически. Однако, когда Apache сконфигурирован как UseCanonicalName=on, SERVER_NAME задается конфигурацией сервера, а не динамически. В этом случае безопаснее использовать SERVER_NAME, а не HTTP_HOST.

define( 'WP_SITEURL', 'http://' . $_SERVER['SERVER_NAME'] . '/path/to/wordpress' );
define( 'WP_HOME', 'http://' . $_SERVER['SERVER_NAME'] );

Не всегда можно использовать $_SERVER['SERVER_NAME'] вместо $_SERVER['HTTP_HOST']. Подробнее: https://stackoverflow.com/questions/1459739/php-serverhttp-host-vs-serverserver-name-am-i-understanding-the-ma

WP_CONTENT_DIR и WP_CONTENT_URL

Вы можете переместить каталог wp-content, в котором хранятся темы, плагины и загружаемые файлы, за пределы каталога WordPress.

Задайте в WP_CONTENT_DIR полный путь, а для WP_CONTENT_URL адрес к папке wp-content. Слэша на конце быть не должно:

define( 'WP_CONTENT_DIR', __DIR__ . '/blog/wp-content' );
define( 'WP_CONTENT_URL', 'http://example.com/blog/wp-content' );

AUTOSAVE_INTERVAL

По умолчанию: 60 (секунд).

При редактировании постов WordPress использует Ajax для автоматического сохранения изменений. Вы можете увеличить или уменьшить время задержек между авто-сохранениями.

Изменим интервал сохранения на 120 секунд (каждые 2 минуты):

define( 'AUTOSAVE_INTERVAL', 120 );

WP_POST_REVISIONS

По умолчанию: true

По умолчанию WordPress сохраняет копии всех правок, внесенных в посты (правка сохраняется когда вы сохраняете изменения). Это позволяет вернуться к предыдущей версии поста. Сохранение правок можно отключить или задать максимальное количество (сколько максимум правок должно сохраняться).

Если константа не установлена, то по умолчанию она будет равна true - ревизии включены.

Чтобы полностью отключить ревизии укажите false:

define( 'WP_POST_REVISIONS', false );

Чтобы ограничить максимальное кол-во хранимых ревизий, замените false на число (например, 5 или 10):

define( 'WP_POST_REVISIONS', 5 );

EMPTY_TRASH_DAYS

По умолчанию: 30

Отвечает за корзину WordPress. Эта константа определяет количество дней, после которых посты, страницы, вложения и комментарии будут безвозвратно удалены из корзины.

Удаляться из корзины будут не все посты, а только те, у которых с момента перемещения их в корзину прошло больше указанного времени.

Укажем, чтобы корзина хранила объекты 7 дней:

define( 'EMPTY_TRASH_DAYS', 7 ); // 7 days

Отключим корзину:

define( 'EMPTY_TRASH_DAYS', 0 ); // Zero days

DISALLOW_FILE_EDIT

По умолчанию: не установлена

Позволяет отключить редактор файлов плагинов или тем.

define( 'DISALLOW_FILE_EDIT', true );

Такое отключение может пригодится, чтобы предотвратить возможность редактирования важных файлов, так как это может привести к поломке сайта. Также, такое отключение обеспечивает дополнительный уровень безопасности, в случае получения хакером доступа к привилегированной учетной записи пользователя.

Включение этой константы форсировано отключает у всех пользователей права:

edit_files
edit_plugins
edit_themes

Смотрите список прав пользователей.

Так, например, current_user_can('edit_plugins') всегда будет возвращать false для всех юзеров. Если какой-то плагин полагается на такое право пользователя, то он может перестать правильно работать.

DISALLOW_FILE_MODS

По умолчанию: не установлена

Отключает любую возможность модифицировать сайт из админки. В частности, отключает возможность устанавливать или обновлять плагины, темы. Отключает обновление ядра и файлов перевода.

define( 'DISALLOW_FILE_MODS', true );

Включение этой константы отключит автоматические обновления всего: тем, плагинов, ядра и переводов. А также форсировано отключит у всех пользователей следующие права:

edit_files
edit_plugins
edit_themes

update_plugins
delete_plugins
install_plugins
upload_plugins
update_themes
delete_themes
install_themes
upload_themes
update_core

install_languages
update_languages

Смотрите список прав пользователей.

Если нужно отключить не все вышеуказанные права и функции, а только некоторые из них, то можно использовать хук file_mod_allowed.

AUTOMATIC_UPDATER_DISABLED

По умолчанию: не установлено

Отключает все автоматические обновления.

Могут быть причины, по которым сайт не подлежит авто-обновлению, например, пользовательские настройки или обновления, поставляемые хостом. Это также может быть сделано перед выпуском крупного релиза, чтобы дать время на тестирование в среде разработки, прежде чем разрешить обновление на рабочем сайте.

Чтобы отключить авто-обновления, добавьте такой код в wp-config.php:

define( 'AUTOMATIC_UPDATER_DISABLED', true );

Чтобы отключить только авто-обновления ядра WordPress, используйте константы:

# Отключите все обновления ядра:
define( 'WP_AUTO_UPDATE_CORE', false );

# Включите все обновления ядра, включая малые и большие:
define( 'WP_AUTO_UPDATE_CORE', true );

# Включить обновление ядра для минорных релизов (по умолчанию):
define( 'WP_AUTO_UPDATE_CORE', 'minor' );

Подробнее об авто-обновлениях читайте в статье: Авто-обновления в WordPress.

IMAGE_EDIT_OVERWRITE

По умолчанию: не установлено

По умолчанию WordPress создает новый набор изображений при каждом редактировании изображения, а при восстановлении оригинала оставляет все правки на сервере. Определение константы IMAGE_EDIT_OVERWRITE = true изменяет это поведение. Будет создается только один набор редактируемых изображений, а при восстановлении оригинала все редактируемые изображения будут удаляются с сервера.

define( 'IMAGE_EDIT_OVERWRITE', true );

ALLOW_UNFILTERED_UPLOADS

По умолчанию: не установлено

Включает работу права пользователя unfiltered_upload.

Право unfiltered_upload позволяет пользователям (ролям) загружать любые файлы, без проверки их типа.

Это право по умолчанию есть у ролей:

• Администратор.
• Супер-администратор (в режиме мультисайт).

Однако это право по умолчанию не работает (заблокировано), т.е. указанные роли не пройдут проверку if( current_user_can('unfiltered_upload') ), несмотря на наличие у них такого права.

Чтобы право unfiltered_upload начало работать как обычно, нужно «включить» константу:

define( 'ALLOW_UNFILTERED_UPLOADS', true );

WP_CACHE

По умолчанию: false

Включает подключение файла wp-content/advanced-cache.php. Этот файл будет подключатся на о-очень раннем этапе загрузки WP. Этим пользуются плагины страничного кэширования, такие как WP Super Cache, Surge.

Подробнее читайте здесь.

Включим подгрузку файла wp-content/advanced-cache.php, если он существует:

define( 'WP_CACHE', true );

WP_HTTP_BLOCK_EXTERNAL

По умолчанию: не установлено

Блокирует все внешние запросы через HTTP API.

По умолчанию HTTP API, может делать запросы на любые сайты. Если включить эту константу, то такие запросы будут разрешены только на свой домен:

define( 'WP_HTTP_BLOCK_EXTERNAL', true );

Если нужно разрешить и другие домены, то их нужно перечислить через запятую в константе WP_ACCESSIBLE_HOSTS. Тут также поддерживается знак *:

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

FORCE_SSL_ADMIN

По умолчанию: true, если в опции siteurl указан https протокол, иначе false.

Форсировано включает https протокол для входа в систему (в админку), чтобы пароли и cookies никогда не передавались в открытом виде. Подробнее см. раздел Администрирование через SSL.

Когда эта константа включена, то при попытке зайти на страницу /wp-load.php, по http протоколу, вас перенаправит на https протокол. Также https, протокол будет установлен и в других защищенных местах, например для REST запросов из админки.

Включим https протокол для администрирования:

define( 'FORCE_SSL_ADMIN', true );

WP_LANG_DIR

По умолчанию: WP_CONTENT_DIR . '/languages' или ABSPATH . WPINC . '/languages' (когда папки WP_CONTENT_DIR/languages не существует)

Позволяет указать глобальную директорию, где лежат .mo файлы переводов. См. wp_set_lang_dir().

WPLANG

Устарела с версии WordPress 4.0.

Позволяла изменять язык сайта. Сейчас это делается из админки, со страницы: Настройки > Общие.

WP_MEMORY_LIMIT и WP_MAX_MEMORY_LIMIT

По умолчанию WP_MEMORY_LIMIT: 40M и 64M (для мультисайта)
По умолчанию WP_MAX_MEMORY_LIMIT: 256M

Позволяет увеличить объем памяти для PHP процесса.

Эти настройки могут понадобиться в случае получения сообщения типа "Allowed memory size of xxxxxx bytes exhausted".

Через обе эти константы WP попытается установить PHP опцию: ini_set( 'memory_limit' ), если это позволяет сервер.

WP_MEMORY_LIMIT - устанавливает лимит для обычных запросов.
WP_MAX_MEMORY_LIMIT - устанавливает лимит для сред где нужно больше памяти, например, при обновлении ВП. ВП сам определяет где нужно больше памяти и использует эту константу в этих случаях.

По умолчанию WordPress будет пытаться увеличить память, выделенную PHP, до 40 МБ и до 64 МБ для multisite, поэтому нужно указывать значение, превышающее 40 МБ или 64 МБ.

Примеры:

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

Увеличьте память PHP до 96 МБ

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

Для выполнения задач администрирования может потребоваться больше памяти, чем для обычной работы. Находясь в области администрирования, память может быть увеличена или уменьшена по сравнению с WP_MEMORY_LIMIT путем определения WP_MAX_MEMORY_LIMIT.

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

WP_TEMP_DIR

По умолчанию: sys_get_temp_dir() или ini_get( 'upload_tmp_dir' )

Абсолютный путь к каталогу для временных файлов. Обычно туда записываются временные файлы при обновлении плагинов, тем, ядра или при загрузке файлов.

См. get_temp_dir().

FS_CHMOD_DIR и FS_CHMOD_FILE

По умолчанию FS_CHMOD_DIR: 0755 или выше, если у папки ABSPATH права выше.
По умолчанию FS_CHMOD_FILE: 0644 или выше если у файла index.php права выше.

Позволяют переопределять дефолтные права на создаваемые файлы/папки.

Эти настройки будут работать, только для папок/файлов обрабатываемых объектами файловой системы WordPress - См. WP_Filesystem(). Т.е. если вы будете использовать функции php вроде: mkdir(), copy(), то значения этих констант никак использоваться ну будут.

Значение нужно указывать в восьмеричной системе счисления, т.е. число должно начинатmся с 0: 0644, а не 644. Эти значение по итогу передаются в параметр $permissions функции chmod().

Пример установки значений с оглядкой на настройки сервера:

define( 'FS_CHMOD_DIR', ( fileperms( ABSPATH ) & 0777 | 0755 ) );
define( 'FS_CHMOD_FILE', ( fileperms( ABSPATH . 'index.php' ) & 0777 | 0644 ) );

Пример: укажем права доступа жестко - без оглядки на настройки сервера:

define( 'FS_CHMOD_DIR', 0755 );
define( 'FS_CHMOD_FILE', 0644 );

Пример: Установим максимально возможные права 755 и 644. Тут, если текущая маска для создаваемых папок/файлов на сервере меньше указанных прав, то будет взята она. Например, если по дефолту, на сервере папки создаются с правами 700, то в этом случае FS_CHMOD_DIR будет равен 700. А если на сервере папки создаются с правами 777, то FS_CHMOD_DIR будет равно 755.

define( 'FS_CHMOD_DIR', ( 0755 & ~ umask() ) );
define( 'FS_CHMOD_FILE', ( 0644 & ~ umask() ) );

Пример: установим права вместе с setgid (set group ID). Тут, результирующее значение FS_CHMOD_DIR - это модифицированное значение разрешения файловой системы, в котором для каталога установлено разрешение setgid (включен бит group execute). Это означает, что все новые файлы и каталоги, созданные внутри каталога, будут наследовать групповое право родительского каталога.

define( 'FS_CHMOD_DIR', ( 02755 & ~umask() ) );

COOKIE_DOMAIN

По умолчанию: false (текущий домен)

Позволяет изменить домен указываемый при установки COOKIE.

Пятый параметр функции setcookie():

(Под)домен, которому доступны cookie. Задание поддомена (например, 'www.example.com') сделает cookie доступными в нем и во всех его подменах (например, w2.www.example.com). Для того, чтобы сделать cookie доступными для всего домена (включая поддомены), нужно просто указать имя домена (то есть 'example.com').

Старые браузеры, следующие устаревшему документу » RFC 2109, могут требовать . перед доменом, чтобы включались все поддомены.

Указывать эту константу нужно, когда у вас необычная настройка домена. Например, если для обслуживания статического содержимого используются под-домены, можно установить в качестве домена cookie только ваш нестатический домен, чтобы предотвратить отправку файлов cookie WordPress при каждом запросе к статическому содержимому на вашем под-домене.

define( 'COOKIE_DOMAIN', 'example.com' );

UPLOADS

По умолчанию: не установлена

Позволяет переместить папку /wp-content/uploads.

Константа используется в функции _wp_upload_dir().

Применяется для определения пути и УРЛ до папки загрузок.

Должна содержать путь, относительно константы ABSPATH и УРЛ относительно опции siteurl (или константы WP_SITEURL).

Не должна содержать слэш / в начале и конце!

Пример, вынесем папку загрузок в корневой каталог files, т.е. УРЛ будет таким https://example.com/files:

define( 'UPLOADS', 'files' );

WP_PLUGIN_DIR и WP_PLUGIN_URL

По умолчанию WP_PLUGIN_DIR: WP_CONTENT_DIR . '/plugins'
По умолчанию WP_PLUGIN_URL: WP_CONTENT_URL . '/plugins'

Позволяет переместить папку плагинов. Не должно содержать слэш / на конце!

Пример: переместим папку плагинов в другое место:

define( 'WP_PLUGIN_DIR', __DIR__ . '/wp-plugins' );
define( 'WP_PLUGIN_URL', 'http://example.com/wp-plugins' );

define( 'PLUGINDIR', WP_PLUGIN_DIR );

WPMU_PLUGIN_DIR и WPMU_PLUGIN_URL

По умолчанию WPMU_PLUGIN_DIR: WP_CONTENT_DIR . '/mu-plugins'
По умолчанию WPMU_PLUGIN_URL: WP_CONTENT_URL . '/mu-plugins'

Позволяет переместить папку обязательных плагинов.

Не должно содержать слэш / на конце!

Пример: переместим папку мю-плагинов в другое место:

define( 'WPMU_PLUGIN_DIR', __DIR__ . '/force-plugins' );
define( 'WPMU_PLUGIN_URL', 'http://example.com/force-plugins' );

define( 'MUPLUGINDIR', WPMU_PLUGIN_DIR );

Перемещение папки тем (themes)

Переместить папку themes невозможно, поскольку ее путь жестко задан относительно папки wp-content:

$theme_root = WP_CONTENT_DIR . '/themes';

Однако вы можете зарегистрировать дополнительные каталоги тем с помощью функции register_theme_directory().

WP Cron

Подробно о том как работает WP Cron и как его настраивать смотрите в отдельной статье.

Ниже приведу константы связанные с кроном.

Включим альтернативный метод запуска крон задач:

Браузер пользователя получает перенаправление от PHP, когда необходимо запустить cron. Таким образом, он сразу же возвращается на сайт, в то время как cron продолжает работать. Этот метод имеет определенные риски, поскольку зависит от неродного сервиса WordPress.

define( 'ALTERNATE_WP_CRON', true );

Полное отключение Сron

define( 'DISABLE_WP_CRON', true );

Ограничение повторного запуска Cron

Установим минимальный лимит времени (в секундах) между запусками Cron процессов:

define( 'WP_CRON_LOCK_TIMEOUT', 60 );

WP_ALLOW_REPAIR

По умолчанию: не установлено

Включает поддержку автоматического восстановления базы данных:

define( 'WP_ALLOW_REPAIR', true );

После установки этой константы перейдите по ссылке:

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

CUSTOM_USER_TABLE и CUSTOM_USER_META_TABLE

Позволяют переопределить названия таблиц где хранятся данные пользователей. В этом случае дефолтные таблицы пользователей использоваться не будут, а будут вместо них использоваться таблицы указанные в этих константах.

define( 'CUSTOM_USER_TABLE', 'myprefix_users' );
define( 'CUSTOM_USER_META_TABLE', 'myprefix_usermeta' );

Такой трюк позволяет устанавливать разные WP сайты в одну базу данных и при этом у всех сайтов будут одни и те же пользователи.

Однако, в дополнении к этим константам нужно также учесть и другие моменты. Например, у всех сайтов должны быть одинаковые секретные ключи.

Подробнее про все условия смотрите в этом видео:

Шаги такие:

• Устанавливаете первый сайт как обычно.
• После установки, добавляете в wp-config.php эти константы. Префикс таблиц нужно захардкодить.
• Создаете второй сайт и копируете в него wp-config.php из первого сайта. И измените $table_prefix для второго сайта. При этом префикс для таблиц пользователя должен остаться такой какой был при первой установке (захардкоженный).
• Установите второй сайт. В этом случае вам не будет предложено ввести данные пользователя.
• После установки, при попытке войти в админку вы увидите ошибку, что у вас недостаточно прав. Это потому что в таблице wp_usermeta есть опция wp_capabilities где префикс должен совпадать с текущим префиксом $table_prefix. Но у второй установки префикс другой, поэтому для второй установки как бы нету этой опции. Решить эту проблему поможет плагин: WP-Orphanage Extended.

FS_METHOD - Константы обновления WordPress

Примечание: Определите столько констант, сколько необходимо для устранения проблем с обновлением.

Наиболее распространенными причинами необходимости определить следующие константы являются:

• Работа хоста со специальной установкой, включающей симлинки. Может потребоваться определение констант, связанных с путями (FTP_BASE, FTP_CONTENT_DIR и FTP_PLUGIN_DIR). Часто достаточно определить просто базу.

• Некоторые версии PHP поставляются с расширением PHP FTP, которое несовместимо с некоторыми FTP-серверами. В этих редких ситуациях может потребоваться определить FS_METHOD как "ftpsockets".

Ниже приведены допустимые константы для обновлений WordPress:

• FS_METHOD определяет метод работы с файловой системой. Может быть только: "direct", "ssh2", "ftpext" или "ftpsockets". Как правило, этот параметр следует изменять только в случае проблем с обновлением. Если вы изменили этот параметр и он не помог, верните его обратно или удалите.

  • (1-е предпочтение) direct - PHP работает с файловой системой напрямую. Это чревато проблемы безопасности на плохо настроенных серверах. Выбирается автоматически по возможности.
  • (2-е предпочтение) ssh2 - использует SSH PHP-расширение, если оно установлено.
  • (3-е предпочтение) ftpext - принудительное использование расширения FTP PHP для доступа к FTP.
  • (4-е предпочтение) ftpsockets - использует класс PHP Sockets для доступа к FTP.

• FTP_BASE - полный путь к папке установки WordPress (ABSPATH).

• FTP_CONTENT_DIR - полный путь к папке wp-content.

• FTP_PLUGIN_DIR - полный путь к папке plugins в инсталляции WordPress.

• FTP_PUBKEY - полный путь к вашему открытому ключу SSH.

• FTP_PRIKEY - полный путь к вашему закрытому ключу SSH.

• FTP_USER является либо именем пользователя FTP, либо именем пользователя SSH. Скорее всего, они одинаковы, но используйте подходящее для того типа обновления, который вы хотите выполнить.

• FTP_PASS пароль для имени пользователя, введенного в поле FTP_USER. Если вы используете аутентификацию с открытым ключом SSH, этот параметр можно не указывать.

• FTP_HOST - комбинация имя хост:порт для вашего SSH/FTP-сервера. По умолчанию FTP-порт равен 21, а SSH-порт - 22. Указывать их не обязательно.

• FTP_SSL - TRUE для SSL-соединения, если оно поддерживается базовым транспортом (доступно не на всех серверах). Это относится к "Secure FTP", а не к SSH SFTP.

Пример значений констант:

define( 'FS_METHOD', 'ftpext' );
define( 'FTP_BASE', '/path/to/wordpress/' );
define( 'FTP_CONTENT_DIR', '/path/to/wordpress/wp-content/' );
define( 'FTP_PLUGIN_DIR ', '/path/to/wordpress/wp-content/plugins/' );
define( 'FTP_PUBKEY', '/home/username/.ssh/id_rsa.pub' );
define( 'FTP_PRIKEY', '/home/username/.ssh/id_rsa' );
define( 'FTP_USER', 'username' );
define( 'FTP_PASS', 'password' );
define( 'FTP_HOST', 'ftp.example.org' );
define( 'FTP_SSL', false );

В некоторых конфигурациях для параметра FTP_HOST следует установить значение localhost, чтобы избежать проблем с 503 ошибкой при попытке обновления плагинов или самого WP.

Включение доступа к обновлению по SSH

Существует два способа обновления с помощью SSH2.

• Первый - использовать плагин SSH SFTP Updater Support.
• Второй - использовать встроенную программу обновления SSH2, для чего необходимо установить расширение pecl SSH2.

Для установки расширения pecl SSH2 необходимо выполнить команду, аналогичную следующей, или обратиться к своему хостинг-провайдеру для его установки:

pecl install ssh2

После установки расширения pecl ssh2 необходимо изменить конфигурацию PHP для автоматической загрузки этого расширения.

pecl поставляется в пакете pear в большинстве дистрибутивов linux.

Для установки pecl в Redhat/Fedora/CentOS:

yum -y install php-pear

Для установки pecl в Debian/Ubuntu:

apt-get install php-pear

Рекомендуется использовать закрытый ключ, не защищенный парольной фразой. Имеются многочисленные сообщения о том, что закрытые ключи, защищенные парольной фразой, работают некорректно. Если вы решили использовать закрытый ключ, защищенный парольной фразой, то при установке обновлений вам необходимо ввести парольную фразу для закрытого ключа в FTP_PASS или ввести ее в поле "Пароль" в представленном поле учетных данных.

DO_NOT_UPGRADE_GLOBAL_TABLES

По умолчанию: не установлена

Определение константы DO_NOT_UPGRADE_GLOBAL_TABLES не позволяет функции dbDelta() и функциям обновления выполнять дорогостоящие запросы к глобальным таблицам.

Сайты, имеющие большие глобальные таблицы (в частности, users и usermeta), а также сайты, имеющие общие таблицы пользователей с bbPress и другими установками WordPress, могут предотвратить изменение этих таблиц в процессе обновления, задав для параметра DO_NOT_UPGRADE_GLOBAL_TABLES значение true.

Поскольку выполнение ALTER, а также неограниченных DELETE или UPDATE может занять много времени, крупные сайты обычно хотят избежать их выполнения в процессе обновления и провести нужные обновления самостоятельно.

Кроме того, если таблицы пользователей используются совместно несколькими установками bbPress и WordPress, возможно, стоит выбрать один сайт в качестве мастера обновления.

Multisite

WP_ALLOW_MULTISITE

По умолчанию: false.

Включает multisite функциональность. Подробнее см. Установка Мультисайта.

define( 'WP_ALLOW_MULTISITE', false );

NOBLOGREDIRECT

Используется для перенаправления браузера, если посетитель пытается обратиться к несуществующему подсайту:

define( 'NOBLOGREDIRECT', 'http://example.com' );

Перенаправляем на главный сайт сети:

define( 'NOBLOGREDIRECT', '%siteurl%' );

Пример wp-config.php

Пример wp-config.php указан в файле wp-config-sample.php. Посмотрим его код:

<?php
/**
 * The base configuration for WordPress
 *
 * The wp-config.php creation script uses this file during the installation.
 * You don't have to use the website, you can copy this file to "wp-config.php"
 * and fill in the values.
 *
 * This file contains the following configurations:
 *
 * * Database settings
 * * Secret keys
 * * Database table prefix
 * * ABSPATH
 *
 * @link https://developer.wordpress.org/advanced-administration/wordpress/wp-config/
 *
 * @package WordPress
 */

// ** Database settings - You can get this info from your web host ** //
/** The name of the database for WordPress */
define( 'DB_NAME', 'database_name_here' );

/** Database username */
define( 'DB_USER', 'username_here' );

/** Database password */
define( 'DB_PASSWORD', 'password_here' );

/** Database hostname */
define( 'DB_HOST', 'localhost' );

/** Database charset to use in creating database tables. */
define( 'DB_CHARSET', 'utf8' );

/** The database collate type. Don't change this if in doubt. */
define( 'DB_COLLATE', '' );

/**#@+
 * Authentication unique keys and salts.
 *
 * Change these to different unique phrases! You can generate these using
 * the {@link https://api.wordpress.org/secret-key/1.1/salt/ WordPress.org secret-key service}.
 *
 * You can change these at any point in time to invalidate all existing cookies.
 * This will force all users to have to log in again.
 *
 * @since 2.6.0
 */
define( 'AUTH_KEY',         'put your unique phrase here' );
define( 'SECURE_AUTH_KEY',  'put your unique phrase here' );
define( 'LOGGED_IN_KEY',    'put your unique phrase here' );
define( 'NONCE_KEY',        'put your unique phrase here' );
define( 'AUTH_SALT',        'put your unique phrase here' );
define( 'SECURE_AUTH_SALT', 'put your unique phrase here' );
define( 'LOGGED_IN_SALT',   'put your unique phrase here' );
define( 'NONCE_SALT',       'put your unique phrase here' );

/**#@-*/

/**
 * WordPress database table prefix.
 *
 * You can have multiple installations in one database if you give each
 * a unique prefix. Only numbers, letters, and underscores please!
 */
$table_prefix = 'wp_';

/**
 * For developers: WordPress debugging mode.
 *
 * Change this to true to enable the display of notices during development.
 * It is strongly recommended that plugin and theme developers use WP_DEBUG
 * in their development environments.
 *
 * For information on other constants that can be used for debugging,
 * visit the documentation.
 *
 * @link https://developer.wordpress.org/advanced-administration/debug/debug-wordpress/
 */
define( 'WP_DEBUG', false );

/* Add any custom values between this line and the "stop editing" line. */



/* That's all, stop editing! Happy publishing. */

/** Absolute path to the WordPress directory. */
if ( ! defined( 'ABSPATH' ) ) {
	define( 'ABSPATH', __DIR__ . '/' );
}

/** Sets up WordPress vars and included files. */
require_once ABSPATH . 'wp-settings.php';

--

См. также: https://developer.wordpress.org/apis/wp-config-php/