Support

Account

Register Login

Home › Forums › Search › Search Results for 'max_input_vars'

Search Results for 'max_input_vars'

topic

  • Solving

    Loss of Repeater Field Data when Rearranging Layouts in Flexible Content

    Hello,

    When using a Flexible Content field in ACF, which contains layouts that include Repeater fields, there is an issue where changing the order of the layouts in the WordPress admin interface results in the loss of data from the Repeater field within those layouts.

    Environment:

    1. Web Server: Apache/2.4.54 (Unix) OpenSSL/1.0.2u PHP/8.2.0
    2. PHP Version: 8.2.0
    3. max_input_vars 10000
    4. MySQL Server Version: 5.7.39
    5. WordPress Version: 6.3.1
    6. ACF Version: 6.2.1.1

    Statement:

    I wanted to provide an update regarding the configuration change I made in PHP. As recommended in the discussion thread found here: Thread Link, I adjusted the max_input_vars to 10000.

    Unfortunately, despite making this adjustment, the issue of data loss when updating Flexible Content fields persists. The rows continue to disappear in the backend as mentioned in the thread.

    Steps to Reproduce the Issue:

    Create a Flexible Content field in ACF and add layouts that contain Repeater fields.
    Populate data in the Repeater fields within the layouts.
    In the WordPress admin interface, rearrange the order of the layouts within the Flexible Content field.
    Save the changes.
    Notice that the data in the Repeater fields has been erased.

    Additional Information:

    This issue leads to the loss of critical user data and can have a significant impact on their use of ACF.
    Expectations: We expect that rearranging the layouts within the Flexible Content field should not result in data loss within the Repeater fields.

    Thank you for considering this bug report and working towards its resolution. If additional information is required, please feel free to request it.

  • Helping

    need help with repeater

    i have a repeater field , when the post have more that 106 rows i get 404 when trying to save… before i could save more that 100 rows (they have only a few filds inside)

    when i run phpinfo i can see:
    local. master
    max_execution_time 10000 10000
    max_file_uploads 20 20
    max_input_nesting_level 256 64
    max_input_time -1 -1
    max_input_vars 20000 10000
    memory_limit 1G 1G

    i think i change this to this high values… what could it be ? i also tryed :
    /**
    * Increase ACF Repeater row limit
    */
    function my_acf_repeater_settings( $field ) {
    $field[‘max’] = 5000; // Change this value to your desired limit
    return $field;
    }
    add_filter(‘acf/fields/repeater/settings’, ‘my_acf_repeater_settings’);

    no luck .. my acf is Ver5.12.3 … can any kind soul help me? tanks

  • Solved

    Can only output 6 layouts from my Flexible Content field

    Hi,
    I’m using ACF Pro Version 6.0.5 with WP 6.1. I have a Flexible Content field with 6 layouts in it. They display fine on the front end. When I create a 7th layout in the field I just can’t get that layout to display. It’s like I’ve reached a limit.
    If I try and just display that 7th layout and not display layouts 1-6 it displays.
    Go figure. 2 of the layouts use basic Repeaters if it matters.
    I did see 1 issue in my php-fpm-error.log “server reached max_children setting (4), consider raising it”
    I’m hosted on Pantheon with these setting in php.ini
    with max_execution_time = 120
    max_input_time = 900
    max_input_vars = 10000
    memory_limit = 256M
    Any help appreciated!
    Thanks

  • Solving

    max_input_vars and fields not saving

    For one of WordPress’ core plugins, that this is not resolved is quite concerning. I didn’t even know it was a thing.

    We have a multi-language multisite and flexible content fields disappear without any sense of consistency. We are not using particularly complicated page structures.

    I have max_input_vars at 5000, our server admin is reluctant to up it any more.

    Surely there should not be a limit on the number of fields available, or at the very least, some kind of warning. Page builders liek Elementor and even Gutenberg use far more variables than simple ACF compounds.

    Why is this happening and is there any fresh thinking on the issue?

  • Solving

    Create new Field, creates another one and losing position after update

    As soon as I create a new field in a group via the WordPress admin, a second field of type text is automatically created. The keys of the fields are “26017” and then “field_60efcd5f9a084”.

    At the same time, when I click on update, I also lose the position where everything should be displayed. It resets itself to post. The Original Position it should be displayed on is an options page.

    I have 204 Fields (Text fields + repeater) in this Group. And fieldnamens can be something like this “language_mybikes_modals_angebot_nicht_mehr_verfugbar_bodytext_start”.

    So a very long name.

    So i just googled für acf losing postion and came up with a solution to increase max_input_vars. It was 1000, then increase it to 3000 and my problems are gone.

    Now my Question to this.

    Can this really be the reason for the problems described.
    Is there a way to determine how long the string (or how many vars) is that ACF produces at the moment I click on update.
    And gives a recommended value for max_input_vars.

    Probably in 99.9% of all cases the 1000 for max_input_vars is by far enough.

  • Helping

    Field data not saved on new page's first 'update'

    I have a series of ACF custom fields that are setup to show on the page edit screen if the page’s template is set to a certain template. When I create a new page, and go to the template dropdown to select my template, it makes my ACF fields appear in the edit screen. If I then add content to those fields and save the draft or ‘Publish’, I can refresh my edit screen and my content in my ACF fields doesn’t save. However, if I add the content again to the ACF custom fields, and save/update, the changes stick.

    I tested a situation where I have an ACF custom field appear on the post type of ‘page’ and when I create a new page, add content to that custom field, save/publish and refresh, my custom field content is saved and isn’t lost like in my scenario described above.

    I’ve disabled all plugins except ACF and it is still an issue. max_input_vars is set to 3000. ACF Pro and WP are both up to date

  • Helping

    I cannot create / add / delete ACF fields

    Hello,

    I was in the process of creating a site for a client, everything was going fine but for some unknown reason I can no longer see / edit or create acf fields. I tried increasing max_input_vars to 19000 in my php.ini or in the .htaccess but it doesn’t change anything. I also tried to add in my function.php ‘add_filter (‘ acf / settings / remove_wp_meta_box ‘,’ __return_false ‘);’ but that doesn’t work either. When I inspect my console I have no javascript errors. I also deleted all my plugins except ACF but without result. And finally I deleted ACF and reinstalled via zip from the official website but still without success. Do you have a solution to suggest to me?

