Support

Account

Register Login

Home › Forums › Search › Search Results for 'slow saving'

Search Results for 'slow saving'

topic

  • Unread

    ACF fields filled in with XMLRPC will not save

    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.

  • Unread

    Slow saving with repeater and large data

    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

  • Helping

    Issue with images size in gallery field (back end)

    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 ?

  • Solving

    Create product title + permalink + slug from several custom fields

    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?

  • Solved

    Many custom fields in a post : optimize performance

    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 !

reply

  • 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.

  • 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.

  • 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.

  • 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.

  • 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?

  • 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

  • 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.

  • 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.

  • 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.

  • 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.

  • 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.

  • 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.

  • 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.

  • 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?

  • I’m dealing with a site right now that has a lot of fields and I’ve been thinking about this issue. I’m using ACF as a page builder of sorts, and while I’ve found ways to reduce the number of fields in use the slowdown is noticeable on large pages.

    I’m wondering if some sort of alternate saving option might be viable? For example, if top-level repeaters and flexible content fields were saved as a single post meta (encoded in some format), then only decoded and cached when have_rows() is called, that might help with this sort of issue (I assume all large field quantity issues come from repeaters and flex fields). I am not at all sure what other repercussions this might have though, nor if there are better options. If there are tradeoffs, making it an option on the field group level might be sufficient so that we can choose the best save method for our intended use case.

  • Hi, Im using the above, and it works for me,
    What I added, in order to make the post slug work is this:
    While it works, I am not sure whether it is the best approach, seems to make the saving of a post very slow.

    add_action('save_post', 'set_slug');

function set_slug($post_id){
    $new_slug = get_post_meta($post_id,'custom-slug', true);    
    $post_args = array(
        'ID' => $post_id,
        'post_name' => $new_slug,
    );

    wp_update_post($post_args);
}

  • Hi @signalwarrant

    I don’t think saving the total to the database is a good thing to do. It can add loads to your database and make your site slow. Instead, you can create a function to calculate it like this:

    function totalMiles( $post_id ){
    $miles = get_field('miles', $post_id);
    $cars = get_field('cars', $post_id);
    
    return $cars * $miles;
}

    Then you can use it like this:

    echo totalMiles(698);

    If you still want to save it to the database, you need to do it with the acf/save_post hook and the update_field() function.

    I hope this makes sense 🙂

  • Hey, we found no solution or workaround..
    Splitted up the longest page to multiple WordPress-pages and aggregated the data on frontend then. Only saving changes is very slow, reading from DB not. 🙂

  • Hi @geert

    Hard to know where to start…

    Okay, so most people on the web with a WordPress site probably has shared hosting (I’m guessing). They have little to no control over the servers settings and limitations. Here’s some standard PHP values which are unlikely to be set higher in such shared hosting:
    http://php.net/manual/en/info.configuration.php

    disclaimer: I’m not gonna research everything here before (limited time) so some is a little bit of guesswork when it comes to numbers.

    max_input_vars there is one of the most interesting ones. Basically it says that PHP will accept a maximum of 1000 input fields to send to a single request (page load). In the case of WP admin that would likely be a POST request. WordPress per default already have quite a bit of fields for a standard edit screen. There’s a whole bunch of hidden fields as well as formats, categories, tags, featured image, title, editor, permalink, visibility, status etc. Let’s say you also have a few regular custom fields. Then you also add a repeater field to this. Each row might contain 2-10 fields + some hidden fields ACF uses to keep track of everything. Maybe you even have nested repeaters! So for each row there’s 2-10 fields + a nested repeater which in term contains 2-10 fields. And say you add in a gallery field there as well. That’s at the very least 1 field for each image.

    You’re quickly gonna find that you hit the 1000 input vars limit if you abuse repeaters. That’s gonna stop you from adding any new content to the page before you delete other. That in itself should be enough to reconsider huge repeater fields. But to make matters worse there’s also server limits like max_execution_time and max_allowed_packet (mysql). Saving all these fields will take some time and if you’re not on a great internet connection you may hit the max_excecution_time which will lead to your page save ending abruptly and unfinished. max_allowed_packet is a variable for mySQL which basically limits how large of data chunk you may insert in one go. It’s much harder to hit but it’s possible.

    If you’d be on a VPS you could prevent all of this by just upping your server stats. However you’ll still get a very slow admin experience and let’s face it, you’re patching a leaking boat and probably have to pay a hefty price for it (big servers aren’t cheap).

    Then there’s also the issue of WordPress database structure and the performance of WP_Query. 10up has written a great article on performance with WP_Query and one of the things to avoid is post meta lookup. Usually there’s no choice BUT we can at least do what we can to use simple post meta like a single date field or a boolean. And of course try to minimize the amount of post meta for each single post. https://10up.github.io/Engineering-Best-Practices/php/#performance
    Consider that ACF adds two rows to wp_postmeta for each field (both regular and sub fields).

    So if we can refactor our data structure to use a custom post type which would contain some fields and then perhaps link different posts/post types together with the post object or relationship field we’ll end up with safer and quicker admin requests, faster and often more versatile use of wp_queries in our front end and a better DB structure more fitting of WordPress strengths and weaknesses.

    It’s hard to say a number of repeater rows that’d be “too much” since it depends on what they contain. But for me, if I find that I’d end up with more than 20-30 row of simpler repeater data or 10-15 rows of more complex ones I would consider a different solution. Sometimes it’s hard to predict tho. We’ve had customers where they were supposed to use repeaters for just a few categories of Press media attachments but they ended up dumping soooo much media there that we eventually had to rebuild it for them with a CPT where each post was a single media file and a taxonomy for the categories of media.

    Hope that was a sufficient answer 🙂

  • Thanks for the recursive example–it was just what I needed. Here’s what I came up with that works with non-repeater fields and repeater subfields:

    add_filter('acf/update_value', 'my_acf_update_value', 10, 3);
function my_acf_update_value( $value ) {
	if (!is_array($value)) {
		$value .= ' added by filter';
		return $value;
	}
	$return = array();
	foreach ($value as $index => $data) {
		$return[$index] = my_acf_update_value ($data);
	}
	return $return;
}

    There’s still something not quite right as ‘ added by filter’ appears twice on the 2 repeater subfields and saving the page is appallingly slow even on my local server. For my purposes (removing cruft from pasting text from MS Word), I can tolerate running the filter twice, but I’d like to cut the redundancy if I can. Any suggestions?

Viewing 25 results - 1 through 25 (of 29 total)
1 2