Ошибка пароля в wp config

Темы

  • Настройка параметров базы данных
    • Стандартный wp-config-sample.php
      • Изменение имени базы данных
      • Изменение пользователя базы данных
      • Изменение пароля базы данных
      • Изменение хоста базы данных
      • Альтернативный порт MySQL
      • Сокеты или конвееры MySQL
      • Возможные значения DB_HOST
    • Кодировка базы
    • Сопоставление базы данных
    • Ключи безопасности
  • Расширенные настройки
    • table_prefix
    • WP_SITEURL
    • Адрес сайта (URL)
    • Перемещение каталога wp-content
    • Перемещение каталога плагинов
    • Перемещение каталога тем
    • Перемещение каталога загрузок
    • Изменить интервал автосохранения
    • Редакции записей
      • Отключить редакции записей
      • Укажите количество редакций записи
    • Установить домен для cookie
    • Установка сети (Мультисайт)
    • Редирект несуществующих блогов
    • WP_DISABLE_FATAL_ERROR_HANDLER
    • WP_DEBUG
    • SCRIPT_DEBUG
    • Отключить объединение Javascript
    • Настройка журналирования ошибок
    • Увеличение памяти, выделенной PHP
    • Кэш
    • Настраиваемые таблицы User и Usermeta
    • Язык и папка языковых файлов
      • WordPress v3.9.6 и ниже
    • Сохранение запросов SQL для анализа
    • Отмена разрешений для файлов по умолчанию
    • Константы обновления WordPress
      • Включение доступа к обновлению по SSH
    • Альтернативный Cron
    • Отключить Cron и Cron Timeout
    • Дополнительные определяемые константы
    • Очистить корзину
    • Автоматическая оптимизация базы данных
    • DO_NOT_UPGRADE_GLOBAL_TABLES
    • Просмотр всех определенных констант
    • Отключение редактора плагинов и тем
    • Отключить обновление и установку плагинов и тем
    • Требовать SSL для администратора и входа в систему
    • Блокировать внешние URL-запросы
    • Отключить автообновления WordPress
    • Отключить обновления ядра WordPress
    • Очистка при редактировании изображений
  • Дважды проверьте перед сохранением

Один из самых важных файлов в вашей установке 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 по умолчанию.

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

  • Райан Борен — SSL и файлы cookie в WordPress 2.6
  • Объяснение взлома паролей из Википедии
  • Лорель ВанФоссен — Защитите свой блог надежным паролем
  • Instructables — Советы по безопасному паролю
  • Huffington Post — 17 советов, которые вы можете сделать сегодня, чтобы защитить свои пароли в Интернете

Наверх ↑

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

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

Наверх ↑

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

Домен, установленный в файлах 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!

I don’t know a lot of WordPress yet, and I’m just wondering:

Before installation you have to fill in the correct data in wp-config-sample.php but this also includes the database password. Isn’t that dangerous? I mean, can some one explain how this is protected from just reading the file and thus getting the password of your DB?

asked May 29, 2012 at 16:45

Bram Vanroy's user avatar

The «Hardening WordPress» page of the Codex contains a section on «Securing wp-config.php». It includes changing the permissions to 440 or 400. You can also move the wp-config file one directory up from the root if your server configuration allows for that.

Of course there is some danger to having a file with the password like this if someone gets access to your server, but, honestly, at that point they already are in your server.

Finally, you don’t have much of a choice. I’ve never seen an alternate means of configuring WordPress. You can lock it down as much as you can, but this is how WordPress is built, and if it were a serious security threat, they wouldn’t do it that way.

Celso Bessa's user avatar

answered May 29, 2012 at 16:53

mrwweb's user avatar

mrwwebmrwweb

10.1k5 gold badges37 silver badges73 bronze badges

4

To make a case for keeping your config file one level up from the web root (as mrwweb suggested): a few months ago, an automatic update on a production server of ours killed php but left apache running. So everyone coming to the homepage was being offered index.php as a download. In theory, anybody who knew it was a WordPress site could have requested wp-config.php, and gotten it (had it been in the web root). Of course, they’d only be able to use those DB credentials if we allowed remote MySQL connections—but still, not cool. I realize this is a fringe case, but it’s so easy to keep your config out of sight, why not do it?

