Support

Account

Register Login

Home › Forums › Search › Search Results for 'custom fields not saving'

Search Results for 'custom fields not saving'

reply

  • Follow-up on my last post and the mysterious “Enter a URL” message. I scanned my entire codebase and could not find that phrase anywhere, so on a hunch I investigated whether it might be a browser-specific issue, and it appears to be. I’m getting the “Enter a URL” error that is preventing saving in Safari; but if I edit the exact same page in Chrome, it works. Then if I open the page — now containing my # URL — in Safari and try to save without any changes, it fails with the same “Enter a URL” message again.

    It seems to be a browser-specific handling of the new HTML5 <input type="url"> field. Is there a way to customize the pattern attribute for URL fields in ACF? If so I haven’t seen it anywhere.

  • Hi everyone,
    just wanted to chime in and tell you that I’ve managed to use ACF with innerblocks. My use case is a “Text” Block which wrapps all other textish blocks (paragraph, heading, list) for a common wrapper (container, margins/paddings – all design reasons).
    I’m using this helper methods and the editor.BlockEdit und blocks.getSaveElement hooks to overwrite the save & edit components of acf blocks. You can see it in this gist.

    It’s kinda hacky, works only until ACF 5.8.2 (have to find out what’s breaking it in 5.8.3). But with mode set to preview, the fields only showing in the sidebar and some styling I managed to get it working for editors/normal users.

    I’m also working on adding custom fields to core blocks – have a proof of concept which adds fields to core/paragraph but not saving correctly atm. If anyone wants to help/the code I’ll set it up as a github repo.

  • Reposting:

    Not sure this will help anyone else, but after trying nearly all of the fixes I found in this forum and elsewhere (none worked), I was able to come up with one that worked in my situation.

    I, too, was not seeing any content populated in the page editor ACF fields as location-related to two templates I had on various sites. And no data was being saved if I tried to enter it into the ACF page editor fields.

    While troubleshooting, I noticed in reviewing the ACF field settings in Custom Fields>Field Groups>(item)Field Name, I was getting <p></p> tags within the field every time I saved the ACF Field Groups settings even though I deleted the tags prior to saving.

    Remembering that the TinyMCE Advanced plugin has an option for keeping paragraph tags within the text editor, I tried disabling TinyMCE to see if it would get rid of the paragraph tags. It didn’t, but I had forgotten that I also had the TinyMCE Excerpt plugin installed. So I disabled that and VOILA! The paragraph tags disappeared after saving the field settings again, and my ACF metaboxes were populated and editable again in the page editor.

    So even if this was also the case for you, disabling all of your plugins (including TinyMCE), would not have produced any successful outcomes unless you then went into your Field Groups settings and updated all of the Field Names to remove extraneous tags.

    I spent an entire day trying to fix this. If it helps one person, it will be worth posting it here.

  • Not sure this will help anyone else, but after trying nearly all of the fixes I found in this forum and elsewhere (none worked), I was able to come up with one that worked in my situation.

    I, too, was not seeing any content populated in the page editor ACF fields as location-related to two templates I had on various sites. And no data was being saved if I tried to enter it into the ACF page editor fields.

    While troubleshooting, I noticed in reviewing the ACF field settings in Custom Fields>Field Groups>(item)Field Name, I was getting <p></p> tags within the field every time I saved the ACF Field Groups settings even though I deleted the tags prior to saving.

    Remembering that the TinyMCE Advanced plugin has an option for keeping paragraph tags within the text editor, I tried disabling TinyMCE to see if it would get rid of the paragraph tags. It didn’t, but I had forgotten that I also had the TinyMCE Excerpt plugin installed. So I disabled that and VOILA! The paragraph tags disappeared after saving the field settings again, and my ACF metaboxes were populated and editable again in the page editor.

    So even if this was also the case for you, disabling all of your plugins (including TinyMCE), would not have produced any successful outcomes unless you then went into your Field Groups settings and updated all of the Field Names to remove extraneous tags.

    I spent an entire day trying to fix this. If it helps one person, it will be worth posting it here. Good luck!

  • Not sure this will help anyone else, but after trying nearly all of the fixes I found in this forum and elsewhere (none worked), I was able to come up with one that worked in my situation.

    I, too, was not seeing any content populated in the page editor ACF fields as location-related to two templates I had on various sites. And no data was being saved if I tried to enter it into the ACF page editor fields.

    While troubleshooting, I noticed in reviewing the ACF field settings in Custom Fields>Field Groups>(item)Field Name, I was getting <p></p> tags within the field every time I saved the ACF Field Groups settings even though I deleted the tags prior to saving.

    Remembering that the TinyMCE Advanced plugin has an option for keeping paragraph tags within the text editor, I tried disabling TinyMCE to see if it would get rid of the paragraph tags. It didn’t, but I had forgotten that I also had the TinyMCE Excerpt plugin installed. So I disabled that and VOILA! The paragraph tags disappeared after saving the field settings again, and my ACF metaboxes were populated and editable again in the page editor.

    So even if this was also the case for you, disabling all of your plugins (including TinyMCE), would not have produced any successful outcomes unless you then went into your Field Groups settings and updated all of the Field Names to remove extraneous tags.

    I spent an entire day trying to fix this. If it helps one person, it will be worth posting it here.

  • Incase it’s useful to anyone looking. I troubleshooted this issue down to a specific behavior in my project.

    The bug
    In a plugin I was authoring, I called get_field on repeater too early which caused a whole host of problems with ACF including the repeater field returning only it’s count as a string, and data seemingly not saving to the repeater when pressing the Update button.
    (in reality, ACF was saving the edits properly to the database but displaying an empty repeater in the post editor as a result of this error).

    The solution was to hook my ACF-dependent logic to the acf/init action instead found here:
    https://www.advancedcustomfields.com/resources/acf-init/

    Without hooking into acf/init, you would expect PHP to throw a fatal error and say get_field() is not a function in this case, but that didn’t happen.

    I’m thinking get_field() was being called in some intermediary matter– after the get_field() function was registered, but before other functions in its call stack were available– resulting in a half-baked instantiation for that particular repeater’s data.

    ¯\_(ツ)_/¯.

  • Not sure if this is the same problem I’m experiencing, but fields that I defined using the acf_add_local_field function are also not saving on my custom post types?

    I’m running:

    • WordPress Version 5.2.2
    • ACF Pro Version 5.8.2
    • Classic Editor Version 1.5

    Gutenberg editor is disabled.

  • Sorry to dredge this up again; I wanted to share some code I wrote that may benefit others who find this question. I was looking for a solution a bit lighter than the suggested plugin and a bit more user-configurable than John’s (excellent) solution above, and came up with the following.

    I used a lot of PHP7+ syntax here—you may need to do a little translating if you’re running a lower version on your server!

    
