Slow update for large number of ACF Fields

• willryanuk

• November 10, 2015 at 10:41 pm

We have a page which has a repeater field which contains users (First name, last name and email address). This list can grow up to about 1500 people. This means that there are up to around 4500 ACF fields on the wp-admin page. If I want to change one of these fields, and then press “Update” on the page, the request eventually times out and fails to update anything.

I have read numerous others having the same problem on the forum but without any definitive answer (note: this is not a problem with PHP settings such as max_input_vars – I have checked all of that).

The strange thing is, updating the field programatically is quick.. I can get the field, iterate through, update a value and then:

update_field('users', $updated_users_array, $page_id);

and it all happens almost instantaneously. But doing it through wp-admin is slow and unusable. How do I overcome this? Is ACF unable to cope with this number of fields? 🙁 I have a feeling it is doing thousands of database updates just to change a single field but I can’t be sure of this.

• John Huebner

• November 11, 2015 at 10:23 am

Yes, ACF is doing possibly two queries for every field that needs to be updated. The reason that it does it that it uses the WP function update_metadata for each field.

I have run into this myself in the past and I now think about how much data will need to be saved before I make a decision on how to build it. With a long list like that I would now probably create a custom post type for storing that information. To be honest, I don’t know why there is such a difference between update_field() and saving through the admin.

As far as not updating… yes the page times out, but depending on the server time limit, for example if you add set_time_limit(0) the code will continue to run till completion because PHP only checks to see if the user has disconnected when it tries to send output and it will not try to send output until the process is complete.

I could not go back and rebuild the site that had a problem but what I could to is add an acf/save_post filter that runs before ACF starts, check to see if it was the post type that was giving me problems and if it was I set the time limit to 0. Now when it times out if you hit the browser back button instead of the reload button, then wait a minute and reload the page with the group on it, it will show all of the changes. A PITA I hope to avoid myself in the future.

Anyway, I know it’s not a solution, and I can’t say what the solutions is, but I will mark this topic for the developer to take a look at and maybe he’ll be able to find a way to solve it in the future.

• willryanuk

• November 14, 2015 at 5:46 am

@hube2 Thanks for your suggestions. I think allowing the scripts to run for longer for a specific post type is a decent approach given how it works now, but i worry how it might affect DB and general server performance if it is taking 10s of minutes to run. Do you know if ACF Pro might resolve the above issues…. I’ve read about Local JSON and more advanced JSON read/write functionality, and I wondered if this might help?

It seems a shame that ACF isn’t able to deal with the case of a large set of fields. I’d be interested to know what @elliot thinks of this and whether it would be possible to improve the update mechanisms here. After a while the whole page just becomes unmanageable as nothing is able to be updated. Even if there were 4500 or so fields on the page, doing an update of 4500 rows of a database shouldn’t take that long?! But there are clearly optimisations that could be made here. i.e. why update anything if it hasn’t changed?

Is there another approach that perhaps we’re not thinking about here?

• John Huebner

• November 14, 2015 at 6:16 am

Like I said above, I have flagged this thread for E to look at when he has time but I can’t say if he will or if he will comment.

I run into the same problem with ACF pro. It has some more optimization but eventually you still run into the problem.

The site I mentioned above uses ACF Pro and to give you an idea of the problem I was facing.

One post type has a repeater field that lets the client add sections to a page. Each section actually represents a page of a printed publication. Each section can have up to 7 content areas. Each content area has controls that allow the client to specify the formatting of the block including padding, background, border, font color and I’m sure some things I don’t remember. So ff they add 10 sections that means they have up to 70 WYSUWYG editors plus the related settings fields for each. I created an interface using ACF Pro that was extremely easy for them to use, but I did not realize I would run into the updating problem.

Having run into this problem I now make a special effort to think about how much data the client might try to add. If I could go back to the beginning of that project I would create a parent/child structure to the custom post type where each “Page” section was a different post. It would have been a bit more difficult for the client to use but would have avoided the problem that they now have to work around.

This hasn’t changed my opinion of ACF, I still think it’s the best tool for the job I need to do, but I have a better handle on it’s limitations.

What I would like to see is not using the WP update meta function and use $wpdb to build queries to insert or update all of the needed database rows in a single query. I started looking into this when I had the problem but could not figure out a safe way of bypassing or cancelling what ACF was doing. I would still like to figure something out but it’s been put on a back burner do to my current workload and other projects that I need to get done.

• willryanuk

• November 14, 2015 at 6:29 am

@hube2 I was thinking the same thing about using pure WP DB stuff to do the update for any Advanced Custom Fields. But of course I’d love it just to do this out the box 😉

However, like I said, I can update the fields programatically very successfully! So I’m not quite sure why the wp-admin doesn’t do the same thing and avoid the slow update_metadata function. By maybe there is something more complex that I’m not really understanding!

I agree that ACF is absolutely brilliant and powerful. I’ve build really complex UIs using it. This is the first true limitation I’ve encountered.

• danstramer

• August 31, 2016 at 2:36 am

Hi @willryanuk
I am also having this issue with a school website, listing teachers on a page.
I currently have 75 teachers each with Name, Role, Picture, Email, Phone fields and each update can cause a timeout. It’s on a dedicated server so that’s why I think maybe some code optimization can help.
This is the code I’m using, maybe you can find something not being optimised?

   <!-- /////////// Staff /////////////// -->                   
                     
                     <?php 
 
				// check for rows (parent repeater)
				if( get_field('staff') ): ?>
					<div id="staff">
					<?php 
 
					// loop through rows (parent repeater)
					while( has_sub_field('staff') ): ?>
						<div class="section">
							<h3><?php the_sub_field('title'); ?></h3>
							<?php 
 
							// check for rows (sub repeater)
							if( get_sub_field('items') ): ?>
								
								<?php 
 
								// loop through rows (sub repeater)
								while( has_sub_field('items') ): 
 
									// display each item as a list - with a class of completed ( if completed )
									?>
									
                                    <div class="item">
                          <div class="portrait">
                         
<?php $image = wp_get_attachment_image_src( get_sub_field('image'), 'staff-portrait' ); ?>
<?php if (get_sub_field('image')): ?>
<img src="<?php echo $image[0];?>" alt="<?php echo get_the_title(get_sub_field('image'))?>" />
<?php endif; ?>
</div>
<div class="data">
                     <h4 ><?php the_sub_field('name'); ?></h4>
                     <span><?php the_sub_field('role'); ?></span>
                     <?php if (get_sub_field('email')) : ?>
                       <span><a href="mailto:<?php the_sub_field('email'); ?>">שליחת מייל</a></span>
                       <?php endif;?>
                        <span><?php the_sub_field('phone'); ?></span>
						 	</div>					
						</div>       
								<?php endwhile; ?>
								
							<?php endif; //if( get_sub_field('items') ): ?>
						</div>	
 
					<?php endwhile; // while( has_sub_field('staff') ): ?>
					</div>
				<?php endif; // if( get_field('staff') ): ?>
                     
                     
                     
                      <!-- /////////// End Staff /////////////// --> 

Dan

• Iain Poulson

• October 4, 2022 at 5:39 pm

Hey @willryanuk – the new pagination setting for the Repeater field in ACF 6.0 should help with this issue. https://www.advancedcustomfields.com/blog/acf-6-0-released/#repeater-pagination