Home Forums Backend Issues (wp-admin) Custom fields get emptied when publishing


Custom fields get emptied when publishing

  • @pers & @mathias Gomig – after a considerable amount of searching, I finally figured out that this problem is being caused by the ‘load_field_defaults’ function in ACF’s core/fields/_base.php. The value is being saved and even being loaded without issue, but this function overwrites the value of the field with the default value. I’m not entirely sure why this is happening, but it’s definitely the culprit.

    To resolve the situation, simply override this function like so:

    function load_field_defaults( $field ) { return $field; }

    The field values are now displaying correctly for me on ACF 4.2.0.

    • PerS

    • August 10, 2013 at 8:56 am

    @flahertydaf Thank you!! This has been giving me a headache and you found the fix 🙂

    @eliot, you should remove “// Note: This function can be removed if not used” from {{field_name}}-v4.php

    • Elliot

    • August 10, 2013 at 11:01 am

    Hi @pers

    Looks more like the issue is that the developer of the 3rd party field may be adding ‘value’ as a default. This would then cause the load_field_defaults function to add in a blank value.

    The developer should remove this attribute from the defaults array of the field.

  • Hello, is this problem fixed now? I have still same problem.
    ACF plugin 4.2.1, ACF Datepicker plugin 2.0.9

    Must I change something in plugin source code?

    • Elliot

    • August 13, 2013 at 2:03 pm

    Hi @tomasjindrich

    Please read my previous comment

    • PerS

    • August 13, 2013 at 5:45 pm

    @elliot, @tomasjindrich. I’ve removed “value” from defaults in the latest release (2.0.10)

    • ChrisH

    • November 8, 2015 at 11:50 am

    I am running ACF v4.4.3 (standard, not pro) and was experiencing the same issue. I tried the fix proposed by flahertydaf:

    function load_field_defaults( $field ) { return $field; }

    to no avail.

    The problem was that I had cloned a field group, but even though the fields were given totally different names/slugs, the field values were not being saved to the DB.

    Deleting the cloned group and manually recreating those fields in a new group solved the issue.

Viewing 7 posts - 26 through 32 (of 32 total)

You must be logged in to reply to this topic.

We use cookies to offer you a better browsing experience, analyze site traffic and personalize content. Read about how we use cookies and how you can control them in our Cookie Policy. If you continue to use this site, you consent to our use of cookies.