Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

env variables are strings #229

Merged
merged 1 commit into from
Jan 17, 2016
Merged

env variables are strings #229

merged 1 commit into from
Jan 17, 2016

Conversation

dvorakluk
Copy link
Contributor

In Bash, environment variable is always a string (which is what getenv() returns).
Because of the way this constant is checked in WP:
if ( defined('DISABLE_WP_CRON') && DISABLE_WP_CRON ),
setting DISABLE_WP_CRON=false would resolve to true.
This approach should be more predictable

@@ -63,7 +63,7 @@
* Custom Settings
*/
define('AUTOMATIC_UPDATER_DISABLED', true);
define('DISABLE_WP_CRON', getenv('DISABLE_WP_CRON') ?: false);
define('DISABLE_WP_CRON', getenv('DISABLE_WP_CRON') == "true" ? true : false);
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Could simplify this to:

define('DISABLE_WP_CRON', getenv('DISABLE_WP_CRON') == 'true');

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Of course, I just thought that the longer version is easier to understand.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

swalk's version is easier to understand for me

@swalkinshaw
Copy link
Member

@dvorakluk just had one more minor comment. Would you be able to squash the commits into 1 if possible?

…this constant is checked in WP ( defined('DISABLE_WP_CRON') && DISABLE_WP_CRON ), DISABLE_WP_CRON=false would resolve to true.
@dvorakluk
Copy link
Contributor Author

@swalkinshaw Here you are :)

swalkinshaw added a commit that referenced this pull request Jan 17, 2016
@swalkinshaw swalkinshaw merged commit 985c5ff into roots:master Jan 17, 2016
@swalkinshaw
Copy link
Member

Thanks!

@dvorakluk dvorakluk deleted the env_bool branch January 17, 2016 18:23
@andrewfrankel
Copy link

Noticed something similar recently... but should it be "True" (capital T)? That's how booleans render for me in the .env file.

SOME_VAR="True"

@aaemnnosttv
Copy link
Contributor

@swalkinshaw - Shouldn't boolean environment variables should be set as an integer for this reason?

The if ( defined('CONSTANT') && CONSTANT ) conditional check is used in many places in WordPress.

It's true that defining CONSTANT=false in .env would return a false positive, but defining CONSTANT=0 would be evaluated correctly.

The way it is now, if I would define DISABLE_WP_CRON=1 in my .env, it would evaluate to false because "1" does not equal "true", and for that matter neither does "0".

I suggest reverting this change because I think it is more in line with the conventions followed in other configuration files to use 1 or 0 for boolean values. 1 and 0 are also going to be interpreted correctly by both WP and bash. Also, as @andrewfrankel pointed out, 1 and 0 will not be misinterpreted simply because of a case-sensitive difference.

I think it would be better to document the best practice for setting boolean values in the .env file rather than making this check simply for the semantic value.

In summary:

false === (bool) "0"
true  === (bool) "1"
true  === (bool) "false"
true  === (bool) "true"

@dvorakluk
Copy link
Contributor Author

$ VAR=1 php -r "var_dump((bool) getenv('VAR')=="true");"
bool(true)
$ VAR=0 php -r "var_dump((bool) getenv('VAR')=="true");"
bool(false)

Case-sensitivity is another story, good point.

@swalkinshaw
Copy link
Member

Think we're just going to use https://github.com/oscarotero/env and let it take care of this.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants