aduth

Hi Mehul, those three inserter shortcuts are intentionally removed as of WordPress 5.4, as they were a common source of confusion for users. In particular, they were not predictable. While you note that these were for “recently used 3 block icons”, this was only sometimes true; in fact, there was a very opaque calculation of both recency and frequency of use that determined which blocks would be shown.

For your purposes, there is still a “Most used” section of the primary block inserter that will present a selection of frequently and recently used blocks to insert.

Does it make a difference if you log in from the “/wp-login.php” page?

This appears to be a conflict where clicking the drag handle causes the block to become selected, and the toolbar stops the drag from occurring.

I’ve logged the issue here, with workarounds included:

https://github.com/WordPress/gutenberg/issues/12601

Hi @obsidianurbex,

In order to narrow down whether this is an issue on your site, or in your network / browser environment(s), could you try installing Gutenberg on another site and see whether you experience similar issues?

You can create a free temporary WordPress installation at this site (mind the URL ??):

https://poopy.life/

It’s expected that shortcodes should continue to work without issues in Gutenberg. A Shortcode block exists which will respect the syntax of any previously supported shortcode in the context of Gutenberg.

Many users will expect to be able to insert shortcodes into a paragraph block, and this should be supported as well, tracked at the following GitHub issue:

https://github.com/WordPress/gutenberg/issues/3062

With some in-progress work here:

https://github.com/WordPress/gutenberg/pull/3609
https://github.com/WordPress/gutenberg/pull/3610

Can you check to see if your shortcode works with the Shortcode block?

To your other questions:

any published guidelines for plugin developers to take into account and prepare their plugins for www.ads-software.com 5 ?

Related to the first question, since it is the hope that Gutenberg is largely compatible with previous plugin behaviors, there should not be much that a plugin author needs to anticipate. Where breaking changes do occur will certainly be documented as those are introduced.

any guidelines/reccomendations for bbcode plugin developers to switch from the add_shortcode() API to something else that will result in a gutenberg block?

This does not yet exist, but I believe it should, as many will find themselves in a similar situation as yourself. While much of what had previously been implemented as shortcodes could serve well as blocks, there should be a clear path for upgrading. The idea of an editable block lends itself to different conventions from a shortcode, so this path is not always 1-to-1; and in fairness, a block introduces new editing capabilities that a plugin author should want to leverage to improve the user experience of modifying a block’s behavior.

This is covered by the following GitHub issue:

https://github.com/WordPress/gutenberg/issues/1894

The initial direction was to make this an opt-out. Post type supports would require that developers update their plugin code to add support for Gutenberg. There was some discussion of this here:

https://github.com/WordPress/gutenberg/pull/2528#issuecomment-324693328

It is possible to disable Gutenberg on a per-post-type basis. The following URL includes the discussion and changes where this was introduced:

https://github.com/WordPress/gutenberg/pull/2528

You can use the gutenberg_add_edit_link_for_post_type filter to disable Gutenberg for a specific post type:

function myplugin_disable_gutenberg_book_type( $is_enabled, $post_type ) {
	if ( 'book' === $post_type ) {
		return false;
	}

	return $is_enabled;
}
add_filter( 'gutenberg_add_edit_link_for_post_type', 'myplugin_disable_gutenberg_book_type', 10, 2 );

Glad you got it working! Your solution looks good to me.

Could you share your save implementation? I suspect that this issue is that your source is matching the first of your two images for both attributes. Keep in mind that the first argument to attr behaves effectively the same as querySelector (or a jQuery selector):

https://developer.mozilla.org/en-US/docs/Web/API/Document/querySelector

I’ve put together a CodePen which should help illustrate the problem:

https://codepen.io/aduth/pen/PJNgOG

The solution would be in the case that you’re including multiple images in your save to assign some attribute to help differentiate them. This could be an id, class, or data- attribute. Then, update your selector to one which would specifically match only one or the other.