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

Rename Group blocks in the Editor via Modal #53735

Merged
merged 38 commits into from
Sep 1, 2023

Conversation

getdave
Copy link
Contributor

@getdave getdave commented Aug 16, 2023

What?

Screen Shot 2023-08-16 at 14 29 09

Adds the ability to give blocks (currently limited to Group block) a custom name via a Rename item in the block's options menu.

This is then displayed in the List View (although that functionality was enabled in a previous PR).

⚠️ Unlike #42605 you cannot double click to rename blocks in the List View. See below for why this PR doesn't pursue this approach.

Alternative to

Why?

Allowing users to distinguish between blocks in the List View is becoming increasingly important as the scope of the Site Editor grows. Given that all blocks are currently labelled by the block name (e.g. Group) it can be difficult to distinguish between them. This is especially important if your Groups represent distinct "sections" of a given page/template.

As you can see the feature is much requested.

Why not pursue the existing PR for renaming within List View?

#42605 has been around for a while and was my original attempt at this. Unfortunately it was beset by a number of a11y changes relating to editing/renaming inline with the list view.

In the PR several contributors suggested making the it a global feature where rename could be handled via a modal. Returning to the PR it makes sense to land this simpler and more intuitive approach first and then circle back to the "inline" block editing (within the list view) if that is possible/desirable.

Why is this limited to the Group block?

The aim is to limit the scope of the change. Once merged it will be possible to follow up to enable this feature for other "container" type blocks.

Where are you saving this custom name data?

It's saved to the block's metadata attribute under the name property. That's in WP Core and standard.

{
    "attributes": {
        "metadata": {
            "name": "My custom name"
        }
    }
}

How?

Adds a Rename menu item to the block's options menu (available in canvas or in list view). When clicked a modal appears which allows you to provide a custom name for the block.

Once applied the block's metadata is set with a custom name attribute which is then reflected everywhere that consumes useBlockInformation (that was added previously in another PR).

This means that List View will show the custom name.

Testing Instructions

  • New Post (or enter the Site Editor)
  • Add some blocks and then Group them.
  • Open List View
  • Now open the block options menu (either via List View or via the block in the canvas) and click Rename.
  • Type a custom name and save.
  • See custom name is now shown in List View.
  • Bring up the Rename UI again, but this time remove all of the text and click out of the input field (triggering onBlur).
  • See the value reset to the block's original name (e.g. Group). See the Save button is active again.
  • Save the change and verify it updated.
  • Switch to codeview and check the metadata.name attribute was reset (it should not be Group).

Testing Instructions for Keyboard

  • Do the same as for Testing instructions above but use the keyboard.
  • Ensure that modal fields are perceivable and focus is placed inside the modal.
  • Check that the form is intuitive to use and has accessible roles.
  • Check you can submit / cancel the change.
  • Key that focus is correctly restored to wherever you "came" from when you triggered "Rename".

Screenshots or screencast

Screen.Capture.on.2023-08-16.at.14-17-10.mp4
Screen Shot 2023-08-16 at 14 28 25

@getdave getdave added the [Type] Feature New feature to highlight in changelogs. label Aug 16, 2023
@getdave getdave self-assigned this Aug 16, 2023
@getdave getdave marked this pull request as ready for review August 16, 2023 13:19
@getdave
Copy link
Contributor Author

getdave commented Aug 16, 2023

I would appreciate any ideas on if/how we can create a UI which allows users to revert the custom naming back to the original (e.g. Group). Probably one for a followup...

@github-actions
Copy link

github-actions bot commented Aug 16, 2023

Size Change: +585 B (0%)

Total Size: 1.51 MB

