Support

Account

Register Login

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

Search Results for 'custom fields not saving'

reply

  • Hi there – has anyone come up with a solution to this? So far everything with Gravity Forms saving to my custom fields created with ACF work great… except for my custom image and gallery fields. I’d love to get this to work, but not sure where to look or who to ask.

    Thanks!

  • Similar issue. WP 3.9, ACF 4.3.7. Not limited to repeater fields. Wherever I create a custom field with a rule where “Page is equal to Home” (or similar), the field shows up when editing that page, but upon saving, the content disappears. (Also confirmed it’s not saving to db.)

  • Hi @nitins

    1. Use the get_posts function to return all the posts you want
    2. Loop over the posts
    3. For each post, update the value

    To update the value, either use a WP function such as update_post_meta or the ACF function update_field.

    Please note that update_field will only work to update a repeater field, not a sub field within a repeater.

    Saving a repeater field: http://support.advancedcustomfields.com/forums/topic/update_field-with-repeater-fields-issue/

    Thanks
    E

  • Hi @SnitchHomer

    Are you using the acf_form_head function? If so, just remove this from the code and ACF will not run the save.

    If this is not the issue, perhaps ACF is listening to the saving of a new user and running it’s code there.

    This may be a limitation with ACF at the moment which will be fixed in ACF5 (very soon to be released).

    Maybe for now, you will have to add custom fields to the form in a manual way instead of acf_form

    Thanks
    E

  • Hi @elliot,

    thank you for your answer.
    We use a OO-Form to create our new WP-page. After we create this page we use the following function to save the values:

    public function updateFields($cover_pic_id) {
        // update all custom fields in the projects page
        update_field('project_name', $_POST[PNAME], $this->post_id);
        update_field('short_description', $_POST[SHORTDESC], $this->post_id);
        update_field('overview_text', $_POST[OVERVIEW], $this->post_id);
        update_field('equity_text', $_POST[EQUITY], $this->post_id);
        update_field('start_date', $_POST[STARTDATE], $this->post_id);
        update_field('end_date', $_POST[ENDDATE], $this->post_id);
        update_field('investment_goal', $_POST[INVGOAL], $this->post_id);
        update_field('keywords', $_POST[KEYWORDS], $this->post_id);
        update_field('cover_pic', $cover_pic_id, $this->post_id);
    }

    ($this->post_id is a private member variable that saves the post-id of the page just created)

    So all in short on submitting:

    $this->createNewProject();
