Файл wp-config.php — это не обычный шаблон WordPress, а конфигурация, от которой зависит подключение к базе данных, режим отладки, лимиты памяти и часть служебных настроек. Если открыть его неаккуратно, можно получить белый экран, ошибку синтаксиса или потерять доступ к админке. Поэтому править его нужно только понимая, где он лежит, чем удобнее открыть именно в вашем случае и как быстро откатить изменения.
Обычно файл редактируют через FTP/SFTP, файловый менеджер хостинга или по SSH. Все три способа рабочие, но для разных ситуаций. Если нужен быстрый и безопасный доступ к одному файлу, чаще всего удобнее файловый менеджер или SSH. Если сайт уже недоступен из админки, но сервер отвечает, FTP/SFTP и SSH остаются основными вариантами.
Где находится wp-config.php
В стандартной установке WordPress файл лежит в корне сайта, рядом с папками wp-admin, wp-content и wp-includes. На хостинге это обычно каталог сайта, который открывается как корень домена: например, public_html, www, htdocs или папка с именем домена.
Если вы не видите файл сразу, проверьте два момента:
- в файловом менеджере включён показ скрытых файлов;
- вы открыли именно корень сайта, а не вложенную папку темы или плагина.
Иногда wp-config.php размещают на уровень выше корня WordPress. Это допустимо и иногда используется как дополнительная мера защиты, но не на каждом хостинге и не во всех схемах развёртывания. Если файл не находится в корне, проверьте родительский каталог.
Как открыть wp-config.php через FTP или SFTP
Этот способ подходит, если у вас есть доступ к серверу, но нет удобного файлового менеджера или нужно работать из локального редактора. Для WordPress лучше использовать SFTP, а не обычный FTP: соединение шифруется, и логин с паролем не передаются открытым текстом.
Порядок действий простой:
- Подключитесь к сайту через FTP-клиент, например FileZilla, WinSCP или другой клиент, который поддерживает SFTP.
- Откройте корневую папку сайта.
- Скачайте
wp-config.phpна компьютер и сделайте копию файла перед правкой. - Откройте файл в текстовом редакторе, который не меняет кодировку и форматирование, например VS Code, Notepad++ или Sublime Text.
- Внесите нужные изменения и загрузите файл обратно на сервер с заменой старой версии.
Перед загрузкой проверьте, что редактор сохранил файл в обычном UTF-8 без BOM. Лишний BOM или «умное» автозамещение символов иногда ломают PHP-файл ещё до выполнения WordPress.
Если после замены сайт перестал открываться, первым делом верните резервную копию файла. При ошибке в wp-config.php WordPress часто не успевает показать нормальное сообщение, и это самый быстрый способ восстановить доступ.
Как отредактировать файл через файловый менеджер хостинга
Файловый менеджер удобен, когда доступ к панели хостинга уже есть, а ставить отдельный FTP-клиент не хочется. У большинства хостингов файл можно открыть прямо в браузере и изменить встроенным редактором.
Рабочая схема обычно такая:
- Откройте панель управления хостингом.
- Перейдите в файловый менеджер.
- Откройте каталог сайта.
- Найдите
wp-config.php. - Сделайте копию файла или скачайте его перед редактированием.
- Откройте встроенный редактор, внесите изменения и сохраните файл.
У этого способа есть практическое ограничение: встроенные редакторы на хостингах не всегда удобно показывают кодировку и иногда плохо работают с длинными строками. Если файл содержит нестандартные символы или хостинг подменяет форматирование, лучше скачать файл, отредактировать локально и загрузить обратно.
Если хостинг предлагает выбор кодировки, оставляйте UTF-8 без BOM. Это особенно важно, если вы добавляете новые строки вручную.
Как править wp-config.php по SSH
SSH подходит, если вы уверенно работаете в терминале или на сервере нет удобного графического редактора. Этот способ быстрее для опытного пользователя, но требует аккуратности: одна лишняя кавычка или пропущенная точка с запятой ломают весь сайт.
Сначала подключитесь к серверу и перейдите в каталог сайта. Затем откройте файл в редакторе, который доступен в вашей среде. На большинстве серверов используют nano или vim. Если вы не уверены в работе с vim, проще использовать nano.
Пример для nano:
cd /path/to/site
nano wp-config.phpПосле правки сохраните файл и выйдите из редактора. В nano это обычно Ctrl+O, затем Enter, потом Ctrl+X.
Если вы редактируете файл через SSH, особенно важно не запускать команды, которые могут массово менять права или содержимое каталога без понимания последствий. Для wp-config.php достаточно точечной правки самого файла.
Что обычно меняют в wp-config.php и где это делать
В этот файл имеет смысл вносить только настройки, которые действительно относятся к конфигурации сайта, а не к теме или плагину. Чаще всего там задают параметры подключения к базе данных, ключи безопасности, режим отладки, лимит памяти и некоторые служебные константы.
Для ориентира:
| Что меняют | Зачем | Где править |
|---|---|---|
| Данные подключения к БД | Чтобы WordPress мог подключаться к базе | Только в wp-config.php |
WP_DEBUG | Включить диагностику ошибок | Только в wp-config.php |
WP_MEMORY_LIMIT | Попросить WordPress использовать больше памяти | Только в wp-config.php |
| Ключи и соли | Сбросить сессии и куки авторизации | Только в wp-config.php |
Не стоит переносить в этот файл настройки, которые относятся к плагину или теме, если разработчик прямо не требует этого. Если параметр можно задать в админке или через интерфейс плагина, обычно лучше использовать именно штатный способ.
Куда вставлять новые строки
Если вы добавляете константу вручную, размещайте её до строки /* That's all, stop editing! Happy publishing. */ или перед аналогичным комментарием в русской локализации. Это не строгое техническое требование для всех случаев, но так проще сохранить структуру файла и не задеть служебный код ниже.
Если в файле уже есть нужная константа, не дублируйте её. В PHP повторное объявление одной и той же константы может вызвать предупреждение или конфликт логики. Сначала найдите существующее значение, потом изменяйте его, а не добавляйте новую строку рядом.
Как не сломать сайт при редактировании
Самая частая проблема при правке wp-config.php — синтаксическая ошибка. Она возникает из-за пропущенной точки с запятой, лишней кавычки, неверной скобки или случайного символа в начале файла. Вторая типичная ошибка — сохранение файла в неправильной кодировке или с BOM.
Перед изменением сделайте три вещи:
- скачайте резервную копию
wp-config.php; - сохраните исходное содержимое отдельно, чтобы можно было быстро вернуть его назад;
- меняйте только то, что действительно нужно для задачи.
Если вы правите файл на рабочем сайте, лучше делать это в момент, когда есть возможность быстро проверить главную страницу и админку. Для более рискованных изменений разумно сначала проверить их на staging-копии, если она есть.
После сохранения откройте сайт в браузере и проверьте:
- главную страницу;
/wp-admin/;- страницу, на которой проявлялась проблема;
- при необходимости — журнал ошибок на хостинге.
Если вместо сайта видите сообщение о критической ошибке или белый экран, вернитесь к резервной копии. Не пытайтесь «дописывать ещё что-то» вслепую: при ошибке в конфигурации это обычно только усложняет восстановление.
Как проверить, что изменения действительно сработали
Проверка зависит от того, что именно вы меняли. Для WP_DEBUG результатом будет появление записей в логах или вывод сообщений об ошибках в зависимости от того, как настроены связанные константы. Для WP_MEMORY_LIMIT важно понимать, что WordPress может запросить больше памяти, но фактический предел всё равно ограничен PHP и настройками хостинга. Если хостинг не разрешает увеличить лимит, одна строка в wp-config.php не решит проблему.
Для параметров базы данных проверка обычно сводится к тому, что сайт снова открывается без ошибки подключения. Для ключей и солей — к повторному входу в админку после замены значений. Это нормальное поведение: старые авторизационные cookies становятся недействительными.
Если вы меняли настройки отладки, не оставляйте публичный вывод ошибок включённым на рабочем сайте без необходимости. Для диагностики полезнее писать ошибки в лог, чем показывать их посетителям. Иначе можно раскрыть пути к файлам, фрагменты кода и внутренние детали окружения.
Когда лучше не редактировать файл вручную
Ручная правка wp-config.php не подходит, если вы не уверены, что именно меняете, или если проблема связана не с конфигурацией WordPress, а с сервером, правами файлов, базой данных или конфликтом плагинов. В таких случаях правка файла может не помочь и только добавит риск.
Если задача касается настроек PHP на уровне хостинга, лимитов памяти на стороне сервера, версии PHP или правил веб-сервера, это уже не решается одной правкой wp-config.php. Тогда нужно смотреть панель хостинга, документацию провайдера или обращаться к специалисту, который управляет сервером.
Если вам нужно лишь включить диагностику, изменить лимит памяти или проверить параметры подключения к базе, wp-config.php — правильное место. Но редактировать его стоит только после резервной копии и с пониманием, как вы будете проверять результат и как быстро вернёте рабочую версию, если что-то пойдёт не так.