Filename Size Change
build/block-editor/index.min.js 214 kB +549 B (0%)
build/block-editor/style-rtl.css 15 kB +14 B (0%)
build/block-editor/style.css 15 kB +14 B (0%)
build/block-library/index.min.js 203 kB +8 B (0%)
ℹ️ View Unchanged
Filename Size
build/a11y/index.min.js 955 B
build/annotations/index.min.js 2.69 kB
build/api-fetch/index.min.js 2.28 kB
build/autop/index.min.js 2.1 kB
build/blob/index.min.js 451 B
build/block-directory/index.min.js 7.01 kB
build/block-directory/style-rtl.css 1.02 kB
build/block-directory/style.css 1.02 kB
build/block-editor/content-rtl.css 4.25 kB
build/block-editor/content.css 4.24 kB
build/block-editor/default-editor-styles-rtl.css 381 B
build/block-editor/default-editor-styles.css 381 B
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 90 B
build/block-library/blocks/archives/style.css 90 B
build/block-library/blocks/audio/editor-rtl.css 150 B
build/block-library/blocks/audio/editor.css 150 B
build/block-library/blocks/audio/style-rtl.css 122 B
build/block-library/blocks/audio/style.css 122 B
build/block-library/blocks/audio/theme-rtl.css 126 B
build/block-library/blocks/audio/theme.css 126 B
build/block-library/blocks/avatar/editor-rtl.css 116 B
build/block-library/blocks/avatar/editor.css 116 B
build/block-library/blocks/avatar/style-rtl.css 104 B
build/block-library/blocks/avatar/style.css 104 B
build/block-library/blocks/block/editor-rtl.css 305 B
build/block-library/blocks/block/editor.css 305 B
build/block-library/blocks/button/editor-rtl.css 584 B
build/block-library/blocks/button/editor.css 582 B
build/block-library/blocks/button/style-rtl.css 629 B
build/block-library/blocks/button/style.css 628 B
build/block-library/blocks/buttons/editor-rtl.css 337 B
build/block-library/blocks/buttons/editor.css 337 B
build/block-library/blocks/buttons/style-rtl.css 332 B
build/block-library/blocks/buttons/style.css 332 B
build/block-library/blocks/calendar/style-rtl.css 239 B
build/block-library/blocks/calendar/style.css 239 B
build/block-library/blocks/categories/editor-rtl.css 113 B
build/block-library/blocks/categories/editor.css 112 B
build/block-library/blocks/categories/style-rtl.css 124 B
build/block-library/blocks/categories/style.css 124 B
build/block-library/blocks/code/editor-rtl.css 53 B
build/block-library/blocks/code/editor.css 53 B
build/block-library/blocks/code/style-rtl.css 121 B
build/block-library/blocks/code/style.css 121 B
build/block-library/blocks/code/theme-rtl.css 124 B
build/block-library/blocks/code/theme.css 124 B
build/block-library/blocks/columns/editor-rtl.css 108 B
build/block-library/blocks/columns/editor.css 108 B
build/block-library/blocks/columns/style-rtl.css 421 B
build/block-library/blocks/columns/style.css 421 B
build/block-library/blocks/comment-author-avatar/editor-rtl.css 125 B
build/block-library/blocks/comment-author-avatar/editor.css 125 B
build/block-library/blocks/comment-content/style-rtl.css 92 B
build/block-library/blocks/comment-content/style.css 92 B
build/block-library/blocks/comment-template/style-rtl.css 199 B
build/block-library/blocks/comment-template/style.css 198 B
build/block-library/blocks/comments-pagination-numbers/editor-rtl.css 123 B
build/block-library/blocks/comments-pagination-numbers/editor.css 121 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/comments-title/editor-rtl.css 75 B
build/block-library/blocks/comments-title/editor.css 75 B
build/block-library/blocks/comments/editor-rtl.css 840 B
build/block-library/blocks/comments/editor.css 839 B
build/block-library/blocks/comments/style-rtl.css 637 B
build/block-library/blocks/comments/style.css 636 B
build/block-library/blocks/cover/editor-rtl.css 647 B
build/block-library/blocks/cover/editor.css 650 B
build/block-library/blocks/cover/style-rtl.css 1.63 kB
build/block-library/blocks/cover/style.css 1.62 kB
build/block-library/blocks/details/editor-rtl.css 65 B
build/block-library/blocks/details/editor.css 65 B
build/block-library/blocks/details/style-rtl.css 98 B
build/block-library/blocks/details/style.css 98 B
build/block-library/blocks/embed/editor-rtl.css 293 B
build/block-library/blocks/embed/editor.css 293 B
build/block-library/blocks/embed/style-rtl.css 410 B
build/block-library/blocks/embed/style.css 410 B
build/block-library/blocks/embed/theme-rtl.css 126 B
build/block-library/blocks/embed/theme.css 126 B
build/block-library/blocks/file/editor-rtl.css 316 B
build/block-library/blocks/file/editor.css 316 B
build/block-library/blocks/file/style-rtl.css 280 B
build/block-library/blocks/file/style.css 281 B
build/block-library/blocks/file/view-interactivity.min.js 317 B
build/block-library/blocks/file/view.min.js 375 B
build/block-library/blocks/footnotes/style-rtl.css 201 B
build/block-library/blocks/footnotes/style.css 199 B
build/block-library/blocks/freeform/editor-rtl.css 2.61 kB
build/block-library/blocks/freeform/editor.css 2.61 kB
build/block-library/blocks/gallery/editor-rtl.css 947 B
build/block-library/blocks/gallery/editor.css 952 B
build/block-library/blocks/gallery/style-rtl.css 1.53 kB
build/block-library/blocks/gallery/style.css 1.53 kB
build/block-library/blocks/gallery/theme-rtl.css 108 B
build/block-library/blocks/gallery/theme.css 108 B
build/block-library/blocks/group/editor-rtl.css 654 B
build/block-library/blocks/group/editor.css 654 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 76 B
build/block-library/blocks/heading/style.css 76 B
build/block-library/blocks/html/editor-rtl.css 336 B
build/block-library/blocks/html/editor.css 337 B
build/block-library/blocks/image/editor-rtl.css 834 B
build/block-library/blocks/image/editor.css 833 B
build/block-library/blocks/image/style-rtl.css 1.42 kB
build/block-library/blocks/image/style.css 1.41 kB
build/block-library/blocks/image/theme-rtl.css 126 B
build/block-library/blocks/image/theme.css 126 B
build/block-library/blocks/image/view-interactivity.min.js 1.83 kB
build/block-library/blocks/latest-comments/style-rtl.css 357 B
build/block-library/blocks/latest-comments/style.css 357 B
build/block-library/blocks/latest-posts/editor-rtl.css 213 B
build/block-library/blocks/latest-posts/editor.css 212 B
build/block-library/blocks/latest-posts/style-rtl.css 478 B
build/block-library/blocks/latest-posts/style.css 478 B
build/block-library/blocks/list/style-rtl.css 88 B
build/block-library/blocks/list/style.css 88 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 505 B
build/block-library/blocks/media-text/style.css 503 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 712 B
build/block-library/blocks/navigation-link/editor.css 711 B
build/block-library/blocks/navigation-link/style-rtl.css 115 B
build/block-library/blocks/navigation-link/style.css 115 B
build/block-library/blocks/navigation-submenu/editor-rtl.css 296 B
build/block-library/blocks/navigation-submenu/editor.css 295 B
build/block-library/blocks/navigation/editor-rtl.css 2.26 kB
build/block-library/blocks/navigation/editor.css 2.26 kB
build/block-library/blocks/navigation/style-rtl.css 2.23 kB
build/block-library/blocks/navigation/style.css 2.22 kB
build/block-library/blocks/navigation/view-interactivity.min.js 988 B
build/block-library/blocks/navigation/view-modal.min.js 2.85 kB
build/block-library/blocks/navigation/view.min.js 469 B
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 401 B
build/block-library/blocks/page-list/editor.css 401 B
build/block-library/blocks/page-list/style-rtl.css 175 B
build/block-library/blocks/page-list/style.css 175 B
build/block-library/blocks/paragraph/editor-rtl.css 174 B
build/block-library/blocks/paragraph/editor.css 174 B
build/block-library/blocks/paragraph/style-rtl.css 279 B
build/block-library/blocks/paragraph/style.css 281 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/editor-rtl.css 96 B
build/block-library/blocks/post-comments-form/editor.css 96 B
build/block-library/blocks/post-comments-form/style-rtl.css 508 B
build/block-library/blocks/post-comments-form/style.css 508 B
build/block-library/blocks/post-date/style-rtl.css 61 B
build/block-library/blocks/post-date/style.css 61 B
build/block-library/blocks/post-excerpt/editor-rtl.css 71 B
build/block-library/blocks/post-excerpt/editor.css 71 B
build/block-library/blocks/post-excerpt/style-rtl.css 141 B
build/block-library/blocks/post-excerpt/style.css 141 B
build/block-library/blocks/post-featured-image/editor-rtl.css 588 B
build/block-library/blocks/post-featured-image/editor.css 586 B
build/block-library/blocks/post-featured-image/style-rtl.css 319 B
build/block-library/blocks/post-featured-image/style.css 319 B
build/block-library/blocks/post-navigation-link/style-rtl.css 153 B
build/block-library/blocks/post-navigation-link/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 314 B
build/block-library/blocks/post-template/style.css 314 B
build/block-library/blocks/post-terms/style-rtl.css 96 B
build/block-library/blocks/post-terms/style.css 96 B
build/block-library/blocks/post-time-to-read/style-rtl.css 69 B
build/block-library/blocks/post-time-to-read/style.css 69 B
build/block-library/blocks/post-title/style-rtl.css 100 B
build/block-library/blocks/post-title/style.css 100 B
build/block-library/blocks/preformatted/style-rtl.css 125 B
build/block-library/blocks/preformatted/style.css 125 B
build/block-library/blocks/pullquote/editor-rtl.css 135 B
build/block-library/blocks/pullquote/editor.css 135 B
build/block-library/blocks/pullquote/style-rtl.css 335 B
build/block-library/blocks/pullquote/style.css 335 B
build/block-library/blocks/pullquote/theme-rtl.css 168 B
build/block-library/blocks/pullquote/theme.css 168 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 302 B
build/block-library/blocks/query-pagination/style.css 299 B
build/block-library/blocks/query-title/style-rtl.css 63 B
build/block-library/blocks/query-title/style.css 63 B
build/block-library/blocks/query/editor-rtl.css 450 B
build/block-library/blocks/query/editor.css 449 B
build/block-library/blocks/query/style-rtl.css 370 B
build/block-library/blocks/query/style.css 368 B
build/block-library/blocks/query/view.min.js 559 B
build/block-library/blocks/quote/style-rtl.css 222 B
build/block-library/blocks/quote/style.css 222 B
build/block-library/blocks/quote/theme-rtl.css 223 B
build/block-library/blocks/quote/theme.css 226 B
build/block-library/blocks/read-more/style-rtl.css 132 B
build/block-library/blocks/read-more/style.css 132 B
build/block-library/blocks/rss/editor-rtl.css 149 B
build/block-library/blocks/rss/editor.css 149 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 178 B
build/block-library/blocks/search/editor.css 178 B
build/block-library/blocks/search/style-rtl.css 607 B
build/block-library/blocks/search/style.css 607 B
build/block-library/blocks/search/theme-rtl.css 114 B
build/block-library/blocks/search/theme.css 114 B
build/block-library/blocks/search/view.min.js 631 B
build/block-library/blocks/separator/editor-rtl.css 146 B
build/block-library/blocks/separator/editor.css 146 B
build/block-library/blocks/separator/style-rtl.css 234 B
build/block-library/blocks/separator/style.css 234 B
build/block-library/blocks/separator/theme-rtl.css 194 B
build/block-library/blocks/separator/theme.css 194 B
build/block-library/blocks/shortcode/editor-rtl.css 323 B
build/block-library/blocks/shortcode/editor.css 323 B
build/block-library/blocks/site-logo/editor-rtl.css 754 B
build/block-library/blocks/site-logo/editor.css 754 B
build/block-library/blocks/site-logo/style-rtl.css 204 B
build/block-library/blocks/site-logo/style.css 204 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 116 B
build/block-library/blocks/site-title/editor.css 116 B
build/block-library/blocks/site-title/style-rtl.css 57 B
build/block-library/blocks/site-title/style.css 57 B
build/block-library/blocks/social-link/editor-rtl.css 184 B
build/block-library/blocks/social-link/editor.css 184 B
build/block-library/blocks/social-links/editor-rtl.css 682 B
build/block-library/blocks/social-links/editor.css 681 B
build/block-library/blocks/social-links/style-rtl.css 1.44 kB
build/block-library/blocks/social-links/style.css 1.43 kB
build/block-library/blocks/spacer/editor-rtl.css 348 B
build/block-library/blocks/spacer/editor.css 348 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 432 B
build/block-library/blocks/table/editor.css 432 B
build/block-library/blocks/table/style-rtl.css 639 B
build/block-library/blocks/table/style.css 639 B
build/block-library/blocks/table/theme-rtl.css 146 B
build/block-library/blocks/table/theme.css 146 B
build/block-library/blocks/tag-cloud/style-rtl.css 251 B
build/block-library/blocks/tag-cloud/style.css 253 B
build/block-library/blocks/template-part/editor-rtl.css 403 B
build/block-library/blocks/template-part/editor.css 403 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/term-description/style-rtl.css 111 B
build/block-library/blocks/term-description/style.css 111 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 99 B
build/block-library/blocks/verse/style.css 99 B
build/block-library/blocks/video/editor-rtl.css 552 B
build/block-library/blocks/video/editor.css 555 B
build/block-library/blocks/video/style-rtl.css 185 B
build/block-library/blocks/video/style.css 185 B
build/block-library/blocks/video/theme-rtl.css 126 B
build/block-library/blocks/video/theme.css 126 B
build/block-library/classic-rtl.css 179 B
build/block-library/classic.css 179 B
build/block-library/common-rtl.css 1.1 kB
build/block-library/common.css 1.1 kB
build/block-library/editor-elements-rtl.css 75 B
build/block-library/editor-elements.css 75 B
build/block-library/editor-rtl.css 12.1 kB
build/block-library/editor.css 12.1 kB
build/block-library/elements-rtl.css 54 B
build/block-library/elements.css 54 B
build/block-library/reset-rtl.css 478 B
build/block-library/reset.css 478 B
build/block-library/style-rtl.css 13.8 kB
build/block-library/style.css 13.8 kB
build/block-library/theme-rtl.css 688 B
build/block-library/theme.css 693 B
build/block-serialization-default-parser/index.min.js 1.12 kB
build/block-serialization-spec-parser/index.min.js 2.87 kB
build/blocks/index.min.js 51.4 kB
build/commands/index.min.js 15.5 kB
build/commands/style-rtl.css 932 B
build/commands/style.css 929 B
build/components/index.min.js 245 kB
build/components/style-rtl.css 11.8 kB
build/components/style.css 11.8 kB
build/compose/index.min.js 12.1 kB
build/core-commands/index.min.js 2.72 kB
build/core-data/index.min.js 16.8 kB
build/customize-widgets/index.min.js 12 kB
build/customize-widgets/style-rtl.css 1.46 kB
build/customize-widgets/style.css 1.45 kB
build/data-controls/index.min.js 640 B
build/data/index.min.js 8.38 kB
build/date/index.min.js 17.8 kB
build/deprecated/index.min.js 451 B
build/dom-ready/index.min.js 324 B
build/dom/index.min.js 4.64 kB
build/edit-post/classic-rtl.css 544 B
build/edit-post/classic.css 545 B
build/edit-post/index.min.js 35.5 kB
build/edit-post/style-rtl.css 7.62 kB
build/edit-post/style.css 7.62 kB
build/edit-site/index.min.js 91 kB
build/edit-site/style-rtl.css 13.2 kB
build/edit-site/style.css 13.2 kB
build/edit-widgets/index.min.js 16.9 kB
build/edit-widgets/style-rtl.css 4.52 kB
build/edit-widgets/style.css 4.52 kB
build/editor/index.min.js 45.5 kB
build/editor/style-rtl.css 3.53 kB
build/editor/style.css 3.52 kB
build/element/index.min.js 4.82 kB
build/escape-html/index.min.js 537 B
build/format-library/index.min.js 7.73 kB
build/format-library/style-rtl.css 554 B
build/format-library/style.css 553 B
build/hooks/index.min.js 1.55 kB
build/html-entities/index.min.js 448 B
build/i18n/index.min.js 3.58 kB
build/interactivity/index.min.js 11.2 kB
build/is-shallow-equal/index.min.js 527 B
build/keyboard-shortcuts/index.min.js 1.64 kB
build/keycodes/index.min.js 1.87 kB
build/list-reusable-blocks/index.min.js 2.2 kB
build/list-reusable-blocks/style-rtl.css 836 B
build/list-reusable-blocks/style.css 836 B
build/media-utils/index.min.js 2.9 kB
build/notices/index.min.js 948 B
build/nux/index.min.js 1.99 kB
build/nux/style-rtl.css 735 B
build/nux/style.css 732 B
build/patterns/index.min.js 2.71 kB
build/patterns/style-rtl.css 240 B
build/patterns/style.css 240 B
build/plugins/index.min.js 1.79 kB
build/preferences-persistence/index.min.js 1.84 kB
build/preferences/index.min.js 1.24 kB
build/primitives/index.min.js 943 B
build/priority-queue/index.min.js 1.52 kB
build/private-apis/index.min.js 958 B
build/react-i18n/index.min.js 615 B
build/react-refresh-entry/index.min.js 9.47 kB
build/react-refresh-runtime/index.min.js 7.31 kB
build/redux-routine/index.min.js 2.7 kB
build/reusable-blocks/index.min.js 2.7 kB
build/reusable-blocks/style-rtl.css 243 B
build/reusable-blocks/style.css 243 B
build/rich-text/index.min.js 11 kB
build/router/index.min.js 1.78 kB
build/server-side-render/index.min.js 1.94 kB
build/shortcode/index.min.js 1.39 kB
build/style-engine/index.min.js 1.85 kB
build/sync/index.min.js 53.8 kB
build/token-list/index.min.js 582 B
build/url/index.min.js 3.73 kB
build/vendors/inert-polyfill.min.js 2.48 kB
build/vendors/react-dom.min.js 41.8 kB
build/vendors/react.min.js 4.02 kB
build/viewport/index.min.js 958 B
build/warning/index.min.js 249 B
build/widgets/index.min.js 7.16 kB
build/widgets/style-rtl.css 1.15 kB
build/widgets/style.css 1.16 kB
build/wordcount/index.min.js 1.02 kB

