Support

Account

Register Login

Forum Replies Created

  • @flightcreative that’s interesting. I haven’t checked it with latest version but might be something buggy. Hopefully not though or if it is, ACF team will fix it asap. They’re pretty quick with bugfixes

  • UPDATE

    Fixed myself. The problem was caused by the modification of the search using in admin using pre_get_posts. I would consider this a bug with ACF because if you modify pre_get_posts, ACF should still work.

    Anyway, I struggled with this issue for hours. Leaving this comment here for someone else who’s facing similar issues.

    Feel free to reply here if you get stuck; hopefully, I’ll respond soon.

  • @damontribble sorry for hijacking your thread. While @hube2 might be able to give better advice, I would also like to share my experience:

    I had to do exactly the same on one of the client’s sites where I had over 30+ layouts and growing. The saving of the ACF field group was painful and continuously breaking.

    I simply created 30 new field groups for each layout and moved the fields from each layout to their respective field group without changing their keys and names.

    This way, the actual ACF in the backend wasn’t touched and all the existing pages (over 300+) remained intact.

    I can provide more info if you need.

  • @hube2 hmm, I hoped there would be a default better alternative to this situation. But apparently, there doesn’t seem to be.

    In this situation, I do have an alternative which I used in the past to create tabs. It’s not ideal but for the sake of performance, I think it’s better.

    Will share my solution here after implementing it.

  • @hube2 I have already set the WYSIWYG fields to delayed init.

    Yes, that’s what I noticed the hidden clone layout is being copied multiple times which makes the HTML so big.

    What are your suggestions here? Is there any alternative to the repeater field that is better performance-wise?

  • @hube2 update, I just copied the HTML being generated for these fields https://share.cleanshot.com/5cWX8j is over 134000 lines (see: https://share.cleanshot.com/W3uG3X) – could that be the main reason of the problem?

    UPDATE:

    I also see that the clone fields HTML is actually being generated on the page here: https://share.cleanshot.com/b0hqeA – is that normal? Isn’t there a way that this HTML is only generated when you actually add the layout?

  • @hube2 I’m facing a similar challenge so I am posting my question here rather than opening a new thread.

    I am building a new using Flexible Content + Repeater Field. This is an example of the edit screen: https://share.cleanshot.com/5cWX8j. So we have a repeater field that holds the flexible content. The reason for using the repeater field is to act as a container wrapper in case the client wants to customize colors, backgrounds, etc. Then each of the sub section also has those similar options.

    I am also extensively using “clone” field so all the layouts in flexible content are cloned in different groups like this: https://share.cleanshot.com/FWZjcI

    While this is working perfectly in terms of functionality, I am facing a performance issue on the edit screen. It takes around 20 to 40 seconds to load the fields. However, once it’s loaded, I can easily edit the fields. The problem with this is that it becomes hard for me as well as the client to be able to edit something quickly.

    Is there anything I can do to improve the performance in some way? In the past, I know that when I didn’t wrap the repeater field around the flexible content, it worked better. However, that repeater field is quite important for styling and functionality part.

    Any help or right direction would be appreciated.

  • I accept this has a solution. After my last message, I checked a bit and the only way seemed was to actually read the JSON file stored in the plugin and get the field keys from there.

    But thanks for pointing out in the right direction with acf_get_field_groups() hint. I’m gonna check this out and probably will share my solution here if I could have one.

    Thanks a lot for the quick support!

  • 1) Yes, I first create the post and get the post ID. And then pass it down to the fields.

    2) Ah, that’s a good point. So you mean that if the fields do not exist, then we must use field key (e.g., field_1231231) instead of the field name (e.g., _products)? However, my client is how do I get the field key programmatically by providing the field name? if possible at all?

    Sorry, I confused field key with field name. Yes, field keys (e.g., field_123123) are unique throughout the site in all field groups. Only field names (e.g., _products) are being used in multiple field groups.

  • So I am also creating the post dynamically using wp_insert_post() WP function. Is it possible that during this creation, ACF somehow gets the reference of a different post/post type?

    1) the post ID is correct as it works for all other non-repeater fields.
    2) yes, you are right here. that’s what I mean, the key/post ID pair seems to be wrong in the database.

    As for the same key, so the repeater fields have same field key but they are showing on totally different post types. e.g., one repeater field with _products that has 6 sub-fields is showing on “post type A” and another repeater field with _products that has only 3 sub-fields is showing on “post type B”. So this should not be an issue.

  • @hube2 thanks for your response.

    Yes, I am passing the correct post ID in the update_row() function. It’s all happening in the backend using a webhook. I built a plugin to dynamically create posts and update ACF fields.

    So the problem occurred, when I duplicated the field group for “post type A” and renamed it for “post type B”. I ensured that the location is unique. Now, every time when the plugin dynamically creates a post in “post type A”, basically uses the repeater field from the “post type B”. This does not happen when I manually create a post from WP admin.

    I believe that because the field group for “post type B” was created later, update_row() is somehow picking the _products field key from “post type B” instead of the correct “post type A”.

    Here’s the code if it can help:

    
