6.4 Dev Note Tracking Issue

[properlypurple]

Tracking all Dev Notes from Gutenberg plugin releases 16.2 - 16.7

Please read the information below carefully. If you have questions, ask in #core-editor on Slack or comment here.

Not all developer-related information needs to be in a separate DevNote on the Make Core blog for the field guide. We can group related information. We can already make decisions on some features if it warrants a stand-alone blog post or if the information will be part of a group post.

Stand-alone post

To streamline the process and eliminate bottlenecks, all writers of stand-alone dev notes will write the dev notes on the Make Core Blog. If you need access to write on the Blog, connect with @hellofromtonya or @abhansnuk via Slack or comment here.

Instructions

Details

• Create your note in a new post, - Save as Draft - Enable public preview - Share the link to the public preview in a comment below, as "ready for review" - "For dev notes, each one must have at least two reviewers" (Handbook)

Part of a group post

If the information related to your PR will be part of a group post, please write the dev note in a comment on the PR, so it can be reviewed and, if necessary commented on, by the release docs team or a reviewer.

Before you start writing 📣 please read the handbook pages:

Details

• ⭐️ Writing developer notes
• ⭐️ Style & Substance section of the Post & Comment Guidelines for Make Blog
• ⭐️ Documentation Style Guide - Good for reference, when in doubt, especially when English is not your native language.

The list is incomplete. We are in the process of reviewing plugin release changelogs and add them as we progress on the task.

There are two labels:
needs dev note and has dev note

If you worked on a feature/module/component that definitely needs a dev note, please assign the label needs dev note If you already added the Dev Note to the make blog on draft or as a comment on the PR, please label it has dev note

---

Standalone dev notes:

Block hooks

• Experiment: Auto-inserting blocks on the frontend and in the editor (via REST API) #51449 @ockham
• Block API: Stabilize Block Hooks feature #54293 @gziolo

Miscellaneous dev notes: (these are the ones which already have the neds-dev-note tag, grouped by release)

• RichText: replace deprecated multiline prop with simple multiple instances #54310 @ellatrix

• Theme Previews: Make the back button customizable #54242 @scruffian

• Add edits data to the useEntityRecord #54167 @matiasbenedetto

• Indicate nested paths on __experimentalSaveSpecifiedEntityEdits #54161 @matiasbenedetto

---

• Always render the fallback Popover anchor within the Popover's parent element #53982 @ciampo

---

• Fonts Library: Backend #52704 @matiasbenedetto
• Make useBlockEditingMode() public #52094 @ramonjd

---

• Add new registerInserterMediaCategory API to make media categories extensible #51542 @ntsekouras

[ellatrix]

• RichText: replace deprecated multiline prop with simple multiple instances #54310

Doesn't make sense as a standalone dev note, would be good to add to miscellaneous.

RichText's multiline prop has been deprecated since 6.1 and was scheduled for removal in 6.3. We're leaving the deprecated prop in place, but its functionality has been simplified internally, so you may experience changes. Instead of one large rich text field, each line is now its own rich text field. We added splitting and merging functionality so the fallback is gracious, but some things like paste may work differently. It's worth noting that this prop remains deprecated and all block authors are encourage to use InnerBlocks instead.

[gziolo]

• Block API: Stabilize Block Hooks feature #54293
• Experiment: Auto-inserting blocks on the frontend and in the editor (via REST API) #51449

It's a single feature now called Block Hooks, and @ndiego is helping with the dev note.

[abhansnuk]

Thanks for the efforts that have gone into this and the ongoing review of tickets. In the docs release team and with the cohort, we have been helping newer contributors get involved and had been working through a similar ticket review. Thanks to @bph for sharing that this ticket review is also being done in core-editor, so to avoid duplicating with two lists, we will lose the one we had been working on, and focus effort on this tracker.

Just a signpost to the handbook information, please do not make any dev notes live until seen by the docs release co-leads so that we can keep an overview of where we are and to avoid too many dev notes being published together which can be difficult for those receiving the RSS feed. We also want to build on the efforts from 6.0 onwards to make sure dev notes have useful excerpts and intro paragraphs for search results to help users/ devs know if a note is what they are looking for.

Thanks again to everyone contributing to this. I am @abhanonstopnewsuk on Slack if you need dev note access.

[ntsekouras]