compressed-size-action

@getdave
Copy link
Contributor Author

getdave commented Aug 16, 2023

@alexstine In terms of a11y, I tested this with Voiceover and it seemed to work well. The only question I have is whether once you submit/cancel we should add a speak() to announce that the changes have been made (or not!).

@getdave getdave added the Needs Accessibility Feedback Need input from accessibility label Aug 16, 2023
@fabiankaegy

This comment was marked as resolved.

@getdave

This comment was marked as resolved.

@Mamaduka
Copy link
Member

Mamaduka commented Aug 16, 2023

Nice! I forgot that we shipped a #43986, so it to me a minute to realize why the List View could already display changed name 😄

@getdave getdave requested a review from kevin940726 August 16, 2023 17:11
@getdave
Copy link
Contributor Author

getdave commented Aug 16, 2023

Also resurfacing this comment by @mtias asking for this effort to be aligned with partially synced patterns.

That comment thread lead to a dead-end so I'm pinging @kevin940726 who I believe is still working on this feature 😅

@github-actions
Copy link

github-actions bot commented Aug 16, 2023

Flaky tests detected in 39fe73a.
Some tests passed with failed attempts. The failures may not be related to this commit but are still reported for visibility. See the documentation for more information.

🔍 Workflow run URL: https://github.com/WordPress/gutenberg/actions/runs/6048004840
📝 Reported issues:

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, I like the idea of just starting with the Group block, too 👍

