[wp-trac] [WordPress Trac] #13611: Infinite loops created when page parent data relationships are incorrect

[WordPress Trac]

#13611: Infinite loops created when page parent data relationships are incorrect
--------------------------+-------------------------------------------------
 Reporter:  chrisbliss18  |       Owner:            
     Type:  defect (bug)  |      Status:  new       
 Priority:  normal        |   Milestone:  Unassigned
Component:  General       |     Version:  3.0       
 Severity:  normal        |    Keywords:  has-patch 
--------------------------+-------------------------------------------------
 I tested out some code on trunk today and ran into a serious issue.
 Whenever I navigated to certain pages on the front-end or tried to load
 the page editor, my server would either kill the request after 30 seconds
 or after it consumed all available memory (135M), whichever came first.

 I dug in and found that when I imported my sample content that the
 post_parent relationships for the imported pages were severely broken. You
 can see the resulting relationships in the following output:

 {{{
 select ID, post_parent, post_author,post_type from 3_0_test_posts;
 +----+-------------+-------------------------+------------+
 | ID | post_parent | post_title              | post_type  |
 +----+-------------+-------------------------+------------+
 |  1 |           0 | Hello world!            | post       |
 |  2 |           0 | About                   | page       |
 |  3 |           0 | Auto Draft              | post       |
 |  4 |           0 | rotator                 | attachment |
 |  5 |           0 | postsxml.zip.txt        | attachment |
 |  6 |           0 | posts.xml_.txt          | attachment |
 |  7 |           0 | A Simple Post with Text | post       |
 |  8 |           7 | A Simple Post with Text | revision   |
 |  9 |           7 | A Simple Post with Text | revision   |
 | 10 |          25 | About Us                | revision   |
 | 11 |          25 | About Us                | revision   |
 | 12 |          25 | About Us                | revision   |
 | 13 |          25 | About Us                | revision   |
 | 14 |          12 | Our Company             | revision   |
 | 15 |          25 | Our Company             | page       |
 | 16 |          14 | Job Opportunities       | revision   |
 | 17 |          25 | Our Staff               | page       |
 | 18 |          17 | Company History         | revision   |
 | 19 |          17 | Company History         | revision   |
 | 20 |          25 | History                 | page       |
 | 21 |          19 | Support                 | revision   |
 | 22 |           0 | Support                 | page       |
 | 23 |          21 | Links                   | revision   |
 | 24 |           0 | Links                   | page       |
 | 25 |          23 | Contact Us              | revision   |
 | 26 |           0 | Auto Draft              | page       |
 +----+-------------+-------------------------+------------+
 }}}

 As you can see, most of the post_parent values are set to 25, which is a
 revision.

 All WP code that calculated page ancestries would go into an infinite loop
 whenever it hit a page with a parent of 25.

 This might have revealed an importer bug (since I've previously used this
 data on a 2.9.2 install without issue), but I'll chase that in another
 ticket. Whether or not the data is bad, the code should not make itself
 prone to going into infinite loops.

 The attached patch fixes all the functions that created infinite loop
 conditions. Beyond just avoiding the infinite loop condition, the patch
 also adds a data correction process to the page_rows function. Since that
 function already has a set of checks to fix broken parent IDs, I added the
 code to that section.

 For those that are interested in testing this, I've attached an export of
 the broken data set as both a WordPress data export and as an SQL dump.
 Note that the SQL dump is a complete export, so you might want to prune
 out specific tables (such as the users table). In addition, I've attached
 the file I used to import.

 Checking the code of previous versions, it looks like this infinite loop
 condition has existed in these functions for quite some time. Based on
 that, it would seem to be a low priority issue. However, if there is new
 code (such as the importer) in 3.0 that causes the data to become
 corrupted, then having this as a reliable failsafe could prevent major
 issues.

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