Как редактировать wp-config.php файл в WordPress
wp-config.php — это файл конфигурации, который является обязательным для всех сайтов WordPress. Этот файл генерируется в процессе установки WordPress . Здесь хранится информация о вашей БД(базе данных) и несколько других дополнительных настроек. Без этого файла сайт на WordPress работать не будет.
С учетом того, что файл содержит крайне важную информацию вносить в него изменения без крайней на то необходимости не рекомендую. Если все же вам понадобилось это сделать,внимательно изучите информацию ниже.
Начало работы
Перед началом работы обязательно сделайте резервную копию сайта WordPress, ведь даже небольшая ошибка сделает его недоступным.
Затем подключитесь к сайту с помощью FTP-клиента.
WP-config.php находится в корневой папке, там же где размещаются основные папки (wp-admin и т.д.).
Наведите мышью на название файла, нажмите правой кнопкой и выберите Просмотр/Правка, чтобы открыть wp-config.php-файл на вашем компьютере. Вы можете редактировать его с помощью редактора, например notepad++, VSC или Sublime.
Основы wp-config.php
Вот так выглядит наш файл:
Рассмотрим подробнее каждый раздел.
Настройки MySQL в wp-config.php
В самом начале отображаются настройки подключения к базе данных WordPress в разделе MySQL settings. Вы должны внести имя базы данных, имя пользователя базы данных и пароль, чтобы заполнить этот раздел.
Все эти данные вы моете найти в учетной записи вашего хостинга.
Ключи аутентификации
Эти ключи безопасности необходимы для того, чтобы повысить безопасность вашего сайта WordPress. Ключи обеспечивают надежное шифрование пользовательских сеансов и файлов cookie, создаваемых WordPress. Их можно сгенерировать самостоятельно и вставить в файл.
Префикс Таблицы БД
WordPress всегда добавляет префикс wp_ ко всем таблицам, созданным WordPress. Желательно заменить его собственным префиксом, чтобы затруднить работу взломщикам. Это можно сделать с помощью плагина WP Security.
Режим Отладки WordPress
Эта настройка особенно полезна для разработчиков. WordPress не показывает уведомления об ошибках, генерируемые PHP при выполнении кода. Чтобы включить такую возможность и видеть что и когда пошло не так, нужно заменить false на true. Это предоставляет разработчикам важную информацию для поиска ошибок.
define(‘WP_DEBUG’, false);
define(‘WP_DEBUG’,true);
Параметры Абсолютного Пути
Абсолютный путь используется для установки WordPress переменных и включенных файлов. Здесь лучше ничего не менять.
Другие wp-config.php хаки
Это еще не все настройки wp-config. php, рассмотрим некоторые другие возможности этого файла.
Изменение url WordPress с помощью wp-config.php
Возможно, вам понадобится поменять URL в случае перемещения сайта WordPress на новое доменное имя или новый веб-узел. Это можно сделать из админ-панели, Настройки>Общие.
Это же можно сделать с помощью wp-config.php. Вот что нужно добавить в этот файл:
define(‘WP_HOME’,’http://ваш_домен.com’);
define(‘WP_SITEURL’,’http://ваш_домен.com’);
ваш_домен.com — доменное имя вашего сайта. Запомните, что поисковики считают www.ваш_домен.com и ваш_домен.com двумя разными адресами. Если ваш сайт индексируется с префиксом www, то вам необходимо добавить это доменное имя.
Меняем каталог загрузки
WordPress сохраняет все загрузки мультимедиа в директории /wp-content/uploads/. Если вас не устраивает эта папка и вы хотите, чтобы данные сохранялись в любой другой новой папке, внесите в wp-config. php следующие строки:
define( ‘UPLOADS’, ‘wp-content/ваша папка’ );
Отключить автоматическое обновление в WordPress
Не смотря на то, что автоматические обновления необходимы для безопасности, бывают ситуации, что такие обновления ломали сайт и делали его недоступным.
Чтобы отключить все автоматические обновления на вашем WordPress сайте добавьте в код следующие строки:
define( ‘WP_AUTO_UPDATE_CORE’, false );
Чтобы включить автоматическое обновление всех основных обновлений, включая основные и второстепенные, добавьте следующую строку:
define( ‘WP_AUTO_UPDATE_CORE’, true );
Ограничить изменения записей в WordPress
Добавьте эту строку кода в WP-config.php-файл для ограничения количества ревизий, хранящихся для записи.
define( ‘WP_POST_REVISIONS’, 3 );
Замените 3 числом ревизий, которые требуется сохранить. WordPress теперь автоматически откажется от старых версий. Тем не менее, старые версии записей по-прежнему хранятся в базе данных.
Ищете курс по PHP, чтобы расширить свои знания в области веб-разработки? Переходите Read more
Localhost нужен для того, чтобы абсолютно бесплатно и спокойно создать Read more
Итак, вы создали свой сайт, выбрали подходящую тему, но не Read more
Не у всех есть технические навыки, чтобы создать рабочий веб-сайт. Read more
Вы можете совершать множество изменений на своем сайте WordPress, не Read more
Существует два способа с помощью которых можно установить wordpress тему: Установка Read more
Где находится конфигурационный файл WordPress?
Конфигурационный файл служит для первичной настройки сайта на движке WordPress, клювым функцией которой является подключение сайта к базе данных.
Сам файл называется wp-config.php и находится в корневой директории сайта, абсолютный путь к которой, Вы можете узнать в своей панели управления
define( 'DB_NAME', 'НАВЗВАНИЕ БАЗЫ ДАННЫХ' ); define( 'DB_USER', 'ИМЯ ПОЛЬЗОВАТЕЛЯ БАЗЫ ДАННЫХ' ); define( 'DB_PASSWORD', 'ПАРОЛЬ ОТ ПОЛЬЗОВАТЕЛЯ БАЗ ДАННЫХ' ); define( 'DB_HOST', 'СЕРВЕР РАЗМЕЩЕНИЯ БАЗЫ ДАННЫХ' ); $table_prefix = 'ПРЕФИКС НАЗВАНИЯ ТАБЛИЦ, КОТОРЫЕ ИСПОЛЬЗУЮТСЯ В БАЗЕ ДАННЫХ';
При переносе сайта к нам на хостинг, важно корректно заполнить все эти данные.
Корректно скопировать их из панели управления, Вы можете при помощи инструкций из [РАЗДЕЛА MYSQL]
Все категории вопросов
- Общие вопросы по услуге хостинга
- Робота с хостинг 2.0
- Работа с базами данных [MySQL]
- Работа с FTP
- Работа с SSH
- Работа с почтой
- Работа с Cron
- Работа с SSL
- Работа с резервным копированием
- Работа с htaccess
- Работа с CMS
- Дополнительные услуги
- Нагрузка
- Ошибки на сайте
- Конструктор сайтов
- Регистрация и продление доменов
- Управление DNS-записями домена
- Трансфер домена
- Смена контактных данных владельца домена
- Настройка CloudFlare
- Общие вопросы по серверам
- Администрирование виртуального сервера (VPS)
- Администрирование выделенного сервера (DS)
- Инструкции по Windows Server
- Инструкции по Linux
- Панель управления FASTPANEL
- Панель управления Hestia CP
- Панель управления Vesta CP
- Платный SSL-сертификат
- Файловое хранилище
- SMS-сервис
- CallBack-сервис
Похожие статьи
- Как создать базу данных MySQL? 0 —>
- Как создать пользователя MySQL? 0 —>
- Как узнать пароль от пользователя баз данных? 0 —>
- Как узнать сервер для подключения к базе данных? 0 —>
Файл wp-config.php: для чего нужен, где найти, как с ним работать
wp-config.php – ключевой конфигурационный файл WordPress, загружающийся до запуска ядра. Не входит в инсталляционный пакет CMS, обычно генерируется «движком» во время установки сайта. С помощью этого файла подключается ваша база данных MySQL и устанавливается ее префикс, обеспечивается хранение ключей шифрования, включается режим отладки, указывается путь к директории WordPress, задаются глобальные значения констант PHP.
Ответ на вопрос, где находится wp-config.php, обычно лежит в корневой директории вашего ресурса, рядом с другими служебными файлами WordPress и каталогами wp-admin, wp-includes, wp-content. Однако в типовом месте размещения есть существенный недостаток – здесь главный конфигурационный скрипт CMS становится легкой мишенью для злоумышленников. Многие плагины безопасности предлагают опцию перемещения wp-config в другую папку в качестве одного из шагов по усилению защиты сайта на WordPress.
Для чего нужен файл wp-config.php
В базовой конфигурации CMS в главном файле системы управления сайтом задаются:
- ключевые параметры подключения базы данных (БД);
- ключи безопасности; // шифрование хранящихся в браузере паролей;
- префикс таблицы БД; // wp_ по умолчанию, но рекомендуется более сложный префикс;
- константа ABSPATH, указывающая путь к корневой директории.
Параметры подключения БД определяются фиксированными переменными:
- DB_NAME – тип данных text, значение – текущее название БД MySQL;
- DB_USER – текстовый тип данных, имя пользователя;
- DB_HOST – имя хоста (домен, IP-адрес, опционально – +номер порта);
- DB_PASSWORD – тип данных text, пароль БД MySQL;
- DB_CHARSET – кодировка текста таблиц БД;
- DB_COLLATE – тип сравнения для БД.
Параметр DB_HOST чаще всего принимает значение ‘localhost’, однако у многих хостеров дефолтные значения этой фиксированной переменной отличаются. Например, Yahoo использует хост ‘mysql’, 1and1 Hosting – db12345679. Если не подходит ‘localhost’, уточните корректное значение у своего провайдера услуг хостинга. Значение $_ENV даст на выходе функции define актуальный хост базы данных. С помощью константы DB_HOST можно указать и альтернативный порт хоста MySQL. Номер порта указывается после двоеточия. Например, ‘localhost:х’, где ‘х’ – новое глобальное значение порта.
В скрипте wp-config могут определяться и другие фиксированные константы языка сценариев PHP, не входящие в базовый функционал.
Принципы работы с файлом wp-config.php
Некорректные установки wp-config.php могут вызвать сбои или полностью заблокировать загрузку сайта и доступ к панели администрирования. Поэтому при работе с основным конфигурационным файлом ресурса рекомендуется соблюдать следующие меры предосторожности:
- делайте резервные копии главного скрипта WordPress перед каждой модификацией файла конфигурации;
- вносите изменения в wp-config.php только в том случае, если уверены на 100% в своих действиях.
Базовая конфигурация изначально находится в файле примера wp-config-sample.php. Сценарий инсталляции CMS копирует этот файл в корневую директорию, присваивает константам значения, введенные пользователем во время установки WordPress, и сохраняет результаты в скрипте wp-config.php. Если что-то пойдет не так, пользователю может понадобиться прописать нужные значения вручную. Для этого придется зайти в корень сайта с помощью файлового менеджера или FTP-клиента.
Настройки БД, ключи и путь к корневому каталогу, где находится wp-config.php, определяются функцией define(), принимающей на входе название константы, а на выходе дающей ее значение. С помощью этой функции глобально переопределяются и другие константы PHP. Формат записи:
define (‘КОНСТАНТА’, ‘значение_константы’);
define (‘DB_HOST’, ‘localhost’); // задаем сервер базы данных;
define (‘DB_CHARSET’, ‘utf8’); // определяем кодировку текста таблиц БД, рекомендуется UTF-8;
Полный перечень констант PHP, их тип и значения по умолчанию можно найти в Кодексе WordPress, официальном справочнике самой популярной CMS мира. Например, за включение и отключение режима отладки отвечает фиксированная переменная ‘WP_DEBUG’. Дебаг относится к логическому типу данных и может принимать значения ‘true’ (отладка включена) или ‘false’ (режим отладки отключен).
define ( ‘WPLANG’, ‘ru_RU’ ); // устаревшая константа указания файла локализации (до WP 4.0);
define ( ‘DISABLE_WP_CRON’, true ); // отключение cron, по умолчанию значение ‘false’;
define ( ‘EMPTY_TRASH_DAYS’, false ); // отключение корзины, по умолчанию включена;
В WordPress 4.0 фиксированная переменная WPLANG заменена функцией get_locale(), устанавливающей локаль и получающей текущий индекс языка сайта (например, en_US для английского (США) или ru_RU для русского). Начиная с WP 5.0, вместо функции get_locale() обычно используется обертка determine_locale().
Константа EMPTY_TRASH_DAYS показывает, сколько суток должны храниться в корзине стертые записи перед их окончательным удалением. Значение по умолчанию – 30 [дней]. Фиксированной переменной можно изменить период времени нахождения записей в корзине или полностью отключить корзину (значение – false). Есть возможность отключить корзину только для файлов медиа (видео, аудио, изображения). Делается это с помощью «переключателя» MEDIA_TRASH, принимающего два значения – ‘false’ (функция отключена) или ‘true’ (медиафайлы отправляются в корзину и хранятся там столько суток, сколько определено константой EMPTY_TRASH_DAYS).
Для получения пути и URL каталога плагинов можно воспользоваться константами WP_PLUGIN_DIR и WP_PLUGIN_URL. За настройки автоматического обновления ядра отвечает фиксированная переменная WP_AUTO_UPDATE_CORE. Она может принимать значения ‘true’, ‘false’ или ‘minor’. True – автообновление включено. False – отключение автоматического апдейта. Minor – включение обновлений только для незначительных релизов.
Фиксированная переменная WP_MEMORY_LIMIT задает предельный объем ROM под выполнение скриптов WordPress. По умолчанию для сценариев выделяется 32 Мб, в режиме Multisite выставляется дефолтное значение 64 Мб. Обычно такого количества памяти хватает. Если же из-за превышения лимита наблюдаются сбои или полностью блокируется работа сайта на CMS WordPress, не стоит торопиться со смягчением ограничений. Возможно, есть смысл отказаться от «прожорливых» сценариев и плагинов и заменить их на более «легкое» ПО с меньшими требованиями к программно-аппаратной части сервера.
В wp-config.php можно задать значения еще нескольких десятков фиксированных переменных. Все они определяются глобально, поскольку главный конфигурационный файл сайта загружается еще до запуска ядра CMS. Полный список констант PHP смотрите в официальной документации WordPress.
Реклама: плагин A-Rating позволяет создавать и управлять неограниченным количеством рейтингов на WordPress-сайте. О том, как монетизировать рейтинги, можно почитать здесь.
Новые публикации
- WordPress рейтинги: как увеличить продажи с помощью конструктора рейтингов 19.11.2023
- Плагины для WordPress: интересные новинки 2023 года 26.08.2023
- Обзор плагина HYIPLab 07.05.2023
- Обзор плагина Faview 22.04.2023
- Обзор темы Phlox Pro – Самая многоцелевая тема WordPress! 26.02.2023
- Обзор темы Harington 25.02.2023
- Тенденции WordPress сайтов в 2023 10.02.2023
- Темы WordPress 2023: бесплатные темы начала года 15.01.2023
- Топ 5 WordPress тем зимы 2022-2023 года 01.01.2023
- Обзор темы для WordPress Druco 27.12.2022
- Организация путешествий: топ 5 тем для WordPress 26.11.2022
- Listygo: тема для каталогов онлайн и досок объявлений 24.11.2022
- Плагин Pimp my Site для создания праздничного настроения на сайте 22.11.2022
- Fashion темы для WordPress: ТОП5 10.11.2022
- SEO плагины WordPress: топ на 2023 год 03.11.2022
- Лучшие WordPress плагины для создания слайдеров и каруселей 26.10.2022
- Companion: WordPress тема для консалтинга и корпоративных страниц 19.10.2022
- Лучшие темы WordPress для IT-стартапов 15.09.2022
- Плагин для вывода новостей WP News and Scrolling Widgets 06.08.2022
- ТОП плагинов для защиты сайта на WordPress 04.08.2022
- Плагин Essential Grid Gallery: тысячи вариантов
для создания сеток изображений на сайте 20.06.2022 - Emyui – Отличная тема для малого бизнеса 23.05.2022
- Организуем SMS-рассылку с WordPress-сайта! Обзор Vonage for LatePoint 01.05.2022
- Предприятия не продают товары без этой темы! Обзор Megamau 13.04.2022
- Лучшие темы для интернет-магазина на март 2022. 30.03.2022
wp-config.php в WordPress
wp-config.php — это один из самый важных файлов в WordPress — базовый конфигурационный файл. Он находится в корневом каталоге (обычно рядом с остальными файлами и папками движка). Этот файл содержит настройки (конфигурации) WordPress.
ВАЖНО! Если указать константу в самом конце файла wp-config.php, то она работать не будет! Все константы нужно указывать до строки:
/** Sets up WordPress vars and included files. */ require_once ABSPATH . 'wp-settings.php';
Смотрите также: Все Константы WordPress.
Оглавление:
- Как создать wp-config.php
- База данных
- DB_NAME
- DB_USER
- DB_PASSWORD
- DB_HOST
- DB_CHARSET
- DB_COLLATE
- $table_prefix
- WP_DEBUG
- WP_ENVIRONMENT_TYPE
- Ключи безопасности (Security Keys)
- Заметки
- Остальные настройки
- WP_SITEURL и WP_HOME
- WP_CONTENT_DIR и WP_CONTENT_URL
- AUTOSAVE_INTERVAL
- WP_POST_REVISIONS
- EMPTY_TRASH_DAYS
- DISALLOW_FILE_EDIT
- DISALLOW_FILE_MODS
- AUTOMATIC_UPDATER_DISABLED
- IMAGE_EDIT_OVERWRITE
- ALLOW_UNFILTERED_UPLOADS
- WP_CACHE
- WP_HTTP_BLOCK_EXTERNAL
- FORCE_SSL_ADMIN
- WP_LANG_DIR
- WPLANG
- WP_MEMORY_LIMIT и WP_MAX_MEMORY_LIMIT
- WP_TEMP_DIR
- FS_CHMOD_DIR и FS_CHMOD_FILE
- COOKIE_DOMAIN
- UPLOADS
- WP_PLUGIN_DIR и WP_PLUGIN_URL
- WPMU_PLUGIN_DIR и WPMU_PLUGIN_URL
- Перемещение папки тем (themes)
- WP Cron
- WP_ALLOW_REPAIR
- CUSTOM_USER_TABLE и CUSTOM_USER_META_TABLE
- FS_METHOD — Константы обновления WordPress
- DO_NOT_UPGRADE_GLOBAL_TABLES
- Multisite
- WP_ALLOW_MULTISITE
- NOBLOGREDIRECT
- Пример wp-config.php
Как создать wp-config.php
Когда вы только скачали WordPress этого файла в папке нет, но есть wp-config-sample.php — это пример того как должен выглядеть wp-config.php .
Создать файл wp-config.php можно разными способами:
- Вручную. Для этого отредактируйте файл wp-config-sample.php и сохраните его как wp-config.php .
- Через WP CLI. Для этого используйте команду wp config create.
- Автоматически. При установке WP через браузер. Если в корне сайта нет файла wp-config.php и вы переходите на сайт в браузере, то вы увидите такое сообщение: Нажав на кнопку Создать файл настроек вы увидите форму в которой WP попросит вас ввести данные для генерации файла wp-config.php . В частности WordPress просит ввести информацию о подключении к базе данных: Все данные введенные в эту форму будут прописаны в файле wp-config.php в этих строках:
define('DB_NAME', 'database_name_here'); define('DB_USER', 'username_here'); define('DB_PASSWORD', 'password_here'); define('DB_HOST', 'localhost'); $table_prefix = 'wp_';
Как создавать и куда сохранять файл wp-config.php, думаю понятно. Теперь перейдем к конкретным константам и переменным, которые нужно или можно указать в wp-config.php.
База данных
Настройки подключения к базе данных вы получаете при создании базы данных в панели управления сервером или их передают вам администраторы сервера, если они создают базу данных за вас.
Открыв wp-config.php в каком-нибудь текстовом редакторе (я рекомендую sublime text), вы увидите подробное описание к каждой константе:
/** Параметры MySQL: Эту информацию можно получить у вашего хостинг-провайдера */ /** Имя базы данных для WordPress */ define( 'DB_NAME', 'database_name_here' ); /** Имя пользователя MySQL */ define( 'DB_USER', 'username_here' ); /** Пароль к базе данных MySQL */ define( 'DB_PASSWORD', 'password_here' ); /** Имя сервера MySQL */ define( 'DB_HOST', 'localhost' ); /** Кодировка базы данных для создания таблиц. */ define( 'DB_CHARSET', 'utf8' ); /** Схема сопоставления. Не меняйте, если не уверены. */ define( 'DB_COLLATE', '' );
DB_NAME
Содержит название вашей базы данных.
define( 'DB_NAME', 'my_database' );
DB_USER
Содержит имя пользователя вашей базы данных.
define( 'DB_USER', 'my_db_user' );
DB_PASSWORD
Содержит пароль пользователя вашей базы данных.
define( 'DB_USER', 'my_db_user_password' );
DB_HOST
Содержит домен, по которому нужно подключаться к Базе данных.
Разные хостинг-компании используют разные настройки подключения. Чаще всего эта константа равна localhost :
define( 'DB_HOST', 'localhost' );
Порт подключения к MySQL
Если в вашем хосте используется нестандартный порт для подключения к БД, то порт можно указать так.
define( 'DB_HOST', '127.0.0.1:3307' ); // or define( 'DB_HOST', 'localhost:3307' );
Для конкретного сервера:
define( 'DB_HOST', 'mysql.example.com:3307' );
Сокет или Pipe подключения к MySQL
define( 'DB_HOST', '127.0.0.1:/var/run/mysqld/mysqld.sock' ); // or define( 'DB_HOST', 'localhost:/var/run/mysqld/mysqld.sock' ); // or define( 'DB_HOST', 'example.tld:/var/run/mysqld/mysqld.sock' );
DB_CHARSET
По умолчанию: utf8 (Unicode UTF-8).
Содержит название кодировки для создаваемых таблиц Базы данных.
define( 'DB_CHARSET', 'utf8' );
Практически всегда utf8 — это лучший вариант. UTF-8 поддерживает любой язык. Обычно эту настройку не трогают и иногда меняют значение DB_COLLATE, подходящую для вашего языка.
Значение utf8 автоматически будет изменено на utf8mb4 для свойства wpdb::$charset, если кодировка utf8mb4 поддерживается сервером.
Обычно нет причин менять значение DB_CHARSET по умолчанию. Если для вашего блога требуется другой набор символов, прочтите Наборы символов поддерживаемые MySQL, для получения информации о доступных значениях DB_CHARSET.
ВНИМАНИЕ: Добавление DB_CHARSET и DB_COLLATE в файл wp-config.php для существующего сайта может привести проблемам.
Если в wp-config.php не указаны DB_CHARSET и DB_COLLATE, и вы точно не знаете что в них должно быть указано, то НЕ указывайте их (оставьте как есть).
DB_COLLATE
По умолчанию: » .
Содержит название сравнения (collation) для создаваемых таблиц Базы данных.
define( 'DB_COLLATE', '' );
Значение DB_COLLATE было добавлено для того, чтобы можно было указать collation базы данных (порядок сортировки набора символов).
В большинстве случаев это значение следует оставлять пустым (»). В этом случае MySQL сам определит нужный collate при создании таблицы на основе набора символов указанных DB_CHARSET.
Иногда нужно установить значение DB_COLLATE в одно из значений UTF-8. Это нужно когда, например для западноевропейского языка, отображается не тот символ который был введен. (См. также раздел Наборы символов Unicode в руководстве по SQL).
// UTF-8 Unicode General collation define( 'DB_COLLATE', 'utf8_general_ci' ); // UTF-8 Unicode Turkish collation define( 'DB_COLLATE', 'utf8_turkish_ci' );
ВНИМАНИЕ: Добавление DB_COLLATE в файл wp-config.php для существующего блога может привести к серьезным проблемам.
Если в wp-config.php не указано DB_COLLATE, и вы точно не знаете что там нужно указать, то НЕ указывайте ничего (оставьте как есть).
$table_prefix
По умолчанию: wp_
Переменная $table_prefix — содержит базовый префикс для всех таблиц базы данных.
$table_prefix = 'wp_';
С префиксом wp_ полные названия таблиц выглядят как: wp_posts , wp_terms и т.д.
В значении допускается только a-z0-9_ : латинские буквы (в нижнем регистре), цифры и знак подчеркивания _ :
Это значение меняют:
- Когда устанавливаются несколько WordPress сайтов и для всех них используется одна база данных. Так делать не рекомендуется из-за безопасности.
- Когда хотят повысить безопасность путём изменения дефолтного названия таблиц. Я не думаю, что это как-то повысит безопасность сайта.
Ни в коем случае нельзя менять этот префикс на уже рабочем сайте! Потому что после такой замены, вам придется переименовать все таблицы и некоторые названия опций в таблице wp_options, например опцию wp_capabilities — capabilities .
WP_DEBUG
По умолчанию: false
Включает дебаг режим.
define( 'WP_DEBUG', true );
Подробнее про дебаг режим и другие константы для дебага читайте здесь:
- WP_DEBUG_DISPLAY
- WP_DEBUG_LOG
- WP_DISABLE_FATAL_ERROR_HANDLER
- SAVEQUERIES
- SCRIPT_DEBUG
- CONCATENATE_SCRIPTS
WP_ENVIRONMENT_TYPE
По умолчанию: не установлена (соответствует типу production)
Определяет тип окружения для сайта. Возможные значения:
- local
- development
- staging
- production
Пример: Установим среду локальной разработки:
define( 'WP_ENVIRONMENT_TYPE', 'local' );
Далее в коде проверить текущую среду разработки, нужно через функцию wp_get_environment_type().
Если указано неправильное значение (не из списка возможных), то wp_get_environment_type() вернет значение по умолчанию: production .
ЗАМЕТКА: При установке типа окружения development автоматически включается дебаг режим — WP_DEBUG = true . Если константа WP_DEBUG не установлена. См. wp_initial_constants().
Ключи безопасности (Security Keys)
Секретные ключи защищают ваш сайт от хакерских атак, усложняя пароли и другие секретные данные.
Четыре ключа обязательны и необходимы для повышения безопасности. Четыре соли рекомендуются, но не являются обязательными, поскольку WordPress сам сгенерирует их, если они не указаны. Их стоит указать в wp-config.php для удобства, чтобы они постоянно не менялись.
Ключи должны быть длинными, случайными и сложными. Чтобы не писать их вручную, воспользуйтесь онлайн-генератором: https://api.wordpress.org/secret-key/1.1/salt/.
Ключи можно изменить в любое время, чтобы аннулировать все существующие cookies. После изменения всем пользователям придется войти в систему заново.
define( 'AUTH_KEY', 'rC$ `h-7|=FDvevE,tesQ4h< Ic2eB(e5n]y|wY*VN6pYAXo$qT#8Zj->D7M_b~1G6B|R:5Y=XgD(x oA|>:7Ex-q(y.m8!~,/&(wV.bF+3p_Hp+' ); define( 'NONCE_KEY', 'Ffv*n?P2J~8r0_)dHhK-n&oL1FKR;9t5sDL$|@#,HfwjMq~U[h&,wa,#YMk<$|j[pmUp`f5A@YFF6)N+[a&7-u+e92):cs' );
Более подробную информацию о технической стороне и разборе секретных ключей и безопасных паролей:
- Ryan Boren — SSL and Cookies in WordPress 2.6
- Объяснение взлома паролей в Википедии
- Lorelle VanFossen — Protect Your Blog With a Solid Password
- Instructables — Security Password Tips
- Huffington Post — 17 советов, которые вы можете сделать сегодня, чтобы защитить свои пароли в Интернете
Заметки
- Файл wp-config.php можно перемещать на одну директорию выше. Т.е. если файл находится в каталоге /public_html/wordpress/wp-config.php его можно переместить в каталог /public_html/wp-config.php при этом все будет работать как работало.
Остальные настройки
WP_SITEURL и WP_HOME
WP_SITEURL и WP_HOME переопределяют значение опции siteurl и home в таблице wp_options соответственно. Но они не изменяют эти значения в базе данных.
- siteurl — это URL адрес, по которому находятся ядро WordPress.
- home — это URL сайта (фронт-энд).
Обе эти константы должны начинаться с http:// и НЕ должны содержать / в конце.
define( 'WP_SITEURL', 'http://example.com' ); define( 'WP_HOME', 'http://example.com' );
Установка константы WP_SITEURL отменяет использование опции siteurl из таблице wp_options. Однако это не приведет к изменению значения в базе данных. Если эта константа будет удалена из wp-config, URL вернется к старому значению базы данных.
Для изменения значения siteurl в базе данных можно использовать константу RELOCATE:
define( 'RELOCATE', true );
Установка константы RELOCATE запустит проверку и (если нужно) обновление опции siteurl при попытке авторизоваться через https://example.com/wp-login.php .
Если WordPress установлен в директорию с именем «wp» для домена example.com, определите WP_SITEURL следующим образом:
define( 'WP_SITEURL', 'http://example.com/wp' ); define( 'WP_HOME', 'http://example.com' );
Динамическая установка на основе $_SERVER[‘HTTP_HOST’]:
define( 'WP_SITEURL', 'https://' . $_SERVER['HTTP_HOST'] . '/path/to/wordpress' ); define( 'WP_HOME', 'https://' . $_SERVER['HTTP_HOST'] );
Примечание: HTTP_HOST создается PHP динамически на основе данных из запроса, что может привести к возникновению уязвимостей, связанных с включением файлов. SERVER_NAME также может создаваться динамически. Однако, когда Apache сконфигурирован как UseCanonicalName=on , SERVER_NAME задается конфигурацией сервера, а не динамически. В этом случае безопаснее использовать SERVER_NAME, а не HTTP_HOST.
define( 'WP_SITEURL', 'http://' . $_SERVER['SERVER_NAME'] . '/path/to/wordpress' ); define( 'WP_HOME', 'http://' . $_SERVER['SERVER_NAME'] );
WP_CONTENT_DIR и WP_CONTENT_URL
Вы можете переместить каталог wp-content , в котором хранятся темы, плагины и загружаемые файлы, за пределы каталога WordPress.
Задайте в WP_CONTENT_DIR полный путь, а для WP_CONTENT_URL адрес к папке wp-content . Слэша на конце быть не должно:
define( 'WP_CONTENT_DIR', __DIR__ . '/blog/wp-content' ); define( 'WP_CONTENT_URL', 'http://example.com/blog/wp-content' );
AUTOSAVE_INTERVAL
По умолчанию: 60 (секунд).
При редактировании постов WordPress использует Ajax для автоматического сохранения изменений. Вы можете увеличить или уменьшить время задержек между авто-сохранениями.
Изменим интервал сохранения на 120 секунд (каждые 2 минуты):
define( 'AUTOSAVE_INTERVAL', 120 );
WP_POST_REVISIONS
По умолчанию: true
По умолчанию WordPress сохраняет копии всех правок, внесенных в посты (правка сохраняется когда вы сохраняете изменения). Это позволяет вернуться к предыдущей версии поста. Сохранение правок можно отключить или задать максимальное количество (сколько максимум правок должно сохраняться).
Если константа не установлена, то по умолчанию она будет равна true — ревизии включены.
Чтобы полностью отключить ревизии укажите false:
define( 'WP_POST_REVISIONS', false );
Чтобы ограничить максимальное кол-во хранимых ревизий, замените false на число (например, 5 или 10):
define( 'WP_POST_REVISIONS', 5 );
EMPTY_TRASH_DAYS
По умолчанию: 30
Отвечает за корзину WordPress. Эта константа определяет количество дней, после которых посты, страницы, вложения и комментарии будут безвозвратно удалены из корзины.
Удаляться из корзины будут не все посты, а только те, у которых с момента перемещения их в корзину прошло больше указанного времени.
Укажем, чтобы корзина хранила объекты 7 дней:
define( 'EMPTY_TRASH_DAYS', 7 ); // 7 days
define( 'EMPTY_TRASH_DAYS', 0 ); // Zero days
Примечание: При использовании этой настройки WordPress не будет запрашивать подтверждения при нажатии на кнопку «Удалить навсегда».
Подробнее о том как отключить корзину в WordPress читайте в этой статье (в том числе корзину для отдельных типов записей).
DISALLOW_FILE_EDIT
По умолчанию: не установлена
Позволяет отключить редактор файлов плагинов или тем.
define( 'DISALLOW_FILE_EDIT', true );
Такое отключение может пригодится, чтобы предотвратить возможность редактирования важных файлов, так как это может привести к поломке сайта. Также, такое отключение обеспечивает дополнительный уровень безопасности, в случае получения хакером доступа к привилегированной учетной записи пользователя.
Включение этой константы форсировано отключает у всех пользователей права:
edit_files edit_plugins edit_themes
Так, например, current_user_can(‘edit_plugins’) всегда будет возвращать false для всех юзеров. Если какой-то плагин полагается на такое право пользователя, то он может перестать правильно работать.
Я рекомендую всегда включать эту константу и редактировать файлы как-то еще, но не через админку WP!
DISALLOW_FILE_MODS
По умолчанию: не установлена
Отключает любую возможность модифицировать сайт из админки. В частности, отключает возможность устанавливать или обновлять плагины, темы. Отключает обновление ядра и файлов перевода.
define( 'DISALLOW_FILE_MODS', true );
Включение этой константы отключит автоматические обновления всего: тем, плагинов, ядра и переводов. А также форсировано отключит у всех пользователей следующие права:
edit_files edit_plugins edit_themes update_plugins delete_plugins install_plugins upload_plugins update_themes delete_themes install_themes upload_themes update_core install_languages update_languages
Установка этой константы также отключает редактор файлов плагинов и тем — делает тоже что и DISALLOW_FILE_EDIT. Т.е. нет смысла устанавливать DISALLOW_FILE_EDIT = true , поскольку установка DISALLOW_FILE_MODS = true будет иметь тот же эффект.
Если нужно отключить не все вышеуказанные права и функции, а только некоторые из них, то можно использовать хук file_mod_allowed.
AUTOMATIC_UPDATER_DISABLED
По умолчанию: не установлено
Отключает все автоматические обновления.
Могут быть причины, по которым сайт не подлежит авто-обновлению, например, пользовательские настройки или обновления, поставляемые хостом. Это также может быть сделано перед выпуском крупного релиза, чтобы дать время на тестирование в среде разработки, прежде чем разрешить обновление на рабочем сайте.
Чтобы отключить авто-обновления, добавьте такой код в wp-config.php:
define( 'AUTOMATIC_UPDATER_DISABLED', true );
Авто-обновления также можно отключить через хуки: automatic_updater_disabled и file_mod_allowed.
Чтобы отключить только авто-обновления ядра WordPress, используйте константы:
# Отключите все обновления ядра: define( 'WP_AUTO_UPDATE_CORE', false ); # Включите все обновления ядра, включая малые и большие: define( 'WP_AUTO_UPDATE_CORE', true ); # Включить обновление ядра для минорных релизов (по умолчанию): define( 'WP_AUTO_UPDATE_CORE', 'minor' );
Подробнее об авто-обновлениях читайте в статье: Авто-обновления в WordPress.
IMAGE_EDIT_OVERWRITE
По умолчанию: не установлено
По умолчанию WordPress создает новый набор изображений при каждом редактировании изображения, а при восстановлении оригинала оставляет все правки на сервере. Определение константы IMAGE_EDIT_OVERWRITE = true изменяет это поведение. Будет создается только один набор редактируемых изображений, а при восстановлении оригинала все редактируемые изображения будут удаляются с сервера.
define( 'IMAGE_EDIT_OVERWRITE', true );
ALLOW_UNFILTERED_UPLOADS
По умолчанию: не установлено
Включает работу права пользователя unfiltered_upload .
Право unfiltered_upload позволяет пользователям (ролям) загружать любые файлы, без проверки их типа.
- Администратор.
- Супер-администратор (в режиме мультисайт).
Однако это право по умолчанию не работает (заблокировано), т.е. указанные роли не пройдут проверку if( current_user_can(‘unfiltered_upload’) ) , несмотря на наличие у них такого права.
Чтобы право unfiltered_upload начало работать как обычно, нужно «включить» константу:
define( 'ALLOW_UNFILTERED_UPLOADS', true );
WP_CACHE
По умолчанию: false
Включает подключение файла wp-content/advanced-cache.php. Этот файл будет подключатся на о-очень раннем этапе загрузки WP. Этим пользуются плагины страничного кэширования, такие как WP Super Cache, Surge.
Включим подгрузку файла wp-content/advanced-cache.php , если он существует:
define( 'WP_CACHE', true );
WP_HTTP_BLOCK_EXTERNAL
По умолчанию: не установлено
Блокирует все внешние запросы через HTTP API.
По умолчанию HTTP API, может делать запросы на любые сайты. Если включить эту константу, то такие запросы будут разрешены только на свой домен:
define( 'WP_HTTP_BLOCK_EXTERNAL', true );
Если нужно разрешить и другие домены, то их нужно перечислить через запятую в константе WP_ACCESSIBLE_HOSTS . Тут также поддерживается знак * :
define( 'WP_ACCESSIBLE_HOSTS', 'api.wordpress.org, *.github.com' );
Подробнее смотрите код метода WP_Http::block_request().
FORCE_SSL_ADMIN
По умолчанию: true, если в опции siteurl указан https протокол, иначе false.
Форсировано включает https протокол для входа в систему (в админку), чтобы пароли и cookies никогда не передавались в открытом виде. Подробнее см. раздел Администрирование через SSL.
Когда эта константа включена, то при попытке зайти на страницу /wp-load.php , по http протоколу, вас перенаправит на https протокол. Также https, протокол будет установлен и в других защищенных местах, например для REST запросов из админки.
Включим https протокол для администрирования:
define( 'FORCE_SSL_ADMIN', true );
Константа FORCE_SSL_LOGIN .
До версии WP 4.0 вместо этой константы использовалась константа FORCE_SSL_LOGIN , теперь она устарела.
WP_LANG_DIR
По умолчанию: WP_CONTENT_DIR . ‘/languages’ или ABSPATH . WPINC . ‘/languages’ (когда папки WP_CONTENT_DIR/languages не существует)
Позволяет указать глобальную директорию, где лежат .mo файлы переводов. См. wp_set_lang_dir().
WPLANG
Устарела с версии WordPress 4.0.
Позволяла изменять язык сайта. Сейчас это делается из админки, со страницы: Настройки > Общие .
WP_MEMORY_LIMIT и WP_MAX_MEMORY_LIMIT
По умолчанию WP_MEMORY_LIMIT: 40M и 64M (для мультисайта)
По умолчанию WP_MAX_MEMORY_LIMIT: 256M
Позволяет увеличить объем памяти для PHP процесса.
Эти настройки могут понадобиться в случае получения сообщения типа «Allowed memory size of xxxxxx bytes exhausted».
Через обе эти константы WP попытается установить PHP опцию: ini_set( ‘memory_limit’ ) , если это позволяет сервер.
WP_MEMORY_LIMIT — устанавливает лимит для обычных запросов.
WP_MAX_MEMORY_LIMIT — устанавливает лимит для сред где нужно больше памяти, например, при обновлении ВП. ВП сам определяет где нужно больше памяти и использует эту константу в этих случаях.
По умолчанию WordPress будет пытаться увеличить память, выделенную PHP, до 40 МБ и до 64 МБ для multisite, поэтому нужно указывать значение, превышающее 40 МБ или 64 МБ.
Некоторые хостеры запрещают изменять PHP опцию ‘memory_limit’ через ini_set(). В этом случае обратитесь к хостеру.
Не нужно бездумно увеличивать лимита памяти — это может привести к проблемам. Так, вы можете скрыть проблемный участок кода, который выстрелит потом, когда на сайте возрастет посещаемость или в других случаях.
Если вы сталкиваетесь с проблемой Out of Memory даже при увеличенном лимите памяти, вам следует исправить код.
Смотрите связанные функции:
- wp_initial_constants()
- wp_raise_memory_limit()
define( 'WP_MEMORY_LIMIT', '64M' );
Увеличьте память PHP до 96 МБ
define( 'WP_MEMORY_LIMIT', '96M' );
Для выполнения задач администрирования может потребоваться больше памяти, чем для обычной работы. Находясь в области администрирования, память может быть увеличена или уменьшена по сравнению с WP_MEMORY_LIMIT путем определения WP_MAX_MEMORY_LIMIT.
define( 'WP_MAX_MEMORY_LIMIT', '128M' );
WP_TEMP_DIR
По умолчанию: sys_get_temp_dir() или ini_get( ‘upload_tmp_dir’ )
Абсолютный путь к каталогу для временных файлов. Обычно туда записываются временные файлы при обновлении плагинов, тем, ядра или при загрузке файлов.
FS_CHMOD_DIR и FS_CHMOD_FILE
По умолчанию FS_CHMOD_DIR: 0755 или выше, если у папки ABSPATH права выше.
По умолчанию FS_CHMOD_FILE: 0644 или выше если у файла index.php права выше.
Позволяют переопределять дефолтные права на создаваемые файлы/папки.
Эти настройки будут работать, только для папок/файлов обрабатываемых объектами файловой системы WordPress — См. WP_Filesystem(). Т.е. если вы будете использовать функции php вроде: mkdir(), copy(), то значения этих констант никак использоваться ну будут.
Значение нужно указывать в восьмеричной системе счисления, т.е. число должно начинатmся с 0 : 0644 , а не 644 . Эти значение по итогу передаются в параметр $permissions функции chmod().
Про схему прав для файлов WordPress читайте здесь.
Пример установки значений с оглядкой на настройки сервера:
define( 'FS_CHMOD_DIR', ( fileperms( ABSPATH ) & 0777 | 0755 ) ); define( 'FS_CHMOD_FILE', ( fileperms( ABSPATH . 'index.php' ) & 0777 | 0644 ) );
Пример: укажем права доступа жестко — без оглядки на настройки сервера:
define( 'FS_CHMOD_DIR', 0755 ); define( 'FS_CHMOD_FILE', 0644 );
Пример: Установим максимально возможные права 755 и 644. Тут, если текущая маска для создаваемых папок/файлов на сервере меньше указанных прав, то будет взята она. Например, если по дефолту, на сервере папки создаются с правами 700, то в этом случае FS_CHMOD_DIR будет равен 700. А если на сервере папки создаются с правами 777, то FS_CHMOD_DIR будет равно 755.
define( 'FS_CHMOD_DIR', ( 0755 & ~ umask() ) ); define( 'FS_CHMOD_FILE', ( 0644 & ~ umask() ) );
Пример: установим права вместе с setgid (set group ID). Тут, результирующее значение FS_CHMOD_DIR — это модифицированное значение разрешения файловой системы, в котором для каталога установлено разрешение setgid (включен бит group execute). Это означает, что все новые файлы и каталоги, созданные внутри каталога, будут наследовать групповое право родительского каталога.
define( 'FS_CHMOD_DIR', ( 02755 & ~umask() ) );
COOKIE_DOMAIN
По умолчанию: false (текущий домен)
Позволяет изменить домен указываемый при установки COOKIE.
Пятый параметр функции setcookie():
(Под)домен, которому доступны cookie. Задание поддомена (например, ‘www.example.com’) сделает cookie доступными в нем и во всех его подменах (например, w2.www.example.com). Для того, чтобы сделать cookie доступными для всего домена (включая поддомены), нужно просто указать имя домена (то есть ‘example.com’).
Старые браузеры, следующие устаревшему документу » RFC 2109, могут требовать . перед доменом, чтобы включались все поддомены.
Указывать эту константу нужно, когда у вас необычная настройка домена. Например, если для обслуживания статического содержимого используются под-домены, можно установить в качестве домена cookie только ваш нестатический домен, чтобы предотвратить отправку файлов cookie WordPress при каждом запросе к статическому содержимому на вашем под-домене.
define( 'COOKIE_DOMAIN', 'example.com' );
Смотрите все возможные константы связанные с куками в коде функций:
- wp_cookie_constants()
- ms_cookie_constants() для мультисайта.
Другие константы связанные с куками:
define( 'COOKIEHASH', md5( $siteurl ) );
define( 'USER_COOKIE', 'wordpressuser_' . COOKIEHASH );
define( 'PASS_COOKIE', 'wordpresspass_' . COOKIEHASH );
define( 'AUTH_COOKIE', 'wordpress_' . COOKIEHASH );
define( 'SECURE_AUTH_COOKIE', 'wordpress_sec_' . COOKIEHASH );
define( 'LOGGED_IN_COOKIE', 'wordpress_logged_in_' . COOKIEHASH );
define( 'TEST_COOKIE', 'wordpress_test_cookie' );
define( 'COOKIEPATH', preg_replace( '|https?://[^/]+|i', '', get_option( 'home' ) . '/' ) );
define( 'SITECOOKIEPATH', preg_replace( '|https?://[^/]+|i', '', get_option( 'siteurl' ) . '/' ) );
define( 'ADMIN_COOKIE_PATH', SITECOOKIEPATH . 'wp-admin' );
define( 'PLUGINS_COOKIE_PATH', preg_replace( '|https?://[^/]+|i', '', WP_PLUGIN_URL ) );
define( 'COOKIE_DOMAIN', false );
define( 'RECOVERY_MODE_COOKIE', 'wordpress_rec_' . COOKIEHASH );
UPLOADS
По умолчанию: не установлена
Позволяет переместить папку /wp-content/uploads .
Константа используется в функции _wp_upload_dir().
Применяется для определения пути и УРЛ до папки загрузок.
Должна содержать путь, относительно константы ABSPATH и УРЛ относительно опции siteurl (или константы WP_SITEURL).
Не должна содержать слэш / в начале и конце!
Пример, вынесем папку загрузок в корневой каталог files , т.е. УРЛ будет таким https://example.com/files :
define( 'UPLOADS', 'files' );
Я не рекомендую перемещать папку UPLOADS без очень веской на то причины!
WP_PLUGIN_DIR и WP_PLUGIN_URL
По умолчанию WP_PLUGIN_DIR: WP_CONTENT_DIR . ‘/plugins’
По умолчанию WP_PLUGIN_URL: WP_CONTENT_URL . ‘/plugins’
Позволяет переместить папку плагинов. Не должно содержать слэш / на конце!
Не рекомендую перемещать папку плагинов без очень веской на то причины! Потому что не все плагины правильно умеют работать с нестандартным путём. И в целом — это может вызвать кучу проблем из-за нестандартного пути.
Пример: переместим папку плагинов в другое место:
define( 'WP_PLUGIN_DIR', __DIR__ . '/wp-plugins' ); define( 'WP_PLUGIN_URL', 'http://example.com/wp-plugins' );
Есть также устарелая константа PLUGINDIR — это старый вариант константы WP_PLUGIN_DIR .
Некоторые плагины могут использовать именно её. Поэтому если у вас возникают какие-то проблемы со старым плагином, возможно вам нужно установить также значение и этой константы:
define( 'PLUGINDIR', WP_PLUGIN_DIR );
WPMU_PLUGIN_DIR и WPMU_PLUGIN_URL
По умолчанию WPMU_PLUGIN_DIR: WP_CONTENT_DIR . ‘/mu-plugins’
По умолчанию WPMU_PLUGIN_URL: WP_CONTENT_URL . ‘/mu-plugins’
Позволяет переместить папку обязательных плагинов.
Не должно содержать слэш / на конце!
Не рекомендую перемещать папку мю-плагинов без очень веской на то причины!
Пример: переместим папку мю-плагинов в другое место:
define( 'WPMU_PLUGIN_DIR', __DIR__ . '/force-plugins' ); define( 'WPMU_PLUGIN_URL', 'http://example.com/force-plugins' );
Есть также устарелая константа MUPLUGINDIR — это старый вариант константы WPMU_PLUGIN_DIR .
Некоторые плагины могут использовать именно её. Поэтому, если у вас возникают какие-то проблемы со старым плагином, возможно вам нужно установить также значение и этой константы:
define( 'MUPLUGINDIR', WPMU_PLUGIN_DIR );
Перемещение папки тем (themes)
Переместить папку themes невозможно, поскольку ее путь жестко задан относительно папки wp-content:
$theme_root = WP_CONTENT_DIR . '/themes';
Однако вы можете зарегистрировать дополнительные каталоги тем с помощью функции register_theme_directory().
Подробнее о том, как определяется папка themes, см. в файле wp-includes/theme.php.
WP Cron
Подробно о том как работает WP Cron и как его настраивать смотрите в отдельной статье.
Ниже приведу константы связанные с кроном.
Включим альтернативный метод запуска крон задач:
Браузер пользователя получает перенаправление от PHP, когда необходимо запустить cron. Таким образом, он сразу же возвращается на сайт, в то время как cron продолжает работать. Этот метод имеет определенные риски, поскольку зависит от неродного сервиса WordPress.
define( 'ALTERNATE_WP_CRON', true );
Полное отключение Сron
Я не рекомендую этого делать, потому что на кроне выполняются важные задачи, например удаление записей из корзины, очистка авто-черновиков и т.д.
define( 'DISABLE_WP_CRON', true );
Ограничение повторного запуска Cron
Установим минимальный лимит времени (в секундах) между запусками Cron процессов:
define( 'WP_CRON_LOCK_TIMEOUT', 60 );
WP_ALLOW_REPAIR
По умолчанию: не установлено
Включает поддержку автоматического восстановления базы данных:
define( 'WP_ALLOW_REPAIR', true );
После установки этой константы перейдите по ссылке:
https://example.com/wp-admin/maint/repair.php
Эту функцию следует включать только в случае необходимости и отключать после решения проблемы. Если эта функция включена, на указанную страницу может зайти любой пользователь, поскольку ее основная цель — восстановление поврежденной базы данных, когда невозможно войти в систему.
CUSTOM_USER_TABLE и CUSTOM_USER_META_TABLE
Позволяют переопределить названия таблиц где хранятся данные пользователей. В этом случае дефолтные таблицы пользователей использоваться не будут, а будут вместо них использоваться таблицы указанные в этих константах.
define( 'CUSTOM_USER_TABLE', 'myprefix_users' ); define( 'CUSTOM_USER_META_TABLE', 'myprefix_usermeta' );
Такой трюк позволяет устанавливать разные WP сайты в одну базу данных и при этом у всех сайтов будут одни и те же пользователи.
Однако, в дополнении к этим константам нужно также учесть и другие моменты. Например, у всех сайтов должны быть одинаковые секретные ключи.
Подробнее про все условия смотрите в этом видео:
- Устанавливаете первый сайт как обычно.
- После установки, добавляете в wp-config.php эти константы. Префикс таблиц нужно захардкодить.
- Создаете второй сайт и копируете в него wp-config.php из первого сайта. И измените $table_prefix для второго сайта. При этом префикс для таблиц пользователя должен остаться такой какой был при первой установке (захардкоженный).
- Установите второй сайт. В этом случае вам не будет предложено ввести данные пользователя.
- После установки, при попытке войти в админку вы увидите ошибку, что у вас недостаточно прав. Это потому что в таблице wp_usermeta есть опция wp_capabilities где префикс должен совпадать с текущим префиксом $table_prefix. Но у второй установки префикс другой, поэтому для второй установки как бы нету этой опции. Решить эту проблему поможет плагин: WP-Orphanage Extended.
FS_METHOD — Константы обновления WordPress
- Про авто-обновления WordPress читайте здесь.
- Смотрите также WP_Filesystem().
Примечание: Определите столько констант, сколько необходимо для устранения проблем с обновлением.
Наиболее распространенными причинами необходимости определить следующие константы являются:
- Работа хоста со специальной установкой, включающей симлинки. Может потребоваться определение констант, связанных с путями ( FTP_BASE , FTP_CONTENT_DIR и FTP_PLUGIN_DIR ). Часто достаточно определить просто базу.
- Некоторые версии PHP поставляются с расширением PHP FTP, которое несовместимо с некоторыми FTP-серверами. В этих редких ситуациях может потребоваться определить FS_METHOD как «ftpsockets» .
Ниже приведены допустимые константы для обновлений WordPress:
- FS_METHOD определяет метод работы с файловой системой. Может быть только: «direct», «ssh2», «ftpext» или «ftpsockets». Как правило, этот параметр следует изменять только в случае проблем с обновлением. Если вы изменили этот параметр и он не помог, верните его обратно или удалите.
- (1-е предпочтение) direct — PHP работает с файловой системой напрямую. Это чревато проблемы безопасности на плохо настроенных серверах. Выбирается автоматически по возможности.
- (2-е предпочтение) ssh2 — использует SSH PHP-расширение, если оно установлено.
- (3-е предпочтение) ftpext — принудительное использование расширения FTP PHP для доступа к FTP.
- (4-е предпочтение) ftpsockets — использует класс PHP Sockets для доступа к FTP.
Пример значений констант:
define( 'FS_METHOD', 'ftpext' ); define( 'FTP_BASE', '/path/to/wordpress/' ); define( 'FTP_CONTENT_DIR', '/path/to/wordpress/wp-content/' ); define( 'FTP_PLUGIN_DIR ', '/path/to/wordpress/wp-content/plugins/' ); define( 'FTP_PUBKEY', '/home/username/.ssh/id_rsa.pub' ); define( 'FTP_PRIKEY', '/home/username/.ssh/id_rsa' ); define( 'FTP_USER', 'username' ); define( 'FTP_PASS', 'password' ); define( 'FTP_HOST', 'ftp.example.org' ); define( 'FTP_SSL', false );
В некоторых конфигурациях для параметра FTP_HOST следует установить значение localhost , чтобы избежать проблем с 503 ошибкой при попытке обновления плагинов или самого WP.
Включение доступа к обновлению по SSH
Существует два способа обновления с помощью SSH2.
- Первый — использовать плагин SSH SFTP Updater Support.
- Второй — использовать встроенную программу обновления SSH2, для чего необходимо установить расширение pecl SSH2.
Для установки расширения pecl SSH2 необходимо выполнить команду, аналогичную следующей, или обратиться к своему хостинг-провайдеру для его установки:
pecl install ssh2
После установки расширения pecl ssh2 необходимо изменить конфигурацию PHP для автоматической загрузки этого расширения.
pecl поставляется в пакете pear в большинстве дистрибутивов linux.
Для установки pecl в Redhat/Fedora/CentOS :
yum -y install php-pear
Для установки pecl в Debian/Ubuntu:
apt-get install php-pear
Рекомендуется использовать закрытый ключ, не защищенный парольной фразой. Имеются многочисленные сообщения о том, что закрытые ключи, защищенные парольной фразой, работают некорректно. Если вы решили использовать закрытый ключ, защищенный парольной фразой, то при установке обновлений вам необходимо ввести парольную фразу для закрытого ключа в FTP_PASS или ввести ее в поле «Пароль» в представленном поле учетных данных.
DO_NOT_UPGRADE_GLOBAL_TABLES
По умолчанию: не установлена
Определение константы DO_NOT_UPGRADE_GLOBAL_TABLES не позволяет функции dbDelta() и функциям обновления выполнять дорогостоящие запросы к глобальным таблицам.
Сайты, имеющие большие глобальные таблицы (в частности, users и usermeta), а также сайты, имеющие общие таблицы пользователей с bbPress и другими установками WordPress, могут предотвратить изменение этих таблиц в процессе обновления, задав для параметра DO_NOT_UPGRADE_GLOBAL_TABLES значение true.
Поскольку выполнение ALTER, а также неограниченных DELETE или UPDATE может занять много времени, крупные сайты обычно хотят избежать их выполнения в процессе обновления и провести нужные обновления самостоятельно.
Кроме того, если таблицы пользователей используются совместно несколькими установками bbPress и WordPress, возможно, стоит выбрать один сайт в качестве мастера обновления.
Для проверки нужно ли обновлять глобальные таблицы в функциях обновления используется функция: wp_should_upgrade_global_tables().
Multisite
WP_ALLOW_MULTISITE
По умолчанию: false.
Включает multisite функциональность. Подробнее см. Установка Мультисайта.
define( 'WP_ALLOW_MULTISITE', false );
NOBLOGREDIRECT
Используется для перенаправления браузера, если посетитель пытается обратиться к несуществующему подсайту:
define( 'NOBLOGREDIRECT', 'http://example.com' );
Перенаправляем на главный сайт сети:
define( 'NOBLOGREDIRECT', '%siteurl%' );
Для главного сайта сети, если эта константа установлена, то все 404 страницы будут редиректить на указанный тут УРЛ.
Для более правильного редиректа рекомендуется использовать хук ms_site_not_found вместо этой константы.
Пример wp-config.php
Пример wp-config.php указан в файле wp-config-sample.php. Посмотрим его код:
. * * You can change these at any point in time to invalidate all existing cookies. * This will force all users to have to log in again. * * @since 2.6.0 */ define( 'AUTH_KEY', 'put your unique phrase here' ); define( 'SECURE_AUTH_KEY', 'put your unique phrase here' ); define( 'LOGGED_IN_KEY', 'put your unique phrase here' ); define( 'NONCE_KEY', 'put your unique phrase here' ); define( 'AUTH_SALT', 'put your unique phrase here' ); define( 'SECURE_AUTH_SALT', 'put your unique phrase here' ); define( 'LOGGED_IN_SALT', 'put your unique phrase here' ); define( 'NONCE_SALT', 'put your unique phrase here' ); /**#@-*/ /** * WordPress database table prefix. * * You can have multiple installations in one database if you give each * a unique prefix. Only numbers, letters, and underscores please! */ $table_prefix = 'wp_'; /** * For developers: WordPress debugging mode. * * Change this to true to enable the display of notices during development. * It is strongly recommended that plugin and theme developers use WP_DEBUG * in their development environments. * * For information on other constants that can be used for debugging, * visit the documentation. * * @link https://wordpress.org/documentation/article/debugging-in-wordpress/ */ define( 'WP_DEBUG', false ); /* 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';