Nice! I forgot that we shipped a #43986, so it to me a minute to realize why the List View could already display changed name 😄

Same here 😆. A good case of a feature being built iteratively! 🎉

I would appreciate any ideas on if/how we can create a UI which allows users to revert the custom naming back to the original (e.g. Group). Probably one for a followup...

Could we allow saving an empty block name field to perform a reset? I.e. if a user opens the modal with a custom name set, and then deletes the custom name, could we allow the Save button to work? I suppose that'd mean updating the check so that we only look for notEmptyString if there isn't already a custom name set. Here's how it's looking for me currently:

2023-08-17 11 35 58

Other than that, this is testing very nicely for me.

One question re: how the code's organised — do we need the separate block-rename-ui.js file, or could we combine things in the metadata-name file, so that the UI related to the hook is contained within the one file? I don't feel strongly about it, but I see there's quite a few files in this directory, so wondered if it'd help consolidating things in one place. Just a thought, though!

@Mamaduka
Copy link
Member

Could we allow saving an empty block name field to perform a reset?

I was thinking about something similar last night. Here's the logic I had in mind:

  1. When the input field is cleared, the component sets the internal state to the block's default name (we could use onBlur here). This should help with visual feedback that the block name has been reset.
  2. In the "save flow," we can check if a submitted name is the original and set the meta value to undefined.