$this->updateFields($cover_pic_id);  // update custom fields in project

    maybe we do have to update the fields before we create the page? but that would not be logical?

    As mentionned the values are visible in the backend, but we cannot access them with get_field() before saving the page manually.
    Thanks Julson

  • Hi @julson

    The issue here is that your custom code is not saving the reference field which links the ACF value to the ACF field.

    Please use the update_field function to better save the custom fields:
    http://www.advancedcustomfields.com/resources/functions/update_field/

    Thanks
    E

  • Hi @noisemedia

    Thanks for the question.
    You will find the same issue in this thread:
    http://support.advancedcustomfields.com/forums/topic/option-fields-not-saving-within-flexible-content/

    In short:
    The wp_options table has a character limit of 64 on the options_name column. This means that WP can’t save any data that exceeds this limit. Your nested repeater field is most likely causing the field_name to become too long.

    Please read the linked thread for some solutions.

    Thanks
    E

  • I’m having a similar situation with repeater fields. There’s a limit to how many repeater fields in a row I can use before they stop saving. I used a custom php.ini in the site root to do the following:

    > php_value max_input_nesting_level 128
    > php_value max_input_time 300
    > php_value max_input_vars 3000
    > php_value max_execution_time 300
    > php_value post_max_size 32M

    But this did not fix the problem. I’m going to try to boost the max_input_vars to higher.

  • Hi @James

    There is no limit for saving fields in a field group.
    Each time you save, all fields are updated and this requires PHP memory, vars, database calls and time.

    It is possible that your server is not allowing the sufficient resources needed for the save to complete. The max_vars is a good place to start, but it is important to make sure that this value is being used by your server. Please google how to test server info such as max_vars.

    Here are some similar threads:
    http://support.advancedcustomfields.com/forums/topic/field-group-not-accepting-more-than-69-fields/
    http://support.advancedcustomfields.com/forums/topic/is-there-a-limit-on-fields/

    Hope that helps.

    Thanks
    E

  • Hi, @liesju
    a) The translation with a LOT of rep fields and other works pretty well but it s important to do things in a certain order. elliot mentioned that the new version will be more compatible with wpml, but I can tell in our setups with very complex ACF setup it works as it is in all our “cases”.

    b) In my mind, for reading and writing this on a hollyday trip during chrismas, the

    -rule
    -position
    -layout
    -hide_on_screen

    must be “traslateable”, in the wpml settings, or I think you can activate them in the meta box on ANY ACF edit page the FIRST TIME, before saving any changes.

    c) I think the “rule” is the “show on” example type = posts and / or user = admin , and so on.

    If this is not set to be translateable, the fields never show on the “other” languages = will not be accessable or might not be recorded if you dublicate the fields to that language

    d) It easy to forget that the ACF fields must be dublicated. Just go to the edit ACF field ON THE DEFAULT ADMIN LANGUAGE (selected), choose “dublicate” (AFTER the rule, position, etc etc is radio-checked translateable). Click on the “language” ( the pen) and let the page reload to the actual language and re-save the edit screen.

    d2) do not dublicate a “translated” created ACF setup

    e) Leave the rest of “_your_field_names” as they are, do not “translate them”. (they are a lot of them if y using repeater fields)

    As long as you se the meta-boxes on the “new” languages when edit a page or post or custom post type, you are ok. But the DATA of the field must be “dublicated” AFTER this setup is ok.

    You can not “move” ACF data from the original fields ( all of them ) ONCE you cretaed the tranlated post… Make shure the setup is fine BEFORE you start to translate (including rules that ACF is ok to use AND visible, on the translated pages as well = 99,99% we want)

    Its a little tricky, but it works for us! Actually, the logic make sence, (for a tech point of view). But We cant speak for every setup.

    Hope it can help, and as I mentioned earlier in this thread, some “routines” – the order of setup – will be published with a turtrorial on our domains (my developers team deep circle….) later this year. But for now, we are in the ** of delivering projects…

    / Big user of ACF struggling with Multi-languages and WordPress

  • I’ve experienced a similar issue, I just started up setting a fresh WordPress installation, installed the repeater field plugin, and the ACF plugin and then created a new custom post type page that included some ACF fields.

    Repeater fields where also included, first time I saved the page, with only one regular ACF text field did not produce any problems.

    Then saving the page with a repeater field caused the backend of WordPress to break and all the other fields did not save as well.

    So it looks like there is some serious breakage due to the ACF plugin combined with the Repeater Field plugin once data is saved to the database.

    WordPress backend doesn’t seem to load correctly anymore, background color shows a dark gray color #666666 instead of a white background.

  • Sorry I slept on it and woke up this morning realising it was probably one of my own functions causing the error. After narrowing it down, I realised that a had a function with some acf fields saving to another db table on post save, and that I hadn’t wrapped it correctly in an if function. It’s only supposed to do it with a certain custom post type you see. Sorry!

  • Hi @dom

    Because you are saving / loading data from the options page add-on, you must also remember to specify the $post_id parameter as shown in this doc:
    http://www.advancedcustomfields.com/resources/how-to/how-to-get-values-from-an-options-page/

    Basically, the get_field should look like:

    