Draft dev note in make core for Add new registerInserterMediaCategory API to make media categories extensible PR is here.

[abhansnuk]

Thanks Nik. I will have a look.

…

________________________________ From: Nik Tsekouras ***@***.***> Sent: 04 October 2023 08:25 To: WordPress/gutenberg ***@***.***> Cc: Abhanonstopnewsuk ***@***.***>; Mention ***@***.***> Subject: Re: [WordPress/gutenberg] 6.4 Dev Note Tracking Issue (Issue #54998) Draft dev note in make core for Add new registerInserterMediaCategory API to make media categories extensible PR<#51542> is here<https://make.wordpress.org/core/?p=108427&preview=1&_ppp=88ba8ff4e5>. — Reply to this email directly, view it on GitHub<#54998 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AH6IIEDAXFF42MV2E34RPELX5UMPXAVCNFSM6AAAAAA5QS3PA2VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTONBWGM4DEMRSGQ>. You are receiving this because you were mentioned.Message ID: ***@***.***>

[properlypurple]

If you've been pinged in here, please take a look at the PRs below, and comment if the PR needs a dev note.

• Remove block tools back compat component schedule for deprecated in 6.3 #53115 @getdave
• Export store for the core/customize-widgets package. #52189 @ryanwelcher
• Export the store for the core/edit-widgets pacakage #52190 @ryanwelcher
• Bump plugin minimum supported PHP version to 7.0 #52982 @hellofromtonya
• TabPanel: implement Ariakit internally #52133 @chad1008
• [create-block] Refinements to the create-block-interactive-template package. #52801 @ryanwelcher
• Components: Introduce a basic ProgressBar component #53030 @tyxla
• Font Library: Font Collections frontend #54566 @matiasbenedetto
• Stabilize defaultBlock, directInsert API's and getDirectInsertBlock selector #52083 @sethrubenstein
• Block Editor: Add support for arrays to setImmutably util #52280 @tyxla
• Add runtime support for the wp-style directive #52645 @luisherranz
• Add filter to turn off Interactivity API for a block #52579 @westonruter
• Add support for registering commands without icons #53647 @richtabor
• Allow passing optional afterLoad callbacks to store calls #53363 @DAreRodz
• Warning: Introduce SCRIPT_DEBUG to make the package compatible with webpack 5 #50122 @gziolo
• Interactivity API: router with region-based client-side navigation #53733 @luisherranz
• Interactivity API: add Slot and Fill directives #53958 @DAreRodz
• Make useBlockEditingMode() public #52094 @noisysocks
• Fluid typography: add min and max viewport width configurable options #53081 @ramonjd
• Allow layout controls to be disabled per block from theme.json #53378 @tellthemachines
• Modal: add headerActions prop to render buttons in the header #53328 @ciampo

[abhansnuk]

I am creating Dev Note tracking issues for the items listed above. I will add them to this list. This allows to have an overview of all the Dev Notes in one place.

Standalone dev notes
UPDATE ON BELOW combined these two to be one on the documentation tracker given the note above from @gziolo that these have been combined to be 'Block Hooks'.
WordPress/Documentation-Issue-Tracker#1144

• Dev Note tracking: Experiment: Auto-inserting blocks on the frontend and in the editor (via REST API) Experiment: Auto-inserting blocks on the frontend and in the editor (via REST API) #51449
• Experiment: Auto-inserting blocks on the frontend and in the editor (via REST API) Experiment: Auto-inserting blocks on the frontend and in the editor (via REST API) #51449

Please can you update this with items relating to the Dev Note. If a google doc has not already been started for this, please let me know and I will create it in the docs area we are using for 6.4 and share it with you.

If you have already started the Dev Note in the CMS, please add the public preview link to the ticket.

Miscellaneous Editor Dev Notes for 6.4
This has been set up reading for those writing dev notes in the Make/Core CMS. Please can you add any links and updates to the Docs tracking issue 1146

Thanks so much.

[luisherranz]

The Interactivity API is still private in WP 6.4 and only used internally for Core blocks, so there's nothing to inform yet. I've checked all the related items:

• Add runtime support for the wp-style directive #52645
• Add filter to turn off Interactivity API for a block #52579
• Allow passing optional afterLoad callbacks to store calls #53363
• Interactivity API: router with region-based client-side navigation #53733
• Interactivity API: add Slot and Fill directives #53958

[matiasbenedetto]

Font Library was punted to 6.5, and for that reason not included in 6.4, so a dev note is not required.

• Font Library: Font Collections frontend #54566
• Fonts Library: Backend #52704

[sethrubenstein]

@properlypurple Yes, but probably just updating the existing InnerBlocks tutorial doc to include these stabilized apis? When would you need those updates by?

[bph]

After a conversation with @abhansnuk last night, we agreed that I will centralize the Dev Notes wrangling here.
After I get up to speed, I will coordinate what will be as single post (ie Block Hooks) what will go into a Miscellaneous Editor Changes post and what will just get a mention in the Fieldguide with the Gutenberg contributors.

[bph]

Hi @sethrubenstein Thank you!

Tt would help to alert people that something has changed even if it's just a one paragraph, update to the docs would also be quite appreciated. The deadline for the blurb is Monday, so we get it into the FieldGuide on Tuesday. For the docs updated, it should happen between now and and Nov 7 (release date for 6.4)

[gziolo]

• Warning: Introduce SCRIPT_DEBUG to make the package compatible with webpack 5 #50122

I'm not sure whether it requires a dev note. From the WordPress core, it's mostly an internal optimization to send less code to the browser. It could be useful for folks using @wordpress/scripts to inform them they can put some debug code behind:

if ( typeof SCRIPT_DEBUG !== 'undefined' && SCRIPT_DEBUG === true ) {
    // This code runs only in the development mode and gets completely removed from the production build.
}

However, it's something that we could as well put into the README for @wordpress/scripts in the advanced section.

[andrewhayward]

• Adding support for defined IDs in TextControl component #52028

This was a minor fix to bring a component in line with some others. No dev note needed.

[matiasbenedetto]

My contribution to the miscellaneous dev notes:

---

Add edits data to the useEntityRecord

• Add edits data to the useEntityRecord #54167

Now, the useEntityRecord adds to its output a key called edits containing the nonTransientEdits of an entity record. A code example:

const widget = useEntityRecord( 'root', 'widget', 1 );
widget.edit( { hello: 'foo' } );

Expected result:

{
    edits:  { hello: 'foo' }
    ...
}

---

Indicate nested paths on __experimentalSaveSpecifiedEntityEdits

• Indicate nested paths on __experimentalSaveSpecifiedEntityEdits #54161

Previously, one could only indicate which top-level properties one wanted to save using __experimentalSaveSpecifiedEntityEdits. So we were limited to doing something like this:

__experimentalSaveSpecifiedEntityEdits( 'root', 'globalStyles', globalStylesId, [ 'settings' ] );

The latest changes enable developers to indicate which nested paths want to be saved into the database. For example, if one made some client-side changes to the fontFamilies array of the global styles settings ( settings.typography.fontFamilies ) and wants to save to the database only those changes instead of all the changes that the settings objects may have.

__experimentalSaveSpecifiedEntityEdits( 'root', 'globalStyles', globalStylesId, [ 'settings.typography.fontFamilies' ] );

---

Thanks, @bph and @properlypurple for the ping and for running this.

[ciampo]

@youknowriad I'll write the dev note for #53982

[scruffian]

#54242 @scruffian

Site Editor: Make the back to dashboard link text customizable

It has been possible to customize the "Back to Dashboard" link in the Site Editor since 6.2, but not the link text. Now it is possible to also customize the text of the link, by providing a __experimentalDashboardLinkText setting:

function gutenberg_custom_back_to_dashboard_link( $settings ) {
	$settings['__experimentalDashboardLink']     = '/* Put your custom link here */';
	$settings['__experimentalDashboardLinkText'] = /* Put your custom link text here */;
	return $settings;
}

add_filter( 'block_editor_settings_all', 'gutenberg_custom_back_to_dashboard_link' );

This gives extenders the ability to ensure that link labels are updated when they change this back button, which is important for accessibility.

[ryanwelcher]

Dev Note for

• Export store for the core/customize-widgets package. #52189
• Export the store for the core/edit-widgets pacakage #52190

Developer Experience: Exporting stores for the core/customize-widgets and core/edit-widgets packages

Most code examples import the store directly from the package and it is now possible from these packages as well.

[ramonjd]

#53081 @ramonjd

Dev note here:

• Fluid typography: add min and max viewport width configurable options #53081 (comment)

[ramonjd]

#52094 @ramonjd

Dev note here:

• Make useBlockEditingMode() public #52094 (comment)

[tellthemachines]

Thanks for the ping @properlypurple!

Dev note for disabling layout controls from theme.json is here.

[tyxla]

Thanks for wrangling the dev notes, @properlypurple 🙌

#53030 @tyxla

✍️ I've added a dev note at the bottom of the PR description: #53030

#52280 @tyxla

🚫 This was an enhancement to an internal API that is not public-facing, so a dev note is not needed.

[bph]

The state of Gutenberg Dev Notes

We will have four post about developer relevant Gutenberg changes in 6.4 on Make Blog:

Two of them are in review
Two are WIP

• Editor Components updates in WordPress 6.4 (public preview)

  • Thank you to @brookewp , @tyxla @chad1008 and @ciampo

• Introducing Block Hooks dev note by @ndiego is in the works.

• New registerInserterMediaCategory API (public preview) by @ntsekouras

• Miscellaneous Editor changes in WordPress 6.4 (public preview) assembled by me (WIP)

  • Thank you to @ellatrix @scruffian @gziolo @matiasbenedetto @tyxla @ramonjd @ryanwelcher

cc: @hector @anne @richtabor @Mamaduka are there things missing?

Huge thank you to @properlypurple for surfacing all PRs possibly needing Dev Notes.

[abhansnuk]

Thank you @bph and @properlypurple , and everyone working on these dev notes.

I think Birgit is already doing a first review, so I will add second review comments below.

1. Editor Components updates in WordPress 6.4 (public preview)
   Really useful note.
   Only 2nd review comments are below:

• In the section 'Introducing a new experimental...', semi-colons could be added at the end of the bullet points to keep in the style used elsewhere in the post for bullet points
• At the end of that section 'More information are' to change to 'More information is'
• 'New props for modal component' - "Note that it is the responsibility of the consumer". What is meant by the description 'consumer', is it the developer or extender?
• excerpt for search results and to give a concise text when people link to it
• once the item has had both reviews, reviewers IDs to be added to the end of the props list

General comments about this and other dev notes
a) Links to GitHub
For links out for more information, we have had discussions before about whether dev notes should make clear the link is going outside the blog, eg in this case to GitHub, for accessibility reasons. I can't find the answer in a search of slack but @bph may recall. I thought the decision was to try and say visit GitHub then ticket number.

