Support

Account

Register Login

Home › Forums › Add-ons › Repeater Field › Repeater not saving on some pages, but works on others?

Solved

Repeater not saving on some pages, but works on others?

  • Peculiar problem happening with the Repeater Field plugin:

    I’m using the Repeater Field on a few different sections of my website. For the FAQs section, the data is organized as separate repeater fields nested into a larger repeater field. When I try to update that Page, it saves the data just fine, no problem.

    However, on my Retailers page, I have a single repeater field which holds multiple text fields (store name, address, phone, etc.). Whenever I try to add a new entry on this page, it doesn’t save my data. There is only one entry on that page, and I’m just trying to add a second entry, but it won’t save.

    Summary: the Repeater Field plugin is working on some sections of my website, but not others. It’s not saving data when I click “Update.”

    Has anyone encountered this problem? Any help?

  • Hi @retorial

    It is possible that you are hitting a server limit which is Causing the save function to terminate early.

    How much data are you trying to save?

    Have you checked your server logs for any clues?

  • Thanks for the quick reply, @elliot.

    I don’t believe it’s a server limit. The amount of data I’m trying to save is very small. The only data on the Page (the only data I’m saving) is two instances of a single Repeater Field. Each instance of the Repeater Field contains 9 text fields (retailer name, address, city, state, phone, etc.).

    Whenever I try to add an additional Repeater Field instance, it doesn’t save the new entry upon hitting “Update.” As I said though, it works fine on other sections of my site. It’s only the Retailers section that isn’t working.

    Just a little more info: my retailers section is broken into separate pages, organized by region. New York, Florida, Germany, United Kingdom, France, etc. and each of those separate Pages contains the Repeater Field form. Each page only has a few instances (2 – 3) of the “Retailers” Repeater Field.

    In other words, France for example only lists three retailer locations. It’s not a lot of data.

    I’ll also add this: if I add all the relevant data manually (retailers_1_name, retailers_1_address, retailers_1_city, etc.) using WordPress’s Custom Fields box, everything works fine and it saves the data. It’s just not saving the data when I use the Repeater Field input box.

    I’ll also say that it used to work fine a few months ago (the last time I tried updating the Retailers section). And again, it’s only my Retailers pages that aren’t saving properly, but the other sections where I use the Repeater Field plugin work fine. FAQs, Color Chart, etc.

    Any thoughts based on all this information?

    Thanks again.

  • Hi @retorial

    Thanks for the info.

    We can definitely rule out a server limit issue, but this leaves us with the very annoying ‘plugin conflict’ issue.

    There is a chance that another plugin / theme code is conflicting with ACF and causing the save function to not run.

    Can you turn on debug mode and save the location. Do any errors appear which would stop the save?

  • Hi @elliot — no errors were returned with the debug mode set to true. I also took a look at the database and can confirm that no new post meta is being inserted into the _postmeta table upon saving the retailer pages.

    Here’s something very peculiar though…

    If I create a new page (titled “Testing Page”) and include the troubled ACF “Retailers” field on that page, it works fine on the new “Testing Page.” It’s just not working on the existing retailer pages (it used to work fine a few months ago). It shows the previous, existing retailer entries on each respective retailer page, but it’s not saving the new entries. Whereas, again, it works fine on the newly added “Testing Page.”

    Furthermore, if I edit the content field (the main WordPress content field) on the retailer pages, those changes get saved. It’s just not inserting the post meta via the ACF Repeater field into the _postmeta table on the retailer pages.

    It really is very peculiar. Any other thoughts?

    PS. Despite this strange Repeater field problem, ACF is a really great product — excellent work, man!

  • Hi @retorial

    There us something on the ‘original page’ which is stopping ACF from saving.
    I’m not sure what the issue is without doing some thorough debugging.

    Are you able to debug the problem? I would first locate the save_post function in acf.php / controllers/input.php and print out some variables / test if it is running

  • @elliot – yes, I am able to do some debugging.

    I tested the save_post function and can confirm save_post is NOT being called when saving the effected Pages. However, on the test page and other new pages in which the Repeater Fields plugin works properly, the save_post function is being called successfully.

  • I’ve also tested the save_post function in the acf_input class.
    Everything works if I end this function with the exit() command.

    Then when saving/updating the page the page loads as a WSOD (of coarse) then if you us the back arrow on the browser to go back and refresh the page the changes have been made.

    Why this happens I HAVE NO IDEA but this may help with the issue.

    Hope it helps

  • Hi @hillbilly

    In my testing, I actually included an exit() command too, like you. On the pages that are working fine, it performed as expected and exited out of the script (WSOD), but it did not perform on my troubled pages — which means the save_post function obviously isn’t being called for some reason…

  • OK.

    I’m also running the latest version (nightly) of ACF via github and i’ve added the htaccess entries

    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

    Give this a go as well

  • Perhaps a temp fix:

    // lines 30-31 of core/controllers/input.php
    add_action(‘save_post’, array($this, ‘save_post’), 10, 1);
    add_action(‘pre_post_update’, array($this, ‘save_post’));

    It solves the issue for me. I added it to Github to hopefully be stomped in later releases 🙂

  • Hi @Kaitnyl

    Wouldn’t this run the save function twice?
    If so, I don’t think this is an optimal solution as it would take twice as long to perform.

  • Hey @elliot,

    Untested, but I would assume that yes- it would run the save function twice for those posts that are not facing this issue. However, it only runs once for the problematic post that I have.

    I don’t see it as a solution either, tbh, haha. It’s merely a temporary fix for those who may need the ability to edit those fields’ content while the underlying issue is discovered.

  • Hi guys,

    I came across this problem on my site today. We’ve been building the site over the past 2-3 weeks so we’re using the latest version of WP (3.6) and all the latest ACF, ACF Options, ACF Gallery, ACF Repeater, ACF Flex Content Plugins.

    I went through the same steps as @retorial so adding a new page (custom post type post in my case) with the same custom fields block I setup in ACF. The new page saves the data correctly.

    I did a bit of debugging. Like retorial I was getting no errors on save. I disabled the other plugins we use (WordPress SEO, TinyMCE Advanced, Responsive Lightbox, and Gravity Forms). Still no joy. I tried activating the twentythirteen theme, and then twentytwelve theme. Still nothing.

    Then I deleted a repeater field row from the page that wasn’t working and saved the page. Then Added a new repeater field row and saved. This worked. The page that wasn’t working now works.

    I need to test this further and make sure it doesn’t break again but all appears to be OK at the moment. It doesn’t however answer why there is a problem.

    I’ve got a backup of the database pre the above fix. Happy to package the database up for ACF Team to investigate it further.

  • Hi @chrisj

    This really does sound like the website is timing out during the save. I would have a look at your server logs to see if any PHP memory or max vars limits were hit.

    Thanks
    E

  • Hi:

    @elliot
    I was also experiencing this problem, but your suggestion to check the server logs was correct. Here is what I found in my php_error.log:

    PHP Warning:  Unknown: Input variables exceeded 1000. To increase the limit change max_input_vars in php.ini. in Unknown on line 0

    It is because I had an obscene of amount of fields on my page. Luckily I’m working locally so I can adjust max_input_vars. Not so sure about my host though…

  • Thanks @jplew that did the trick! However I wasn’t getting any PHP Warnings in my error log – in fact I’m getting no errors when I save the form which is strange.

    Initially I thought my solution of deleting and re-adding entries worked but I hit the same brick wall a few days later. I had come across max_input_vars previously but it was commented out in my PHP.INI so naively assumed it was Unlimited. Here’s what I’ve added in my .htaccess to fix the issue:

    
