Если после настройки сайта или передачи доступа другим пользователям вам нужно убрать возможность править темы и плагины прямо из админки, в WordPress это делается через одну константу в wp-config.php. Речь о встроенном редакторе файлов в разделе «Внешний вид → Редактор файлов темы» и «Плагины → Редактор файлов плагина». После отключения эти пункты исчезают из панели, и случайно изменить код через браузер уже не получится.
Это не замена нормальному контролю доступа, а дополнительная мера. Она полезна, когда сайт уже работает, а вы хотите снизить риск случайных правок, неосторожных экспериментов или вредоносных изменений со стороны пользователя с доступом в админку.
Что именно отключает эта настройка
WordPress использует константу DISALLOW_FILE_EDIT. Если задать ей значение true, встроенный редактор файлов темы и плагинов в админке становится недоступен. При этом сам сайт продолжает работать, а установленные темы и плагины не удаляются и не отключаются автоматически.
Важно не путать эту настройку с более жёстким ограничением DISALLOW_FILE_MODS. Вторая константа запрещает не только редактирование файлов, но и установку, обновление и удаление тем и плагинов из админки. Для задачи «убрать именно редактор» обычно нужна только DISALLOW_FILE_EDIT.
Когда это действительно нужно
Чаще всего такую настройку включают в трёх сценариях:
- сайт передают клиенту или сотрудникам, которым не нужен доступ к коду;
- на проекте несколько администраторов, но правки должны вноситься только через Git, SFTP или файловый менеджер хостинга;
- нужно снизить риск, что кто-то случайно сломает сайт, открыв файл темы или плагина в браузере.
На рабочих сайтах это особенно полезно, если в админке остаются пользователи с широкими правами, но процесс разработки уже выстроен отдельно. В этом случае правки через редактор в браузере не дают никакой пользы, а риск от них заметный: достаточно одной лишней скобки или удаления строки, чтобы получить белый экран или ошибку PHP.
Как отключить редактор файлов через wp-config.php
Нужная строка добавляется в файл wp-config.php в корне установки WordPress. Обычно её размещают выше строки /* That's all, stop editing! Happy publishing. */. Если эта строка уже есть, повторно добавлять ничего не нужно.
Перед изменением файла сделайте резервную копию wp-config.php. Это не формальность: одна синтаксическая ошибка в этом файле может временно сделать сайт недоступным, а на некоторых хостингах ещё и заблокировать вход в админку до исправления.
Добавьте строку:
define( 'DISALLOW_FILE_EDIT', true );Если в файле уже есть другие константы, например настройки базы данных, префикс таблиц или режим отладки, новую строку вставляют рядом с ними, но до завершающего комментария. Порядок здесь важен только в том смысле, что константа должна быть определена до того, как WordPress начнёт использовать её в работе.
После сохранения файла обновите админку. Пункты редактирования темы и плагинов должны исчезнуть из меню.
Как проверить, что всё сработало
Проверка простая и не требует доступа к серверу:
- войдите в админку WordPress под учётной записью администратора;
- откройте раздел «Внешний вид» и убедитесь, что пункт редактора файлов темы отсутствует;
- откройте раздел «Плагины» и проверьте, что редактор файлов плагина тоже не отображается.
Если пункт всё ещё виден, обычно причина одна из трёх: строка не сохранилась в wp-config.php, файл редактируется не в той установке WordPress, либо на сайте стоит плагин, который меняет поведение админки и скрывает или показывает эти элементы по-своему. В последнем случае стоит проверить не только саму константу, но и настройки плагинов безопасности или админских ограничений.
Что эта настройка не делает
DISALLOW_FILE_EDIT не защищает сайт от всех способов изменения кода. Она только убирает встроенный редактор из админки. Если у пользователя есть доступ к SFTP, SSH, панели хостинга или файловому менеджеру, он всё равно сможет менять файлы темы и плагинов другими способами.
Также эта константа не ограничивает права пользователя в самой WordPress. Если у человека есть роль администратора, он по-прежнему сможет управлять плагинами, темами и настройками сайта в тех пределах, которые разрешает система и другие плагины. Поэтому для реальной безопасности важно сочетать эту настройку с нормальным разграничением доступа: отдельные учётные записи, сложные пароли, двухфакторная аутентификация, ограничение доступа к хостингу и резервные копии.
Когда лучше выбрать более жёсткое ограничение
Если задача не просто убрать редактор, а полностью запретить любые изменения тем и плагинов из админки, тогда рассматривают DISALLOW_FILE_MODS. Но это уже другой сценарий: WordPress перестанет позволять устанавливать, обновлять и удалять расширения через панель управления.
Такой вариант подходит не всем. На сайте, который обслуживается вручную, это может быть полезно. Но если вы рассчитываете обновлять плагины прямо из админки, включать DISALLOW_FILE_MODS не стоит: вы сами себе отключите удобный способ обслуживания сайта. Для большинства рабочих проектов достаточно именно DISALLOW_FILE_EDIT.
Если редактировать wp-config.php не хочется
Иногда доступ к wp-config.php ограничен политикой хостинга или вы не хотите трогать файл на боевом сайте без подготовки. Тогда есть альтернативы, но они не равнозначны.
- Плагин безопасности может скрывать редактор файлов, но это зависит от самого плагина и его настроек.
- Ограничение прав пользователя через роль или плагин управления ролями помогает только частично и не всегда убирает сам пункт меню для администратора.
- На уровне сервера можно ограничить доступ к файловому менеджеру или SSH, но это уже не настройка WordPress.
Если нужен именно надёжный и предсказуемый способ для WordPress, константа в wp-config.php остаётся самым прямым решением. Она не зависит от темы и обычно работает одинаково на большинстве хостингов, где сайт установлен стандартно.
На что обратить внимание после отключения
После внесения изменения проверьте, не полагается ли кто-то из команды на встроенный редактор как на основной способ правки. Если такие правки были обычной практикой, лучше заранее договориться о другом процессе: через SFTP, файловый менеджер хостинга, staging-копию или систему контроля версий.
На рабочем сайте это особенно важно, потому что отключение редактора убирает не только риск, но и быстрый аварийный способ «поправить одну строку прямо сейчас». Если у вас нет запасного канала доступа к файлам, сначала убедитесь, что он есть. Иначе при срочной правке вы просто упрётесь в закрытую админку и будете терять время на поиск обходного пути.
В нормальной схеме работы это ограничение только помогает: администраторы остаются администраторами, но случайно изменить код из браузера уже не смогут. Для сайта после передачи доступа это обычно именно то, что и нужно.