Another question for you. What do you for configuration management? Ini files? PHP Code? Yml? Do you have it as part of your deployment process? Hand-code in production?
And, do you like your configuration management mechanism?
I’m using .ini files, just started a few months ago. Before that my configuration options have been hard coded in PHP code, very bad idea Ini files seems good and nice to work.
Am using ini files now, but have used PHP code, and Spring style xml files, though each have their benefits and failure points.
I usually use PHP code, just a config.php file with a $CONFIG array that has all the configuration, sometimes I use ini files, but now I am starting to use json files. Maybe I will need to do some benchmarking in fetching info, from these 3 methods.
But this are all from my side projects/jobs, I haven’t got the chance to use PHP in a company job or at least in a biiig project.
“Configuration Management” means different things to different people.
To some people it means handling the configuration of your application at run time.
To others it means source control.
To me, configuration management could mean:
* configuration settings of the application (Think appSettings in .NET)
* configuration settings of the web server, or PHP runtime (Eg. register_globals)
* Source control, build management
* Server/network setup and management
I think it definitely worth to use PHP files (in worst case you var_export your ini file in deploying time) if performance counts. PHP files can be easily bytecode cached with APC (or eAccelerator and company) so reading and processing is much quicker.
I usually write class for my config.
ini files for config files, database for website settings that can be changed by the user.
I use xml, due to it’s flexibility to manage it better using eclipse or other xml editors.
ini for hard config (db connections etc), there are some usecases for dynamic config which is stored in db. And there is another thing to config management: deployment of the config. DB stored cofnig is obsiusly shared among all the nodes and the ini file is deployed via separete svn repo and some custom made machinery. So any change to the config (turning on and off bits of cache, some default values like page size for pagination, mail config etc) is supervised and trackable and deployed simultanously on all nodes.
Well, I uses the application.ini file for general configuration but for convenience reason, I use too some plugin resource classes that allow me to have great control over the configuration.
Depends. For small to medium sized projects I use a php array for db settings, and a generic config class for both application and user settings.
The two big projects i’m working with uses a pretty large ini file for app settings, cached in shared memory. User settings in db, cached with memcache.
Creating a config.php file where you set variable or constant values is pretty much the standard for PHP applications. For .NET applications, there’s App.config or Web.config.
Your email address will not be published. Required fields are marked *