Редактирование wp-config.php

Темы

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

Когда вы впервые загружаете архив WordPress, файл wp-config.php в нём отсутствует. В процессе установки WordPress будет создан файл wp-config.php на основе предоставленной вами информации.

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

Внимание: содержимое файла wp-config-sample.php находится в строго определенном порядке. Порядок имеет значение. Если у вас уже есть файл wp-config.php, изменение его содержимого может привести к ошибкам в вашем блоге.

Чтобы изменить файл wp-config.php для вашей установки, вам понадобится следующая информация:

  • Database Name – Имя базы данных, используемое WordPress
  • Database Username – Имя пользователя, используемое для доступа к базе данных
  • Database Password – Пароль, используемый именем пользователя для доступа к базе данных
  • Database Host – Адрес хоста вашего сервера базы данных. Также может потребоваться номер порта, путь к файлу сокета Unix или конвееру.

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

Настройка параметров базы данных

Важно: никогда не используйте текстовый редактор, например Microsoft Word, для редактирования файлов WordPress!

Найдите файл wp-config-sample.php в базовом каталоге вашего каталога WordPress и откройте его в текстовом редакторе.

Наверх ↑

Стандартный wp-config-sample.php

Примечание. Это пример стандартного wp-config-sample.php. Значения здесь являются примерами, чтобы показать вам, что делать.

// ** MySQL settings - You can get this info from your web host ** //
/** The name of the database for WordPress */
define( 'DB_NAME', 'database_name_here' );
/** MySQL database username */
define( 'DB_USER', 'username_here' );
/** MySQL database password */
define( 'DB_PASSWORD', 'password_here' );
/** MySQL hostname */
define( 'DB_HOST', 'localhost' );

Внимание: Текст внутри /* */ являеться комментариями, только в информационных целях.

Наверх ↑

Изменение имени базы данных

Замените «database_name_here» именем своей базы данных, например MyDatabaseName.

define( 'DB_NAME', 'MyDatabaseName' ); // Example MySQL database name

Наверх ↑

Изменение пользователя базы данных

Замените «username_here» на имя вашего имени пользователя, например MyUserName.

define( 'DB_USER', 'MyUserName' ); // Example MySQL username

Наверх ↑

Изменение пароля базы данных

Замените «password_here» своим паролем, например MyPassWord.

define( 'DB_PASSWORD', 'MyPassWord' ); // Example MySQL password

Наверх ↑

Изменение хоста базы данных

Замените «localhost» именем хоста вашей базы данных, например MyDatabaseHost. Также может потребоваться номер порта или путь к файлу сокета Unix.

define( 'DB_HOST', 'MyDatabaseHost' ); // Example MySQL Database host

Примечание. Вполне вероятно, что вам НЕ придется его менять. Если вы не уверены, попробуйте установить со значением по умолчанию «localhost» и посмотрите, работает ли это. Если установка не удалась, обратитесь к своему провайдеру веб-хостинга.

Наверх ↑

Альтернативный порт MySQL

Если ваш хост использует альтернативный номер порта для вашей базы данных, вам необходимо изменить значение DB_HOST в файле wp-config.php, чтобы отразить альтернативный порт, предоставленный вашим хостом.

Для localhost:

define( 'DB_HOST', 'localhost:3307' );

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

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

Замените 3307 любым номером порта, который вам дает ваш хост.

Наверх ↑

Сокеты или конвееры MySQL

Если ваш хост использует сокеты или конвееры Unix, соответственно измените значение DB_HOST в файле wp-config.php.

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' );

Замените /var/run/mysqld/mysqld.sock информацией о сокете или конвеере, предоставленной вашим хостом.

Наверх ↑

Возможные значения DB_HOST

Разные хостинговые компании используют разные сетевые настройки для своих баз данных mysql. Обратитесь в службу технической поддержки и/или выполните поиск в документации по вашей хостинг-компании в Интернете.

Наверх ↑

Кодировка базы

DB_CHARSET был сделан доступным для обозначения набора символов базы данных (например, tis620 для TIS620 Thai), который будет использоваться при определении таблиц базы данных MySQL.

Значение по умолчанию utf8 (Unicode UTF-8) почти всегда является лучшим вариантом. UTF-8 поддерживает любой язык, поэтому вы обычно оставляете DB_CHARSET на utf8 и вместо этого используете значение DB_COLLATE для вашего языка.

В этом примере показана кодировка utf8, которая считается значением WordPress по умолчанию:

