Какие настройки поставить в php

Поведение этих функций зависит от установок в php.ini .

Настройки PHP/Параметры конфигурации информации

Имя	По умолчанию	Место изменения	Список изменений
assert.active	«1»	PHP_INI_ALL
assert.bail	«0»	PHP_INI_ALL
assert.warning	«1»	PHP_INI_ALL
assert.callback	NULL	PHP_INI_ALL
assert.quiet_eval	«0»	PHP_INI_ALL	Удалено в PHP 8.0.0
assert.exception	«1»	PHP_INI_ALL	До PHP 8.0.0 значение по умолчанию было «0» .
enable_dl	«1»	PHP_INI_SYSTEM	Эта возможность устарела и будет обязательно удалена в будущем.
max_execution_time	«30»	PHP_INI_ALL
max_input_time	«-1»	PHP_INI_PERDIR
max_input_nesting_level	«64»	PHP_INI_PERDIR
max_input_vars	1000	PHP_INI_PERDIR
zend.enable_gc	«1»	PHP_INI_ALL

Для подробного описания констант PHP_INI_*, обратитесь к разделу Где могут быть установлены параметры конфигурации.

Краткое разъяснение конфигурационных директив.

Включение выполнение assert() . zend.assertions следует использовать вместо этого для управления поведением функции assert() .

Завершение работы скрипта при провале проверки утверждений.

Вызов предупреждений PHP для каждой проваленной проверки утверждения.

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

Внимание

Данная функциональность была УДАЛЕНА, начиная с PHP 8.0.0.

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

Генерирует исключение AssertionError для неудачной проверки утверждения.

Директива позволяет включать и выключать динамическую подгрузку модулей PHP с помощью функции dl() .

Главной причиной, по которой требуется выключение динамической загрузки, является безопасность. С помощью динамической загрузки можно обойти все open_basedir ограничения. По умолчанию динамическая загрузка разрешена.

Эта директива задаёт максимальное время в секундах, в течение которого скрипт должен полностью загрузиться. Если этого не происходит, парсер завершает работу скрипта. Этот механизм помогает предотвратить зависание сервера из-за плохо написанного скрипта. По умолчанию на загрузку даётся 30 секунд. Если PHP запущен из командной строки, это значение по умолчанию равно 0 .

В системах, отличных от Windows, на максимальное время выполнения не влияют системные вызовы, потоковые операции и т.п. За дополнительной информацией обращайтесь к документации к функции set_time_limit() .

Веб-серверы обычно имеют свои настройки времени ожидания, по превышении которого сами завершают выполнение скрипта PHP. В Apache есть директива Timeout , в IIS есть функция CGI timeout. В обоих случаях по умолчанию установлено 300 секунд. Точные значения можно узнать из документации к веб-серверу.

Эта директива задаёт максимальное время в секундах, в течение которого скрипт должен разобрать все входные данные, переданные запросами вроде POST или GET. Это время измеряется от момента, когда PHP вызван на сервере до момента, когда скрипт начинает выполняться. Значение по умолчанию -1 , что означает, что будет использоваться max_execution_time. Если установить равным 0 , то ограничений по времени не будет.

Задаёт максимальную глубину вложенности входных переменных (то есть $_GET , $_POST .)

Сколько входных переменных может быть принято в одном запросе (ограничение накладывается на каждую из глобальных переменных $_GET, $_POST и $_COOKIE отдельно). Использование этой директивы снижает вероятность сбоев в случае атак с использованием хеш-коллизий. Если входных переменных больше, чем задано директивой, выбрасывается предупреждение E_WARNING , а все последующие переменные в запросе игнорируются.

Включает или отключает сборщик циклических ссылок.

User Contributed Notes

There are no user contributed notes for this page.

Установка и настройка
- Требования
- Установка
- Настройка во время выполнения
- Типы ресурсов
Самые быстрые настройки для PHP-скриптов

Наверное, все, кто сталкивался с разработкой более или менее серьезных приложений, знают, что выбор формата хранения настроек скрипта или приложения — достаточно ответственное дело. Конфиги должны быть легко читаемыми, легко модифицируемыми, легко переносимыми, и так далее — список можно продолжать и продолжать.
- INI-файлы
- PHP-скрипты
- XML-файлы
- Текстовые файлы
- Файлы с сериализованными данными
- Вне конкурса — PHP-скрипты с define’ами
- JSON-файлы NEW!
- Как можно быстрее загрузить настройки из файла
- Вернуть массив настроек в виде «ключ» => «значение»
- Конфигурационный файл содержит 10, 100 или 1000 конфигурационных параметров, представляющих собой короткие строки
- Конфигурация читается 1000 раз подряд, замеряется время работы в секундах
Конфигурацию оборудования не привожу. Понятно, что скорость скриптов зависит от сервера, но в данном случае сравниваются скрипты, а не серверы.

