Miguel Fonseca

Hey, @lunaman. Although in this case the issue is visible only when the plugin is active, it could still hint at a problem in WP 6.9. And indeed I believe it could be this recently reported bug at play. If so, it has been fixed in trunk and is expected in the 6.9.1 release soon (but no dates available yet).

Hello,

The data-back attribute is not standard in the Group block. Could you provide detailed instructions so that I can try to reproduce the problem?

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!

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.

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.

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://ww.wp.xz.cn/support/article/faq-troubleshooting/#how-to-deactivate-all-plugins-when-not-able-to-access-the-administrative-menus

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!