Hey @keithlock ,
I’m jumping in here 5 years later because I discovered a glitch (maybe a JS conflict) while using the filter of your suggestion.
Have a repeater field with a few subfields, try setting those input fields ‘disabled’ by add_filter (or even using a jquery script loaded in admin from your theme).
Set a bunch of rows with dummy data into “hello world” post.
Now try to drag and switch places between two rows, and update your post: sometimes data are literally switched between rows, sometimes rows disappear at all.
Try also to start over, this time delete one row from top or middle of the group, and update post again: the row you chosed to remove is still there while the last one of the group has gone.
I made some tests and the glitch seems to stop when I stop keeping fields ‘disabled’.
I’d love to offer a brilliant solution as well, but I’m not skilled enough.
Have you got some suggestion how to solve this?
I just found out why that happened and how to avoid this behaviour, here:
https://support.advancedcustomfields.com/forums/topic/disabled-readonly-field-in-repeater/#post-68179
set the field to “readonly” (required to avoid weird reaction of ACF when trying to save a JS disabled input)
please note that disabled field are not saved and it is better to use radonly to keep your data
Hope this helps someone in the near future. 🙂
Stumbled upon this report after a couple of hours struggling, can confirm the same issue with WP 6.01 / ACF 5.12.3
I’m using ACF with a calendar PHP script and I need to use
date_default_timezone_set(‘Europe/Rome’);
in one of my functions.
This results literally in a datepicker value that, when retrieved from that function
get_field (‘my_date’, $post_id); //format Y-m-d
// * * * output: 2022-07-06`
while if edited in the original post field or even in the database record is:
// * * * output: 2022-07-07
EDIT: as per this other thread, it looks like a WordPress core issue
