Miguel Fonseca

Can you point me in the right direction for the documentation for this Data API? I can only find information on the REST API.

The Data API is organised in “stores”, with each store exposing its own set of “selectors” (methods with which you retrieve state) and “actions” (which you can dispatch to trigger changes in the store).

You can access the entire reference here. Within it, you will find two stores that are helpful for your task: the editor store and the block-editor store. The editor store contains data specific to the post editor, such as active taxonomies. The block-editor store contains, among other things, settings dictating how the block editor should behave, such as which block types are allowed.

I’ve implemented the code but when I change the category I just see the same taxonomy term ID returned:

If I understood you correctly, I think the issue is that you would like the code to run without having to even save the draft. In that case, you’ll need a slightly different state selector called getEditedPostAttribute. I have updated my demo accordingly, and this works on my test site:

function makeListener() {
	let prevCategories = [];

	return function updateAllowedBlockTypes() {
		// We use wp.data.select() to access a specific data store -- in this
		// case, the 'core/editor' store, which is tied to the post currently
		// being edited.
		//
		// This call exposes all state selectors, among which we find:
		//
		// - getEditedPostAttribute
		// - getCurrentPostAttribute
		//
		// Selector getEditedPostAttribute reflects changes to the post as
		// they are being made by the user, while getCurrentPostAttribute
		// only reflects changes after the post is saved.
		const categories = wp.data
			.select( 'core/editor' )
			.getEditedPostAttribute( 'categories' );

		// Bail if the data isn't ready yet.
		if ( ! categories ) {
			return;
		}

		// Bail if there has been no meaningful state change.
		if ( categories === prevCategories ) {
			return;
		}

		prevCategories = categories;

		const MY_CATEGORY = 1;
		const MY_CATEGORY_ALLOWED_TYPES = [ 'core/paragraph', 'core/image' ];

		// Notice how we connect to the 'core/block-editor' store instead of
		// 'core/editor' for state related to block editor settings, such as
		// allowed block types.
		const currentTypes = wp.data
			.select( 'core/block-editor' )
			.getSettings()?.allowedBlockTypes;

		const nextTypes = categories.includes( MY_CATEGORY )
			? MY_CATEGORY_ALLOWED_TYPES
			: true;

		if ( nextTypes !== currentTypes ) {
			console.log( 'setting allowed block types to', nextTypes );
			wp.data.dispatch( 'core/block-editor' ).updateSettings( {
				allowedBlockTypes: nextTypes,
			} );
		}
	};
}

const unsubscribe = wp.data.subscribe( makeListener() );

I hope this helps!

Hi there,

I think you’ll have a better experience if, instead of having to refresh, you leverage the Data API to react to changes in the post’s terms. As a proof of concept, you can try the following directly in your browser console when editing a post:

function makeListener() {
	let prevCategories;

	return function updateAllowedBlockTypes() {
		const categories = wp.data.select('core/editor').getCurrentPost().categories;
		if (categories === prevCategories) {
			return;
		}
		prevCategories = categories;

		const MY_CATEGORY = 1;
		const MY_CATEGORY_ALLOWED_TYPES = ['core/paragraph', 'core/image'];

		const currentTypes = wp.data.select('core/block-editor').getSettings().allowedBlockTypes;
		const nextTypes = categories.includes(MY_CATEGORY) ? MY_CATEGORY_ALLOWED_TYPES : true;

		if (nextTypes !== currentTypes) {
			console.log('setting allowed block types to', nextTypes);
			wp.data.dispatch('core/block-editor').updateSettings({
				allowedBlockTypes: nextTypes,
			});
		}
	};
};

const unsubscribe = wp.data.subscribe(makeListener());

Replace the constant MY_CATEGORY = 1; with whatever works for you. You’ll notice that, as soon as you save your draft after toggling that category, the console will log that it either set the allowed block types to ['core/paragraph', 'core/image'] or that it reset it to true.

I’ll leave the details up to you, but I hope this illustrates how to work with the Data API. ??

Oh, also note that the allowed_block_types filter was deprecated in 5.8 in favour of allowed_block_types_all.

Hello,

Internally, Reusable Blocks are a Custom Post Type (CPT), so you could prevent editors from deleting them by filtering the capabilities on said CPT.

I suggest starting at the support article for Roles & Capabilities, from which you could either manually perform the necessary changes in code, or find a plugin that might do that for you.

Hope this helps.

Hello,

We do have an official tool. Check out @wordpress/create-block.

This seems like a plugin compatibility issue coming from Unyson. To quote the notice on the plugin’s homepage: This plugin hasn’t been tested with the latest 3 major releases of WordPress. It may no longer be maintained or supported and may have compatibility issues when used with more recent versions of WordPress.

I recommend asking at Unyson’s support page so the plugin’s developers and support community can help you with this.

Hello,

I can see many galleries on that page — presumably all of them — with no issues. Perhaps you experienced a temporary caching issue, or throttling from the server serving the images?

In any case, I’ll mark this as resolved.

Hi @nick6352683, thanks for the extra feedback.

Two quick notes on the following:

Another issue that came back is the issue of ACF blocks not “registering” default field values until you make any change to a field. So let’s say you have a Heading block made with ACF Pro, and if you just insert the block and make no changes to it, and save the post/page, nothing shows up on the front end, even though on the backend, the default value is correctly shown. If you make a change to any of the block fields, then all is fine… This was happening a year ago, got fixed by springtime 2019, and Gutenberg managed to reintroduce this annoyance with Gutenberg 6.4, which persists until now…

• This would be better handled in a separate ticket, so that this ticket can be kept focused and tickets can be easier to search in general.
• It’s important to note that these systems for change detection in the block editor are, as of WordPress 5.3, part of core and not just the Gutenberg plugin. Without having more means to debug, this really sounds like an issue to bring up with maintainers of either ACF Blocks or ACF.

If I create a new page, add some blocks, close it, re-open it, changing nothing, then this message is there.

Hi, James. Some logic around autosaving was fixed recently (e.g. #18051). Are you still experiencing this issue in the latest version of Gutenberg?

If so, then the following would definitely be something to look at:

I am using custom ACF Blocks, and some custom changes to Gutenberg Blocks. It seems to happen more when using ACF Blocks, but I need to look in to some more.

(emphasis mine)

This is odd.

Are you then completely unable to access your site’s admin dashboard?

Is it possible that any plugin could be interfering with the login page?

If indeed you are locked out of your dashboard, you could try deactivating all plugins using phpMyAdmin by following the steps indicated here:

https://www.ads-software.com/support/article/faq-troubleshooting/#how-to-deactivate-all-plugins-when-not-able-to-access-the-administrative-menus

Updated to wordpress 5.3 and was getting ‘isSavingPost’ of null in my console error. […] Not sure if this is related to Yoast or any other plugin

I’ve tracked the error down to a plugin called Link Whisper. One of the scripts in the plugin (wp-content/plugins/link-whisper/js/wpil_admin.js) listens to data-related events in the editor and, whenever anything changes, it tries to call a WordPress API but fails in the process.

In this case, it seems that the Yoast plugin, as part of its normal operation, initiates an action which Link Whisper then reacts to. I’d try disabling Link Whisper rather than Yoast and see if that helps. If so, I would then suggest bringing up this issue with the maintainers of Link Whisper.

Hello! Could you provide some details? Namely:

– Which browser you are using, and which version of it
– Which operating system you are using
– Whether there are any specificities in how you are navigating the page, e.g. using a mouse to click on fields, or the keyboard to tab, or some other method.

Thanks!

Hello,

You can find the Options dialog under Tools. See this screencast.

Aha! That makes total sense, and I’m sorry I missed it in my original gist! Type is something that’ll get ya every time.

I’m glad it all worked out! ??

Hey, Michal

Do you mean “skipped” as in the callback for infinite_scroll_query_args is never called? I fail to see why that would happen. The snippet I shared with you does the trick for me. Anything less than 11, however, means the callback is called prematurely and doesn’t work.

Also, when you mentioned adding a var_dump at line 894, you meant right after

$query_args = apply_filters( 'infinite_scroll_query_args', $query_args );

correct? Because it is during the evaluation of apply_filters (second callback, as the first one must be inject_query_args) that extra gets pushed into $query_args.

Don’t worry, we’ll fix the Internet.

Hey Michal!

I was just discussing this with Jeremy, and the tricky thing is that those predicates — is_admin(), is_home(), etc. — actually depend on WP’s global $wp_query object:

https://core.trac.www.ads-software.com/browser/trunk/src/wp-includes/query.php#L443

However, the filter infinite_scroll_query_args has to run before we instantiate the new query because we need those args to feed them into new WP_Query( ... ). So the predicates you need aren’t available when you want them. ??

We have ways of working around this, though. Here’s what I’ve come up with:

https://gist.github.com/mcsf/6c5cda9ee61acc8849c6

I’ve left some comments around, but do feel free to ask us about anything. Hope this helps!

Miguel