php get php config

ini_get

(PHP 4, PHP 5, PHP 7, PHP 8)

ini_get — Получает значение настройки конфигурации

Описание

В случае успешного выполнения возвращает значение настройки конфигурации.

Список параметров

Имя настройки конфигурации.

Возвращаемые значения

Примеры

Пример #1 Несколько примеров использования ini_get()

/*
Наш файл php.ini содержит следующие настройки:

display_errors = On
register_globals = Off
post_max_size = 8M
*/

Результатом выполнения данного примера будет что-то подобное:

Примечания

Замечание: Возвращаемые логические значения

Boolean-значение ini-настройки off будет возвращено в виде пустой строки или строки «0», в то время как значению on будет соответствовать строка «1». Функция также может возвращать буквенные значения INI-настройки.

Замечание: Возвращаемые значения количества памяти

ini_get() не может прочесть опции типа «массив», такие как pdo.dsn.*, и возвращает false таких случаях.

Смотрите также

User Contributed Notes 11 notes

another version of return_bytes which returns faster and does not use multiple multiplications (sorry:). even if it is resolved at compile time it is not a good practice;
no local variables are allocated;
the trim() is omitted (php already trimmed values when reading php.ini file);
strtolower() is replaced by second case which wins us one more function call for the price of doubling the number of cases to process (may slower the worst-case scenario when ariving to default: takes six comparisons instead of three comparisons and a function call);
cases are ordered by most frequent goes first (uppercase M-values being the default sizes);
specs say we must handle integer sizes so float values are converted to integers and 0.8G becomes 0;
‘Gb’, ‘Mb’, ‘Kb’ shorthand byte options are not implemented since are not in specs, see
http://www.php.net/manual/en/faq.using.php#faq.using.shorthandbytes

Be aware that max_execution_time can be altered by XDebug.

It makes sense, since debugging manually takes time so we don’t want the script to time out ; but in that particular case, it made it look to the script like max_execution_time was 0, so calculations were wrong.

Источник

get_cfg_var

(PHP 4, PHP 5, PHP 7, PHP 8)

get_cfg_var — Извлекает значение настройки конфигурации PHP

Описание

Функция не вернёт никакой информации, заданной при сборке PHP или указанной в конфигурационном файле Apache.

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

Список параметров

Имя настройки конфигурации.

Возвращаемые значения

Возвращает текущее значение настройки конфигурации PHP option или false в случае возникновения ошибки.

Смотрите также

User Contributed Notes 6 notes

get_cfg_var returns the value from php.ini directly,while the ini_get returns the runtime config value. I have tried it on PHP 5.1.6

settings with the value of ‘yes’ will be returned as ‘1’.

//#my ini file
//A = 1
//B = any-thing
//C = yes
//D = /some/path/file

get_cfg_var ( ‘A’ ) // returns ‘1’
get_cfg_var ( ‘B’ ) // returns ‘any-thing’
get_cfg_var ( ‘C’ ) // returns ‘1’, wait, why?
get_cfg_var ( ‘D’ ) // returns ‘/some/path/file’
?>

I had my setting = yes and then checked it as ===»yes» for epic fail.

keep in mind get_cfg_var() returns a string(1) ‘1’ for the value: On

$A1 = get_cfg_var ( «A» ) === «On» ;
$A2 = get_cfg_var ( «A» ) === 1 ;
$A3 = get_cfg_var ( «A» ) === «1» ;

//$A1 is false
//$A2 is false
//$A3 is true
?>

Regarding the statement by the earlier poster that:

«Unfortunately, you almost never want to know the original value in the config file. Instead, you want to know the value currently in effect.»

I have found this useful for changing the error reporting levels for a few specific pages while testing. I turn on all error_reporting while testing, but for a few pages I want to turn off notices. So, I put this at the top of the page:

( 8183 );
?>

and this at the bottom:

( get_cfg_var ( ‘error_reporting’ ));
?>

to put it back to whatever default I had at the time.

Источник

Создание конфигурационного файла в PHP

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

у меня есть 2 идеи до сих пор.

1-Использовать Переменную

2-Используйте Const

3-Использовать Базу Данных

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

10 ответов:

один простой, но элегантный способ создать config.php файл (или как вы его называете), который просто возвращает массив:

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

так что единственное, что вам нужно сделать, это позвонить:

важно: по соображениям безопасности INI-файл должен находиться в непубличной папке

Я использую небольшую эволюцию @hugo_leonardo ‘ s решение:

кроме того, если ваше приложение имеет конфигурации, которые вам нужны на стороне клиента (например, для углового приложения), вы можете иметь это config.php файл содержит все ваши конфигурации (централизованные в одном файле вместо одного для JavaScript и одного для PHP). Тогда трюк будет иметь другой PHP-файл что бы echo только информация на стороне клиента (чтобы избежать отображения информации, которую вы не хотите показывать как строку подключения к базе данных). Назовите это сказать get_app_info.php :

выше предполагая, что ваш config.php содержит элемент :

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

варианты, которые я вижу:

механизмы на основе файлов

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

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