$images = isset( $data['images'] ) ? $data['images'] : array();
$post_id = isset( $data['post_id'] ) ? $data['post_id'] : '';
$swingline_id = isset( $data['swingline_id'] ) ? $data['swingline_id'] : '';
$acf_key = isset( $data['acf_key'] ) ? $data['acf_key'] : '';
$acf_repeater_key_values = isset( $data['acf_repeater_key_values'] ) ? $data['acf_repeater_key_values'] : '';
$row_index = isset( $data['row_index'] ) ? $data['row_index'] : 1;

$new_images = $this->helpers->upload_images( $images, $post_id, $swingline_id );

if ( ! empty( $new_images ) && is_array( $new_images ) ) {
	$acf_repeater_key_values['_images'] = $new_images;
}

$updated = update_row( $acf_key, $row_index, $acf_repeater_key_values, $post_id );

    I hope this helps to understand the problem. I really think it’s a bug which ACF devs should look into. I can help with more details if needed.

  • Update 2:

    Not for new trips either. Please note that I am using update_row() function to add to the _products field. And that is not working even for new trips which makes me believe that it’s a bug within update_row() or some internal functions.

    Please check and fix this asap as it’s affecting our work.

    Thanks in advance.

  • Update:

    This seems to be affecting the old posts. Not the new ones that I create. Which makes me believe if this has to do with the cache?? If yes, then why doesn’t ACF clear cache when a field group is updated?

    Or is there a way to clear the fields/ACF metadata cache of a post?

  • I tried above solutions, unfortunately, none worked out for me. When I used ‘OR’ in the first wp_query argument, it hung up the page.

    I ended up accidentally writing this code that solved the issue for me:

    'meta_query' => array(
    'relation' => 'OR',
    array(
        'key'     => 'date_start',
        'value'   => date( 'Ymd' ),
        'compare' => '=',
        'type'    => 'date'
    ),
    array(
        'relation' => 'AND',
        array(
            'key'     => 'date_start',
            'value'   => date( 'Ymd' ),
            'compare' => '<=',
            'type'    => 'date'
        ),
        array(
            'key'     => 'date_end',
            'value'   => date( 'Ymd' ),
            'compare' => '>=',
            'type'    => 'date'
        ),
    ),
)

    Gist for description: https://gist.github.com/842c14baeb42d33ce90d1d1bf7a5de68

    Not sure why the previous code didn’t work for me as the logic seems perfectly fine. I guess it’s just way to complex to be a query 🙂

  • Faced the same issue, i.e., upgrading from 4 to 5 didn’t show any ‘Upgrade Database’ message, but the solution provided by @thisislawatts worked flawlessly. Thank you!

  • Thanks @wube your solution worked great for me. I’ve expanded it a little bit more to have these option pages:

    – Global Options (options same for all languages, e.g., social profile links)
    – Options (EN) (options specific to English language)
    – Options (IT) (options specific to Italian language)
    …

    /**
 * ACF Options Page
 */

if ( function_exists( 'acf_add_options_page' ) ) {

  
  // Main Theme Settings Page
  $parent = acf_add_options_page( array(
    'page_title' => 'Theme General Settings',
    'menu_title' => 'Theme Settings',
    'redirect'   => 'Theme Settings',
  ) );

  // 
  // Global Options
  // Same options on all languages. e.g., social profiles links
  // 

  acf_add_options_sub_page( array(
    'page_title' => 'Global Options',
    'menu_title' => __('Global Options', 'text-domain'),
    'menu_slug'  => "acf-options",
    'parent'     => $parent['menu_slug']
  ) );

  // 
  // Language Specific Options
  // Translatable options specific languages. e.g., social profiles links
  // 
  
  $languages = array( 'it', 'en' );

  foreach ( $languages as $lang ) {
    acf_add_options_sub_page( array(
      'page_title' => 'Options (' . strtoupper( $lang ) . ')',
      'menu_title' => __('Options (' . strtoupper( $lang ) . ')', 'text-domain'),
      'menu_slug'  => "options-${lang}",
      'post_id'    => $lang,
      'parent'     => $parent['menu_slug']
    ) );
  }

}

    Gist: https://gist.github.com/zeshanshani/60bdf497bcae87bd3a8b03920cf64fc6

    And just like @philby mentioned, you can set an option group to show on all language specific option pages.

    Hope it helps someone looking for the complete solution. 🙂


    @alchemistics     I tried the plugin, it indeed works, but a bit buggy as in initial stages I assume. For example, when you select to show all languages, the options page is empty again so could confusing for normal users.

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