Support

Account

Register Login

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

Search Results for 'custom fields not saving'

reply

  • Hi @roi

    I’m not sure what happened, but a lot of things can happen in two years of time span. It’s possible the issue came from ACF, but it’s also possible that the issue came from WPML itself.

    If the issue can be solved by re-saving the post, then I suggest you do that instead. Re-saving the post mostly will save the required data that is not generated back then.

    Also, could you please make sure that you have followed the guide here: https://www.advancedcustomfields.com/resources/multilingual-custom-fields/.

    Please make sure to backup your site before doing that.

    I hope this makes sense 🙂

  • I switched to the ‘acf/save_post’ hook instead of ‘transition_post_status’, per a support ticket, and it’s saving now 🙂

    I got the post id by echoing out get_the_ID() (see code comments); I just hardcoded it to be sure. This was just a basic text field. To test, I was just saving the post and checking to see that the field had been updated from the edit-post view.

    Note: For this to work, I set the priority to 20; leaving it as 1 (before post save) didn’t work.

    Thanks for the help.

  • Options page values are stored in the _options table, there is only one place to save them in this case and creating two fields with the same name means they have the same option_name. ACF does not have any way to determine that a field belongs to a specific options page, either when saving it or when calling one of the front end functions with ‘options’ as the ID. Contrary to what a lot of people think, ACF does not actually track what field value belongs where, it simply save values to the database and then retrieves them when you supply the right information. The “Location Rules” have no effect on the fields, they just tell ACF that a group should be displayed. Saving values to an options page is like a “default”, if ACF can’t figure out where a value should be saved it ends up there. ACF basically works as a big wrapper for existing functions in WP. ACF has always worked this way and there is very little chance that this will change in the future.

    If you want to submit this as a bug you should open a new ticket https://support.advancedcustomfields.com/new-ticket/, but I suspect you will get a response similar, but maybe a little less verbose, as the one I just gave.

    There are choices. I’ve already mentioned a couple of them.

    Another option, if you’re using ACF 5 (Pro), is to specify a post_id to save the options to when creating the options page https://www.advancedcustomfields.com/resources/acf_add_options_page/.

    Another option is to customize the field group based on the options page that’s being loaded to add your own prefixes or suffixes to all the field names and then use these modified field names when getting the values in templates. This option would require a lot more explanation than is possible on this forum, but if you investigate this I suspect you’ll learn a lot more about why ACF works the way it works.

  • Note this happens with no custom fields set up at all – replicated locally just with both plugins installed, and a recipe inserted into the content. Refresh and you’ll see the error.

    Given this prevents posts from saving at all, a quick fix would be appreciated 🙂 (It could be an issue in the other plugin, but..)

  • Thank you so much for the reply. It’s about 1:30am for me right now so I only worked on Item 2 from your suggestion. It’s showing the *current* date now, but not the date selected in the date selector field. However, I wonder if Item #1 may be partially to blame.

    Better than a screenshot, here’s a link to the dev page. Maybe that’ll show you what’s going on. The first time you visit the page, you *should* have no fields pre-filled. And you *shouldn’t* have them pre-filled at *any* point you visit the page. But at least for me (I’m using FF), ever since the first time I filled out the form for testing purposes it remains filled out, and when I try to change a field (for instance, Church Name, which is part of the modified custom post type title), it saves in admin as the original entry I made, but when I click to edit/view, it shows the correct entry in the form itself – it’s just not saving it to the title properly.

    The other items I’ll look at when I’m up again. Thanks again.

  • Hi @renar

    I’m not so sure how the saving process in Gravity Form and WPML works, so I’m sorry if I can’t help you much. For something like that, I suggest you consult to their support instead. After you know how to create the translated post using those plugins, then you need to get the translated post ID. By using this ID, you can add the values to the translated post by using the update_field() function.

    I hope this makes sense 🙂

  • When registering a taxonomy if you set the ‘meta_box_cb’ argument to false then the WP box for the taxonomy will not appear.

    I don’t know about the feature to prevent ACF from saving the values as normal. The best way to get feature requests looked at by the developer is to create a new support ticket: https://support.advancedcustomfields.com/new-ticket/

    It is possible to abort the saving of data to the field in WP using this: https://codex.wordpress.org/Plugin_API/Filter_Reference/update_(meta_type)_metadata

  • Hi @claw

    I think the easiest way for you to achieve all of these is to create your own custom fields for the title and the editor. You can then hook into the acf/save_post action hook and retrieve the values in these fields yourself and add them as the post title and post content.

    A few things to note:
    1. You have to run the remove_action before saving the post title and content (if you save them using wp_update_post) and add it back in after. Basically same thing as this explains with infinite loops except you apply it to acf/save_post: https://codex.wordpress.org/Plugin_API/Action_Reference/save_post
    2. You’re gonna end up with two extra fields in the admin area for these title and content fields. You can remove them in the admin area using CSS or simply disable them (to stop user from being able to interact with them) using this filter: https://www.advancedcustomfields.com/resources/acfload_field/
    and setting $field['disabled'] = 1;

  • Hi @geert

    Hard to know where to start…

    Okay, so most people on the web with a WordPress site probably has shared hosting (I’m guessing). They have little to no control over the servers settings and limitations. Here’s some standard PHP values which are unlikely to be set higher in such shared hosting:
    http://php.net/manual/en/info.configuration.php

    disclaimer: I’m not gonna research everything here before (limited time) so some is a little bit of guesswork when it comes to numbers.

    max_input_vars there is one of the most interesting ones. Basically it says that PHP will accept a maximum of 1000 input fields to send to a single request (page load). In the case of WP admin that would likely be a POST request. WordPress per default already have quite a bit of fields for a standard edit screen. There’s a whole bunch of hidden fields as well as formats, categories, tags, featured image, title, editor, permalink, visibility, status etc. Let’s say you also have a few regular custom fields. Then you also add a repeater field to this. Each row might contain 2-10 fields + some hidden fields ACF uses to keep track of everything. Maybe you even have nested repeaters! So for each row there’s 2-10 fields + a nested repeater which in term contains 2-10 fields. And say you add in a gallery field there as well. That’s at the very least 1 field for each image.

    You’re quickly gonna find that you hit the 1000 input vars limit if you abuse repeaters. That’s gonna stop you from adding any new content to the page before you delete other. That in itself should be enough to reconsider huge repeater fields. But to make matters worse there’s also server limits like max_execution_time and max_allowed_packet (mysql). Saving all these fields will take some time and if you’re not on a great internet connection you may hit the max_excecution_time which will lead to your page save ending abruptly and unfinished. max_allowed_packet is a variable for mySQL which basically limits how large of data chunk you may insert in one go. It’s much harder to hit but it’s possible.

    If you’d be on a VPS you could prevent all of this by just upping your server stats. However you’ll still get a very slow admin experience and let’s face it, you’re patching a leaking boat and probably have to pay a hefty price for it (big servers aren’t cheap).

    Then there’s also the issue of WordPress database structure and the performance of WP_Query. 10up has written a great article on performance with WP_Query and one of the things to avoid is post meta lookup. Usually there’s no choice BUT we can at least do what we can to use simple post meta like a single date field or a boolean. And of course try to minimize the amount of post meta for each single post. https://10up.github.io/Engineering-Best-Practices/php/#performance
    Consider that ACF adds two rows to wp_postmeta for each field (both regular and sub fields).

    So if we can refactor our data structure to use a custom post type which would contain some fields and then perhaps link different posts/post types together with the post object or relationship field we’ll end up with safer and quicker admin requests, faster and often more versatile use of wp_queries in our front end and a better DB structure more fitting of WordPress strengths and weaknesses.

    It’s hard to say a number of repeater rows that’d be “too much” since it depends on what they contain. But for me, if I find that I’d end up with more than 20-30 row of simpler repeater data or 10-15 rows of more complex ones I would consider a different solution. Sometimes it’s hard to predict tho. We’ve had customers where they were supposed to use repeaters for just a few categories of Press media attachments but they ended up dumping soooo much media there that we eventually had to rebuild it for them with a CPT where each post was a single media file and a taxonomy for the categories of media.

    Hope that was a sufficient answer 🙂

  • @James,
    Thanks for the suggestion. I actually came up with a slightly more elegant solution.
    First I pluralize the name attribute by hooking into 'acf/prepare_field'

    
