Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Gallery block: turn on auto-migration of v1 Gallery blocks to v2 format when edited #36191

Merged

Conversation

glendaviesnz
Copy link
Contributor

@glendaviesnz glendaviesnz commented Nov 4, 2021

Description

Turns on automigration of v1 gallery blocks to v2 format unless a site has use_BalanceTags enabled and is not running WP >= 5.9

Testing

  • Before checking out this PR, on a site on WP < 5.9 set use_balanceTags option to 1
  • Then check out this PR and add a gallery and check that it is still the old format (see screenshots below) when editing and viewing and when reloading in the editor
  • Switch use_balanceTags to 0 and load the v1 Gallery block in the editor and check that it auto migrates to the v2 block format (see screenshots below) and can be edited, saved, reloaded ok
  • Try setting use_balanceTags back to 1 and you should get an error message about needing to upgrade to WP 5.9
  • For both v1 and v2 blocks check that you can transform to individual Image blocks and back to Gallery block again, and when transforming back to Gallery make sure it is v1 format for use_balanceTags site, and v2 for others
  • Also try adding a v1 block with external images (to do this add Image blocks and use the replace button to add the url of an external image - then transform the Image blocks to a Gallery block) and make sure these migrate to v2 gallery format ok. There is a known Image size selector error with this flow

Important note: It is not possible to load v2 version blocks in a site with use_balanceTags on and WP < 5.9, they will show an invalid error. The plan is to add some sort of explanatory error to indicate that user has to turn off use_balanceTags or upgrade to 5.9 in these instances - there is no point in showing a valid block as it will just break when the user saves it, but the user will not know unless they reload or view in the frontend, so better to fail on first editor load.

You can use wp option set use_balanceTags 1 to toggle the option, or you can make the option available at /wp-admin/options-writing.php by running wp option set initial_db_version 32452

Screenshots

v1 Gallery block:
Screen Shot 2021-11-16 at 9 50 57 PM

v2 Gallery block:
Screen Shot 2021-11-16 at 9 58 45 PM

@glendaviesnz glendaviesnz added [Status] In Progress Tracking issues with work in progress [Block] Gallery Affects the Gallery Block - used to display groups of images labels Nov 4, 2021
@glendaviesnz glendaviesnz self-assigned this Nov 4, 2021
@github-actions
Copy link

github-actions bot commented Nov 4, 2021

Size Change: -329 B (0%)

Total Size: 1.1 MB

Filename Size Change
build/block-library/index.min.js 162 kB -329 B (0%)
ℹ️ View Unchanged
Filename Size
build/a11y/index.min.js 960 B
build/admin-manifest/index.min.js 1.1 kB
build/annotations/index.min.js 2.75 kB
build/api-fetch/index.min.js 2.21 kB
build/autop/index.min.js 2.12 kB
build/blob/index.min.js 459 B
build/block-directory/index.min.js 6.28 kB
build/block-directory/style-rtl.css 1.01 kB
build/block-directory/style.css 1.01 kB
build/block-editor/default-editor-styles-rtl.css 378 B
build/block-editor/default-editor-styles.css 378 B
build/block-editor/index.min.js 139 kB
build/block-editor/style-rtl.css 14.4 kB
build/block-editor/style.css 14.4 kB
build/block-library/blocks/archives/editor-rtl.css 61 B
build/block-library/blocks/archives/editor.css 60 B
build/block-library/blocks/archives/style-rtl.css 65 B
build/block-library/blocks/archives/style.css 65 B
build/block-library/blocks/audio/editor-rtl.css 58 B
build/block-library/blocks/audio/editor.css 58 B
build/block-library/blocks/audio/style-rtl.css 111 B
build/block-library/blocks/audio/style.css 111 B
build/block-library/blocks/audio/theme-rtl.css 125 B
build/block-library/blocks/audio/theme.css 125 B
build/block-library/blocks/block/editor-rtl.css 161 B
build/block-library/blocks/block/editor.css 161 B
build/block-library/blocks/button/editor-rtl.css 470 B
build/block-library/blocks/button/editor.css 470 B
build/block-library/blocks/button/style-rtl.css 560 B
build/block-library/blocks/button/style.css 560 B
build/block-library/blocks/buttons/editor-rtl.css 291 B
build/block-library/blocks/buttons/editor.css 291 B
build/block-library/blocks/buttons/style-rtl.css 275 B
build/block-library/blocks/buttons/style.css 275 B
build/block-library/blocks/calendar/style-rtl.css 207 B
build/block-library/blocks/calendar/style.css 207 B
build/block-library/blocks/categories/editor-rtl.css 84 B
build/block-library/blocks/categories/editor.css 83 B
build/block-library/blocks/categories/style-rtl.css 79 B
build/block-library/blocks/categories/style.css 79 B
build/block-library/blocks/code/style-rtl.css 90 B
build/block-library/blocks/code/style.css 90 B
build/block-library/blocks/code/theme-rtl.css 134 B
build/block-library/blocks/code/theme.css 134 B
build/block-library/blocks/columns/editor-rtl.css 206 B
build/block-library/blocks/columns/editor.css 205 B
build/block-library/blocks/columns/style-rtl.css 503 B
build/block-library/blocks/columns/style.css 502 B
build/block-library/blocks/comments-pagination/editor-rtl.css 222 B
build/block-library/blocks/comments-pagination/editor.css 209 B
build/block-library/blocks/comments-pagination/style-rtl.css 235 B
build/block-library/blocks/comments-pagination/style.css 231 B
build/block-library/blocks/cover/editor-rtl.css 546 B
build/block-library/blocks/cover/editor.css 547 B
build/block-library/blocks/cover/style-rtl.css 1.22 kB
build/block-library/blocks/cover/style.css 1.22 kB
build/block-library/blocks/embed/editor-rtl.css 488 B
build/block-library/blocks/embed/editor.css 488 B
build/block-library/blocks/embed/style-rtl.css 417 B
build/block-library/blocks/embed/style.css 417 B
build/block-library/blocks/embed/theme-rtl.css 124 B
build/block-library/blocks/embed/theme.css 124 B
build/block-library/blocks/file/editor-rtl.css 300 B
build/block-library/blocks/file/editor.css 300 B
build/block-library/blocks/file/style-rtl.css 255 B
build/block-library/blocks/file/style.css 255 B
build/block-library/blocks/file/view.min.js 322 B
build/block-library/blocks/freeform/editor-rtl.css 2.44 kB
build/block-library/blocks/freeform/editor.css 2.44 kB
build/block-library/blocks/gallery/editor-rtl.css 976 B
build/block-library/blocks/gallery/editor.css 980 B
build/block-library/blocks/gallery/style-rtl.css 1.62 kB
build/block-library/blocks/gallery/style.css 1.62 kB
build/block-library/blocks/gallery/theme-rtl.css 122 B
build/block-library/blocks/gallery/theme.css 122 B
build/block-library/blocks/group/editor-rtl.css 159 B
build/block-library/blocks/group/editor.css 159 B
build/block-library/blocks/group/style-rtl.css 57 B
build/block-library/blocks/group/style.css 57 B
build/block-library/blocks/group/theme-rtl.css 78 B
build/block-library/blocks/group/theme.css 78 B
build/block-library/blocks/heading/style-rtl.css 114 B
build/block-library/blocks/heading/style.css 114 B
build/block-library/blocks/html/editor-rtl.css 332 B
build/block-library/blocks/html/editor.css 333 B
build/block-library/blocks/image/editor-rtl.css 731 B
build/block-library/blocks/image/editor.css 730 B
build/block-library/blocks/image/style-rtl.css 507 B
build/block-library/blocks/image/style.css 511 B
build/block-library/blocks/image/theme-rtl.css 124 B
build/block-library/blocks/image/theme.css 124 B
build/block-library/blocks/latest-comments/style-rtl.css 284 B
build/block-library/blocks/latest-comments/style.css 284 B
build/block-library/blocks/latest-posts/editor-rtl.css 137 B
build/block-library/blocks/latest-posts/editor.css 137 B
build/block-library/blocks/latest-posts/style-rtl.css 528 B
build/block-library/blocks/latest-posts/style.css 527 B
build/block-library/blocks/list/style-rtl.css 94 B
build/block-library/blocks/list/style.css 94 B
build/block-library/blocks/media-text/editor-rtl.css 266 B
build/block-library/blocks/media-text/editor.css 263 B
build/block-library/blocks/media-text/style-rtl.css 493 B
build/block-library/blocks/media-text/style.css 490 B
build/block-library/blocks/more/editor-rtl.css 431 B
build/block-library/blocks/more/editor.css 431 B
build/block-library/blocks/navigation-link/editor-rtl.css 649 B
build/block-library/blocks/navigation-link/editor.css 650 B
build/block-library/blocks/navigation-link/style-rtl.css 94 B
build/block-library/blocks/navigation-link/style.css 94 B
build/block-library/blocks/navigation-submenu/editor-rtl.css 299 B
build/block-library/blocks/navigation-submenu/editor.css 299 B
build/block-library/blocks/navigation-submenu/view.min.js 343 B
build/block-library/blocks/navigation/editor-rtl.css 1.89 kB
build/block-library/blocks/navigation/editor.css 1.89 kB
build/block-library/blocks/navigation/style-rtl.css 1.67 kB
build/block-library/blocks/navigation/style.css 1.66 kB
build/block-library/blocks/navigation/view.min.js 2.74 kB
build/block-library/blocks/nextpage/editor-rtl.css 395 B
build/block-library/blocks/nextpage/editor.css 395 B
build/block-library/blocks/page-list/editor-rtl.css 377 B
build/block-library/blocks/page-list/editor.css 377 B
build/block-library/blocks/page-list/style-rtl.css 172 B
build/block-library/blocks/page-list/style.css 172 B
build/block-library/blocks/paragraph/editor-rtl.css 157 B
build/block-library/blocks/paragraph/editor.css 157 B
build/block-library/blocks/paragraph/style-rtl.css 273 B
build/block-library/blocks/paragraph/style.css 273 B
build/block-library/blocks/post-author/style-rtl.css 175 B
build/block-library/blocks/post-author/style.css 176 B
build/block-library/blocks/post-comments-form/style-rtl.css 444 B
build/block-library/blocks/post-comments-form/style.css 444 B
build/block-library/blocks/post-comments/style-rtl.css 492 B
build/block-library/blocks/post-comments/style.css 493 B
build/block-library/blocks/post-excerpt/editor-rtl.css 73 B
build/block-library/blocks/post-excerpt/editor.css 73 B
build/block-library/blocks/post-excerpt/style-rtl.css 69 B
build/block-library/blocks/post-excerpt/style.css 69 B
build/block-library/blocks/post-featured-image/editor-rtl.css 721 B
build/block-library/blocks/post-featured-image/editor.css 721 B
build/block-library/blocks/post-featured-image/style-rtl.css 153 B
build/block-library/blocks/post-featured-image/style.css 153 B
build/block-library/blocks/post-template/editor-rtl.css 99 B
build/block-library/blocks/post-template/editor.css 98 B
build/block-library/blocks/post-template/style-rtl.css 391 B
build/block-library/blocks/post-template/style.css 392 B
build/block-library/blocks/post-terms/style-rtl.css 73 B
build/block-library/blocks/post-terms/style.css 73 B
build/block-library/blocks/post-title/style-rtl.css 80 B
build/block-library/blocks/post-title/style.css 80 B
build/block-library/blocks/preformatted/style-rtl.css 103 B
build/block-library/blocks/preformatted/style.css 103 B
build/block-library/blocks/pullquote/editor-rtl.css 198 B
build/block-library/blocks/pullquote/editor.css 198 B
build/block-library/blocks/pullquote/style-rtl.css 378 B
build/block-library/blocks/pullquote/style.css 378 B
build/block-library/blocks/pullquote/theme-rtl.css 167 B
build/block-library/blocks/pullquote/theme.css 167 B
build/block-library/blocks/query-pagination-numbers/editor-rtl.css 122 B
build/block-library/blocks/query-pagination-numbers/editor.css 121 B
build/block-library/blocks/query-pagination/editor-rtl.css 221 B
build/block-library/blocks/query-pagination/editor.css 211 B
build/block-library/blocks/query-pagination/style-rtl.css 234 B
build/block-library/blocks/query-pagination/style.css 231 B
build/block-library/blocks/query/editor-rtl.css 131 B
build/block-library/blocks/query/editor.css 132 B
build/block-library/blocks/quote/style-rtl.css 187 B
build/block-library/blocks/quote/style.css 187 B
build/block-library/blocks/quote/theme-rtl.css 223 B
build/block-library/blocks/quote/theme.css 226 B
build/block-library/blocks/rss/editor-rtl.css 202 B
build/block-library/blocks/rss/editor.css 204 B
build/block-library/blocks/rss/style-rtl.css 289 B
build/block-library/blocks/rss/style.css 288 B
build/block-library/blocks/search/editor-rtl.css 165 B
build/block-library/blocks/search/editor.css 165 B
build/block-library/blocks/search/style-rtl.css 397 B
build/block-library/blocks/search/style.css 398 B
build/block-library/blocks/search/theme-rtl.css 64 B
build/block-library/blocks/search/theme.css 64 B
build/block-library/blocks/separator/editor-rtl.css 99 B
build/block-library/blocks/separator/editor.css 99 B
build/block-library/blocks/separator/style-rtl.css 245 B
build/block-library/blocks/separator/style.css 245 B
build/block-library/blocks/separator/theme-rtl.css 172 B
build/block-library/blocks/separator/theme.css 172 B
build/block-library/blocks/shortcode/editor-rtl.css 474 B
build/block-library/blocks/shortcode/editor.css 474 B
build/block-library/blocks/site-logo/editor-rtl.css 772 B
build/block-library/blocks/site-logo/editor.css 772 B
build/block-library/blocks/site-logo/style-rtl.css 165 B
build/block-library/blocks/site-logo/style.css 165 B
build/block-library/blocks/site-tagline/editor-rtl.css 86 B
build/block-library/blocks/site-tagline/editor.css 86 B
build/block-library/blocks/site-title/editor-rtl.css 84 B
build/block-library/blocks/site-title/editor.css 84 B
build/block-library/blocks/social-link/editor-rtl.css 177 B
build/block-library/blocks/social-link/editor.css 177 B
build/block-library/blocks/social-links/editor-rtl.css 670 B
build/block-library/blocks/social-links/editor.css 669 B
build/block-library/blocks/social-links/style-rtl.css 1.32 kB
build/block-library/blocks/social-links/style.css 1.32 kB
build/block-library/blocks/spacer/editor-rtl.css 307 B
build/block-library/blocks/spacer/editor.css 307 B
build/block-library/blocks/spacer/style-rtl.css 48 B
build/block-library/blocks/spacer/style.css 48 B
build/block-library/blocks/table/editor-rtl.css 471 B
build/block-library/blocks/table/editor.css 472 B
build/block-library/blocks/table/style-rtl.css 481 B
build/block-library/blocks/table/style.css 481 B
build/block-library/blocks/table/theme-rtl.css 188 B
build/block-library/blocks/table/theme.css 188 B
build/block-library/blocks/tag-cloud/style-rtl.css 146 B
build/block-library/blocks/tag-cloud/style.css 146 B
build/block-library/blocks/template-part/editor-rtl.css 560 B
build/block-library/blocks/template-part/editor.css 559 B
build/block-library/blocks/template-part/theme-rtl.css 101 B
build/block-library/blocks/template-part/theme.css 101 B
build/block-library/blocks/text-columns/editor-rtl.css 95 B
build/block-library/blocks/text-columns/editor.css 95 B
build/block-library/blocks/text-columns/style-rtl.css 166 B
build/block-library/blocks/text-columns/style.css 166 B
build/block-library/blocks/verse/style-rtl.css 87 B
build/block-library/blocks/verse/style.css 87 B
build/block-library/blocks/video/editor-rtl.css 569 B
build/block-library/blocks/video/editor.css 570 B
build/block-library/blocks/video/style-rtl.css 173 B
build/block-library/blocks/video/style.css 173 B
build/block-library/blocks/video/theme-rtl.css 124 B
build/block-library/blocks/video/theme.css 124 B
build/block-library/common-rtl.css 857 B
build/block-library/common.css 856 B
build/block-library/editor-rtl.css 9.8 kB
build/block-library/editor.css 9.81 kB
build/block-library/reset-rtl.css 474 B
build/block-library/reset.css 474 B
build/block-library/style-rtl.css 10.5 kB
build/block-library/style.css 10.5 kB
build/block-library/theme-rtl.css 672 B
build/block-library/theme.css 677 B
build/block-serialization-default-parser/index.min.js 1.09 kB
build/block-serialization-spec-parser/index.min.js 2.79 kB
build/blocks/index.min.js 46.3 kB
build/components/index.min.js 214 kB
build/components/style-rtl.css 15.4 kB
build/components/style.css 15.4 kB
build/compose/index.min.js 10.9 kB
build/core-data/index.min.js 13.2 kB
build/customize-widgets/index.min.js 11.4 kB
build/customize-widgets/style-rtl.css 1.5 kB
build/customize-widgets/style.css 1.49 kB
build/data-controls/index.min.js 631 B
build/data/index.min.js 7.47 kB
build/date/index.min.js 31.5 kB
build/deprecated/index.min.js 485 B
build/dom-ready/index.min.js 304 B
build/dom/index.min.js 4.5 kB
build/edit-navigation/index.min.js 16 kB
build/edit-navigation/style-rtl.css 3.76 kB
build/edit-navigation/style.css 3.76 kB
build/edit-post/classic-rtl.css 492 B
build/edit-post/classic.css 494 B
build/edit-post/index.min.js 29.6 kB
build/edit-post/style-rtl.css 7.1 kB
build/edit-post/style.css 7.09 kB
build/edit-site/index.min.js 34.2 kB
build/edit-site/style-rtl.css 6.63 kB
build/edit-site/style.css 6.62 kB
build/edit-widgets/index.min.js 16.5 kB
build/edit-widgets/style-rtl.css 4.18 kB
build/edit-widgets/style.css 4.18 kB
build/editor/index.min.js 37.8 kB
build/editor/style-rtl.css 3.78 kB
build/editor/style.css 3.77 kB
build/element/index.min.js 3.29 kB
build/escape-html/index.min.js 517 B
build/format-library/index.min.js 6.57 kB
build/format-library/style-rtl.css 571 B
build/format-library/style.css 571 B
build/hooks/index.min.js 1.63 kB
build/html-entities/index.min.js 424 B
build/i18n/index.min.js 3.71 kB
build/is-shallow-equal/index.min.js 501 B
build/keyboard-shortcuts/index.min.js 1.8 kB
build/keycodes/index.min.js 1.39 kB
build/list-reusable-blocks/index.min.js 1.86 kB
build/list-reusable-blocks/style-rtl.css 838 B
build/list-reusable-blocks/style.css 838 B
build/media-utils/index.min.js 2.92 kB
build/notices/index.min.js 925 B
build/nux/index.min.js 2.08 kB
build/nux/style-rtl.css 747 B
build/nux/style.css 743 B
build/plugins/index.min.js 1.84 kB
build/primitives/index.min.js 924 B
build/priority-queue/index.min.js 582 B
build/react-i18n/index.min.js 671 B
build/redux-routine/index.min.js 2.65 kB
build/reusable-blocks/index.min.js 2.22 kB
build/reusable-blocks/style-rtl.css 256 B
build/reusable-blocks/style.css 256 B
build/rich-text/index.min.js 11 kB
build/server-side-render/index.min.js 1.57 kB
build/shortcode/index.min.js 1.49 kB
build/token-list/index.min.js 639 B
build/url/index.min.js 1.9 kB
build/viewport/index.min.js 1.05 kB
build/warning/index.min.js 248 B
build/widgets/index.min.js 7.15 kB
build/widgets/style-rtl.css 1.16 kB
build/widgets/style.css 1.16 kB
build/wordcount/index.min.js 1.04 kB

