Php хранить настройки в файле

Лучший способ сохранить настройки PHP-приложения?

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

• рассчитать ранг пользователя
• Как сделать массив для добавления нескольких строк в таблицу sql той же формой
• Уязвимости от mysql_escape_string
• Есть ли способ использовать инструкции подготовки wpdb для массива implode (‘OR’, $ myArray)?
• Как «делать что-то OR DIE ()» в PHP?
• Многомерное хранилище массивов CodeIgniter в одной колонке базы данных mysql

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

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

UPDATE: Да. A .ini или разбор включенного файла будет приятным, и я знаю, как это сделать. Но я хотел знать, какой будет лучший подход к их хранению в MySQL со всем остальным.

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

Solutions Collecting From Web of «Лучший способ сохранить настройки PHP-приложения?»

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

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

ОБНОВИТЬ:

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

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

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

Для сайтов с высоким трафиком с большими конфигурациями рекомендуется кэшировать ваши данные конфигурации в APC (например, в виде единого массива) – по крайней мере, вы сохраняете накладные расходы на выполнение операторов в файле config.php. Примечательно, что facebook делает это. Когда вы подаете много запросов в секунду, при каждом нажатии запроса на чтение файла конфигурации (с использованием parse_ini_file, анализатора XML и т. Д.) На каждый запрос не может быть и речи.

Для моего текущего проекта у нас есть много сайтов, каждый со своей собственной конфигурацией. На каждом сайте были и база данных, и файл конфигурации; однако, убедитесь, что вы всегда используете правильный файл конфигурации с правильной базой данных, которая может стать головной болью. Кроме того, изменения потребуют изменения вещей в двух местах – db и config. Забывание того или другого всегда вызывало проблемы, и это случалось слишком часто.

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

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

$siteConfig['db_name'] = 'database1'; $siteConfig['site_name'] = 'Stackoverflow'; 

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

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

Просто об этом поговорили с несколькими людьми в IRC. Я посмотрел, как WordPress справился с этим после того, как я вытащил SQL-дамп одной копии. Я думаю, что я буду использовать этот макет и немного переименовать столбцы. Но идея …

option_id | option_name | option_value | autoload int | varchar | longtext | varchar (PRIMARY) | (UNIQUE) | | 

Обычно я в файле index.php настраиваю «необходимые» настройки так:

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

 http://localhost/public/images/ */ define('CSS', URIPATH.'public/css/'); // DEFINE DIR: css define('IMG', URIPATH.'public/images/'); // DEFINE DIR: images define('JS', URIPATH.'public/scripts/'); // DEFINE DIR: scripts // system define('INC', BASEPATH.'system/includes/'); // DEFINE DIR: includes define('LIB', BASEPATH.'system/lib/'); // DEFINE DIR: lib define('SQL', BASEPATH.'system/sql/'); // DEFINE DIR: sql if (DEBUGGER) < ini_set('log_errors',TRUE); ini_set("error_log", BASEPATH.'system/'."error_log.txt"); >else < ini_set('log_errors',TRUE); ini_set("error_log", BASEPATH.'system/'."error_log.txt"); >$db_info = array( 'host' => 'localhost', 'username' => 'root', 'password' => 'root', 'database' => 'my_db' ); /* to use: $db_info = unserialize(DB_INFO); echo $db_info['host']; echo $db_info['username']; echo $db_info['password']; echo $db_info['database']; */ define('DB_INFO', serialize($db_info)); ?> 

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

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

• Подсчет количества символов X
• Объединение двух сложных объектов в PHP
• Поиск массива без учета регистра
• Композитный шаблон в PHP, как создавать классы для работы вокруг необходимости расширения двух классов
• Преобразование SWF в PNG
• Получите все уведомления об уведомлении PostgreSQL о повышении
• Codeigniter & HTML5 – попытка одновременного загрузки нескольких изображений
• Удаление # из url в Angularjs при использовании .run в маршрутах
• Ссылка на открытый почтовый клиент и файл прикрепления?
• Загрузка файла .zip в формате .php
• Лучшие практики в PHP и MySQL с международными строками
• Отображение цены только при выборе варианта и скидки в процентах относительно обычной цены
• Команда «clear-compiled» не определена. Laravel 5.2
• php mysql single record show
• PHP header () перенаправляет переменные POST

