Хранение настроек в файле php

Обновлено: 07.07.2024

Файл конфигурации ( php.ini ) считывается при запуске PHP. Для версий серверных модулей PHP это происходит только один раз при запуске веб-сервера. Для CGI и CLI версий это происходит при каждом вызове.

  • По месту расположения модуля SAPI ( PHPIniDir директива Apache 2, -c параметр командной строки CGI и CLI)
  • Переменная среды PHPRC .
  • Местоположение файла php.ini может быть указано для различных версий PHP. Корневой ключ реестра зависит от разрядности операционной системы и установки PHP. Для 32-разрядного PHP на 32-разрядной Windows или 64-разрядного PHP и 64-разрядной Windows используйте [(HKEY_LOCAL_MACHINE\SOFTWARE\PHP] . Для 32-разрядного PHP на 64-разрядной Windows [HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\PHP] . Следующие ключи реестра исследуются при поиске для установок с совпадающей разрядностью: [HKEY_LOCAL_MACHINE\SOFTWARE\PHP\x.y.z] , [HKEY_LOCAL_MACHINE\SOFTWARE\PHP\x.y] и [HKEY_LOCAL_MACHINE\SOFTWARE\PHP\x] , где x, y и z подразумевают major, minor и release версии PHP. Для 32-разрядного PHP на 64-разрядной Windows ключи реестра будут другими: [HKEY_LOCAL_MACHINE\SOFTWARE\WOW6421Node\PHP\x.y.z] , [HKEY_LOCAL_MACHINE\SOFTWARE\WOW6421Node\PHP\x.y] и [HKEY_LOCAL_MACHINE\SOFTWARE\WOW6421Node\PHP\x] . Если также имеется значение IniFilePath в любом из этих ключей, то местонахождение php.ini будет определено первым ключом по порядку (только для Windows).
  • [HKEY_LOCAL_MACHINE\SOFTWARE\PHP] или [HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\PHP] , значение IniFilePath (только для Windows).
  • Текущая директория (исключая CLI).
  • Директория веб-сервера (для модулей SAPI) или директория PHP (иначе в Windows).
  • В директории Windows ( C:\windows или C:\winnt ) (для Windows) или --with-config-file-path с выбором при компиляции.

Если файл php-SAPI.ini существует (где SAPI - это тип интерфейса, который используется, например, php-cli.ini или php-apache.ini ), то он используется вместо php.ini . Тип интерфейса между веб-сервером и PHP может быть определён с помощью функции php_sapi_name() .

Замечание:

Веб-сервер Apache изменяет текущую директорию на корневую при запуске, в результате чего PHP считывает php.ini из корневой файловой системы, если файл существует.

В php.ini можно использовать переменные окружения, как показано ниже.

Директивы php.ini , обрабатываемые модулями, описаны на соответствующих страницах модулей. Список директив ядра имеется в приложении. Не все директивы PHP документированы в этом руководстве: для ознакомления с полным списком директив доступных в вашей версии PHP, прочитайте комментарии вашего php.ini . Кроме того, вы можете найти полезной » последнюю версию php.ini из Git.

Возможно обращаться к существующим ini-переменным из ini-файлов. Пример: open_basedir = $ ":/new/dir" .

Сканирование директорий

Существует возможность сконфигурировать PHP для сканирования директорий в поисках .ini-файлов после считывания php.ini . Это можно сделать на моменте компиляции, указав опцию --with-config-file-scan-dir. Сканирование директорий может быть переопределено во время исполнения установкой переменной среды PHP_INI_SCAN_DIR .

Можно сканировать несколько директорий, разделяя их разделителем, используемом в вашей операционной системе ( ; в Windows, NetWare и RISC OS; : на всех остальных платформах; в PHP есть константа PATH_SEPARATOR , которую можно использовать) Если PHP_INI_SCAN_DIR пуста, то PHP также будет сканировать директорию, заданную на этапе компиляции с помощью --with-config-file-scan-dir.

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

способы хранения конфигурации для веб-приложения, написанного на 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. комментарии и форматирование кода.

Сегодня заведём разговор на такую, казалось бы простую, тему, как конфигурация сайта. То есть поговорим о таких вещах, как параметры подключения к БД, различные настройки, как всё это хранить и как со всем этим работать.

Разобьём этот разговор на три части:

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


Итак, где же можно хранить настройки системы?

Нигде не хранить

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

mysql_connect('localhost', 'vasa', 'qwerty');

И так желательно сделать в каждом файле, где нужен доступ к базе. Тогда попытка изменить какой-то параметр обязательно превратиться в незабываемый праздник.

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

Глобальные переменные

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

Уже лучше, но есть и минусы. Те же самые, что и вообще у глобальных переменных. Загадили глобальный контекст неоднородными, неструктурированными данными. С областями видимости будут постоянные проблемы. А так как и вся система при таком конфиге, очевидно, будет построена на глобальных переменных, то встаёт вопрос конфликта имён со всеми неприятно вытекающими последствиями.

Константы

define('DB_HOST', 'localhost'); define('DB_USER', 'vasa'); // .

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

Имея небольшое преимущество перед глобальными переменными, в некоторых случаях константы даже хуже них.

База данных

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

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

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

Такое решение обычно предполагается гибким, так как позволяет менять настройки через какую-нибудь админку, не имея доступа к коду (или не затрудняясь этим доступом). На деле для общих настроек это нахрен не нужно. Никому в жизни не понадобиться изменять путь к папке с темами для форума SMF. А если и понадобиться: ему всё равно придётся лезть в код и копировать эту папку на новое место.

Изменить что-то не предусмотренное в подобной админке, а тем более добавить новый параметр выливается во множество неприятных ощущений. А попытка скопировать себе сайт на локалку для разработке, превращается вообще во что-то мазохистское. После копирования нужно лезть в базу и выискивать там все параметры, которые необходимо изменить. Особенно радует, что хранятся они обычно в совершенно неудобоваримом формате.

Массивчик

Теперь у нас всё в отдельном конфигурационном массиве и не засоряет глобальную область.

Можно ещё избавиться от вредных привычек и вспомнить, что ассоциативный массив позволяет нам по-человечески всё структурировать:

Теперь и глазу приятнее и можно работать не со всем массивом, а с его частями.

return array()

Не все знают, что обработку файла можно завершать, как и для функции, с помощью оператора return . Более того, из него можно возвращать значение, которое станет результатом include или require , которыми мы этот файл подключили.

Создадим файл конфигурации ( config.php , допустим):

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

$config = include('/path/to/config.php'); // Считываем конфигурацию из файла в переменную

Интерфейс доступа

Напишем простейший класс для получения конфигурации:

$config = Config::get(); // в нужном месте

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

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

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

Улучшение интерфейса

Интерфейс доступа к конфигу (в прошлом примере это Config::get() ) можно улучшать бесконечно и по своему вкусу.

Убрать статику, а на объект навешать магических методов и SPL-интерфейсов, чтобы получилось что-то вроде:

$db_host = $config->db->host; $db_user = $config->db->user;

Получение config-объекта можно сделать через IoC-контейнер или через какую-нибудь другую заумную вещь.

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

Форматы хранения: адаптеры

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

А вот для хранения могут быть удобны разные форматы. Опять-таки массив (как выше), xml, ini-файл или ещё что-то.

Так как хранение от представления мы уже отделили, хранить мы можем в чём угодно, никак не влияя этим на интерфейс. Единственное, что нужно, это преобразовывать выбранный формат хранения к древовидной структуре для доступа к ней (то есть использовать различные адаптеры для загрузки).

Один из примеров такого подхода: Zend_Config.

P.S. Что хранить в конфиге

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

Вот такого вот делать не надо:

Потребуется что-то изменить, перенести на другой сервер, скопировать на локалку: о такое можно убиться.

Все значения, которые можно сгенерировать на основании какого-то базового, лучше генерировать:

Базовое значение в примере, также в большинстве случаев можно получить автоматически на основании $_SERVER['DOCUMENT_ROOT'] или dirname(__FILE__) .

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

Для начала, пожалуй хватит. В следующей части поговорим о более интересных вещах.

18 комментариев »

и юзаем где надо:
import settings
или
from settings import DATABASE_NAME, DATABASE_USERNAME
и т.д.

Мне такой способ хранения конфигов куда больше нравится :)