@andrewserong
Copy link
Contributor

Here's the logic I had in mind:

I like it!

@getdave
Copy link
Contributor Author

getdave commented Aug 17, 2023

  1. When the input field is cleared, the component sets the internal state to the block's default name (we could use onBlur here). This should help with visual feedback that the block name has been reset.
  2. In the "save flow," we can check if a submitted name is the original and set the meta value to undefined.

✅ This has been implemented

@getdave
Copy link
Contributor Author

getdave commented Aug 17, 2023

One question re: how the code's organised — do we need the separate block-rename-ui.js file, or could we combine things in the metadata-name file

@andrewserong I was following the example set by:

https://github.com/WordPress/gutenberg/blob/fb37f1ffe616bb64758ef150bab9dbde8be95097/packages/block-editor/src/hooks/content-lock-ui.js

Personally I don't think the registration of the metadata field name and the UI are necessarily related. For example, in the future we may choose to have another means of editing the name that doesn't involve modals or anything like that. For example, we might want to enable editing the name from the List View (a la Photoshop layer renaming).

However, if there is a precedent / convention established that it would be helpful to follow I'm happy to do so.

@getdave
Copy link
Contributor Author

getdave commented Aug 17, 2023

Writing some e2e tests now.

@alexstine
Copy link
Contributor

@millertchris Its also worth pointing out that OS-specific functionality is not generally impacted by web standards. Screen readers use available OS APIs to maintain compatibility outside of the web and these are generally a lot more stable vs. countless ARIA attributes. There is a difficult aspect in accessibility around education, that users are just supposed to know certain things. Its one thing to double click and rename, its another to know you need to press F2 or Shift+F10, Down Arrow to Rename, and then press Enter.

My brain is always learning new keyboard shortcuts because even different Microsoft Office programs have different interaction models. Its a lot to ask of a user to constantly remember more shortcuts and interaction models.

Plus the modal approach helps us with focus. That is a problem you generally don't worry about so much in the OS layer but it matters a lot in SPAs rendered by React.

Feel free to connect with me on Slack, at alexstine, if you want to discuss this further. I am blind and I graduated with many blind people, so I can speak much further to why we should avoid the type of interactions you describe. I want Gutenberg to do things differently for the accessibility of it to all.

Thanks for adding your opinion. Ideas are important for any projects success.

@richtabor
Copy link
Member

@alexstine what's your opinion on maintaining the modal functionality alongside double-click?

@alexstine
Copy link
Contributor

@richtabor Unusable for me but as long as the rename option exists in the block options menu, I'm fine with it. Thanks.

@millertchris
Copy link

@alexstine here are my responses:

@alexstine what's your opinion on maintaining the modal functionality alongside double-click?
@richtabor Unusable for me but as long as the rename option exists in the block options menu, I'm fine with it. Thanks.

@alexstine double-click is unusable to you but the enter key is not, right? That's how you interact with forms and countless other element when you have focus, correct?

Its also worth pointing out that OS-specific functionality is not generally impacted by web standards. Screen readers use available OS APIs to maintain compatibility outside of the web and these are generally a lot more stable vs. countless ARIA attributes.

Fair point — but I would also look to all other widely adopted UX patterns for renaming things on the web i.e. Chrome Bookmarks, Firefox Bookmarks, Figma, etc, etc.

There is a difficult aspect in accessibility around education, that users are just supposed to know certain things. Its one thing to double click and rename, its another to know you need to press F2 or Shift+F10, Down Arrow to Rename, and then press Enter.

I agree — and that's what tooltips, labels, landmarks, etc are used for. To announce to the user when an action can be taken and how to take that action. Also, remember that users are also all accustomed to renaming things in all of these other platforms i.e. Google Chrome Bookmarks — so my position on this matter is let's not force the user to learn how to do the same thing differently just because they are using WordPress.

My brain is always learning new keyboard shortcuts because even different Microsoft Office programs have different interaction models. Its a lot to ask of a user to constantly remember more shortcuts and interaction models.

I'm not sure I follow this point — CMD + C / CMD + V is the same shortcut across every piece of software. Could you imagine if a piece of software decided not to adopt this and how disruptive that would be?

Plus the modal approach helps us with focus. That is a problem you generally don't worry about so much in the OS layer but it matters a lot in SPAs rendered by React.

I disagree — in order for the modal to be in focus, you have to write some additional JS to make it so. However, if the user has already tabbed to the layer or clicked on the layer, it's already in focus. No additional actions necessary. I'm not exactly sure what type of markup is used for the layer markup but if it where an input (but styled to look like regular text) and the input label visually hidden — that would follow existing accessibility best practices.

Feel free to connect with me on Slack, at alexstine, if you want to discuss this further. I am blind and I graduated with many blind people, so I can speak much further to why we should avoid the type of interactions you describe. I want Gutenberg to do things differently for the accessibility of it to all.

I appreciate the invite and I'll look you up! I myself am a low vision user and have been working with American Printing House for the Blind for many years. Our agency is also working on a beta release for an ALT text WordPress plugin that leverages AI to help ensure that all images on the web receive helpful alt text. I would love to chat with you about that some more when we connect.

@getdave here are my responses:

Nonetheless, as other contributors have noted, whilst this feature is implemented in a certain way in those tools doesn't necessarily mean we should do the same in WordPress if it provides a poor experience for groups of users.

I would argue that massive amounts of engineers, developers, designers, etc over the decades have put a tremoundous amount of thought and consideration into how this work. Again, think Chrome, Firefox, Mac, Windows, Linux, and the endless sea of software that we all use on a daily basis all adhere to the same design and UX pattern when it comes to renaming things. Accessibility included.

It feels like we are trying to reinvent the spoon here.

Would you agree that the route taken to draw on the expertise of those in the community is the the best one for deciding between multiple (potentially subjective) opinions? A wide range of views were sought (developers, designers, a11y experts...etc) to come to the best possible conclusion.

Absolutely and I admire the amount of attention and effort that went into this. I still question how this is a more accessible or a better UX experience. If the WordPress community is attempting to "reimagine" this particular experience — then is the community taking a stand or wanting to influence how all other platforms operate?

If so, then that's something I could personally get behind — but if not — then why?

I'm totally down with helping in anyway possible — and subjectively — I would love to see a solution in core (eventually) that aligns with the same UX we see across all pieces of software.

Same way WP adopted the CMD+P / CMD+K to bring up a command palette. 😉

@draganescu
Copy link
Contributor

Hi! @millertchris I am chiming in to tell you that your input is valuable, correct and to also try to clear up some of the items in @alexstine and @getdave 's comments and I think we're all on the same page here.

I would also look to all other widely adopted UX patterns for renaming things on the web i.e. Chrome Bookmarks, Firefox Bookmarks, Figma, etc, etc.

It is true that the standard rename process of items in trees in OS based software is like you describe it, the problem is inside the browser there are not many examples. And the examples that exist e.g. Figma probably miss the underlying issues we have. Many web based apps have an "accessibility mode" to mitigate this. WordPress doesn't and it aims for offering a similar experience for everyone.

Nevertheless, like Dave said, nothing is set in stone.

I still question how this is a more accessible or a better UX experience.

You are right to question the UX. The accesibility improvement is covered in the process we went through, and should be documented instead of questioned. On the side of UX I don't think anyone sighted and used to the standard process that decades of tree UIs taught is going to say this is the best we can do. On the side of accessibility having the rename in the dot menu, with the modal, makes a lot of sense.

I think the best path is what @richtabor suggested to have both paths. For the rename via double click and enter we need to make sure we are able to overcome the noise and announce what is going on properly, which may be challenging. Fot rename via the dot menu we need to fix the focus management.

IF eventually the ways merge into one and the rename in the dot menu biggest issue is how to land focus back in the tree. It will be announced in a very confusing way. This does not currently have a solution.

the WordPress community is attempting to "reimagine" this particular experience

That is not the case I believe. We're trying to make it as people expect it - but sometimes the road to there is longer.

Also on:

I would argue that massive amounts of engineers, developers, designers, etc over the decades have put a tremoundous amount of thought and consideration into how this work.

... we all agree on this. What Dave explained is for this particular implementation (which is one step, not the end) there was a lot of effort to navigate through different needs of different people, and the history can be found above. We need to build on top of where we're at.

I think we can and should revive the rename with double click/ enter and add that along with the modal behavior.

I'm totally down with helping in anyway possible

You can help with that! 🙇🏻

@alexstine
Copy link
Contributor

@millertchris

double-click is unusable to you but the enter key is not, right? That's how you interact with forms and countless other element when you have focus, correct?

Single Enter press moves focus out of the list view and into the editor canvas to focus the block, can't use that here.

Fair point — but I would also look to all other widely adopted UX patterns for renaming things on the web i.e. Chrome Bookmarks, Firefox Bookmarks, Figma, etc, etc.

  • Google Chrome actually renders a dialog for renaming bookmarks and does not properly maintain focus inside of it. This is actually a bug and not a good example. The dialog has cancel and save buttons and does not rely on Enter alone.
  • Firefox bookmark add/rename also renders in a dialog that implements a roving tab index. This is valid. This dialog also has a cancel and save button and does not rely on Enter.
  • I never interact with Figma because it is a visual tool to start, really can't comment much on it.

I realize these might not be so visible to visual users alone but if you fire up a screen reader, you will find that all these implementations in Google Chrome and Firefox are the exact same way we implemented it for the editor semantically even though it may not appear as a dialog/modal visually.

For the modal, we use a custom React component that handles focus and roving tab index by default.

APH, that's cool. I went to the Kentucky School for the Blind but live in Dallas now. I did have the chance a few years back for a little collaboration.

Thanks.

@millertchris
Copy link

First off — I really appreciate the energy and time you all are putting into this thread alone @alexstine @draganescu @getdave @richtabor and anyone else that's involved!

@alexstine here are my responses:

Single Enter press moves focus out of the list view and into the editor canvas to focus the block, can't use that here.

Right — but that would need to change if we were entertaining what we're discussing.

Google Chrome actually renders a dialog for renaming bookmarks and does not properly maintain focus inside of it. This is actually a bug and not a good example. The dialog has cancel and save buttons and does not rely on Enter alone.
Firefox bookmark add/rename also renders in a dialog that implements a roving tab index. This is valid. This dialog also has a cancel and save button and does not rely on Enter.
I never interact with Figma because it is a visual tool to start, really can't comment much on it.
I realize these might not be so visible to visual users alone but if you fire up a screen reader, you will find that all these implementations in Google Chrome and Firefox are the exact same way we implemented it for the editor semantically even though it may not appear as a dialog/modal visually.

Totally fair and valid points — and their experiences have also changed from the last I remembered them so I'm completely wrong in providing those examples.

OK — so now I see what's happening when really putting all of this to the test.

  • Navigation (up/down keys) - when navigating up and down the list view using the up and down arrows, it's also updating the cursor position within the editor, smart!
  • Enter key - the enter key is not only shifting focus into the editor, but it's creating a return within the editor and creating a new line, I'm not sure how I feel about that but it's totally subjective.
  • Spacebar key - the spacebar key is not only shifting focus into the editor, but it's creating a space within the editor, also not sure how I feel about that but it too is totally subjective.
  • Tab key - the tab key (when focused within the list view) reveals the "Open document settings" button in the lower right hand of the screen if the document settings panel is closed. If it is opened, it places the focus inside of the panel.

That said, here's a proposal:

  • Tab key - when we think about how tab is used throughout all web experiences, it takes you to the "next thing". As a simple example, in a web form, tab will take you to the next field. In the context of the list view in Gutenberg, rather than tab taking you to the next thing — it skips over everything and focusing the user squarely inside of the document settings panel. Instead, we should consider changing this so that pressing the tab key focuses you within block of the layer you have selected.
  • Enter key - instead of having the enter key place focus within the block, the tab key will now do this for us, creating a more intuitive user experience like filling out a web form. This would free up the enter button to now be used to rename a layer within the list view.

This seems like a reasonable compromise which will give sighted users and low vision users what they want, while still providing low and no vision users with the modal option that they want.

This could be a win / win for everyone. 😄

What are your thoughts @alexstine ?

@draganescu here's my responses:

It is true that the standard rename process of items in trees in OS based software is like you describe it, the problem is inside the browser there are not many examples. And the examples that exist e.g. Figma probably miss the underlying issues we have. Many web based apps have an "accessibility mode" to mitigate this. WordPress doesn't and it aims for offering a similar experience for everyone.

Totally agree — and I think we should absolutely steer clear of band-aids like "accessibility mode".

On the side of UX I don't think anyone sighted and used to the standard process that decades of tree UIs taught is going to say this is the best we can do. On the side of accessibility having the rename in the dot menu, with the modal, makes a lot of sense.

I agree and disagree — just as much as sighted users should not be the governing body over what low-vision / no-vision users want/need, the same can be said the sighted or low-vision users. From a screen reader and semantics standpoints, a modal can totally work, and visually, it doesn't have to "appear" as a modal but can work and appear like we are accustomed to when renaming layer.

Here's my biggest issue with the workflow:

Rather than:

  1. Press enter
  2. Rename
  3. Press enter

We will have to:

  1. Click to expand
  2. Move the mouse
  3. Click "rename"
  4. Move the cursor to the input field (or tab)
  5. Rename
  6. Move the cursor to the save button (or tab again)

Adding more steps, objectively, is not good UX for everyone. It's getting in the way of productivity and efficiency.

Good UX should improve the quality of life, for everyone. ❤️‍🔥

I think the best path is what @richtabor suggested to have both paths. For the rename via double click and enter we need to make sure we are able to overcome the noise and announce what is going on properly, which may be challenging. Fot rename via the dot menu we need to fix the focus management.

I'm 100% with you!!! There's not a one-size fits all here — but we're moving in the right direction.

IF eventually the ways merge into one and the rename in the dot menu biggest issue is how to land focus back in the tree. It will be announced in a very confusing way. This does not currently have a solution.

I have not tested the announcements yet, but in my proposed solution above where enter is replaced with tab — you could implement the shift+tab to tab back to the layer you came from, just like we do in forms.

I think we can and should revive the rename with double click/ enter and add that along with the modal behavior.

I'm 100% down with that!

P.S. I was also not able to find keyboard shortcuts anywhere in the "Keyboard shortcuts" modal that tells me how to interact or trigger the ellipses (three dots) within the "List view". @alexstine do you know what shortcut key is used for that?

@briangrider
Copy link

briangrider commented Sep 16, 2023

@millertchris Love your suggestions here. I think relying strictly on the tab key to focus a block's content (and shift tab to move back to the list view) to free up the enter key for rename is the way to go.

1st tab press -> focus the block (and move into editing/writing for paragraph/heading, etc.)
2nd tab press -> focus the block's toolbar group
3rd tab press -> move to the block's appender
4th tab press -> move to the currently open sidebar panel on the right

I realize there would be additional tabs for blocks that have tabbable options as part of their content like the image block, a new group block, etc. but generally speaking, I imagine a 4th tab would take the user to the sidebar.

Workflow for keyboard users would be:

  • navigate blocks with up and down arrows
  • tab into content when ready to edit
  • shift tab back when ready to move to other blocks using the list view
  • after tabbing into content, tab again if the user needs to interact with the toolbar group for the selected block
  • one more tab to add additional blocks with the appender
  • one more tab if they'd like to move into the right side bar
  • shift tab back 4 times to get right back to the list view (when focused on the top focusable item in the sidebar)

This would add quick block renaming with the enter key for keyboard users as well - something that I think would be very intuitive. The right arrow would work as it does now in list view to move to the context menu for the selected block giving the option to rename a block using the context menu as well for users who prefer things to be more explicit.

I would love to see this all done with inline renaming but it would work with a modal based system just as well.

Adding double click to rename would be icing on the cake.

As it is now, Enter feels a bit confusing and unintuitive, especially on a paragraph block. Just experimenting with it for a few minutes, I had to do a double take a few times to understand what was happening (after adding a number of unintended empty paragraph blocks).

@alexstine @draganescu @getdave @richtabor what are your thoughts?

@alexstine
Copy link
Contributor

alexstine commented Sep 17, 2023

Short answer, it isn't going to happen without refactoring the entire editor experience and I'm not sure any of us have the bandwidth for a task this huge any time soon.

The list view itself is a floating sidebar of sorts so I don't like the idea that Tab/Shift+Tab moves focus to the currently selected block and back. The current system with writing flow where Shift+Tab moves to the block toolbar and Tab moves to the sidebar is super hacked together and its something we're looking to replace.

Current items:

  1. There is a PR in progress right now to combine the block and document toolbars that way we have a single toolbar region for the entire editor.
  2. There is a PR in progress to modify the editor canvas iFrame so it is wrapped in a role="application". This is to prevent screen readers from constantly switching modes depending on the type of block users come in contact with.
  3. The idea is to eventually reserve Shift+Tab and Tab keys for navigational keys within blocks or block-specific actions. Examples include:
  • Image block: Tab/Shift+Tab keys should navigate the form controls before a media file is selected.
  • List block: Change the indent level using Tab.

Essentially, the principal is Tab/Shift+Tab will be used to perform text actions in content editable blocks and those shortcuts will be used as navigational keys in non-editable blocks.
4. Most of the serious problems in Gutenberg right now come from trying to guess in React code where focus should land. I want to move away from this pattern and Tab/Shift+Tab should navigate the region that they are in while region navigation keys can move to different areas of the editor.

@millertchris

We will have to:

  1. Click to expand
  2. Move the mouse
  3. Click "rename"
  4. Move the cursor to the input field (or tab)
  5. Rename
  6. Move the cursor to the save button (or tab again)

Yeah, its actually a better experience as a keyboard user and sorry I couldn't see passed my own objections to realize it sooner.

  1. Open list view with Alt+Shift+O.
  2. Find the block with Up/Down Arrow keys.
  3. Press Right Arrow to focus the block options menu and expand it with Enter.
  4. Select Rename.
  5. Type a new name.
  6. Select Save.

I can do this in no time flat as a keyboard power user but it does seem unfairly slow with the mouse.

We are currently working on adjusting the Modal custom component so it will focus the input field after the modal opens, this will save some clicks I hope.

I still want to point out though that this would not be super discoverable. Enter to rename is a Mac OS feature, not a Windows one. So I'm not sure how much time it would save certain people over others, it would likely be highly dependent on which OS they are from. On Windows, the keyboard shortcut is F2 to rename in Windows Explorer. A normal Enter press in Windows Explorer opens an item. Single click would select and double click would open. Even Mac vs. Windows things at OS level are so different.

I value your ideas and not trying to shut them down but we've got bigger fish to fry right now. I know the flow for this feature could probably be improved but I am working really hard to give all users a great editing experience. I'm really busy at the moment trying to fix bigger bugs around how the editor behaves outside of this one sidebar. My eventual goal is to see the list view become the primary means of block navigation because currently there are 2 other ways. Its really been a development nightmare keeping it all working.

My point, you are envisioning functionality super far out of the scope of any one PR and this probably needs to move to a discussion. That way everyone can have their ideas heard, we can all have an open architecture discussion, etc. I'd hate for all of this to eventually be forgotten in a PR that we all forget about later.

Thanks.

@briangrider
Copy link

@alexstine Thank you for your response and expertise. Earlier, @richtabor asked if you would be fine with a double click and you replied that as long as the option remained in the context menu, you're fine with it. Can everyone agree that this is a path forward in satisfying the wants/needs of a large number of users? I'm in a number of advanced user groups and there was some recent scoffing about how many clicks the new rename features take compared to what they deem to be "professional" builders. I explained that a double click option was suggested and executed by @richtabor in 2021 but there's a lot more to getting something into Core. Anyway, I think it would satisfy a lot of power users who are used to a double click rename just being the way things work in other WP page builders, apps, etc.

@getdave
Copy link
Contributor Author

getdave commented Sep 18, 2023

I explained that a double click option was suggested and executed by @richtabor in 2021 but there's a lot more to getting something into Core.

I'd like to clarify that this [Inline approach] was explored in detail recently (i.e. not in 2020) in #53852. Just wanted to avoid any confusion that this wasn't explored recently.

@briangrider
Copy link

briangrider commented Sep 18, 2023

@getdave I loved your approach in #53852. If there is support, I think it is the way to go. If there isn't support right now, or if people feel it's a possibility, but not in the immediate/near future, I think incorporating a double click to open the modal (so not exactly inline) and focus the name input field with this current PR would still enhance usability for mouse users who are looking for a quicker way to rename blocks.

The complete process would be:
-> Double click the block name
-> Modal opens with name input field focused
-> User types name and presses enter

While this UX doesn't exactly mirror what people are used to with other page builders/apps, it is functionally very close

@draganescu
Copy link
Contributor

I like @briangrider 's idea to, for now, add double click as another way to open the rename modal.

@getdave
Copy link
Contributor Author

getdave commented Sep 18, 2023

Adding Double Click would could be relatively trivial. We could explore that 👍

@alexstine
Copy link
Contributor

Yes, if its a quick add, add. 👍

@millertchris
Copy link

Great call outs @briangrider and thanks for all of your insights @alexstine !

I too am onboard with @briangrider here and based on what you mentioned @getdave — and with the support from @alexstine — it sounds like this can be a win/win for everyone!

Thanks for everyone's hardwork on this, looking forward to seeing this in core!

@richtabor
Copy link
Member

Yes, if its a quick add, add. 👍

Agreed.

@mikachan mikachan added the [Package] Block editor /packages/block-editor label Sep 20, 2023
@getdave
Copy link
Contributor Author

getdave commented Sep 21, 2023

Noting that as of #54590 the rename modal will now have focus placed automatically on the input. This should make the flow smoother.

@millertchris
Copy link

Hell yeah!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Needs Design Feedback Needs general design feedback. Needs User Documentation Needs new user documentation [Package] Block editor /packages/block-editor [Type] Feature New feature to highlight in changelogs.
Projects
Status: Done
Development

Successfully merging this pull request may close these issues.