@hube2 Ah yep! You’re spot on. series is a part of the Pro plugin.
@hube2 Ah, yep… You’re spot on. series is a part of the Pro plugin.
This solution works. Adding series to the list of post types in the relationship field did the trick.
['tribe_events', 'series',]
The maddening part is that series isn’t a registered post type, at least not as far as I can tell.
Yeah, that’s more than likely the issue. I’m guessing this has to do with a recent TEC update, but have yet to fully test that theory.
In the interim, I created an mu-plugin that disables Tribe scripts on a given page:
https://gist.github.com/joshuafredrickson/bfac0d08c5d3366326d7b8ab75d8471c
This fixed the immediate issue for me.
Since this discussion is the top result in Google:
As of 5.9, this option is available by holding shift when hovering over a row.
https://www.advancedcustomfields.com/blog/acf-5-9-0-release-inner-blocks-ui-improvements-and-exciting-features/
Elliot replied to the issue on Github:
This issue is due to a change we made in beta-4 which enqueues out JS in the “enqueue_block_assets” action. This seems to also be run on the front-end and explains why all the WP blocks JS is being enqueued.
The fix for this issue is to change “enqueue_block_assets” to “enqueue_block_editor_assets” in the “/pro/blocks.php” file on line 383.
I’m seeing this same behavior. But it doesn’t work even after I remove the minimum rows requirement.
EDIT: After I remove the minimum rows requirement, I can rearrange the blocks with the exception of the first block. It always remains first.
Here’s what the POST to admin_ajax.php looks like. For some reason, the first item has a [0] array key but the subsequent items appear to have hashed keys.
action: acf/ajax/render_block_preview
block[id]: block_5c5a09cdd6c41
block[data][field_5c59f6ad04f2e][0][field_5c59f6ad0803b]: 4955
block[data][field_5c59f6ad04f2e][0][field_5c59f745b0c76]: The Distillers League of Alabama logo
block[data][field_5c59f6ad04f2e][0][field_5c59f6ad08084]: #f4f4f4
block[data][field_5c59f6ad04f2e][5c5a09ead6c42][field_5c59f6ad0803b]: 4953
block[data][field_5c59f6ad04f2e][5c5a09ead6c42][field_5c59f745b0c76]: Shoal Creek logo
block[data][field_5c59f6ad04f2e][5c5a09ead6c42][field_5c59f6ad08084]: #a6a5a5
block[data][field_5c59f6ad04f2e][5c5a0a03d6c43][field_5c59f6ad0803b]: 4945
block[data][field_5c59f6ad04f2e][5c5a0a03d6c43][field_5c59f745b0c76]: Attune Health logo
block[data][field_5c59f6ad04f2e][5c5a0a03d6c43][field_5c59f6ad08084]: #aaad00
block[data][field_5c59f6ad04f2e][5c5a0a5ed6c44][field_5c59f6ad0803b]: 4876
block[data][field_5c59f6ad04f2e][5c5a0a5ed6c44][field_5c59f745b0c76]: America's First Financial logo
block[data][field_5c59f6ad04f2e][5c5a0a5ed6c44][field_5c59f6ad08084]: #ffffff
block[name]: acf/logo-grid-block
block[align]:
block[mode]: preview
nonce: 057b20ab19
post_id: 4974
Appreciate all the work you’re putting in.
Gutenberg’s been such a moving target… Nearly impossible to plan and develop for on anything but the surface level.
Can confirm this occurs with ACF Pro 5.7.7. I’ve seen it on different versions of Gutenberg going back to 3.5.0, including the latest 4.1.1.
Just for clarity’s sake… There may be an issue on multisite, but that seems to be a separate issue from what many of the rest of us are experiencing. At least in my case, there are about a half dozen single site installations that are unable to upgrade to 5.7.7 from 5.7.6.
I’ve been seeing this sporadically across several sites as well. The solution @webnoticelt provided worked for me on at least one site. I’ll try it on others as I encounter them.