// My field group contains only a single Post Object field
add_filter('acf/prepare_field/type=post_object', 'my_acf_prepare_field' );
function my_acf_prepare_field ( $field ) {
    $field['_input'] = $field['_input'] . '[]';
    return $field;
}

    That will create an array of entries in $_POST

    
[acf] => Array
        (
            [field_573e727f24ef4] => Array
                (
                    [0] => 170
                    [1] => 152
                    [2] => 155
                    [3] => 170
                )

            [_validate_email] =>
        )

    This creates 2 issues however.
    1. The array keys are kinda meaningless to me.
    2. acf_form_head() cannot process this. IMO it should be able to in a future version.

    To fix the first issue I had to store a post id in $GLOBALS at the time I was calling acf_form()

    
// leaving out some context here but this demonstrates the idea
$GLOBALS['current_menu_item_id'] = $item_id;
$acf_options = array(
  'post_id' => $item_id,
  'form' => false,
  'field_groups' => array('group_573e71ff44db1'),
  'return' => '',
);
acf_form( $acf_options );

    Now we can modify our earlier prepare_field handler to pluraize with meaning

    
function my_acf_prepare_field ( $field ) {
  $field['_input'] = $field['_input'] . '[' . $GLOBALS['current_menu_item_id'] . ']';
  return $field;
}

    Which creates something in $_POST we can use during our fix for the second issue.

    