answered May 30, 2012 at 2:13

MathSmath's user avatar

MathSmathMathSmath

5,5684 gold badges24 silver badges23 bronze badges

Unless someone has access via FTP, you don’t need to worry about this. PHP is rendered on the server before it hit’s the users browser.

answered May 29, 2012 at 16:51

Simon's user avatar

SimonSimon

4173 silver badges9 bronze badges

Here’s another tip: protect wp-config.php (and any other sensitive files) with .htaccess

Add the following to an .htaccess file in your site’s directory where all other WordPress files are located:

<Files wp-config.php>
order allow,deny
deny from all
</Files>

from How to harden your WordPress installation

answered Aug 16, 2018 at 0:27

Welcome's user avatar

If somebody has access to read the contents of your Php files, you’ve already been hacked.

answered May 30, 2012 at 1:07

Otto's user avatar

OttoOtto

32.4k1 gold badge60 silver badges107 bronze badges

1

1 / 1 / 1

Регистрация: 09.12.2010

Сообщений: 34

1

14.05.2014, 01:01. Показов 5241. Ответов 4


Студворк — интернет-сервис помощи студентам

Здравствуйте. Мне необходимо установить WordPress на локал. Но столкнулся с проблемой. Заполняю пучком wp-config, перехожу на домен.лок/wp-admin/install.php — получаю ошибку:

Ошибка установки соединения с базой данных

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

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

Проверял как мог. БД работает ТОЧНО. Скорее всего ошибка при вводе данных исключена.. Что же тогда за беда?

Добавлено через 4 минуты
Возможно, необходимо указать порт? Какой указывать?



0



1957 / 796 / 89

Регистрация: 03.11.2009

Сообщений: 3,066

Записей в блоге: 2

14.05.2014, 01:26

2

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



1



1 / 1 / 1

Регистрация: 09.12.2010

Сообщений: 34

14.05.2014, 01:54

 [ТС]

3

romchiksoad, хм. Значит, всё же, в БД проблема. Попытался на внешнюю, всё нормально. В общем, это мои проблемы. Уже дальше сам, значит, разберусь.

Добавлено через 9 минут
Вот, выяснил. Это вообще на локальном БД кривляется. В чем может быть проблема? В phpAdmin заходит..



0



1957 / 796 / 89

Регистрация: 03.11.2009

Сообщений: 3,066

Записей в блоге: 2

14.05.2014, 01:58

4

Лучший ответ Сообщение было отмечено Grem как решение

Решение

Grem, как вариант Вы можете зайти в конфиг PMA и там посмотреть какие данные используются для входа.



1



1 / 1 / 1

Регистрация: 09.12.2010

Сообщений: 34

14.05.2014, 02:11

 [ТС]

5

romchiksoad, во, спасибо. Оказывается, пароль всё таки стоит. Его PMA не спрашивает при входе :/



0



Если вы занимаетесь разработкой своего сайта сначала на локальном компьютере, то при переносе на хостинг практически всегда столкнётесь с ошибкой установки соединения с базой данных, в английской версии WordPress она звучит так: Error establishing a database connection.

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

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

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

Проявляется ли проблема в wp-admin

Первым делом стоит убедиться, что данное сообщение об ошибке выводится и на сайте, и в административной панели. Для этого попробуйте зайти в админку сайта (wp-admin).

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

Если же вы получили сообщение «Одна или несколько таблиц базы данных недоступны», тогда нужно будет выполнить автоматическое исправление таблиц механизмами WordPress.

Для этого нужно выполнить следующие шаги:

  1. Открыть файл wp-config.php и добавить в него следующую строку:
    [php]define(‘WP_ALLOW_REPAIR’, true);[/php]
  2. После этого зайти по адресу http://ваш-сайт.ru/wp-admin/maint/repair.php
    Исправляем ошибку установки соединения с базой данных
  3. Нажать кнопку «Починить базу данных» и дождаться завершения операции.
    Это может занять некоторое время, в зависимости от размера данных в таблицах базы вашего сайта.

