[Mobile] - Deprecate Gallery V1 as an Unsupported block #46157
Closed
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
geriux
added
[Status] In Progress
|
Size Change: -2.44 kB (0%) Total Size: 1.32 MB
ℹ️ View Unchanged
|
fluiddot
reviewed
Nov 30, 2022
| @@ -31,6 +31,8 @@ function gutenberg_get_block_editor_settings_mobile( $settings ) { | |||
| $settings['__experimentalEnableQuoteBlockV2'] = true; | |||
| // To tell mobile that the site uses list v2 (inner blocks). | |||
| $settings['__experimentalEnableListBlockV2'] = true; | |||
| // To tell mobile if it should mark the Gallery block as Unsupported for older versions of WordPress. | |||
| $settings['__unstableGalleryWithImageBlocks'] = is_wp_version_compatible( '5.9' ); | |||
There was a problem hiding this comment.
I'm wondering if we should also include the condition (int) get_option( 'use_balanceTags' ) !== 1 as we have here 🤔 :
gutenberg/lib/experiments-page.php
Line 142 in ae560c8
There was a problem hiding this comment.
To be honest, I'm not really sure what that's doing but let me ping @glendaviesnz do you know by any chance what (int) get_option( 'use_balanceTags' ) !== 1 does? And if that would be needed for mobile? I think with just having is_wp_version_compatible( '5.9' ) would be enough but it'd be nice to confirm, thank you!
There was a problem hiding this comment.
In versions of WP < 5.9 if use_balanceTags was enabled the post HTML was parsed and rewritten to make sure all the HTML tags were correctly balanced, but the code doing this didn't accept figure as being nestable so would rewrite any v2 gallery code to remove the nesting.
This was updated in core here so that the gallery code was left nested as is even if use_balanceTags is enabled on a site. So, as long as a site is >= 5.9 there should be no issues even if use_balanceTags is enabled.
| @@ -120,6 +127,26 @@ export class UnsupportedBlockEdit extends Component { | |||
| } | |||
| } | |||
|
|
|||
| getSheetTitle( blockTitle ) { | |||
| if ( CUSTOM_UNSUPPORTED_BLOCK_MESSAGE[ blockTitle ] ) { | |||
There was a problem hiding this comment.
Maybe instead of using the block's title, we could use the name (i.e. core/gallery) as it might be closer to being an identifier and hence less subject to change, wdyt?
There was a problem hiding this comment.
Good idea, I updated it 👍
fluiddot
reviewed
Dec 2, 2022
Comment on lines
+38
to
+44
| const CUSTOM_UNSUPPORTED_BLOCK_MESSAGE = { | ||
| 'core/gallery': { | ||
| /* translators: Unsupported block alert title. %s: The localized block name */ | ||
| title: __( "'%s' needs an updated version of WordPress" ), | ||
| description: __( 'Please update to version 5.9 or above' ), | ||
| }, | ||
| }; |
There was a problem hiding this comment.
Probably an edge case but if for any other reason the Gallery block is missing, using this message could be misleading to the user.
In this PR I explored passing the block name to the native.missing_block_detail filter hook, this way we could override the details string by block. We could use a similar approach here and, instead of setting the custom message here, use the filter hook in the galleryCheck function and based on the value of galleryWithImageBlocks override the string. For this approach, we'd also need to define a new filter hook to allow overriding the sheet title. WDYT?
| const unsupportedBlock = await getBlock( screen, 'Unsupported' ); | ||
| expect( unsupportedBlock ).toBeVisible(); | ||
|
|
||
| expect( getEditorHtml() ).toMatchSnapshot(); |
There was a problem hiding this comment.
I'm wondering if we expect the HTML to be different, even though the block is unsupported the HTML output will remain the same, is this accurate? If so, we might not need this expectation.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
What?
Deprecates the V1 of the Gallery block since three versions of WordPress have been released since version 2 was released in
5.9.Why?
To avoid maintaining old code that is no longer supported for too long.
How?
Since there is still some usage we will use the current
__unstableGalleryWithImageBlocksflag that was previously pulled fromgutenberg_experiments_editor_settingsbut now it will be in the mobile block editor settings endpoint, to show users that have this flag asfalsean unsupported version of the Gallery block.It will provide hints to upgrade to a newer version of WordPress and editing capability using a WebView in some specific cases.
Users that have this flag as
falsewon't see the Gallery block button in the inserter. We could provide a hint every time they open the inserter or the editor but maybe it could be annoying for users that might not even use this block?Testing Instructions
Precondition:
On the mobile app:
Unsupportedif you don't see this, re-open the editor?buttonScreenshots or screencast