PHP configuration file - Best Practice

[Thor]

I always create a central config file that contains all the settings and constants for the particular project and now that I am starting to make some headway I want to ensure I am doing it all according to "best practices"

Right so, assume this is my config file: (just as an example)

define DEBUG, 0

define PRODUCTION, 1 

Database hostname
Database name
Database username
Database passoword

sitetitle
public_email
public_phone

admin_email
admin_phone


app_url
app_email
app_name

Now I use to just store this in a DB and then have a file called config.php which reads data from a DB and then return a array like so:

<?php

return array(
    'host' => 'localhost',
    'username' => 'root',
    'password' => 'fantablikkie34',
);

and then I just did:

<?php
$database = include('config.php');
echo $database['host']; // 'localhost'
?>

However now I have been reading the php manual and been thinking of creating an INI file instead so the idea is:

config.ini (I store this outside the public folder)

[database]
db_name     = database
db_user     = user
db_password = password

and then create config.php

$ini = parse_ini_file('config.ini');

And then throughout my app/website I can just:

echo $ini['db_name'];
echo $ini['db_user'];
echo $ini['db_name'];
echo $ini['app_name'];

Question how do you guys go about creating and storing the config file?

 

[halfmoonforever]

Depends on what you want to configure?

Normally database location / username to access said database and password is stored within the file (or config *file*) and not the database. Because you will get a chicken/egg situation. How does your app connect to your database if it needs to access the database to be able to read it's settings to be able to connect to it....

In any case. You can't fix everything with a hammer. Apply what is needed when it's needed where it's needed using the best practices of that.

How do I store configuration that isn't database connection related? in a table within the database which is read after connecting to it.

 

[Thor]

Depends on what you want to configure?

Normally database location / username to access said database and password is stored within the file (or config *file*) and not the database. Because you will get a chicken/egg situation. How does your app connect to your database if it needs to access the database to be able to read it's settings to be able to connect to it....

In any case. You can't fix everything with a hammer. Apply what is needed when it's needed where it's needed using the best practices of that.

How do I store configuration that isn't database connection related? in a table within the database which is read after connecting to it.

I forgot to add sorry, my initially config is stored in a flat file DB in a protected folder.

 

[_kabal_]

Try to not use define, because you cannot redefine.

"Redefining" is useful because it is very common to have versioned controlled config AND overridden, ignored by source control, environment specific config.

A nicely namespaced ini/properties, yaml, or php key/value array (map) makes this simple to do

Ini/properties style:

database.driver=pdomysq
database.name=my_db

Yaml style

database:
    driver: pdomysql
    name: my_db

Re PRODUCTION and DEBUG. Imo PRODUCTION is not a setting. One of your environments just happens to be production. You can run your production environment with debug enabled.

 

[Waansin]

For our production systems and their secrets, which include values like DB username & passwords, we set environment variables instead of storing those secrets in any file that may accidentally find its way into source control. I wouldn't use this if you host on a shared server.

Laravel does a combination of environment variables and config files. These config files are literally PHP files that return arrays that get managed via a helper function.

For my personal projects I usually just create a config.php file that sets an array that gets included when required.

Have a look at a few open source PHP projects and evaluate how they handle configuration settings. You will probably find that your approach isn't wrong and will probably work well until growth forces you to change it.

 

[Thor]

For our production systems and their secrets, which include values like DB username & passwords, we set environment variables instead of storing those secrets in any file that may accidentally find its way into source control. I wouldn't use this if you host on a shared server.

Laravel does a combination of environment variables and config files. These config files are literally PHP files that return arrays that get managed via a helper function.

For my personal projects I usually just create a config.php file that sets an array that gets included when required.

Have a look at a few open source PHP projects and evaluate how they handle configuration settings. You will probably find that your approach isn't wrong and will probably work well until growth forces you to change it.

Good point ( both environment variables and advise to look how open source projects do it. )

 

[f0Iygu7gXHVM]

Simple config.php storing arrays, variables etcetc with htaccess 404ing any access to it.

 

[Thor]

Simple config.php storing arrays, variables etcetc with htaccess 404ing any access to it.

From a security standpoint what is better:

File in public document with .htaccess 404

Or file stored outside the www directory

 

[f0Iygu7gXHVM]

From a security standpoint what is better:

File in public document with .htaccess 404

Or file stored outside the www directory

Latter, but I'm lazy af(I like the entire project being in one easy to drop folder) and trust htaccess to 404 everything in the directory.