Правда, необходимо сделать небольшое уточнение по поводу программного обеспечения сервера. Использовался реальный веб-сервер, в момент низкой загрузки. Соответственно, конфигурация сервера «боевая»: Linux Debian Lenny, много памяти и RAID1-массив жестких дисков. PHP серии 5.2.x (не самый последний, врочем) с eAccelerator’ом. На время тестов отключался Zend Optimizer, чтобы тесты были более «чистыми», что минимально повлияло на результаты. Тесты без eAccelerator тоже проводились, но, как ни странно, сильно на распределение сил это не повлияло. Причина, на мой взгляд, кроется в том, что eAccelerator настроен на дисковое кэширование опкодов PHP и на сравнение времени модификации файлов, что «съедает» определенное количество времени — хотя и приносит определенные бонусы.

INI-файлы

Результаты: 0.015, 0.086, 0.784

Пример:
x1 = 1
x2 = 2
x3 = 3

Скрипт:
function config ( $file ) <
return parse_ini_file ( $file );
>

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

PHP-скрипты

Результаты: 0.029, 0.111, 0.902

Пример:
return array (
‘x1’ => ‘1’,
‘x2’ => ‘2’,
‘x3’ => ‘3’,
);
?>

Скрипт:
function config ( $file ) <
return include ( $file );
>

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

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

XML-файлы

Результаты: 0.062, 0.385, 3.911

Пример:

1
2
3

Скрипт:
function config ( $file ) <
$r = array ();
$dom = new DOMDocument ;
$dom -> load ( $file );
foreach ( $dom -> firstChild -> childNodes as $node ) <
if ( $node -> nodeType == XML_ELEMENT_NODE ) <
$r [ $node -> nodeName ] = $node -> firstChild -> nodeValue ;
>
>
return $r ;
>

Недостаток очевидный: очень маленькая скорость работы, в несколько раз медленнее, чем другие варианты. Чтобы проверить, не слишком ли медленная PHP-часть этого кода, я попробовал сделать return сразу после загрузки XML-документа (то есть, фактически, конфигурационные параметры не возвращались). Это ускорило процесс всего приблизительно в два раза. Что подтвердило общий вывод.

Результаты: NEW! 0.047, 0.276, 2.791

Скрипт: NEW!
function config ( $file ) <
$r = array ();
foreach ( simplexml_load_file ( $file ) as $k => $v ) <
$r [ $key ] = strval ( $v );
>
return $r ;
>

С помощью SimpleXML получается, конечно, быстрее. Но не настолько, чтобы претендовать на лидерство.

Текстовые файлы

Результаты: 0.034, 0.250, 2.369

Пример:
x1 1
x2 2
x3 3

Скрипт:
function config ( $file ) <
$r = array ();
if ( $F = fopen ( $file , «r» )) <
while (( $line = fgets ( $F )) !== false ) <
list ( $k , $v ) = explode ( «\t» , $line , 2 );
$r [ trim ( $k )] = trim ( $v );
>
fclose ( $F );
>
return $r ;
>

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

Результат: NEW! 0.036, 0.250, 2.213

Скрипт: NEW!
function config ( $file ) <
$r = array ();
foreach ( explode ( «\n» , file_get_contents ( $file )) as $line ) <
list ( $k , $v ) = explode ( «\t» , $line , 2 );
$r [ trim ( $k )] = trim ( $v );
>
return $r ;
>

Такой вариант реализации несколько медленнее для небольших файлов и быстрее для больших файлов. Но, в общем, не влияет на расстановку сил.

Файлы с сериализованными данными

Результаты: 0.011, 0.041, 0.309

Пример:
a:3:

Скрипт:
function config ( $file ) <
return unserialize ( file_get_contents ( $file ));
>

Наименее удобочитаемый конфигурационный файл — но при этом самый быстрый результат.

PHP-скрипты с define’ами

Результаты: 0.045, 0.252, 2.404

