• MachineScott

• in reply to: Add_row and add_sub_row running slowly
• August 8, 2018 at 3:27 am

Hi John,
Yeah, I kinda figured. Was hoping for some miraculous way around jamming a ton of data into WordPress…

We ended up changing the business logic on this one, and are now running the duplicate exam function every 10 minutes starting a few days before the exam date, so that all users will have their exams created before they show up. Not the best, but everyone will at least get instant access to their exams.

Thanks for the reply!

• MachineScott

• in reply to: Duplicate title posts – one disappears.
• April 7, 2016 at 12:18 am

This is great – thanks James!

• MachineScott

• in reply to: have_rows causing infinite loop when getting repeater values from another page
• November 10, 2015 at 3:35 am

Hi John,
This is an interesting workaround, but in the end, all it’s doing is passing in the post_id to have_rows(). I’ve accomplished this in a simplified manner using setup_postdata() a few comments back. This method also avoids having to update all of the other templates I’m using for the large number of flexible content layouts included on each site.

I think we can call this one closed for now, but thanks for investigating it with me!

• MachineScott

• in reply to: have_rows causing infinite loop when getting repeater values from another page
• November 7, 2015 at 5:56 am

Hi John,
We’ve tried it without get_template_part, and it still does the same thing. My first message in this thread included that code.

Yes, please pass this up – would be great to have a fix that doesn’t include setup_postdata.

Thanks!

• MachineScott

• in reply to: have_rows causing infinite loop when getting repeater values from another page
• November 5, 2015 at 3:42 am

Okay, ultra simple version of this, with a temporary workaround.

The problem is that have_rows uses $post_id from the current page when you don’t specifically set it, even if it’s nested in a have_rows that has it specifically set.

1. have_rows(‘field’) <- uses current (original) $post_id
   1. have_rows(‘field’, $otherpostobj) <- uses $otherpostobj
      1. have_rows(‘otherfield’) <- uses original $post_id instead of $otherpostobj

The workaround is to setup_postdata before the third-level have_rows, and wp_reset_postdata it once we’re done with it.

Can this be updated to use the parent have_rows post if it’s been specifically set?

• MachineScott

• in reply to: have_rows causing infinite loop when getting repeater values from another page
• November 5, 2015 at 2:40 am

Hi John,
I’ve drawn up a little diagram to further explain what I’m doing here.

Here’s a point-by-point explanation:

• Both pages use flexible content layouts, so they both include have_rows()
• Page 2 includes a flexible content layout that has a repeater inside
• That block has a text field “block_id”, where a user can give it a unique name (we’re using “targetblock”)
• We want to include “targetblock” on another page
• Page 1 includes a flexible content layout, “block_reference” that includes two fields:
  • “target_block” – text field where users can enter the unique name of the target layout to include
  • “target_page” – post object field where users can select the page that has the target layout on it
• “block_reference” does a few things:
  • Loops through the flexible layouts on the target_page
  • Checks if there’s a “block_id” field that matches “target_block”
  • If found, it includes whatever that flexible content layout would normally include (in this case, a repeater field)

All of this is working as long as the block that we’re trying to pull from Page 2 doesn’t include another have_rows() call. I’ve explored the plugin code a bit, and it looks like there’s a case where it breaks in api/api-template.php around line 489.

I’m going to do some more testing, but the main problem is that it’s resetting the have_rows() loop for Page 1, causing the entire page to be re-generated, which includes the item from Page 2 again, causing the infinite loop.

I’m aware of the potential for including another “block_reference” from another page, and have added some code to avoid this.

Thanks again for your help,
Scott

Base-Target-....png

• MachineScott

• in reply to: have_rows causing infinite loop when getting repeater values from another page
• November 4, 2015 at 2:21 am

Hi John,
Please see attached! I’ve re-created a simplified version of the field group, and have re-tested using updated code. It’s still doing the same – it resets the first loop, causing the page to keep spitting everything out again and again.

Thanks!

acf-export-2....zip

pages-and-te....zip