tschortsch

See my answer here: https://ww.wp.xz.cn/support/topic/wordpress-7-compatibility/. I really hope I’ll find the time to update the plugin but I can’t promise anything :/

Hi @foldesistudio. You can add custom button styling options with the wpBootstrapBlocks.button.styleOptions JavaScript hook (see: https://github.com/liip/bootstrap-blocks-wordpress-plugin#wpbootstrapblocksbuttonstyleoptions).

In your case this would look something like this:

function outlinePrimaryStyleOption( styleOptions ) {
	styleOptions.push( {
		label: 'Outline primary',
		value: 'outline-primary',
		bgColor: '#ff0000',
		textColor: '#ffffff',
	} );
	return styleOptions;
}
wp.hooks.addFilter(
	'wpBootstrapBlocks.button.styleOptions',
	'myplugin/wp-bootstrap-blocks/button/styleOptions',
	outlinePrimaryStyleOption
);

Hope this helps!

Hey @sandrowuermli. We released version 5.1.0 of the plugin which addresses a bug related to the favicons. The site_icon stacks which are used for favicons weren’t created on rokka side which resulted in not displaying the favicons at all. Could you try updating the plugin and sync the stack again in the settings? Maybe your issue was also related to that.

• This reply was modified 3 years, 3 months ago by tschortsch.

Hi @bajweb. A column offset is not directly supported via the blocks UI but you can always set arbitrary classes in the Advanced section (Advanced > ADDITIONAL CSS CLASS(ES)) of the column block. But for your use case it would probably make more sense to use the alignment options of the row block (which sets the flex classes accordingly).

We just released version 4.2.1 of the plugin with the described change.

Hi @jonroc804. Thanks for your feedback! We actually also though about naming the blocks differently in the first place but it somehow looked weird 😉 But your request is very valid and useful for the clients so we will rename the blocks in the next release again to <Blockname> (Bootstrap). Hope that’s fine for you?

Hi @wpzoneman. Hmm since the whole editor is written in JavaScript and therefore rendered on the client-side it’s probably not that easy to restrict certain options for certain roles. Of course it would be possible to hide some of those options as @comonist34 wrote but security-wise this is not really safe. What should additionally be restricted is the “save” call to the API which is triggered by the editor itself but I think Gutenberg doesn’t offer a simple way to do that.
What could be implemented are block-level permissions with which it would be possible to define which role should see which blocks but this doesn’t really help your use case.