Where is the PHP.ini File in WordPress? How to Find and Edit its Settings

PHP.ini is an important WordPress file that you can configure to extend your site’s functionality and improve its performance. Although the file is relatively easy to work with, you might not know how to locate and edit its settings.
Fortunately, this straightforward guide can help you easily locate your PHP.ini file in WordPress. Then, you’ll be able to edit and configure it to maximize your site’s performance.
Let’s take a closer look at PHP.ini and show you where to find it. Then, we’ll discuss three ways to edit it and boost your site’s performance.
What is the PHP.ini file?
WordPress executes several programming languages in the browser, including CSS, HTML, and JavaScript. Additionally, it uses PHP to generate and serve those languages.
In other words, PHP is the scripting language used by WordPress on the server side of operations. Through PHP, WordPress is able to display all of a website’s content, like blog posts, products, and more.
PHP.ini is the default configuration file for PHP on your WordPress site. You can change its default settings and run applications requiring the PHP scripting language. Overall, it’s a pretty important file when it comes to your site’s functionality and performance.
When would editing the PHP.ini file be required?
Although PHP is essential to WordPress, it has pretty limited default configuration settings. Fortunately, thanks to PHP.ini, you can override the default values for the following settings:
- Maximum file size upload. Increasing this limit is ideal if you run a photography website or any other content-heavy site. Since videos and images tend to have large file sizes, editing this setting will enable you to upload heavier clips and photos.
- File timeouts. When a file takes too long to process, your website will return an error message and stop processing the request. You can increase the number of seconds allowed before your upload times out.
- Resource limits. You can increase the memory available to upload files and run commands. Plus, if you write long blog posts or add plenty of images to your site, you might increase the maximum post size to accommodate more data.
- Maximum execution time. This setting determines the number of seconds a script is allowed to run before it gets terminated by the parser. As such, it helps prevent poorly-written scripts from draining your server.
Essentially, by editing these PHP configurations, you’re able to extend your site’s functionality and improve performance. Additionally, you might also want to edit PHP.ini in WordPress to enable or disable file extensions.
For example, a common error that you may see is “Your PHP is missing the MySQL extension.” In this instance, editing the PHP.ini file can enable the extension and clear the error message.
Can all WordPress site owners edit their PHP.ini files?
This depends on your server environment and system. Typically, it’s up to your WordPress hosting provider to allow access to the file. If PHP.ini is inaccessible, you may need to contact your host for support and see if they’ll help you edit it.
Certain hosting types are less likely to give users access to the PHP.ini file. For instance, a shared hosting setup consists of multiple websites hosted on a single server. It’s a great way to reduce costs, but you won’t have root access to your server.
By contrast, you’re more likely to have access to your PHP.ini file if you’ve signed up for a Virtual Private Server (VPS), dedicated server, or reseller hosting plan. In these setups, you’re not sharing resources with other sites, so you have more freedom to configure your website’s server.
Fortunately, if you don’t have direct access to the PHP.ini file in WordPress, there are some useful workarounds that can achieve the same results. Let’s take a quick look at two of them:
1. Edit your .htaccess file
Editing PHP.ini can increase your site’s maximum execution time. But if you don’t have access to the file, you can also adjust this setting in .htaccess.
First, you must access your website files via FTP or File Manager. Then, find the root directory of your site. This is usually labeled public_html.
Open the .htaccess file and paste the following code into the editor:
php_value max_execution_time = X
Replace the “X” with an amount of time in seconds. Inserting “60” will increase the maximum execution time to one minute, giving your website more time to load scripts before terminating the process.
2. Edit your wp-config.php file
Additionally, you may want to eliminate the run time limit in WordPress. This setting controls the time your site will spend on an operation before timing out. At that point, your site will return an error.
To extend the time limit, locate your wp-config.php file and paste the following code into the editor:
set_time_limit = 60
If the code is already there from work you’ve done previously, simply change the value to 60. You can exceed 60 seconds, but doing so may be risky since the setting is in place to protect your system from poorly-written scripts.
Where is the PHP.ini file located?
By now, you should have a basic idea of the purpose of the PHP.ini file. Now you might be wondering: where is PHP.ini in WordPress?
If you have a PHP.ini file, you’ll usually find it in the root directory of your WordPress site. If not, you can create a new file for your website, which we’ll show you how to do in the next part of this article.
There are also different locations if you’re working in a local environment. If you’re a WAMP user, you can locate your WordPress PHP.ini file by right-clicking on the program icon. Then, head to PHP → php.ini.
In XAMPP, all you need to do is open the program and click on Config. Then, find the php.ini option within the menu.
Finally, using Linux, you can typically locate your PHP.ini file in the Loaded Configuration File. To access this, you’ll need to enter the following code below the terminal:
PHP –I | grep “Loaded Configuration File”
You should receive the following output:
Loaded Configuration File => /usr/local/lib/php.ini
If you still can’t find your PHP.ini file’s location in WordPress, it’s time to contact your web host or create your own file. Let’s look at how this process works.
What to do before editing your PHP.ini file
Before making any changes to your site files, including PHP.ini, it’s a good idea to make a fresh backup of your site. That way, if you make any mistakes, you’ll be able to revert your site to an earlier version in just seconds.
If you don’t already have a WordPress backup plugin, consider installing Jetpack VaultPress Backup.

Not only does VaultPress back up your entire website, but it also stores copies of your database, your site files, and all WooCommerce customer and order data.
How to open and edit your WordPress PHP.ini file
There are several reasons you may want to edit your PHP.ini file. Here are some of the recommended configurations that might be useful:
max_execution_time = 180 memory_limit = 128M post_max_size = 64M upload_max_filesize = 64M max_input_time = 60 file_uploads = On safe_mode = Off
Adjusting the maximum execution time will increase the time available to execute every script on your site. Essentially, this refers to the time the server needs to run the commands, so it can be handy if you have heavy scripts.
The memory limit enables you to restrict and expand the memory usage of PHP. Generally, this concerns the memory needed to upload files and run commands on your site.
Post max size defines the maximum data a post can have. So, if you have plenty of images on your pages or write super long blog posts, you might want to increase this value.
Additionally, you can increase the upload max file size. This is a helpful setting for photographers or other creatives who need to upload heavy media files like videos.
However, before you can make these edits, you’ll need to locate an existing PHP.ini file or create a new one. Keep in mind that if you’re using shared hosting, you may be unable to follow these steps.
1. Use an FTP client
Using an FTP client is one of the easiest ways to find and access your PHP.ini WordPress file. Once you’ve got a current backup in place, it’s time to connect to your site via FTP.
If you don’t already have one installed, you’ll need to find an FTP client like FileZilla and download it to your computer.

Then, you can connect to your site via FTP to access your site’s files. Just enter your FTP credentials to establish a connection (which you can typically get from your hosting provider).
Once the connection is made, locate the root directory of your site. This is usually labeled public_html or public.

