Расширенное руководство разработчика по файлу wp-config.php

Опубликовано: 2022-09-28

Насколько хорошо вы действительно знаете wp-config ? В этих нескольких строках PHP заключена удивительная сила! Эта статья представляет собой экскурсию по некоторым частям wp-config , о которых вы, возможно, не знали, но должны были.

Все ли вы знаете о файле wp-config.php ? Вы прочитали всю страницу документации WordPress об этом? Прямо до конца?

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

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

Милхаус из «Симпсонов» с надписью «wp-config» на лице и надписью «Моя мама говорит, что я крутой».

Оглавление

  1. Кто должен это прочитать?
  2. Почему вы должны это прочитать?
  3. Основы
  4. Просмотр констант wp-config
  5. Разбираем процесс загрузки wp-config.php
    1. wp-config можно переместить вверх
    2. Экран установки загружается, если нет файла wp-config.php
    3. wp-config.php загружается очень рано
    4. Не связывайтесь с wp-config.php!
  6. Проверка/анализ вашего файла wp-config.php
  7. Защита WordPress с помощью wp-config.php
    1. Защита wp-config.php от посетителей сайта
    2. Вращающиеся ключи/соли
    3. Перемещение и сокрытие вещей
    4. Отключение редакторов файлов
    5. Отключение автоматических обновлений
    6. Предотвращение внешних HTTP-запросов
  8. Перемещение вещей
    1. Перемещение таблиц User и Usermeta
    2. Перемещение каталогов контента, загрузок и плагинов
  9. Настройки, связанные с контентом
    1. Изменить URL-адреса сайта и панели инструментов
    2. Настройки публикации
    3. Опубликовать изменения
    4. Изменение интервала автосохранения
  10. Подведение итогов

Кто должен это прочитать?

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

Я не буду рассказывать вам, как редактировать файл с помощью FTP или cPanel, или почему вам не следует использовать для его редактирования MS Word.

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

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

Почему вы должны это прочитать?

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

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

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

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

Вполне вероятно, что есть вещи, о которых вы даже не подозреваете, что можете делать с помощью wp-config.php ! Какое-то «Ага!» моменты, которые нужно иметь.

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

Основы

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

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

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

  • Соединение с базой данных и префикс таблицы, который использует WordPress.
  • Информация о безопасности, такая как соли и ключи аутентификации.
  • Настройки для других функций ядра WordPress, таких как WP_CACHE и WP_DEBUG .
  • Настройки для плагинов, которые могут добавлять свои параметры в файл.
  • Ваши собственные параметры конфигурации.

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

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

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

Просмотр констант wp-config

Есть несколько способов быстро проверить значения констант WordPress без SSH-подключения к удаленному серверу и открытия файла.

Функция «Здоровье сайта» в ядре WordPress позволяет просматривать некоторые основные значения, перейдя в «Инструменты» -> «Здоровье сайта» -> «Информация» -> «Константы WordPress». Константы базы данных также можно увидеть в разделе «База данных» на той же странице.

Константы базы данных, показанные здесь, в разделе «База данных» на странице «Состояние сайта WordPress».

Плагин Query Monitor имеет панель «Среда», где вы можете увидеть некоторые часто используемые константы wp-config .

Панель «Среда» плагина Query Monitor, показывающая некоторые часто используемые константы wp-config.

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

Разбираем процесс загрузки wp-config.php

Полезно знать, когда загружается файл wp-config.php , так как это определяет некоторые вещи, которые вы можете и не можете делать с ним. Это хорошее упражнение для отслеживания процесса загрузки:

  • WordPress начинает загружаться с файла index.php . Для этого требуется файл wp-blog-header.php .

  • Практически первое, что делает wp-blog-header.php , — загружает wp-load.php .

  • Затем wp-load.php устанавливает константу ABSPATH (базовый основной каталог WordPress) и инициализирует error_reporting() перед загрузкой wp-config.php .

