Support

Account

Home Forums Backend Issues (wp-admin) Found root cause for fields not saving (using ACF PRO 5.0.8)

Solving

Found root cause for fields not saving (using ACF PRO 5.0.8)

  • Dear support,

    After a few days with my site in “read-only mode” due to the upgrade to v5.0.8 and after a lack of news from support via email (which I am very disappointed about), I have been working on my own to understand why custom field values didn’t get created or updated.

    After a lot of debugging, I found out that the DB upgrade logic from v4.x and the custom queries do not seem to match. In summary, the function wp_posts_where in acf.php seems to be looking for field names in the wrong column of wp_posts, thus returning zero rows and not validating the field (not updating it’s value to the one provided in any form field). Changing the name to the right column does the trick for me.

    For example, field names are searched for in the post_excerpt column, when they are (at least in my case) in the post_name column. This means that either the upgrade put things in the wrong place or the code needs to be upgraded.

    I will appreciate if you can take a look at this and officially fix it as soon as possible. Count on my feedback whenever it is required.

    All the best,
    Hector

  • I too am having this exact same problem.

  • I had a similar problem, but it was not only on upgraded fields ; but also on new created fields ; nothing saved.

    I found that it was the post_name which cause problem.
    — post_excerpt is a readable slug
    — post_name is a string starting with “field-”

    If I change post_name to start with “field_” ; I was able to save my data.
    I just run this SQL query and everything seems to work :

    UPDATE wp_posts SET post_name = CONCAT( 'field_', SUBSTR( post_name, 7 ) ) WHERE post_type = "acf-field" && post_name LIKE "field-%"

  • After some tests, I realize that in group fields, ACF create fields named “field_***” (used for post_name) but after saving post_name become “field-***”.
    The reason is that wp_insert_post() (used for creating field) sanitize post_name with sanitize_title function (check wp-includes/post.php on line 3189).

    To prevent this, I have to add a filter to return original post_name.
    In advanced-custom-fields-pro/api/api-field.php, I add in function acf_update_field() on line 839 :
    add_filter( 'sanitize_title', 'acf_update_field_sanitize_title', 100, 3 );
    just before :
    $field['ID'] = wp_insert_post( $save );
    and remove that filter just after saving :
    remove_filter( 'sanitize_title', 'acf_update_field_sanitize_title', 100 );

    And after acf_update_field :

    function acf_update_field_sanitize_title ( $title, $raw_title, $context ) {
        return $raw_title;
    }

    It seems to work for me…

    Note :
    if you don’t want to alter ACF sources, you can add this to your functions.php :

    function acf_update_field_sanitize_title ( $title, $raw_title, $context ) {
      return $raw_title;  
    }
    
    // add filter for sanitize_title
    add_filter( 'acf/update_field', function ( $field ) {
      add_filter( 'sanitize_title', 'acf_update_field_sanitize_title', 100, 3 );
      return $field;
      }, 10, 1 );
    
    // remove filter for sanitize_title
    add_filter( 'wp_unique_post_slug', function ( $slug, $post_ID, $post_status, $post_type, $post_parent, $original_slug ) {
      remove_filter( 'sanitize_title', 'acf_update_field_sanitize_title', 100 );
      return $slug;
      }, 10, 6 );
  • It seems that the problem is linked to a custom filter I added to sanitize_title that doesn’t allow underscores and convert them to dashes.

    The problem is that ACF checks for field key to be like “field_***” (function function acf_is_field_key() in api/api-field.php) ; so if the field key is “field-***”, it doesn’t work.

    Another solution is to activate local JSON so your field key can be what you want. Just create a folder name acf-json on your theme folder and re-save your field group.

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

You must be logged in to reply to this topic.