Чому публічні веб-додатки не використовують файли ini для конфігурації

10

Практично кожен загальнодоступний CMS використовує файл конфігурації .php для налаштувань бази даних тощо. Наприклад, WordPress автоматично створює конфігураційний файл .php при його встановленні.

Чому вони просто не використовують файл .ini? У PHP вже є parse_ini_file (), і я впевнений, що інші мови мають подібні функції.

php cms configuration

— thelolcat
джерело

9

Зокрема, з PHP; різниця між файлом .ini та файлом .conf.php незначна.

Використання PHP безпосередньо для конфігурації має виразну перевагу лише у тому, що потрібно зв’язатися з одним чітко визначеним переносним синтаксисом для конфігурації, а факт того, що файл конфігурації є правильним кодом, іноді корисний.

У порівнянні з цим; файл ini може нічого не запропонувати; і include, requireі require_onceвсе добре відомі , і ( в основному) добре вивчені.

— Вілліхам Тотланд
джерело

relate to one well-defined, portable syntax for configurationЯ цього не розумію. ini-файли також мають чітко визначений і портативний синтаксис. Кожен .conf.phpфайл має свою структуру, більшість засновані на масиві, але це не так інакше, ніж файл ini.

— янніс

7

Також зауважте, що файл PHP може забезпечити основну безпеку. Якщо Joomla використовував XML або .iniфайли для зберігання конфігурації, без сумніву, було б багато неправильно налаштованих екземплярів, які працюють там, де конфігурація була загальнодоступною, що зазвичай не дуже добре. З PHP-файлами сервер буде дуже-дуже рідкісним, коли його неправильно налаштовують для розміщення вмісту його відвідувачу.

— Том Мартенал

4

Взагалі, я віддаю перевагу .iniфайлам конфігурації XML. У великих системах часто комусь, крім розробника, потрібно буде змінити значення конфігурації, можливо, DBA або sysadmin. Більшість DBA та sysadmins, яких я знаю, не мали б проблем із навігацією через простий скрипт PHP, але я вважаю за краще, якщо б вони цього не зробили. Одна невелика помилка там може завдати шкоди всій програмі досить кількома способами.

Але в менших системах надзвичайно зручно використовувати сценарії PHP для налаштування. Я сьогодні грав з AWS SDK , який також використовує сценарій PHP для конфігурації:

CFCredentials::set(array(
    'development' => array(
        'key' => 'xxx',
        'secret' => 'xxxx',
        'default_cache_config' => sys_get_temp_dir(),
        'certificate_authority' => true
    ),
    '@default' => 'development'
));

Замість жорсткого кодування a default_cache_config, я передаю системний темп, і це працювало б у кожній системі, в якій я розгортаю сценарій. Цей сценарій є невеликим доказом концепції, яку пройдуть близько 10 розробників, і я хочу, щоб вони запустили її так, як є, без того, щоб багато про що думати. Якщо прототип розвиватиметься, я перекладу його з моїм класом конфігурації XML (і явно не буду покладатися на кеш файлової системи).

— яніс
джерело

"Одна невелика помилка там може завдати шкоди всій програмі досить кількома способами". Як би недійсні значення для ini не будуть? Або що XML будь-який дружній?

— whatsisname

@whatsisname Як правило, якщо неправильно встановлене значення конфігурації гальмує вашу систему, ваші проблеми є в іншому місці. Я думав більше про ненавмисний фрагмент коду в конфігурації сценарію, роблячи щось екстремальне, те, що я відчував не один раз. У файлі ini / xml це неможливо, головне - конфігурація сценарію - це не те, що ви хотіли б поділитися з не розробниками.

— янніс

3

Відповідь проста: у conf.php в основному нульова робота, необхідна для роботи. Це просто ще один вихідний файл.

— whatsisname
джерело

0

Швидкість без кешування також може бути причиною. Конфігурацію PHP можна при необхідності прозоро кешувати за допомогою коду. Тоді як INI-файл потрібно аналізувати кожен раз, коли він читається, і вам потрібно створити кеш самостійно. Для невеликих файлів це нормально, але при сотенні рядків, розібраних у кожному запиті, він може піднятися до десятків мілісекунд, що досить багато для оптимізованого веб-інтерфейсу за 200 мс.

— Томаш Фейфар
джерело