NYCPHP Meetup

[Kristina D. H. Anderson]

Hi, sorry if this was covered anywhere previously in this thread, but 
I've found it useful, in addition to enabling the full error reporting 
that's built into PHP, to also add customized error_log calls anywhere 
where you have such things as database inserts/updates, web service 
request/response or other behind-the-scenes text generation or 
processing, or any other areas of the application which you feel are 
extremely performance intensive, bug-prone or hard to monitor using 
more generic error messages.

Set it up so that you can toggle this function on/off in one place 
before turnover to production, so that you can leave in all your calls 
to error_log for future use.

Your error_log file on the server will quickly grow to enormous 
proportions, but since it's only a test server, it won't be a worry!  
By doing this you can build a history of the application's behavior and 
performance and verify that everything is exactly as it should be.

Right now I'm working with the Paypal IPN code and I'm finding that 
it's quite a creative experience to figure out what, in any particular 
instance, is the highest level of valuable information you can wreak 
out of some code by dint of the old error_log function...I'd love to 
see some error handling examples from people on this list which are 
undoubtedly leaps and bounds above what I've got going on here...!!

Kristina

> Ajai Khattri wrote:
> >> Do any of you have recommendations on configuration settings to 
use?
> > 
> > Most of these packages come with pretty sensible config settings so 
I 
> > probably would *not* mess with them without knowing the 
consequences.
> 
> Duly noted.
> 
> >> Which packages/extensions/modules should be installed/enabled?
> > 
> > That kind of depends on what software you're writing dont you 
think? 
> 
> Ah, right--thinking. Sometimes I forget to do that. Yes, that would 
be a
> sensible thing to consider. :-)
> 
> >Some 
> > frameworks will need additional extensions and tweaks to Apache so 
there 
> > is no simple fits-all rule. The other thing to consider is that any 
> > changes you make should be easy to maintain and put back after a 
software 
> > update. (In the case of Apache I tend to leave the main config 
alone since 
> > any changes will likely be overwritten when the software is 
updated). IIRC 
> > Ubuntu has something like a sites-enabled/sites-available folder 
where you 
> > can put vhost files (one per vhost is good practice). I usually 
create a 
> > file called ALL that contains any global config tweaks.
> > 
> >> Should I go ahead and turn off error reporting and enable it via my
> >> scripts, or should I leave it on all the time? If I should leave 
it on,
> >> at what level should I set it? E_ALL?
> > 
> > If you're using a framework it might already do all that for you 
and maybe 
> > provide its own config file for you to tweak that in.
> 
> I'll look into all that, thanks.
> 
> > Firebug is good on the browser side (also look at the Web Developer 
> > Toolbar and the YSlow extension for Firebug). On the server side 
look at 
> > FirePHP and Xdebug extensions for PHP.
> > 
> 
> Firebug, YSlow, and the Web Developer Toolbar have been my best 
friends
> for front-end work for quite some time. I've seen the FirePHP & Xdebug
> extensions but didn't really understand how to use them, so I just
> ignored them. Now that you've mentioned them I'll go back and give 
them
> a closer look.
> 
> > All developers should be using version control. Subversion is very 
popular 
> > but Git is also becoming so these days.
> 
> Understood.
> 
> Bev
> 
> 
> _______________________________________________
> New York PHP User Group Community Talk Mailing List
> http://lists.nyphp.org/mailman/listinfo/talk
> 
> http://www.nyphp.org/show_participation.php
> 
>