define( 'DB_CHARSET', 'utf8' );

Обычно не должно быть причин для изменения значения DB_CHARSET по умолчанию. Если вашему блогу нужен другой набор символов, прочтите, пожалуйста, «Наборы символов и сопоставления, поддерживаемые MySQL», чтобы узнать допустимые значения DB_CHARSET. ВНИМАНИЕ: Это требует обновления.

Если DB_CHARSET и DB_COLLATE не существуют в вашем файле wp-config.php, НЕ ДОБАВЛЯЙТЕ какое-либо определение в файл wp-config.php, если вы не прочитали и не поняли преобразование наборов символов базы данных. Добавление DB_CHARSET и DB_COLLATE в файл wp-config.php для существующего блога может вызвать серьезные проблемы.

Наверх ↑

Сопоставление базы данных

DB_COLLATE стал доступным для обозначения параметров cопоставления кодировки базы данных (то есть порядка кодировки набора символов). В большинстве случаев это значение следует оставить пустым (нулевым), чтобы кодировка базы данных была автоматически назначена MySQL на основе набора символов базы данных, указанного в DB_CHARSET. Примером того, когда вам может потребоваться установить «DB_COLLATE» в одно из значений UTF-8, определенных в наборах символов UTF-8 для большинства западноевропейских языков, может быть другой язык, на котором введенные вами символы не являются то же самое, что отображается. (См. также Наборы символов Unicode в Руководстве по SQL)

Значение DB_COLLATE по умолчанию WordPress:

define( 'DB_COLLATE', '' );

UTF-8 Unicode Общие параметры кодировки

define( 'DB_COLLATE', 'utf8_general_ci' );

UTF-8 Unicode турецкая кодировка

define( 'DB_COLLATE', 'utf8_turkish_ci' );

Обычно не должно быть причин для изменения значения DB_COLLATE по умолчанию. Если оставить значение пустым (null), MySQL автоматически назначит сопоставление при создании таблиц базы данных. ВНИМАНИЕ: Это требует обновления

Если DB_COLLATE и DB_CHARSET не существуют в вашем файле wp-config.php, НЕ добавляйте ни одно определение в ваш файл wp-config.php, если вы не прочитали и не поняли преобразование наборов символов базы данных. И вам может потребоваться обновление WordPress.

Наверх ↑

Ключи безопасности

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

Пример (не используйте их!):

define( 'AUTH_KEY',         't`DK%X:>xy|e-Z(BXb/f(Ur`8#~UzUQG-^_Cs_GHs5U-&Wb?pgn^p8(2@}IcnCa|' );
define( 'SECURE_AUTH_KEY',  'D&ovlU#|CvJ##uNq}bel+^MFtT&.b9{UvR]g%ixsXhGlRJ7q!h}XWdEC[BOKXssj' );
define( 'LOGGED_IN_KEY',    'MGKi8Br(&{H*~&0s;{k0<S(O:+f#WM+q|npJ-+P;RDKT:~jrmgj#/-,[hOBk!ry^' );
define( 'NONCE_KEY',        'FIsAsXJKL5ZlQo)iD-pt??eUbdc{_Cn<4!d~yqz))&B D?AwK%)+)F2aNwI|siOe' );
define( 'AUTH_SALT',        '7T-!^i!0,w)L#JK@pc2{8XE[DenYI^BVf{L:jvF,hf}zBf883td6D;Vcy8,S)-&G' );
define( 'SECURE_AUTH_SALT', 'I6`V|mDZq21-J|ihb u^q0F }F_NUcy`l,=obGtq*p#Ybe4a31R,r=|n#=]@]c #' );
define( 'LOGGED_IN_SALT',   'w<$4c$Hmd%/*]`Oom>(hdXW|0M=X={we6;Mpvtg+V.o<$|#_}qG(GaVDEsn,~*4i' );
define( 'NONCE_SALT',       'a|#h{c5|P &xWs4IZ20c2&%4!c(/uG}W:mAvy<I44`jAbup]t=]V<`}.py(wTP%%' );

Секретный ключ усложняет успешную атаку на ваш сайт, добавляя случайные элементы к паролю.

Проще говоря, секретный ключ — это пароль с элементами, которые затрудняют создание достаточного количества параметров для преодоления ваших барьеров безопасности. Пароль типа «пароль» или «тест» прост и легко взломан. Для взлома случайного длинного пароля без словарных слов, например «88a7da62429ba6ad3cb3c76a09641fc», злоумышленнику могут потребоваться миллионы часов. «Соль» используется для дальнейшего повышения надежности полученного результата.

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

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

