Support

Account

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

Search Results for 'custom fields not saving'

reply

  • There have been other reports of taxonomy fields not loading and saving correctly. Most of the time it’s something to do with other plugins or a filter in place on the field. In one case the filter that was causing the issue had nothing to do with the taxonomy field (http://support.advancedcustomfields.com/forums/topic/okay-why-are-my-custom-taxonomies-not-saving-anymore/)

    Try deactivating plugins and changing themes.

  • This is working the way ACF has always worked. The values from the fields that are removed are not deleted from the database.

    You can probably see this on a repeater field as well, if you add 3 rows and save and then remove one of them the 3rd will probably linger. ACF currently does not have the ability to remove data from fields that don’t exist when saving the form. It only inserts and updates fields that are submitted.

    If you want data that is no longer needed to be deleted you would need to create an acf/save_post action http://www.advancedcustomfields.com/resources/acfsave_post/ and delete the data yourself.

  • Here’s another posts from a while back on the same topic that might explain why it is not included in ACF http://support.advancedcustomfields.com/forums/topic/taxonomies-not-saving-for-users/

  • You shouldn’t be calling the_form in a hook, but rather placing acf_form() directly in your template where you want the form to appear.

    http://www.advancedcustomfields.com/resources/acf_form/

    Saving and continuing later, to be honest, there is nothing that will tell you how to do this that I know of. I just think it should be possible. It will probably take some research to find your answer. To display a post that has already been created you need to display you form on template where the post would normally be displayed. I would then check to see if the post is published or not and if it’s not then show the form to edit it. Alternately you might have the form hidden with a JavaScript action to show the form if the user clicks on an edit button or something like that. I don’t know all of the coding that would be necessary. You asked if it was possible, not how complex it might be.

    You could start new topics with specific questions along the way.

  • Part 1, yes. There are attributes that can be added to show and use the title and content fields. They are covered here: http://www.advancedcustomfields.com/resources/acf_form/

    Part 2, as far as I know you can’t include the standard category and tag meta boxes on the front end form. I’ve seen several discussions about it and I’ve looked into it but have not found a way. I think this is more of a WP limitation than an ACF limitation. However, this also means that having a field group that with location rules that are dependent on a specific category or tag is also not possible. You’d need to use a Taxonomy field. Taxonomy fields can load and save the selected terms to the post automatically. For location rules, they can be used but it will require saving the post with the selected terms in order to see the conditional field groups.

    Hope that helps,

    ~JH

  • So, looking that the json file you attached

    
        "fields": [
                {
                    "key": "staff-members",
                    ..............
    

    the we look further down at

    
            "sub_fields": [
                        {
                            "key": "name",
                            ..............
    

    That is the problem. The plugin that you had installed, the validation field plugin, changed the key value. It should look something like field_0112ab5e75678. This is the reason that data is not saving properly and being retrieved properly by ACF5. This kind of field key renaming used to work and may still work in ACF4 but won’t work in ACF5.

    This is what a normal field export would look like:

    
        "fields":[
          {
            "key":"field_55946dcc88ab8",
            ..............
    

    You need to delete the entire works and recreate it without that plugin being active and you need to contact the developer of that plugin about making it compatible with ACF5, or at least remove the “or greater” part of where it says “Requires Advanced Custom Fields version 4.0 or greater.”

    EDIT:I have been looking for information on when this changed or if there is a setting that will make these fields work, but I cannot find anything. I do remember that in the past at some point I had a serious issue with one of my plugins. It stopped working completely. I was also using custom key values that did not conform to the ‘field_’ pattern. I corrected the problem by making sure that my keys always conformed to this pattern and since then I have not tried to use custom key values.

  • Narrowing it down here…

    The problem is in the use of acf/save_post.

    Quick overview: I have a multi-step process setup for creating a tribute (custom post type). First form creates the post (a custom post type). Next forms are for adding additional meta data. To get users to step 2, I am using the acf/save_post action to redirect them (back to the editor) after the post is created. However, using this action is preventing the custom taxonomy (states) from saving. It saves the text fields just fine.

    function get_tribute_editor_url($trib_step=false,$trib_id=false) {
    	
    	$url = site_url() . '/edit-tribute/';
    	
    	if ($trib_step && $trib_id) {
    		$url .= "?trib_step=$trib_step&trib_id=$trib_id";	
    	}
    	
    	return $url;
    }
    
    function acf_post_save_tribute( $post_id ) {
    	
    	// bail early if not a tribute
    	if( get_post_type($post_id) !== 'tribute' ) {
    		return;
    	}
    	
    	// get step
    	$trib_step = get_field('trib_step', $post_id);
    	
    	// create/update the post title if this is a new post or if the user has edited step 1
    	if ( $trib_step <= 1 ) {
    		$args = array(
    			'ID' 		 => $post_id,
    			'post_title' => $_POST['acf']['field_558884854c6ce'] . ' ' . $_POST['acf']['field_558884974c6cf'],
    		);
    		wp_update_post($args);
    	}
    
    	// redirect	new tributes to step 2 and pass along the proper ID
    	if ($trib_step < 1) {
    		$redirect = get_tribute_editor_url(2,$post_id);
    		wp_redirect($redirect);
    		exit;		
    	}
    }
    add_action( 'acf/save_post', 'acf_post_save_tribute', 20);
    
  • I am also facing the same issue. I was using ACF4. And, issue arises with fields in Repeater and Flexible fields. Then I upgraded to ACF Pro. Still issue was same. So, I changed a field from ACF-Qtranslate to Text, and it works fine.

    My current environment:
    – WordPress 4.2.2
    – Advanced Custom Fields Pro 5.2.7
    – qTranslate-X 3.3
    – Advanced Custom Fields: qTranslate 1.7.9

    Fields are still not saving.

  • The reason is that you are not saving another meta value that is needed. Have you tried using update_field()? http://www.advancedcustomfields.com/resources/update_field/

    This page also has information on field_keys and field_names and data needed to be stored in the database.

  • Not sure if you still need help with this but it may help anyone with the same issue.

    The problem probably has something to do with the field_key values of the field.

    On the back end this field_key doesn’t matter much. You can, for example, create a custom field using the same field name as some other plugin, or that has been entered into the standard WP custom field editor and ACF will get any existing value.

    The front end works a bit differently when it comes to this in a lot of ways. For example, if you try to get a “repeater” field using get_field() that does not have the correct field_key set it in the DB the ACF will return a number that represents the number of rows because it does not know that the field is a repeater without that key. For more information you can see the field_key vs field_name section of this page http://www.advancedcustomfields.com/resources/get_field_object/

    You could correct this without editing and saving every post if you did a search and replace in the database to change all the old field_key references with the new ones.

  • Hi @nexthere

    Not sure why ACF fields are not saving in posts in your WP instance.

    Have a look at these resource: Field value won’t save

    Hmm… Also enable wp_debug to show the errors if any. These errors will point you to what is causing the issue.

  • Hey all…

    I updated from 5.2.3 to 5.2.5 and had trouble saving a basic ‘page’ with a few custom fields, nothing with much data. I rolled back to 5.2.3 and all is well again.

    Had the same JS error reported in the title (preventing the save).

    Just chiming in here that I’m not 100% that this snag has been remedied. Please let me know if I can help any!

    Thx…Ross

  • Same problem here… and getting desperate…

    Checked max_input_vars, nesting_levels, input_time… Also changed option_name to 255 chars… Nothing.

    No errors neither in php logs, apache or mysql. No slow queries… I’ve debugged with save_post and acf/save_post and the array is complete in WP debug.log (it includes the not saved fields)… But they do not save to the DB…

    This behavior started after adding a repeater field in a field group. I had a lot of custom posts with custom fields working fine. Then realized I needed one more repeater field and added to the field group… This made the fields stop saving…

    Some magic would be greatly appreciated 🙂

    Latest version of WordPress and ACFPro at this time.

  • Here’s something…

    I was building an options page with a repeater field and had the same problem as the widget, no matter what I did it wouldn’t save the repeater field.

    Found this support page where Elliot Condon mentions that the Field Names might be too long and not saving properly in the database.

    So I shortened my name field and dropped a bunch of underscores and it worked! I then went back to my widget and did the same thing made the name field shorter and dropped my OCD underscores and it worked!

    Hope this helps, reply if you get it to work.

    Cheers

  • The problem is that when you build a plugin of other code to add fields that ACF will access that you’re not saving the reference value, see this page for more information: http://www.advancedcustomfields.com/resources/get_field_object/

    Your choices are to build your code to also store the reference value or to use the standard WP get_post_meta() function. http://codex.wordpress.org/Function_Reference/get_post_meta

  • Actually I just updated to ACF 5.1.8 and the sync still does it.

    We have production- and staging servers. Locally we develop on Vagrant.
    We git everything to bitbucket and sync fields between vagrants and servers through the ACF json files.

    On the production server, the customer is adding content, and we respond to requests and bugs by fixing them locally, pushing, bambooing to stage and then when stable bambooing to prod. To get the changes locally we use WP Sync DB to pull the database from prod to dev and then sync the json to get our ACF to the latest state.

    I’ve had to use https://github.com/FreshFlesh/ACF-Sync to get it to work, because when I try to use the ACF bundled sync it acts really, really weird.

    What it does is sometimes duplicating fields, and then loosing repeater subfields. This might not be a catastrophe if it didn’t arbitrarily make the json explode at the same time. Now counting three times, I’ve been in the position to have to reset to earlier commit, backing up the json, pulling myself back to HEAD and then pulling the DB all over again, and firing up the ACF-Sync plugin to do what ACF should be able to do just as well.

    ** Hey Eliot **, I think the culprit here might be that you try to do too much in one go. You try to sync both ways, don’t you? First pulling the json into ACF, and then saving a new json. So if operation one creates a problem, then operation two gets equally fu**** up… I would like the option of pulling one way only, letting the json stay untouched, that way I have something to fall back on if the fecal matter hits the rotating impeller.

    Could you separate the sync to db and sync to json from each other?

    I think I will start at ticket…

  • Running 5.1.5 as well and taxonomy fields are not loading for me either. Like RichB, I have multiple taxonomy fields in the edit post area–with 4 ACF fields covering 3 custom taxonomies and the built-in category taxonomy.

    The taxonomies all have data as seen in the database and quick editor, but they’re showing as empty within edit post and saving the post with them empty clears the taxonomy values that did exist.

  • Hi @Elliot,

    Thank you for attending to this! IF this missing feature was included in 5.1.4 (perhaps you meant the next next version?), I don’t think the update has solved this issue yet.

    I am not able to save taxonomy values within the repeater field (but also mentioned that taxonomy values aren’t saving when normal fields, as seen in this post here).

  • Hi,

    Not sure about Issue #1, but I’m definitely having the same problems with Issue #2 and #3.

    I just cannot get the fields to save the additional languages. Saving the primary English values is fine, but never saves for the extra languages I require.

    Tabs go all funny as described above too.

    I’ve read through the instruction article (http://www.advancedcustomfields.com/resources/multilingual-custom-fields/) too, and still can’t get it to work

    Would love this to be rectified ASAP…

    Using:
    WordPress 4.0.1
    ACF Pro 5.1.3
    WPML Multilingual CMS 3.1.8.3
    WPML Translation Management 1.9.8

  • 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 );
  • hey,

    i have pretty much the same issue.

    After setting “translate” for “field groups” and
    “do nothing” for “fields”
    at wpml options
    I can now create independent acf’s for the translation with independent field_names. saving here works…

    on a page/post i can copy the acfs with content to the translated page but when i edit the translated page it always gets overwritten by the acf’s from the default language page.

    trying to achieve:
    i need to copy content with acfs from a default language post to a translated language post. and then edit each language’s acf independently

    On every other project it just works fine that way…

    i already tried:

    1. 1)
      https://wpml.org/forums/topic/post-need-update-and-custom-field-dont-save-value/page/2/
      no success
    2. 2)
      http://support.advancedcustomfields.com/forums/topic/text-area-fields-are-not-saving-on-update/
      no success
    3. 3)
      deleting wpml completely and deactivating acf and all other plugins.
      then install wpml first and then activate acf again.
      no success.
    4. 4)
      tried every possible combination of settings in both plugins available.
      no success

    I can provide some login values to you elliot so you can test the bug and hopefully solve it!

    My next step would be to downgrade acf to an earlier version.

    versions:
    wpml: 3.1.7.2
    acf: 5.0.9
    wordpress: 4.0

    greetings timotheus

  • hi all,
    i think i may have found a temporary fix for the images and fields not saving problem:
    i turned on “local JSON” (see here: http://www.advancedcustomfields.com/resources/whats-new-version-5/#local-json ); now all images and fields get saved in the backend and displayed in the frontend as well.

    try enabling the Local JSON on your projects – maybe it helps until the bugs get fixed.

    regards,
    andi

  • Hi guys.

    Sorry for the late reply.

    It is no longer possible to hook into the ‘acf/save_post’ action (with a priority of less than 10) before ACF has saved it’s data.

    Instead, you can hook into the validation which is always run before saving. This can be done on a field by field level with the filter acf/validate_field (http://www.advancedcustomfields.com/resources/acf-validate_value/) or the action 'acf/validate_save_post' (no docs yet, but found in core/input.php on line 430)

    Also, $_POST['fields'] has changed to a safer $_POST['acf']

    Sorry for the inconvenience, and please be sure to let me know if the logic you are trying to accomplish is not possible with these alternatives.

  • I don’t understand what kind of notification you want to display/trigger, but you could use the update_value filter to check the difference before saving the new values and notify the way you want on removed/added differences.

    function relation_field_update( $value, $post_id, $field  ) {
        if (wp_is_post_revision( $post_id )) return $value;
    
        $old_values = get_field($field['name']);
        $added = @array_diff($value, $old_values);
        $removed = @array_diff($old_values, $value);
    
        return $value;
    }
    
    add_filter('acf/update_value/name=relation_field', 'relation_field_update', 10, 3);
    

    Where name=relation_field in the filter is the name of the ACF field you want to verify.

    The wp_is_post_revision check is necessary since you don’t want to verify post revision. The @ are there to bypass the exception threw when one of the array is null (this could be done better with condition, e.g. is_array()).

    So, $added will be (empty or) containing the added IDs and $removed will be (empty or) containing the removed IDs.

  • I’m having a very similar issue. I’ve got a menu built out using a lot of custom fields and repeaters. Initially our issue in AC4 was that when you would click update it would take a long time to load then refresh and the new fields we had added would be gone. We upped max_input_vars and about every other PHP value I could think of.

    So I was hoping the upgrade would fix our saving issue, but it seems to have cropped up a different one. Now when I try to save I get the same “Uncaught TypeError: Cannot read property ‘length’ of undefined” error in load-scripts.php. This seems to go away when I delete some data / fields, but crops back up when I try to add it back in. Any suggestions?

Viewing 25 results - 176 through 200 (of 243 total)