В каком файле размещаются конфигурационные данные php

Обновлено: 03.07.2024

Новые статьи

Полезные ссылки

Структура и восстановление файла config.php

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

Итак, давайте рассмотрим создание нового config.php.

Чтобы создать новый файл config.php, необходимо использовать текстовые редакторы для Windows, такие как Notepad (блокнот) или лучше текстовые простые редакторы, например Notepad++ или Notepad2.

Откройте текстовый редактор и создайте новый файл.
В этот файл вставьте следующий код:

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

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

$dbms = 'mysql'; замените mysql в соответствии с типом используемой базы данных. Можете использовать следующие типы:
mysql
mysqli
firebird
mssql
mssql_odbc
oracle
postgres
sqlite

$dbport = 'database port if not default'; замените database port if not default на номер порта сервера базы данных, который используется для входящих соединений. Если сервер использует порт по умолчанию, оставьте это поле пустым. Вам необходимо ввести какое-то другое значение, если сервер базы данных использует другой порт, отличный от порта по умолчанию.

$dbname = 'database name'; замените database name на имя базы данных, которую вы указали при установке конференции phpBB3. Если у вас есть доступ к базам данных посредством например PhpMyAdmin, вы сможете узнать его оттуда, в противном случае обратитесь за помощью к вашему провайдеру.

$dbuser = 'database user name'; замените user name на значение учетной записи пользователя базы данных. Во всех случаях для подключения к базе данных требуется учетная запись пользователя, которая используется для подключения к ней.

$dbpasswd = 'database password'; замените database password на пароль к учетной записи пользователя базы данных.

$table_prefix = 'database table prefix'; замените database table prefix на префикс таблиц базы данных. По умолчанию, если вы не меняли префикс при установке, он будет phpbb_ , однако возможно вы его изменили, поэтому проверьте его, подключившись к базе данных через phpMyAdmin.

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

$acm_type = 'file';
$load_extensions ='';
@DEFINE ('PHPBB_INSTALLED', true);

После завершения редактирования файла сохраните его под именем config.php , убедившись, что текстовый редактор не сохранил его как config.txt или config.php.txt.

Теперь у вас есть ваш новый config.php, который необходимо загрузить с помощью FTP-клиента. Он должен быть загружен в папку, где установлен сам форум phpBB3, в том же самом месте, что и файл common.php.

В большинстве случаев FTP-клиент установит правильные права доступа к файлам, но вы должны убедиться, что на файл установлены права 644 (chmod 644).

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

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

Пример:
<root>
<x1>1</x1>
<x2>2</x2>
<x3>3</x3>
</root>

Скрипт:
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 позволило получить следующие результаты:

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

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

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

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

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

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

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

и затем:

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

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

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

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

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

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

PHP-кода

Это обеспечивает огромную гибкость для представления различных структур данных, и (предполагая, что он обрабатывается с помощью include или require) анализируемый код будет доступен из кэша кода операции - что дает преимущество в производительности.

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. но опять же, если параметры БД должны изменяться во время выполнения программы, вы можете придерживаться переменной.

Если вы думаете, что будете использовать более 1 дБ по какой-либо причине, перейдите к переменной, потому что вы сможете изменить один параметр, чтобы переключиться на совершенно другую дБ. Т. е. для тестирования , автоматического резервного копирования и т. д.

способы хранения конфигурации для веб-приложения, написанного на PHP?
Я видел, как люди используют .ini, basic .PHP и др.
Кроме того, define() или просто глобальные переменные?
Большинство информации, как вы можете найти.
Кроме того, являются ли базы данных хорошими методами хранения конфигурации?

нет " лучшего способа (tm)" для хранения конфигураций приложений. На самом деле все зависит от вашего приложения, вида конфигураций, как часто они могут/должны меняться и как легко вы хотите их изменить.

некоторые люди используют полный синглтон (или статический) Config класс для приложения. Что выглядит примерно так (с различными уровнями сложности):

это удобно, потому что вы можете называть его везде, где вы хотите в вашем применение с Config::set() или Config::get() . Затем у вас есть центральное место, которое настроено все ваше приложение, и вы можете сделать его сложным или простым, как вам нравится. Вы можете создавать резервные копии в базе данных, memcached и т. д.

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

самый быстрый способ и, следовательно, самый "трудный" для изменения-использовать config.php файл или тому подобное. Этот файл $_GLOBALS определения ключей массива или define() для значений, к которым вам нужен доступ во всем вашем приложении. Это быстро, потому что он включен в запрос и жестко закодирован в PHP, поэтому все, что PHP должен сделать, это интерпретировать файл - нет сетевого ввода-вывода или каких-либо дополнительных накладных расходов, кроме минимальных накладных расходов на включение файла в ваш скрипт. То, что вы храните в этих файлах PHP, - это такие вещи, как учетные данные подключения MySQL, учетные данные подключения к веб-службе и т. д.

для приложение, которое имеет много пользователей и много настроек, вам, вероятно, придется развернуть "гибрид" методов или придумать свой собственный. Для чего-то, что является просто стандартным развертыванием приложения, вы можете уйти с очень простым config.php тип подхода.

Я не думаю, что есть лучший способ, каждый способ имеет свои преимущества и недостатки. Просто убедитесь, что файл конфигурации (особенно если она содержит пароли)недоступно в общедоступном каталоге, но где-то в частном.

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

С помощью define(); создаст константы, значение которых нельзя изменить во время выполнения. В одних случаях это работает, в других-нет. Если вы хотите, чтобы ваша конфигурация была доступна везде - в каждой области-вы могли бы рассмотреть возможность чтения конфигурации в класс (возможно, одноэлементный шаблон?) чтобы вы могли получить доступ к значениям конфигурации повсюду.

я использовал включенный php-файл .ini-файлы, XML-файлы и JSON-файлы для настройки, лично я предпочитаю избегать .файлы конфигурации php, поскольку я делюсь своими файлами конфигурации между несколькими языками для разных приложений в моих веб-приложениях и придерживаюсь других "стандартов".

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

хранить конфиги на .PHP-файл. Вы можете использовать глобальные переменные, функции define() или обычные переменные. Define обычно лучше всего подходит. Для большей безопасности поместите его вне общедоступного каталога.

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

как на самом деле @ Roger Ng указал, принятый ответ на самом деле не работает. Проблема в том, что вы не можете использовать $this в статическом методе.
PHP: Ключевое слово Static-Manual

Я думал об этом следующим образом:

Я использую функцию Config::init() создать настройки по умолчанию, чтобы вернуться к, и Config::merge() функция для объединения конфигураций по умолчанию с, например, производственными значениями.

так вот мой default_config.php может выглядеть следующим образом:

и мой конфиг.php что-то вроде следующего:

в фактическом коде я получу свои значения конфигурации точно так же, как это сделано в принятом ответе, написав Config::get('key') .

IMO, сегодня имеет смысл хранить ваши данные конфигурации в файле JSON.

некоторые преимущества JSON:

родная поддержка на многих языках программирования
легко читать для людей
легко читать для машин
малый размер файла

пример кода :

файл Json:

класс PHP :

загрузка файла Json:

это то, что я делаю.

во-первых, я определяю общий Dataset класс, который я могу использовать для глобального хранилища данных :

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

обратите внимание, что важно добавить правило protected static $_data = array(); до Config class или любые другие дочерние классы, если вы не хотите, чтобы они разделяли один и тот же массив.

Я изменил код James & Zachu. Вот моя реализация. При поиске значения и при его наличии возвращается пустая строка. Таким образом, никаких уведомлений не будет. Существует метод delete. комментарии и форматирование кода.

Читайте также: