Где находится wp config php
Перейти к содержимому

Где находится wp config php

  • автор:

Как редактировать 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

Вот так выглядит наш файл:

Как редактировать wp-config.php файл в WordPress

Рассмотрим подробнее каждый раздел.

Настройки MySQL в wp-config.php

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

подробнее

Все эти данные вы моете найти в учетной записи вашего хостинга.

Ключи аутентификации

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

Как редактировать wp-config.php файл в WordPress

Префикс Таблицы БД

WordPress всегда добавляет префикс wp_ ко всем таблицам, созданным WordPress. Желательно заменить его собственным префиксом, чтобы затруднить работу взломщикам. Это можно сделать с помощью плагина WP Security.

Как редактировать wp-config.php файл в WordPress

Режим Отладки WordPress

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

define(‘WP_DEBUG’, false);
define(‘WP_DEBUG’,true);

Параметры Абсолютного Пути

Абсолютный путь используется для установки WordPress переменных и включенных файлов. Здесь лучше ничего не менять.

Как редактировать wp-config.php файл в WordPress

Другие wp-config.php хаки

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

Изменение url WordPress с помощью wp-config.php

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

Как редактировать wp-config.php файл в 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

Ищете курс по PHP, чтобы расширить свои знания в области веб-разработки? Переходите Read more

transfer WP site from localhost

Localhost нужен для того, чтобы абсолютно бесплатно и спокойно создать Read more

Как Создать И Настроить Дочернюю Тему WordPress

Итак, вы создали свой сайт, выбрали подходящую тему, но не Read more

Как сделать сайт с WordPress и Elementor

Не у всех есть технические навыки, чтобы создать рабочий веб-сайт. Read more

Что такое .htaccess в WordPress и как его использовать

Вы можете совершать множество изменений на своем сайте WordPress, не Read more

установка темы на WordPress

Существует два способа с помощью которых можно установить wordpress тему: Установка Read more

Где находится конфигурационный файл WordPress?

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

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

define( 'DB_NAME', 'НАВЗВАНИЕ БАЗЫ ДАННЫХ' ); define( 'DB_USER', 'ИМЯ ПОЛЬЗОВАТЕЛЯ БАЗЫ ДАННЫХ' ); define( 'DB_PASSWORD', 'ПАРОЛЬ ОТ ПОЛЬЗОВАТЕЛЯ БАЗ ДАННЫХ' ); define( 'DB_HOST', 'СЕРВЕР РАЗМЕЩЕНИЯ БАЗЫ ДАННЫХ' ); $table_prefix = 'ПРЕФИКС НАЗВАНИЯ ТАБЛИЦ, КОТОРЫЕ ИСПОЛЬЗУЮТСЯ В БАЗЕ ДАННЫХ';

При переносе сайта к нам на хостинг, важно корректно заполнить все эти данные.

Корректно скопировать их из панели управления, Вы можете при помощи инструкций из [РАЗДЕЛА MYSQL]

Все категории вопросов

  1. Общие вопросы по услуге хостинга
  2. Робота с хостинг 2.0
  3. Работа с базами данных [MySQL]
  4. Работа с FTP
  5. Работа с SSH
  6. Работа с почтой
  7. Работа с Cron
  8. Работа с SSL
  9. Работа с резервным копированием
  10. Работа с htaccess
  11. Работа с CMS
  12. Дополнительные услуги
  13. Нагрузка
  14. Ошибки на сайте
  15. Конструктор сайтов
  1. Регистрация и продление доменов
  2. Управление DNS-записями домена
  3. Трансфер домена
  4. Смена контактных данных владельца домена
  5. Настройка CloudFlare
  1. Общие вопросы по серверам
  2. Администрирование виртуального сервера (VPS)
  3. Администрирование выделенного сервера (DS)
  4. Инструкции по Windows Server
  5. Инструкции по Linux
  6. Панель управления FASTPANEL
  7. Панель управления Hestia CP
  8. Панель управления Vesta CP
  1. Платный SSL-сертификат
  2. Файловое хранилище
  3. SMS-сервис
  4. 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

зачем нужен 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

Некорректные установки 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 ); // отключение корзины, по умолчанию включена;

программный код, возможно wp-config.php

В 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-сайте. О том, как монетизировать рейтинги, можно почитать здесь.

A-Feed: автоматическое наполнение 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-config.php Нажав на кнопку Создать файл настроек вы увидите форму в которой WP попросит вас ввести данные для генерации файла wp-config.php . В частности WordPress просит ввести информацию о подключении к базе данных: создание файла wp-config.php Все данные введенные в эту форму будут прописаны в файле 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:

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *