Forum Replies Created

  • I don’t see the wp-config concern as enough of a reason to prevent this given how many other plugins and values such as DB credentials are already following that pattern.

    It would be great if WP supported .env files natively, it’s definitely the proper place for config values.

    Agreed. Until that is part of core, using isn’t that much overhead as an included composer package. The team has a good write-up of how they’ve incorporated into their repo structures, build pipelines, etc. But chances are if wp-config has been committed with values to git, adding a composer dependency may be beyond the same user base :/

  • The following snippets have served me well to store meta revisions on a front-end post save. Note that if your ACF group is very large this can have very large impacts on your DB and post save performance. YMMV. I have not tested it for WP > 5.0

    I believe I sourced the initial concept from a different thread here but cannot locate at the moment.

    //ACF - Extend ACF Save Behaviour to ensure front-end saves trigger revision
    add_action('acf/pre_save_post', 'pre_save_post_update_revisions');
    function pre_save_post_update_revisions($post_id) {
    	// bail early if editing in admin
    	// ACF already handles admin revisions correctly
    	if (is_admin()) {
    	  return $post_id;
    	// force a post update, this will generate a revision and
    	// trigger the '_wp_put_post_revision' action
    	$update_post = get_post($post_id);
    	$saved_revision = wp_save_post_revision( $update_post );
      	return $post_id;
    //ACF - Extend ACF Save Behaviour to ensure revisions include meta
    add_action('_wp_put_post_revision', '_on_wp_put_post_revision');
    function _on_wp_put_post_revision($revision_id) {
    	// get the revision post object
    	$revision = get_post($revision_id);
    	// get the id of the original post
    	$post_id = $revision->post_parent;
    	// bail early if editing in admin
    	if (is_admin())
      	//For Non-Admin Cases - ensure the meta data is written to revision as well as post
    	if (!empty($_POST['acf'])) {
    	  	foreach ($_POST['acf'] as $k => $v) {
    			// bail early if $value is not is a field_key
    			if (!acf_is_field_key($k)) {
    			update_field($k, $v, $revision_id);
    			update_metadata('post', $revision_id, $k, $v);
  • For those who aren’t afraid to write a little bit of JS to self-solve their problem. I put together a blog post explaining this – – and specific JS Gist for reference.


  • FYI – When using @joelstransky snippet with the
    Component Field Add-On, I do get similar errors to what @et3rnal posted. It looks like the $_POST[‘acf’][$v] index is not being properly identified for sub-fields within the component. I’ve cross-posted support request to the vendor page in link above, but thought I’d double up here in case anyone has suggestions to resolve.

  • Works on my environment, no errors noted.

    @joelstransky 1000x thank you for an elegant solution!

  • The feature plugin WP-Post-Meta-Revisions is what you need. With it active, changes to meta will be stored / saved as a full revision. The diffs do show, but perhaps not quite as elegantly as you’d like as they use field_key.

  • The feature plugin WP-Post-Meta-Revisions is what you need. With it active, changes to meta from the front-end forms will be saved in / as a full revision.

    If you want to present a revision (with all it’s meta at the time of revision) on the front-end, make sure you identify the revision ID (as post ID) to the ACF functions like have_rows and get_field_object.

  • Correction – As long as you pass the revision ID (as post ID) to functions like get_field_object and have_rows, you don’t need to change much front-end logic for presenting revisioned meta on the front-end either.


    This “Feature plugin” will eventually be merged into WP Core and addressed some of the issues you highlight.

  • You’ll need to have – or at least until it becomes part of core to enable meta field changes triggering revisions.

    That helps for everything “back end” but does not let you present any of the revisioned meta on the front-end. This SQL might give you a starting point

    SELECT * FROM wp_postmeta WHERE post_ID = [dynamic] AND post_ID IN (SELECT ID FROM wp_posts WHERE post_type = 'revision') ORDER By meta_key;

  • This is multiplied by having layouts within tabs that may also have validation errors. The snippet below is by no means perfect, nor certain to cover every case of layout / repeater / tab / etc, but it is a starting point that you could work with:

    jQuery(".acf-error-message").closest(".layout").find(".acf-fc-layout-handle").css("background", "red");

    You’d need to get it to fire as a part of or after the ACF validation adds the error code into page.

  • With TEC 3.5.1, ACF 4.3.7 and WP 3.9 I am getting a similar JS error again.

    The following snippet works to resolve a similar issue with the jquery-ui-datepicker dependancy. It does de-activate the datepicker, which in my particular use case is not needed. I’m not sure why the conflict occurs in the first place either – but hopefully it helps for another future version to resolve conflict.

    wp_dequeue_script('acf-input' );
    wp_register_script('acf-input', '/wp-content/plugins/advanced-custom-fields/js/input.min.js', array('jquery', 'jquery-ui-core'), '4.3.7');
    wp_enqueue_script ('act-input' );
  • This reply has been marked as private.
  • Solved. I had the register_field_group in plugin tied to admin_init instead of init.

    As a future enhancement to the plugin, I might suggest a section to the admin page that lists field groupings which are created via plugin / theme for reference.

  • And the code (which doesn’t display my form) on template:

    $args = array('post_id' => 'new', 'field_groups' => array('acf_photo-gallery-details'));
    acf_form( $args );

    In other templates I do have the call to acf_head(). I do see the Update button display and when inspecting source the rest of the hidden fields and form. But no actual fields.

  • FYI – The support forum found a resolution for issue with a snippet to de-register the acf-datepicker that, according to them, is conflicting with the use of standard jquery-ui-datepicker. From :

    What is happening is that ACF is using it’s own custom datepicker, enqueued with “acf-datepicker”. The thing is, it conflicts with WP’s ’jquery-ui-datepicker’, which is basically the same thing only it is provided by WordPress. Our plugin uses ’jquery-ui-datepicker’ to avoid conflicts just like this. Other plugins need to be using the scripts that WordPress provides, as this limits conflicts and optimizes the site loading times. Unfortunately ACF is not doing this.

  • This reply has been marked as private.
  • Digging deeper I found that in addition to their specific event page types they also wrap inside a more general template – /wp-content/plugins/the-events-calendar/views/ecp-page-template.php – that you can copy into your theme and customize presentation of. That does make a call to get_header() that I can put the acf_form_head() in front of.

    I’m still left with two JS errors:

    • TypeError: e.fn.datepicker.noConflict is not a function calling from wp-content/plugins/the-events-calendar/resources/tribe-events.min.js?ver=3.4.1
    • TypeError: g is undefined calling from /wp-includes/js/tinymce/tiny_mce.js?ver=359-20131026

    Cross-posted onto the support forum for plugin conflict impact –

  • Only on the front end.

    I’m using the gallery add-on which I purchased purely for the front-end ability to batch upload photos with the standard media upload UI. The gist of the rest of process (which is working):

    • ACF adds a select field to event post type that is populated with Gravity Forms for admin to select which registration form to use. That is displayed on upcoming events via template.
    • Create a CPT for galleries
    • ACF provides meta fields on gallery (eventID, photographer, email and multi-photo from add-on.

    The last piece is having the ACF form show up on event to allow batch upload of photos which is limited by the issue described above.

    I have a temporary workaround of putting a separate the photo submission form onto a separate page that populates the eventID via select field populated with past dated events. But requirement is that everything stays tied to the individual event along with comments, post-event feedback (GF) form.

  • Yes. It applies to a _ anywhere within the field name too.

  • Issue: Field Group location rule is being stored to database but is NOT being shown as selected when viewing the Field Group.

    Steps to reproduce:
    1) Go to Custom Fields menu
    2) Select Add New Field Group from top of page. Title: Gallery Details
    3) Create fields (XML at bottom of this post)
    4) Select Location Rule = Show this field group if Post Type is equal to gallery.
    5) Publish Field Group.
    6) Go to Gallery Post Type edit screen and the ACF form is there.
    7) Go back to Field Group and Edit Gallery Details.
    8) The Location Rule defaults back to Post Type = post.
    9) If I update anything in the field group and do not also re-change the location rule back to Post Type = gallery, the ACF form will be moved from gallery CPT to post.

    I *believe* the issue is related to my initial choice to use _ in my field names (gallery_photo, gallery_event, gallery_photographer) causing the location group to return to default.

  • #2 has been resolved thanks to this thread – – about pre-populated values with _new in the options table.

  • 1) When I go to the Custom Fields edit screen and change the location rule my group applies to CPT (gallery) it will save to that type. All subsequent form entries go to the CPT. But when I go back to the custom field edit screen, the drop-down displays as default post. Essentially every time I go back to the form I have to manually change the location back to CPT option.

    2) With acf_form_head(); above get_header() call in a child theme of in a very vanilla page template I have the following:

    $args = array(
    'post_id' => 'new',
    'field_groups' => array( 252 )
    acf_form( $args ); 

    3) Unfortunately it’s all in local dev atm. But followed very closely to the instructions from for it. Dev environment is a vagrant VM and Capistrano/Composer stack based on bedrock mostly.


  • Changed my local dev environment from VVV to a more generic lamp vagrant setup and the issue has gone away. Not sure what the direct cause in that mix is but happy that it is no longer affecting me.

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

We use cookies to offer you a better browsing experience, analyze site traffic and personalize content. Read about how we use cookies and how you can control them in our Cookie Policy. If you continue to use this site, you consent to our use of cookies.