[wp-trac] Re: [WordPress Trac] #3155: Several "notice" messages in WP 2.1-alpha3

[WordPress Trac]

#3155: Several "notice" messages in WP 2.1-alpha3
-------------------------+--------------------------------------------------
 Reporter:  quix0r       |        Owner:  anonymous
     Type:  enhancement  |       Status:  new      
 Priority:  normal       |    Milestone:  2.1      
Component:  General      |      Version:  2.1      
 Severity:  major        |   Resolution:           
 Keywords:               |  
-------------------------+--------------------------------------------------
Comment (by ringmaster):

 There is a lot of prior work dealing with WordPress and caches, and some
 decisions had been made to offload some of those demands onto server
 software that is more dedicated to the task.

 For instance, qcache is going to do a much better job at handling caching
 than interpreted PHP.  Using APC will enhance your execution performance
 to the point that leaving wptexturize() et. al. uncached will produce
 insignificant impact.

 There is a built-in object cache in WP that is disabled by default because
 it seems that only certain sites benefit from the enhancements under
 particular circumstances.  In some cases the cache actually slows down
 execution when it's not badly needed.

 It might be handy to remove the PHP errors that appear in E_ALL mode, but
 are these changes really critical?  I would also take care that you're not
 harming intended functionality.

 For example, there's a slew of:

  if(!isset($q['p'])) $q['p'] = '';

 ...to integrate into the query engine.  Some of the later code may require
 that the value is unset.  By setting it, you may affect code farther down
 in the execution path.

 Making grand changes to working code for the sake of removing notices (not
 errors or even warnings) from the code in the most extreme reporting
 setting is unwise without significant code review to make sure things are
 still working as expected.

 Looking at your sample, I notice that you're using the value of an unset
 variable inside the loop.  That may delay the loop execution, but I doubt
 you'll see any section of WordPress code that repeatedly accesses an unset
 variable in this way.  Perhaps if there was an obvious instance of this
 and you focused your patch on addressing that individual concern, it would
 be easier to recommend for commit.  As is, this patch is too broad.

-- 
Ticket URL: <http://trac.wordpress.org/ticket/3155>
WordPress Trac <http://wordpress.org/>
WordPress blogging software