compressed-size-action

@noisysocks noisysocks added the Backport to WP 6.7 Beta/RC Pull request that needs to be backported to the WordPress major release that's currently in beta label Nov 7, 2021
@glendaviesnz glendaviesnz force-pushed the update/gallery-block-disable-v2-when-useBalanceTags-set branch from 73bec70 to 3c2480c Compare November 10, 2021 22:30
@glendaviesnz glendaviesnz removed the [Status] In Progress Tracking issues with work in progress label Nov 11, 2021
@glendaviesnz glendaviesnz marked this pull request as ready for review November 11, 2021 00:20
@glendaviesnz glendaviesnz changed the title Update experimental flag to block sites with use_BalanceTags option e… Gallery block: turn on auto-migration of v1 Gallery blocks to v2 format when edited Nov 11, 2021
@mkevins
Copy link
Contributor

mkevins commented Nov 11, 2021

Hi Glen 👋

I encountered an issue when testing this on mobile. Steps:

  1. Created a JN site
  2. Set use_balanceTags on via: wp option set use_balanceTags 1
  3. Added this site to my mobile app
  4. Created a new post with a gallery (confirmed that it was using the original format ✔️ )
  5. Saved and exited the post
  6. Previewed the post (confirmed that the images were still present and the gallery is intact ✔️ )
  7. Reopened the post (:x: gallery shows "problem displaying block")
  8. Checked HTML view (:x: confirmed that the images are missing)
