WordPress.org

Make WordPress Core

Opened 5 years ago

Closed 5 years ago

#9458 closed defect (bug) (duplicate)

There can only be one loop

Reported by: Denis-de-Bernardy Owned by:
Milestone: Priority: normal
Severity: normal Version: 2.8
Component: Optimization Keywords: needs-patch dev-feedback
Focuses: Cc:

Description

Currently, the recent posts widget will needlessly trigger the start_loop and end_loop hooks, and set in_the_loop to true when it's definitely not needed.

The attached patch ensures that only $wp_the_query will do such a thing.

Attachments (2)

9458.diff (1.3 KB) - added by Denis-de-Bernardy 5 years ago.
9458-better.diff (9.7 KB) - added by Denis-de-Bernardy 5 years ago.

Download all attachments as: .zip

Change History (15)

Denis-de-Bernardy5 years ago

comment:1 filosofo5 years ago

I don't think that will work consistently in PHP 4, which will just check for the same attributes.

comment:2 Denis-de-Bernardy5 years ago

  • Keywords has-patch tested dev-feedback added

@filosofo: my understanding is that, in php4, it'll check the object number too.

The second patch fixes a whole range of miscellaneous bugs related to calling query_posts(). Basically, the various is_* functions and so on that are directly related to the main WP_Query are changed in such a way that they all use wp_the_query rather than wp_query (which gets overridden by query_posts().

An additional patch could, optionally, drop the calls to setup_postdata() when it's not the main query. But I figured that, since the template tags are used in the recent posts widgets, that one is probably left untouched.

comment:3 filosofo5 years ago

I can't find an official version of the PHP 4.3 manual (it's probably buried in the CVS repository, but I have no idea where to look), but if this page is accurate, === will evaluate to true when two separate instantiations have the same attributes.

comment:4 Denis-de-Bernardy5 years ago

well, even if that *is* the case, it's an extremely minor issue (imo) compared to kicking loop_start and loop_end when it's completely irrelevant to do so. And if the === works in php5, which is does, that would be much better than no patch at all imo (php4 no longer being maintained).

comment:5 Denis-de-Bernardy5 years ago

  • Keywords commit added

commit, wontfix?

comment:6 Denis-de-Bernardy5 years ago

  • Keywords needs-patch added; has-patch tested commit removed
  • Milestone changed from 2.8 to Future Release

patch is b0rke

comment:8 jacobsantos5 years ago

I think a better question is why isn't the recent posts just not creating a new WP_Query object instead of trying to use the functions?

comment:9 Denis-de-Bernardy5 years ago

trouble is, it does... it *is* creating a new WP_Query. but something in there is not only modifying $wp_query -- it's also modifying $wp_the_query... :-(

comment:10 jacobsantos5 years ago

  • Resolution set to invalid
  • Status changed from new to closed

The $wp_query is not the problem, it is fine, well, unless you consider the wp_reset_query(); but that is needed to reset the post data that is destroyed when running the widget.

The fact is, the widget is working as it should. The problem exists elsewhere and that, well, good luck with that. It is going to require a bit of work to find the root cause and it is going to take a bit of work to find a good fix. Although, I will comment that PHP5 class that implements Iterator wouldn't have the same issues.

comment:11 jacobsantos5 years ago

The reason I closed this patch, is that the description is either out-of-date or incorrect, in which case the 'invalid' is accurate or both.

comment:12 Denis-de-Bernardy5 years ago

  • Resolution invalid deleted
  • Status changed from closed to reopened

see #7080

comment:13 Denis-de-Bernardy5 years ago

  • Milestone Future Release deleted
  • Resolution set to duplicate
  • Status changed from reopened to closed

merging this into #9854

Note: See TracTickets for help on using tickets.