addressalign-toparrow-leftarrow-rightbackbellblockcalendarcameraccwchatcheckchevron-downchevron-leftchevron-rightchevron-small-downchevron-small-leftchevron-small-rightchevron-small-upchevron-upcircle-with-checkcircle-with-crosscircle-with-pluscrosseditemptyheartfacebookfolderfullheartglobegmailgoogleimagesinstagramlinklocation-pinmagnifying-glassmailminusmoremuplabelShape 3 + Rectangle 1outlookpersonplusprice-ribbonImported LayersImported LayersImported Layersshieldstartickettrashtriangle-downtriangle-uptwitteruseryahoo

PHP as a Social Activity Message Board Project Support › PHP Application Config

PHP Application Config

Closed to new replies

A former member
Post #: 2
What are some preferred methods for config files in php? Naturally I want to store commonly used data for my apps such as: database settings (host, user, password, database to use), SMTP settings, app name, version, etc.

I'm seeking ideas that are easy to use and secure. I've seen examples with ini files, xml files, and database records. Does anyone have a preferred method or could someone share some experiences about why one or more mentioned config types aren't the way to go?
Sam L.
samuelelliot
Group Organizer
Saint Petersburg, FL
Post #: 25
Jeff,

What you will see if you traverse the code on other popular projects, is that config files are usually .php files that directly inject the data into the code. This is done by setting constants, setting variables, or passing data directly to a function. All three of these are common, and show marked performance over other external files, this is due to the fact that other formats require the data to be converted to php. In some cases, this would be fine, if the code you are using to convert is used for more than just init. The problem is size, speed, and complexity; the simpler you make it, the easier it will be for everything else. Below are a few examples of suggested code.

== CONSTANTS ==
define('DBASE_DSN','mysql://username:pas­sword@host/database');

== VARIABLES ==
$dbaseDsn = 'mysql://username:password@host/database­';

== FUNCTION ==
#Static Class method
config::set('dbase_dsn', 'mysql://username:password@host/database­');

#Procedural Function
config_set('dbase_dsn', 'mysql://username:password@host/database­');


I hope this is helpful,

Sam
A former member
Post #: 3
I'm not worried about performance because honestly there should not be a performance issue with reading a text file less than a hundred lines. It's an app config, I'm not worried about size, speed, and complexity :) I mostly want something flexible and secure considering I will have database passwords stored in it.

Maybe I'll make a config class with a constructor that loads an ini file and then parses it out into variables. Does php have a dictionary collection? That could be good too because I could access values by key. If not maybe I'll just write a static method that you pass the key value into to retrieve it. Thanks for the advice.
Phillip
philsown
Raleigh, NC
Post #: 30
I personally prefer to use constants. Several of my projects use a framework I have developed which is in source control. In the repository there is a config-sample.php file. When I start a new project, I copy this to config.php and immediately ignore the file. This way I can manage the app in several places with potentially different paths, db settings, etc.

PHP Reads ini files & strings out of the box:
http://us2.php.net/ma...­
http://us2.php.net/ma...­
Sam L.
samuelelliot
Group Organizer
Saint Petersburg, FL
Post #: 26
Phill,

What do you mean by "I copy this to config.php and immediately ignore the file." How do you ignore it, and if your ignoring it why have it at all?

Sam :)
Phillip
philsown
Raleigh, NC
Post #: 31
I was speaking in regards to the subversion/svn/repository status of the file.

For the code question - I simply use constants, in their own file, in a file that is specific to the server/environment I'm on.

define('URL_SITE', 'http://newproject.local/');
// and so on...

Then in the bootstrap or index or wherever...
include('config/config.php');



Back to the SVN confusion I introduced...

I usually work from at least 2 servers, local (development) and production. Sometimes a staging server in between. The repository has config-sample.php committed to it, but this file is merely a template.

When I set up the various environments, I copy config-sample.php into config.php, which is the file that gets used.

I ignore the config.php file in SVN so that when I commit changes and push them to the other servers, the config.php files on those servers are not overwritten.

1) export a clean app setup from my generic 'framework' repo - the config-sample.php is here
$ cd ~/web/dev
$ mkdir newproject
$ cd newproject
$ svn export http://svn.myserver.c...­ website
# website folder is created

2) import that code into the specific project repo
$ svn import website http://svn.myserver.c...­
# website folder's contents are imported into trunk

3) remove the website dir and check it out again so it's a working copy
$ rm -fr website
$ svn co http://svn.myserver.c...­ website

4) make a specific config.php file for the environment
$ cd website/config
$ cp config-sample.php config.php
# edit the config file here...

5) ignore the config file.
$ svn st
# config.php shows up as an un-committed file.

$ svn propset svn:ignore "config.php" .
$ svn up
$ svn st
# config.php will not show up now

$ svn commit -m "ignoring the specific config file"

(at this point you could svn rm config-sample.php from the 'new project' repository).

When I set up the stage or production servers, I simply have to do step 4 above.

The differences in code are only the specifics...

// config-sample.php

define('URL_SITE', 'your site');
define('DB_HOST', 'your host');
define('DB_USER', 'your user');
// etc ...


// config.php - on my local machine

define('URL_SITE', 'http://newproject.local/');
define('DB_HOST', 'localhost');
define('DB_PORT', '3066');
define('DB_USER', 'webdb_user');
// etc...

// config.php - on the production server

define('URL_SITE', 'http://www.new-internet-darling.com/');­
define('DB_HOST', 'db.theserver.com');
// crazy obscure port paranoid db admin set up
define('DB_PORT', '58294');
define('DB_USER', 'long_webdb_username_someone_came_up_wit­h');
// etc...

So - that was kind of a tangent from the question, sorry.
A former member
Post #: 4
That's why I'm wanting to setup a config, for environment settings (dev, qa, production, etc.) I wrote a lightweight framework and wanted to incorporate configuration. Php isn't my first language and because my background in other languages I tend to think in OO (maybe more than the average bear).

I'm writing a config class with static functions to retrieve key/values and for more common config elements that usually have more than one setting (i.e. database, smtp) I'm writing functions that return config objects (i.e. DatabaseConfig, SmtpConfig objects). This is somewhat attractive because it's easy to retrieve database config objects by requesting them by database name from the Config class and since I'm using an IDE, the IDE knows what properties/functions my classes have and will help auto complete config properties to speed up development.

I really would have used a common php framework but I'm not making sites for clients and need to turn out applications quickly. My php apps are side projects and I'd rather have control over the granularity while still being able to pump out code in my applications a little quicker with the help of a framework. Code reuse is a beautiful thing.

Thanks for the tips guys. When I'm finished with my config class I might post it here as a peer review sort of thing. I'm sure the group could provide more guidance if I could have done something easier in my code.
A former member
Post #: 5
Alright I was thinking into the config implementation too much. I'm used to deal with compiled applications that use text files as configs and I found out that php's static is not so static. I ended up with using constants and my IDE even supports code completion for my constants in included files, so I'm happy :)
Powered by mvnForum

Our Sponsors

People in this
Meetup are also in:

Sign up

Meetup members, Log in

By clicking "Sign up" or "Sign up using Facebook", you confirm that you accept our Terms of Service & Privacy Policy