new acf_custom_json_save_path_setting();

class acf_custom_json_save_path_setting {
    // This will store the preferred save path for the group for later retrieval.
    private $preferred_save_path;

    public function __construct() {
        // Add the "JSON Save Path" setting to all field groups.
        add_action('acf/render_field_group_settings', [$this, 'add_json_save_path_setting']);

        // Call an early bird (priority 1) action before saving the field group.
        add_action('acf/update_field_group', [$this, 'set_up_save_path'], 1, 1);
    }

    public function add_json_save_path_setting($field_group) {
        // Create our custom setting field with the specified options.
        acf_render_field_wrap([
            'label'        => 'JSON Save Path',
            'instructions' => 'Determines where the field group\'s JSON file will be saved, relative to the active theme\'s directory.',
            'type'         => 'text',
            'name'         => 'json_save_path',
            'prefix'       => 'acf_field_group',
            'prepend'      => '/',
            'placeholder'  => 'Use default path',
            'value'        => $field_group['json_save_path'] ?? '',
        ]);
    }

    public function set_up_save_path($group) {
        // Get the preferred save path, if set.
        $preferred_save_path = $group['json_save_path'] ?? null;

        // If not set (or set to an empty string), do nothing.
        if (!$preferred_save_path) {
            return $group;
        }

        // Set aside the preferred path and add an override action.
        $this->preferred_save_path = get_stylesheet_directory() . "/$preferred_save_path";
        add_action('acf/settings/save_json', [$this, 'save_to_preferred_save_path'], 9999);

        // Return the group for updating as usual.
        return $group;
    }

