phpguru.org

I agree with Harald.

i set my devel define (not a variable) in the same file as my DB settings.

btw - what happens if the HTTP_HOST is "phpguru.org" ? in that case, your method says it is not live and it is not dev.

why are there two variables at all? surely this is a boolean event - your site is either live or it is devel.

I agree with the above commenters but would add that you also need to ensure that log_errors=1 and error_log is set to something writable.

While you don't want Joe Public to be able to see errors, developers need be able to for any obscure bugs you miss in local testing.

I'm in agreement with all the fellas above, same code, different server settings.

Yeah, gotta agree with what i said above.

The only use of setting it up in your PHP code is if you don't have access to the PHP config. This happens with many shared hosting packages.

However, .htaccess can often do most of the config you need.

Mike G:
> In his article, Stanislav mentioned some of his
> concerns with security issues between
> local/live servers. Since anyone can change
> their 'Host' header, it's probably best to keep
> your development and production servers
> completely separate from one another.

Yes anyone could change thir Host: header, but what they can't change is what my web server answers to. Not only that I could restrict my dev website to certain IPs addresses. In fact, who's to say that the two web sites (dev/live) are even on the same machine?

> I'm a fan of running Apache locally on top of
> my working copy, then uploading to production
> after I've thoroughly tested it on my end.

I run Windows locally and Linux on my web server. As far as I'm concerned, developing a website on a different OS than what you run on is a big no-no.

> If you have a local HTTP server, you can
> configure the corresponding php.ini to have the
> display errors directive enabled always.

harald:
> i never understood, why people hardcode
> error-level/error-reporting settings in their
> PHP applications. the most easy and most
> flexible way imo is just changing the settings
> in your servers php configuration file.

I really don't see how that's more flexible than doing it your code.

> btw - what happens if the HTTP_HOST is
> "phpguru.org" ? in that case, your method says
> it is not live and it is not dev.

No, my web server wouldn't give you anything, in fact with a normal web browser you wouldn't even get to my server as there's no DNS record for "phpguru.org".

> why are there two variables at all? surely this
> is a boolean event - your site is either live or
> it is devel.

Normally I use three - an intermediate "staging" web site that runs on the same box as live so the only real difference is the Host: header.

Most browsers just assume www. then i guess. Since going to phpguru.org in firefox takes me to www.phpguru.org

> However, .htaccess can often do most of the
> config you need.

But if performance is important, you'd have override files off.

Dougal:
> Most browsers just assume www. then i guess.
> Since going to phpguru.org in firefox takes me
> to www.phpguru.org

"Most"?

You've tried it in one and from that you assume most do the same? They don't. Opera doesn't, MSIE (7) doesn't, in fact the only browser that does that I've got is Firefox.

I said I guessed, not assumed ;)

I've only got FF on this machine so wasn't able to try others.

Richard Heyes:
> harald:
> > i never understood, why people hardcode
> > error-level/error-reporting settings in
> their
> > PHP applications. the most easy and most
> > flexible way imo is just changing the
> settings
> > in your servers php configuration file.
>
> I really don't see how that's more flexible
> than doing it your code.

in my opinion it's _always_ more flexible and less error-prone if you don't have to touch your source code, if you want to change configuration related settings.

you don't need variable/registry pattern or something else. One constant is enough. You can use it anywhere

Richard Heyes:
> No, my web server wouldn't give you anything,
> in fact with a normal web browser you wouldn't
> even get to my server as there's no DNS record
> for "phpguru.org".

Your webserver gives me the web support solutions page for whatever domain I want to type in my address bar. A simple entry in a hosts file can sort that.

For example:

217.160.188.12 phpguru.org

Basically, HTTP_HOST can be manipulated by the user and your code example directly depends on it. Change you if ... else if to and if ... else and default to a 'live' environment.

> Your webserver gives me the web support
> solutions page for whatever domain I want to
> type in my address bar. A simple entry in a
> hosts file can sort that.
>
> For example:
>
> 217.160.188.12 phpguru.org

But you won't get my dev site. Security by obscurity comes in handy...

Hello,

I would assume that you'd want to use $_SERVER['SERVER_NAME'] instead - this is something that could be counted on - not the HOST.

Only because of the ordering of your virtual hosts. All I'm saying is that the code you posted shouldn't be relied on.

Shot in the dark though ...

http://dev.websupportsolutions.co.uk

SQL printed at the bottom

Dave Marshall:
> Only because of the ordering of your virtual
> hosts. All I'm saying is that the code you
> posted shouldn't be relied on.

Perhaps. I've changed the variable in the article. In the past though anything serious I've worked has only had one website per server.

You should give linux a try as dev env.
Believe me, once started, you will never want to go back. Test locally, copy over and all is fine.




Richard Heyes:

> I run Windows locally and Linux on my web
> server. As far as I'm concerned, developing a
> website on a different OS than what you run on
> is a big no-no.
>
> > If you have a local HTTP server, you can
> > configure the corresponding php.ini to have
> the
> > display errors directive enabled always.

Wiesbert Henning:
> You should give linux a try as dev env.
> Believe me, once started, you will never want
> to go back. Test locally, copy over and all is
> fine.

So you don't even test before hand on your "live" box? You really should.

My current solution is to define a 'debug enabled' variable and then override error/exception handling and act upon that setting.

The 'debug enabled' is defined in the application config but can also be overridden by sending a cookie with the request. This allows to display errors even in production when needed by just clicking on a simple bookmarklet.

Here is an example bookmarklet which just sets/unsets a cookie named "MYAPP_DEBUG":

javascript:(function(){var minutes = 60, exp = new Date();document.title = 'MyApp Debug Cookie disabled';if (document.cookie.match(/(^|;)\s*MYAPP_DEBUG=/)) {minutes=-minutes;} else {document.title='MyApp Debug Cookie enabled';}exp.setTime( exp.getTime() + minutes*60*1000 );document.cookie = 'MYAPP_DEBUG=true; expires=' + exp.toGMTString()}() )

If you are on PHP 5.3+, then there is a great facility you can use which sets the error reporting level in the INI file dependent upon the path of the file being executed.

[PATH=/path/to/file/may/be/partial/or/complete]
error_reporting = E_NONE

Unfortunately, it doesn't seem to work on Windows.

[HOST=dev.site.com]
error_reporting = E_ALL

does work though.