Support

Account

Forum Replies Created

  • I ran into a need for this today. This forum post seems to be a top google hit for my search so I’ll put the solution that worked for me here.

    The filter mentioned by John up above wasn’t able to influence field keys that were not a part of the field group of the field I was targeting.

    I ended up needing to use some of the JS API functions for this. https://www.advancedcustomfields.com/resources/javascript-api/

    In the example code below, I had a button group field with two options, and depending on the chosen option I am showing or hiding a field from another field group.

    There are a few ways to get the field keys, I found the easiest way was just to inspect the HTML on the page, but you could also get them from the GUI in the field group builder, or the ACF JSON files if you are using that.

    // Handle show/hide on ready
    acf.addAction( 'ready', function() {
    	buttonField = acf.getField( 'field_6202e1499e575' );
    	conditionalField = acf.getField( 'field_5e98b383fa39f' );
    
    	switch( buttonField.val() ) {
    		case 'traditional':
    			conditionalField.show();
    			break;
    
    		case 'simplified':
    			conditionalField.hide();
    			break;
    	}
    });
    
    // Handle show/hide when value is changed
    $('input[name="acf[field_6202e1499e575]"]').on( 'change', function() {
    	conditionalField = acf.getField( 'field_5e98b383fa39f' );
    
    	switch( $( this ).val() ) {
    		case 'traditional':
    			conditionalField.show();
    			break;
    
    		case 'simplified':
    			conditionalField.hide();
    			break;
    	}
    });
    
    // I didn't need any of either of these callbacks, but I verified they do get called with the above code
    function showFieldCallback( field ) {
    	console.log( 'show callback fired' );
    }
    acf.addAction( 'show_field/key=field_5e98b383fa39f', showFieldCallback );
    
    function hiddenFieldCallback( field ) {
    	console.log( 'hidden callback fired' );
    }
    acf.addAction( 'hide_field/key=field_5e98b383fa39f', hiddenFieldCallback );

    I hope this helps someone else!

  • It looks like this must have been fixed in the most recent version.

  • Thanks Elliot, I can confirm that with these new JS files, the issue is resolved.

  • This is an old post, but I wanted to share what I think is a better method for anyone else who winds up here.

    I set the ‘post_id’ value of the acf_form function to ‘new_user’ which isn’t a registered value for this function, but we will get to that. It is worth noting that you can really write anything you want here as we override it later, but I think this communicates the intentions of the form well for anyone reading your code.

    acf_form( array(
    	'id'				=> 'register_new_speaker',
    	'post_id'			=> 'new_user',
    	'field_groups'			=> array(
    		'group_5a83681ebf931'
    	)
    ));

    Then I hook into ‘acf/pre_save_post’. I intercept the $_POST data being sent to the server, generate a new user using the submitted data, and then dynamically set the ‘post_id’ of the form to the new user ID.

    function generate_new_user_id( $post_id, $form ) {
    	// Check that we are targeting the right form. I do this by checking the acf_form ID.
    	if ( ! isset( $form['id'] ) || 'register_new_speaker' != $form['id'] ) {
    		return $post_id;
    	}
    
    	// Create an empty array to add user field data into
    	$user_fields = array();
    
    	// Check for the fields we need in our postdata, and add them to the $user_fields array if they exist
    	if ( isset( $_POST['acf']['field_5a83681ec4d01'] ) ) {
    		$user_fields['first_name'] = sanitize_text_field( $_POST['acf']['field_5a83681ec4d01'] );
    	}
    
    	if ( isset( $_POST['acf']['field_5a83681ec4d15'] ) ) {
    		$user_fields['last_name'] = sanitize_text_field( $_POST['acf']['field_5a83681ec4d15'] );
    	}
    
    	if ( isset( $_POST['acf']['field_5a85f62e356bc'] ) ) {
    		$user_fields['user_login'] = sanitize_user( $_POST['acf']['field_5a85f62e356bc'] );
    	}
    
    	if ( isset( $_POST['acf']['field_5a83689da2624'] ) ) {
    		$user_fields['user_email'] = sanitize_email( $_POST['acf']['field_5a83689da2624'] );
    	}
    
    	if ( isset( $_POST['acf']['field_5a83681ec4d36'] ) ) {
    		$user_fields['user_pass'] = $_POST['acf']['field_5a83681ec4d36'];
    	}
    
    	if ( isset( $_POST['acf']['field_5a83681ec4d01'], $_POST['acf']['field_5a83681ec4d15'] ) ) {
    		$user_fields['display_name'] = sanitize_text_field( $_POST['acf']['field_5a83681ec4d01'] . ' ' . $_POST['acf']['field_5a83681ec4d15'] );
    	}
    
    	$user_id = wp_insert_user( $user_fields );
    
    	if ( is_wp_error( $user_id ) ) {
    		// If adding this user failed, deliver an error message. I also do custom JS field validaiton before submit to check for proper email addresses, and to check for duplicate emails/existing usernames. But that code is beyond the scope of this thread
    		wp_die( $user_id->get_error_message() );
    	} else {
    		// Set the 'post_id' to the newly created user_id, including the 'user_' ACF uses to target a user
    		return 'user_' . $user_id;
    	}
    }
    add_action( 'acf/pre_save_post', 'generate_new_user_id', 10, 2 );

    From here out the ACF Form will submit like normal, but now it will save all of the custom fields to the newly created user. I like this method better than what is mentioned above, because the data gets saved directly to the ‘right spot’.

    Interesting thing to note: If you neglect to do the second part with the ‘acf/pre_save_post’ filter, ACF will save the data to wp_options (definitely not what you want to happen here).

  • This is an older post but it came up in my searching for an answer to this problem, so here is my solution:

    if ( 'undefined' !== typeof acf ) {
    	acf.add_filter( 'validation_complete', function( json, $form ) {
    		if ( json.valid && ! json.errors ) {
    			// Do what you need to do here.
    			// json will hold the current validation status. $form will let you access the form elements on the page if needed
    		}
    
    		return json;
    	});
    }

    This solution probably requires ACF 5+

  • The fix I found for my ACF addon uses an event that WordPress triggers after a new menu item has been added.

    Location: /wp-admin/js/nav-menu.js Line #1017
    Event: menu-item-added

    The event passes along the new menu item markup, which can then be searched for any select fields with stylized UI and initialized if found.

  • Not sure. I haven’t ever used the group field actually, but checking it out on the docs now it looks really handy.

    I am currently chasing down some other bugs with the plugin when multiple conditional fields are set it gets pretty cranky.

    I will take a look at this and see if I can figure out what is going on with group fields too.

    To clarify, is the issue during the field creation while setting the conditional terms. Or is the issue when the fields are being used to enter content while editing a page/post/etc.

  • @mkeys Thank you! This working fine on Advanced Custom Fields PRO v. 5.5.11

    Wonderful!

    Can we leave you donation somewhere? I’d like to think everyone on this post would be happy to throw a little at your skill and generosity.

    That would be very kind. I looked into making a donate button with paypal ( Donate via PayPal form ). It asks for stuff like shipping information which is silly, so if you’d rather just paypal me directly, my paypal email is: [email protected]

  • I ran into this need today and put together a plugin that allows for selection of taxonomy fields and terms in the conditional rules.

    https://github.com/mattkeys/ACF-Conditional-Taxonomy-Rules

    Currently this is written only for ACF v5. I am unsure what it would take to also support v4 and if I plan to do that.

    It should be as simple as install, activate, and start selecting taxonomy fields and terms as needed in your conditional fields.

    Try it out and let me know if you run into any bugs! If it works well for others I will likely release this on the WordPress plugin repository (Unless Elliot wants to roll this functionality into core.

  • I think that is a much better and more secure way of handling this, and less complicated than trying to do anything in wp-admin area that stores to the DB. Great idea.

  • I can tell you how I worked around this issue.

    The docs for acf_form have you add a function called acf_form_head() right before the get_header() function on pages where you want to use acf_form().

    Instead of adding that function, I added my own variant of acf_form_head(). In my variant, it doesn’t use that base_64 encoded string to figure out the settings. Instead I have a hard-coded array with the setting that I want to enforce with this form.

    Here is some example code that might get you started:

    https://gist.github.com/mattkeys/ad9c068fd8176d3dd7b78808828911a1

    I hope this helps you in the meantime while this hopefully gets resolved more officially in a future ACF update.

  • Yea I thought about using the clone field prefixes to work around this, but thought I should report it here since it seemed like a bug to me.

    I guess whether or not this is a bug is open to interpretation and Elliot will have to decide.

    Personally I feel that an individual subpage should be treated uniquely from other sub pages. This might require that values from that subpage be retrieved a bit differently, like perhaps: the_field( ‘field_name’, ‘subpage-slug’ ), instead of the_field( ‘field_name’, ‘options’ ). Or maybe the_field( ‘field_name’, array( ‘options’, ‘subpage-slug’ ) ).

    In the meantime I will work around this and leave it to Elliot and team to decide if this is a bug or a feature 😉

  • After some more searching I discovered everything that I needed is already included in the current version.

    Filters:

    acf/format_value
    acf/load_value

    Function:

    acf_get_row()

  • I am experiencing related/similar issues on 5.2.0.

    We have a couple of custom taxonomy metaboxes that appear on the right side of our new post/page screens.

    Clicking any of the checkboxes in the metaboxes cause some of the taxonomy metaboxes to disappear. Clicking another checkbox will generally toggle them back on.

    Rolling back to version 5.1.8 resolves the issue for now until this can be addressed in 5.2.x

  • It sounds like this may have been fixed in the latest update. From the changelog:

    Gallery field: Added attachment_fields_to_save filter for 3rd party custom field support

    I haven’t had a chance to test yet though.

  • No problem, glad it helped you. Hopefully @elliot can incorporate it soon.

    Also, Tarheel huh? I am in Raleigh.

  • Any update on this?

    These custom attachment meta fields are being displayed properly (line #357 of /pro/fields/gallery.php)

    However without the fix I outlined above, changes to custom meta fields are never saved to the database.

    If ACF isn’t going to properly save the data from these fields, then they shouldn’t be displayed to begin with. But obviously the better solution is simply to call the ‘attachment_fields_to_save’ filter as I outlined above.

    I have this working on a project however until this fix gets included into ACF it will be overwritten with every new update.

  • I added the following code onto line #194 of /pro/fields/gallery.php

    $post = apply_filters( 'attachment_fields_to_save', $post, $changes );

    That seems to do the trick. Would be great to have this added into the next release of ACF

  • In the meantime while this vulnerability is addressed officially, I have found a solid workaround for myself.

    I made a duplicate of the acf_form_head() (renamed of course) and put it into my plugin.

    I kept everything the same, except that instead of reading the values of the ‘_acf_form’ field from the $_POST data, I rely on my own hard coded values in my version of the function.

    This allows me to still utilize the great ACF field types and functionality, without allowing people to modify the functionality of the form beyond the scope I defined.

  • Perfect! I had completely missed the JS example in that repo, and it covers exactly the issue I was having with acf/setup_fields. It looks like it was replaced with a ‘ready append’ action.

    Thanks Hube2!

  • Hube2,

    The JS trigger I am asking about is acf/setup_fields. This is triggered when ACF fields are added to a wordpress post/page. And re-triggered every time new fields are added such as in a repeater.

    The post you linked to is talking about issues with a different action (the php action acf/register_fields which used to be used in v4 when adding new field types).

    Unless I am missing something, the pages you linked to are not related to my question (although I do appreciate your effort to help). Please correct me if I am wrong and I am missing something.

    Thanks,

    Matt Keys

  • The issue with using teh sidebar area (without the external resource plugin) is that users will attempt to insert an image from a url, but this does not add it to the media manager and won’t work with ACF.

    Yes that makes sense, it is really only once you get into a highly customized situation like mine that the need for this arises.

    Perhaps the best solution is to add a JS filter on the args so you can customize them for the image field?

    Yes I think something like this would be perfect.

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