Search Results for 'slow saving'

Hi,

I am currently working on a few small utility applications to help move data from locally stored files to a locally hosted WordPress site. I am doing this through python-xmlrpc which has worked well up until this point.

I would like to pre-face this by saying that I do not have access to change any of the theme code or the ACF field settings within the site. I can simply create and edit posts.

The issue occurs from a post type that only really makes use of the ACF fields given to it and acts like an account database for users (which are separate to the actual WordPress users). When I attempt to create a new post of this post type, it will create a new post and the fields will end up filled but not actually saved to the database. I then need to press the “Update” or “Publish” button manually on the page which will save the data and allow it to be used (since the data acts as accounts, I have tested this by trying to log into the newly made account both before and after manually “saving” the data).

I am placing the values into the WordPressPost.custom_fields attribute (https://python-wordpress-xmlrpc.readthedocs.io/en/latest/ref/wordpress.html). To do this, I am using the field name rather than the field key which is mentioned in a few other threads. I tried to use the field key to make this work but it would make the post and not actually fill in any data at all.

Does anyone know why the post will not save just from the xmlrpc call and anyways that you can make that happen?

I understand that this could just be a limitation of ACF and XMLRPC in which case I have a couple options. One to use Selenium to just simulate the button press but this would be a much slower solution. Another thought I’ve had is to try and perform the same actions that the “Update” button does but externally through my own program. The only thing I’ve found so far is a call to admin-ajax.php, so if anyone has an idea of how that could be replicated that would be very much appreciated.

I would also like to add that editing posts of this type works perfectly as expected and can even edit the new posts before I have manually pressed “Update”. Although, the new posts will not function as accounts until I have pressed “Update” even after editing through xmlrpc.

I would like to share our experience regarding slowness when dealing with a large number of fields and rows in a repeater.

We have a repeater with approximately 14 fields (including 1 media field) and 300 rows in a custom post type.

The saving process takes about 5 seconds.

However, if we enable revisions for our custom post type, the saving process takes 80 seconds. The reason is that revisions re-save all 300 rows in the database, triggering thousands of hooks as well. Instead of saving only the differences, as ACF does when revisions are disabled.

So, it’s something to consider if you’re experiencing slowness issues with a lot of data on your page!

David

Hello, I have a gallery field (acf pro) on a page and when editing that page, it is very slow to open it because after saving and reloading the page, the images are displayed on full size, so the page takes 10-15 sec to refresh.

My preview size for that gallery field is set to a custom size of 250 x 250px not cropped but I tried other sizes with the same result.
I noticed that only square images are correctly resized and displayed to 250x250px (or any size that I choose on preview size setting).

Also, I’m using Shortpixel to optimize images and when I add an image on my gallery (or even refreshing the page), the optimisation and thumbnail are kind of reset (button “optimize now” is back on Media>library and it says “optimize 2 thumbnails” but I have more than 2 thumbnails).
I tried disabling Shortpixel and Regenerate thumbnails but images are still loaded in full size.

Any help on that ?

I want to create new Woo products in backend as admin (or update), without using the default WP title field.
The title (and permalink + slug) should always be created based on values selected in two dropdown boxes and one text field in ACF Pro (all are mandatory fields). When saving the product (also about 20 other custom fields) it should be created/updated and published. The title should be a combination of: “value 1 + 2 + 3”.

Changes afterwards in the products default WP title field should be ignored (maybe hide that), unless any of the three custom fields that create the title have been edited. Updates in any of the three custom fields should not only update the title when saving, but also update the permalink and slug.

I created a solution to this at least 5 years ago, but it was a slow and bad solution as I´m not a coder. I can´t find that code, but it took about 30 seconds to save a product so there were probably several errors in that code (I guess that “wp_insert_post_data” was run before the acf/save_post)! I have searched for an updated code in several forums, but I have not succeeded. I really appreciate any help with this!

WP (5.8.1), Avada (7.5), ACF Pro (5.10.2), PHP (7.4.25). Smarter code and better performance with PHP version 8.0.12?

As I explained in a previous post, I have a repeater with many fields (more than 50).
If I have more than a few rows in a post, this will probably create performance issues when saving the post, and there is no real solution except rethinking the way my fields are built.

I will consider creating separate custom post types, but I’d rather avoid it if I can so first I’ll try to reduce the number of fields. For that I need to understand some concepts on how WP/ACF work with the database.

1. Even though I have more than 50 fields on each row, many of these fields will remain empty most of the time.
– Does an empty field (that was already empty before) make saving time longer? I suppose so, since the simple fact that the field exist obliges WP to check if there is a value in it
– Does an empty field generate a lot of extra time, or is it negligible compared to a field with a value ? I don’t know.

2. Inside my repeater, I have a subrepeater that remains hidden via conditional logic.
Most of the time, this subrepeater remains hidden and empty. However, I set up a minimum of 1 row by default in that subrepeater. Should I make it 0 row by default so as it doesn’t create extra fields unnecessarily ? Will it change anything ?

3. If I’m correct about question 2, I’m wondering if I could optimize performance by “generating” custom fields only when needed (just like I “generate” fields in a post by adding the first row in a repeater).
The post I’m creating is some kind of CRM, or “project pipeline”. Some fields will be used since the creation of the post, but many others will be used only if the project goes to the next stage. Therefore, many fields will remain empty and unused for most of the posts, but slowing saving times anyway, just because they are there.

Wouldn’t it be possible to create a button to “create” these extra fields only when necessary, i.e. when going to the next stage of the project ?
If this is a viable solution, I could maybe extend this logic to other fields inside a same stage : create them only when needed.

Thank you !

Hi

Sidenote: I’ve already asked this question with a support ticket but I’m also looking for an opinion from the community

Right now I’m thinking about creating a website/webapp based on WordPress and ACF Pro. It’s a front-end posting tool: each user will be able to create a new post with acf_form and then get the permalink of the post in return.

Each post is going to have a few basic field (5) and a repeater field which contains 6 fields.
Usually users are going to add about 20-40 repeater’s row.

To my understating (correct me if I’m wrong), this means that each and every time a post is created, since WordPress adresses each custom field saving at a time, there could be about 5+(6*30) = 185 queries which start as the user click the submit button on the form.

I’m not afraid for the actual post viewing – I’ll just add a caching system. What worries me is the amount of queries: is 180-200 queries a lot?. The thing is that I’ve always been a front-end developer and I don’t have that much knowledge server-side. What I’m worried about is what could happen if, per say, 1000 users (or 10k) click the submit button at the same time on this website hosted on a normal basic hosting (It’ll probably be Siteground GoGeek or something similar in the same range.

Is it actually scalable? Will it become super slow? Will it handle the pressure?

I’m sure that whatever the task there’s always been a server able to handle it but I’ll probably have a basic one. What I was wondering is if this scenario is, generally speaking, heavy/intensive for a common/average hosting.

Thank you

Bye

Hello,

I have a PHP script that does the following:
– It returns a JSON object of (dynamic) Google places
– It saves this review data in a repeater field
– Next, this data is displayed in a carousel

The above works properly, there is one main issue though: it makes the pages laod extremely slow. Is there a way to speed this up? Please find the code below:

Please note: I am definitely not a PHP expert, so any help is much appreciated.

Thanks a lot!!

$response_accommodation = wp_remote_get( 'https://maps.googleapis.com/maps/api/place/details/json?placeid=<place_id>&fields=name,rating,user_ratings_total,review&key=<key>');			
			$place_id = get_field('google_place_id');
			
			$response_accommodation_new = str_replace('place_id', $place_id, $response_accommodation );
									
			$body_accommodation = wp_remote_retrieve_body( $response_accommodation_new );					
			$body_decoded_accommodation = json_decode($body_accommodation, true);									
			$place_accommodation = ( $body_decoded_accommodation['result']);			
			$number_reviews_accommodation = ( $place_accommodation['user_ratings_total']);			
			$grade_accommodation = ( $place_accommodation['rating']);				
			
update_field('rating', $grade_accommodation);
			update_field('number_reviews', $number_reviews_accommodation);
						
			$reviews_accommodation = ( $place_accommodation['reviews']);
			
			foreach($reviews_accommodation as $v) {
				
					$review_rating_accommodation = $v['rating'];
				    	$review_name_accommodation = $v['author_name'];
				    	$review_date_accommodation = $v['relative_time_description'];
				    	$review_text_accommodation =  $v['text'];
				    	$review_profile_photo_accommodation =  $v['profile_photo_url'];
					
					$row_accommodation = array(
					    'author_name' 		=> $review_name_accommodation,
					    'review_date'   		=> $review_date_accommodation,
					    'review_rating'  		=> $review_rating_accommodation,
					    'review_text' 		=> $review_text_accommodation,
					    'review_profile_photo'	=> $review_profile_photo_accommodation,
					    'review_summary' 		=> substr($review_text_accommodation, 0,75)
					);
					
					add_row('reviews', $row_accommodation );
					
					}								
?>

If you have any other questions, please let me know!

I am looking forward to receiving your answers.

Cheers,

Hans

Hello everyone,

I am using ACF Pro in a self-developed theme. The backend for inserting new field values operates slow and I want to speed it up.
(I do not care about frontend loading/php-“rendering” the page – I use wp-super-cache).

The field groups are set up nicely structured, using repeater fields (with quite some nested fields in them – wysiwyg, file-uploads and others) so the customer has a good experience inserting values. Hence, the customer used the page to a great extent which led to quite some content.

The backend-page (“edit page”) takes quite some time to be ready for editing (~4 minutes). Updating/saving after a change takes even longer (~15min).

Now, what I did so far is the following:

• use ACF local JSON
  https://www.advancedcustomfields.com/resources/local-json/
• adjusted the amount of revisions to be stored to a small number
• update the server configuration in .htaccess (pages runs on ordinary shared hosting plan)

  php_value max_input_vars 8000
  php_value suhosin.get.max_vars 8000
  php_value suhosin.post.max_vars 8000
  php_value suhosin.request.max_vars 8000
  
  php_value memory_limit 300M
  php_value upload_max_filesize 300M
  php_value max_input_nesting_level 128
  php_value max_input_time 600
  php_value max_input_vars 8000
  php_value max_execution_time 600
  php_value post_max_size 300M

• forced the many TinyMCE-editors from the repeater fields to load in html-tab as suggested by user sdempsey on:
  https://support.advancedcustomfields.com/forums/topic/js-performance-issues/page/3/
  (this helped with the page loading issue and narrowed it down to ~2 minutes)

What I do not understand and only guess:

• ACF loads all contents of (repeater)fields when I start editing a page. This takes time.
• ACF “restores”/saves all values again (or builds huge DB queries) upon saving. This takes time.

Now to the real question (“requirements”):
Is there a way to:

• Load contents of repeater fields asynchronously on the edit page backend?
  (only upon opening the respective repeater-“section”)
• Is it possible to save only the “diff” of changes?
  I.e.: write only the changed fields to the DB, not all (again)?

☞ Is there a plugin or filter/hook-workaround that can fullfil these requirements?

Thanks to everyone who read so far and is deep enough in the topic.
Every answer or hint is appreciated! 🙂

Cheers

PS: Of course I could also avoid this situation by refactoring my Theme “divide and conquer”-style.
I.e. I could split the number of repeater-fields from one page to, lets say custom post types that would resemble the outer-most hierarchy of repeater fields. By this, I would have more “posts” (with each having just a share of the total number of fields) that I would glue together as the final page. But, this would require the customer to re-learn the procedure of editing content. And most of all it would require me to refactor/migrate the Database for existing contents.

Hi,

i have serious performance issues with a repeater-field in wp-admin. Frontend runs ok. The repeater-field contains 7 sub-fields (all text). With more than 100 entrys saving became really slow (over 30 seconds).
Do you have an idea how to speed up the saving procedure?

Thanks!

Hi,

we’re having an issue with the Flexible Content field is acting very sluggish. With only 11 flexible content blocks added to a page it will take a minute to load, even more.

Looks like others have similar issues http://support.advancedcustomfields.com/forums/topic/js-performance-issues

Any hints on where to look to fix these performance issues would be appreciated.

However, our main issue is this:

If the client updates something at the top of the page (ie. an image or the title) and then hits Update before ACF has finished loading all repeater blocks, anything not loaded yet will be cleared from the page.

So, saving before ACF has loaded will delete content from posts.

Is it possible to disable the save button while ACF is loading?

Hi
This is a common question on diffrent forum about multilang support for ACF and how to get it to work. But no straight answer. What I understand you are not so familar with WPML (according to threads, but old ones I found).

When making “field groups” translatable is also have to make som fields translatable too, and the WPML box are showing A LOT of ACF fields, specially when using repeater.

The mandatory selection to “show” ACF on secondary language pages are:

-rule
-position
-layout
-hide_on_screen

They must be set to “Translate”. Then in the box, we have a lot of:

field_523e53ec1fbe0 (around 5 - 10 for me)

and this little single child: (sometimes)

-allorany

Qustion is, the 2 latter, are they “yours” and if so, what are they doing?

Second, in the main config of WPML for custom fields, all my id:s I created are listed, but also a copy with _underscored prefix. Like:

ua_mobile_shortcut_menu_tab_1
_ua_mobile_shortcut_menu_tab_1

In my case, in this setting box, around

30 st field_523e53ec1fbe0...
65 st my_ids-created_for_all_fields...
65 st _my_ids-created_for_all_fields...

All are with option “Make translateable”, “copy” or “never translate”…

Question, are the “underscored versions” yours, and if so, what are they doing?

I did a huge setup 3 years ago (dating site) with ACF buddypress and WPML, and I just checked “Everything”, but I don wanna do that this time. – couse it seems renundant, and I wanna know what Im doing. Checking randomly just make a slowing mess.

ACF is a little tricky when WPML “Dublicated mode” is in use, The “synced copy” must be updated / saved, to get all the ACF “rules” in placed. (Only the first rule is applying, but after saving they all shows up)

With a little help from you, to understand the context, I hope to deliver some aswers to other forums about this 2 plugins.

And yes for any reader, Advanced Custom Fields ACF is today 2014 compatible with WPML – WordPress Multilingual Plugin. Everything just has to be saved in the right order. You Dont have to rewrite any ACF templates.

/ Jonas

• In reply to Over 90 layouts in a flexible content field causing MAJOR slowdowns

• August 20, 2023 at 7:23 am

After testing on my dev build this weekend 6.1.5 is quick on saving and 6.1.6 onwards is really slow (5 mins on saving). I’ll contact their support and see what they say.

There’s been a few security fixes since 6.1.5 so I won’t use it on the live site, but I could leave it on my dev build which should quicken things a bit.

• In reply to Over 90 layouts in a flexible content field causing MAJOR slowdowns

• August 17, 2023 at 5:19 pm

Ignore the above. It must be something thats happened (the slow down) in a recent update as I’ve downgraded to a v5 (as a test) and its back to saving instantly. I’ll now keeping updating until it slows again to find the version thats the issue.

• In reply to Repeater field with many inputs

• April 2, 2023 at 10:36 am

Unfortunately, no.

And by adding the load_value and save_post hooks you’ve slowed it down even more because ACF will still save the values to the database and load those values from the database. Using these hooks does not override the default ACF action.

It might be possible to do this if you use acf/save_post with a priority of < 10. This would run before ACF has saved the values. You could then loop over the repeater in $_POST[‘acf’] and create your JSON and then delete the repeater input from $_POST[‘acf’], deleting the input will prevent ACF from saving the values.

It’s probably too late to make a changes but 250 rows with 12 fields in each row tells me that this should have been done with a custom post type instead of a repeater.

• In reply to Error 500 / 504 on update page with a lot of ACF fields

• August 26, 2022 at 10:10 am

This is something that happens when saving a large number of fields. There are too many DB queries that cause the page to time out. This has been discussed here before, many times.

• In reply to How to get field reference

• September 13, 2021 at 8:44 am

I wish you luck with this. I have had my share of problems with slow updating. My main issue is with flexible content fields and I have never found a way to reliably bypass the ACF saving and do the updates myself.

How are you preventing ACF from saving values in order to run your own code to do the saving?

• In reply to get_posts filtered by custom field very slow

• November 2, 2020 at 12:54 am

Reading in 10k posts and then looping over them will likely cause other issues with performance due to the data returned in the query and memory.

The biggest issue to speed is that regex on the date and the number of fields your using to filter.

If I needed to do something similar to this and knew it before I started I would have a separate field (not in ACF, just your standard WP custom meta field). I would create and acf/save_post filter. In this filter I would get the date field, extract the year and save just the year into this other field. The I could do a simple ‘==’ compare on this field. This would greatly improve the performance of the query.

But with 10k posts to look at it might still be a little slow. If it was I would likely use WP transients to store the results of the query for a time. This would mean the query would only need to be run once every few days.

You could also have a taxonomy for the year, as in one of the points you listed, with the right settings you can actually hide this taxonomy. Instead of saving the year in another fields as in my first suggestion the acf/save_post filter would set the correct term in the year taxonomy.

Post meta can be used for filtering, however, the filtering needs to be limited and the use of things like “LIKE” and “REGEXP” are going to cause performance issues.

I also have one site, this site has “Products” and there are (no lie) 18 different filters used on this site. Trying to filter by 18 custom fields would simply time out the load of the page. In this case, when a new “Product” is saved a CRON is triggered. This CRON runs through all of the possible values for every filter and stores the results. On the front end of the site I use this information to query the posts.

Use a WP option, lets call this option “birth_years”. This option would be an array with this architecture.

$birth_years = array (
  // each element of this array is "YEAR" => array()
  "2020" => array (
    // each element of this array is a post ID of a person in this year
    1, 2, 3, 4, 5
  )
);

Create an acf/save_post filter with a priority of 1 so that it runs before ACF saves the value of the date field. See the doc for this filter. In this filter I would compare the old value with the new value. If it is the same I would do nothing. If it is different I would get the option, remove this person’s post ID from the old year and add it to the new year in my array.

Then when doing the query for people in the same year I would get the option add this to my query

'post__in' => $birth_year['2020']

completely eliminating the meta query.

Hope some of this information helps you

• In reply to Client Side loading of Repeater on Edit page

• March 28, 2019 at 2:12 am

The size of the image may slow it down.

You also have 4 date and/or time fields, times 60 rows, that’s 240 date/time fields that need to be initialized and these types of field do not offer the delayed initialization option. This is likely a contributing factor.

Repeaters (and flex fields) are great, to a certain point. The pitfalls of using them for large amounts of data is something that has to be experienced. So that you know, I’m not knocking the way that you built this feature, I have been here. I once created a page editor for a client using a repeater for “sections” and each “section” could have up to 10 wysiwyg fields plus other associated fields. Everything was fine until the day they tried to create a page with 25 sections (250 WYSIWYG editors + other fields). Even delayed initialization did not help me as saving the page also timed out. I ended up rebuilding the CPT using “child” posts for each section.

I don’t really have any good advice that will help.

• In reply to Ordering by custom field of relationship field object

• August 29, 2018 at 5:26 am

Sorry I didn’t get back to you sooner, I’ve had a crazy week. Glad you got it worked out.

Your last question was correct, it would not be updated if the related post is updated. I would probably go with some alternate approach still other than using those joins because of site speed…

…though I don’t know how I would do that. When the post is updated at the other end I would probably do something like doing a query to get all the posts that have the relationship and update all of the values for those posts. This would slow down the admin when saving posts but that to me is preferable to slowing down the front end of the site.

• In reply to Flexible Content, Help Creating Dynamic Script to Detect Adjacent Flex Content

• April 21, 2018 at 1:58 am

Unfortunately, there really isn’t a way to make some things go faster.

If you’re talking about the field group editor, This shouldn’t get too slow. Each “Field” in the field group is a “Post” so it can take some time to load them and save them.

If you’re talking about the speed when editing a post, this is something that you’ll need to account for. Loading is not generally a problem, but saving can be a problem. You will find other topics on this. ACF uses the standard WP functions for saving meta data. This means that every field adds additional db queries. With enough data the admin page for a post will eventually time out.

• In reply to Performance of Backend super slow

• January 13, 2018 at 5:50 am

ACF has a delayed initialization for WYSIWYG fields, and I would suggest using this.

There is no solution for async loading of fields.

As for the slow saving. There isn’t much that can really be done here. ACF works by using built in functions for updating post meta fields. ACF has no way of know what content has been changed. The WP function update_post_meta() and equivalent do this work. Basically, because of the way meta values work, this is done 1 field at a time. WP supplies no mechanism for doing it any other way.

I see this as a flaw in WP and not in ACF. ACF’s goal, to my understanding, is to allow us to create an admin for editing custom meta values using what is available to all of us without ACF. The problem is that it’s really easy to create these monolithic admin interfaces without realizing that there may be a problem down the road.

This is an inherent limitation when using WP and repeaters/flex fields. There have been many discussions about this here https://support.advancedcustomfields.com/forums/search?bbp_search=slow+saving. If you read any of these you’ll see that I’ve suffered from the same problems myself. There are no good fixes, anything I’ve done has just been hacks that have had varying degrees of success. The only real solution is to be aware of the limitations and develop in a way that works around those limitations, as you suggest, by breaking things up into smaller chunks. Unfortunately, by the time most people realize that there is a limitation they are already having issues because of the limitation.

• In reply to ACF Pro 101 and advanced use?

• December 15, 2017 at 3:01 am

You probably saw this coming, but the answer to all your questions is “It depends”.

I have been using ACF for so long that I do not remember a site I’ve built without it. Every site I build for a client is custom based on their needs.

1. Is there anything like too many ACF fields? Or you always recommend to use ACF.

The answer to this one is Yes. But mostly this has to do with repeaters and flexible content and saving the post. The number of ACF fields will rarely impact the performance of the front end of the site.

When you have a lot of repeaters and flex fields, and depending on what types of fields you are using, the number of fields can impact the performance of the admin in 2 ways.

The first is that the loading of the post editor could be slow when there are a lot of fields that depend on JavaScript, like any of the jQuery fields, this also includes WYSIWYG fields that depend on tinyMCE. When building complex field groups it is important to take advantage of the “Delayed Initialization” provided by some of the ACF fields.

The second way that it effect the performance of the admin is when saving a post. There is a point where the save process can time out.

I’ll give you an example of this. I once built a site for a client that had a repeater. Each row of the repeater had 7 WYSIWYG fields. The content of the page required specific formatting for layout out these content fields in a very structured way to meed the client’s requirements. All went well until the client decided to add 30… let’s call them “Panels” to one page of the site. This meant that ACF needed to save 210 WYSIWYG fields and related fields for determining other options. What happened was that the save took longer that 30 seconds, which meant the the browser timed out and it appeared that it crashed the site. (In reality, it was just the browser timing out. The update went merrily on it’s way in the background and completed successfully. When this happens you can wait a minute or 3, use the browser back button and then refresh the editor and all of the changes would appear.) It was because of this that I built this https://github.com/Hube2/acf-prevent-timeouts.

When building something for a client using ACF it is important to think about how the client can abuse your masterpiece. I did not know that this problem existed when I built this site, but knowing it now I would not build another one the same way. I would likely use a post type using a parent page/post and child pages/posts in order to break things up and therefore avoiding the issue.

2. When certain layout becomes too complex with tiny fields for everything, do you still use ACF or you look for page builder options in such scenarios?

I have never used a page builder. I’ve found that they are too generic. They also rarely meet the specific requirements of my clients. Like I said, I build custom sites to exactly match the client’s needs. ACF allows me to do this without trying to shoehorn them into something that may not be exactly what they wanted. I also find that most page builders are bloated and also give the client too many options that allow them to break things easily. When using ACF I can give them only the options that they need. It makes my life easier because it’s harder for them to break things. And it makes their life easier because there is less for them to learn in order to manage their own site. My goal, when building a site is to turn it over to the client and for them to be able to do everything they need. The last thing I ever want to do is manage the content of a client’s site or need to make changes because they cannot understand how to do it themselves.

3. Finally, lets say you are working on a blog. And at some point you want some custom structures in the middle of article, maybe a table or some other layout. How do you approach it? Do you create ACF templates and split up content area with repeater field so you can use these custom structures in the middle of articles? Or again do you take some other approach?

The answer to this one is the biggest “It Depends” answer.

For a blog… meaning “Blog Posts”. for this they usually get just the standard WP editor. Blogs are free form and all content and formatting inside of “The Content” area is up to the client. I may provide other options on the blog, for example a way to allow them to specify a banner image for the page, or some special feature. However, I will never build a way that requires special formatting and layout within this area.

For the rest of the site. For example, page layouts and custom post types. These are almost always formatted specifically. Meaning that every page must look the same as every other page with set features. These features may be optional on each page, but when they appear they will always be shown in the same place and always appear the same when shown. These pages, templates and post types will have fields for everything that the client should be able to control. Outside of the blog, almost all of my clients require that the structure of specific pages be the same and meets there companies style guide. I may need to build them many specific templates for different page layouts. On occasion I also have included a generic page where the content is just a basic content field where they can control the layout, but this is rare and the client that wants this is usually familiar with WP and the use of things like shortcodes and editing HTML directly.

In the case you mentioned about a “blog” with custom structures in the middle of the content. If this was a requirement given to me by the client I would likely give them 2 content editors, one for the beginning of the blog and one for the end and the other fields in the middle and it would be up to them do decide where this special feature would be inserted. The other option would be to build a custom shortcode so that they can insert the special features into their page. But like I keep saying, that would depend on the client’s specific needs.

• In reply to Better performance when saving large numbers of fields

• January 14, 2017 at 6:38 am

I’ve been digging through the code in ACF and I’ve discovered something else that slows things down. Revisions. If revisions are supported by a post type then this will more than double the number of queries that need to be performed. Revisions is not something that I thought about. Before saving the values ACF gets all the existing values and copies them to the most recent revision and every field goes through the same update process for the revision.

• In reply to JS performance issues

• November 10, 2016 at 8:26 am

No solution here, just some thoughts.

There are really 2 issues discussed in this thread. On of them is a slow admin page due to the performance of JavaScript, the other is a slow saving issue. While it may appear to many that these are the same issue, they are in fact to separate issues as far as code and what’s going on.

The JS issue will cause the admin page to be sluggish do to the way that ACF4 tests conditional logic. ACF5 has improved this…. but if you have a highly complex field groups setup with a lot of conditional logic, you’re still probably going to see problems and a slow down.

The second issue, slow saving. This is an issue with the way that WP updates meta values. Every update query for every field in ACF produces at least 4 DB queries. First WP checks to see if there is already a value for a field and then it updates the value for the field. Sometimes it then does a new query to get the new value and populate the cache… why it needs to do this 3rd one, HTH knows. This is done twice for each field because ACF also needs to update the field key reference for the field. This is a limitation of WP because when updating it deals with one meta field at a time. It may be possible to improve this by adding an acf/save_post filter that gets all the post meta for a post before doing an update… but I have not tested this theory. At any rate, given enough fields on a single update it is possible that the update will time out in the browser before it completes. Fixing this problem I suspect is beyond the scope of what ACF is meant to do. Now, if someone could come up with a way to bypass this one at a time field update…. I’ve thought about it but I simple don’t have the time.

On top of both of these issues is the fact that validation of field values is done on the server using AJAX. Part of the reason for this is to allow us, the developers, to create custom validation filters. This is an extra step that means the a post is actually sent to the server twice before it’s updated.

My solution is to consider the limitations and plan my development around those limitations. What is logically possible and what is possible in practice are not the always the same thing. If I give a user a repeater field to add images and content with I expect them to be practical and not add 10,000 images to the repeater, although I wouldn’t be surprised if they tried.

• In reply to JS performance issues

• November 10, 2016 at 5:35 am

Same here. I’ve some problems saving a Flexible Layout group containing 5 layouts / 24 fields. The site feels very slow (JS) an needs about 10 seconds to save in Chrome – in IE it seems a bit faster. Is there a fix for this?