    public function save_to_preferred_save_path($path) {
        // Ensure this field group is saved to the preferred save path.
        $path = $this->preferred_save_path;

        return $path;
    }
}

    The code above will add a simple “JSON Save Path” text field to each field group’s Settings section, in which you can enter a path where you’d like to save the group’s JSON file. The path is relative to the active theme’s directory (I felt like that was a safe default), but you can use standard directory traversal methods like ../ to go up a few levels if you’re, say, trying to save something to a plugin directory.

    And as a reminder, this code doesn’t do anything to load from your custom save points. I looked into it, but ensuring the array of load points always has the correct paths in it gets complicated quickly. Thankfully, it’s very simple (and much more transparent) to manage your load points manually via the acf/settings/load_json filter.

  • Sorry to dredge this up again; I wanted to share some code I wrote that may benefit others who find this question. I was looking for a solution a bit lighter than the suggested plugin and a bit more user-configurable than John’s (excellent) solution above, and came up with the following.

    I used a lot of PHP7+ syntax here—you may need to do a little translating if you’re running a lower version on your server!

    
new acf_custom_json_save_path_setting();

class acf_custom_json_save_path_setting {
    // This will store the preferred save path for the group for later retrieval.
    private $preferred_save_path;

    public function __construct() {
        // Add the "JSON Save Path" setting to all field groups.
        add_action('acf/render_field_group_settings', [$this, 'add_json_save_path_setting']);

        // Call an early bird (priority 1) action before saving the field group.
        add_action('acf/update_field_group', [$this, 'set_up_save_path'], 1, 1);
    }

    public function add_json_save_path_setting($field_group) {
        // Create our custom setting field with the specified options.
        acf_render_field_wrap([
            'label'        => 'JSON Save Path',
            'instructions' => 'Determines where the field group\'s JSON file will be saved, relative to the active theme\'s directory.',
            'type'         => 'text',
            'name'         => 'json_save_path',
            'prefix'       => 'acf_field_group',
            'prepend'      => '/',
            'placeholder'  => 'Use default path',
            'value'        => $field_group['json_save_path'] ?? '',
        ]);
    }

    public function set_up_save_path($group) {
        // Get the preferred save path, if set.
        $preferred_save_path = $group['json_save_path'] ?? null;

        // If not set (or set to an empty string), do nothing.
        if (!$preferred_save_path) {
            return $group;
        }

        // Set aside the preferred path and add an override action.
        $this->preferred_save_path = get_stylesheet_directory() . "/$preferred_save_path";
        add_action('acf/settings/save_json', [$this, 'save_to_preferred_save_path'], 9999);

        // Return the group for updating as usual.
        return $group;
    }

    public function save_to_preferred_save_path($path) {
        // Ensure this field group is saved to the preferred save path.
        $path = $this->preferred_save_path;

        return $path;
    }
}

    The code above will add a simple “JSON Save Path” text field to each field group’s Settings section, in which you can enter a path where you’d like to save the group’s JSON file. The path is relative to the active theme’s directory (I felt like that was a safe default), but you can use standard directory traversal methods like ../ to go up a few levels if you’re, say, trying to save something to a plugin directory.

    And as a reminder, this code doesn’t do anything to load from your custom save points. I looked into it, but ensuring the array of load points always has the correct paths in it gets complicated quickly. Thankfully, it’s very simple (and much more transparent) to manage your load points manually via the acf/settings/load_json filter.

  • More than likely you are updating the field and then ACF is overwriting it with the submitted value. acf/update_field is called when the field is being updated. So the other field has probably not been updated yet when you update it.

    You need to use an acf/save_post filter and do all the work after ACF has finished saving the post https://www.advancedcustomfields.com/resources/acf-save_post/

    or you need to update the $_POST[‘acf’][$field_key] value of the field you want to change.

    