reply

  • I confirm – it is still a thing.

    It happens for different field setups – I’m still doing a more through investigation of the issue.

    The problem that was reported to me recently was an editor using a simple flexible section (text field, textarea, button + repeater containing only one select input per row) – one day the data is there and the next day the whole section has a structure (so I see lets say 6 repeater rows) but all is empty, even fields marked as required.

    Using a DB backup I noticed that the sections order was changed between the days – so it could support this idea suggested initially by wplus.

    And no John Huebner – there is no conditional logic for this section.

    So far (in my investigation) I can see that the data for this section seems to be still in the DB but ACF does not see it to fill the forms with the values.

    I have:
    ACF Pro Version 6.2.3
    WordPress 6.4.1
    PHP Version 8.1.23
    max_input_vars 10000 (which is not exceeded by the edited page)
    + reasonable log max_execution_time & max_input_time

  • After I posted this, I figured it out it’s related to the max_input_vars.
    Thank you!

    This specific back-end post saving, included lots of lots of vars… (fields inside groups inside repeater inside repeater). Any best practice for this?
    Any way to optimize this max_input_vars? maybe I can make ACF splitting those post requests into several requests?

    Thanks!

  • When fields disappear at the end of a repeater this is usually do to the PHP setting max_input_vars. This setting needs to be edited on your server/host. The default is 1000.
    [Search Results]

  • This is a user forum and ACF developers do not answer questions here.

    Someone can try to help you but you’ll need to provide more information. With the information you’ve provided I can give you some general reasons that this happens.

    If the page you are editing has many fields it could be an issue with the php setting “max_input_vars”

    Another possible issue is that another field with the same name is interfering with saving the value.

    If you want to contact the developers directly you need use the contact form or submit a ticket through your account.

    You’re video does not really help me. How many fields are you dealing with? How many rows have you added to repeaters and flexible content fields? How many other fields are on the page?

  • There’s no limitation coming from ACF but you could hit up against a max setting for PHP max_input_vars on your server or similar that could interfere.

  • How many fields are in your field group? Is it a large number? If this is the case you might be having an issue with php max_input_vars

    If that is not it then your field name may be conflicting with some other field in WP.

  • Well, I just did some reading about max_input_vars and DDOS, it was enlightening. Now I understand the emails I get from WordFence about increased attack rates with increasing numbers of $_POST values. Quite honestly, I was not aware of the reason for PHP to limit this, but now I know something new I did not know yesterday.

    At any rate, a good security plugin, like WordFence does a decent job a blocking these types of attacks, and depending on what country they are coming from I simply block the IP address permanently.

  • ACF works more simply than other “page builders”. ACF is not really a page builder. ACF works by sending all of the data in $_POST in a single request. Other systems use AJAX to update data as you work, ACF does not. ACF is built on the idea of using only what core WP offers for managing custom fields. It does not do anything that you could not do by creating and managing your own custom fields with your own processing using WP add_meta_box().

    I routinely set max_input_vars to 10,000 or even higher on ACF heavy sites. But 10,000 is my general starting point when I’m building a custom site using ACF.

    This plugin has not been updated in a long time, but it still work, and give a warning when the inputs on a page exceed max_input_vars https://wordpress.org/plugins/wp-max-submit-protect/

  • There are too many possibilities.

    The most likely reasons for a field not saving are

    – There is another field with the same name
    – the php setting max_input_vars is preventing the submission of the field.

  • Things like this are generally caused by your server’s php max_input_vars setting https://jonathannicol.com/blog/2014/03/02/wordpress-custom-fields-not-saving-phps-max_input_vars-may-be-to-blame/

  • This plugin, while it has not been updated in a long time, will still work to detect if max_input_vars is the issue.

    https://wordpress.org/plugins/wp-max-submit-protect/

  • We’re hosted on WP Engine, who says this about max_input_vars:

    Max Input Vars

    The default max_input_vars setting is 10000, indicating no more than 10,000 variables can be attached to any request.

    This setting cannot be adjusted, as this is set at a platform level and higher values will have negative performance implications.

    Granted, 10,000 seems like it should be enogh. Hmm.

  • I don’t have any other suggestions. 99% of the time when values are not updating it is a symptom of the php setting max_input_vars not being set high enough.

    max_input_nesting_level can also be an issue if you have repeaters that are deeply nested, but this is rare.

    There may also be other server settings that also deal with these dependent on your hosting environment, but I don’t know the specifics of these.

    There have also been reports in the past of issues with caching of different types that cache admin values, but this should also be rare.

    Unfortunately, beyond this there isn’t much I can do to help you other than the basic “deactivate other plugins” and “try a different theme” to see if you can locate a conflict of some kind.

  • The only thing that I have seen that can cause this is PHP max_input_vars. Your value seems large enough, but I don’t know. Please try installing this plugin and then seeing if it gives an alert. I know the plugin says is has not been updated in a while but it still works. https://wordpress.org/plugins/wp-max-submit-protect/

  • Hi, I have increased the value of PHP max_input_vars but still, it’s not saving the fields value.

  • No, there is no limit to the number of field groups or fields. If you are having an issue with saving on pages with a lot of fields it may be because of php max_input_vars

  • There isn’t really any way to tell from what you’ve supplied. It could really be many things.

    I would start with the basic WP debugging steps. Deactivation of other plugins and changing theme to see if you can figure out is something else is causing it.

    My first thought when you say “migrating to ACF” is that you have other fields with the same names as the ACF fields, this could cause the problem.

    Another issue could be that you are exceeding the php setting max_input_vars on your server.

    All of these are just guesses.

  • You have 400 rows with 10 fields each, that is 4001 fields including the repeater itself. This does not include any other fields on the page.

    max_input_vars is not high enough, but I doubt that is the cause of your issue. This setting being too low would mean that not all of the data would be updated as expected. Missing input might cause the error, but from experience I would say not.

    More than likely you are seeing the save time out during the process of updating all of those fields. A browser will time out after about 30 seconds and this is not affected by max execution time. The server will continue to process even after the browser indicates a timeout.

    400 rows is a lot and I would have looked at other ways of storing this data than a repeater field if this number was expected.

    But there are cases where it cannot be avoided. I have a plugin that I use for this type of problems https://github.com/Hube2/acf-prevent-timeouts

Viewing 25 results - 1 through 25 (of 177 total)
1 2 3 … 6 7 8