Не вижу особой разницы, если честно.
А в следующей статье напишу вещи чуть посложнее, расскажешь как такое в питоне сделать.

Спасибо, порадовал. По большей части так и делаю, видимо я на правильном пути :) .

phpdude, чего прижал? Поржал?

artoodetoo, я в тебе и не сомневался :)

Givi, сломай, дам пирожок )

>интересно как хранить настройки для всего сайта и реврайтить некоторые для поддоменов, например…?
не понял

kostyl, в следующей статейке четай.

2. В случае с путями, обычно получается построить вокруг __DIR__.

3. Я же люблю шаблоны:

return array(
'a' => 1,
'b' => 2,
'ab' => '>->',
);

В коде уже обрабатывать.

vasa_c, спасибо за идеи! Для моей текущей задачи воспользуюсь полухаком.

Не ожидал увидеть такого слаженного решения рассматриваемого вопроса.
Автору респект. :)

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

  • Глобальное имя сайта.
  • Тема (просто переменная или путь к теме)
  • так далее

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

ОБНОВИТЬ:
Да .ini или разбора файла включения было бы хорошо, и я знаю, как это сделать. Но я хотел знать, как лучше всего хранить их в MySQL вместе со всем остальным.

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

Решение

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

Поскольку вы будете использовать их неоднократно в своем PHP-приложении, это было бы наиболее идеально. Это также избавляет от необходимости совершать вызовы из базы данных, если вы должны хранить их в базе данных.

ОБНОВИТЬ:

Я предполагаю, что вы хотите, чтобы эти параметры были редактируемыми через веб-страницу, и не хотите, чтобы несколько запросов к БД изменялись, но не слишком часто?

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

Другие решения

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

  1. Небольшой сайт: просто используйте файл config.php
  2. Очень большой сайт: кеш в APC
  3. Несколько сайтов: сохранить конфигурацию в базе данных, чтобы уменьшить административные издержки; кеш в APC для уменьшения попаданий в базу данных

Мы просто используем

Во включенном файле php. Помещение значений в массив помогает при конфликтах имен.

я понимаю, что вы хотите хранить вещи в таблице mysql, однако это, вероятно, означает хранение требуемой конфигурации в нескольких местах. например, я уверен, что вы хотите, чтобы сервер базы данных и имя сохранялись где-то в строке. это означает помещать их в файл include или .ini, поскольку вы не можете прочитать их из базы данных (как вы можете подключиться к базе данных, не зная об этом). Итак, вы будете хранить информацию о подключении к БД в файле include или .ini, а остальные параметры в базе данных? это работает, я полагаю, но мне нравится хранить все настройки в одном файле (config.php или application.ini или что-то еще). это облегчает поддержание ИМО.

Я обычно в своем файле index.php устанавливаю «обязательные» настройки так:

и в моем файле конфигурации:

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

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

Поэтому я в основном использую этот метод:

Во-первых, я создаю файл config / settings.php со следующим содержимым:

Если вы хотите использовать это в своем файле index.php, добавьте в него следующую строку:

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

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