Support

Account

Register Login

Forum Replies Created

  • Is there a way to restrict the editing of specific ACF fields — in particular, just the ones I create in my theme or plugin? I have a theme I support on single and multisite networks, and using this approach lets me make sure individual site admins can’t mess up the JSON ACF field definitions in multisite networks, but it also is a pretty big hammer — it blocks site-level admins on multisite networks from editing any ACF field groups at all, even if other plugins/local custom work is intended to be done in the ACF GUI.

    Have you ever considered extending the ACF JSON feature so that on multisite networks, it would allow changes to ACF Field Groups that would be site specific, and not network wide, at least as an option? I could see this just extending the current approach, by creating site-id based subfolders in the ACF-JSON folder, and then reading/writing changes done at the local site level to those JSON files, and only let the network admin make changes that would be applied to the core JSON files.

  • I doubt it’s as easy as a typo, but…

    ($_POST[‘acf’][‘field_123456789a’]_[‘field123456789b’])

    Check the real code and make sure that underscore isn’t actually there between the two bracketed key refernces, so:

    ($_POST[‘acf’][‘field_123456789a’][‘field123456789b’])

  • This reply has been marked as private.

  • 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:”);
    ob_start();
    var_dump(get_post_meta($post_id));
    error_log(ob_get_clean());

    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? 😉

Viewing 4 posts - 1 through 4 (of 4 total)