# Safety of globalizing config data

I have some framework in PHP/MySQL for developing web services. Finally my code works on two servers - production and developer. My idea is to create one code without differences, which will work different on both servers, depend of config. I created table [ini], with two rows of data, where I can specifically change settings of many parameters like:

• IDs of advertising banners to display on some pages,
• page name to redirect after successful logging,
• ID of default role of new user
• etc.

I can of course prepare a class for read one specify setting when it is necessary, but it means that I will read data from my [ini] table dozen times in many PHP files.

Is it safe to read it once and globalize by following code?

//on developer machine my INI_ID == 0, on production server INI_ID == 1
if($_SERVER['SERVER_NAME'] == 'www.developer_domain_name.com'){ define('INI_ID',0); } else{ define('INI_ID',1); }$row = function_SQLToRow('SELECT * FROM ini WHERE ini_id = ' . INI_ID . '');
$GLOBALS['ini'] =$row;


I'm open for other solutions, maybe storing config in file and read specific file depend on server, or prepare list of constants depend on server are safer solutions?

$config = json_decode(file_get_contents('config.json')); //I'm assuming JSON here  Also, please don't globalize configuration. Pass whichever config option you need (just that config option, not the whole configuration array) into whatever function/object that needs it. • Actually, the [ini] table is part of data, it means the parameters in the table are available to edit for administrator (I'm a developer, not administrator in the case). For example, in this solution the administrator can change email or prepare advertising banner in wysiwyg editor and change the global config of banner displaying without me. Nov 16 '14 at 22:39 I concur with @MadaraUchiha: this is bad practice. You should have greater segregation between your development and production environments than just a 0/1 selector in a table. Ideally, you should have separate development and production databases, with different passwords, so that: • You can confidently develop code without worrying about accidentally corrupting your production data. • You can reinitialize the development database to a known good state in case you trash the data. • You can test schema changes before deploying to production. • If you store private information in the production database, you don't have to expose it to developers. Instead of switching between 0/1 rows in the ini table, define different database connection parameters for the development and production environments. I would also advise against defaulting to the production environment, as it would be easy to accidentally point to it while setting up a new development sandbox. • Of course I have separated code and database for both servers. The idea is keeping one code for both servers. I have defined db and host in the same way like$GLOBALS in question, which allowed me to do not worry about a differences. However, your answer point out me, that if a hacker explore a client server, then he will find the credentials for my developer database. About the question: finally I think that I will change solution from \$GLOBALS into an array which will include only on pages when it is necessary. Nov 17 '14 at 20:16