my_config.ini vs my_config.php

Question

Al lavoro utilizziamo un file .ini per impostare le variabili prima di chiamare il resto del framework (penso che vada

function getConfigVars(){
    //read my_config.ini file
    ....
    //call framework
}

e mi sono sempre chiesto se ci fosse un vantaggio nel farlo in questo modo.

Mi sembra che devi quindi scrivere le regole di accesso per impedire alle persone di guardarlo dal web e php deve analizzarlo e capirlo.

Quindi, perché usare my_config.ini anziché my_config.php? Non è come se qualcuno dovesse toccarlo dopo che è stato impostato e sembra più conveniente semplicemente chiamare le variabili ed essere in grado di fare in modo che il proprio IDE completi automaticamente il testo ovunque tu stia usando le variabili ini / analizzandolo per errori. p>

Answer 1

Il Zend Framework contiene una configurazione di analisi che analizza i file scritti nel formato ini ( Zend_Config_Ini ), sembra che questo sia quello che stai usando.

Il file di configurazione non deve trovarsi nella radice del documento e, se non si trova nella radice del documento, non sono necessarie regole di riscrittura poiché nessuno può accedervi comunque.

  

Il formato INI è specializzato per fornire sia la possibilità di avere una gerarchia di chiavi dei dati di configurazione sia l'ereditarietà tra le sezioni dei dati di configurazione. Le gerarchie dei dati di configurazione sono supportate separando le chiavi con il carattere punto o punto (.). Una sezione può estendersi o ereditare da un'altra sezione seguendo il nome della sezione con i due punti (:) e il nome della sezione da cui i dati devono essere ereditati.

Dalla Zend_Config_Ini .

Zend Framework lo utilizza per consentire di disporre di più parametri di configurazione, uno per la gestione temporanea, uno per lo sviluppo e uno per la produzione. Ciò consente anche di impostare facilmente le impostazioni del database per la produzione e per lo sviluppo e con due impostazioni molto diverse. Diversi percorsi impostati nel file ini in cui si trovano le inclusioni. Ciò rende molto più semplice spostare il codice dallo sviluppo alla produzione sapendo che immediatamente tutto ciò che è sviluppo verrà disattivato.

Certo, questo sarebbe possibile con uno script PHP, ma richiederebbe più analisi delle varie variabili di configurazione, oltre a fare if / then checks, mentre l'uso di parse_ini_file () fa tutto questo automaticamente per te.

Le altre risposte hanno già sottolineato che i non programmatori potrebbero dover cambiare le variabili e / o qualcosa sul sito Web impostato come variabile di configurazione (ad esempio, il titolo del sito utilizzato nel layout dei siti). I file INI sono facili da capire e leggere anche per qualcuno che non ha mai programmato prima.

Esempio da un sito Web su cui sto attualmente lavorando:

[production]
phpSettings.display_startup_errors = 0
phpSettings.display_errors = 0
includePaths.library = APPLICATION_PATH "/../library"
bootstrap.path = APPLICATION_PATH "/Bootstrap.php"
bootstrap.class = "Bootstrap"
resources.frontController.controllerDirectory = APPLICATION_PATH "/controllers"
resources.layout.layoutPath = APPLICATION_PATH "/layouts/scripts"
resources.db.adapter       = "PDO_SQLITE"
resources.db.params.dbname = APPLICATION_PATH "/../data/db/users.db"

resources.view[] =

[staging : production]

[testing : production]
phpSettings.display_startup_errors = 1
phpSettings.display_errors = 1
resources.db.params.dbname = APPLICATION_PATH "/../data/db/users-testing.db"

[development : production]
phpSettings.display_startup_errors = 1
phpSettings.display_errors = 1
resources.db.params.dbname = APPLICATION_PATH "/../data/db/users-dev.db

Rende estremamente facile avere più set di dati per i vari ambienti in cui è possibile eseguire il codice.

Answer 2

Per coloro che vengono a questa domanda perché vogliono sapere se ci sono differenze di prestazioni tra l'uso di un file INI che deve essere analizzato e un file PHP che è semplicemente incluso (e può essere memorizzato nella cache da PHP): Sì, lì sono differenze ma sono così piccole che non importa davvero.

Il mio scenario di riferimento è un file config.ini con 20 coppie chiave / valore e un file config.php con le stesse 20 coppie chiave / valore scritte come definite. La versione di PHP è 5.4.9 su Ubuntu Linux 13.04.

key1 = value1
...
key20 = value20

vs.

<?php
define("key1", "value1");
...
define("key2", "value20");

Due script di test inclusi i config:

<?php
$CONF = parse_ini_file("config.ini");

vs.

<?php
require_once "config.php";

Ho testato le prestazioni con ab -c 25 -n 10000.

Risultato senza cache PHP:

ini: Requests per second:    2660.89 [#/sec] (mean)
php: Requests per second:    2642.28 [#/sec] (mean)

Risultato con cache PHP APC:

ini: Requests per second:    3294.47 [#/sec] (mean)
php: Requests per second:    3307.89 [#/sec] (mean)

Ho eseguito i test più volte, naturalmente i numeri varieranno ogni volta ma il consenso è: <=> è un po 'più veloce quando non viene utilizzata alcuna cache PHP, <=> è un po' più veloce quando una cache PHP è Usato. Ma la differenza è così piccola che la decisione non dovrebbe essere basata sulle prestazioni.

Answer 3

La tua domanda solleva un punto giusto, certo.

Alcuni punti a favore di .ini file:

• Usa il file con un'altra lingua . Se hai mai desiderato che uno script Perl, Python, Ruby, ecc. Facesse qualcosa di particolarmente facile con quella lingua e che fosse necessario per accedere alle impostazioni del progetto, saresti sfortunato se memorizzassi le tue impostazioni in un file PHP.

• Modifica umana dei dati . Anche se lo hai respinto nella tua domanda, le intenzioni o no è molto probabile che qualcuno finisca per colpire lì e potrebbe non essere un individuo tecnico. Il formato INI è molto meno spaventoso del codice PHP, anche se è solo un mucchio di dichiarazioni variabili

• Aggiornamento delle impostazioni . Penso che sia molto più semplice creare un nuovo file INI piuttosto che scrivere un file PHP. Questo è piuttosto soggettivo, tuttavia, ma vale la pena menzionarlo.

• Relazione tra le variabili di impostazione . È abbastanza semplice / intuitivo assegnare una gerarchia alle impostazioni con un file INI. Anche se questo sarebbe possibile con PHP, non è così pulito e può diventare sgradevole se stai cercando di creare array associativi profondamente annidati per archiviare informazioni.

Oltre a questi, il knock-in INI di " doverlo proteggere dall'accesso web " non è rilevante nella maggior parte degli scenari poiché la maggior parte dei progetti PHP (almeno quelli di cui faccio parte) tengono una buona quantità di codice lontano dalla cartella principale e le impostazioni di solito vanno lì.

Answer 4

Beh, potrebbe essere più facile per un non programmatore modificare le variabili di configurazione ... Se è necessario sul posto di lavoro.

Ho scoperto che un posizionamento accurato di <?php e ?> può impedirne la visualizzazione, mentre parse_ini_file () otterrà comunque i dati rilevanti dal file.

Il modo migliore per proteggerlo, però, è posizionarlo sopra il docroot e negare l'accesso a * .ini nella configurazione del server.