php_value max_input_vars 3000
php_value max_input_time 120
php_value max_execution_time 60

    I’ll have to keep an eye on it but hopefully 3000 is high enough to avoid this problem occurring in the future.

    Thanks for all the help guys
    Chris.

  • My repeaters weren’t saving and I think I tracked it down…. I had 3 nested repeaters, in an options-page, and the third and final repeater wasn’t saving.

    WAIT FOR IT!!!..

    The issue is the mysql field length.

    wp_options > option_name

    With a naming convention like this — options_sidebar_builder_0_parent_section_1_sub_pages_1_post_page

    you need to utilize the maximum of 255.

    For me, it wasn’t php memory allocation after all…

  • jacobnollette,
    what do you mean about utilizing the maximum of 255 for mysql field length? What did you change and where? I may be having the same issue as you and would love to know what solved it for you. Thanks!

  • You need a mysql editor or edit the mysql table format with something like Sequel pro for OS X…
    http://www.sequelpro.com

    The problem I had was that the field “length” as described in my previous post was set too low from standard wordpress install. The field was capping the repeater field from entering the full length. Set it to 255, and you’re set. Im not sure which field anyone.. Haven’t had a fresh install in a month or two. Good luck

  • jacobnollette,
    Thanks for the swift reply.. I did figure out what you meant and went into the db and upped the field length to 255. Will this get overwritten when wordpress updates, though? And is that the only change required? Did you not find that there is also code within wordpress that truncates those based on an assumption of a length of 64?

  • My guess is that WordPress avoids major database migrations… So I’m sure they’ll keep their hands off the database fix.

    That was my exact fix. When you re-save your forms, it will save correctly.

  • Had the same issue with getting a repeater field to save on a custom widget. I shortened the repeater field names and that did the trick. Appears to be the same issue/fix @jacobnollette found.

  • I’m having a very similar problem.

    Reading the comments above, I applied all the guidelines and attempts sent
    one that worked was applying the code below:

    add_action (‘save_post’ array ($ this ‘save_post’), 10, 1);
    add_action (‘pre_post_update’, array ($ this, ‘save_post’));

    I did it yesterday, today after over 30 records inserted the problem happened again.

    I have two scenarios in my localhost environment the problem did not occur, but in the production environment the problem happened again.

    I insert new items, I click refresh, the page loads but does not save the data.

    I do not know what else to do.

    Any idea what I can do?

  • I made new tests in the production environment and identified that is recording up to 137 items in the repeater.

    In the custom field setup I increased the limit to 10000 rows.

    Any idea what could be?

    Recalling that in the development environment this problem is not happening.

Viewing 25 posts - 1 through 25 (of 31 total)
1 2

The topic ‘Repeater not saving on some pages, but works on others?’ is closed to new replies.