Gallery Visual Gallery HTML
gallery-created-visual gallery-created-html

Preview of Gallery:

Re-opened Gallery Visual Re-opened Gallery HTML
gallery-reopened-visual gallery-reopened-html

So, seemingly something is destroying the gallery on when the editor is opened the second time (maybe in the deprecations flow 🤔 ? ).

Copy link
Contributor

@andrewserong andrewserong left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nice work @glendaviesnz! This is working well for migrating from current v1 markup to v2, while preserving columns settings and "link to" settings 👍

I also tested each of the core__gallery__deprecated-x.html deprecations in the v1 version of the editor. Initially I thought I ran into an issue, but then realised I hadn't pulled in the latest changes, but as of e43a6a7 each of the deprecations is migrating correctly when switching between the code and visual editor views 👍

It's all working well for me in practice. Looking at the diff, the main issue I noticed is that a couple of the fixtures (shortcode-matching-out.html and wordpress-out.html) and a snapshot appear to be stripping the internal img element in the diff, but I wasn't quite sure how best to test them in practice, so not sure if it's an issue? Other than that, I left a couple of tiny nits, but feel free to ignore if they're not relevant!

@@ -21,3 +21,11 @@ export const pickRelevantMediaFiles = ( image, sizeSlug = 'large' ) => {
}
return imageProps;
};

export function isGalleryV2Enabled() {
if ( typeof process !== 'undefined' && process.env?.NODE_ENV === 'test' ) {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is possibly a bit nit-picky, and I imagine it doesn't matter too much since it's a simple check. But I was wondering if this needs to be in run-time code. Would it be possible to set window.wp.galleryBlockV2Enabled to true via globals in Jest config instead? I don't think it's a blocker, though, because the check is neatly tucked away inside the isGalleryV2Enabled function so would be easy to change later if we want to.

Copy link
Contributor Author

@glendaviesnz glendaviesnz Nov 21, 2021

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🤦 yeh, jest globals is a much better option - completely overlooked that for some reason when trying to set this for test runs! Have moved there.

@@ -97,9 +101,11 @@ class NativeEditorProvider extends Component {
galleryWithImageBlocks,
} = this.props;

// TODO: remove this as unnecessary since we are setting in constructor?
window.wp.galleryBlockV2Enabled = galleryWithImageBlocks;
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I haven't tested this, but it looks like it can be removed if it's set in the constructor?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks Andrew! That was a WIP "note to self" 😃 that I intended to circle back to and make sure I wan't missing anything about when this is set from the fetch response (originally this was setting a value in the store via updateSettings, which couldn't be done in the constructor - probably the reason it was set after mount initially). 👍

return true;
}

return window.wp.galleryBlockV2Enabled;
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Tiniest of tiny nits, but since this function is called isGalleryV2Enabled, should this return a boolean (e.g. !!)? Also, I assume that the wp object will always be available in practice, but I see that elsewhere in the Gallery block where window.wp is accessed, we've used optional chaining. Not sure if it's needed here, too?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

should this return a boolean

Hm.. window.wp.galleryBlockV2Enabled already is a boolean, I wonder, do you mean to coerce with !! for the case where it is undefined?

Not sure if it's needed here, too?

Good question.. I had contemplated that as well.. my thinking at the time (at least from the mobile perspective) is that window.wp should be defined (and as an Object), and that since we are altering user content on the basis of this flag, it'd be better to fail fast if that assumption is incorrect, to avoid incorrectly transforming the content. Otoh, this is function is shared cross-platform, so it'd be good to know from the web side whether this assumption is valid - and whether or not failing fast is appropriate there as well in case it's undefined. 🤔

Also, maybe it's actually fine on mobile and web to default to false(y) when the assumption is not met? 🤔 One of the hesitations I originally had was born out of the race conditions we've encountered while testing / debugging these flows - not sure whether the presence (or absence) of window.wp, if even possible, could also be a timing-based condition?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@mkevins, @andrewserong I wonder if we want to default to v2 being enabled if window.wp.galleryBlockV2Enabled is not explicitly set to false, eg. return window.wp?.galleryBlockV2Enabled === false ? false : true; - the reason being that the disabled case with use_balanceTags === 1 and WP < 5.9 is the edge case so are we better to assume we use v2 if wp.galleryBlockV2Enabled was undefined for some reason?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for the thoughts Matthew and Glen!

I wonder, do you mean to coerce with !! for the case where it is undefined?

Yes, I was mostly thinking of how do we want to handle the case of undefined.

I wonder if we want to default to v2 being enabled if window.wp.galleryBlockV2Enabled is not explicitly set to false

That logic sounds good to me, as you say, the presence of the flag is there to deal with an explicit edge case, so handling it with an explicit check for false sounds good to me 👍

@glendaviesnz glendaviesnz force-pushed the update/gallery-block-disable-v2-when-useBalanceTags-set branch from 612a9e4 to dd416ed Compare November 21, 2021 23:46
export function isGalleryV2Enabled() {
// We want to fail early here, at least during beta testing phase, to ensure
// there aren't instances where undefined values cause false negatives.
if ( ! window.wp || typeof window.wp.galleryBlockV2Enabled !== 'boolean' ) {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Just wondering, if this PR is backported to the WP core beta, then will the logic in gutenberg_check_gallery_block_v2_compatibility also be backported? Without it, in 5.9, with Gutenberg deactivated, where wp.galleryBlockV2Enabled isn't set, will this throw an error?

In that case, it could be better to treat the v2 gallery block setting being undefined as true 🤔. I might be missing some context with the impact on mobile, though!

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Good question, Andrew. For the mobile perspective, I'm going to test making true default (because some users will not have a cached value when the editor is initialized):

diff --git a/packages/edit-post/src/editor.native.js b/packages/edit-post/src/editor.native.js
index b045724a04..7f71d7f68a 100644
--- a/packages/edit-post/src/editor.native.js
+++ b/packages/edit-post/src/editor.native.js
@@ -31,7 +31,9 @@ class Editor extends Component {
 		super( ...arguments );
 
 		// need to set this globally to avoid race with deprecations
-		window.wp.galleryBlockV2Enabled = props.galleryWithImageBlocks;
+		// defaulting to true to avoid issues with a not-yet-cached value
+		const { galleryWithImageBlocks = true } = props;
+		window.wp.galleryBlockV2Enabled = galleryWithImageBlocks;
 
 		if ( props.initialHtmlModeEnabled && props.mode === 'visual' ) {
 			// enable html mode if the initial mode the parent wants it but we're not already in it

For mobile, we won't face the same backporting issue, since users on older versions won't encounter this logic, and users on newer versions will default to true (assuming all goes well with testing 👆 ). I wonder if something similar would work (or be appropriate) for web? Or perhaps that is an error that we'd like to surface in beta (if it exists)?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks Matthew, nice to see that's how we'll handle the situation in mobile 👍. Let's see what @glendaviesnz thinks for the web when he's back on tomorrow 🙂

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@andrewserong gutenberg_check_gallery_block_v2_compatibility will also need to be pulled into WP 5.9. The explicit error we are throwing here is mostly for test purposes to see if we ever hit that explicit exception during testing - I wasn't thinking we would leave that in in there permanently, but instead more likely default to true once we are comfortable there aren't any funny edge cases we have overlooked that would have that value as undefined when it really should be false - does that make sense?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, thanks for confirming @glendaviesnz! That does sound like a good way to handle it for the beta and so that issues don't go unnoticed.

It sounds like in that case we might want to open up a PR in wordpress-develop to add in the check_gallery_block_v2_compatibility function prior to this PR landing, since I think the PHP code gets merged in separately from the JS being released in npm packages for 5.9?

Copy link
Contributor Author

@glendaviesnz glendaviesnz Nov 22, 2021

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@andrewserong check_gallery_block_v2_compatibility is in the gutenberg repo and added as part of this PR, so was thinking that it gets included in 5.9 when this PR merge is cherry picked? I don't see any of the other methods in lib/compat.php anywhere in the `wordpress-develop repo, am I missing something?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@glendaviesnz good question — I'm not 100% sure of the order in which things go into 5.9. I believe there are two steps: commits for 5.9 are cherry picked into the wp/trunk branch and then new npm package releases are published (e.g. in this recent commit). Then, the next step is that over in wordpress-develop there's a PR created that updates trunk to point to the new packages (e.g. WordPress/wordpress-develop#1883).

It looks like that latter PR includes some PHP changes in addition to bumping the package numbers. I'm not sure if these changes needed to be made manually? So for the case of check_gallery_block_v2_compatibility, it'd be good to confirm where it'll be merged (or how best to do it) before we merge this PR.

CC: @noisysocks — just a question for the 5.9 release, this PR includes an additional function check_gallery_block_v2_compatibility that currently lives in lib/compat.php in Gutenberg, but will need to exist in core. Do we need to open up a separate PR in wordpress-develop for this function, or will it get rolled in when the PR is cherry picked into 5.9?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

When I prepare the Core patch that updates packages (e.g. WordPress/wordpress-develop#1883) every Monday, I do a diff of what PHP has changed in the Gutenberg plugin (git diff $old_sha wp/trunk **/*.php) and then manually make those changes in Core.

For big PHP changes, I appreciate if the PR author can open a ticket in Core Trac and make those changes themselves. That makes it less likely I have to stay up late on Monday 😀

For smaller changes such as this one, it's okay to leave it with me. You can help me (or any future release lead) out by leaving a note in the doc comment which describes how the change should look once added to Core.

Copy link
Contributor

@andrewserong andrewserong left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@glendaviesnz this PR is testing well for me, thanks for addressing all the global mock for galleryBlockV2Enabled, and it sounds like we're good to go in regards to merging in the PHP change 👍

I haven't been able to fault the changes in this PR, but when I went to test a v1 block with external images, I noticed that I'm unable to click any of the buttons in the v1 gallery block to replace an image with an external image. It's these Upload, Media Library, and Insert from URL buttons in the placeholder that don't appear to be clickable for me (only in the v1 version):

image

Are you able to replicate that? It appears to be unrelated to this PR, but meant that I wasn't too sure how to test that external images were migrated correctly. Other than that, this change LGTM!

@andrewserong
Copy link
Contributor

andrewserong commented Nov 24, 2021

I noticed that I'm unable to click any of the buttons in the v1 gallery block to replace an image with an external image. It's these Upload, Media Library, and Insert from URL buttons in the placeholder that don't appear to be clickable for me (only in the v1 version):

I think I've worked out a fix for this @glendaviesnz, so I'll open up a PR soon 🙂
Edit: fix in #36804

@mkevins
Copy link
Contributor

mkevins commented Nov 24, 2021

I've added a few more commits to fix some issues with the flag (default value, cached value, and fetch response): 0885b7a, 73f556b, 1b6df54.

I've also performed a bunch of tests on a Jurassic Ninja site (WordPress 5.8.2) w/ the plugin built locally from this branch installed:

Gallery Auto-conversion Tests

To test the auto-conversion implementation, I used a test site with ssh access, toggled the remote flag and the locally cached flag, and opened posts with existing V1 and V2 content. The table below shows the results of these tests:

Starting with Flag cached to Remote flag Result New blocks
V1 content undefined false ❌ Content lost V1
V1 content undefined true V2 V2
V1 content false false V1 V1
V1 content false true ❌ Content lost V2
V1 content true false ❌ Content lost V1
V1 content true true V2 V2
V2 content undefined false ❌ Content lost V1
V2 content undefined true V2 V2
V2 content false false ❌ Content lost V1
V2 content false true ❌ Content lost V2
V2 content true false ❌ Content lost V1
V2 content true true V2 V2

In order to toggle the remote flag, the command in the WordPress directory is: wp option set use_balanceTags 0 for true and wp option set use_balanceTags 1 for false (Note: this is "inverted" because the gallery flag is disabled when the use_balanceTags flag is enabled).

In order to manipulate the local cache, the App Inspection tab can be used in Android Studio. Under the wp-fluxc database, the flag is stored in the EditorTheme table. Since this table is regenerated each time the editor loads, it is safe to delete all the records to clear the cache with: DELETE FROM EditorTheme;. Also, it may be convenient to manually set the cached value to true or false by executing either UPDATE EditorTheme SET GALLERY_WITH_IMAGE_BLOCKS=1; or UPDATE EditorTheme SET GALLERY_WITH_IMAGE_BLOCKS=0; queries, respectively.

These tests have only been conducted for Android, though similar behavior should be expected for iOS, excepting that when the local cache is not populated, a default value of false appears to be passed to the editor. We can condition this, if desired, to leave it undefined over the bridge, which would result instead in the JS default value true.

Although many cases in this table result in content loss, the proportion of rows in this table in no way reflects the proportion of users / scenarios where these issues will be encountered. Most of these scenarios are edge cases involving the user toggling the deprecated use_balanceTags setting, or having it on while using the V2 content. For completeness, I conducted each permutation listed above, because there is potential for a race between editor initialization and fetch response (i.e. flag usage while parsing vs. editing blocks). It would be good to get some assurance about the impact of these scenarios. E.g. if usage of use_balanceTags is very minimal, I expect these issues to be encountered very rarely.

@antonis
Copy link
Member

antonis commented Nov 24, 2021

@mkevins Thank you for the mobile fixes and the detailed testing and instructions 🙇
I conducted I few tests today and I confirm your results 👍

Most of these scenarios are edge cases involving the user toggling the deprecated use_balanceTags setting, or having it on while using the V2 content.

I would agree with that. The content loss scenarios are edge cases and most of our users should not be affected.

@glendaviesnz glendaviesnz force-pushed the update/gallery-block-disable-v2-when-useBalanceTags-set branch from bc7a1f2 to da99acb Compare November 29, 2021 02:39
@ramonjd
Copy link
Member

ramonjd commented Nov 29, 2021

I've run through the test instructions and it works as described.

✅ Before checking out this PR, on a site on WP < 5.9 set use_balanceTags option to 1
✅ Then check out this PR and add a gallery and check that it is still the old format (see screenshots below) when editing and viewing and when reloading in the editor
✅ Switch use_balanceTags to 0 and load the v1 Gallery block in the editor and check that it auto migrates to the v2 block format (see screenshots below) and can be edited, saved, reloaded ok
✅ Try setting use_balanceTags back to 1 and you should get an error message about needing to upgrade to WP 5.9
✅ For both v1 and v2 blocks check that you can transform to individual Image blocks and back to Gallery block again, and when transforming back to Gallery make sure it is v1 format for use_balanceTags site, and v2 for others
✅ Also try adding a v1 block with external images (to do this add Image blocks and use the replace button to add the url of an external image - then transform the Image blocks to a Gallery block) and make sure these migrate to v2 gallery format ok. There is a known Image size selector error with this flow

Try setting use_balanceTags back to 1 and you should get an error message about needing to upgrade to WP 5.9

Works on both the settings dashboard and CLI.

Screen Shot 2021-11-29 at 3 56 17 pm

Although the CLI doesn't provide any upgrade feedback

Screen Shot 2021-11-29 at 3 24 14 pm

I ran out of time to test more thoroughly, but will pick it up in the morning.

@ramonjd
Copy link
Member

ramonjd commented Nov 30, 2021

Things are working well still for me!

CLI error appears with the latest change 🌮

Screen Shot 2021-11-30 at 11 36 00 am

I noticed one peculiarity: When I have use_balanceTags === 1 (v1) activated, when I transform an Image to a v1 Gallery, and then select Link to: Attachment page in the dropdown, the attachment link doesn't appear.

Kapture 2021-11-30 at 12 10 29

I ran out of time to debug (again) sorry, but would we need to do something similar to what we did in #36388?


if ( 1 === (int) $new_value && version_compare( $wp_version, '5.9', '<' ) ) {
/* translators: %s: Minimum required version */
$message = sprintf( __( 'Gutenberg requires WordPress %s or later in order to enable the &#8220;Correct invalidly nested XHTML automatically&#8221; option. Please upgrade WordPress before enabling.', 'gutenberg' ), '5.9' );
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Not a biggie, but would it possible to strip or replace the HTML entities for the CLI?

Screen Shot 2021-11-30 at 11 36 00 am

Copy link
Contributor Author

@glendaviesnz glendaviesnz Nov 30, 2021

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The chance of somebody toggling on this option via CLI with gutenberg 12.1+ on WP < 5.9 is so slim as to not warrant the bother of adding a string replace method here in my view.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sounds fair enough to me 👍

@glendaviesnz
Copy link
Contributor Author

I noticed one peculiarity: When I have use_balanceTags === 1 (v1) activated, when I transform an Image to a v1 Gallery, and then select Link to: Attachment page in the dropdown, the attachment link doesn't appear.

Nice catch! It looks like this is an existing bug - I get the same thing on 10.9.0, which is before the new Gallery was merged. It will take a bit of work to fix this as it requires for additional calls to getMedia after the transform in order to get the images link data. I am going to suggest that the fix for this is for the user to instead upgrade to 5.9 and use the new Gallery block - sound like a plan @ramonjd ?

Glen Davies and others added 11 commits December 1, 2021 12:16
This makes sure the global value for the flag is established when the
editor is initialized, since some users may not have the value cached
locally yet. This is important to avoid incorrectly branching in the
parsing step, resulting in an incompatible block format.
This adds the flag to the destructuring of the fetch callback (so it is
not binding to the stale closure value), and also conditionally updates
the global only if the type is explicitly boolean. This avoids a
scenario in which updates to other editor settings which omit the
gallery flag property result in the global value being overwritten with
`undefined`.
This adds logic to ensure we report the gallery flag when the editor
settings are fetched.
This allows the value to be set to default `true` on the JS side,
instead of defaulting to a value of `false` from iOS native code.
@glendaviesnz glendaviesnz force-pushed the update/gallery-block-disable-v2-when-useBalanceTags-set branch from 97ad0dd to c752d64 Compare November 30, 2021 23:17
@ramonjd
Copy link
Member

ramonjd commented Nov 30, 2021

I get the same thing on 10.9.0, which is before the new Gallery was merged. It will take a bit of work to fix this as it requires for additional calls to getMedia after the transform in order to get the images link data. I am going to suggest that the fix for this is for the user to instead upgrade to 5.9 and use the new Gallery block - sound like a plan @ramonjd ?

Oh great! Thanks for checking that it's an existing issue. In that case, it makes sense that we don't address it here and rely on the new gallery upgrade. Sounds good.

Copy link
Contributor

@andrewserong andrewserong left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Great work again @glendaviesnz and @mkevins! This is testing well for me, and I haven't been able to find any faults with it 😀

✅ The auto-migration works correctly, irrespective of the use_balanceTags option when I'm running WP 5.9
✅ In 5.8.x, with use_balanceTags set to 1, editing the gallery remains in the v1 version of the gallery block
✅ In 5.8.x, if use_balanceTags is set to 0, I'm unable to set it to 1 and the error message is rendered in the UI and in the CLI, and the UI message looks good:

image

✅ In 5.8.x, the v1 gallery is being correctly auto-migrated to the v2 format, with settings and external images preserved correctly
✅ Updated text for the app version notice when inserting a gallery block reads well to me

image

This LGTM, and I did a quick visual skim of the code changes again. I'm not very familiar with React Native, but no issues jumped out at me from looking over the changes 🙂

Copy link
Member

@ramonjd ramonjd left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I went through the same testing steps as before in #36191 (comment)

I also added a bunch of v1 galleries to a page, some with external images. All migrated as expected.

The v2 gallery on its own works as expected after migration as well.

🥇 Nice work!

@glendaviesnz glendaviesnz merged commit 8fb36de into trunk Dec 1, 2021
@glendaviesnz glendaviesnz deleted the update/gallery-block-disable-v2-when-useBalanceTags-set branch December 1, 2021 01:01
@github-actions github-actions bot added this to the Gutenberg 12.1 milestone Dec 1, 2021
@noisysocks noisysocks removed the Backport to WP 6.7 Beta/RC Pull request that needs to be backported to the WordPress major release that's currently in beta label Dec 6, 2021
noisysocks pushed a commit that referenced this pull request Dec 6, 2021
…at when edited (#36191)

* Remove update gallery modal
* Add check for gallery v2 compat (block sites with use_BalanceTags option enabled and aren't on WP 5.9 or higher) to editor init so it is available when block deprecation pipeline runs
* Remove references to gallery experimental flag
* Add missing transformation updates
* Update fixture to be compat with v2 of gallery block
* Fix unit tests
* Fix issue with link destination not being set when block migrated
* Use `window.wp` global instead of store for gallery flag To resolve a race with the deprecations and asynchronous store updates for the gallery flag, we can use a property on the global wp object instead.
* Simplify deprecations, etc. by always using using v1 methods if use_balanceTags is on regardless of content format
* Move assignment of gallery global flag to native Editor. This moves the setting of the global flag higher in the view hierarchy, since the provider's constructor is still too late (parsing code invokes the deprecations before even the provider is instantiated).
* Default to `true` for gallery flag when not yet cached This makes sure the global value for the flag is established when the editor is initialized, since some users may not have the value cached locally yet. This is important to avoid incorrectly branching in the parsing step, resulting in an incompatible block format.
* Only update gallery flag if fetch result is explicitly boolean
* Update the wording of the mobile warning
* Add filter to prevent use_balanceTags being enabled on WP < 5.9
* Switch to using settings_error for use_balanceTags notice
* Add a CLI error message

Co-authored-by: Glen Davies <[email protected]>
Co-authored-by: Matthew Kevins <[email protected]>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
[Block] Gallery Affects the Gallery Block - used to display groups of images
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants