[wp-trac] [WordPress Trac] #11698: have_posts should not auto rewind

WordPress Trac wp-trac at lists.automattic.com
Mon Jan 18 20:39:33 UTC 2010


#11698: have_posts should not auto rewind
--------------------------------------+-------------------------------------
 Reporter:  mwillberg                 |        Owner:          
     Type:  defect (bug)              |       Status:  reopened
 Priority:  normal                    |    Milestone:          
Component:  General                   |      Version:          
 Severity:  minor                     |   Resolution:          
 Keywords:  dev-feedback 2nd-opinion  |  
--------------------------------------+-------------------------------------
Changes (by mwillberg):

  * status:  closed => reopened
  * resolution:  invalid =>


Comment:

 More details, I dislike multiquoting...

 The current loop defeats the only usefull thing I could try to make it to
 do:

 {{{
 $tmp=5;
 while (have_posts() && ($tmp > 0)) {
   the_post();
   // output the post and decorate it with blinking lights
   $tmp--;
 }

 // Now we CONTINUE iterating the REST of the loop or naturally SKIP it
 // if the have_posts() routine would work AS IT SHOULD
 while (have_posts()) {
   the_post();
   // output normally
 }
 }}}

 So it the query has less than 6 posts they are output twice.

 I have so limited free time with a baby that I just checked briefly the
 referenced bug IDs.

 977 seem to indicate that some people are using some loop-only golbal
 variables when the loop has ened. Funny that when the loop has ended they
 are not set to null which makes than actually unusable. I smell some
 kludges there and it would have been correct way to point programmer to
 reset the loop when he wants to do so.

 1518 talks about in_the_loop, that I was not awere of, which is as useless
 as have_posts in determinind if there actually are anything left on query.


 I also like how Codex has has nearly everywhere if+while construction

 {{{
 <?php if ( have_posts() ) : while ( have_posts() ) : the_post(); ?>
 }}}

 which is totally redudant and useless use of "if", but more importantly
 has the exact problem that I am here crying about: two subsequent calls to
 have_posts() will in certain case have DIFFERENT return values.

 I would say copy+paste coders have high probability of doing somehting
 like this.


 I do not know how I could explain this bizarre behavior more clearly. This
 issue feels like some routine would mangle a object before you have
 finished using it or in file operations EOF detection will work only ONCE
 after that EOF will just happily state that there is more data available.

 If the current way of operation contiunues the documentation needs to add
 some warnings:

 "have_posts() command returns false when there are no more items in the
 loop and loop will be reset. After this subsequent calls to the function
 will return INVALID results.

-- 
Ticket URL: <http://core.trac.wordpress.org/ticket/11698#comment:5>
WordPress Trac <http://core.trac.wordpress.org/>
WordPress blogging software


More information about the wp-trac mailing list