общие форматы файлов, используемые для конфигурационных файлов являются PHP код, ini форматированные файлы, JSON, XML, YAML и сериализованные PHP

PHP-кода

The include_path предоставляет средство для абстрагирования потенциальных местоположений файла без использования дополнительного кода.

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

если конфигурация создается из инструмента, возможно, можно проверить данные в инструменте, но нет стандартной функции для экранирования данных для встраивания в PHP-код, как существует для HTML, url, операторов MySQL, команд оболочки.

сериализованные данные Это относительно эффективно для малых объем конфигурации (до 200 элементов) и позволяет использовать любую структуру данных PHP. Для создания / анализа файла данных требуется очень мало кода (поэтому вы можете вместо этого потратить свои усилия на то, чтобы файл был написан только с соответствующим разрешением).

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

поскольку вы можете сериализовать объекты, он создает возможность для вызова кода просто путем чтения файла конфигурации (the __wakeup magic method).

структурированный файл

хранение его в виде INI-файла, как предложено Marcel или JSON или XML, также предоставляет простой api для отображения файла в структуру данных PHP (и, за исключением XML, для экранирования данных и создания файла), устраняя уязвимость вызова кода с помощью сериализованных данных PHP.

Он будет иметь аналогичные характеристики для сериализованных данных.

Edit: чтобы ответить на ваш комментарий-ни один из механизмов разбора не будет самым быстрым (ini, json и т. д.), но они также не являются частями вашего приложения, которые вам действительно нужно сосредоточиться на оптимизации, поскольку разница в скорости будет незначительной для таких небольших файлов.

обычно я в конечном итоге создаю один conn.php-файл, который имеет моего подключения к базе данных. Затем я включаю этот файл во все файлы, которые требуют запросов к базе данных.

Define сделает константу доступной везде в вашем классе без необходимости использовать global, в то время как переменная требует global в классе, я бы использовал DEFINE. но опять же, если параметры БД должны изменяться во время выполнения программы, вы можете придерживаться переменной.

вы можете создать класс конфигурации ведьма статические свойства

затем вы можете просто использовать это:

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

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

где-то в конфигурационном файле вы выбираете:

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

. и где-то в коде (например. в каком-то классе обслуживания):

Источник

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

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

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

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

INI-файлы

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

PHP-скрипты

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

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

XML-файлы

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

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

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

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

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

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

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

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

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

Пример:

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

JSON-файлы NEW!

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

Выводы

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

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

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

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

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

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

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

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

Источник

Php get php config

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

Опции конфигурации в PHP

Различные опции

Компилировать с информацией об отладке.

Устанавливает, каким образом установленные файлы будут расположены. TYPE принимает значения PHP (по умолчанию) или GNU.

Установить PEAR в директорию DIR (по умолчанию PREFIX/lib/php).

Не устанавливать PEAR.

Включить собственный дескриптор SIGCHLD для PHP.

Не передавать дополнительные пути для поиска библиотек времени исполнения.

Явно использовать libgcc.

Включить экспериментальную функциональность потоков PHP. Используйте только в случае, если вы тестируете код!

Определить местонахождение библиотеки zlib.

Использовать потоки (threads) POSIX (по умолчанию).

Собирать общие библиотеки [по умолчанию=yes].

Собирать статические библиотеки [по умолчанию=yes].

Оптимизировать для быстрой установки [по умолчанию=yes].

Предполагать, что компилятор С использует линкер GNU ld [по умолчанию=no].

Избегать блокирования (может испортить параллельные сборки).

Пытаться использовать только PIC/не PIC объекты [по умолчанию=use both (использовать оба)]

Экспортировать только необходимую информацию для отладки. Смотрите INSTALL для дополнительной информации.

Опции PHP

Включает правила сборки и зависимости make, неиспользуемые (а иногда запутывающие) в обычном установщике.

Включает безопасный режим по умолчанию.

Данная возможность была объявлена УСТАРЕВШЕЙ, начиная с PHP 5.3.0 и была УДАЛЕНА в PHP 5.4.0.

Данная возможность была объявлена УСТАРЕВШЕЙ, начиная с PHP 5.3.0 и была УДАЛЕНА в PHP 5.4.0.

Включает автоматическое экранирование специальных символов по умолчанию.

Данная возможность была объявлена УСТАРЕВШЕЙ, начиная с PHP 5.3.0 и была УДАЛЕНА в PHP 5.4.0.

Включает поддержку многобайтового кода в синтаксическом и лексическом анализаторе языка при запуске. Когда PHP скомпилирован с этой опцией, становится активной также директива encoding в конструкции declare.

Данная возможность была объявлена УСТАРЕВШЕЙ, начиная с PHP 5.3.0 и была УДАЛЕНА в PHP 5.4.0.

Опции SAPI

Следующий список включает доступные опции SAPI ( Server Application Programming Interface ) для PHP.

Включает таблицы перекодировки для модуля mod_charset (для русской версии Apache).

Включает поддержку модуля SAPI для интерактивного дебаггера phpdbg.

Отключает сборку CGI-версии PHP.

Источник