Этот процесс загрузки и, в частности, код в wp-load.php могут научить нас нескольким интересным вещам. Вот этот код:

 /* * If wp-config.php exists in the WordPress root, or if it exists in the root and wp-settings.php * doesn't, load wp-config.php. The secondary check for wp-settings.php has the added benefit * of avoiding cases where the current directory is a nested installation, eg / is WordPress(a) * and /blog/ is WordPress(b). * * If neither set of conditions is true, initiate loading the setup process. */ if ( file_exists( ABSPATH . 'wp-config.php' ) ) { /** The config file resides in ABSPATH */ require_once ABSPATH . 'wp-config.php'; } elseif ( @file_exists( dirname( ABSPATH ) . '/wp-config.php' ) && ! @file_exists( dirname( ABSPATH ) . '/wp-settings.php' ) ) { /** The config file resides one level above ABSPATH but is not part of another installation */ require_once dirname( ABSPATH ) . '/wp-config.php'; } else { // A config file doesn't exist. // [Code here to load the setup screen for in-browser configuration] }

Что мы здесь видим?

wp-config.php можно переместить вверх

Во-первых, комментарий говорит нам, что мы можем поместить wp-config.php в «корень WordPress». Что не упоминается, так это то, что «корневой» каталог на самом деле может быть каталогом выше ABSPATH где находится wp-load.php .

Мы можем увидеть эту дополнительную проверку в elseif , где она ищет dirname( ABSPATH ) . '/wp-config.php' dirname( ABSPATH ) . '/wp-config.php' . Дополнительное условие в elseif объясняется в комментарии.

Экран установки загружается, если нет файла wp-config.php

Во-вторых, мы видим, что если файл конфигурации не существует, он загрузит экран настройки.

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

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

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

wp-config.php загружается очень рано

Третье, на что следует обратить внимание, это то, что wp-config.php загружается очень рано в последовательности запуска WordPress. Это означает, что:

  1. Мы многого не можем сделать в wp-config.php . Например, мы не можем добавить сюда хуки (действия или фильтры), потому что функции и структуры данных для этого еще не загружены. И у нас нет доступа ни к каким внутренним функциям, объектам и API WordPress.

  2. У нас есть большой контроль над тем, что произойдет дальше. Поскольку файл загружается так рано, он оказывает большое влияние на WordPress. Это и хорошо, и плохо. Мы можем легко заставить WordPress полностью умереть. Но мы также можем получить доступ ко всему, что определено в wp-config.php , практически из любого места в WordPress.

Не связывайтесь с wp-config.php!

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

Внизу файла wp-config.php находятся следующие строки:

 /* Add any custom values between this line and the "stop editing" line. */ /* That's all, stop editing! Happy publishing. */ /** Absolute path to the WordPress directory. */ if ( ! defined( 'ABSPATH' ) ) { define( 'ABSPATH', __DIR__ . '/' ); } /** Sets up WordPress vars and included files. */ require_once ABSPATH . 'wp-settings.php';

Здесь есть некоторые инструкции, но строка «остановить редактирование» важна. После этой строки идет продолжение последовательности инициализации WordPress. Добавление нового кода в неправильном месте, вероятно, приведет только к тому, что новый код не будет иметь никакого эффекта. Но чтобы быть в безопасности, я рекомендую следовать этим инструкциям. Они там по уважительной причине.

Проверка/анализ вашего файла wp-config.php

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

Вы можете запустить php в командной строке с параметром -l («lint»), чтобы проверить файл wp-config.php на наличие фатальных синтаксических ошибок PHP.

$ php -l wp-config.php

Ошибка синтаксического анализа: синтаксическая ошибка, неожиданный токен «require_once» в wp-config.php в строке 9.

Ошибки при разборе wp-config.php

Вы даже можете написать сценарий оболочки для…

  1. Скопируйте wp-config.php во временный файл,
  2. Отредактируйте временный файл,
  3. Проанализируйте временный файл и
  4. Скопируйте его обратно, только если в нем нет синтаксических ошибок.

Если вас устраивает командная строка, то безопаснее использовать команды WP-CLI, такие как wp config set <name> <value> , чтобы безопасно устанавливать значения, а не делать это вручную.

Вы также можете перечислить свои значения конфигурации с помощью WP-CLI (это пример с некоторыми удаленными записями — вы поняли!):

$ wp список конфигураций
+------------------------------------+-------------- ------+----------+
| имя | значение | тип |
+------------------------------------+-------------- ------+----------+
| корневой_каталог | /Пользователи/кузнецы/сайты/snpp | переменная |
| веб-каталог | /Users/smithers/sites/snpp/public | переменная |
| table_prefix | wp_ | переменная |
| WP_HOME | https://snpp.test | постоянная |
| WP_SITEURL | https://snpp.test/ | постоянная |
| ИМЯ_БД | снипп | постоянная |
| БД_ПОЛЬЗОВАТЕЛЬ | корень | постоянная |
| БД_ПАРОЛЬ | Монтгомери | постоянная |
| БД_ХОСТ | 127.0.0.1 | постоянная |
| DB_CHARSET | утф8мб4 | постоянная |
| DB_COLLATE | | постоянная |
| БД_ПРЕФИКС | wp_ | постоянная |
| WP_DEBUG | 1 | постоянная |
| WP_DEBUG_LOG | 1 | постоянная |
| WP_DEBUG_DISPLAY | | постоянная |
| WP_ENVIRONMENT_TYPE | развитие | постоянная |
| DISABLE_WP_CRON | | постоянная |
| DISALLOW_FILE_EDIT | 1 | постоянная |
+------------------------------------+-------------- ------+----------+

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

Защита WordPress с помощью wp-config.php

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

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

Защита wp-config.php от посетителей сайта

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

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

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

Наконец, если вы храните файл своего веб-сайта в Git, важно не хранить файл wp-config в вашем репозитории Git. Это может привести к утечке важной информации о вашем сайте, но, кроме того, вы, вероятно, все равно захотите использовать разные версии этого файла в каждой среде. Поэтому лучше добавить его в свой .gitignore и вручную управлять файлами в каждой среде.

Вращающиеся ключи/соли

Что такое ключи/соли?

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

Зачем «вращать» ключи/соли?

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

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

Проблема с ротацией ключей/солей

Смена ключей и солей не безболезненна. Любой, у кого есть набор cookie, потеряет его. Таким образом, любой, кто войдет в систему, будет удален, а любой, у кого есть корзина WooCommerce, будет опустошен.

Как вращать ключи/соли

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

Итак, позвольте мне рассказать вам о нескольких способах установки новых ключей/солей в вашем wp-config .

  1. Вручную добавьте ключи из генератора: вы можете использовать генератор wordpress.org, чтобы получить нужный код. Просто скопируйте и вставьте его в файл wp-config вместо старых значений.
  2. Используйте плагин: Многие плагины безопасности, такие как Sucuri Security, iThemes Security и Malcare, имеют эту функцию. И Salt Shaker — это специальный плагин, который автоматизирует этот процесс по расписанию.
  3. Используйте WP-CLI. Мы уже говорили, насколько крут WP-CLI? Мы сделали? ХОРОШО. Ну, мы говорим это снова! И вы можете использовать команду wp config shuffle-salts , чтобы выполнить эту работу за считанные секунды.

Перемещение и сокрытие вещей

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

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

Отключение редакторов файлов

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

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

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

Многие хосты просто отключают эту функцию по умолчанию. Но если вы хотите, чтобы они исчезли, просто добавьте:

 define( 'DISALLOW_FILE_EDIT', true );

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

Отключение автоматических обновлений

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

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

 # Disable all core updates: define( 'WP_AUTO_UPDATE_CORE', false ); # Enable all core updates, including minor and major: define( 'WP_AUTO_UPDATE_CORE', true ); # Enable core updates for minor releases (default): define( 'WP_AUTO_UPDATE_CORE', 'minor' );

Если вы хотите что-то более экстремальное, вы можете DISALLOW_FILE_MODS :

 define( 'DISALLOW_FILE_MODS', true );

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

Чуть менее экстремальным является AUTOMATIC_UPDATER_DISABLED . Это позволяет вам устанавливать плагины и темы, но не будет обновлять их или основное программное обеспечение. Однако он также отключает обновления перевода.

 define( 'AUTOMATIC_UPDATER_DISABLED', true );

На wordpress.org есть подробное руководство по всем этим вопросам, включая некоторые другие параметры, такие как использование фильтров для более точного контроля.

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

Настройка HTTPS

Настройка HTTPS часто была сложной задачей. С появлением бесплатных доверенных сертификатов безопасности из таких мест, как LetsEncrypt и Cloudflare, многие хосты настроят это за вас в пару кликов. Этот параметр, вероятно, следует считать устаревшим, но, возможно, он вам все еще нужен для чего-то.

Константа FORCE_SSL_ADMIN указывает WordPress всегда использовать SSL для страниц входа и панели управления WordPress. Это гарантирует, что безопасные учетные данные и файлы cookie не могут быть отправлены в незашифрованном виде.

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

Предотвращение внешних HTTP-запросов

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

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

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

 define( 'WP_HTTP_BLOCK_EXTERNAL', true );

Если вы хотите иметь список разрешенных хостов, с которыми можно связаться, вы также можете сделать это:

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

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

Перемещение вещей

Не каждая установка WordPress одинакова. Некоторым хостам или фреймворкам нравится перемещать каталоги из соображений безопасности или хранить специфичный для сайта код и ресурсы отдельно от ядра WordPress. Моя статья об использовании Git и Composer для управления WordPress описывает некоторые преимущества этого подхода.

Итак, какие варианты WordPress предоставляет вам — за неимением лучшего термина — «перемещение вещей»?

Изменение префикса базы данных

WordPress по умолчанию использует префикс имени таблицы базы данных wp_ . Этот префикс добавляется ко всем именам таблиц базы данных, а также используется в некоторых других местах, например, в параметре <prefix>user_roles в таблице параметров и в пользовательских метазаписях <prefix>capabilities .

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

Параметр wp_config $table_prefix позволяет вам сделать это, и вам, вероятно, следует установить для него какую-то короткую, но случайную строку с суффиксом подчеркивания:

 $table_prefix = 'b4F8az_';

Это скажет WordPress использовать имена таблиц, такие как b4F8az_posts , вместо wp_posts .

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

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

Любопытно отметить, что $table_prefix является переменной, а не константой. Это единственная переменная, определенная в образце файла конфигурации, который WordPress предоставляет вам! И если вам все еще любопытно: да, команды wp config WP-CLI позаботятся об этом за вас, даже не зная об этом!

Перемещение таблиц User и Usermeta

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

Я предполагаю, что это помогает предотвратить атаку SQL-инъекцией, которая пытается «SELECT * FROM wp_usermeta;», но я рад услышать и другие причины для этого.

В любом случае, CUSTOM_USER_TABLE и CUSTOM_USER_META_TABLE — это то, что вам нужно:

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

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

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

Также можно переместить весь каталог wp-content , каталог uploads и каталоги themes и plugins . Что следует отметить:

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

Подробности смотрите в официальной документации — я не буду повторяться здесь.

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

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

wp_upload_dir
plugins_url
plugin_dir_url
plugin_dir_path
get_stylesheet_directory
get_stylesheet_directory_uri
get_template_directory — обратите внимание, что для дочерней темы это возвращает местоположение родительской темы.
get_template_directory_uri

В руководстве разработчика WordPress есть более исчерпывающий список подобных функций.

Наконец, помимо перемещения файлов внутри вашей установки WordPress, вы также можете переместить свое местоположение wp-admin или изменить местоположение своего сайта. И с этим может помочь wp-config.php .

Настройки, связанные с контентом

В конце концов, WordPress — это система управления контентом. Таким образом, вы ожидаете, что некоторые константы, которые вы можете использовать в wp-config.php для управления параметрами содержимого. Давайте посмотрим и посмотрим, что мы можем сделать.

Изменить URL-адреса сайта и панели инструментов

Меня всегда это смущало.

Чтобы установить URL-адрес вашего сайта, вам нужно использовать константу WP_HOME , а не константу WP_SITEURL .

Константа WP_SITEURL не меняет URL вашего сайта.

Смущенный?

Официальное описание того, что делает WP_SITEURL , — это «адрес, по которому находятся ваши основные файлы WordPress». Это также сбивает с толку, потому что это URL-адрес, а не каталог.

Не обвиняйте меня в этом, я всего лишь ваш гид на весь день!

Установка WP_HOME и WP_SITEURL переопределяет записи home и siteurl в таблице базы данных wp_options . Так что это, по крайней мере, имеет смысл.

 // NOTE: These must not have trailing slashes define( 'WP_HOME', 'https://helfish.media' ); define( 'WP_SITEURL', 'https://hellfish.media/wordpress` );

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

Параметр WP_SITEURL также можно использовать, когда вы переместили основные файлы WordPress в другой каталог.

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

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

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

Настройки публикации

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

Опубликовать изменения

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

Можно полностью отключить ревизии сообщений, изменив значение WP_POST_REVISIONS в вашем файле wp-config.php . По умолчанию оно равно true. Чтобы отключить ревизии, вы можете вместо этого установить значение false:

 define( 'WP_POST_REVISIONS', false );:

Некоторые хосты, в том числе WP Engine, по умолчанию отключают ревизии сообщений. Я рекомендую проконсультироваться с вашим хостинг-провайдером, прежде чем вносить какие-либо изменения. Это зависит от хоста к хосту, но если вы используете WP Engine, вы не можете включить ревизии через wp-config , так как они будут перезаписаны на уровне сервера.

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

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

 define( 'WP_POST_REVISIONS', 5 );

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

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

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

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

Подведение итогов

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

В официальной документации, несомненно, скрываются и другие сокровища, ожидающие своего открытия. Какие советы по использованию wp-config вы нашли? Дай мне знать в комментариях.