websevendev

Go for it

Yeah the version requirement is arbitrary in the sense that it may very well work with older versions, but since everything below 8.1 is EOL (https://endoflife.date/php) I use 8.1 during development and wouldn’t catch any mistakes that would cause fatal errors in older versions.

If you were to download the plugin zip, modify the Requires PHP, and then install this patched version, the next update would also refuse to install due to PHP version, so it actually feels like a viable method to keep using the plugin with an older PHP version, just requires some extra effort to keep it updated.

Just not possible with this plugin.

You can try Flexible Table Block which seems to support adding ID and class attributes to individual cells, but that’s about it. Otherwise just put your table into Custom HTML block as HTML and you can control everything.

Can’t do it with this plugin, it can only add attributes to the block’s root element.

Thanks for the info, I will add the header there as well.

if the proposed solution will always be needed, even in the future, or if there is hope for a permanent fix

The block editor team are in the process of unifying all the editors, so I would assume that it will start working eventually. Currently the editor is using the setting __experimentalCanUserUseUnfilteredHTML for determining this permission, so I will leave it for now, but once it is no longer experimental and still doesn’t work I’ll see if anything can be done on the plugin side.

Looks like it’s a bug.

The reason you can’t add attributes in the Widget editor is because when the plugin is checking for wp.data.select('core/editor').canUserUseUnfilteredHTML() it returns false even though your user probably can use unfiltered HTML.

Since this restriction is only client-side, as a workaround you can paste this code into the JavaScript console (F12 -> Console) and then you should be able to add attributes (may need to unselect and reselect the block so that it re-renders first):

wp.data.select('core/editor').canUserUseUnfilteredHTML = () => true

The workaround will stop working after you reload the page, but if your user does in fact have unfiltered_html capability then the attributes will persist and you can use the workaround again to edit them later.

do you have an estimated timeframe for when the update with this functionality will be available?

It’s out already.

How to stagger animations:

1. Insert the Animation container block.
2. Enable the Is animation provider option on the block.
3. Now the block has an option to configure stagger and animation.
4. Any child blocks inside the (now called) Animation provider block can use the Inherit animation – which will make use of the stagger option of the provider.
5. So if you add a Query Loop block in the provider and use the “Inherit” animation on a block that is inside Query Loop -> Post Template then for every query loop item it will get a longer delay.

Note: don’t put an animation on the Post Template block itself as on the front end it is the <ul> of the loop not the <li>. Put the animation on a child of Post Template.

Let me know if these instructions make any sense, if so, I’ll include them in the readme and help.

dynamic loop block (generateBlocks) but I would like to use the delay to show every element some seconds after the before element shows

In an upcoming plugin update there will be a way to delay (stagger) elements of Query Loop block, don’t know about GenerateBlocks though, never used it.

The other point is that I have a toggle to change view from large to small element card (images) so when I switch the toggle to show smaller elements it doesn’t show the element untill I resize the window.

I don’t understand this, sorry. But when you have an issue with animating some block, you can always try to wrap this block in another block, such as the Animation container, and animate that instead.

One potential method could be to use custom CSS depending on what animation you use. For example if you’re using “Flip down” then the block receives this CSS from AOS:

for the initial state:

html:not(.no-js) [data-aos=flip-down] {
	transform: perspective(2500px) rotateX(100deg);
}

and for the animated state:

html:not(.no-js) [data-aos=flip-down].aos-animate {
	transform: perspective(2500px) rotateX(0);
}

Take the initial state CSS and apply it with higher specificity to the block in the hidden tab to “unanimate” it, for example:

html:not(.no-js) .tabs > .tab-content [data-aos=flip-down] {
	transform: perspective(2500px) rotateX(100deg);
}

and animate it when the tab is opened:

html:not(.no-js) .tabs > .tab-content[data-open=true] [data-aos=flip-down] {
	transform: perspective(2500px) rotateX(0);
}

Yeah that’s just how it works.

When you press “Attempt recovery” it should always successfully rebuild the correct HTML (albeit without the animations attributes) – if it didn’t, that’s when I’d find it concerning.

Could be a mess with a large website with a lot of animations.

Only on the editor side of things, on the front end everything should keep working normally.

They may change this behavior in the future as I’ve seen people complain about it and it’s causing a lot of confusion. It would technically be possible to just automatically “recover” the block and maybe just display a minor warning or whatnot, but that’s up to the block editor developers to figure out. Nothing I can do on my end.

Ah, interesting. And just to confirm, when you said earlier:

Admins have no issues, but they are not normally responsible for the content.

did you mean super admins? Cause if it was regular admins and they weren’t supposed to have unfiltered_html capability but were able to add attributes it might be something I need to look into as well.

Here’s another method to do it, by filtering the capabilities, rather than granting them:

add_filter('user_has_cap', function($allcaps, $caps, $args, $user) {
	if(
		in_array('unfiltered_html', $caps, true)
		&& in_array('editor', $user->roles, true)
	) {
		$allcaps['unfiltered_html'] = true;
	}
	return $allcaps;
}, 10, 4);

This one should allow unfiltered_html for every user with editor role.

It was part of a security fix to prevent users without unfiltered_html capability from adding attributes as it can be used maliciously.

If you trust your editor users then you can grant them the capability.

You can give the capability to roles:

add_action('init', function() {
	if($role = get_role('contributor')) {
		$role->add_cap('unfiltered_html');
	}
});

Or to individual users:

add_action('init', function() {
	if($user = get_user_by('login', 'editor-users-login')) {
		if(!$user->has_cap('unfiltered_html')) {
			$user->add_cap('unfiltered_html');
		}
	}
});

There are probably plugins that allow managing the capabilities without code as well.

Thanks for the report. Attempted a fix in 1.0.9, let me know if it resolves the issue.