Пример:
define(«x1», «1»);
define(«x2», «2»);
define(«x3», «3»);
?>

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

JSON-файлы NEW!

Результаты: 0.015, 0.057, 0.495

Пример:

Скрипт:
function config ( $file ) <
return json_decode ( file_get_contents ( $file ) , true );
>

JSON ворвался в нашу жизнь. Его реализация в PHP позволила даже обогнать одного из лидеров, INI-файлы, но немного уступает встроенной сериализации PHP. ~~Одно замечание: приведенный код возвращает не массив, а stdClass object.~~

Выводы

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

Если Вы серьезный человек — то избегайте прямого чтения текстовых файлов, особенно с большими объемами. Вместо этого Вам вполне подойдут JSON-файлы или INI-файлы, тем более, что скрипты станут работать быстрее.

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

Настройки в формате XML — самые медленные. Прежде, чем их использовать, подумайте хорошенько.

Искренне надеюсь, что define’ы никто не использует, поэтому оставляем их обсуждение вне выводов.

Итог

Итак, что же применить в реальном приложении? Само собой напрашивается применение комбинированного способа хранения настроек. Например, настройки хранятся в виде PHP-скрипта, результаты выполнения которого кэшируются в виде сериализованного массива. Использование такого подхода вместо чтения конфигурационного файла на PHP позволило получить следующие результаты:

Результаты: 0.018, 0.046, 0.317

Оптимально с точки зрения гибкости и скорости, на мой взгляд.

А вот и сам скрипт:
function config ( $file ) <
$file_dat = «$file.dat» ;
if (! file_exists ( $file_dat ) || filemtime ( $file_dat ) filemtime ( $file )) <
$r = include ( $file );
if ( $F = fopen ( $file_dat , «w» )) <
fwrite ( $F , serialize ( $r ));
fclose ( $F );
>
> else <
$r = unserialize ( file_get_contents ( $file_dat ));
>
return $r ;
>

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

P.S. PHP-код в статье не самый хороший. Я писал его, преследуя две цели: краткость и скорость работы. Поэтому отсутствуют комментарии, длинные имена переменных и различные проверки. Кроме того, большая часть кода работает под PHP 4 и 5 без проблем (кроме, конечно, XML). Надеюсь, это не вызовет излишнего накала страстей.
P.P.S. В сравнение добавлен код JSON.
P.P.P.S. Добавлены небольшие ремарки по поводу железа и программного обеспечения. Без них, согласен с авторами комментариев, было как-то не так.

Какие настройки поставить в php

Всем привет! Сегодня хотел бы рассказать о настройке PHP-CS-Fixer для PHP проекта. PHP-CS-Fixer используется для автоматического форматирования кода в соответствии с определенными правилами, к примеру, стандартами PSR.

С помощью PHP-CS-Fixer можно повысить качество кода. Соблюдение стандартов кодирования делает код проекта более читаемым и упрощает разработку. Кроме того, использование автоматического форматирования должно помочь упростить процесс code review.

Установка

PHP-CS-Fixer устанавливается через composer такой командой:
```
composer require friendsofphp/php-cs-fixer
```
При желании, можно установить глобально.

Настройка

В корне проекта создаем файл .php_cs . Для Symfony проектов использую такую конфигурацию:
```
 declare(strict_types=1); $finder = PhpCsFixer\Finder::create() ->exclude('Migrations') ->in(__DIR__ . '/src') ->in(__DIR__ . '/tests'); return PhpCsFixer\Config::create() ->setRiskyAllowed(true) ->setRules([ '@Symfony' => true, '@PHP71Migration:risky' => true, 'concat_space' => ['spacing' => 'one'], 'psr0' => false, 'array_syntax' => ['syntax' => 'short'], 'class_definition' => ['multiLineExtendsEachSingleLine' => true], 'no_useless_else' => true, 'ordered_imports' => ['sort_algorithm' => 'alpha'], 'phpdoc_add_missing_param_annotation' => ['only_untyped' => true], 'no_short_echo_tag' => true, 'list_syntax' => ['syntax' => 'short'], 'linebreak_after_opening_tag' => true, 'void_return' => false, 'phpdoc_summary' => false, 'multiline_whitespace_before_semicolons' => ['strategy' => 'new_line_for_chained_calls'], 'visibility_required' => ['property', 'method', 'const'], ]) ->setCacheFile(__DIR__ . '/.php_cs.cache') ->setFinder($finder);
```
Для получения информации о конкретном правиле можно использовать describe команду:
```
vendor/bin/php-cs-fixer describe concat_space
```
В результате в консоль будет выведено подробное описание правила и всех доступных параметров.

Запуск

Автоматическое форматирование кода можно запустить такой командой:
```
vendor/bin/php-cs-fixer fix --allow-risky=yes --using-cache=no --config .php_cs
```
Также можно запустить форматирование для конкретного файла или директории:
```
vendor/bin/php-cs-fixer fix --allow-risky=yes --using-cache=no --config .php_cs src/Command/ vendor/bin/php-cs-fixer fix --allow-risky=yes --using-cache=no --config .php_cs src/Command/MyConsoleCommand.php
```
Параметр —allow-risky=yes отвечает за запуск «опасных» правил. Например, добавление strict types может сломать существующий код, поэтому считается опасным. Параметр —using-cache=no отключает использование кэша. Имеет смысл отключить кэш в случае, если количество кода не очень велико и запуск не занимает много времени/ресурсов, Параметр —config .php_cs нужен для указания файла с настойками правил.

Дополнительно

Рекомендую добавить запуск PHP-CS-Fixer в CI/CD для постоянного запуска. Для github actions это можно сделать так:
```
steps: - name: PHP-CS-Fixer uses: docker://oskarstark/php-cs-fixer-ga with: args: --config=.php_cs.dist --diff --dry-run
```
Для более удобного локального запуска можно добавить скрипт в composer.json . И запускать таким образом composer cs-fixer .

Файл с настройками правил также доступен на gist.

На этом пока все. Спасибо за внимание!

Установка Yii ¶

Вы можете установить Yii двумя способами: используя Composer или скачав архив. Первый способ предпочтительнее так как позволяет установить новые расширения или обновить Yii одной командой.

Примечание: В отличие от Yii 1, после стандартной установки Yii 2 мы получаем как фреймворк, так и шаблон приложения.

Установка при помощи Composer ¶

Установка Composer ¶

Если Composer еще не установлен это можно сделать по инструкции на getcomposer.org, или одним из нижеперечисленных способов. На Linux или Mac используйте следующую команду:
```
curl -sS https://getcomposer.org/installer | php mv composer.phar /usr/local/bin/composer 
```
На Windows, скачайте и запустите Composer-Setup.exe.

В случае возникновения проблем читайте раздел «Troubleshooting» в документации Composer. Если вы только начинаете использовать Composer, рекомендуем прочитать как минимум раздел «Basic usage».

В данном руководстве предполагается, что Composer установлен глобально. То есть он доступен через команду composer . Если вы используете composer.phar из локальной директории, изменяйте команды соответственно.

Если у вас уже установлен Composer, обновите его при помощи composer self-update .

Примечание: Во время установки Yii Composer запрашивает довольно большое количество информации через Github API. Количество запросов варьируется в зависимости от количества зависимостей вашего проекта и может превысить ограничения Github API. Если это произошло, Composer спросит логин и пароль от Github. Это необходимо для получения токена для Github API. На быстрых соединениях это может прозойти ещё до того, как Composer сможет обработать ошибку, поэтому мы рекомендум настроить токен доступа до установки Yii. Инструкции приведены в документации Composer о токенах Github API.

После установки Composer устанавливать Yii можно запустив следующую команду в папке доступной через веб:

Установка Yii ¶
```
composer create-project --prefer-dist yiisoft/yii2-app-basic basic 
```
Эта команда устанавливает последнюю стабильную версию Yii в директорию basic . Если хотите, можете выбрать другое имя директории.

Информация: Если команда composer create-project не выполняется нормально, попробуйте обратиться к разделу «Troubleshooting» документации Composer. Там описаны другие типичные ошибки. После того, как вы исправили ошибку, запустите composer update в директории basic .

Подсказка: Если вы хотите установить последнюю нестабильную ревизию Yii, можете использовать следующую команду, в которой присутствует опция stability:
```
composer create-project --prefer-dist --stability=dev yiisoft/yii2-app-basic basic 
```
Старайтесь не использовать нестабильную версию Yii на рабочих серверах потому как она может внезапно поломать код.

Установка из архива ¶