b) Categories
From my notes, in 6.0 and 6.1 I think there was a discussion if 'dev notes' should also tick the 'updates' category in addition to 'general' as they are about something new. @bph what do you think?

[sethrubenstein]

@bph Updated InnerBlocks doc #55375

[andrewserong]

@bph apologies, it looks like I missed that Block Supports: Add background image support to Group block (#53934) also could use a dev note for 6.4. As with other block supports for previous releases, I think this could be added to your Miscellaneous Editor changes in WordPress 6.4 post, as it's just a short one to make sure folks know how to opt-in for their themes.

I've drafted a short dev note to be added to that post over in this comment: #53934 (comment)

[bph]

Thank you @andrewserong

Note that as of WP 6.4, the backgroundImage support is only available at the individual block level, and not in global styles or at the site root.

That bears the question: Are there plans in place to broaden the support?

[bph]

@sethrubenstein @andrewserong both items made it into the Misc Editor changes dev note.

[bph]

@abhansnuk I am not aware of the discussions regarding additional annotating source for the link or the Updates category. For 6.1 and 6.2 I didn't implement either

[nalininsbs]

Suggest we take the question on the link @abhansnuk to accessibility. This can be implemented later if needed. In terms of Updates category, is there a definition or description of what category to use in the handbook?

[andrewserong]

That bears the question: Are there plans in place to broaden the support?

Yes! I touched on it earlier in the dev note in the sentence "Ideas for enhancements in future releases are being tracked in this Github issue: #54336", but we could add another similar sentence at the end there to make sure it's clear. How about:

Note that as of WP 6.4, the backgroundImage support is only available at the individual block level, and not in global styles or at the site root. These features will be explored in subsequent releases, with progress tracked in this Github issue: #54336.

[bph]

Field Guide published: WordPress 6.4 Field Guide