Источник

Где хранить конфигурацию php приложения?

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

Рассмотрим на простом примере как оптимизировать хранение настроек приложения.

Создадим файл index.php со следующим содержимым:

 // Настройки для подключения к базе данных $dbHost = 'localhost'; $dbUser = 'tester'; $dbPassword = 'fB8vh83gHj4'; $dbDatabase = 'my_base'; // Настройки для отправки почты через SMTP $mailerHost = 'smtp.yandex.ru'; $mailerUsername = 'sender@test.ru'; $mailerPassword = 'fdDj3gf4Hbh'; $mailerPort = '465'; $mailerEncryption = 'SSL'; 

Мы видим 2 группы переменных: первая для подключения к базе данных, а вторая для отправки письма по smtp протоколу. Избавимся от многочисленных переменных, объединив все значения в один многомерный ассоциативный массив.

 $config = [ 'db' => [ 'host' => 'localhost', 'user' => 'tester', 'password' => 'fB8vh83gHj4', 'database' => 'my_base' ], 'mailer' => [ 'host' => 'smtp.yandex.ru', 'username' => 'sender@test.ru', 'password' => 'Vbs3Hts42sdh', 'port' => '465', 'encryption' => 'SSL' ] ]; 

Уже лучше. В современных Web приложениях конфигурацию принято хранить в отдельном файле / файлах. Давайте создадим файл config.php, перенесём туда наш массив и подгрузим его в index.php

Подключать будем с помощью конструкциии require, использовав её полезную особенность — возможно выполнить выражение return внутри включаемого файла. Делать это нужно следующим образом:

 // Код файла config.php return [ 'db' => [ 'host' => 'localhost', 'user' => 'tester', 'password' => 'fB8vh83gHj4', 'database' => 'my_base' ], 'mailer' => [ 'host' => 'smtp.yandex.ru', 'username' => 'sender@test.ru', 'password' => 'Vbs3Hts42sdh', 'port' => '465', 'encryption' => 'SSL' ] ]; 

В файле конфигурации мы сделали return нашего массива. А в index.php присвоим этот массив переменной $config, используя выражение require.

 // Код файла index.php $config = require 'config.php'; print_r($config); 

С помощью print_r выведем результат. Вот что у нас получилось:

Если конфиг слишком большой, разбивать его на несколько файлов и собирайте с помощью require.

Хранение файла конфигурации в репозитории

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

Это нужно сделать по следующим причинам:

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

Перейдём к практике. Создайте файл «config.sample.php». Скопируйте туда созержимое вашего файла конфигурации и удалите как минимум значения важных (в нашем случае — паролей).

 // Код файла config.sample.php return [ 'db' => [ 'host' => 'localhost', 'user' => '', 'password' => '', 'database' => '' ], 'mailer' => [ 'host' => '', 'username' => '', 'password' => '', 'port' => '465', 'encryption' => 'SSL' ] ]; 

Добавьте файл config.sample.php в репозиторий. А боевой файл конфигурации config.php не должен туда попадать, поэтому исключите его из индексации, добавив строчку в файл «.gitignore«:

Источник

Как правильно организовать хранение и чтение настроек сайта?

Собственно, разрабатываю сайт на php. Столкнулся с вечным вопросом хранения настроек сайта. Варианты, которые рассматривал: mysql база и ini файлы.

Но вот вопрос, если хранить настройки в базе, то когда происходит чтение из базы, мы совершаем запрос. А если надо прочитать 30 настроек, то будет +30 запросов, что при большой посещалке скажется на производительности.

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

Прошу учитывать изначально хранение тысячу полей в настройках (как в cms это обычно бывает).

Предложу тогда и свой вариант. Храните настройки в сериализованом виде: как только сайт открывается, он проверяет наличие файла (например: settings.dat), если файл найден — читает его и делает unserialize — на выходе получается массив настроек. Если файла нет — делаете запрос в базу (как предлгал @VasiliyIsaichkin) и затем полученный массив настроек сохраняете в файл (например settings.dat) через serialize функцию + при каждом изменении настроек CMS — удаляйте файл settings.dat и он будет снова синхронизирован с БД.

Источник