Установка Yii из архива состоит из трёх шагов:
1. Скачайте архив с yiiframework.com;
2. Распакуйте скачанный архив в папку, доступную из Web.
3. В файле config/web.php добавьте секретный ключ в значение cookieValidationKey (при установке через Composer это происходит автоматически):
```
// . insert a secret key in the following (if it is empty) - this is required by cookie validation 'cookieValidationKey' => 'enter your secret key here', 
```
Другие опции установки ¶

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

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

После установки приложение будет доступно по следующему URL:
```
http://localhost/basic/web/index.php 
```
Здесь подразумевается, что вы установили приложение в директорию basic в корневой директории вашего веб сервера сервер работает локально ( localhost ). Вам может потребоваться предварительно его настроить.

Вы должны увидеть страницу приветствия «Congratulations!». Если нет — проверьте требования Yii одним из способов:
- Браузером перейдите по адресу http://localhost/basic/requirements.php
- Или выполните команду в консоли:
```
cd basic php requirements.php 
```
Для корректной работы фреймворка вам необходима установка PHP, соответствующая его минимальным требованиям. Основное требование — PHP версии 5.4 и выше. Если ваше приложение работает с базой данных, необходимо установить расширение PHP PDO и соответствующий драйвер (например, pdo_mysql для MySQL).

Настройка веб сервера ¶

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

Приложение, установленное по инструкциям, приведённым выше, будет работать сразу как с Apache, так и с Nginx под Windows и Linux с установленным PHP 5.4 и выше. Yii 2.0 также совместим с HHVM. Тем не менее, в некоторых случаях поведение при работе с HHVM отличается от обычного PHP. Будьте внимательны.

На рабочем сервере вам наверняка захочется изменить URL приложения с https://www.example.com/basic/web/index.php на https://www.example.com/index.php . Для этого необходимо изменить корневую директорию в настройках веб сервера так, чтобы та указывала на basic/web . Дополнительно можно спрятать index.php следуя описанию в разделе «Разбор и генерация URL». Далее будет показано как настроить Apache и Nginx.

Информация: Устанавливая basic/web корневой директорией веб сервера вы защищаете от нежелательного доступа код и данные, находящиеся на одном уровне с basic/web . Это делает приложение более защищенным.

Информация: Если приложение работает на хостинге где нет доступа к настройкам веб сервера, то можно изменить структуру приложения как описано в разделе «Работа на Shared хостинге».

Рекомендуемые настройки Apache ¶

Добавьте следующее в httpd.conf Apache или в конфигурационный файл виртуального хоста. Не забудьте заменить path/to/basic/web на корректный путь к basic/web .
```
# Устанавливаем корневой директорией "basic/web" DocumentRoot "path/to/basic/web"  RewriteEngine on # Если запрашиваемая в URL директория или файл существуют обращаемся к ним напрямую RewriteCond % !-f RewriteCond % !-d # Если нет - перенаправляем запрос на index.php RewriteRule . index.php # . прочие настройки.  
```
Рекомендуемые настройки Nginx ¶

PHP должен быть установлен как FPM SAPI для Nginx. Используйте следующие параметры Nginx и не забудьте заменить path/to/basic/web на корректный путь к basic/web и mysite.test на ваше имя хоста.
```
server < charset utf-8; client_max_body_size 128M; listen 80; ## listen for ipv4 #listen [::]:80 default_server ipv6only=on; ## слушаем ipv6 server_name mysite.test; root /path/to/basic/web; index index.php; access_log /path/to/project/log/access.log; error_log /path/to/project/log/error.log; location / < # Перенаправляем все запросы к несуществующим директориям и файлам на index.php try_files $uri $uri/ /index.php?$args; > # раскомментируйте строки ниже во избежание обработки Yii обращений к несуществующим статическим файлам #location ~ \.(js|css|png|jpg|gif|swf|ico|pdf|mov|fla|zip|rar)$ # try_files $uri =404; #> #error_page 404 /404.html; location ~ \.php$ < include fastcgi.conf; fastcgi_pass 127.0.0.1:9000; #fastcgi_pass unix:/var/run/php5-fpm.sock; > location ~ /\.(ht|svn|git) < deny all; > > 
```
Используя данную конфигурацию установите cgi.fix_pathinfo=0 в php.ini чтобы предотвратить лишние системные вызовы stat() .

Учтите, что используя HTTPS необходимо задавать fastcgi_param HTTPS on; чтобы Yii мог корректно определять защищенное соединение.

Читать:
Какая лампочка в холодильнике индезит