Наверх ↑

Расширенные настройки

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

Наверх ↑

table_prefix

$table_prefix — это значение, помещаемое перед таблицами базы данных. Измените значение, если вы хотите использовать что-то другое, кроме wp_ для префикса вашей базы данных. Обычно это изменяется, если вы устанавливаете несколько сайтов WordPress в одной базе данных, как это делается с функцией работы с несколькими сайтами.

Можно сделать несколько установок в одной базе данных, если вы дадите каждой из них уникальный префикс. Помните о безопасности, если решите это сделать.

$table_prefix = 'r235_'; // Only numbers, letters, and underscores please!

Наверх ↑

WP_SITEURL

WP_SITEURL позволяет определить адрес (URL) WordPress. Определенное значение — это адрес, по которому находятся ваши файлы ядра WordPress. Он также должен включать часть http://. Не ставьте в конце косую черту «/». Установка этого значения в wp-config.php переопределяет значение таблицы wp_options для siteurl. Добавление этого может уменьшить количество обращений к базе данных при загрузке вашего сайта. Примечание: это не изменит сохраненное значение базы данных. URL вернется к старому значению базы данных, если эта строка когда-либо будет удалена из wp-config.php. Используйте константу RELOCATE, чтобы изменить значение siteurl в базе данных.

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

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

Динамически установить WP_SITEURL на основе $ _SERVER [‘HTTP_HOST’]

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

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

Динамически установить WP_SITEURL на основе $ _SERVER [‘SERVER_NAME’]

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

Наверх ↑

Адрес сайта (URL)

Подобно WP_SITEURL, WP_HOME переопределяет значение таблицы wp_options для главной, но не изменяет его в базе данных. главная — это адрес, который вы хотите, чтобы люди вводили в своем браузере, чтобы попасть в ваш сайт WordPress. Он должен включать часть http:// и не иметь косой черты «/» в конце. Добавление этого может уменьшить количество обращений к базе данных при загрузке вашего сайта.

