Файл wp-config.php — подробное описание настроек WordPress
Все, у кого есть свой сайт на WordPress, знают о таком файле как wp-config.php, но не все знают как правильно его настроить. 90% пользователей вписывают в него только данные для подключения к базе.
Сегодня я бы хотел вам рассказать что в этот файл можно очень много интересного прописать для безопасности вашего сайта, и не только. Поехали!
Одним из наиболее важных файлов установки WordPress является файл конфигурации. Он находится в корневом каталоге и содержит постоянные определения и инструкции PHP, которые заставляют WordPress работать так, как вы хотите.
В файле wp-config.php хранятся такие данные, как сведения о подключении к базе данных, префикс таблицы, пути к определенным каталогам и множество настроек, связанных с конкретными функциями, которые мы с вами собираемся подробно рассмотреть в этом посте.
Базовый файл wp-config.php
Когда вы впервые устанавливаете WordPress, вас просят ввести необходимую информацию, такую как сведения о базе данных и префикс таблицы. Иногда ваш хостер настроит WordPress для вас, и вам не нужно будет запускать настройку вручную. Но когда вы запускаете 5-минутную установку вручную, вам будет предложено ввести некоторые наиболее важные данные, хранящиеся в wp-config.
Вот основной файл wp-config.php:
Обычно этот файл генерируется автоматически при запуске установки, но иногда WordPress не имеет прав для записи в папку установки. В этой ситуации вы должны создать пустой файл wp-config.php, скопировать и вставить содержимое из wp-config-sample.php и установить правильные значения для всех определенных констант. Когда вы закончите, загрузите ваш файл в корневую папку и запустите установку WordPress.
Сначала приведу определения констант базы данных, которые вы должны были получить от своего хостера:
- DB_NAME
- DB_USER
- DB_PASSWORD
- DB_HOST
- DB_CHARSET
- DB_COLLATE
Следуя данным базы данных, восемь ключей безопасности сделают сайт более защищенным от хакеров. При запуске установки WordPress автоматически генерирует ключи безопасности и соли, но вы можете изменить их в любое время, добавив любую произвольную строку. Для большей безопасности рассмотрите возможность использования онлайн-генератора.
Переменная «$table_prefix» хранит префикс всех таблиц WordPress. К сожалению, любой знает его значение по умолчанию, и это может открыть базу данных WordPress для уязвимости, которую можно легко исправить, установив пользовательское значение «$table_prefix» при запуске установки.
Чтобы изменить префикс таблицы на работающем веб-сайте, необходимо выполнить несколько запросов к базе данных, а затем вручную отредактировать файл wp-config.php. Если у вас нет доступа к базе данных или вы не обладаете необходимыми знаниями для создания пользовательских запросов, вы можете установить плагин, такой как Change Table Prefix (правда он давно не обновлялся), который будет переименовывать таблицы базы данных и имена полей, а также обновлять файл конфигурации без риска.
До сих пор анализ был ограничен базовой конфигурацией. Но у нас есть много констант, которые мы можем определить, чтобы включить функции, настроить и защитить установку.
Базовая конфигурация: редактирование файловой системы
Файловая система WordPress хорошо известна пользователям и хакерам. По этой причине вы можете рассмотреть возможность изменения встроенной файловой структуры путем перемещения определенных папок в произвольных местах и установки соответствующих URL-адресов и путей в файле wp-config.
Во-первых, мы можем переместить папку содержимого, определив две константы. Первый устанавливает полный путь к каталогу:
Второй устанавливает новый URL каталога:
Мы можем переместить только папку плагинов, определив следующие константы:
Таким же образом мы можем переместить папку загрузки, установив новый путь к каталогу:
Когда закончите, расставьте папки и перезагрузите WordPress.
Невозможно переместить папку /wp-content/themes из файла wp-config, но мы можем зарегистрировать новый каталог темы в плагине или файле functions.php темы.
Возможности для разработчиков: режим отладки и сохранение запросов
Если вы разработчик (как и я), вы можете заставить WordPress отображать ошибки и предупреждения, которые помогут вам в отладке тем и плагинов. Чтобы включить режим отладки, вам просто нужно установить «WP_DEBUG» в значение «true», как показано ниже:
«WP_DEBUG» по умолчанию имеет значение «false». Если вам нужно отключить режим отладки, вы можете просто удалить определение или установить значение константы в «false».
Когда вы работаете на живом сайте, вы должны отключить режим отладки. Ошибки и предупреждения никогда не должны показываться зрителям сайта, поскольку они могут предоставить хакерам ценную информацию. Но что делать, если вам все равно придется отлаживать?
В таких ситуациях вы можете заставить WordPress вести таблицу ошибок и предупреждений в файле «debug.log», расположенном в папке /wp-content. Чтобы включить эту функцию, скопируйте и вставьте следующий код в файл wp-config.php:
Чтобы эта функция работала, сначала нужно включить режим отладки. Затем, установив «WP_DEBUG_LOG» в значение «true», мы заставляем WordPress хранить сообщения в файле «debug.log», а при определении «WP_DEBUG_DISPLAY» в «false» скрываем их с экрана. Наконец, мы устанавливаем в 0 значение переменной PHP — «display_errors» чтобы сообщения об ошибках не выводились на экран. Wp-config никогда не загружается из кеша. По этой причине это хорошее место для переопределения настроек «php.ini».
Другая константа отладки определяет версии скриптов и стилей для загрузки. Установите «SCRIPT_DEBUG» в значение «true», если вы хотите загружать несжатые версии:
Если ваша тема или плагин показывает данные, полученные из базы данных, вы можете сохранить сведения о запросе для последующего просмотра. Константа «SAVEQUERIES» заставляет WordPress хранить информацию о запросах в массиве «$wpdb->queries». Эти сведения будут напечатаны, добавив следующий код в шаблон подвала вашего сайта:
Настройки, связанные с контентом
Когда ваш сайт вырастет, вы можете захотеть уменьшить количество пост-редакций. По умолчанию WordPress автоматически сохраняет изменения каждые 60 секунд. Мы можем изменить это значение, установив пользовательский интервал в wp-config следующим образом:
Конечно, вы также можете уменьшить интервал автосохранения.
Каждый раз, когда мы сохраняем наши изменения, WordPress добавляет строку в таблицу сообщений, чтобы мы могли восстановить предыдущие версии сообщений и страниц. Это полезный функционал, который может стать проблемой, когда наш сайт станет больше. К счастью, мы можем уменьшить максимальное количество сохраняемых пост-ревизий или вообще отключить эту функцию.
Если вы хотите отключить публикацию ревизий, определите следующую константу:
Если вы хотите ограничить максимальное количество ревизий, добавьте следующую строку:
По умолчанию WordPress хранит удаленные сообщения, страницы, вложения и комментарии в течение 30 дней, а затем удаляет их навсегда. Мы можем изменить это значение с помощью следующей константы:
Мы даже можем отключить корзину, установив для нее значение 0, но учтите, что WordPress больше не позволит вам восстанавливать содержимое.
Разрешенный объем памяти
Иногда вы можете получить сообщение, подобное следующему:
Максимальный объем памяти зависит от конфигурации сервера. Если у вас нет доступа к файлу php.ini, вы можете увеличить ограничение памяти только для WordPress, установив константу «WP_MEMORY_LIMIT» в файле wp-config. По умолчанию WordPress пытается выделить 40 МБ для PHP для отдельных сайтов и 64 МБ для многосайтовой установки. Конечно, если выделенная PHP память превышает 40 МБ (или 64 МБ), WordPress примет максимальное значение.
При этом, вы можете установить пользовательское значение с помощью следующей строки:
При необходимости вы также можете установить максимальный предел памяти с помощью следующего оператора:
Автоматические обновления
Начиная с версии 3.7, WordPress поддерживает автоматические обновления для выпусков безопасности. Это важная функция, которая позволяет администраторам сайтов постоянно поддерживать безопасность своего сайта.
Вы можете отключить все автоматические обновления, определив следующую константу:
Возможно, не стоит отключать обновления безопасности, но это ваш выбор.
По умолчанию автоматические обновления не работают с основными выпусками, но вы можете включить любые основные обновления, определяя их «WP_AUTO_UPDATE_CORE» следующим образом:
Значение по умолчанию «minor»:
Дополнительная константа отключает автообновления (и любое обновление или изменение любого файла). Если вы установите «DISALLOW_FILE_MODS» в значение «true», все изменения файлов будут отключены, даже установки и обновления тем и плагинов. По этой причине его использование не рекомендуется.
Настройки безопасности
Мы можем использовать файл wp-config для повышения безопасности сайта. В дополнение к изменениям в файловой структуре, которые мы рассмотрели выше, мы можем заблокировать некоторые функции, которые могут открыть ненужные уязвимости. Прежде всего, мы можем отключить редактор файлов, представленный в панели администратора. Следующая константа скроет экран «Appearance Editor»:
Функцией безопасности является администрирование через SSL. Если вы приобрели сертификат SSL и он правильно настроен, вы можете заставить WordPress передавать данные через SSL при любом входе в систему и сеансе администратора. Используйте следующую константу:
Проверьте Кодекс, если вам нужна дополнительная информация об администрировании через SSL.
Две другие константы позволяют блокировать внешние запросы и выводить список разрешенных хостов.
В этом примере мы сначала отключили все обращения с внешних хостов, затем перечислили разрешенные хосты, разделенные запятыми (подстановочные знаки разрешены).
Другие дополнительные настройки
«WP_CACHE» — значение «true» включает скрипт wp-content/advanced-cache.php. Эта константа действует только если вы устанавливаете постоянный плагин кэширования.
«CUSTOM_USER_TABLE» и «CUSTOM_USER_META_TABLE» используются для установки пользовательских таблиц, отличных от таблиц «wp_users» и «wp_usermeta» по умолчанию. Эти константы включают полезную функцию, которая позволяет пользователям сайта получать доступ к нескольким веб-сайтам только с одной учетной записью. Чтобы эта функция работала, все установки должны совместно использовать одну и ту же базу данных.
Начиная с версии 2.9, WordPress поддерживает автоматическую оптимизацию базы данных. Благодаря этой функции, установив «WP_ALLOW_REPAIR» в значение «true», WordPress автоматически восстановит поврежденную базу данных.
WordPress создает новый набор изображений каждый раз, когда вы редактируете изображение. Если вы восстановите исходное изображение, все созданные наборы останутся на сервере. Вы можете перезаписать это поведение, установив «IMAGE_EDIT_OVERWRITE» значение в «true», чтобы при восстановлении исходного изображения все изменения были удалены с сервера.
Блокировка wp-config.php
Теперь мы знаем, почему wp-config.php является одним из наиболее важных файлов WordPress. Итак, почему мы не скрываем это от хакеров? Прежде всего, мы можем переместить wp-config на один уровень выше корневой папки WordPress (всего на один уровень). Однако этот метод немного противоречив, поэтому я бы предложил принять другие решения для защиты файла. Если ваш сайт работает на веб-сервере Apache, вы можете добавить следующие директивы в файл .htaccess:
Если сайт работает на Nginx, вы можете добавить следующую директиву в файл конфигурации:
Если ваш сайт прошел несколько миграций или вы приобрели его у кого-то другого, рекомендуется создать новый набор ключей безопасности WordPress. Эти ключи представляют собой набор случайных величин, которые улучшают шифрование информации, хранящейся в файлах «cookie» пользователя. Начиная с WordPress 2.7, было 4 разных ключа: «AUTH_KEY», «SECURE_AUTH_KEY», «LOGGED_IN_KEY» и «NONCE_KEY».
По умолчанию они генерируются случайным образом для вас. Но на самом деле WordPress имеет бесплатный инструмент, который вы можете использовать для генерации новых случайных ключей. Затем вы можете просто обновить ваши текущие ключи, которые хранятся в вашем файле wp-config.php.
И наконец, вы должны дважды проверить и убедиться, что ваши права доступа усилены в вашем файле wp-config.php. Обычно для файлов в корневом каталоге сайта WordPress устанавливается значение 644, что означает, что файлы доступны для чтения и записи для владельца файла и для чтения пользователями в группе, владеющей этим файлом, и для чтения всеми остальными. Согласно документации WordPress, разрешения для файла wp-config.php должны быть установлены на 440 или 400, чтобы другие пользователи на сервере не могли его прочитать. Вы можете легко изменить это с вашим FTP-клиентом.
Резюме
В этом посте я перечислил много констант WordPress, которые мы можем определить в файле wp-config. Некоторые из этих констант имеют общее использование, и их функции легко понять. Другие константы включают расширенные функции, которые требуют глубоких знаний WordPress и администрирования сайта.
Я перечислил наиболее распространенные функции, оставляя в стороне некоторые дополнительные функции, которые мы можем обсудить в будущих публикациях. Если вы хотите изучить функции и константы не перечисленные здесь, начните разговор в комментариях ниже, и мы углубимся в подробности.
alt=»Блог Михаила Григорьева» />
19 Сен 2017 10:09:49 | 
0 comments
Где находится конфигурационный файл подключения к базе данных в популярных CMS ?
Для разных CMS файл конфигурации имеет как правило разные имена и может находиться в разных каталогах.
Рассмотрим самые популярные CMS ниже.
В NetCat соединение с базой данных настраивается в файле vars.inc.php
В Bitrix подключение настраивается в файле /bitrix/php_interface/dbconn.php
В новых версиях Bitrix в файле /bitrix/.settings.php
В Joomla есть файл configuration.php, в котором есть строчки
В WordPress есть файл wp-config.php, в котором есть строчки
В Drupal в папке /site/default/ есть файл settings.php, в котором есть строчка
В DLE в папке /engine/data/ есть файл dbconfig.php, в котором подключение к базе прописывается в строчках
В Shop-script подключение настраивается в файле /cfg/connect.inc.php
В ShopCMS база данных подключается в файле /core/config/connect.inc.php
В WebAsyst всё немного сложнее. Там есть файл /dblist/логин.xml в котором за соединение с базой отвечают следующие параметры
а также в файле кеша /temp/scdb/.settings.логин дублируются эти же параметры
В PrestaShop подключение настраивается в файле /config/settings.inc.php
В MODx подключение настраивается в файле /manager/includes/config.inc.php
В PHPShop подключение настраивается в файле phpshop/inc/config.ini
В HostCMS конфигурационный файл размещается в modules/core/config/database.php и содержит следующие настройки
В UMI настройки подключения к БД находятся в секции [connections] файла docs/config.ini
В phpBB в файле config.php
В Amiro.CMS настройки соединения с базой данных устанавливаются в файле docs/_local/config.ini.php
На этом все, до скорых встреч. Если у Вас возникли вопросы или Вы хотите чтобы я помог Вам, то Вы всегда можете связаться со мной разными доступными способами.
Редактирование 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. Значения здесь являются примерами, чтобы показать вам, что делать.
Внимание: Текст внутри /* */ являеться комментариями, только в информационных целях.
Изменение имени базы данных
Замените «database_name_here» именем своей базы данных, например MyDatabaseName.
Изменение пользователя базы данных
Замените «username_here» на имя вашего имени пользователя, например MyUserName.
Изменение пароля базы данных
Замените «password_here» своим паролем, например MyPassWord.
Изменение хоста базы данных
Замените «localhost» именем хоста вашей базы данных, например MyDatabaseHost. Также может потребоваться номер порта или путь к файлу сокета Unix.
Примечание. Вполне вероятно, что вам НЕ придется его менять. Если вы не уверены, попробуйте установить со значением по умолчанию «localhost» и посмотрите, работает ли это. Если установка не удалась, обратитесь к своему провайдеру веб-хостинга.
Альтернативный порт MySQL
Если ваш хост использует альтернативный номер порта для вашей базы данных, вам необходимо изменить значение DB_HOST в файле wp-config.php , чтобы отразить альтернативный порт, предоставленный вашим хостом.
Для указанного сервера:
Замените 3307 любым номером порта, который вам дает ваш хост.
Сокеты или конвееры MySQL
Если ваш хост использует сокеты или конвееры Unix, соответственно измените значение DB_HOST в файле wp-config.php .
Замените /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 по умолчанию:
Обычно не должно быть причин для изменения значения 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:
UTF-8 Unicode Общие параметры кодировки
UTF-8 Unicode турецкая кодировка
Обычно не должно быть причин для изменения значения DB_COLLATE по умолчанию. Если оставить значение пустым (null), MySQL автоматически назначит сопоставление при создании таблиц базы данных. ВНИМАНИЕ: Это требует обновления
Если DB_COLLATE и DB_CHARSET не существуют в вашем файле wp-config.php , НЕ добавляйте ни одно определение в ваш файл wp-config.php , если вы не прочитали и не поняли преобразование наборов символов базы данных. И вам может потребоваться обновление WordPress.
Ключи безопасности
Вам не нужно запоминать ключи, просто сделайте их длинными, случайными и сложными — а еще лучше — используйте онлайн-генератор. Вы можете изменить их в любой момент, чтобы аннулировать все существующие файлы cookie. Это означает, что всем пользователям придется снова войти в систему.
Пример (не используйте их!):
Секретный ключ усложняет успешную атаку на ваш сайт, добавляя случайные элементы к паролю.
Проще говоря, секретный ключ — это пароль с элементами, которые затрудняют создание достаточного количества параметров для преодоления ваших барьеров безопасности. Пароль типа «пароль» или «тест» прост и легко взломан. Для взлома случайного длинного пароля без словарных слов, например «88a7da62429ba6ad3cb3c76a09641fc», злоумышленнику могут потребоваться миллионы часов. «Соль» используется для дальнейшего повышения надежности полученного результата.
Четыре ключа необходимы для повышенной безопасности. Четыре соли рекомендуются, но не требуются, потому что WordPress будет генерировать соли для вас, если они не предоставлены. Они включены в wp-config.php по умолчанию.
Дополнительные сведения о технических характеристиках и структуре секретных ключей и безопасных паролей смотрите:
Расширенные настройки
Следующие разделы могут содержать дополнительную информацию, и некоторые изменения могут привести к непредвиденным проблемам. Перед изменением этих настроек убедитесь, что вы регулярно выполняете резервное копирование и знаете, как их восстановить.
table_prefix
$table_prefix — это значение, помещаемое перед таблицами базы данных. Измените значение, если вы хотите использовать что-то другое, кроме wp_ для префикса вашей базы данных. Обычно это изменяется, если вы устанавливаете несколько сайтов WordPress в одной базе данных, как это делается с функцией работы с несколькими сайтами.
Можно сделать несколько установок в одной базе данных, если вы дадите каждой из них уникальный префикс. Помните о безопасности, если решите это сделать.
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 следующим образом:
Динамически установить WP_SITEURL на основе $ _SERVER [‘HTTP_HOST’]
Примечание. HTTP_HOST создается PHP динамически на основе значения заголовка HTTP HOST в запросе, что, возможно, допускает уязвимости включения файлов. SERVER_NAME также может быть создан динамически. Однако, когда Apache настроен как UseCanonicalName «on», SERVER_NAME устанавливается конфигурацией сервера, а не динамически. В этом случае для пользователя SERVER_NAME безопаснее, чем HTTP_HOST.
Динамически установить WP_SITEURL на основе $ _SERVER [‘SERVER_NAME’]
Адрес сайта (URL)
Подобно WP_SITEURL, WP_HOME переопределяет значение таблицы wp_options для главной, но не изменяет его в базе данных. главная — это адрес, который вы хотите, чтобы люди вводили в своем браузере, чтобы попасть в ваш сайт WordPress. Он должен включать часть http:// и не иметь косой черты «/» в конце. Добавление этого может уменьшить количество обращений к базе данных при загрузке вашего сайта.
Если вы используете технику, описанную в разделе «Создание собственного каталога WordPress», следуйте приведенному ниже примеру. Помните, что вы также разместите index.php в своем корневом веб-каталоге, если вы используете такую настройку.
Динамически установить WP_HOME на основе $ _SERVER [‘HTTP_HOST’]
Перемещение каталога wp-content
Вы можете переместить каталог wp-content , в котором хранятся ваши темы, плагины и загрузки, за пределы каталога приложений WordPress.
Установите WP_CONTENT_DIR на полный локальный путь к этому каталогу (без косой черты в конце), например
Установите WP_CONTENT_URL на полный URL-адрес этого каталога (без косой черты в конце), например
Перемещение каталога плагинов
Установите WP_PLUGIN_DIR на полный локальный путь к этому каталогу (без косой черты), например
Установите WP_PLUGIN_URL на полный URI этого каталога (без косой черты в конце), например
Если у вас есть проблемы с совместимостью плагинов, установите PLUGINDIR на полный локальный путь к этому каталогу (без косой черты в конце), например
Перемещение каталога тем
Вы не можете переместить папку тем, потому что ее путь жестко задан относительно папки wp-content :
Однако вы можете зарегистрировать дополнительные каталоги тем с помощью register_theme_directory.
Посмотрите, как переместить папку wp-content. Подробнее о том, как определяется папка тем, см. wp-includes/theme.php .
Перемещение каталога загрузок
Установить каталог загрузок
Этот путь не может быть абсолютным. Он всегда относительно ABSPATH, поэтому не требует косой черты в начале.
Изменить интервал автосохранения
При редактировании сообщения WordPress использует Ajax для автоматического сохранения изменений в публикации во время редактирования. Вы можете увеличить эту настройку, чтобы увеличить задержки между автосохранениями, или уменьшить ее, чтобы не потерять изменения. По умолчанию 60 секунд.
Редакции записей
WordPress по умолчанию сохраняет копии каждого изменения, внесенного в сообщение или страницу, что дает возможность вернуться к предыдущей версии этого сообщения или страницы. Сохранение редакций можно отключить или указать максимальное количество редакций для каждой записи или страницы.
Отключить редакции записей
Если вы не устанавливаете это значение, WordPress по умолчанию устанавливает для WP_POST_REVISIONS значение true (разрешить редактирование сообщений). Если вы хотите отключить функцию ревизий, используйте этот параметр:
Примечание. Иногда это не работает, пока команда не будет перемещена в первую строку под комментарием начального блока в wp-config.php .
Укажите количество редакций записи
Если вы хотите указать максимальное количество редакций, которые хранит WordPress, измените false на целое число (например, 3 или 12).
Примечание. Иногда это не работает, пока команда не будет перемещена в первую строку под комментарием начального блока в wp-config.php .
Установить домен для cookie
Домен, установленный в файлах cookie для WordPress, может быть указан для пользователей с необычными настройками домена. Например, если субдомены используются для обслуживания статического содержимого, вы можете установить в качестве домена cookie только ваш нестатический домен, чтобы предотвратить отправку cookie WordPress с каждым запросом к статическому содержимому на вашем субдомене.
Установка сети (Мультисайт)
WP_ALLOW_MULTISITE — это функция, позволяющая работать с несколькими сайтами. Если этот параметр отсутствует в wp-config.php , по умолчанию используется значение false.
Редирект несуществующих блогов
NOBLOGREDIRECT может использоваться для перенаправления браузера, если посетитель пытается получить доступ к несуществующему поддомену или каталогу.
WP_DISABLE_FATAL_ERROR_HANDLER
WordPress 5.2 представил режим восстановления, который отображает сообщение об ошибке вместо белого экрана, когда плагины или темы вызывают фатальную ошибку.
Сайт испытывает технические трудности. Пожалуйста, проверьте почтовый ящик администратора вашего сайта для получения инструкций.
Белые экраны и сообщения об ошибках PHP больше не отображаются для пользователей. Но в среде разработки, если вы хотите включить WP_DEBUG_DISPLAY, вы должны отключить режим восстановления, установив true в WP_DISABLE_FATAL_ERROR_HANDLER.
WP_DEBUG
Параметр WP_DEBUG управляет отчетом о некоторых ошибках и предупреждениях и позволяет использовать настройки WP_DEBUG_DISPLAY и WP_DEBUG_LOG. Значение по умолчанию — false.
Установка 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, вам следует добавить следующий код в свой файл конфигурации:
Отключить объединение Javascript
Чтобы ускорить экраны администрирования, все файлы JavaScript объединяются в один URL. Если JavaScript не работает на экране администрирования, вы можете попробовать отключить эту функцию:
Настройка журналирования ошибок
Настройка журнала ошибок может быть немного сложной. Прежде всего, журнал ошибок PHP по умолчанию и настройки отображения устанавливаются в файле php.ini, к которому вы можете иметь или не иметь доступа. Если вы это сделаете, они должны быть установлены на желаемые настройки для реальных страниц PHP. Настоятельно рекомендуется не публиковать сообщения об ошибках, а направлять их в журнал ошибок. Более того, журналы ошибок не должны находиться в общедоступной части вашего сервера. Пример рекомендуемых настроек ошибок php.ini:
Об отчетах об ошибках 4339 Это настраиваемое значение, которое регистрирует только проблемы, влияющие на работу вашего сайта, и игнорирует такие вещи, как уведомления, которые могут даже не быть ошибками. См. В разделе Константы ошибок PHP значение каждой двоичной позиции для 1000011110011, которое является двоичным числом, равным 4339. Крайняя левая цифра 1 означает сообщение о любой E_RECOVERABLE_ERROR. Следующий 0 означает, что не следует сообщать E_STRICT (который выдается при использовании небрежного, но функционального кодирования) и так далее. Не стесняйтесь определять свой собственный номер сообщения об ошибке, который будет использоваться вместо 4339.
Очевидно, вам понадобятся другие настройки для вашей среды разработки. Если ваша разрабатываемая копия находится на том же сервере или у вас нет доступа к php.ini, вам нужно будет изменить настройки по умолчанию во время выполнения. Это вопрос личных предпочтений, предпочитаете ли вы, чтобы ошибки записывались в файл журнала, или вы предпочитаете немедленно получать уведомления о любой ошибке, или, возможно, и то и другое. Вот пример, который немедленно сообщает обо всех ошибках, которые вы можете вставить в файл wp-config.php :
Поскольку 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.
Другой пример регистрации ошибок, предложенный Майком Литтлом в списке рассылки wp-hackers:
Проблема в том, что в 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, даже если он может быть частично избыточным:
Файл журнала отладки по умолчанию — /wp-content/debug.log . Размещение журналов ошибок в общедоступных местах представляет собой угрозу безопасности. В идеале файлы журнала должны размещаться над общедоступным корневым каталогом вашего сайта. Если вы не можете этого сделать, по крайней мере, установите разрешения для файла журнала на 600 и добавьте эту запись в файл .htaccess в корневом каталоге вашей установки WordPress:
Это предотвращает доступ к файлу через 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 МБ
Задачи администрирования требуют больше памяти, чем обычные операции. Находясь в области администрирования, память может быть увеличена или уменьшена с WP_MEMORY_LIMIT путем определения WP_MAX_MEMORY_LIMIT.
Примечание: это должно быть указано перед включением wp-settings.php.
Параметр WP_CACHE, если он истинен, включает сценарий wp-content/advanced-cache.php при выполнении wp-settings.php.
Настраиваемые таблицы User и Usermeta
CUSTOM_USER_TABLE и CUSTOM_USER_META_TABLE используются для обозначения того, что пользовательские и пользовательские таблицы метаданных, обычно используемые WordPress, не используются, вместо этого эти значения/таблицы используются для хранения вашей пользовательской информации.
Примечание. Даже если параметр «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.
Чтобы узнать код языка WPLANG, перейдите сюда. Код в столбце WP Local — это то, что вам нужно.
Сохранение запросов SQL для анализа
Определение SAVEQUERIES сохраняет запросы к базе данных в массив, и этот массив может быть отображен, чтобы помочь проанализировать эти запросы. В этой информации сохраняется каждый запрос, какая функция его вызвала и сколько времени потребовалось для выполнения этого запроса. Примечание. Это повлияет на производительность вашего сайта, поэтому обязательно отключите эту функцию, когда не занимаетесь отладкой.
Сначала добавьте это в файл wp-config.php:
Затем в подвал вашей темы поместите это:
Отмена разрешений для файлов по умолчанию
Операторы FS_CHMOD_DIR и FS_CHMOD_FILE позволяют переопределить права доступа к файлам по умолчанию. Эти две переменные были разработаны в ответ на проблему сбоя функции обновления ядра с хостами, работающими под suexec. Если хост использует ограничительные права доступа к файлам (например, 400) для всех пользовательских файлов и отказывается получить доступ к файлам, для которых установлены разрешения группы или общие, эти определения могут решить проблему.
Пример предоставления setgid:
Примечание. «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_HOST на localhost, чтобы избежать проблем 503 при попытке обновить плагины или сам WP.
Включение доступа к обновлению по SSH
Есть два способа обновления с использованием SSH2.
Первый — использовать плагин SSH SFTP Updater Support. Второй — использовать встроенное средство обновления SSH2, для которого необходимо установить расширение pecl SSH2.
Чтобы установить расширение pecl SSH2, вам нужно будет ввести команду, подобную следующей, или поговорить с вашим провайдером веб-хостинга, чтобы установить его:
После установки расширения pecl ssh2 вам нужно будет изменить конфигурацию PHP для автоматической загрузки этого расширения.
pecl предоставляется пакетом pear в большинстве дистрибутивов Linux. Чтобы установить pecl в Redhat/Fedora/CentOS:
Чтобы установить pecl в Debian/Ubuntu:
Рекомендуется использовать закрытый ключ, не защищенный парольной фразой. Было много сообщений о том, что закрытые ключи, защищенные парольной фразой, не работают должным образом. Если вы решите попробовать секретный ключ, защищенный парольной фразой, вам нужно будет ввести парольную фразу для секретного ключа как FTP_PASS или ввести ее в поле «Пароль» представленного поля учетных данных при установке обновлений.
Альтернативный Cron
Может возникнуть необходимость использовать альтернативный Cron с WP. Чаще всего это делается, если запланированные публикации не публикуются, как предполагалось. Этот альтернативный метод использует подход перенаправления. Браузер пользователей получает перенаправление, когда cron необходимо запустить, так что они сразу же возвращаются на сайт, в то время как cron продолжает работать в только что отключенном соединении. У этого метода есть определенные риски, поскольку он зависит от не родного сервиса для WordPress.
Отключить Cron и Cron Timeout
Полностью отключите cron, установив для DISABLE_WP_CRON значение true.
Установить ограничение на запуск процесса cron чаще одного раза в WP_CRON_LOCK_TIMEOUT секунд.
Дополнительные определяемые константы
Вот дополнительные константы, которые можно определить. Их, вероятно, не следует устанавливать, если сначала не были опробованы другие методики. Определения файлов cookie могут быть особенно полезны, если у вас необычная настройка домена.
Очистить корзину
Эта константа контролирует количество дней до того, как WordPress окончательно удалит сообщения, страницы, вложения и комментарии из корзины. По умолчанию 30 дней:
Чтобы отключить корзину, установите нулевое количество дней.
Примечание: WordPress не будет запрашивать подтверждение, когда кто-то нажимает «Удалить навсегда», используя этот параметр.
Автоматическая оптимизация базы данных
Существует поддержка автоматического восстановления базы данных, которую вы можете включить, добавив следующее определение в файл wp-config.php.
Примечание: это следует включать только при необходимости и отключать после решения проблемы. Если этот параметр включен, пользователю не нужно входить в систему для доступа к функциям, поскольку его основная цель — восстановить поврежденную базу данных, и пользователи часто не могут войти в систему, если база данных повреждена.
Скрипт можно найти по адресу <$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, вы можете захотеть, чтобы один сайт был основным при обновлениях.
Просмотр всех определенных констант
В PHP есть функция, которая возвращает массив всех определенных в настоящее время констант с их значениями.
Отключение редактора плагинов и тем
Иногда вы можете отключить плагин или редактор тем, чтобы чрезмерно усердные пользователи не могли редактировать конфиденциальные файлы и, возможно, вывести сайт из строя. Их отключение также обеспечивает дополнительный уровень безопасности, если хакер получает доступ к учетной записи с высокими привилегиями.
Примечание. На функциональность некоторых плагинов может влиять использование current_user_can(‘edit_plugins’) в их коде. Авторам плагинов следует избегать проверки этой возможности или, по крайней мере, проверять, установлена ли эта константа, и отображать соответствующее сообщение об ошибке. Имейте в виду, что если плагин не работает, это может быть причиной.
Отключить обновление и установку плагинов и тем
Это заблокирует пользователям возможность использовать функции установки/обновления плагинов и тем из области администрирования WordPress. Установка этой константы также отключает редактор плагинов и тем (т.е. вам не нужно устанавливать DISALLOW_FILE_MODS и DISALLOW_FILE_EDIT, так как DISALLOW_FILE_MODS будет иметь тот же эффект).
Требовать SSL для администратора и входа в систему
Примечание. В WordPress версии 4.0 FORCE_SSL_LOGIN не рекомендуется. Пожалуйста, используйте FORCE_SSL_ADMIN
FORCE_SSL_ADMIN используется, когда вы хотите защитить логины и область администрирования, чтобы пароли и файлы cookie никогда не отправлялись в открытом виде. См. также Administration_Over_SSL для более подробной информации.
Блокировать внешние URL-запросы
Заблокируйте внешние URL-запросы, указав WP_HTTP_BLOCK_EXTERNAL как true, и это позволит делать запросы только localhost и вашему блогу. Константа WP_ACCESSIBLE_HOSTS позволит дополнительным хостам проходить запросы. Формат константы WP_ACCESSIBLE_HOSTS представляет собой список разрешенных имен хостов, разделенных запятыми, поддерживаются домены с подстановочными знаками, например, *.wordpress.org позволит связаться со всеми поддоменами wordpress.org.
Отключить автообновления WordPress
Возможна ситуация, при которой сайт не обновляется автоматически, например настройки или обновления, предоставляемые хостом. Это также можно сделать перед основным выпуском, чтобы дать время для тестирования в среде разработки или промежуточной среде, прежде чем разрешить обновление на рабочем сайте.
Отключить обновления ядра WordPress
Самый простой способ управлять обновлениями ядра — использовать константу WP_AUTO_UPDATE_CORE:
Очистка при редактировании изображений
По умолчанию WordPress создает новый набор изображений каждый раз, когда вы редактируете изображение, а когда вы восстанавливаете оригинал, он оставляет все изменения на сервере. Определение IMAGE_EDIT_OVERWRITE как true меняет это поведение. Когда-либо создается только один набор изменений изображения, и когда вы восстанавливаете оригинал, изменения удаляются с сервера.
Дважды проверьте перед сохранением
Обязательно проверьте наличие начальных и/или конечных пробелов вокруг любого из указанных выше значений, и НЕ удаляйте одинарные кавычки!
Перед сохранением файла обязательно дважды проверьте, не удалили ли вы случайно ни одну из одинарных кавычек вокруг значений параметров. Убедитесь, что после закрывающего тега PHP в файле нет ничего. Последним в файле должно быть ?> и ничего больше. Без пробелов.
What Is a Database Host in WordPress?
Everybody knows that the database is an integral part of any WordPress website. However, many people don’t really understand how it works and what it does. Site owners are also a bit baffled when WP asks them to set a database host .
Let’s clear up some of the confusion, starting with the basics.
What Is a WordPress Database?
The database is where your website’s data is stored. Thanks to it, instead of a collection of static HTML pages with images and text , you can have an interactive website where users can sign up, leave comments, generate and manage data, search through and filter content, and a lot more.
In the database, you have anything from the posts and pages you write, through users’ personal data , to WP’s core configuration and settings .
The information in the database shouldn’t be freely accessible . That’s why, in addition to a database, you also need to create a user account . It has a username, a password, and a set of permissions governing what it’s allowed to do with the data.
WordPress uses this user account to retrieve the information and serve it to the site’s visitors. Users of ScalaHosting’s SPanel VPS services can view and manage MySQL user accounts and databases via the MySQL Databases tool in SPanel’s User Interface.
What Is a Database Table?
WordPress works with MySQL databases which organize the information in tables. During the initial installation, WP automatically creates the required tables for users, posts, comments, options, etc ., with more being added at later stages (e.g., when you install plugins ).
You can view all tables through the phpMyAdmin database management tool inside your web hosting control panel.
Tables allow for a tidier database and a quicker delivery of the requested information .
What Is an SQL Query?
WordPress and the database communicate through SQL queries . In simple terms, whenever WP needs to display a piece of information, it sends an SQL query. The MySQL server processes it and responds with the correct data.
All manner of events may trigger an SQL query . It could be a user clicking on a button, you filtering comments in the WP dashboard , or a plugin trying to alter some settings.
Traffic volumes directly affect the number of queries your server needs to process, but they’re far from the only factor. Complex WP plugins can also generate quite a few database queries and significantly affect your hardware resource usage.
What Is a Database Host?
Many people understand the roles of the database, the MySQL user, and the SQL queries . However, they still get confused when, for example, they’re setting up WordPress manually , and the installation wizard asks them for the database host .
By default, the wizard sets it to “ localhost ,” and a quick Google search reveals leaving it like this will work in most cases. However, the search engine results rarely explain what the database host actually is.
In simple terms, it’s the server hosting the database . Most website owners host the site and the database on the same server, so leaving “localhost” in the DB host field usually works.
But what if you want to put the database on another machine? Is it possible to do it? Yes, it is. However, there are certain preparations you need to take care of first.
You need to make sure MySQL on the database host is configured to receive connections from your web hosting server . If you don’t have root access to the database host, you might need some assistance with this because it involves editing MySQL’s main configuration file – /etc/mysql/my.cnf . You need to find the bind-address parameter and set it to the IP of your web hosting server. A restart of the MySQL service saves the changes.
Next, you’ll have to create the MySQL user account WP will use to connect to the database. Depending on the database host, you’ll need to do that either through the control panel or via the command-line interface. You need to make sure you set the new user account’s hostname to your web hosting server’s IP (i.e., [email protected] instead of [email protected] ).
Pay attention to the permissions the MySQL user account gets. WordPress needs the select, delete, insert, and update privileges to work correctly, and security best practices dictate that these are the privileges you’ll need to give the new user. However, if you’re configuring a fresh installation, you’ll need to grant it full permissions, at least until WP is fully set up and ready to go.
The only thing left is to configure WordPress to work with the remote database host .
If you’re installing WordPress manually, you can do that from the installation wizard. You’ll need to enter the database name , the MySQL account’s login credentials , and the database host’s IP address . WP should have no problems connecting to the database if everything is configured correctly.
If you’re using an automatic installer or re-configuring an existing WordPress installation, you’ll need to edit the wp-config.php file . The parameters you need to look for are:
- DB_NAME
- DB_USER
- DB_PASSWORD
- DB_HOST
Potential Problems With Using a Different Host for Your Database
The point of hosting your site’s database on a different server is to lower the load on the primary host and improve the site’s performance .
However, many people are left surprised when they move their database to a different machine, and instead of reduced loading times, they witness a significant drop in performance .
Hiring a separate database host can backfire because of latency. If the database and the web hosting server are located in different data centers , the data will need to travel a long way before WordPress can serve it to the site’s visitors.
Because of all this, experts advise that if you’re going to use a separate database host, you’re better off having both machines located on the same network . The data will be transferred more quickly, and the site’s visitors will instantly feel the reduced load on the main hosting server.
If this is the setup you’re going for, you need to use the machines’ local rather than public IPs when setting up the database host and configuring WordPress.