1

I am writing this CMS, and I'd like to know if there's any disadvantages of adding additional values to the global $_ENV variable.

Example; 

$_ENV['baseURL'] = 'http://www.example.org';

I want to do so, because I want the variable i keep settings to be global automatically. I think it's a good way. Do you agree? if not, why? I'm curious if there's any disadvantages.

Ilyas Serter
  • 640
  • 6
  • 12
  • 3
    The general opinion is that global variables in any way is not a good thing to start with – zerkms Jan 31 '12 at 22:20
  • create your own 'settings' file and included it as needed. –  Jan 31 '12 at 22:25
  • 1
    You can do that. Despite the meme misattributions this seems workable. And `baseURL` might semantically even belong there. However if you add *arbitrary* settings into `$_ENV` (like `backgroundColor` etc), then it becomes a mislabel. You should rather make it shared-scope `$config` array or something. – mario Jan 31 '12 at 23:03
  • 1
    Yeah, the big disadvantage is that it is horribly confusing. If you must make a global, put it in `$GLOBALS`. – Brad Feb 04 '12 at 04:32

2 Answers2

1

The clean way is to set the environment from outside (it's called environment for a reson), for instance from apache:

<VirtualHost *:80>
 <Directory "/srv/http/my/app/public">
     AllowOverride FileInfo
     SetEnv baseURL http://www.example.org
 </Directory>
</VirtualHost>

DO NOT use globals, they're bad. In the beginning, all globals look innocent. Follow the link for the full argumentation.

Never ever write something into $_GET, $_POST, $_ENV, etc, in your program. These superglobal arrays are supposed to contain input, and you never write to the input, you write to the output.

Community
  • 1
  • 1
Flavius
  • 12,501
  • 13
  • 76
  • 118
  • The `$GLOBALS` array is a clear exception that is not limited to system input, it is in fact intended to be written to from userspace. Not advocating using globals in general, but if you are going to `$GLOBALS` is the appropriate place. That is to say __most__ superglobals aren't intended to be written to from Userspace. Another thing to point out is passing variables from the Webserver environment is only useful for variables that aren't going to change on a per-request basis; typically something like APPLICATION_ENV from Zend Framework. – quickshiftin Jun 19 '12 at 23:50
  • You've downvoted it without a reason. You yourself say "Another thing to point out is passing variables from the Webserver environment is only useful for variables that aren't going to change on a per-request basis;" - well, **this is such a case**. So why the downvote? Please follow your own argumentation and vote accordingly ;) – Flavius Jun 20 '12 at 05:46
  • AND if your globals DO change, then there you have it: spaghetti code, prone to bugs and errors, hard to debug and maintain (follow the link for the full argumentation). **In the beginning, all globals look innocent.** – Flavius Jun 20 '12 at 06:24
0

Use the $GLOBALS array, it's for user defined global variables, that way other programmers won't get confused by these user defined values you wish to store.

Brad
  • 146,404
  • 44
  • 300
  • 476
quickshiftin
  • 55,146
  • 9
  • 56
  • 76
  • Umm, what was the -1 for (to whomever put it there) ?? – quickshiftin Jun 19 '12 at 23:53
  • Another thing to note is the info OP wants in a global variable is already available via `$_SERVER` in some pieces, maybe a global function like `function base_url() { return $_SERVER['HTTPS'] ? 'https://' . $_SERVER['HTTP_HOST'] : 'http://' . $_SERVER['HTTP_HOST']; }` would be best. Another approach for something like this would be a `define` statement, many valid ways to approach this really. – quickshiftin Jun 20 '12 at 00:11