Support

Account

Register Login

Home › Forums › Backend Issues (wp-admin) › All fields randomly disappearing in the backend

Solved

All fields randomly disappearing in the backend

  • Issue: our site has been running smoothly with ACF for over 1.5 years already. Since roughly one month, the custom fields in the backend disappear (very) randomly, both for pages and posts as well for custom post types. They do continue being displayed in the frontend though.

    Problem is, they aren’t even showing up in the screen option section at the top of the post (see screenshot).

    Things I’ve tried:
    -disabling all the plugins but ACF
    -changing theme
    -deleting/creating new field groups
    -assigning field groups to other custom post types
    -many other weird things that I can’t even remember now.

    What (sometimes) works:
    Sometimes, when I add a new field group or update any of the fields group, then they show up again, but for a random limit of time that can go for hours or days.

    When they are showing up, this is the debug I get through debug bar plugin.

    And this is when they disappear.

    As a side note, I’m using WordPress.com hosting. Got in touch with them regarding this issue, and they are more lost than I am.

    I’m really stressed and out of ideas, Any clue what might be happening or what can I try to find the source of the problem?

  • Are you seeing any JavaScript errors in console when they do not appear?

    Sorry, I can’t really give you a lot of help because I’ve never seen a site do this.

    My next step after looking for JS errors would be do disable any caching the server is doing like memecache shown in your post to see if that helps.

  • Are you using any ACF add on plugins? What are they? Does the disappearing of fields coincide with updating any of these plugins? Or with updating ACF?

  • Thanks for getting back.

    There are no javascript errors.

    Regarding memcache, I’ve all the plugins disabled, even cache ones. Where can I check this?

    We are on wordpress.com hosting

  • I’m using ACF Pro. I’ve not installed any extra addons, however I see that the repeater field is supposed to be an addon?

    One of the field groups has a repeater field. However when the fields are displaying, the repeater field is still enabled.

  • I have no idea. I have never worked with wordpress.com hosting.

    The reason I asked about other ACF addons is that I have run into some in the past that cause a premature initialization of ACF that in some cases could cause the issue that your are seeing. The order of plugin initialization can change based on plugin activation order and this includes when they are updated. So, if there is a plugin that is causing premature initialization this could change and seem random based on the last plugin that was updated/activated.

    Premature plugin initialization could also happen in the theme.

    Basically, premature ACF initialization can happen whenever an ACF function is called before the acf/init action. This action happens on the WP init action at priority 10. The order that init actions happen at a specific priority is based on when they are added, which is also a function of the order that the plugins are loaded which is a result of activation order. This does not happen with all ACF function calls. Basically if a function is called before ACF has been initialized and that function requires ACF to be initializes then ACF will try to initialize then, but there are some things that will not work if this happens too early.

    Most of the time when I’ve seen this happen it has been with plugins that add new ACF fields or modify existing ACF fields.

  • If you are using ACF Pro then you do not need the ACF repeater add on active. The repeater field in included in ACF Pro.

  • Thanks John, this explanation makes more sense. However, this still happens randomly when ACF is the only plugin active.

    How would you go to debug/solve this? Is there a way to do this via the init hook?

  • If this happens when the only plugin active is ACF then the condition I explained could only happen if there is something in the theme causing it. But you said you tried a different theme, so that would eliminate the theme, or should, unless you have 2 themes with the same issue.

    If you have eliminated other plugins and the theme then the only other cause would have to be server specific.

    Server caching like memcache could also be exacerbating the debugging problem. Depending on how long these types of caches last, not to mention your browser cache, you may not actually be seeing changes reflected when you refresh the page. When you are having issues it is important to be able to turn all such caching off so you can see what is actually happening. Again, I don’t know how to do this on the host you are using.

  • Hi John. I’ve disabled all caching and left only ACF activated, and the issue persists. Also tested with other themes, and same thing happens.

    Besides, this is backend related and not frontend, so I’m not sure how the theme would affect here?

    What seems to “fix” it almost everytime, is adding a new field group. But then again, after what seems to be a random number of hours/days, it stops working again.

    Having in mind what I’m doing to temporarily fix it, can you determine where the issue might be coming from? Or what else could I check?

  • It is possible to have filters and actions in the theme that effect the admin. Also any function. functions.php and any files that this file loads are loaded in the admin. But if you’ve tried other themes then this should be eliminated.

    I would say it could be a possible read issue if you are using local json, but since this requires having a folder in the theme folder, this should also be eliminated by changing themes.

    I honestly have not idea what could be causing your problem.

    At this point, if it were me, I would wait until it happens and then I would attempt to figure out why it’s not happening. I would do this by opening the main ACF file /plugins/advanced-custom-fields-pro/acf.php, and I would follow the code and find where the field group is and using echo, print_r and var_dump on variables in ACF I would see if I can figure out what’s going on.

  • I like that approach. Just tried cleaning the functions.php completely and that didn’t change things either.

    Do you know which line should I look at in acf.php?

    Is there a price if I find a bug? 🙂

  • I can’t say exactly where I’d start or how I would work through it.

    I would actually probably start in acf-field-group-functions.php in the function acf_get_field_groups() and then try to work either backwards or forwards in the code depended on what that function is getting.

    I would look into this myself if I had a site that was doing it, but I can’t debug something I can’t recreate.

  • Great news, I did some findings. At least just spotted where the problem is coming from and how to patch it.

    I did check acf-field-group-functions.php as you suggested, and after tracing the errors through the code I found out that when the fields are not showing up, $post_ids in acf_get_raw_field_groups() is returning an empty array, then the if statement at line 360 fails (see below).

    So changing the if statement like this did the trick
    if( $post_ids === false || empty($post_ids) ) {

    I’m not sure how wp_cache works, but I’ve read that “All cache-related work is made using instance of the WP_Object_Cache class. The cache data is saved to the memory (server RAM) during the page generation. But if you’re using a persistent cache plugin, the cache can be stored among page visits for a longer amount of time.”

    The cache plugin (FlyingPress) is currently deactivated when testing this, but it seems that the hosting (it’s WordPress.com hosting, from automattic) has memcache activated by default. This is what they told me regarding memcache:

    “Memcache cannot be disabled, it’s part of site infrastructure here and there’s no way to turn it off. It’s not possible to turn off memcache in our hosting environment (and honestly, I’m not sure why you would since it’s common on websites of all sorts, and I’ve never personally seen an issue with that)”

    TBH I’m not sure about these comments as I’m no cache expert by any means. But having this issue in mind and that this may be the case for other hosting platforms, is my solution feasible for future plugin updates?

    If not, how would you suggest fixing this permanently on my end? As future plugin updates will overwrite this line of code.

  • Looking past what the cache is returning, I would look at what could be causing the get_posts() query to return an empty array, because this is where the empty array in the cache is being set. This has to happen at some point before you see the fields disappear.

  • I do not know if this will work, it is purely a guess based on what I know

    
add_action('acf/init', 'check_acf_get_field_group_posts_cache', 20);
check_acf_get_field_group_posts_cache() {
  $cache_key = acf_cache_key("acf_get_field_group_posts");
  $post_ids = wp_cache_get( $cache_key, 'acf' );
  if ($post_ids !== false && empty($post_ids)) {
    // not false which should be returned for an empty cache
    // but empty, indicating an empty array
    // delete the cached value
    wp_cache_delete(acf_cache_key("acf_get_field_group_posts"), 'acf');
  }
}

  • It worked John! Thanks a lot for all the help, I’ve been troubleshooting this for over a month already.

    BTW, can you add the function tag to that function, just in case someone wants to copy and paste the solution?

    Looking past what the cache is returning, I would look at what could be causing the get_posts() query to return an empty array, because this is where the empty array in the cache is being set. This has to happen at some point before you see the fields disappear.

    Regarding your previous comment, I’m not sure to what line or file are you referring, but the line that’s returning an empty array is not get_posts(), it’s this one:

    $post_ids = wp_cache_get( $cache_key, 'acf' );

Viewing 17 posts - 1 through 17 (of 17 total)

You must be logged in to reply to this topic.