get_field('gallery', 'option')

    Thanks
    E

  • Hi @cedric_charles

    All post types will be available in the location rules dropdown., even if the post_type public setting is false.

    If your post_type is not appearing, then perhaps your post_type is not registered when ACF does the AJAX request to populate the select field.

    This would be the case if you have wrapped your register code within an action. During an AJAX call, no WP action will be called (for example: admin_menu, admin_head, plugins_loaded, etc)

    Could this be the issue?

    Can you try setting the post_type to ‘post’ and then saving the field group. Does the newly refreshed page contain the correct post_types in the dropdown?

  • @stephw
    I came accross you posts / rely: I also wanted to hide the ‘Title’ from the backend form, as it acts as a duplicate of 2 collated fields (firstname & last name…). Obviously the title is the post name so is needed.
    Could you please share the way you set up the title value, without having to input it ?
    I understand the ACF hooks system, similar to theWP logic, but am not comfortable with it at all yet (where to I how, which hoo to use, how to I collate the 2 values befofore saving the form…?
    Many thanks
    JMB

  • Hi @robteamworks

    Thanks for the bug report. It looks like the front end form needs to contain some kind of ‘honey pot’ or captcha for spam entries.

    Becuase the front end form is quite new to ACF, the plugin does not yet contain these features, but I’mm sure we can add them in.

    Version 5 is well underway and contains PHP validation which can prevent the data from being saved. It would be quite easy to add in a hidden cutom field (honey pot) and then use the PHP validation hook to return false and stop the post from saving.

    For now, I think you could do something similar using the pre_save_post action.

    Give this a go:

    In the acf_form args, add a hidden custom field in the ‘html_before_fields’. Perhaps also read up on the honey pot tactics online

    Then in the pre_save_post action, check the $_POST data and simply die if the form contains data in that field.

    Hope that helps.

    Thanks
    E

  • Hi @v1z1w0rx

    This is most odd! Are the fields registered via PHP code, or are they created via the standard database UI?

    Have you tried setting up the website on a local MAMP server? Perhaps there is an issue with POSTING data

    My first through is that there is some conflict going on either from another plugin or from the theme.

    Did you deactivate 100% of all plugins AND change theme to default? Can you make sure the default theme did not contain any custom functionality?

    I would setup on a local install and start fresh.
    1. Re create the field group (perhaps even import / export)
    2. Create some new posts and see if it works
    3. Install your plugins 1 by one until the issue starts again
    4. Install your theme.

    Thanks
    E

  • Sorry I haven’t gotten back to you Elliot, I had trouble signing on a few times but I think it was because it was from an insecure network. I actually got it to work by simply changing the field values. I don’t have any other custom fields with those values, so I’m not exactly sure what the problem was.

    But to confirm your questions, yes ACF was saving the first image but not others. I did remove and upload the image and it didn’t work. My guess is some issue in the database?

  • Hi @patternbook

    You are using a ‘custom’ field tpye (star rating).

    This field type is using the wrong name attribute. That is why ACF is not saving it’s data.

    Please review the docs on how to create a field type and study the field type template on github to learn how to set the correct name attribute

    Thanks
    E

  • Hi @patternbook

    I have logged in anad taken a look.
    Just to clarify.

    This is not an issue with the ACF plugin. All ACF fields are saving values correctly.

    The only issue here is with the ‘custom’ field type you have created / installed. It is not using the correct ‘name’ attribute to save the data.

    Thanks
    E

  • As I wrote in my first post, I use my wordpress instalation in a non-standard way. It’s used because it provides a great amount of useful functions + admin interface, but on the frontent I have my custom .php files which load wordpress with the SHORTINIT param. And I have also my custom database queries to get the ACF fields, because the plugins are not loaded on SHORTINIT. As I wrote I need to pass the fields as an object to ajax response, to have it in my frontend javascript, so I create an object of fields, $obj->field_name = 'field_value'. If there was an empty field without name, without label, it caused error because of trying to create an object property with empty name 

    $prop_name = null;
$obj->$prop_name = $field_val; // error!

    Of course, I can just check if the field name is not empty, but I think it should be done during saving a field, because I’m sure no one needs a field without name, but one can create it ‘by accident’.

    Just for rules, logically when the field is marked as required, and it really is required, it should be required.

    Please consider adding this one or two lines of code, in the next version 🙂

  • Hello, in all my sites the plugin stopped working. I try to create a new group of fields, but he did not publish.

  • I found the solution in another thread:
    http://support.advancedcustomfields.com/forums/topic/text-area-fields-are-not-saving-on-update/

  • I found the cause in my case:
    http://support.advancedcustomfields.com/forums/topic/text-area-fields-are-not-saving-on-update/

  • Hi @dominic

    I doubt the action do_action (‘acf / save_post’) will be of much help to you as the names of your fields (from the WP User Frontend plugin) will not be in the ACF format.

    What I would do is research the WP User Frontend plugin docs for an action which is triggered during the saving of the form. Hook into this action and then manually save the ACF data using the update_field function.

    You will find documentation about this function over on the docs page.

    Thanks
    E

Viewing 25 results - 201 through 225 (of 243 total)
1 2 3 … 8 9 10