> No, display_errors should be turned off (with log_errors turned on)
> and error_reporting should be set to whatever standard you're coding
> to (preferably, E_ALL | E_STRICT, but a lot of people like to ignore
> E_NOTICE's).
yep, it should be a production environment
> So it's not zero configuration, then?
it is, described in the Security page inside the wiki, zero config means no extensions, no code to change except a single require ... we can call it zero config compared with everything else, specially something to compile or able to change the env as your solution does
> And I wasn't
> aware that a 1:1 development:production environment was a desirable
> thing.
sure, PHP 4 on production and 5 as dev then is desiderable, right?
What about specific PHP version, extensions, and other specific env problems/bugs?
I hope you are not following errors that could appear only because of your plugns/extensions ... that would be a massive waste of time, isn't it?
> Things like xdebug, display_errors, inclued, etc. should be
> disabled for production and enabled for development.
1:1 is about what is running and where it is running ... you have an extension which is not official and which could cause false positives or could have other problems. I prefer same extensions in both dev/prod environments in order to be sure behaviors will be the same, got it?
> Run "tail -f /path/to/your/php/error.log" and watch the error logs as
> they're appended, if you need instant error notification.
on windows dev env? and with at least two monitors to maintain a decent application size for client side testings? checking both logs and errors without a red line easily "surfable" with entire stack rather than pure text to analyze? I prefer Formaldehyde here
> Honestly, I'm sure it sounds like this by now but I'm not trying to
> trash your application, but you've not done a very good job selling
> it. It looks like you took some keywords ("ajax", "zero
> configuration", "portable", etc. etc.) and tried to apply them to your
> project, without actually seriously describing what your project is.
did you describe xdebug? I had a read, I got what it is, and I am replying ...
> As best I can tell, your project doesn't do much other than facilitate
> php debugging with Firebug, which is a very niche thing to do and any
> development cycle that I've been a part of has had no need to do such
> things, so I'm still failing to see Formaldahyde's usefulness.
'cause you have tail habit ... I do exactly what you do except I spot it quicker and I can isntantly red Errors expanding and contracting stack traces without any extra effort. This is the difference.
If you think Formaldehyde is useless, I can say your way is useless as well, since the purpose is the same, the way logs/errors are showed is different.
You had no choice before, and you'll probably never go for Formaldehyde, but you kinda confirmed there was nithing similar before, and I can tell you I am using it and I will do, so this project is not going to die soon, that is for sure, as xdebug will hopefully be maintained (as FirePHP or others)
I call them alternatives, and I am an open minded person, I'll give xdebug a try indeed, maybe I can integrate some feature.
Of course every of us developed Ajax application 'till now, does it mean the debug process is death as is? Can we try to improve it somehow? That is what I have done but everybody is free to choose his way, this is just a new one, and you already said why (facilitate php debugging).
The fact you had no need is also because you had not this option, now you do.
Regards
P.S. Firebug is just one of compatible consoles, the best so far though, but not because Formaldehyde is for Firebug, client side does not matter, it will work with IE as well for those behind "legacy companies" (me right now, as example)
_________________________________________________________________
Drag n’ drop—Get easy photo sharing with Windows Live™ Photos.
http://www.microsoft.com/windows/windowslive/products/photos.aspx
