Support

Account

Forum Replies Created

  • I found a bit cleaner solution that doesn’t require the basic uploader – use the nice uploader and just stop the Media Library itself from loading.

    
    // Conditionally don't load the Media Library tab/ content
    function remove_medialibrary_tab($strings) {
    	if ( !user_is_admin() ) {
    		unset($strings["mediaLibraryTitle"]);
    		return $strings;
    	} else {
    		return $strings;
    	}
    }
    add_filter('media_view_strings','remove_medialibrary_tab');
    
    // Conditionally don't run the Media Library's initializing AJAX
    function restrict_non_Admins(){
    	if( !user_is_admin() ){
    		exit;
    	}
    }
    add_action('wp_ajax_query-attachments','restrict_non_Admins',1);
    add_action('wp_ajax_nopriv_query-attachments','restrict_non_Admins',1);
    
  • That seems to have fixed it! The post_title field now has all of the correct attributes and it appears everything is saving correctly on both my live site and test site. Thanks a million, John!

    My test function from above now works and looks like:

    
    function test_cms_form() {
    	echo "In AJAX";
    	_acf_form_register_fields();
    	acf_form( array('post_id'=>14,'post_title'=>true) );
    	die();
    }
    

    I wonder what happened in the 5.4.0 update that made this addition necessary (that seems to be the first version where post_title wasn’t rendered properly) and if this is a fix that can be implemented in a future release to ensure it works for others.

  • Yep, they suggested disabling all plugins, etc. Waiting to hear back again after I tried that and reported back with same results.

    No problem, thanks for looking at it!

  • That’s more so related to interactive JS on the form not working. That’s an issue I’ve run into in the past and actually that exact post helped in that case, but this is a different issue.

    It seems like the problem here is related to the actual rendering of the form elements. Unless maybe some JS is removing the attributes after output, but that seems fairly unlikely since all of the other fields render and save correctly.

    I get the impression I’m experiencing the same issue that’s noted as being fixed in the 5.4.2 update, just applied to an AJAX loaded form.

  • I did some more testing – I’ve deactivated all other plugins and had the same results. I then stripped down my AJAX call to the bare minimum and ran it in a single-site WP v4.6 install (separate website, running a bare-bones theme, ACF v5.4.4, no other plugins) – same issue as above

    Here’s the relevant PHP & JS:

    
    // in functions.php
    add_action( 'wp_enqueue_scripts', 'add_scripts_styles' );
    function add_scripts_styles() {
    	$reqScripts = array('jquery');
    	wp_enqueue_script( 'cmsAJAX', get_template_directory_uri() . '/js/script.js', $reqScripts, '1.0' );
    	wp_localize_script( 'cmsAJAX', 'myAjax', array( 'ajaxurl' => admin_url('admin-ajax.php')) );
    }
    
    add_action("wp_ajax_test_cms_form", "test_cms_form");
    function test_cms_form() {
    	echo "In AJAX";
    	acf_form( array('post_id'=>14,'post_title'=>true) );
    	die();
    }
    
    // in script.js
    (function($){
    $(document).ready( function(){
    	do_test_form_ajax();
    });
    function do_test_form_ajax(){
    	
    	var data = {
    		'action'		: 'test_cms_form'
    	};
    	$.ajax({
    		type		: "post",
    		dataType	: "html",
    		url			: myAjax.ajaxurl,
    		data		: data,
    		success	: function(response) {
    			$( 'body' ).show().append( response );
    		},
    		error	: function(xhr, ajaxOptions, thrownError) {
    			$( 'body' ).append( "AJAX error" );
    		}
    	});
    	return false;
    }
    })(jQuery);
    

    Here again, the post_title field displays with no name, id, class, or placeholder attributes set. Specifically the attribute words show up in the Inspector, they just has no value (see prior post code).

    Any ideas?

  • acf_form_head() helps with the actual saving of the form. For me the issue is that the post_title input field is displayed on the page without a name attribute set, so the data isn’t submitted with the form.

    I did some more digging and for me, it’s an issue that appears strictly when the form is loaded via AJAX, so I’ve made a separate forum topic documenting it more fully, found here.

  • I’m running v5.4.4 and still experiencing this.

    Is it documented somewhere where exactly the 5.4.2 issue/ fix was so I can check it on my install?

  • This seems to finally have been fixed in ACF Pro Version 5.2.0, for the most part. Send a never-valid ID as the post_id for new posts (like -5) and then check for the when you save the post. You’ll need to manually save the post, or add to the acf/pre_save_post filter as described here: http://www.advancedcustomfields.com/resources/using-acf_form-to-create-a-new-post/

    It doesn’t work when sending a string as the post_id still using acf_form, but when editing you’re sending an int so it seems to work.

  • I’m having this issue as well. I have my field set to only show media uploaded to the post, but on the frontend it’s showing all media items. This, for me, only happens when I’m making a new post on the frontend – always in the admin and when editing a post on the frontend it works as expected.

    Knowing that it works when editing, I’ve been playing around with the attributes sent to acf_form, specifically, post_id. When I set it to 'new' or 'new_post' like the guides say, it doesn’t work – however, when I set it to false for new posts it seems to show the library correctly! This, however, then makes ACF send the post ID from the page displaying the form to acf/load_value when it should be false or blank to indicate it’s a new post. It also makes it impossible to save the new posts..so yeah.

    Anyone figure out what going on here?

  • I believe I’ve found an actually really simple solution for this – set $value to an array of your default values inside the acf/load_value hook.

    add_filter('acf/load_value/key=field_54aa5b3b008b0',  'afc_load_my_repeater_value', 10, 3);
    function afc_load_my_repeater_value($value, $post_id, $field) {
    	if ($post_id === false) {
    		$value	= array();
    		$value[] = array(
    			field_54aa5beb008b1 => 'Hours',
    			field_54aa5c25008b2 => 1
    		);
    		$value[] = array(
    			field_54aa5beb008b1 => 'Minutes'
    		);
    		$value[] = array(
    			field_54aa5beb008b1 => 'Seconds'
    		);
    	}
    	return $value;
    }
    

    I have more details on this post.

  • This has been bugging me for quite a while, but I think I’ve finally cracked it. It was almost disappointingly simple in the end – $value needs to be an array.

    
    add_filter('acf/load_value/key=field_54aa5b3b008b0',  'afc_load_my_repeater_value', 10, 3);
    function afc_load_my_repeater_value($value, $post_id, $field) {
    	if ($post_id === false) {
    		$value	= array();
    		$value[] = array(
    			field_54aa5beb008b1 => 'Hours',
    			field_54aa5c25008b2 => 1
    		);
    		$value[] = array(
    			field_54aa5beb008b1 => 'Minutes'
    		);
    		$value[] = array(
    			field_54aa5beb008b1 => 'Seconds'
    		);
    	}
    	return $value;
    }
    

    This case is pretty straight forward; I have one repeater field field_54aa5b3b008b0 that has two text fields inside it (field_54aa5beb008b1 and field_54aa5c25008b2). I imagine the same setup will apply to more in-depth scenarios as well with some tweaking.

    Step 1. Hook into acf/load_value on your repeater field. You can use type/key/name as desired here.

    Step 2. Check if the $post_id is set or not. If you want to modify the values of existing posts as well you wouldn’t need to, but here I want to set default values for new posts only.

    Step 3. Set $value to your array of default values. Above, I have 3 rows by default on new posts. Each row has two values – ‘unit of time’ and ‘amount of time’. The ‘unit of time’ values are set to “Hours”, “Minutes” and “Seconds”. The ‘amount of time’ value on the “Hours” row I have set default to 1. In the other rows, I didn’t want the second value to be set by default, so it’s omitted – if omitted, ACF uses the default value set in the admin (or just blank).

    Step 4. Return the $value. Make sure you always return it – even if you haven’t modified it.

    ———– NOTES
    – I’m using ACF Pro 5.1.8, but it should work in other versions as well (using the proper hooks as needed).
    – The sub fields appear to be required to the the exact field key – field name and type haven’t worked for me.
    – Above, I’m setting a static set of values as my defaults. You could certainly call a function or otherwise dynamically load an array into $value from elsewhere as well – just need to make sure it uses the key for sub fields.
    – If you’re not sure how the array should be set up, just print out an array from an existing repeater in the wp-admin like this:

    
    add_filter('acf/load_value/key=field_54aa5b3b008b0',  'afc_load_my_repeater_value', 10, 3);
    function afc_load_my_repeater_value($value, $post_id, $field) {
    	echo print_r($value);
    	return $value;
    }
    

    This will print out the repeater value from an existing post. Save the post with some rows in your repeater and you’ll see a guide of how to set up the array of defaults.

  • If anyone else is having issues here, the specific fix that worked for me is:

    	//	$(document).trigger('acf/setup_fields', $("#"+ formID) );
    		acf.do_action('ready', $("#"+ formID) );
    
  • As an update, this appears to be in the default ACF with a action hook now. For example:

    
    add_filter('acf/load_field/key=field_12345678', 'acf_create_select');
    function acf_create_select( $field ) {
    	$field['choices'] = array();
    	$choices = get_my_options();
    	foreach( $choices as $t ) {
    		if ( !isset( $field['choices'][ $t->optgroup ] ) )
    			$field['choices'][ $t->optgroup ] = array();
    		$field['choices'][ $t->optgroup ][ $t->item_value ] = $t->item_text;
    	}
    	return $field;
    }
    
Viewing 13 posts - 1 through 13 (of 13 total)