Handling config in large PHP projects?
When making a website, I have always just had a single config.php file with a bunch of constants in it, and I include it at the top of every PHP file:
1. config.php
// config.php
$hostname = get_user();
define("HOME", "/home/$hostname/my/website");
define("DB_USER", 'username');
define("DB_PASS", 'password');
This is easy enough and I've never had a problem with it. But is this the standard way to handle config in a big PHP website?
I thought it might be better to contain all the config in a class, like this:
2. Config class
class Config {
public $home;
const DB_USER = 'username';
const DB_PASS = 'password';
function __construct() {
$hostname = get_current_user();
$this->home = "/home/$hostname/my/website";
}
}
But this seems to make the config more complex, because:
- Instead of just needing to include the file, I now also need to instantiate a Config object first.
- I need to use a mix of properties and class constants, because some parts of the config are set dynamically.
- The overall code just isn't quite as simple.
Summary.
I realize the class provides namespacing, but is there anything much more beneficial about putting config in to a class like this?
In short, is it still perfectly fine these days to stick to a classic config.php file, or are there reasons why I look toward using a more OOP approach to configuration?
EDIT:
I also found this answer very helpful: https://codereview.stackexchange.com/questions/79528/standard-and-common-config-file-for-core-php-project?newreg=eb97ce022c9f4e8a98a1e2d3547b767a
php configuration configuration-files
asked Nov 22 '18 at 17:31
inershainersha
200213
add a comment |
When making a website, I have always just had a single config.php file with a bunch of constants in it, and I include it at the top of every PHP file:
1. config.php
// config.php
$hostname = get_user();
define("HOME", "/home/$hostname/my/website");
define("DB_USER", 'username');
define("DB_PASS", 'password');
This is easy enough and I've never had a problem with it. But is this the standard way to handle config in a big PHP website?
I thought it might be better to contain all the config in a class, like this:
2. Config class
class Config {
public $home;
const DB_USER = 'username';
const DB_PASS = 'password';
function __construct() {
$hostname = get_current_user();
$this->home = "/home/$hostname/my/website";
}
}
But this seems to make the config more complex, because:
- Instead of just needing to include the file, I now also need to instantiate a Config object first.
- I need to use a mix of properties and class constants, because some parts of the config are set dynamically.
- The overall code just isn't quite as simple.
Summary.
I realize the class provides namespacing, but is there anything much more beneficial about putting config in to a class like this?
In short, is it still perfectly fine these days to stick to a classic config.php file, or are there reasons why I look toward using a more OOP approach to configuration?
EDIT:
I also found this answer very helpful: https://codereview.stackexchange.com/questions/79528/standard-and-common-config-file-for-core-php-project?newreg=eb97ce022c9f4e8a98a1e2d3547b767a
php configuration configuration-files
asked Nov 22 '18 at 17:31
inershainersha
200213
Config files should be just that. Files. Nothing sucks more than trying to automate deployment of a config file that's in an indeterminate format and contains executable logic. Pick something like INI, JSON, YAML, etc, and have your config class do nothing but parse the config file.
– Sammitch
Nov 22 '18 at 17:39
@Sammitch Thanks, I hadn't considered using a simpler JSON or JSON file for config stuff and parsing it using code from there.
– inersha
Nov 22 '18 at 21:35
add a comment |
When making a website, I have always just had a single config.php file with a bunch of constants in it, and I include it at the top of every PHP file:
1. config.php
// config.php
$hostname = get_user();
define("HOME", "/home/$hostname/my/website");
define("DB_USER", 'username');
define("DB_PASS", 'password');
This is easy enough and I've never had a problem with it. But is this the standard way to handle config in a big PHP website?
I thought it might be better to contain all the config in a class, like this:
2. Config class
class Config {
public $home;
const DB_USER = 'username';
const DB_PASS = 'password';
function __construct() {
$hostname = get_current_user();
$this->home = "/home/$hostname/my/website";
}
}
But this seems to make the config more complex, because:
- Instead of just needing to include the file, I now also need to instantiate a Config object first.
- I need to use a mix of properties and class constants, because some parts of the config are set dynamically.
- The overall code just isn't quite as simple.
Summary.
I realize the class provides namespacing, but is there anything much more beneficial about putting config in to a class like this?
In short, is it still perfectly fine these days to stick to a classic config.php file, or are there reasons why I look toward using a more OOP approach to configuration?
EDIT:
I also found this answer very helpful: https://codereview.stackexchange.com/questions/79528/standard-and-common-config-file-for-core-php-project?newreg=eb97ce022c9f4e8a98a1e2d3547b767a
php configuration configuration-files
asked Nov 22 '18 at 17:31
inershainersha
200213
When making a website, I have always just had a single config.php file with a bunch of constants in it, and I include it at the top of every PHP file:
1. config.php
// config.php
$hostname = get_user();
define("HOME", "/home/$hostname/my/website");
define("DB_USER", 'username');
define("DB_PASS", 'password');
This is easy enough and I've never had a problem with it. But is this the standard way to handle config in a big PHP website?
I thought it might be better to contain all the config in a class, like this:
2. Config class
class Config {
public $home;
const DB_USER = 'username';
const DB_PASS = 'password';
function __construct() {
$hostname = get_current_user();
$this->home = "/home/$hostname/my/website";
}
}
But this seems to make the config more complex, because:
- Instead of just needing to include the file, I now also need to instantiate a Config object first.
- I need to use a mix of properties and class constants, because some parts of the config are set dynamically.
- The overall code just isn't quite as simple.
Summary.
I realize the class provides namespacing, but is there anything much more beneficial about putting config in to a class like this?
In short, is it still perfectly fine these days to stick to a classic config.php file, or are there reasons why I look toward using a more OOP approach to configuration?
EDIT:
I also found this answer very helpful: https://codereview.stackexchange.com/questions/79528/standard-and-common-config-file-for-core-php-project?newreg=eb97ce022c9f4e8a98a1e2d3547b767a
php configuration configuration-files
php configuration configuration-files
asked Nov 22 '18 at 17:31
inershainersha
200213
asked Nov 22 '18 at 17:31
inershainersha
200213
edited Nov 22 '18 at 21:41
inersha
asked Nov 22 '18 at 17:31
inershainersha
200213
asked Nov 22 '18 at 17:31
inershainersha
200213
asked Nov 22 '18 at 17:31
inershainersha
200213
200213
Config files should be just that. Files. Nothing sucks more than trying to automate deployment of a config file that's in an indeterminate format and contains executable logic. Pick something like INI, JSON, YAML, etc, and have your config class do nothing but parse the config file.
– Sammitch
Nov 22 '18 at 17:39
@Sammitch Thanks, I hadn't considered using a simpler JSON or JSON file for config stuff and parsing it using code from there.
– inersha
Nov 22 '18 at 21:35
add a comment |
Config files should be just that. Files. Nothing sucks more than trying to automate deployment of a config file that's in an indeterminate format and contains executable logic. Pick something like INI, JSON, YAML, etc, and have your config class do nothing but parse the config file.
– Sammitch
Nov 22 '18 at 17:39
@Sammitch Thanks, I hadn't considered using a simpler JSON or JSON file for config stuff and parsing it using code from there.
– inersha
Nov 22 '18 at 21:35
Config files should be just that. Files. Nothing sucks more than trying to automate deployment of a config file that's in an indeterminate format and contains executable logic. Pick something like INI, JSON, YAML, etc, and have your config class do nothing but parse the config file.
– Sammitch
Nov 22 '18 at 17:39
Config files should be just that. Files. Nothing sucks more than trying to automate deployment of a config file that's in an indeterminate format and contains executable logic. Pick something like INI, JSON, YAML, etc, and have your config class do nothing but parse the config file.
– Sammitch
Nov 22 '18 at 17:39
@Sammitch Thanks, I hadn't considered using a simpler JSON or JSON file for config stuff and parsing it using code from there.
– inersha
Nov 22 '18 at 21:35
@Sammitch Thanks, I hadn't considered using a simpler JSON or JSON file for config stuff and parsing it using code from there.
– inersha
Nov 22 '18 at 21:35
add a comment |
1 Answer
1
active
oldest
votes
It's fine to use site wide config files. You would typically use a config class for library-specific configs so that a library only strictly accepts well defined config objects as its dependency instead of arrays. As a bonus, you get the added benefit of type hinting the config parameters.
answered Nov 22 '18 at 17:42
IMBIMB
4,340124389
add a comment |
Your Answer
StackExchange.ifUsing("editor", function () {
StackExchange.using("externalEditor", function () {
StackExchange.using("snippets", function () {
StackExchange.snippets.init();
});
});
}, "code-snippets");
StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "1"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});
function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: true,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: 10,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});
}
});
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53435894%2fhandling-config-in-large-php-projects%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
1 Answer
1
active
oldest
votes
1 Answer
1
active
oldest
votes
active
oldest
votes
active
oldest
votes
It's fine to use site wide config files. You would typically use a config class for library-specific configs so that a library only strictly accepts well defined config objects as its dependency instead of arrays. As a bonus, you get the added benefit of type hinting the config parameters.
answered Nov 22 '18 at 17:42
IMBIMB
4,340124389
add a comment |
It's fine to use site wide config files. You would typically use a config class for library-specific configs so that a library only strictly accepts well defined config objects as its dependency instead of arrays. As a bonus, you get the added benefit of type hinting the config parameters.
answered Nov 22 '18 at 17:42
IMBIMB
4,340124389
add a comment |
It's fine to use site wide config files. You would typically use a config class for library-specific configs so that a library only strictly accepts well defined config objects as its dependency instead of arrays. As a bonus, you get the added benefit of type hinting the config parameters.
answered Nov 22 '18 at 17:42
IMBIMB
4,340124389
It's fine to use site wide config files. You would typically use a config class for library-specific configs so that a library only strictly accepts well defined config objects as its dependency instead of arrays. As a bonus, you get the added benefit of type hinting the config parameters.
answered Nov 22 '18 at 17:42
IMBIMB
4,340124389
answered Nov 22 '18 at 17:42
IMBIMB
4,340124389
answered Nov 22 '18 at 17:42
IMBIMB
4,340124389
answered Nov 22 '18 at 17:42
IMBIMB
4,340124389
4,340124389
add a comment |
add a comment |
Thanks for contributing an answer to Stack Overflow!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53435894%2fhandling-config-in-large-php-projects%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Config files should be just that. Files. Nothing sucks more than trying to automate deployment of a config file that's in an indeterminate format and contains executable logic. Pick something like INI, JSON, YAML, etc, and have your config class do nothing but parse the config file.
– Sammitch
Nov 22 '18 at 17:39
@Sammitch Thanks, I hadn't considered using a simpler JSON or JSON file for config stuff and parsing it using code from there.
– inersha
Nov 22 '18 at 21:35