function save_post_functions( $post_id ) {
  $my_post = array();
  $my_post['ID'] = $post_id;
  if ( get_post_type( ) == 'artists') {
	$artist_name = get_field('artist_name');
	$artist_sort = get_field('artist_sort');
		
	$name_sort = name_sort($artist_name);
	if (substr_count($name_sort,'%')>0) { $name_sort = $artist_name; }
        if (isset($_POST['acf']['field_XYZ123'])) { // replace with your field key
          $_POST['acf']['field_XYZ123'] = $name_sort;
        } else {
	  update_field('artist_sort',$name_sort,$post_id);
        }
		
  }
}
add_action('acf/save_post', 'save_post_functions', 20);

  • You are using WP all import, as I said, if you have the ACF extension for this plugin then it will handle the import for you and then there is no need to call any ACF function.

    If you want to do this yourself then update_field() https://www.advancedcustomfields.com/resources/update_field/ would be used, just like any other field. Make sure to read the important notes about using the field key vs. the field name when updating fields that do not exist. The value for using this function would be a value that matches what ACF normally stores in the database. In the case of a GM field it would be an array. Exactly what needs to be in the array I can’t really answer, I’ve never used a GM field or needed to update them if I did. You can figure this out by saving a value to a map field and looking at the value that is stored in the database, or you can run a test on the front end of the site.

    
echo '<pre>'; print_r(get_field('your-field-name', false, false)); echo '</pre>';

  • Situation & Problem
    I’m implementing a custom admin page that gets ACF fields based on a selection.
    Everything is working fine, including the showing and saving of the fields.

    However, after a field is loaded using Ajax, certain JavaScript functionalities are not working:

    • In a repeater field, the add row button does nothing, it also shows nothing in the console when clicked.
      According to my browser a click event IS bound to it from acf-input.js:
      return a.apply(b || this, c.concat(e.call(arguments)))
    • In a wysiwyg field, the Visual button does not work. When clicked it shows the following error in the console: TypeError: r is undefined [tinymce.min.js]

    Am I maybe supposed to perform a JavaScript call to initialise the newly loaded fields? Or is there something wrong with my implementation of ACF?

    Info on my implementation
    Initial page load
    On initial page load I run acf_enqueue_scripts(); to load all ACF scripts/styling.

    Getting fields with Ajax
    On the page when a selection is made, an Ajax call is made to a custom route which performs the following to get the fields HTML:

    
// get fields based on group key received from POST request
$fields = acf_get_fields(['key' => $key]);

// render fields, and use output buffering to catch the HTML
ob_start();
acf_render_fields($fields, 'my-page');
$fields_html = ob_get_contents();
ob_end_clean();

return $fields_html;

    Which successfully returns the required HTML to the page.

    Saving Fields
    I very simply perform a POST with all the fields to a route which performs the acf_save_post('my-page') function.
    This function gets the fields from the request and saves them, which works wonderfully.

  • Well, forget about when i said “working ok”…

    The first field that was saved is a textfield into a group displayed on pages. This one SAVE on page update using gutemberg.

    The second field is a textarea inside a flexible field inside a group. This one NOT SAVE on page update.

    If i use another flexible field, with a select, it was SAVED on update page.

    Those same flexible fields are used also on a custom post type that do not use gutemberg, on those, fields save normaly. Something when using gutemberg for sure, right?

    So… i don´t know, for now i can see something with textareas/text fields on flexible fields not saving with gutemberg.
    Anybody can check something like this situation? Test with diferent field types.

  • Hey guys, some more data:

    Yesterday i installed a new site i´ve started to develope, same WP 5.0.2, same ACF 5.7.9, same Parent theme i use for all my projects…. and, when i went to some page (first edited one on fresh install) my custom fields where saved, and in fact is working.

    It´s very strange, on the old websites, where i updated WP from 4.9 to 5.0, this thing about gutemberg and saving fields don´t work. But with same versions installs from zero yes they work. JS Cache problems are not the issue for sure.

    I was clear? new installs works, updated ones not.

    At least that´s my last experience related to this. Hope helps to find what is going on.

  • See this https://www.advancedcustomfields.com/resources/limit-number-fields/

    Also, ACF can time out when there is too much data to be saved. This depends not only on the number of fields but what’s in those fields and how many queries need to be accomplished to do the saving. There is no fix for this. I suspect this may be part of the problem if you’re getting a blank page.

  • Hi, nop, i couldn´t solve the problem using WP 5.0. The only way is to install the Classic Editor plugin, so guttemberg editor will be disabled.

    When guttemberg is enabled, pages, posts, etc, having custom groups/fields, do not save the changes when pressing “publish”. The new content on those fields do not disappear, but if i leave editor and return, no changes saved.

    I guess is something when guttember saves data (js), well, it´s not saving for some reason, thats´s the problem.

  • This code is un-tested as of now, but your best bet would be to use the acf/save_post hook, most likely:

    function merge_post_values($post_id) {
    if (empty($_POST['acf'])) {
        return;
    }

    // Run some logic to determine whether or not the current post is
    // correct -- for example, based on the ID, template, post type, etc.
    if ($post_id == 1) {
        $merged_values = [];

        if (isset($_POST['value_1'])) {
            $merged_values[] = $_POST['value_1'];
        }

        if (isset($_POST['value_2'])) {
            $merged_values[] = $_POST['value_2'];
        }

        update_post_meta($post_id, 'merged_values', $merged_values);
    }
}

