Support

Account

Register Login

Forum Replies Created

  • The fix in 5.8.5 looks good. Code change looks like the content of $field_gruop['ID'] and $field_gruop['menu_order'] were explicitly cast as INT to prevent issues with later comparisons.

  • It looks like this is fixed in 5.8.5, as per patch notes at https://www.advancedcustomfields.com/blog/acf-5-8-5-release/

    *Release Date - 8 October 2019*

* New - Added new choice "Add" to the User Form location rule.
* New - Optimized acf_form() logic when used in combination with acf_register_form().
* Fix - Fixed bug causing incorrect field order after sync.
* Fix - Fixed bug reverting the first field type to Text in Firefox version 69.0.1.
* Fix - Fixed bug causing tinymce issues when changing between block modes.
* Fix - Fixed bug preventing block registration when category does not exist.
* Fix - Fixed bug preventing block registration when no icon is declared.
* Dev - Added RegExp compatibility for innerBlocks.

    I am currently downloading to verify.

  • It looks like this is fixed in the latest ACF release, as per patch notes:

    https://www.advancedcustomfields.com/blog/acf-5-8-5-release/

    *Release Date - 8 October 2019*

* New - Added new choice "Add" to the User Form location rule.
* New - Optimized acf_form() logic when used in combination with acf_register_form().
* Fix - Fixed bug causing incorrect field order after sync.
* Fix - Fixed bug reverting the first field type to Text in Firefox version 69.0.1.
* Fix - Fixed bug causing tinymce issues when changing between block modes.
* Fix - Fixed bug preventing block registration when category does not exist.
* Fix - Fixed bug preventing block registration when no icon is declared.
* Dev - Added RegExp compatibility for innerBlocks.

    I am currently downloading to verify locally.

  • FYI we are also still seeing this issue, and we can confirm that the codefix provided by @jewella works.

  • We can confirm that this issue is also occurring for us on ACF 5.8.3. We performed the following patch to /advanced-custom-fields-pro/includes/acf-field-group-functions.php:1029:

    
/**
 * 20190809 MONKEYPATCH
 * There is a bug causing fields to lose their ordering specified in the local-json files.
 * The fix below addresses this until Elliot releases a fix.
 * See: https://support.advancedcustomfields.com/forums/topic/flexible-content-fields-with-local-json-save-out-of-order/
 */
//             // Add field menu_order.
//             if( !isset($count[ $field['parent'] ]) ) {
//                 $count[ $field['parent'] ] = 1;
//             } else {
//                 $count[ $field['parent'] ]++;
//             }

//             // Only add menu order if doesn't already exist.
//             // Allows Flexible Content field to set custom order.
//             if( !isset($field['menu_order']) ) {
//                 $field['menu_order'] = ($count[ $field['parent'] ] - 1);
//             }
/**
 * 20190809 BEGIN FIX FROM
 * https://support.advancedcustomfields.com/forums/topic/flexible-content-fields-with-local-json-save-out-of-order/
 */
            // Add field menu_order.
            if ( ! isset( $field['parent_layout'] ) ) {
                if ( ! isset( $count[ $field['parent'] ] ) ) {
                    $count[ $field['parent'] ] = 1;
                } else {
                    $count[ $field['parent'] ]++;
                }
            } else {
                if ( ! isset( $count[ $field['parent_layout'] ] ) ) {
                    $count[ $field['parent_layout'] ] = 1;
                } else {
                    $count[ $field['parent_layout'] ]++;
                }
            }

            // Only add menu order if doesn't already exist.
            // Allows Flexible Content field to set custom order
            if ( ! isset( $field['parent_layout'] ) ) {
                if ( empty( $field['menu_order'] ) ) {
                    $field['menu_order'] = $count[ $field['parent'] ] - 1;
                }
            } else {
                if ( empty( $field['menu_order'] ) ) {
                    $field['menu_order'] = $count[ $field['parent_layout'] ] - 1;
                }
            }
/**
 * 20190809 END MONKEYPATCH
 * https://support.advancedcustomfields.com/forums/topic/flexible-content-fields-with-local-json-save-out-of-order/
 */

    We can confirm that this is the same thing posted by @hube2, and that it fixed the issue for us. Hopefully this information is helpful in developing a permanent fix, or to others who are testing the issue.

  • I actually ended up going in a different direction. Since I only needed one post to be the Related post, I changed the field type from Relationship to Post Object. From here, when the page loads with the aforementioned query tags, I use javascript to set the value of #acf-field_<number>-input field to the post_id of the parent. Then, when saving, it properly sets the parent post.

    This is a bit hackish, but does what I need it to.

  • It might be easiest to do this by using JavaScript to check the state of a form, and hide/show certain form elements depending on what the state is.

  • I was able to get around the issue I’d encountered by simply only referring to files actually being saved to the post, instead of files associated with the post.

  • My final solution ended up being as you suggested, and I have it fire on save_post. Basically when the post saves, it checks for the state of the two conditional objects. Depending on what’s set for those two conditionals, it does a check against each of the fields that could have data in them, and if it’s present, clears the data from that ACF Field, and then deletes the object term relationship via WordPress directly.

    It appears to be working fine so far!

  • So I’ve come down to this essentially.

    When updating an ACF taxonomy field with update_field( "field_ID", "", $post_id) in order to clear the field, it does NOT remove the taxonomy association in the wp_term_relationships table.

    This is with the Field Type set to Taxonomy, and the following checked:

    Save Terms: Yes
    Load Terms: Yes

    Is there a way to unset the taxonomy field association on update_field? Currently I know what field I want to update and the applicable taxonomy, so I can use wp_delete_object_term_relationship against the given $post_id, but it would be nice if update_field took care of this for me.

  • Yea, we’re likely going to add an action to “save_post” to clean up this post type on save.

    Thanks again for your assistance.

  • Totally understand the logic behind it, and agree that the current in-place implementation works as intended! I’ll work on coding a front-end fix that pulls depending on the Grade and Standard selected for the post, instead of just polling every single taxonomy in the post_meta.

    Thank you for the quick follow up.

  • I believe what Joel is pointing out is that the ACF-JSON updates on EVERY save of an ACF field, including sync. Since saving a Sync creates a new date-timestamp, this becomes the new master when pushed up to Git, and then everyone else Syncs, creating new date-timestamps, and then it’s turtles all the way down.

  • Thanks, that did it!

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