Запомните, что доступ к этой странице может получить любой пользователь вашего сайта, обратившись к ней по прямому адресу. Поэтому после исправления ошибки обязательно удалите строку WP_ALLOW_REPAIR из файла wp-config.php!

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

В ином случае рекомендую продолжить чтение заметки.

Проверка файла wp-config.php

Файл wp-config.php один из самых важных файлов в WordPress — именно в нём прописаны все параметры для нормальной работы вашего сайта. Все настройки для подключения к базе данных тоже находятся именно в этом файле.

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

За настройки подключения к базе данных MySQL отвечают следующие константы:
[php]define(‘DB_NAME’, ‘название базы данных’);
define(‘DB_USER’, ‘пользователь базы данных’);
define(‘DB_PASSWORD’, ‘пароль пользователя’);
define(‘DB_HOST’, ‘localhost’);[/php]

Имейте в виду, что в константе DB_HOST не всегда будет значение localhost, это может быть и IP адрес сервера, либо же какой-то другой адрес, если вы используете хостинг от МастерХост, например. В любом случае, эту информацию вам нужно уточнить у вашего хостинг-провайдера, либо в личном кабинете вашего хостинга.

Но для большинства хостингов значение DB_HOST будет всё-таки localhost и чаще всего изменять его не придётся.

Стоит упомянуть, что в некоторых случаях вам нужно будет указать нестандартный порт для подключения к MySQL, это делается следующей командой в файле wp-config.php:
[php]define(‘DB_HOST’, ‘127.0.0.1:3351’);[/php]
, где 3351 — порт, на котором «прослушивается» MySQL-сервер. Уточните это значение у вашего системного администратора.

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

Проверка работоспособности MySQL сервера

Если ваш хостинг-провайдер позволяет использовать скрипт phpMyAdmin — попробуйте воспользоваться им. Для этого зайти на ваш аккаунт, найдите пункт в меню с упоминанием базы данных и возле него будет ссылка на phpMyAdmin.

Если у вас виртуальный сервер (VPS) и вы используете cPanel или ISPManager, то ссылка на phpMyAdmin будет на главной странице панели управления сервером.

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

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

  1. Создаёте на компьютере файл, назовём его test.php и добавляем в него следующий код:
    [php]<?php
    $resource = mysql_connect(‘localhost’, ‘пользователь’, ‘пароль’);
    if (!$resource) {
    die(‘Ошибка при подключении: ‘ . mysql_error());
    }
    echo ‘Подключено успешно!’;
    mysql_close($resource);[/php]
    Вместо «пользователь» и «пароль» укажите свои данные для подключения к базе данных. Если у вас VPS — можете использовать учётную запись root.
  2. Загружайте этот файл на FTP вашего хостинга
  3. Открывайте в браузере адрес http://ваш-сайт.ru/test.php
  4. Если на экране отразилось «Ошибка при подключении», то рядом с ней будет выведено сообщение (чаще на английском), по которой в Google или Яндекс можно найти какие-то комментарии
  5. Если же отобразилось «Подключено успешно», тогда внесите используемые ваши логин и пароль для подключения к базе данных в файл wp-config.php, как в позапрошлом шаге

Если при открытии этого скрипта вы получили сообщение: #1045 – Access denied for user ‘foo’@’%’ (using password: YES), это значит вы используете неправильный логин или пароль. Проверьте ещё раз и попробуйте снова.

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

Решения, которые помогли другим

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

Обновление настройки в wp_options

Некоторым пользователям помогало выполнение следующего запроса к базе данных через phpMyAdmin:
[sql]UPDATE wp_options SET option_value=’адрес_вашего_сайта’ WHERE option_name=’siteurl’;[/sql]

Вместо «адрес_вашего_сайта» укажите адрес сайта, чтобы запрос выглядел так:
[sql]UPDATE wp_options SET option_value=’http://ваш-сайт.ru’ WHERE option_name=’siteurl’;[/sql]

Имейте в виду, что таблица wp_options может называться иначе, если вы изменяли префикс таблиц WordPress. В этом случае, вместо wp_ укажите свой префикс.