add_action('acf/save_post', 'merge_post_values', 1);

    I’ve not included any sanitation and I’m not entirely sure how your structure is setup (for example, if the values are strings, arrays, so on), or how they need to be saved, but the above should be enough of a premise to work on for saving the values as a separate piece of post meta.

  • I have managed to show ACF field on “Add Product” page for WC Vendors.

    This is the code I have got from WC Vendor’s support forum.

    and just bit of modification in the hook, instead of add_action(‘wcvendors_settings_after_shop_name’, ‘wcv_save_acf_fields’); hook I used add_action('wcvendors_after_product_form' to save the form. and to display field original code : add_action(‘wcvendors_settings_after_seller_info’, ‘wcv_add_acf_fields’); and I have replaced it with add_action('wcv_after_product_details' to display it on Add product page. The full code is below:

    /*
 *- Courtesy of Ben Lumley -
 * https://www.wcvendors.com/help/topic/howto-add-acf-fields-to-frontend-shop-edit/
 *
 * https://docs.wcvendors.com/knowledge-base/adding-advanced-custom-fields-acf-support/
 *
 * This will display + save any custom fields applicable to the vendor_shop in question.
 * Second one displays the fields, you can adjust the action it’s attached to in order
 * to move the fields (see templates/dashboard/store-settings.php in the pro plugin for
 *  possible actions). You could also split and display different fields in different
 * places – see the docs for acf_form, you can select single/groups of fields.
 * http://www.advancedcustomfields.com/resources/acf_form/
 * Also possible via acf_form to alter the markup a bit to make it fit your theme.
 *
 * This code is not supported by WC Vendors, use at your own risk and at your own discretion.
*/

add_action('wcvendors_after_product_form', function () {
    acf_form_head();
});

add_action('wcv_after_product_details', function () {

    acf_form(
        [
            'post_id' => 'user_' . get_current_user_id(),
            'form' => false,
            'return' => false
        ]
    );

});

    the field shows now, but the problem is it’s not saving the ACF value. any idea why it is not saving 🙁

  • When using the seamless and you include the same fields multiple times at the same level the fields will have the same field names and they are at the same level. Not only will you have trouble with conditional logic, you will also have trouble saving the data in the fields, since they both have the same name the saving of the 2nd, 3rd, etc fields will overwrite the previous values. In essence you only have one field shown multiple times. Seamless is meant for reusing the fields in a repeater or flex field where they already have some protection.

    When grouped they work more like the sub fields of a repeater or flex field. The field names are prefixed, the fields have parents, and this prevents the issues.

    This is all explained in the clone field documentation. See Limitations and Notes near the bottom of the page. https://www.advancedcustomfields.com/resources/clone/

  • Since you are using the layout custom field, you should probably also take a look at this post…

    php-input-variables-exceeded-1000

    On complex field groups it is possible for the number of form variables submitted to exceed your web server’s maximum number of allowed variables per post. This happened to me on what seemed like a field group that wasn’t all that big. But once you start repeating layouts, the number of inputs can become quite large.

    Until the developers start using a different method of saving data (like I suggested in my post) you will either have to change the configuration of your web server (not always possible on shared web hosting) or figure out a different way to do it.

  • The answer to the question is, yes, this could be done, because you will have one Staff taxonomy field that matches each Role.

    Using this filter https://www.advancedcustomfields.com/resources/acf-fields-taxonomy-query/ for each field.

    ACF uses get_terms() https://developer.wordpress.org/reference/functions/get_terms/

    Get terms supports meta queries https://developer.wordpress.org/reference/classes/wp_term_query/__construct/

    So, when getting the staff terms you can use the ACF filter to only return staff members that have a specific taxonomy set by using a meta query on the role field.

    However, you will still have a problem adding new staff members on the fly. The reason is that a new staff member will not have the correct roles set. This means that after saving the post the same staff will not be found for that role so it will not be displayed or selected.

    To correct this you will need to create an acf/update_value filter for each field https://www.advancedcustomfields.com/resources/acf-update_value/

    The update value filter will not alter the value. What the update value filter will do is add the new staff member to the correct role. You will need to look at the value, get the selected terms and then look at each term to see if it has the needed role. If it does not then you would use the update_field() function to alter the ACF field associated with the staff term to add the role.

  • The problem here, I think, is that you’re attempting to update a field that does not exist when you’re trying to update it. Try using the field key instead of the field name. https://www.advancedcustomfields.com/resources/update_field/ the field key should always be used when saving values that are new.

    Also set the priority > 10. ACF uses the same hooks to update fields that we use and it uses the default priority of 10. If for some reason ACF runs after your filter then it will overwrite whatever you update the field to.

    The final issue could be using the draft_to_publish hook. I don’t know the details this hook, when it is called or how it works. It could be possible that whatever values you’re trying to get to update the value of your field don’t exist, but you said that “all codes in the function are run without error (this is tested and verified)” so I’m guessing that this isn’t the problem.

  • 1) Display of taxonomy fields is covered here https://www.advancedcustomfields.com/resources/taxonomy/. You can’t use the_field() with this type of field.

    2) You need can use tax_query if you are saving and loading terms. Otherwise you need to use meta_query. For the meta_query you need to search for the Term ID in a like query. See this page https://www.advancedcustomfields.com/resources/query-posts-custom-fields/ 3. Multiple custom field values (array based values). In this case the values to look for will be LIKE "'.$term_id.'"', note the quote marks (“) around the term ID.

    3) Not sure what you are looking for on this
    ...How do I get the field displayed as a inputable dropdown on the front end...

  • Some common reasons for not saving

    ACF will only save to the acf-json folder of the current theme. For example you can’t write to the parent theme of a child theme unless you set up a custom save location. Also, ACF will not load json files from the parent theme unless a custom load point is added https://www.advancedcustomfields.com/resources/local-json/

    This folder needs to have permissions set to that it can be written to.

    If you are creating a theme that will use a child theme then the best practice would be to do all ACF work in the parent theme and set a custom load point to load json files from the parent theme.

  • Hi John,

    thank you so much for your quick reply.

    Writing a theme is as with every other software project: It grows and can become a “monster” (Thinking of Lehman’s Laws …). I get what you are saying and it was never intended to be this big. Requirements change over time and that can become difficult.

    So the best bet would be to rebuild the logic of my theme.

    There seem to be some tools that help in refactoring:
    https://github.com/StoutLogic/acf-migrations

    I am going to give that a try.

    Still open for tricks or links if anyone has ideas 🙂

    Cheers

    Just a thought:
    I have no experience with writing a plugin as huge as ACF and I can only wonder:
    Would it be possible to track if a field has been changed with JS and sent only that change out for saving separately? Like, doing this on my own on top of ACF?
    (I get that circumventing the WP save routine is not a good idea for the consistency of the DB.)

    PS: For anyone interested – here some info on how to move fields to other post
    https://support.advancedcustomfields.com/forums/topic/how-to-move-fields-to-another-post/
    https://www.logicspot.com/development/advanced-custom-fields-quick-hack-to-move-a-field-to-another-group/

Viewing 25 results - 101 through 125 (of 244 total)
1 2 3 4 5 6 … 8 9 10