If you have a PHP.ini file, you should see it in this folder. If you can’t find it, you can locate it manually by creating a new PHP file and pasting the following code into it:
Update the file by saving your changes. At this point, open the file in your browser to identify the correct file path.
Simply type your website’s URL followed by the file name you chose into the search bar. This might look something like this: yourwebsite.com/file-name.php.
This should launch a page in your browser with information about your PHP installation, including the file path for your PHP.ini file. You can find this information within the Configuration File Path or Loaded Configuration File field.
Once you’ve opened the php.ini file, enter your custom directives. You can check out this list of common PHP.ini directives and syntax rules to configure the file correctly.
Finally, save your file! The settings should start taking effect within a few minutes.
2. Use cPanel
cPanel is a common control panel tool included in many hosting provider dashboards. It’s pretty straightforward and easy to use.
First, you’ll need to log in to your hosting account and locate the cPanel File Manager. Then, open your public_html folder.

Here, you’ll want to look for your PHP.ini file by its name. Note that it might also be hidden, so click on Settings and check the box next to Show Hidden Files (dotfiles).

If you still can’t find it, click on New file and name it “php.ini”. Make your edits, save the file, and your site should start showing the changes within a few minutes.
Depending on your hosting account dashboard, you may also have access to the MultiPHP INI Editor. This tool enables you to configure your PHP settings from a list of available directives. Keep in mind that the editor is typically only available with VPS, dedicated server, or reseller hosting plans.
3. Utilize a WordPress file manager plugin
File manager plugins enable you to easily edit your website’s files without playing around on the back end. Therefore, using a plugin is an accessible, quick, and beginner-friendly way to access your WordPress PHP.ini file.
With a file manager plugin, you’ll typically get access to a clean, intuitive interface to manage, upload, download, and even back up and restore files. One of the most popular options is Advanced File Manager.

To edit your PHP.ini file with Advanced File Manager, you’ll need to install the plugin in WordPress. In your dashboard, navigate to Plugins → Add New. Then, search for “Advanced File Manager” and click on Install Now → Activate.

Once the tool has been installed successfully, head to File Manager → File Manager to access the plugin’s interface.

You may be able to find PHP.ini within the file list. Otherwise, click on New file and select txt to create a simple text file. You’ll be prompted to name the file, so call it “php.ini”.
Next, select the newly created file and click on Edit file. Then, input your code, along with any custom configurations.
Again, make sure to save your changes when you’re done to finish setting up your WordPress PHP.ini file.
Frequently asked questions about the PHP.ini file
We’ve just covered the basics of finding and editing your PHP.ini file in WordPress. If you still have any questions, we’ll answer them in this section!
What if I don’t have access to the PHP.ini file? Can I still edit my PHP settings?
If you can’t access your PHP.ini file, you may be able to edit your PHP settings by creating a new PHP.ini file via FTP, File Manager, or a file manager plugin. Keep in mind that this typically isn’t available for shared hosting plans. Alternatively, you can configure some PHP settings using .htaccess and wp-config.php.
Can I create a new PHP.ini file to overwrite my hosting provider’s file?
In some cases, it’s possible to override PHP settings by creating a new PHP.ini file. If this doesn’t work, you’ll need to contact your hosting provider directly. You may need to switch to a different hosting configuration, like VPS or dedicated hosting.
Do PHP.ini changes take effect immediately?
PHP.ini changes often take effect immediately or within a few minutes. If you’ve made edits, but your site’s configuration hasn’t changed, you may be editing the file in the wrong directory.
Can your WordPress site’s PHP.ini file be hacked?
Although it’s not very common, your WordPress website can be hacked via its PHP.ini file. That’s why it’s worth investing in a high-quality hosting provider with strict security protocols, along with WordPress security plugins.
Locate and edit your PHP.ini file
Editing the PHP.ini file is a great way to extend the functionality of your site and configure its PHP settings. But you might not know how to carry out these changes.
To recap, here are three ways to locate and edit PHP.ini:
- Use an FTP client.
- Use cPanel within your hosting account dashboard.
- Utilize a file manager plugin like Advanced File Manager.
Before you start editing any of your site files, it’s important to back up your site. Jetpack VaultPress Backup backs up all your database tables, website files, and WooCommerce data, so you’ll never lose your content. Better yet, it’s super simple to restore your site if anything goes wrong.
This entry was posted in Learn. Bookmark the permalink.
Jen is a Happiness Engineer for Jetpack. She has been working with WordPress and Jetpack for over a decade. Prior to starting at Automattic, Jen has helped small businesses, local non-profits, and Fortune 50 companies create engaging web experiences for their customers. She is passionate about teaching others how to create on the web without fear.
Explore the benefits of Jetpack
[UPDATED 2021] Оптимальные настройки php для WordPress
При работе с WordPress без настроек в php.ini, Вы рано или поздно столкнетесь с ошибками, сообщающими, что:
- «Размер загруженного файла превышает upload_max_filesize»
- «exceeds the maximum upload size for this site»
- «Fatal Error: Maximum execution time of 30 seconds exceeded»
Или любым другим сообщением, связанным с ограничениями php.ini.
Эти проблемы, такие как белый экран, сбой импорта демоконтента, пустое содержимое страницы и другие связаны с стандартными ограничения в PHP WordPress.
Версия PHP для WordPress
На момент написания статьи (Декабрь 2020), оптимальный PHP для WordPress — PHP 7.4, так как WordPress, темы и плагины ещё криво работают на PHP 8, а в PHP меньше чем 7.4 и 5.x отсутствуют необходимые патчи безопасности и хуже производительность.

Сравнение производительности разных версий PHP для WordPress 5.3
Важно обновлять WordPress, темы, плагины, библиотеки, версию PHP для высокой производительности сайта, новых функций, совместимости компонентов и повышения безопасности.
Директивы php.ini для WordPress
В зависимости от хостинга и панели управления, php.ini находится в разных местах, уточните у вашего хостинг-провайдера. У меня на sprinthost.ru это выглядит так:

Директивы, которые надо вставить в php.ini:
upload_max_filesize = 64M post_max_size = 128M memory_limit = 256M max_execution_time = 600 max_input_vars = 5000 max_input_time = 400 zend.enable_gc = On
Пояснения директив php.ini для WordPress:
upload_max_filesize — максимальный размер ОДНОГО загружаемого на сайт файла
post_max_size — максимальный размер POST запросов / должен быть больше или равен upload_max_filesize, может включать в себя несколько файлов, на каждый из которых распространяется upload_max_filesize
memory_limit — размер максимально доступной памяти в PHP
max_execution_time — максимальное время работы скрипта
max_input_vars — количество входных переменных, которые могут быть приняты в одном запросе (ограничение накладывается на каждую из глобальных переменных $_GET, $_POST и $_COOKIE отдельно)
max_input_time — время за которое PHP должен обработать все входные данные
zend.enable_gc — включает сборщик мусора (будет оптимизировать память на фоне)
Заключение
Прежде чем пытаться импортировать демоданные и вообще начинать работу с сайтом, настоятельно рекомендую начать с оптимальных настроек php.ini и версии PHP 7.4 для вашего сайта на WordPress. Это предотвратит неправильный импорт каких-либо страниц или любые другие проблемы, которые могут возникнуть из-за стандартных ограничений php.ini. А также повысит скорость работы сайта и его безопасность. Если у вас веб-хостинг не желает обновлять свою версию PHP, вероятно, пора перейти к лучшему провайдеру, который понимает важность этого вопроса.

