Support

Account

Register Login

Forum Replies Created

  • These is more in responsive to the thread about disabling dragging only on certain items, but that thread doesn’t allow new replies. I needed to disable dragging/ordering only certain items in a flexible content field. We create these items dynamically when a post is created and want them to remain always at the top. The only solution that worked well was destroying the jQuery UI sortable instance and creating a new one. I’ll post the code for that below, but first here’s what would answer the OP’s question:

    acf.addAction( 'ready_field/key=field_5f6de18aefdd9', ( field ) => {

	let list = $( '.acf-flexible-content:first > .values', field.$el[0] );

	list.on( 'sortcreate', ( event, ui ) => {

		list.sortable( 'destroy' );

	} );

} );

    Here’s what I did to exclude certain items from being dragging and also from being drop targets:

    acf.addAction( 'ready_field/key=field_5f6de18aefdd9', ( field ) => {

	let list = $( '.acf-flexible-content:first > .values', field.$el[0] );

	list.on( 'sortcreate', ( event, ui ) => {

		if ( list.data( 'reinitializing-sortable' ) === true ) {
			list.data( 'reinitializing-sortable', false );
			return;
		}

		list.data( 'reinitializing-sortable', true );
		list.sortable( 'destroy' );
		list.sortable( {
			items: '> .layout:not([data-layout="first_name"]):not([data-layout="last_name"]):not([data-layout="email"])',
			handle: '> .acf-fc-layout-handle',
			forceHelperSize: true,
			forcePlaceholderSize: true,
			scroll: true,
			stop: ( event, ui ) => {
				field.render();
			},
			update: ( event, ui ) => {
				field.$input().trigger( 'change' );
			}
		} );

		$( '> .layout[data-layout="first_name"], > .layout[data-layout="last_name"], > .layout[data-layout="email"]', list ).each( function() {

			$( '.acf-fc-layout-handle', this ).css( 'cursor', 'default' );

		} );

	} );

} );

    Technically, based on the docs, I shouldn’t have to destroy and recreate the sortable instance. I should just be able to do this:

    list.sortable( 'option', 'items', '> .layout:not([data-layout="first_name"]):not([data-layout="last_name"]):not([data-layout="email"])' );

    But that wouldn’t work, so instead I had to use the hacky solution above.

  • I made some updates to the javascript so that it shows a small loading icon inside the preview button until the ajax request is finished. It makes it feel a bit less hacky I guess 😉 For some reason it’s not letting me post it here, so you can get it here: https://pastebin.com/wGNttfSV

  • @hejamartin I totally agree. Not sure why they’ve let it go so long…

    For us this happens on all our sites for all posts, even those with revisions already, so I didn’t add in any checks for the number of revisions.

    Oh also in the javascript that const formData should be let formData.

  • Hey everyone,

    Not sure why ACF hasn’t put more priority on this annoying issue, since it’s been going on for years. That said, I’ve created a workaround. It’s super hacky and not ideal, but it works.

    Basically what this does is intercept the Preview button’s click event, sends the form data to an Ajax function that creates an autosave, and once that’s done it triggers a click on the Preview button. After the first click it removes itself, so it’ll only do this once.

    Here’s the javascript that needs to be included in the admin area:

    jQuery( ( $ ) => {

	let previewBtn = $( '#preview-action .preview' );

	if ( previewBtn.length ) {

		let previewIntercept = $( '<span id="preview-action--trigger" style="position: absolute; left: -1px; right: -1px; top: -1px; bottom: -1px;"></span>' );

		previewBtn.css( 'position', 'relative' ).append( previewIntercept );
		previewIntercept.click( ( e ) => {

			const formData = new FormData( $( '#post' )[0] );

			formData.set( 'action', 'create-preview-autosave' );

			$.ajax( {
				url: ajaxurl,
				method: 'post',
				data: formData,
				cache: false,
				contentType: false,
				processData: false,
				success: () => {
					previewIntercept.remove();
					previewBtn.trigger( 'click' );
				},
			} );

			e.preventDefault();
			e.stopPropagation();

		} );

	}

} );

    And here’s the WP Ajax function that should go in functions.php or wherever you want:

    add_action( 'wp_ajax_create-preview-autosave', function() {
	wp_create_post_autosave( $_POST );
	header( 'HTTP/1.1 200 OK' );
	wp_die();
} );

  • Actually I just updated on a blank WordPress install and the tabs work, so this may be a theme issue.

  • Thanks John. Is there a way to only show these attachment fields when editing a certain field? The additional inputs I would like to add to the media items would only be relevant to that one field, not to all attachments in the media library.

  • In case it can help someone, Relevanssi has an article about this now: https://www.relevanssi.com/knowledge-base/indexing-acf-relationship-content/

  • By the way I also needed to clear the 2nd select’s value when the 1st select changed, so I just added this under the “acf.add_filter” javascript:

    				$( '#acf-field_648b0890a2462' ).on( 'change', function( e ) {
	$( '#acf-field_648b0852a2448' ).val( '' ).trigger( 'change' );
} );

  • Just in case it can help someone, I was able to accomplish this perfectly for my situation using Elliot’s select2_ajax_data filter suggestion and it’s much simpler than the other methods it seems. I have two taxonomy dropdowns and needed the 2nd one to be filtered by the value of the 1st one. @oscarfanatic ‘s solution got me pointed in the right direction and some other code I found online helped clear the rest up.

    Also want to tag @hube2 in case it can help with his awesome efforts of helping people out in the forums.

    Here’s how it works:

    add_action( 'acf/input/admin_footer', function() {
	?>
	<script>
		( function( $ ) {
			if ( typeof acf !== 'undefined' ) {
				acf.add_filter( 'select2_ajax_data', function( data, args, elem, field, instance ) {
					if ( 'field_648b0852a2448' === data.field_key ) {
						data.format_id = $( '#acf-field_648b0890a2462' ).val(); // format_id is a custom property being added to the data object. It can be named whatever you want.
					}
					return data;
				} );
			}
		} )( jQuery );
	</script>
	<?php
} );

add_filter( 'acf/fields/taxonomy/query/key=field_648b0852a2448', function( $args, $field, $post_id ) {
	$format_id = $_POST['format_id'] ?? false; // $_POST['format_id'] is the custom property you created in the javascript above
	if ( $format_id ) {
		$args['meta_key'] = 'format';
		$args['meta_value'] = $format_id;
	}
	return $args;
}, 10, 3 );

  • @hube2 Sorry I missed your reply here. We’re exporting and then importing the field groups. I believe it also happens when duplicating or moving fields. It doesn’t happen consistently so unfortunately we can’t give steps to reproduce it.

    I’m curious, have you not heard anything else about this issue? I assumed other people must be experiencing it, since it’s been affecting both myself and another dev on multiple projects for the last few months.

  • FYI you can also do something like:

    the_field( 'repeater_3_phone' );

    The 3 here is a zero-based index, so this should output the phone field from row 4.

  • @hube2 Do you know if there’s been any progress on this? I use Message fields as a type of container for my own custom output, but it’s stripping out the HTML tags. Or is there a filter besides prepare_field I should be using? I’d rather not have to modify wp_kses_allowed_html.

  • I’m having the same problem on a non-multi-site WordPress install. I guess WordPress has extended this annoying “feature” to all installations.

  • I’m just wondering, since the Label is an optional field, and in this case omitting the label breaks the layout, why wouldn’t this be considered a bug? Shouldn’t ACF check if the label is empty and account for it?

  • Had to make an update since the post IDs weren’t being included in the custom relationship field’s results correctly.

    acf-field-re....zip

  • What I ended up doing is extending “acf_field_relationship” with my own classname “acf_field_relationship_nogroup”. A few things needed to be customized, and I needed to register the new control in jQuery as well. It seems to be working well.

    Seems like not grouping the results by post type should be an option for Relationship fields though.

    .
    .

  • Hey John, sorry for bringing this up again, but since I was having a hard time explaining the issue, I decided to just poke around until I figured it out but I’m still having problems.

    I think a simpler explanation is that the default way of displaying my posts in the relationship field is like this:

    Bios
Jack Brown
Jane Smith
John Doe

Resumes
Jack Johnson
James Thompson

    But I need the results to simply display like this:

    Jack Brown
Jack Johnson
Jane Smith
James Thompson
John Doe

    So no grouping by post type. I’ve poked around in the code and the get_ajax_query function calls the function acf_get_grouped_posts which groups the results by post type, and as far as I can see there’s no way to bypass the grouping function. So I’m thinking I need to create a custom ACF Relationship field/plugin that doesn’t call the acf_get_grouped_posts. I just want to check in real quick and see if I’m missing something before doing that, since it’s not an ideal solution.

    Thanks you!

  • +1

    This would a great option to have

  • Thanks for your help

  • Thanks John. This looks like it can help with sorting the results for each post type, but can this also help with combining the posts from each post type into a single listing?

    Basically the real use case is that I have two post types: Bio and Resume. The Relationship field needs to show both post types combined into a single listing, not separated by post type.

    Maybe it would be best to duplicate the Relationship field and just create a new field based on it.

  • That’s a good idea! I wanted to keep all my “clonable” fields in their own field group, like “Library” or “Templates”, but I can just name them something like “Template > Call To Action” so at least they’re organized together. Thanks!

    Edit: I accidentally marked my own post as having solved the question instead of yours and can’t change it 🙂

  • That’s really good to know, thanks!! I definitely don’t want these filters to be applied when exporting.

  • Oh interesting. Yep, I frequently use load_field filters, although I always use them with the /key=field_XXXXXX params. I can’t say for the previous times I’ve had the issue, but this last time with the clone field I mentioned, there were no filters on any of those image fields.

  • This is a pretty common problem for me, and it happens on many different WordPress installs. I’d say it’s been happening for about a year, but it’s probably more like 1.5 years since Covid has screwed up my sense of time. I’m usually exporting locally and importing to a dev server. I always first delete the field group on the dev server, then import the json from my local install. The imported image fields will then only return IDs instead of arrays. It doesn’t happen with all image fields though. For the affected fields, I need to change them to return ID, save, then change back to array, save, and then the problem is usually fixed.

    This last one was being extremely stubborn and wouldn’t fix when changing the return type, but it was a somewhat unique use case. It was a disabled field group that was included in another field group as a Clone field (seamless replace). I deleted both field groups and reimported many times, and changed the return type many times. No matter what the image field would only return an array, not an ID (in this case I wanted the ID returned, not array.) Eventually I tried what I talked about above and that fixed it (exporting json, changing characters in the field key, and importing the modified json). Luckily I wasn’t using any hard-coded field keys anywhere so it immediately started working correctly.

    By the way, I want to add that when this problem happens, it always reverses the output type. If it’s set to an array, it will return an ID. If it’s set to an ID it will return an array. It seems to me that somewhere in the import process the return types get mixed up. The admin UI still shows the correct return type though (the correct radio button is selected), it just returns the wrong value.

  • This one was being really stubborn. Changing the field return type wouldn’t affect anything. Anyways, what I did was export the group to JSON, change a few characters in the image field keys, then delete the group and reimport the edited JSON. Then it starts returning the correct return type. Hopefully this is a reliable fix because this issue is extremely annoying and frequently breaks features when importing field groups between environments.

Viewing 25 posts - 1 through 25 (of 46 total)
1 2