1

I have a custom post type "Properties". I have around 11,000 entries and each property has around 400 ACF custom fields. When I go to the Dashboard Properties page to edit them.. I get a blank screen. I thought maybe it was cause of the ACF fields, but why do the fields need to load on the listing page?

I detached the custom fields for testing (I did not delete the custom fields from the database) and it still gave me a blank page.

If I reduce the amount of posts in my CPT to just a couple thousand... it works. So what is actually loading when you load the listing page in the dashboard? I assumed it was just the post itself and not the meta data. Is this correct? If it's paginating why would it matter how many posts there are? I assume because there's so many posts with so much postmeta data that it's hitting a memory limit, but even on a dedicated server with 8GB of ram?

I'm not really running a ton of plugins, less than 10 and none are heavy duty besides ACF. Thoughts? This is driving me nuts.

EDIT: I found out on the listing page it's for sure trying to load all the postmeta for what ever reason even though it doesn't display it here. And that's causing it to use too much memory doing this for that many properties. Any way I can prevent that?

1

WordPress loads the meta values for all the posts in the current query in order to avoid performing an SQL query each time a post meta value is used. In almost all cases, this gives a huge performance benefit.

This pre-caching can be disabled (I'll get to that in a minute) but, unfortunately for you, storing 400 post meta fields against every post is going to cause you performance problems whether this cache is disabled or not. If you keep the pre-caching enabled, you'll see the memory issues that you're currently seeing. If you disable the pre-caching, you'll see an increase in the number of SQL queries performed when you do use those post meta fields (eg. in your theme).

So, on to disabling this pre-caching. It is controlled via the update_post_meta_cache query variable, which is set to true for all post queries by default. To disable it, you'll need to target the queries you're interested in and set it to false. Example:

function wpse_160203( WP_Query $wp_query ) {
    if ( 'property' == $wp_query->get( 'post_type' ) ) {
        $wp_query->set( 'update_post_meta_cache', false );
    }
}
if ( is_admin() ) {
    add_action( 'pre_get_posts', 'wpse_160203' );
}

This will prevent the pre-caching of post meta for the property post type in the admin area. If you want to do the same for the front end, simply remove the is_admin() conditional, but bear in mind you'll see a sharp increase in SQL queries and probably not much of a drop in memory usage if you actually start using those 400 post meta fields.

  • Thanks for this, this was the answer I was originally looking for. HOWEVER! I found another solution as well. I went through and ran a query to delete unused postmeta to start. The next thing I did was turn my ACF fields into PHP so it wouldn't have to hit the database to get all the different fields. Then I used W3 Total Cache to cache database and object calls. This seemed to help. I'm able to get what I need but I don't know what kind of impact it's making specifically, so far so good though! – paper_robots Sep 4 '14 at 22:02
  • The real question is why is WordPress NOT limiting the results as set in Screen Options (under "Number of items per page") which is usually set to 20? I use Query Monitor plugin for development and see that query is generated as "SELECT * FROM wp_posts ..." which is so bad... – mjakic Jan 19 '16 at 16:06

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.