Yeah, that’s what I ended up doing to get the project wrapped today.
I did a quick grab and dump of get_post_meta() to the error log from within my acf/save_post function, then watched it to see which of the many variables was the one acf was actually using. I realized I’d need to do that after I noticed moving fields into a new group for an existing custom post doesn’t actually clean up any of the old post_meta values– it just leaves the old post_metas there, creates new ones and starts using them. I think it may even have left/used the same ACF key_hashvalue in there, so now it appears twice in the post_meta (one of the reasons I was concerned about just using update_post_meta and similar WP functions instead of leveraging an ACF function to manage grouped fields).
By the way, in case anyone else runs into this, @keithlock is spot on. ACF, when creating page_metas for groups, does so in the format:
group_pretty_name . “_” . field_pretty_name
In case anyone else runs into this problem and wants to dump stuff to the log to watch what’s going on during your custom function hooked in to acf/save_post, I found this little snippet super helpful (wish I had recorded what site/who I grabbed it from, but in my rush to solve this problem I forgot to — needless to say, not my original code solution here 😉
error_log(“Meta values of post:”);
Since all this stuff is happening at a point you can’t just echo the returned value of a get_post_meta() var_dump to the screen, I had to look up that little gem to get the var_dump into the log.
The value does get dumped as one long string, but if you bring it into regular expression compliant application like notepad++, you can do a reg ex find/replace for \\n to \r\n and quickly have a human readable dump of the page_meta to scan and find what ACF is doing where.
Updating the post_meta value directly is currently working fine (so far as I can tell– I have my acf/save add_action priority set to the suggested level of 20… doing it at other priority levels might cause some oddness…). But I’d much prefer an ACF native way of doing this, which so far as I can tell, doesn’t currently exist. I’m a little concerned about the direct update_post_meta (and in another location, delete_post_meta) that I’m using currently to work around this, since a quick google search of acf update_post_meta|delete_post_meta turns up all kinds of threads where people (and some acf support folks/devs) seem to be waiving everyone off from doing that, in favor of acf methods (a literal, archaic/original use of deprecation here? 😉
Welcome to the Advanced Custom Fields community forum.
Browse through ideas, snippets of code, questions and answers between fellow ACF users
Helping others is a great way to earn karma, gain badges and help ACF development!