define( ‘WP_HOME’, ‘http://example.com/wordpress’ );

Если вы используете технику, описанную в разделе «Создание собственного каталога WordPress», следуйте приведенному ниже примеру. Помните, что вы также разместите index.php в своем корневом веб-каталоге, если вы используете такую ​​настройку.

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

Динамически установить WP_HOME на основе $ _SERVER [‘HTTP_HOST’]

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

Наверх ↑

Перемещение каталога wp-content

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

Установите WP_CONTENT_DIR на полный локальный путь к этому каталогу (без косой черты в конце), например

define( 'WP_CONTENT_DIR', dirname(__FILE__) . '/blog/wp-content' );

Установите WP_CONTENT_URL на полный URL-адрес этого каталога (без косой черты в конце), например

define( 'WP_CONTENT_URL', 'http://example/blog/wp-content' );

Наверх ↑

Перемещение каталога плагинов

Установите WP_PLUGIN_DIR на полный локальный путь к этому каталогу (без косой черты), например

define( 'WP_PLUGIN_DIR', dirname(__FILE__) . '/blog/wp-content/plugins' );

Установите WP_PLUGIN_URL на полный URI этого каталога (без косой черты в конце), например

define( 'WP_PLUGIN_URL', 'http://example/blog/wp-content/plugins' );

Если у вас есть проблемы с совместимостью плагинов, установите PLUGINDIR на полный локальный путь к этому каталогу (без косой черты в конце), например

define( 'PLUGINDIR', dirname(__FILE__) . '/blog/wp-content/plugins' );

Наверх ↑

Перемещение каталога тем

Вы не можете переместить папку тем, потому что ее путь жестко задан относительно папки wp-content:

$theme_root = WP_CONTENT_DIR . '/themes'; 

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

Посмотрите, как переместить папку wp-content. Подробнее о том, как определяется папка тем, см. wp-includes/theme.php.

Наверх ↑

Перемещение каталога загрузок

Установить каталог загрузок

define( 'UPLOADS', 'blog/wp-content/uploads' );

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

Наверх ↑

Изменить интервал автосохранения

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

define( 'AUTOSAVE_INTERVAL', 160 ); // Seconds

Наверх ↑

Редакции записей

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

Наверх ↑

Отключить редакции записей

Если вы не устанавливаете это значение, WordPress по умолчанию устанавливает для WP_POST_REVISIONS значение true (разрешить редактирование сообщений). Если вы хотите отключить функцию ревизий, используйте этот параметр:

define( 'WP_POST_REVISIONS', false );

Примечание. Иногда это не работает, пока команда не будет перемещена в первую строку под комментарием начального блока в wp-config.php.

Наверх ↑

Укажите количество редакций записи

Если вы хотите указать максимальное количество редакций, которые хранит WordPress, измените false на целое число (например, 3 или 12).

define( 'WP_POST_REVISIONS', 3 );

Примечание. Иногда это не работает, пока команда не будет перемещена в первую строку под комментарием начального блока в wp-config.php.

Наверх ↑

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

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

Наверх ↑

Установка сети (Мультисайт)

WP_ALLOW_MULTISITE — это функция, позволяющая работать с несколькими сайтами. Если этот параметр отсутствует в wp-config.php, по умолчанию используется значение false.

define( 'WP_ALLOW_MULTISITE', true );

Наверх ↑

Редирект несуществующих блогов

NOBLOGREDIRECT может использоваться для перенаправления браузера, если посетитель пытается получить доступ к несуществующему поддомену или каталогу.

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

Наверх ↑

WP_DISABLE_FATAL_ERROR_HANDLER

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

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

Белые экраны и сообщения об ошибках PHP больше не отображаются для пользователей. Но в среде разработки, если вы хотите включить WP_DEBUG_DISPLAY, вы должны отключить режим восстановления, установив true в WP_DISABLE_FATAL_ERROR_HANDLER.

define( 'WP_DISABLE_FATAL_ERROR_HANDLER', true );   // 5.2 and later define( 'WP_DEBUG', true );
define( 'WP_DEBUG_DISPLAY', true ); 

Наверх ↑

WP_DEBUG

Параметр WP_DEBUG управляет отчетом о некоторых ошибках и предупреждениях и позволяет использовать настройки WP_DEBUG_DISPLAY и WP_DEBUG_LOG. Значение по умолчанию — false.

define( 'WP_DISABLE_FATAL_ERROR_HANDLER', true );   // 5.2 and later
define( 'WP_DEBUG', true );

Ошибки базы данных выводятся, только если WP_DEBUG имеет значение true. Ошибки базы данных обрабатываются классом wpdb и не зависят от настроек ошибок PHP.

Установка WP_DEBUG в значение true также повышает уровень сообщения об ошибках до E_ALL и активирует предупреждения при использовании устаревших функций или файлов; в противном случае WordPress устанавливает уровень сообщения об ошибках на E_ALL ^ ​​E_NOTICE ^ E_USER_NOTICE.

Наверх ↑

SCRIPT_DEBUG

SCRIPT_DEBUG — это связанная константа, которая заставит WordPress использовать «dev» версии скриптов и таблиц стилей в wp-includes/js, wp-includes/css, wp-admin/js, и wp-admin/css будут загружены вместо версии .min.css и .min.js. Если вы планируете модифицировать некоторые из встроенных в WordPress таблиц JavaScript или CSS, вам следует добавить следующий код в свой файл конфигурации:

define( 'SCRIPT_DEBUG', true );

Наверх ↑

Отключить объединение Javascript

Чтобы ускорить экраны администрирования, все файлы JavaScript объединяются в один URL. Если JavaScript не работает на экране администрирования, вы можете попробовать отключить эту функцию:

define( 'CONCATENATE_SCRIPTS', false );

Наверх ↑

Настройка журналирования ошибок

Настройка журнала ошибок может быть немного сложной. Прежде всего, журнал ошибок PHP по умолчанию и настройки отображения устанавливаются в файле php.ini, к которому вы можете иметь или не иметь доступа. Если вы это сделаете, они должны быть установлены на желаемые настройки для реальных страниц PHP. Настоятельно рекомендуется не публиковать сообщения об ошибках, а направлять их в журнал ошибок. Более того, журналы ошибок не должны находиться в общедоступной части вашего сервера. Пример рекомендуемых настроек ошибок php.ini:

error_reporting = 4339
display_errors = Off
display_startup_errors = Off
log_errors = On
error_log = /home/example.com/logs/php_error.log
log_errors_max_len = 1024
ignore_repeated_errors = On
ignore_repeated_source = Off
html_errors = Off

Об отчетах об ошибках 4339 Это настраиваемое значение, которое регистрирует только проблемы, влияющие на работу вашего сайта, и игнорирует такие вещи, как уведомления, которые могут даже не быть ошибками. См. В разделе Константы ошибок PHP значение каждой двоичной позиции для 1000011110011, которое является двоичным числом, равным 4339. Крайняя левая цифра 1 означает сообщение о любой E_RECOVERABLE_ERROR. Следующий 0 означает, что не следует сообщать E_STRICT (который выдается при использовании небрежного, но функционального кодирования) и так далее. Не стесняйтесь определять свой собственный номер сообщения об ошибке, который будет использоваться вместо 4339.

Очевидно, вам понадобятся другие настройки для вашей среды разработки. Если ваша разрабатываемая копия находится на том же сервере или у вас нет доступа к php.ini, вам нужно будет изменить настройки по умолчанию во время выполнения. Это вопрос личных предпочтений, предпочитаете ли вы, чтобы ошибки записывались в файл журнала, или вы предпочитаете немедленно получать уведомления о любой ошибке, или, возможно, и то и другое. Вот пример, который немедленно сообщает обо всех ошибках, которые вы можете вставить в файл wp-config.php:

@ini_set( 'log_errors', 'Off' );
@ini_set( 'display_errors', 'On' );
define( 'WP_DISABLE_FATAL_ERROR_HANDLER', true );   // 5.2 and later
define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', false );
define( 'WP_DEBUG_DISPLAY', true );

Поскольку wp-config.php загружается для каждого просмотра страницы, не загруженного из файла кеша, это отличное место для установки настроек php.ini, управляющих вашей установкой PHP. Это полезно, если у вас нет доступа к файлу php.ini или вы просто хотите изменить некоторые настройки на лету. Единственное исключение — error_reporting. Если для WP_DEBUG задано значение true, для параметра error_reporting будет установлено значение E_ALL WordPress, независимо от того, что вы пытаетесь установить в wp-config.php. Если вам действительно нужно установить для параметра error_reporting что-то еще, это нужно сделать после загрузки wp-settings.php, например, в файле плагина.

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

Вот пример, который включает PHP error_logging и записывает их в определенный файл. Если для WP_DEBUG задано значение true, ошибки также будут сохраняться в этом файле. Просто поместите это над любыми командами require_once или include.

@ini_set( 'log_errors', 'On' );
@ini_set( 'display_errors', 'Off' );
@ini_set( 'error_log', '/home/example.com/logs/php_error.log' );
/* That's all, stop editing! Happy blogging. */

Другой пример регистрации ошибок, предложенный Майком Литтлом в списке рассылки wp-hackers:

/**
 * This will log all errors notices and warnings to a file called debug.log in
 * wp-content (if Apache does not have write permission, you may need to create
 * the file first and set the appropriate permissions (i.e. use 666) )
 */
define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );
@ini_set( 'display_errors', 0 );

Усовершенствованная версия Майка Литтла из Манчестерской группы пользователей WordPress:

/**
 * This will log all errors notices and warnings to a file called debug.log in
 * wp-content only when WP_DEBUG is true. if Apache does not have write permission,
 * you may need to create the file first and set the appropriate permissions (i.e. use 666).
 */
define( 'WP_DEBUG', true ); // Or false
if ( WP_DEBUG ) {
    define( 'WP_DEBUG_LOG', true );
    define( 'WP_DEBUG_DISPLAY', false );
    @ini_set( 'display_errors', 0 );
}

Проблема в том, что в WordPress есть три (3) константы, которые выглядят так, как будто они могут делать одно и то же. Во-первых, помните, что если WP_DEBUG имеет значение false, он и две другие константы WordPress DEBUG ничего не делают. Директивы PHP, какими бы они ни были, будут иметь преимущественную силу. За исключением error_reporting, WordPress установит для него значение 4983, если WP_DEBUG определен как false. Во-вторых, даже если WP_DEBUG истинно, другие константы что-то делают, только если они тоже имеют значение true. Если для них установлено значение false, директивы PHP остаются неизменными. Например, если в вашем файле php.ini есть директива (‘display_errors’ = ‘On’); но у вас есть оператор define (‘WP_DEBUG_DISPLAY’, false); в вашем файле wp-config.php ошибки все равно будут отображаться на экране, даже если вы пытались предотвратить это, установив для WP_DEBUG_DISPLAY значение false, потому что это поведение, настроенное PHP. Вот почему очень важно установить в директивах PHP то, что вам нужно, если для какой-либо из связанных констант WP установлено значение false. На всякий случай явно установите / определите оба типа. Более подробные описания констант WP доступны в разделе «Отладка в WordPress».

