Title: Andrew Duthie's Replies | WordPress.org --- # Andrew Duthie [ ](https://wordpress.org/support/users/aduth/) * [Profile](https://wordpress.org/support/users/aduth/) * [Topics Started](https://wordpress.org/support/users/aduth/topics/) * [Replies Created](https://wordpress.org/support/users/aduth/replies/) * [Reviews Written](https://wordpress.org/support/users/aduth/reviews/) * [Topics Replied To](https://wordpress.org/support/users/aduth/replied-to/) * [Engagements](https://wordpress.org/support/users/aduth/engagements/) * [Favorites](https://wordpress.org/support/users/aduth/favorites/) Search replies: ## Forum Replies Created Viewing 9 replies - 1 through 9 (of 9 total) * Forum: [Alpha/Beta/RC](https://wordpress.org/support/forum/alphabeta/) In reply to: [Missing Recent block icon when hovering block-editor-default-block](https://wordpress.org/support/topic/missing-recent-block-icon-when-hovering-block-editor-default-block/) * [Andrew Duthie](https://wordpress.org/support/users/aduth/) * (@aduth) * [6 years, 5 months ago](https://wordpress.org/support/topic/missing-recent-block-icon-when-hovering-block-editor-default-block/#post-12484207) * 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. * Forum: [Fixing WordPress](https://wordpress.org/support/forum/how-to-and-troubleshooting/) In reply to: [Unable to access dashboard after updating to 5.0](https://wordpress.org/support/topic/unable-to-access-dashboard-after-updating-to-5-0/) * [Andrew Duthie](https://wordpress.org/support/users/aduth/) * (@aduth) * [7 years, 8 months ago](https://wordpress.org/support/topic/unable-to-access-dashboard-after-updating-to-5-0/#post-10954888) * Does it make a difference if you log in from the “/wp-login.php” page? * Forum: [Alpha/Beta/RC](https://wordpress.org/support/forum/alphabeta/) In reply to: [Images in wide width and full width](https://wordpress.org/support/topic/images-in-wide-width-and-full-width/) * [Andrew Duthie](https://wordpress.org/support/users/aduth/) * (@aduth) * [7 years, 8 months ago](https://wordpress.org/support/topic/images-in-wide-width-and-full-width/#post-10947158) * 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](https://github.com/WordPress/gutenberg/issues/12601) * Forum: [Plugins](https://wordpress.org/support/forum/plugins-and-hacks/) In reply to: [[Gutenberg] Won’t preview a post draft, or published post](https://wordpress.org/support/topic/wont-preview-a-post-draft-or-published-post/) * Plugin Author [Andrew Duthie](https://wordpress.org/support/users/aduth/) * (@aduth) * [8 years ago](https://wordpress.org/support/topic/wont-preview-a-post-draft-or-published-post/#post-10555731) * Hi [@obsidianurbex](https://wordpress.org/support/users/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 😬): * [http://poopy.life/](http://poopy.life/) * Forum: [Plugins](https://wordpress.org/support/forum/plugins-and-hacks/) In reply to: [[Gutenberg] support/compatibility for bbcode plugins using add_shortcode()](https://wordpress.org/support/topic/support-compatibility-for-bbcode-plugins-using-add_shortcode/) * Plugin Author [Andrew Duthie](https://wordpress.org/support/users/aduth/) * (@aduth) * [8 years, 8 months ago](https://wordpress.org/support/topic/support-compatibility-for-bbcode-plugins-using-add_shortcode/#post-9726014) * 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](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/3609) [https://github.com/WordPress/gutenberg/pull/3610](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 wordpress.org 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](https://github.com/WordPress/gutenberg/issues/1894) * Forum: [Reviews](https://wordpress.org/support/forum/reviews/) In reply to: [[Gutenberg] Hook to disable Gutenberg per post-type](https://wordpress.org/support/?post_type=topic&p=9531762) * Plugin Author [Andrew Duthie](https://wordpress.org/support/users/aduth/) * (@aduth) * [8 years, 10 months ago](https://wordpress.org/support/?post_type=topic&p=9531762#post-9543710) * 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](https://github.com/WordPress/gutenberg/pull/2528#issuecomment-324693328) * Forum: [Reviews](https://wordpress.org/support/forum/reviews/) In reply to: [[Gutenberg] Hook to disable Gutenberg per post-type](https://wordpress.org/support/?post_type=topic&p=9531762) * Plugin Author [Andrew Duthie](https://wordpress.org/support/users/aduth/) * (@aduth) * [8 years, 10 months ago](https://wordpress.org/support/?post_type=topic&p=9531762#post-9536897) * 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](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 ); ``` * Forum: [Plugins](https://wordpress.org/support/forum/plugins-and-hacks/) In reply to: [[Gutenberg] 2 images in same block](https://wordpress.org/support/topic/2-images-in-same-block/) * Plugin Author [Andrew Duthie](https://wordpress.org/support/users/aduth/) * (@aduth) * [8 years, 10 months ago](https://wordpress.org/support/topic/2-images-in-same-block/#post-9514146) * Glad you got it working! Your solution looks good to me. * Forum: [Plugins](https://wordpress.org/support/forum/plugins-and-hacks/) In reply to: [[Gutenberg] 2 images in same block](https://wordpress.org/support/topic/2-images-in-same-block/) * Plugin Author [Andrew Duthie](https://wordpress.org/support/users/aduth/) * (@aduth) * [8 years, 10 months ago](https://wordpress.org/support/topic/2-images-in-same-block/#post-9513736) * 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](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](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. Viewing 9 replies - 1 through 9 (of 9 total)