[acf] => Array
  (
    [field_573e727f24ef4] => Array
      (
        [172] => 170
        [173] => 152
        [174] => 155
        [175] => 170
      )

    [_validate_email] =>
)

    To fix the second issue I removed acf_form_head() and called acf’s meta update manually. In my case I was saving changes to a Menu so I just hooked into the relevant filter but this could be done wherever you’re handling your form submit. This is inspired by Remi Corson

    
// save menu custom fields
add_action( 'wp_update_nav_menu_item', 'my_update_custom_nav_fields', 10, 3 );
function my_update_custom_nav_fields ($menu_id, $menu_item_db_id, $args) {
  if ( is_array( $_REQUEST['acf']['field_573e727f24ef4'] ) ) {
    $field_value = $_REQUEST['acf']['field_573e727f24ef4'][$menu_item_db_id];
    $field = get_field_object('field_573e727f24ef4', $menu_item_db_id, false, false);
    acf_update_value( $field_value, $menu_item_db_id, $field );
  }
}

  • There was a problem in 5.3.8, but it was supposed to be corrected in 5.3.8.1. See this topic https://support.advancedcustomfields.com/forums/topic/custom-image-field-not-saving-v5-3-8/.

  • Hi @pabloalmeida

    Thanks for the bug report.
    We have had similar issues raised today and will have this fixed ASAP.

    To avoid duplicate threads, can you please follow the instructions here:
    https://support.advancedcustomfields.com/forums/topic/custom-image-field-not-saving-v5-3-8/

    Thanks
    E

  • Hello,
    That is sad to hear, though maybe it’s time to change that?!
    I mean, i’m sure that happens to so many people:
    You investing some time on filling the custom fields up (in my case it’s about 20 fields in the product post type),
    BY MISTAKE ;( you are pressing the “Back” button on the keyboard or accidentally close the browser, leave the page or maybe getting time out and just like that you have lost ALL the custom fields meta that you just inserted.

    I think we do need a solution for that.

    I have collected few other people that are having the same issue, i think we need to solve it once for all.

    Autosave and Custom Fields in WordPress
    http://stackoverflow.com/questions/4822175/autosave-and-custom-fields-in-wordpress

    Feasibility of AutoSaving Fields?
    https://support.advancedcustomfields.com/forums/topic/feasibility-of-autosaving-fields/

    NOT AUTOSAVING CAUSING MASSIVE CATASTROPHIC DATA LOSS
    https://support.advancedcustomfields.com/forums/topic/not-autosaving-causing-massive-catastrophic-data-loss-2/

    periodic auto save
    https://support.advancedcustomfields.com/forums/topic/periodic-auto-save/

  • Hi @quantum_leap

    By using the 'form' => false option, you need to create a custom code to handle the saving process. To do that, you need to know how WP Job Manager form works and add the update_field() function to save the posted custom field to the database. I believe you can get the custom fields data from the form like this:

    $custom_field_data = $_POST['acf']['field_1234567890abc']

    Where ‘field_1234567890abc’ is the key of your custom field.

    Regarding the warning messages, I’m afraid I’m not able to give you direction regarding that issue. Could you please ask it to WP Job Manager support?

    I hope this makes sense. Thanks 🙂

  • Hi @v3madmin

    You can use the field name if the value has been initialized in the database at least once. You can do it by saving the post from the backend editor or front end form. But if the value is not initialized yet, you need to use the field key so ACF knows which field you want to add since you can have different custom fields with the same name. It will prevent the confusion in the system.

    But if you still think that this is a bug, you can create a new ticket from the following link so it can be passed directly to the plugin author: https://support.advancedcustomfields.com/new-ticket.

    I hope this makes sense 🙂

  • Hi James, yes it’s really strange. I have deleted and recreated the custom fields in the plugin.

    When I enter content and go to ‘preview’ the page I can see its outputting correctly. When I click save the content in the custom field text area does not update. Its blank (not saving)

    I have tried multiple browsers and I have also tried uninstalling and reinstalling the plugin.

  • The problem was max_input_vars.
    I should have looked harder for the earlier thread, which I already seen, bearing the solution – http://support.advancedcustomfields.com/forums/topic/stuck-at-59-fields-not-saving-more/

    max_input_vars = 10000;

  • Yes, I did, sorry, forgot to add the link http://support.advancedcustomfields.com/forums/topic/taxonomies-not-saving-for-users/

  • Hi @tdmalone,
    I had this same exact issue a while back and found it was actually how the custom field keys were being saved in the database. Essentially, once you reach a certain character limit (length) inside the database for these keys, they stop saving. I brought this up to ACF support and was directed to purchase the ACF PRO version as they save these fields in a different fashion and with greater lengths. After upgrading to ACF pro, the issues stopped happening and now have very complex nested repeaters that work flawlessly. Also to note, you will not lose any custom fields or data you have created in the regular version as ACF PRO imports all of the old info. Hope this helps.

  • What you’re trying to do can’t really be done, basically because sorting posts by two different meta keys and intermixing them in WP is beyond what WP is capable of. However, you can do this by saving the value of org_name in the last_name field when the post is saved.

    
add_filter('acf/update_value/name=org_name', 'insert_org_into_last_name', 10, 3);

function insert_org_into_last_name($value, $post_id, $field) {
    // replace the value of $last_name_field_key
    // with the field key of the last name field
    $last_name_key = "field_123456789ABCD";
    
    update_field($last_name_key, $value, $post_id);
    
    return $value;
}

    Now you can do a query and sort by last name. The value in last name will not be seen because it’s in a conditional field.

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

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

  • please use code tags when posting code.

    I’m not sure exactly what you’re doing, but if you want to set the default value of a field then I think you need to use the acf/load_field filter. the acf/update_value runs when before the acf field is saved, not when the field is loaded.

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

    You can’t change the default value of an ACF field when you’re saving a product in woocommerce.

    Also, looking at what I can make out of your code $order->id has no meaning inside of the function.

    $post_id = $order->id; is setting $post_id to NULL.

  • ACF does not support user taxonomies and from what I understand the developer will not add it since WP does not really support user taxonomies.

    There has been some discussion on these forums about this and ways to get it working. Not sure if this will help you or not.

    http://support.advancedcustomfields.com/forums/topic/user-taxonomies/

    http://support.advancedcustomfields.com/forums/topic/taxonomies-not-saving-for-users/

  • User taxonomies are not supported by ACF. There is a topic with a potential solution and the developers explanation of why it is not supported here http://support.advancedcustomfields.com/forums/topic/taxonomies-not-saving-for-users/

  • @jonathan – thanks for the help. I ran into an issue with the wordpress “save_post” action that it was running prior to the saving of all of the custom post meta fields. I wound up messing around with several other actions before trying the “acf/save_post” again and I pulled the priority 20 and now it runs as I’m expecting it too.

    I also stuck a hidden value into my front end form to look for on the server side so that I know if it’s a post from the front end or not.

    Thanks for all of the help!

    Alan

Viewing 25 results - 151 through 175 (of 243 total)
1 2 3 … 6 7 8 9 10