Если Вам было полезно или есть вопросы, оставляйте комментарии, всем удачи
Каковы лучшие настройки PHP для WordPress?
Так, Modern Events Calendar использует базовые настройки WordPress и может бесперебойно работать даже с ограниченными ресурсами.
Конфигурации хоста: для доступа к этим полям отредактируйте файл «php.ini», который находится на хосте (если вы не можете его найти, обратитесь к своему поставщику услуг хостинга).
Поделиться
Статьи по теме
- Установка
- Как добавить событие в плагин MEC?
- Формат даты PHP
- Параметры даты шорткода
- Импортировать события Facebook
Сообщить об устаревшем содержании
Если вы считаете, что содержание этой страницы не отражает обновленную информацию, сообщите нам об этом.
Редактирование wp-config.php
Если ваш хостинг-провайдер установил для вас WordPress, получите информацию от него. Если вы управляете своим собственным веб-сервером или учетной записью хостинга, эта информация будет у вас в результате создания базы данных и пользователя.
Настройка параметров базы данных
Важно: никогда не используйте текстовый редактор, например Microsoft Word, для редактирования файлов WordPress!
Найдите файл wp-config-sample.php в базовом каталоге вашего каталога WordPress и откройте его в текстовом редакторе.
Стандартный wp-config-sample.php
Примечание. Это пример стандартного wp-config-sample.php. Значения здесь являются примерами, чтобы показать вам, что делать.
// ** MySQL settings - You can get this info from your web host ** // /** The name of the database for WordPress */ define( 'DB_NAME', 'database_name_here' ); /** MySQL database username */ define( 'DB_USER', 'username_here' ); /** MySQL database password */ define( 'DB_PASSWORD', 'password_here' ); /** MySQL hostname */ define( 'DB_HOST', 'localhost' );
Внимание: Текст внутри /* */ являеться комментариями, только в информационных целях.
Изменение имени базы данных
Замените «database_name_here» именем своей базы данных, например MyDatabaseName.
define( 'DB_NAME', 'MyDatabaseName' ); // Example MySQL database name
Изменение пользователя базы данных
Замените «username_here» на имя вашего имени пользователя, например MyUserName.
define( 'DB_USER', 'MyUserName' ); // Example MySQL username
Изменение пароля базы данных
Замените «password_here» своим паролем, например MyPassWord.
define( 'DB_PASSWORD', 'MyPassWord' ); // Example MySQL password
Изменение хоста базы данных
Замените «localhost» именем хоста вашей базы данных, например MyDatabaseHost. Также может потребоваться номер порта или путь к файлу сокета Unix.
define( 'DB_HOST', 'MyDatabaseHost' ); // Example MySQL Database host
Примечание. Вполне вероятно, что вам НЕ придется его менять. Если вы не уверены, попробуйте установить со значением по умолчанию «localhost» и посмотрите, работает ли это. Если установка не удалась, обратитесь к своему провайдеру веб-хостинга.
Альтернативный порт MySQL
Если ваш хост использует альтернативный номер порта для вашей базы данных, вам необходимо изменить значение DB_HOST в файле wp-config.php , чтобы отразить альтернативный порт, предоставленный вашим хостом.
define( 'DB_HOST', 'localhost:3307' );
Для указанного сервера:
define( 'DB_HOST', 'mysql.example.com:3307' );
Замените 3307 любым номером порта, который вам дает ваш хост.
Сокеты или конвееры MySQL
Если ваш хост использует сокеты или конвееры Unix, соответственно измените значение DB_HOST в файле wp-config.php .
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' );
Замените /var/run/mysqld/mysqld.sock информацией о сокете или конвеере, предоставленной вашим хостом.
Возможные значения DB_HOST
Разные хостинговые компании используют разные сетевые настройки для своих баз данных mysql. Обратитесь в службу технической поддержки и/или выполните поиск в документации по вашей хостинг-компании в Интернете.
Кодировка базы
DB_CHARSET был сделан доступным для обозначения набора символов базы данных (например, tis620 для TIS620 Thai), который будет использоваться при определении таблиц базы данных MySQL.
Значение по умолчанию utf8 (Unicode UTF-8) почти всегда является лучшим вариантом. UTF-8 поддерживает любой язык, поэтому вы обычно оставляете DB_CHARSET на utf8 и вместо этого используете значение DB_COLLATE для вашего языка.
В этом примере показана кодировка utf8, которая считается значением WordPress по умолчанию:
define( 'DB_CHARSET', 'utf8' );
Обычно не должно быть причин для изменения значения DB_CHARSET по умолчанию. Если вашему блогу нужен другой набор символов, прочтите, пожалуйста, «Наборы символов и сопоставления, поддерживаемые MySQL», чтобы узнать допустимые значения DB_CHARSET. ВНИМАНИЕ: Это требует обновления.
Если DB_CHARSET и DB_COLLATE не существуют в вашем файле wp-config.php , НЕ ДОБАВЛЯЙТЕ какое-либо определение в файл wp-config.php , если вы не прочитали и не поняли преобразование наборов символов базы данных. Добавление DB_CHARSET и DB_COLLATE в файл wp-config.php для существующего блога может вызвать серьезные проблемы.
Сопоставление базы данных
DB_COLLATE стал доступным для обозначения параметров cопоставления кодировки базы данных (то есть порядка кодировки набора символов). В большинстве случаев это значение следует оставить пустым (нулевым), чтобы кодировка базы данных была автоматически назначена MySQL на основе набора символов базы данных, указанного в DB_CHARSET. Примером того, когда вам может потребоваться установить «DB_COLLATE» в одно из значений UTF-8, определенных в наборах символов UTF-8 для большинства западноевропейских языков, может быть другой язык, на котором введенные вами символы не являются то же самое, что отображается. (См. также Наборы символов Unicode в Руководстве по SQL)
Значение DB_COLLATE по умолчанию WordPress:
define( 'DB_COLLATE', '' );
UTF-8 Unicode Общие параметры кодировки
define( 'DB_COLLATE', 'utf8_general_ci' );
UTF-8 Unicode турецкая кодировка
define( 'DB_COLLATE', 'utf8_turkish_ci' );
Обычно не должно быть причин для изменения значения DB_COLLATE по умолчанию. Если оставить значение пустым (null), MySQL автоматически назначит сопоставление при создании таблиц базы данных. ВНИМАНИЕ: Это требует обновления
Если DB_COLLATE и DB_CHARSET не существуют в вашем файле wp-config.php , НЕ добавляйте ни одно определение в ваш файл wp-config.php , если вы не прочитали и не поняли преобразование наборов символов базы данных. И вам может потребоваться обновление WordPress.
Ключи безопасности
Вам не нужно запоминать ключи, просто сделайте их длинными, случайными и сложными — а еще лучше — используйте онлайн-генератор. Вы можете изменить их в любой момент, чтобы аннулировать все существующие файлы cookie. Это означает, что всем пользователям придется снова войти в систему.
Пример (не используйте их!):
define( 'AUTH_KEY', 't`DK%X:>xy|e-Z(BXb/f(Ur`8#~UzUQG-^_Cs_GHs5U-&Wb?pgn^p8(2@>IcnCa|' ); define( 'SECURE_AUTH_KEY', 'D&ovlU#|CvJ##uNq>bel+^MFtT&.b9XWdEC[BOKXssj' ); define( 'LOGGED_IN_KEY', 'MGKi8Br(&zBf883td6D;Vcy8,S)-&G' ); define( 'SECURE_AUTH_SALT', 'I6`V|mDZq21-J|ihb u^q0F >F_NUcy`l,=obGtq*p#Ybe4a31R,r=|n#=]@]c #' ); define( 'LOGGED_IN_SALT', 'w(hdXW|0M=X= qG(GaVDEsn,~*4i' ); define( 'NONCE_SALT', 'a|#hW:mAvy.py(wTP%%' );
Секретный ключ усложняет успешную атаку на ваш сайт, добавляя случайные элементы к паролю.
Проще говоря, секретный ключ — это пароль с элементами, которые затрудняют создание достаточного количества параметров для преодоления ваших барьеров безопасности. Пароль типа «пароль» или «тест» прост и легко взломан. Для взлома случайного длинного пароля без словарных слов, например «88a7da62429ba6ad3cb3c76a09641fc», злоумышленнику могут потребоваться миллионы часов. «Соль» используется для дальнейшего повышения надежности полученного результата.
Четыре ключа необходимы для повышенной безопасности. Четыре соли рекомендуются, но не требуются, потому что WordPress будет генерировать соли для вас, если они не предоставлены. Они включены в wp-config.php по умолчанию.
Дополнительные сведения о технических характеристиках и структуре секретных ключей и безопасных паролей смотрите:
- Райан Борен — SSL и файлы cookie в WordPress 2.6
- Объяснение взлома паролей из Википедии
- Лорель ВанФоссен — Защитите свой блог надежным паролем
- Instructables — Советы по безопасному паролю
- Huffington Post — 17 советов, которые вы можете сделать сегодня, чтобы защитить свои пароли в Интернете
Расширенные настройки
Следующие разделы могут содержать дополнительную информацию, и некоторые изменения могут привести к непредвиденным проблемам. Перед изменением этих настроек убедитесь, что вы регулярно выполняете резервное копирование и знаете, как их восстановить.
table_prefix
$table_prefix — это значение, помещаемое перед таблицами базы данных. Измените значение, если вы хотите использовать что-то другое, кроме wp_ для префикса вашей базы данных. Обычно это изменяется, если вы устанавливаете несколько сайтов WordPress в одной базе данных, как это делается с функцией работы с несколькими сайтами.
Можно сделать несколько установок в одной базе данных, если вы дадите каждой из них уникальный префикс. Помните о безопасности, если решите это сделать.
$table_prefix = 'r235_'; // Only numbers, letters, and underscores please!
WP_SITEURL
WP_SITEURL позволяет определить адрес (URL) WordPress. Определенное значение — это адрес, по которому находятся ваши файлы ядра WordPress. Он также должен включать часть http:// . Не ставьте в конце косую черту «/». Установка этого значения в wp-config.php переопределяет значение таблицы wp_options для siteurl. Добавление этого может уменьшить количество обращений к базе данных при загрузке вашего сайта. Примечание: это не изменит сохраненное значение базы данных. URL вернется к старому значению базы данных, если эта строка когда-либо будет удалена из wp-config.php . Используйте константу RELOCATE, чтобы изменить значение siteurl в базе данных.
Если WordPress установлен в каталог с именем «wordpress» для домена example.com, определите WP_SITEURL следующим образом:
define( 'WP_SITEURL', 'http://example.com/wordpress' );
Динамически установить WP_SITEURL на основе $ _SERVER [‘HTTP_HOST’]
define( 'WP_SITEURL', 'http://' . $_SERVER['HTTP_HOST'] . '/path/to/wordpress' );
Примечание. HTTP_HOST создается PHP динамически на основе значения заголовка HTTP HOST в запросе, что, возможно, допускает уязвимости включения файлов. SERVER_NAME также может быть создан динамически. Однако, когда Apache настроен как UseCanonicalName «on», SERVER_NAME устанавливается конфигурацией сервера, а не динамически. В этом случае для пользователя SERVER_NAME безопаснее, чем HTTP_HOST.
Динамически установить WP_SITEURL на основе $ _SERVER [‘SERVER_NAME’]
define( 'WP_SITEURL', 'http://' . $_SERVER['SERVER_NAME'] . '/path/to/wordpress' );
Адрес сайта (URL)
Подобно WP_SITEURL, WP_HOME переопределяет значение таблицы wp_options для главной, но не изменяет его в базе данных. главная — это адрес, который вы хотите, чтобы люди вводили в своем браузере, чтобы попасть в ваш сайт WordPress. Он должен включать часть http:// и не иметь косой черты «/» в конце. Добавление этого может уменьшить количество обращений к базе данных при загрузке вашего сайта.
define( ‘WP_HOME’, ‘http://example.com/wordpress’ );
Если вы используете технику, описанную в разделе «Создание собственного каталога WordPress», следуйте приведенному ниже примеру. Помните, что вы также разместите index.php в своем корневом веб-каталоге, если вы используете такую настройку.
define( 'WP_HOME', 'http://example.com' );
Динамически установить WP_HOME на основе $ _SERVER [‘HTTP_HOST’]
define( 'WP_HOME', 'http://' . $_SERVER['HTTP_HOST'] . '/path/to/wordpress' );
Перемещение каталога wp-content
Вы можете переместить каталог wp-content , в котором хранятся ваши темы, плагины и загрузки, за пределы каталога приложений WordPress.
Установите WP_CONTENT_DIR на полный локальный путь к этому каталогу (без косой черты в конце), например
define( 'WP_CONTENT_DIR', dirname(__FILE__) . '/blog/wp-content' );
Установите WP_CONTENT_URL на полный URL-адрес этого каталога (без косой черты в конце), например
define( 'WP_CONTENT_URL', 'http://example/blog/wp-content' );
Перемещение каталога плагинов
Установите WP_PLUGIN_DIR на полный локальный путь к этому каталогу (без косой черты), например
define( 'WP_PLUGIN_DIR', dirname(__FILE__) . '/blog/wp-content/plugins' );
Установите WP_PLUGIN_URL на полный URI этого каталога (без косой черты в конце), например
define( 'WP_PLUGIN_URL', 'http://example/blog/wp-content/plugins' );
Если у вас есть проблемы с совместимостью плагинов, установите PLUGINDIR на полный локальный путь к этому каталогу (без косой черты в конце), например
define( 'PLUGINDIR', dirname(__FILE__) . '/blog/wp-content/plugins' );
Перемещение каталога тем
Вы не можете переместить папку тем, потому что ее путь жестко задан относительно папки wp-content :
$theme_root = WP_CONTENT_DIR . '/themes';
Однако вы можете зарегистрировать дополнительные каталоги тем с помощью register_theme_directory.
Посмотрите, как переместить папку wp-content. Подробнее о том, как определяется папка тем, см. wp-includes/theme.php .
Перемещение каталога загрузок
Установить каталог загрузок
define( 'UPLOADS', 'blog/wp-content/uploads' );
Этот путь не может быть абсолютным. Он всегда относительно ABSPATH, поэтому не требует косой черты в начале.
Изменить интервал автосохранения
При редактировании сообщения WordPress использует Ajax для автоматического сохранения изменений в публикации во время редактирования. Вы можете увеличить эту настройку, чтобы увеличить задержки между автосохранениями, или уменьшить ее, чтобы не потерять изменения. По умолчанию 60 секунд.
define( 'AUTOSAVE_INTERVAL', 160 ); // Seconds
Редакции записей
WordPress по умолчанию сохраняет копии каждого изменения, внесенного в сообщение или страницу, что дает возможность вернуться к предыдущей версии этого сообщения или страницы. Сохранение редакций можно отключить или указать максимальное количество редакций для каждой записи или страницы.
Отключить редакции записей
Если вы не устанавливаете это значение, WordPress по умолчанию устанавливает для WP_POST_REVISIONS значение true (разрешить редактирование сообщений). Если вы хотите отключить функцию ревизий, используйте этот параметр:
define( 'WP_POST_REVISIONS', false );
Примечание. Иногда это не работает, пока команда не будет перемещена в первую строку под комментарием начального блока в wp-config.php .
Укажите количество редакций записи
Если вы хотите указать максимальное количество редакций, которые хранит WordPress, измените false на целое число (например, 3 или 12).
define( 'WP_POST_REVISIONS', 3 );
Примечание. Иногда это не работает, пока команда не будет перемещена в первую строку под комментарием начального блока в wp-config.php .
Установить домен для cookie
Домен, установленный в файлах cookie для WordPress, может быть указан для пользователей с необычными настройками домена. Например, если субдомены используются для обслуживания статического содержимого, вы можете установить в качестве домена cookie только ваш нестатический домен, чтобы предотвратить отправку cookie WordPress с каждым запросом к статическому содержимому на вашем субдомене.
define( 'COOKIE_DOMAIN', 'www.example.com' );
Установка сети (Мультисайт)
WP_ALLOW_MULTISITE — это функция, позволяющая работать с несколькими сайтами. Если этот параметр отсутствует в wp-config.php , по умолчанию используется значение false.
define( 'WP_ALLOW_MULTISITE', true );
Редирект несуществующих блогов
NOBLOGREDIRECT может использоваться для перенаправления браузера, если посетитель пытается получить доступ к несуществующему поддомену или каталогу.
define( 'NOBLOGREDIRECT', 'http://example.com' );
WP_DISABLE_FATAL_ERROR_HANDLER
WordPress 5.2 представил режим восстановления, который отображает сообщение об ошибке вместо белого экрана, когда плагины или темы вызывают фатальную ошибку.
Сайт испытывает технические трудности. Пожалуйста, проверьте почтовый ящик администратора вашего сайта для получения инструкций.
Белые экраны и сообщения об ошибках PHP больше не отображаются для пользователей. Но в среде разработки, если вы хотите включить WP_DEBUG_DISPLAY, вы должны отключить режим восстановления, установив true в WP_DISABLE_FATAL_ERROR_HANDLER.
define( 'WP_DISABLE_FATAL_ERROR_HANDLER', true ); // 5.2 and later define( 'WP_DEBUG', true ); define( 'WP_DEBUG_DISPLAY', true );
WP_DEBUG
Параметр WP_DEBUG управляет отчетом о некоторых ошибках и предупреждениях и позволяет использовать настройки WP_DEBUG_DISPLAY и WP_DEBUG_LOG. Значение по умолчанию — false.
define( 'WP_DISABLE_FATAL_ERROR_HANDLER', true ); // 5.2 and later define( 'WP_DEBUG', true );
Установка WP_DEBUG в значение true также повышает уровень сообщения об ошибках до E_ALL и активирует предупреждения при использовании устаревших функций или файлов; в противном случае WordPress устанавливает уровень сообщения об ошибках на E_ALL ^ E_NOTICE ^ E_USER_NOTICE.
SCRIPT_DEBUG
SCRIPT_DEBUG — это связанная константа, которая заставит WordPress использовать «dev» версии скриптов и таблиц стилей в wp-includes/js , wp-includes/css , wp-admin/js , и wp-admin/css будут загружены вместо версии .min.css и .min.js . Если вы планируете модифицировать некоторые из встроенных в WordPress таблиц JavaScript или CSS, вам следует добавить следующий код в свой файл конфигурации:
define( 'SCRIPT_DEBUG', true );
Отключить объединение Javascript
Чтобы ускорить экраны администрирования, все файлы JavaScript объединяются в один URL. Если JavaScript не работает на экране администрирования, вы можете попробовать отключить эту функцию:
define( 'CONCATENATE_SCRIPTS', false );
Настройка журналирования ошибок
Настройка журнала ошибок может быть немного сложной. Прежде всего, журнал ошибок PHP по умолчанию и настройки отображения устанавливаются в файле php.ini, к которому вы можете иметь или не иметь доступа. Если вы это сделаете, они должны быть установлены на желаемые настройки для реальных страниц PHP. Настоятельно рекомендуется не публиковать сообщения об ошибках, а направлять их в журнал ошибок. Более того, журналы ошибок не должны находиться в общедоступной части вашего сервера. Пример рекомендуемых настроек ошибок php.ini:
error_reporting = 4339 display_errors = Off display_startup_errors = Off log_errors = On error_log = /home/example.com/logs/php_error.log log_errors_max_len = 1024 ignore_repeated_errors = On ignore_repeated_source = Off html_errors = Off
Об отчетах об ошибках 4339 Это настраиваемое значение, которое регистрирует только проблемы, влияющие на работу вашего сайта, и игнорирует такие вещи, как уведомления, которые могут даже не быть ошибками. См. В разделе Константы ошибок PHP значение каждой двоичной позиции для 1000011110011, которое является двоичным числом, равным 4339. Крайняя левая цифра 1 означает сообщение о любой E_RECOVERABLE_ERROR. Следующий 0 означает, что не следует сообщать E_STRICT (который выдается при использовании небрежного, но функционального кодирования) и так далее. Не стесняйтесь определять свой собственный номер сообщения об ошибке, который будет использоваться вместо 4339.
Очевидно, вам понадобятся другие настройки для вашей среды разработки. Если ваша разрабатываемая копия находится на том же сервере или у вас нет доступа к php.ini, вам нужно будет изменить настройки по умолчанию во время выполнения. Это вопрос личных предпочтений, предпочитаете ли вы, чтобы ошибки записывались в файл журнала, или вы предпочитаете немедленно получать уведомления о любой ошибке, или, возможно, и то и другое. Вот пример, который немедленно сообщает обо всех ошибках, которые вы можете вставить в файл wp-config.php :
@ini_set( 'log_errors', 'Off' ); @ini_set( 'display_errors', 'On' ); define( 'WP_DISABLE_FATAL_ERROR_HANDLER', true ); // 5.2 and later define( 'WP_DEBUG', true ); define( 'WP_DEBUG_LOG', false ); define( 'WP_DEBUG_DISPLAY', true );
Поскольку wp-config.php загружается для каждого просмотра страницы, не загруженного из файла кеша, это отличное место для установки настроек php.ini, управляющих вашей установкой PHP. Это полезно, если у вас нет доступа к файлу php.ini или вы просто хотите изменить некоторые настройки на лету. Единственное исключение — error_reporting. Если для WP_DEBUG задано значение true, для параметра error_reporting будет установлено значение E_ALL WordPress, независимо от того, что вы пытаетесь установить в wp-config.php . Если вам действительно нужно установить для параметра error_reporting что-то еще, это нужно сделать после загрузки wp-settings.php, например, в файле плагина.
Если вы включите регистрацию ошибок, не забудьте потом удалить файл, так как он часто будет находиться в общедоступном месте, где любой может получить доступ к вашему журналу.
Вот пример, который включает PHP error_logging и записывает их в определенный файл. Если для WP_DEBUG задано значение true, ошибки также будут сохраняться в этом файле. Просто поместите это над любыми командами require_once или include.
@ini_set( 'log_errors', 'On' ); @ini_set( 'display_errors', 'Off' ); @ini_set( 'error_log', '/home/example.com/logs/php_error.log' ); /* That's all, stop editing! Happy blogging. */
Другой пример регистрации ошибок, предложенный Майком Литтлом в списке рассылки wp-hackers:
/** * This will log all errors notices and warnings to a file called debug.log in * wp-content (if Apache does not have write permission, you may need to create * the file first and set the appropriate permissions (i.e. use 666) ) */ define( 'WP_DEBUG', true ); define( 'WP_DEBUG_LOG', true ); define( 'WP_DEBUG_DISPLAY', false ); @ini_set( 'display_errors', 0 );
/** * This will log all errors notices and warnings to a file called debug.log in * wp-content only when WP_DEBUG is true. if Apache does not have write permission, * you may need to create the file first and set the appropriate permissions (i.e. use 666). */ define( ‘WP_DEBUG’, true ); // Or false if ( WP_DEBUG )
Проблема в том, что в WordPress есть три (3) константы, которые выглядят так, как будто они могут делать одно и то же. Во-первых, помните, что если WP_DEBUG имеет значение false, он и две другие константы WordPress DEBUG ничего не делают. Директивы PHP, какими бы они ни были, будут иметь преимущественную силу. За исключением error_reporting, WordPress установит для него значение 4983, если WP_DEBUG определен как false. Во-вторых, даже если WP_DEBUG истинно, другие константы что-то делают, только если они тоже имеют значение true. Если для них установлено значение false, директивы PHP остаются неизменными. Например, если в вашем файле php.ini есть директива (‘display_errors’ = ‘On’); но у вас есть оператор define (‘WP_DEBUG_DISPLAY’, false); в вашем файле wp-config.php ошибки все равно будут отображаться на экране, даже если вы пытались предотвратить это, установив для WP_DEBUG_DISPLAY значение false, потому что это поведение, настроенное PHP. Вот почему очень важно установить в директивах PHP то, что вам нужно, если для какой-либо из связанных констант WP установлено значение false. На всякий случай явно установите / определите оба типа. Более подробные описания констант WP доступны в разделе «Отладка в WordPress».
Для обычной установки WordPress вы можете подумать о размещении следующего в файле wp-config.php, даже если он может быть частично избыточным:
@ini_set( 'log_errors', 'On' ); @ini_set( 'display_errors', 'Off' ); define( 'WP_DISABLE_FATAL_ERROR_HANDLER', false ); // 5.2 and later define( 'WP_DEBUG', false ); define( 'WP_DEBUG_LOG', false ); define( 'WP_DEBUG_DISPLAY', false );
Файл журнала отладки по умолчанию — /wp-content/debug.log . Размещение журналов ошибок в общедоступных местах представляет собой угрозу безопасности. В идеале файлы журнала должны размещаться над общедоступным корневым каталогом вашего сайта. Если вы не можете этого сделать, по крайней мере, установите разрешения для файла журнала на 600 и добавьте эту запись в файл .htaccess в корневом каталоге вашей установки WordPress:
Order allow,deny Deny from all
Это предотвращает доступ к файлу через HTTP. Вы всегда можете просмотреть файл журнала, загрузив его со своего сервера по FTP.
Увеличение памяти, выделенной PHP
Параметр WP_MEMORY_LIMIT позволяет указать максимальный объем памяти, который может использовать PHP. Эта настройка может потребоваться в случае, если вы получите сообщение, такое как «Допустимый размер памяти xxxxxx байт исчерпан».
Этот параметр увеличивает память PHP только для WordPress, а не для других приложений. По умолчанию WordPress будет пытаться увеличить память, выделенную для PHP, до 40 МБ (код находится в начале /wp-includes/default-constants.php ) для одного сайта и 64 МБ для мультисайта, поэтому параметр в wp-config.php должен отражать что-то более 40 МБ или 64 МБ в зависимости от ваших настроек.
WordPress автоматически проверит, выделено ли PHP меньше памяти, чем введенное значение, прежде чем использовать эту функцию. Например, если PHP было выделено 64 МБ, нет необходимости устанавливать это значение на 64 МБ, так как WordPress при необходимости автоматически использует все 64 МБ.
Примечание. Некоторые хосты не позволяют автоматически увеличивать лимит памяти PHP. В этом случае обратитесь к своему хосту, чтобы увеличить лимит памяти PHP. Кроме того, многие хосты устанавливают лимит PHP на 128 МБ.
Увеличьте память PHP до 256 МБ
define( 'WP_MEMORY_LIMIT', '256M' );
Задачи администрирования требуют больше памяти, чем обычные операции. Находясь в области администрирования, память может быть увеличена или уменьшена с WP_MEMORY_LIMIT путем определения WP_MAX_MEMORY_LIMIT.
define( 'WP_MAX_MEMORY_LIMIT', '512M' );
Примечание: это должно быть указано перед включением wp-settings.php.
Кэш
Параметр WP_CACHE, если он истинен, включает сценарий wp-content/advanced-cache.php при выполнении wp-settings.php.
define( 'WP_CACHE', true );
Настраиваемые таблицы User и Usermeta
CUSTOM_USER_TABLE и CUSTOM_USER_META_TABLE используются для обозначения того, что пользовательские и пользовательские таблицы метаданных, обычно используемые WordPress, не используются, вместо этого эти значения/таблицы используются для хранения вашей пользовательской информации.
define( 'CUSTOM_USER_TABLE', $table_prefix.'my_users' ); define( 'CUSTOM_USER_META_TABLE', $table_prefix.'my_usermeta' );
Примечание. Даже если параметр «CUSTOM_USER_META_TABLE» установлен вручную, таблица пользовательских метаданных все равно создается для каждой базы данных с соответствующими разрешениями для каждого экземпляра. По умолчанию установщик WordPress добавит разрешения для первого пользователя (ID # 1). Вам также необходимо управлять разрешениями для каждого сайта с помощью плагина или настраиваемой функции. Если этого не сделать, вы столкнетесь с ошибками разрешений и проблемами со входом в систему.
CUSTOM_USER_TABLE проще всего использовать во время начальной установки вашего первого экземпляра WordPress. Операторы define файла wp-config.php в первом экземпляре указывают на то, где по умолчанию будут храниться данные wp_users. После первой настройки сайта копирование рабочего wp-config.php в следующий экземпляр потребует только изменения переменной $table_prefix. Не используйте адрес электронной почты, который уже используется в исходной установке. После завершения процесса установки войдите в систему с автоматически созданной учетной записью администратора и паролем. Затем продвиньте свою обычную учетную запись до уровня администратора и выйдите из системы администратора. Войдите в систему как вы, удалите учетную запись администратора и продвигайте другие учетные записи пользователей по мере необходимости.
Язык и папка языковых файлов
WordPress c версии 4.0 позволяет менять язык на экранах администрирования WordPress. Чтобы изменить язык в экране настроек администратора. Перейдите в Настройки — Общие и выберите Язык сайта.
WordPress v3.9.6 и ниже
WPLANG определяет имя файла языкового перевода (.mo). WP_LANG_DIR определяет, в каком каталоге находится файл WPLANG.mo. Если WP_LANG_DIR не определен, WordPress сначала ищет wp-content/languages , а затем wp-includes/languages для .mo, определенного файлом WPLANG.
define( 'WPLANG', 'de_DE' ); define( 'WP_LANG_DIR', dirname(__FILE__) . 'wordpress/languages' );
Чтобы узнать код языка WPLANG, перейдите сюда. Код в столбце WP Local — это то, что вам нужно.
Сохранение запросов SQL для анализа
Определение SAVEQUERIES сохраняет запросы к базе данных в массив, и этот массив может быть отображен, чтобы помочь проанализировать эти запросы. В этой информации сохраняется каждый запрос, какая функция его вызвала и сколько времени потребовалось для выполнения этого запроса. Примечание. Это повлияет на производительность вашего сайта, поэтому обязательно отключите эту функцию, когда не занимаетесь отладкой.
Сначала добавьте это в файл wp-config.php:
define( 'SAVEQUERIES', true );
Затем в подвал вашей темы поместите это:
"; print_r( $wpdb->queries ); echo "
«; > ?>
Отмена разрешений для файлов по умолчанию
Операторы FS_CHMOD_DIR и FS_CHMOD_FILE позволяют переопределить права доступа к файлам по умолчанию. Эти две переменные были разработаны в ответ на проблему сбоя функции обновления ядра с хостами, работающими под suexec. Если хост использует ограничительные права доступа к файлам (например, 400) для всех пользовательских файлов и отказывается получить доступ к файлам, для которых установлены разрешения группы или общие, эти определения могут решить проблему.
define( 'FS_CHMOD_DIR', ( 0755 & ~ umask() ) ); define( 'FS_CHMOD_FILE', ( 0644 & ~ umask() ) );
Пример предоставления setgid:
define( 'FS_CHMOD_DIR', ( 02755 & ~umask() ) );
Примечание. «0755» и «02755» — восьмеричные значения. Восьмеричные значения должны иметь префикс 0 и не выделяться одинарными кавычками (‘). См. Также: Изменение прав доступа к файлам
Константы обновления WordPress
Примечание. Определите только необходимые константы для исправления проблем с обновлением.
Наиболее частые причины, по которым необходимо их определить:
Хост работает со специальной установкой, включающей символические ссылки. Возможно, вам потребуется определить константы, относящиеся к пути (FTP_BASE, FTP_CONTENT_DIR и FTP_PLUGIN_DIR). Часто достаточно простого определения базы.
Некоторые установки PHP поставляются с расширением PHP FTP, несовместимым с определенными FTP-серверами. В этих редких ситуациях вам может потребоваться определить FS_METHOD как «ftpsockets».
Следующие допустимые константы для обновлений WordPress:
- FS_METHOD принудительно использует метод файловой системы. Это должно быть только «direct», «ssh2», «ftpext» или «ftpsockets». Как правило, вам следует изменять это только при возникновении проблем с обновлением. Если вы измените его, и это не поможет, поменять обратно/удалить. В большинстве случаев установка ftpsockets будет работать, если автоматически выбранный метод не работает..
- (Основная настройка) “direct” принудительно устанавливает, чтобы использовать Прямые запросы ввода/вывода Файла изнутри PHP, это чревато открытием вопросов безопасности на плохо конфигурировавших серверах. Это выбирается автоматически при поддержке сервера.
- (вторая настройка) “ssh2” должен вызвать использование SSH PHP Расширение если оно установлено
- (третья настройка) “ftpext” заключается в принудительном использовании расширения FTP PHP для доступа к FTP и, наконец,
- (четвертая настройка) “ftpsockets” использует класс сокетов PHP для доступа по 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 или ввести ее в поле «Пароль» представленного поля учетных данных при установке обновлений.
Альтернативный Cron
Может возникнуть необходимость использовать альтернативный Cron с WP. Чаще всего это делается, если запланированные публикации не публикуются, как предполагалось. Этот альтернативный метод использует подход перенаправления. Браузер пользователей получает перенаправление, когда cron необходимо запустить, так что они сразу же возвращаются на сайт, в то время как cron продолжает работать в только что отключенном соединении. У этого метода есть определенные риски, поскольку он зависит от не родного сервиса для WordPress.
define( 'ALTERNATE_WP_CRON', true );
Отключить Cron и Cron Timeout
Полностью отключите cron, установив для DISABLE_WP_CRON значение true.
define( 'DISABLE_WP_CRON', true );
Установить ограничение на запуск процесса cron чаще одного раза в WP_CRON_LOCK_TIMEOUT секунд.
define( 'WP_CRON_LOCK_TIMEOUT', 60 );
Дополнительные определяемые константы
Вот дополнительные константы, которые можно определить. Их, вероятно, не следует устанавливать, если сначала не были опробованы другие методики. Определения файлов 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( 'TEMPLATEPATH', get_template_directory() ); define( 'STYLESHEETPATH', get_stylesheet_directory() );
Очистить корзину
Эта константа контролирует количество дней до того, как WordPress окончательно удалит сообщения, страницы, вложения и комментарии из корзины. По умолчанию 30 дней:
define( 'EMPTY_TRASH_DAYS', 30 ); // 30 дней
Чтобы отключить корзину, установите нулевое количество дней.
define( 'EMPTY_TRASH_DAYS', 0 ); // Ноль дней
Примечание: WordPress не будет запрашивать подтверждение, когда кто-то нажимает «Удалить навсегда», используя этот параметр.
Автоматическая оптимизация базы данных
Существует поддержка автоматического восстановления базы данных, которую вы можете включить, добавив следующее определение в файл wp-config.php.
Примечание: это следует включать только при необходимости и отключать после решения проблемы. Если этот параметр включен, пользователю не нужно входить в систему для доступа к функциям, поскольку его основная цель — восстановить поврежденную базу данных, и пользователи часто не могут войти в систему, если база данных повреждена.
define( 'WP_ALLOW_REPAIR', true );
Скрипт можно найти по адресу /wp-admin/maint/repair.php .
DO_NOT_UPGRADE_GLOBAL_TABLES
Определение DO_NOT_UPGRADE_GLOBAL_TABLES запрещает dbDelta() и функциям обновления выполнять дорогостоящие запросы к глобальным таблицам.
Сайты с большими глобальными таблицами (в частности, пользователи и мета пользователей), а также сайты, которые используют общие таблицы пользователей с bbPress и другими установками WordPress, могут предотвратить изменение этих таблиц при обновлении, задав для DO_NOT_UPGRADE_GLOBAL_TABLES значение true. Поскольку выполнение ALTER или неограниченного DELETE или UPDATE может занять много времени, крупные сайты обычно не хотят, чтобы они выполнялись при обновлениях, чтобы они могли сделать это самостоятельно. Кроме того, если в установках используются общие таблицы пользователей между несколькими установками bbPress и WordPress, вы можете захотеть, чтобы один сайт был основным при обновлениях.
define( 'DO_NOT_UPGRADE_GLOBAL_TABLES', true );
Просмотр всех определенных констант
В PHP есть функция, которая возвращает массив всех определенных в настоящее время констант с их значениями.
print_r( @get_defined_constants() );
Отключение редактора плагинов и тем
Иногда вы можете отключить плагин или редактор тем, чтобы чрезмерно усердные пользователи не могли редактировать конфиденциальные файлы и, возможно, вывести сайт из строя. Их отключение также обеспечивает дополнительный уровень безопасности, если хакер получает доступ к учетной записи с высокими привилегиями.
define( 'DISALLOW_FILE_EDIT', true );
Примечание. На функциональность некоторых плагинов может влиять использование current_user_can(‘edit_plugins’) в их коде. Авторам плагинов следует избегать проверки этой возможности или, по крайней мере, проверять, установлена ли эта константа, и отображать соответствующее сообщение об ошибке. Имейте в виду, что если плагин не работает, это может быть причиной.
Отключить обновление и установку плагинов и тем
Это заблокирует пользователям возможность использовать функции установки/обновления плагинов и тем из области администрирования WordPress. Установка этой константы также отключает редактор плагинов и тем (т.е. вам не нужно устанавливать DISALLOW_FILE_MODS и DISALLOW_FILE_EDIT, так как DISALLOW_FILE_MODS будет иметь тот же эффект).
define( 'DISALLOW_FILE_MODS', true );
Требовать SSL для администратора и входа в систему
Примечание. В WordPress версии 4.0 FORCE_SSL_LOGIN не рекомендуется. Пожалуйста, используйте FORCE_SSL_ADMIN
FORCE_SSL_ADMIN используется, когда вы хотите защитить логины и область администрирования, чтобы пароли и файлы cookie никогда не отправлялись в открытом виде. См. также Administration_Over_SSL для более подробной информации.
define( 'FORCE_SSL_ADMIN', true );
Блокировать внешние URL-запросы
Заблокируйте внешние URL-запросы, указав WP_HTTP_BLOCK_EXTERNAL как true, и это позволит делать запросы только localhost и вашему блогу. Константа WP_ACCESSIBLE_HOSTS позволит дополнительным хостам проходить запросы. Формат константы WP_ACCESSIBLE_HOSTS представляет собой список разрешенных имен хостов, разделенных запятыми, поддерживаются домены с подстановочными знаками, например, *.wordpress.org позволит связаться со всеми поддоменами wordpress.org.
define( 'WP_HTTP_BLOCK_EXTERNAL', true ); define( 'WP_ACCESSIBLE_HOSTS', 'api.wordpress.org,*.github.com' );
Отключить автообновления WordPress
Возможна ситуация, при которой сайт не обновляется автоматически, например настройки или обновления, предоставляемые хостом. Это также можно сделать перед основным выпуском, чтобы дать время для тестирования в среде разработки или промежуточной среде, прежде чем разрешить обновление на рабочем сайте.
define( 'AUTOMATIC_UPDATER_DISABLED', true );
Отключить обновления ядра WordPress
Самый простой способ управлять обновлениями ядра — использовать константу WP_AUTO_UPDATE_CORE:
# Отключите все основные обновления: define( 'WP_AUTO_UPDATE_CORE', false ); # Включите все основные обновления, включая незначительные и крупные: define( 'WP_AUTO_UPDATE_CORE', true ); # Включить основные обновления для второстепенных выпусков (по умолчанию): define( 'WP_AUTO_UPDATE_CORE', 'minor' );
Очистка при редактировании изображений
По умолчанию WordPress создает новый набор изображений каждый раз, когда вы редактируете изображение, а когда вы восстанавливаете оригинал, он оставляет все изменения на сервере. Определение IMAGE_EDIT_OVERWRITE как true меняет это поведение. Когда-либо создается только один набор изменений изображения, и когда вы восстанавливаете оригинал, изменения удаляются с сервера.
define( 'IMAGE_EDIT_OVERWRITE', true );
Дважды проверьте перед сохранением
Обязательно проверьте наличие начальных и/или конечных пробелов вокруг любого из указанных выше значений, и НЕ удаляйте одинарные кавычки!
Перед сохранением файла обязательно дважды проверьте, не удалили ли вы случайно ни одну из одинарных кавычек вокруг значений параметров. Убедитесь, что после закрывающего тега PHP в файле нет ничего. Последним в файле должно быть ?> и ничего больше. Без пробелов.
Чтобы сохранить файл, выберите File>SaveAs>wp-config.php и сохраните файл в корне установки WordPress. Загрузите файл на свой веб-сервер, и вы готовы к установке WordPress!