Подключение под root к базе данных

Если у вас VPS и удалось подключиться с помощью файла test.php к базе данных под пользователем root — тогда попробуйте использовать эти данные для подключения к базе данных вашего сайта через wp-config.php.

Если всё пройдёт нормально и сайт заработает, тогда рекомендую зайти в phpMyAdmin, создать нового пользователя и указать логин и пароль нового пользователя в wp-config.php.

Никогда не работайте под учётной записью суперпользователя на вашем боевом сервере.

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

Если вы знаете ещё какие-то пути решения это проблемы — напишите о них в комментариях и я обновлю заметку.

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

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

6 распространенных проблем при входе в админку WordPress (и их решения)

inet.ws - Powerful VPS around the World!

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

1. Вы потеряли или забыли пароль

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

Смотрите также:

  • Как сбросить пароль для WordPress через phpMyAdmin
  • Как сбросить пароль для WordPress через MySQL

Решение:

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

Если по какой-то причине вы не можете использовать этот метод, то есть ещё два других.

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

Если и это не сработало, то можно обновить пароль прямо в базе данных WordPress. Если ваш сайт расположен на сервере Linux, то у вас, скорее всего, будет доступ к phpMyAdmin. Однако, перед тем, как редактировать вашу базу данных WordPress, создайте бэкап. И тогда выполните следующие шаги:

  • Запустите phpMyAdmin, выберите базу данных вашего сайта и откройте wp_users
  • В списке пользователей найдите свое имя в столбце user_login и выберите «Правка» напротив этой строки.
  • Найти поле user_pass и введите новый пароль в поле Value.
  • Из выпадающего меню выберите MD5.
  • Перейдите к нижней части страницы и нажмите кнопку Go.

6 распространенных проблем при входе в админку WordPress (и их решения)

inet.ws - Powerful VPS around the World!

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

1. Вы потеряли или забыли пароль

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

Смотрите также:

  • Как сбросить пароль для WordPress через phpMyAdmin
  • Как сбросить пароль для WordPress через MySQL

Решение:

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

Если по какой-то причине вы не можете использовать этот метод, то есть ещё два других.

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

Если и это не сработало, то можно обновить пароль прямо в базе данных WordPress. Если ваш сайт расположен на сервере Linux, то у вас, скорее всего, будет доступ к phpMyAdmin. Однако, перед тем, как редактировать вашу базу данных WordPress, создайте бэкап. И тогда выполните следующие шаги:

  • Запустите phpMyAdmin, выберите базу данных вашего сайта и откройте wp_users
  • В списке пользователей найдите свое имя в столбце user_login и выберите «Правка» напротив этой строки.
  • Найти поле user_pass и введите новый пароль в поле Value.
  • Из выпадающего меню выберите MD5.
  • Перейдите к нижней части страницы и нажмите кнопку Go.

6 распространенных проблем при входе в админку WordPress (и их решения)

Теперь вы можете войти, используя новый пароль, который вы только что присвоили вашему имени пользователя в WordPress с помощью phpMyAdmin. Однако, если у вас не получилось и в этот раз, то есть ещё несколько трюков.

2. Cache и Cookies

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

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

Смотрите также:

  • Ошибка 500 Internal Server Error: разбираемся и устраняем проблему
  • Устраняем белый экран смерти на WordPress

Кэш браузера обращается к временным файлам, хранящимся в вашем браузере, когда вы заходите на веб-страницу. Если кэш не обновляется вовремя, то вам отобразится старая версия сайта.

Решение:

К счастью, проблемы с кэшем и cookies обычно решаются просто. Во-первых, проверьте включены ли cookies, а потом очистите и кэш, и cookies в вашем браузере.

3. Вмешательство плагинов

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

Смотрите также:

  • Что дает сбой в работе сайта на WordPress: плагин или тема?
  • Порядок загрузки файлов WordPress темы

Решение:

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

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

Если же у вас нет доступа к админ панели, то вы можете переименовать папку плагинов. Используйте FTP клиент, найдите папку wp-content/plugins и переименуйте её.

6 распространенных проблем при входе в админку WordPress (и их решения)

WordPress не распознает папку и отключит все плагины.

После отключения плагинов попробуйте войти в систему. Если получилось, то это подтвердит, что причиной были плагины. И теперь вам предстоит выяснить, какой именно плагин причинил неудобства. Для этого просто начните включать обратно плагины по одному и проверяйте работоспособность сайта после каждого включенного плагина.

4. Проблемы с темой

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

Смотрите также:

  • ThemeCheck.org — узнайте надежность и безопасность своей WordPress-темы
  • 9 советов и подсказок при выборе новой темы оформления WordPress

Решение:

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

Для этого зайдите в папку wp-content/themes с помощью FTP клиента, найдите папку текущей темы и переименуйте её. Тогда WordPress будет вынужден вернуться к стандартной теме.

Теперь попробуйте войти в систему, чтобы проверить вашу догадку.

5. Повреждение файла wp-login.php

Если файл авторизации wp-login.php повреждён, удалён или находится не на своём месте, у вас не получится даже зайти на страницу входа в систему.

Смотрите также:

  • WordPress File Monitor — узнайте, изменялись ли файлы на вашем сайте
  • Журналы аудита — недостающий компонент в вашей стратегии безопасности WordPress

Решение:

Для проверки этой причины возникновения проблемы (и сразу её решения) вам будет нужно заменить этот файл новым.

  • Создайте бекап WordPress до того, как удалите файл wp-login.php
  • Найдите ваш wp-login.php файл с FTP клиентом и удалите его. Вы найдёте его в директории, где установили WordPress
  • Далее, загрузите последнюю версию WordPress и найдите файл wp-login.php в новых загрузках
  • Скопируйте этот файл и замените им удалённый
  • Откройте новый файл и найдите «redefining user_login»
  • Прямо под php комментарием найдите и замените код, как показано в ниже:
// Удалите эту строку
$user_login = $user_data["user_login"];
 
// Замените ее этой строкой
$user_login = $user_data->user_login;

Если причиной был файл wp-login.php, то теперь всё должно быть в порядке.

6. Перенаправление WordPress или URL сайта

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

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

Смотрите также:

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

Решение:

Есть много потенциальных вариантов решения проблемы адреса WordPress и адреса сайта URL. Но есть уловка, которая поможет понять, действительно ли проблема в этом.

После создания бэкапа вашего сайта, зайдите в файл wp-config.php с вашим FTP клиентом и добавьте следующий код:

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

Убедитесь, что используете WordPress адрес URL для WP_HOME и адрес сайта URL для WP_SITEURL. По умолчанию, оба адреса будут одинаковыми. Однако, если вы предоставите WordPress свою директорию, то WordPress адрес URL будет указывать директорию, где вы установили WordPress.

Сохраните обновлённый файл wp-config.php и загрузите изменённый файл на сервер, используя ваш FTP клиент. Если вы теперь можете войти в систему, то мы нашли проблему.

Однако, это временное решение, вам нужно будет удалить код и обновить значения WP_HOME и WP_SITEURL в базе данных сайта.

Итоги

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

Давайте быстро пробежимся по решениям проблем:

  1. Изменение пароля
  2. Очистите кэш и cookies браузера
  3. Отключите ваши плагины
  4. Вернитесь к стандартной теме
  5. Замените ваш login файл
  6. Определите URL сайта и WordPress

А вы сталкивались с проблемой входа в систему WordPress? Расскажите нам в комментариях, как вы её решили.

Источник: elegantthemes.com

Смотрите также:

inet.ws - Powerful VPS around the World!
Алексей Шевченко

Изучает сайтостроение с 2008 года. Практикующий вебмастер, специализирующий на создание сайтов на WordPress. Задать вопрос Алексею можно на https://profiles.wordpress.org/wpthemeus/

Понравилась статья? Поделить с друзьями:
  • Ошибка пароля администратора роутера xiaomi
  • Ошибка пароль не может быть сброшен
  • Ошибка пароль для яндекс не введен iphone
  • Ошибка пароль для удаления не задан либо неверен
  • Ошибка пароль для yandex не введен iphone