Home/ Questions/Q 221657
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-05-11T19:03:15+00:00

At work we use a .ini file to set variables prior to calling the

  • 0

At work we use a .ini file to set variables prior to calling the rest of the framework (I think it goes

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

and I have always wondered if there was a benefit to doing it that way.

It seems to me that you then have to write access rules to stop people from looking at it from the web and php has to parse it and understand it.

So, why use my_config.ini rather than my_config.php? It is not like anyone should be touching it after it is set up and it seems more convenient to just call the variables and be able to have your IDE auto complete the text wherever you are using the ini variables / parse it for errors.

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    The Zend Framework contains a config parses that parses files that are written in the ini format (Zend_Config_Ini), it sounds like this is what you are using.

    The config file should not be located in your document root, and if it is not in your document root then no re-write rules are required since no-one can access it anyway.

    The INI format is specialized to provide both the ability to have a hierarchy of configuration data keys and inheritance between configuration data sections. Configuration data hierarchies are supported by separating the keys with the dot or period character (.). A section may extend or inherit from another section by following the section name with a colon character (:) and the name of the section from which data are to be inherited.

    From Zend_Config_Ini page.

    The Zend Framework uses it to allow you to have multiple configuration parameters, one for staging, one for development and one for production. This also allows for easy setting database settings for production, and for development and having two very different settings. Different paths set up in the ini file to where includes are located. This makes it much easier to move code from development to production knowing that immediately everything that is development will be turned off.

    Sure, this would be possible with a PHP script, but it would require more parsing of the various configuration variables as well as doing if/then checks, whereas using the parse_ini_file() does all of this for you automatically.

    The other answers also already pointed out that non-programmers may need to change variables and or something on the website that is set as a configuration variable (for example, site title that is used in the sites layout). INI files are easy to understand and read even for someone that has never programmed before.

    Example from a website I am currently working on:

    [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

    It makes it extremely easy to have multiple data sets for the various environments in which the code can be run.

    • 0