Для обычной установки WordPress вы можете подумать о размещении следующего в файле wp-config.php, даже если он может быть частично избыточным:

@ini_set( 'log_errors', 'On' );
@ini_set( 'display_errors', 'Off' );
define( 'WP_DISABLE_FATAL_ERROR_HANDLER', false );   // 5.2 and later
define( 'WP_DEBUG', false );
define( 'WP_DEBUG_LOG', false );
define( 'WP_DEBUG_DISPLAY', false );

Файл журнала отладки по умолчанию — /wp-content/debug.log. Размещение журналов ошибок в общедоступных местах представляет собой угрозу безопасности. В идеале файлы журнала должны размещаться над общедоступным корневым каталогом вашего сайта. Если вы не можете этого сделать, по крайней мере, установите разрешения для файла журнала на 600 и добавьте эту запись в файл .htaccess в корневом каталоге вашей установки WordPress:

<Files debug.log>
    Order allow,deny
    Deny from all
</Files>

Это предотвращает доступ к файлу через HTTP. Вы всегда можете просмотреть файл журнала, загрузив его со своего сервера по FTP.

Наверх ↑

Увеличение памяти, выделенной PHP

Параметр WP_MEMORY_LIMIT позволяет указать максимальный объем памяти, который может использовать PHP. Эта настройка может потребоваться в случае, если вы получите сообщение, такое как «Допустимый размер памяти xxxxxx байт исчерпан».

Этот параметр увеличивает память PHP только для WordPress, а не для других приложений. По умолчанию WordPress будет пытаться увеличить память, выделенную для PHP, до 40 МБ (код находится в начале /wp-includes/default-constants.php) для одного сайта и 64 МБ для мультисайта, поэтому параметр в wp-config.php должен отражать что-то более 40 МБ или 64 МБ в зависимости от ваших настроек.

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

Примечание. Некоторые хосты не позволяют автоматически увеличивать лимит памяти PHP. В этом случае обратитесь к своему хосту, чтобы увеличить лимит памяти PHP. Кроме того, многие хосты устанавливают лимит PHP на 128 МБ.

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

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

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

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

Примечание: это должно быть указано перед включением wp-settings.php.

Наверх ↑

Кэш

Параметр WP_CACHE, если он истинен, включает сценарий wp-content/advanced-cache.php при выполнении wp-settings.php.

define( 'WP_CACHE', true );

Наверх ↑

Настраиваемые таблицы User и Usermeta

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

define( 'CUSTOM_USER_TABLE', $table_prefix.'my_users' );
define( 'CUSTOM_USER_META_TABLE', $table_prefix.'my_usermeta' );

