Support

Account

Register Login

Forum Replies Created

  • This is NOT solved. Just updated to the 5.1.7.1 three months later to this one-word patch has not been applied to the live code…after a customer received 150 duplicate emails from our site. So though the problem is “solved” the code is not fixed.

    Why don’t you incorporate this one-word fix (posted above) into the code? If you would share the githib repo with @haroldkyle I would be happy to submit a pull request.

  • The first Woocommerce issue was likely unrelated to ACF Pro.

    The latter two popped up because acf_form_post::save_post() hooks onto ‘save_post’. This hook only fires if something changs on the post’s <i>main</i> fields. What this means, for example, if you change a field within an ACF metabox without changing anything else, this hook doesn’t fire. Instead, hook into ‘pre_update_post’. See this diff to solve this problem:
    http://pastie.org/9617141
    Here is a reference to this same problem in another plugin.

  • The fix I posted above was on the right track to hook into ‘pre_post_update’, but just went about it in the wrong way. I got a little spun around tackled the wrong save_post() method.

    So, there is one simple change to fix this problem on my installation, so please ignore my patchfile above. Here is a better patch which fixes the problem of subfields not saving on our installation.

    In short, hook acf_form_post::save_post() onto ‘pre_post_update’ instead of ‘save_post’.

  • Glad that worked for you. I’m pretty sure the issue I’m seeing is due to bugs in ACF PRO 5.0.8. I double checked the errors I described above, and would only add that the duplicate nonces are created because acf_admin_field_group::edit_form_after_title() uses the same key as the nonce in acf_input::acf_form_data(). This appears to be by design, because they both use the same nonce validation function, acf_verify_nonce(). This makes me think that the field-group nonce was not properly implemented, and should either be removed or rewritten to use a different nonce (which would affect the nonce verification as well).

    Anyway, since this isn’t up on Github yet, here is a patch [http://pastie.org/9611813] for those experiencing these issues. I removed the field-group nonce entirely until the dust settles. I also hook onto ‘pre_post_update’, then remove this action once it’s executed (to avoid a loop).

    UPDATE: Read below, don’t apply this patch.

  • I quickly looked under the hood and found a few things about my issue:
    – The ‘save_post’ hook isn’t firing when I update a Page. Not sure exactly why…documentation is slim even though this is a common problem…but perhaps we should hook the acf_admin_field_group::save_post() method to ‘pre_post_update’ instead?
    – The ‘field_group’ nonce can fail when there are multiple field groups. This writes multiple ‘_acfnonce’ hidden inputs to the page’s form. The last input value stomps the other nonce values (which don’t appear in the POST params). Perhaps the _acfnonce value should be keyed to each particular field group?
    I would be happy to contribute code to fix these issues if you give the thumbs up, Eliot.
    Hope that helps.
    Harold

  • I’m also experiencing the problem where page post types are not saving their ACF fields. These were migrated to Pro. I’m now running ACF 5.0.8 on WP 4.0.

  • I guess the problem I referred to was completely different then. All the code that caused the JS error was from the ACF plugin itself.

  • I spent some time trying to figure a similar issue out this evening. In my case, I saw the error “switchEditors is not defined” on the Edit Media page and wanted to figure out why. I’m running WP 3.8 and ACF 4.3.4.

    From the code it looks like ACF always inserts a WYSIWYG editor in the footer of any post page, including Media. Not sure why this needs to happen, but it’s added in acf_field_wysiwyg::input_admin_head, which appears to run with the ‘acf/input/admin_head’ action…regardless of whether or not a wysiwyg field is used on that page…and actually it appears regardless of whether or not there are any ACF elements that page. Not sure why this needs to be there…?

    Anyhow, there is inline onclick JS on the #acf_settings-tmce element which is the cause of the problem. When my user-settings in the options table specify the “html” editor then input.js fires off a click event to this element. The edit Media page doesn’t have switchEditors defined though, hence the error. When my user settings are for the “tinymce” editor, no error occurs, because input.js will not attempt to click the element. Otherwise, the only way to avoid this error is to deactivate ACF entirely.

    I hope this helps!
    Harold

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