Примечание. Даже если параметр «CUSTOM_USER_META_TABLE» установлен вручную, таблица пользовательских метаданных все равно создается для каждой базы данных с соответствующими разрешениями для каждого экземпляра. По умолчанию установщик WordPress добавит разрешения для первого пользователя (ID # 1). Вам также необходимо управлять разрешениями для каждого сайта с помощью плагина или настраиваемой функции. Если этого не сделать, вы столкнетесь с ошибками разрешений и проблемами со входом в систему.

CUSTOM_USER_TABLE проще всего использовать во время начальной установки вашего первого экземпляра WordPress. Операторы define файла wp-config.php в первом экземпляре указывают на то, где по умолчанию будут храниться данные wp_users. После первой настройки сайта копирование рабочего wp-config.php в следующий экземпляр потребует только изменения переменной $table_prefix. Не используйте адрес электронной почты, который уже используется в исходной установке. После завершения процесса установки войдите в систему с автоматически созданной учетной записью администратора и паролем. Затем продвиньте свою обычную учетную запись до уровня администратора и выйдите из системы администратора. Войдите в систему как вы, удалите учетную запись администратора и продвигайте другие учетные записи пользователей по мере необходимости.

Наверх ↑

Язык и папка языковых файлов

WordPress c версии 4.0 позволяет менять язык на экранах администрирования WordPress. Чтобы изменить язык в экране настроек администратора. Перейдите в Настройки — Общие и выберите Язык сайта.

Наверх ↑

WordPress v3.9.6 и ниже

WPLANG определяет имя файла языкового перевода (.mo). WP_LANG_DIR определяет, в каком каталоге находится файл WPLANG.mo. Если WP_LANG_DIR не определен, WordPress сначала ищет wp-content/languages, а затем wp-includes/languages ​​для .mo, определенного файлом WPLANG.

define( 'WPLANG', 'de_DE' );
define( 'WP_LANG_DIR', dirname(__FILE__) . 'wordpress/languages' );

Чтобы узнать код языка WPLANG, перейдите сюда. Код в столбце WP Local — это то, что вам нужно.

Наверх ↑

Сохранение запросов SQL для анализа

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

Сначала добавьте это в файл wp-config.php:

define( 'SAVEQUERIES', true );

Затем в подвал вашей темы поместите это:

<?php
if ( current_user_can( 'administrator' ) ) {
    global $wpdb;
    echo "<pre>";
    print_r( $wpdb->queries );
    echo "</pre>";
}
?>

Наверх ↑

Отмена разрешений для файлов по умолчанию

Операторы FS_CHMOD_DIR и FS_CHMOD_FILE позволяют переопределить права доступа к файлам по умолчанию. Эти две переменные были разработаны в ответ на проблему сбоя функции обновления ядра с хостами, работающими под suexec. Если хост использует ограничительные права доступа к файлам (например, 400) для всех пользовательских файлов и отказывается получить доступ к файлам, для которых установлены разрешения группы или общие, эти определения могут решить проблему.

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

Пример предоставления setgid:

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

Примечание. «0755» и «02755» — восьмеричные значения. Восьмеричные значения должны иметь префикс 0 и не выделяться одинарными кавычками (‘). См. Также: Изменение прав доступа к файлам

Наверх ↑

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

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

Наиболее частые причины, по которым необходимо их определить:

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

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

Следующие допустимые константы для обновлений WordPress:

  • FS_METHOD принудительно использует метод файловой системы. Это должно быть только «direct», «ssh2», «ftpext» или «ftpsockets». Как правило, вам следует изменять это только при возникновении проблем с обновлением. Если вы измените его, и это не поможет, поменять обратно/удалить. В большинстве случаев установка ftpsockets будет работать, если автоматически выбранный метод не работает..
    • (Основная настройка) “direct” принудительно устанавливает, чтобы использовать Прямые запросы ввода/вывода Файла изнутри PHP, это чревато открытием вопросов безопасности на плохо конфигурировавших серверах. Это выбирается автоматически при поддержке сервера.
    • (вторая настройка) “ssh2” должен вызвать использование SSH PHP Расширение если оно установлено
    • (третья настройка) “ftpext” заключается в принудительном использовании расширения FTP PHP для доступа к FTP и, наконец,
    • (четвертая настройка) “ftpsockets” использует класс сокетов PHP для доступа по FTP.
  • FTP_BASE — это полный путь к «корневой» (ABSPATH) папке установки WordPress.
  • FTP_CONTENT_DIR — это полный путь к папке wp-content установки WordPress.
  • FTP_PLUGIN_DIR — это полный путь к папке плагинов установки 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-соединения если поддерживается нижележащим транспортом (доступно не на всех серверах). Это для «Безопасного 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 или ввести ее в поле «Пароль» представленного поля учетных данных при установке обновлений.

Наверх ↑

Альтернативный Cron

Может возникнуть необходимость использовать альтернативный Cron с WP. Чаще всего это делается, если запланированные публикации не публикуются, как предполагалось. Этот альтернативный метод использует подход перенаправления. Браузер пользователей получает перенаправление, когда cron необходимо запустить, так что они сразу же возвращаются на сайт, в то время как cron продолжает работать в только что отключенном соединении. У этого метода есть определенные риски, поскольку он зависит от не родного сервиса для WordPress.

define( 'ALTERNATE_WP_CRON', true );

Наверх ↑

Отключить Cron и Cron Timeout

Полностью отключите cron, установив для DISABLE_WP_CRON значение true.

define( 'DISABLE_WP_CRON', true );

Установить ограничение на запуск процесса cron чаще одного раза в WP_CRON_LOCK_TIMEOUT секунд.

define( 'WP_CRON_LOCK_TIMEOUT', 60 );

Наверх ↑

Дополнительные определяемые константы

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

define( 'COOKIEPATH', preg_replace( '|https?://[^/]+|i', '', get_option( 'home' ) . '/' ) );
define( 'SITECOOKIEPATH', preg_replace( '|https?://[^/]+|i', '', get_option( 'siteurl' ) . '/' ) );
define( 'ADMIN_COOKIE_PATH', SITECOOKIEPATH . 'wp-admin' );
define( 'PLUGINS_COOKIE_PATH', preg_replace( '|https?://[^/]+|i', '', WP_PLUGIN_URL ) );
define( 'TEMPLATEPATH', get_template_directory() );
define( 'STYLESHEETPATH', get_stylesheet_directory() );

Наверх ↑

Очистить корзину

Эта константа контролирует количество дней до того, как WordPress окончательно удалит сообщения, страницы, вложения и комментарии из корзины. По умолчанию 30 дней:

define( 'EMPTY_TRASH_DAYS', 30 ); // 30 дней

Чтобы отключить корзину, установите нулевое количество дней.

define( 'EMPTY_TRASH_DAYS', 0 ); // Ноль дней

Примечание: WordPress не будет запрашивать подтверждение, когда кто-то нажимает «Удалить навсегда», используя этот параметр.

Наверх ↑

Автоматическая оптимизация базы данных

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

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

 define( 'WP_ALLOW_REPAIR', true );

Скрипт можно найти по адресу {$your_site}/wp-admin/maint/repair.php.

Наверх ↑

DO_NOT_UPGRADE_GLOBAL_TABLES

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

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

  define( 'DO_NOT_UPGRADE_GLOBAL_TABLES', true );

Наверх ↑

Просмотр всех определенных констант

В PHP есть функция, которая возвращает массив всех определенных в настоящее время констант с их значениями.

 print_r( @get_defined_constants() );

Наверх ↑

Отключение редактора плагинов и тем

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

define( 'DISALLOW_FILE_EDIT', true );

Примечание. На функциональность некоторых плагинов может влиять использование current_user_can('edit_plugins') в их коде. Авторам плагинов следует избегать проверки этой возможности или, по крайней мере, проверять, установлена ​​ли эта константа, и отображать соответствующее сообщение об ошибке. Имейте в виду, что если плагин не работает, это может быть причиной.

Наверх ↑

Отключить обновление и установку плагинов и тем

Это заблокирует пользователям возможность использовать функции установки/обновления плагинов и тем из области администрирования WordPress. Установка этой константы также отключает редактор плагинов и тем (т.е. вам не нужно устанавливать DISALLOW_FILE_MODS и DISALLOW_FILE_EDIT, так как DISALLOW_FILE_MODS будет иметь тот же эффект).

define( 'DISALLOW_FILE_MODS', true );

Наверх ↑

Требовать SSL для администратора и входа в систему

Примечание. В WordPress версии 4.0 FORCE_SSL_LOGIN не рекомендуется. Пожалуйста, используйте FORCE_SSL_ADMIN

FORCE_SSL_ADMIN используется, когда вы хотите защитить логины и область администрирования, чтобы пароли и файлы cookie никогда не отправлялись в открытом виде. См. также Administration_Over_SSL для более подробной информации.

define( 'FORCE_SSL_ADMIN', true );

Наверх ↑

Блокировать внешние URL-запросы

Заблокируйте внешние URL-запросы, указав WP_HTTP_BLOCK_EXTERNAL как true, и это позволит делать запросы только localhost и вашему блогу. Константа WP_ACCESSIBLE_HOSTS позволит дополнительным хостам проходить запросы. Формат константы WP_ACCESSIBLE_HOSTS представляет собой список разрешенных имен хостов, разделенных запятыми, поддерживаются домены с подстановочными знаками, например, *.wordpress.org позволит связаться со всеми поддоменами wordpress.org.

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

Наверх ↑

Отключить автообновления WordPress

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

 define( 'AUTOMATIC_UPDATER_DISABLED', true );

Наверх ↑

Отключить обновления ядра WordPress

Самый простой способ управлять обновлениями ядра — использовать константу WP_AUTO_UPDATE_CORE:

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

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

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

Ссылка: Отключение автообновлений в WordPress 3.7

Наверх ↑

Очистка при редактировании изображений

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

 define( 'IMAGE_EDIT_OVERWRITE', true );

Наверх ↑

Дважды проверьте перед сохранением

Обязательно проверьте наличие начальных и/или конечных пробелов вокруг любого из указанных выше значений, и НЕ удаляйте одинарные кавычки!

Перед сохранением файла обязательно дважды проверьте, не удалили ли вы случайно ни одну из одинарных кавычек вокруг значений параметров. Убедитесь, что после закрывающего тега PHP в файле нет ничего. Последним в файле должно быть ?> и ничего больше. Без пробелов.

Чтобы сохранить файл, выберите File>SaveAs>wp-config.php и сохраните файл в корне установки WordPress. Загрузите файл на свой веб-сервер, и вы готовы к установке WordPress!