-
Notifications
You must be signed in to change notification settings - Fork 4.2k
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
Dev Notes Tracking Issue for WordPress 6.0 #39654
Comments
Here's a data module related dev note, if there are more data module dev notes, they could potentially be grouped together in a post. Data ModuleSupport for Handling Resolution ErrorsWordPress 6.0 no longer ignores the exceptions thrown by the resolvers. In WordPress 5.9 and earlier, an exception thrown inside the resolver kept it in the Example: // Let's register an example store where the resolver always throws an error:
const temperatureStore = wp.data.createReduxStore( 'my-store', {
selectors: {
getTemperature: ( state ) => state.temperature
},
resolvers: {
getTemperature: () => { throw new Error( 'Network error' ); }
},
reducer: () => ({}), // Bogus reducer for the example
} );
wp.data.registerStore( temperatureStore );
// Using that resolver has different results in different WordPress versions:
// In WordPress 5.9:
const promise = wp.data.resolveSelect( temperatureStore ).getTemperature();
// Error handling is unsupported, so this promise never gets rejected nor resolved.
// In WordPress 6.0:
const promise = wp.data.resolveSelect( temperatureStore ).getTemperature();
// Error handling is now supported, so this promise gets rejected with Error( 'Network error' ) The error details may be retrieved using the wp.data.select( temperatureStore ).hasResolutionFailed( 'getTemperature' );
// the above returns: true
wp.data.select( temperatureStore ).getResolutionError( 'getTemperature' );
// the above returns: Error( 'Network error' )
wp.data.select( temperatureStore ).getResolutionState( 'getTemperature' );
// the above returns: { "state": "error", "error": Error( 'Network error' ) } The |
Theme ExportThe "Export" feature in the Site Editor has been improved so that now you can export your whole theme, including all the edits you have made to your templates and styles. Previously the export function only gave you access to your template files. This change makes it possible to build a block theme using the site editor and easily share the zip file with anyone. The Export processThe export process copies all files from the current theme into a zip file. Then it extracts the template changes that are stored in the database to files and adds them to the zip file. If these template have the same names as those in the theme, they will be overwritten, so that the database version take precedence. The same process happens for the theme.json file. There are three directories that are excluded from the export: .git, node_modules and vendor. Unexpected changesThe export process may make a few unexpected changes to your templates and theme.json files.
How to submit a themeOnce you have your exported theme, you may need to make several changes before you can submit it to the theme repository.
We're looking forward to seeing more block theme submissions! |
Gallery blockAbility to adjust gap between images addedIn order to implement this the spacing of the Gallery images had to be changed from a right margin setting to the CSS Default gap changedThe new block editor block gap support functionality has been used to implement this and this adds a default block gap of .wp-block-gallery {
--wp--style--gallery-gap-default: 16px;
} Gallery Image bottom margins removedSome themes may have depended on the bottom margin set on the gallery images to provide a gap between two galleries. Because the gallery now uses the flex .wp-block-gallery {
margin-top: 16px;
} Gallery gutter CSS var deprecatedTo keep the naming of the Theme authors should be able to provide compatibility for WP 5.9 and 6.0+ with the following: .wp-block-gallery {
--gallery-block--gutter-size: var( --wp--custom--spacing--4 );
--wp--style--gallery-gap-default: var( --wp--custom--spacing--4 );
} |
Separator blockUpdated to use block supports color settingsIn order to allow the setting of a custom opacity for each block the Separator block has been updated to use the block supports color settings. The custom opacity can then be set using the alpha channel setting of the selected color. separator-opacity.mp4The HMTL structure of the block is unchanged, and all of the existing classes are still in place, but two additional classes have been added - If theme authors have opted in to block styles with hr.wp-block-separator.has-alpha-channel-opacity {
opacity: 0.4;
} |
Unrecognized block preservationWe've started making strides in preserving unrecognized content in the editor, also called (sometimes incorrectly) "invalid" or "missing." In situations where the editor is unable to validate a loaded block against its implementation we run into a number of cases where content has previously been lost or corrupted, notably when inner blocks are involved. Right now we're on the journey to preserving that original unrecognized content but have a lot of corners in the project to update before it's finished. Notably when loading posts in the editor or in the code view that content will be preserved as it was loaded. Surprisingly this lets us do something we've never been able to do before: intentionally create certain kinds of broken blocks within the code editor, or modify and fix blocks in the code editor whose block implementation is missing. Still on the list to update are smaller parts of the flow such as the array of confusing block resolution dialogs and operations as well as certain validation steps that currently fail but shouldn't. In short, if you've been frustrated by the editor breaking your posts as soon as you hit "save" then good news is coming in 6.0. |
A new /patterns directory for themesWordPress 6.0 makes it easier for themes to define their own block patterns. Themes can now define block patterns as files in the Each pattern file consists of a set of plugin-style headers followed by the pattern's actual source: <?php
/**
* Title: Hello
* Slug: my-theme/hello
* Categories: featured, text
*/
<main><p>Hello, world!</p></main> MotivationWhile all themes benefit from this API, it is especially convenient for block themes, where conventional folders like Note that this is not a breaking change. Much like plugins, themes have been able to register block patterns since the introduction of Observations
<img src="<?php echo esc_url( get_template_directory_uri() ); ?>/assets/hello.png">
Supported fields
|
#36176 won't be included in the WP 6.0 release. |
Dev note for Allow pattern registration from directory with theme.json #38323 Pattern registration from Pattern Directory for themesWith WordPress 6.0 themes can easily register patterns from Pattern Directory through Within this field, themes can list patterns to register from Pattern Directory. The patterns field is an array of
Noting that this field requires using the version 2 of |
Dev note for #37160 I'm not sure if this warrants a Dev Note, so please feel free to cut it entirely if it doesn't meet the noteworthiness threshold! Removed bottom margin on
|
This PR has been part of 5.9, and the corresponding devnote has been published at https://make.wordpress.org/core/2022/01/08/updates-for-settings-styles-and-theme-json/ Does that devnote need any further clarification, perhaps? |
This is just a bugfix/code quality thing that doesn't introduce or modify any behavior. I've just marked it as done. |
Block markup updatesImage block alignmentsHistorically, the image block with left, right or center alignments used to have an extra div wrapper around the figure tag to help with alignment styling.
In WordPress 6.0, for themes that support the layout feature, this wrapper has been removed. The markup becomes:
The new markup/behavior for alignment classes is consistent regardless of the block and regardless of the chosen alignment. To minimize the impact of this change on the websites, this change is only effective for themes with a theme.json file. These themes do support the "layout" feature which automatically provides the right styles for this new markup. Quotes and listsThe blockquote, ul and ol tag names all now come with a default value for `box-sizing` equal to `border-box`. This change has been made as a bug fix for quote and list blocks using background colors or padding. Group block stack variationThe new Stack block is a variation of the Group block, and can be thought of as a vertical variant of the Row block. It's a flex container, meaning it has access to content justifications and block spacing. If combined with the Row block and its ability to optionally wrap onto new lines, it can enable basic responsive behaviors, such as two columns that stack to a single column on smaller displays. Removal of data-align div wrappersIn the editor and in order to support/style block alignments, the editor used to add wrapper divs to any block that had an alignment applied to it. For themes that support the layout feature (with theme.json file), the div wrapper with the `data-align` attribute has been removed. The markup now matches exactly the frontend output. -- This dev note can probably be merged with some of @glendaviesnz's notes above related to block markup. |
Global Styles variationsTheme authors can now create multiple theme.json variations and place them into their theme’s Custom JSON files should follow the standard theme.json schema and their filename is going to be used as the variation's label in the UI(example Webfonts handlerA webfonts handler has been included in this release, allowing theme authors to include multiple font options within a single theme.json file or to offer vastly different styles by utilizing different font options in their multiple theme.json variations.
Here's a more robust example of how to implement this new option:
Right now, there is only support for top level settings and the more granular option of defining fonts per block is not currently available. For further inspiration, theme authors can review the approach the default Twenty Twenty-Two theme has taken since it will ship with three style variations with different fonts for WordPress 6.0. Notes
global.styles.variations.mov |
This is a super minor change so it might not even be worth including IMHO. If you want to however, here's a quick explaination. The List View shows a list of each block in the editor canvas by name. It's now easier to target the block's name via CSS thanks to the addition of a wrapping element. |
Comments blocksEnable legacy Post Comments blockWith WordPress 6.0, there is a new set of blocks to show the Comments of a post:
The legacy Post Comments block, which directly renders the comments.php file, has been deprecated and hidden. It will still work for themes currently using it, but it won’t appear in the inserter. The new set of blocks provides almost the same functionalities with the benefit that the layout and styles can be customized from the Editor. However, if any user wants to re-enable the Post Comments legacy block, they can use the block registration filters and adapt it to their needs. For example, this piece of code shows the legacy block in the inserter again and removes the “deprecated” from the title: function enable_post_comments_legacy_block( $metadata ) {
if ( 'core/post-comments' === $metadata['name'] ) {
$metadata['title'] = 'Post Comments';
$metadata['supports']['inserter'] = true;
}
return $metadata;
}
add_filter( 'block_type_metadata', 'enable_post_comments_legacy_block' ); |
New
|
Allowing the registration of Blocks from within ThemesUp until WordPress 6.0 building blocks inside plugins was the only way possible if you wanted to use Even with that best practice in place, there are however instances where the styling of a block is so tightly coupled with a theme that it doesn't make sense to have a block active without a given theme. This comes especially true when building very purpose build custom solutions. In these cases, you had to resort to hacky approaches to get the registration of blocks within themes to work. This is now no longer necessary. With 6.0 the registration of blocks using |
Adding 🎉 to published ones |
Adding the dev note for page creation patterns #40034. Page creation patternsWhen a user creates a page, the editor starts with an empty canvas. However, that experience may not be ideal, especially since there are often possible patterns the user can use when creating a page, e.g., an about page, a contact page, a team page, etc. Starting with WordPress 6.0, offering a set of patterns that users can choose from to create their pages is possible. The modal appears each time the user creates a new page when there are patterns on their website that declare support for the Any theme or plugin can register a pattern with
Completely disabling this functionalityBy default, no modal appears because there are no post-content patterns unless a theme or plugin registers one.
|
For transparency, noting that I directly edited two dev notes above:
For the comments block note @SantosGuillamot , I'd highly recommend listing out all of the blocks going into the release rather than linking off to a GitHub issue. Might be easiest to just pull from this call for testing: https://make.wordpress.org/test/2022/04/08/help-test-the-comments-blocks-for-wordpress-6-0/ |
Thanks for the feedback, it totally makes sense 🙂 I have just updated the comment. Moreover, if I am not mistaken, the new Comments should be explained later in detail in a user-facing release note (not a dev note). |
All dev notes from here are published or will be soon. Thank you to everyone who participated in making them, you are heros ❤️ |
Thank you so much for shouldering the crunch time effort getting everything together! You are my hero @zzap 👏🎉🦸♀️ |
Sorry for the delay on this @bph @zzap - this covers #38535, #39723, and #38530 Updates to the @wordpress/create-block templating systemA powerful feature of the @wordpress/create-block package is the ability to create templates to allow customization of how a block is structured. WordPress 6.0 introduces some new template variables to allow even more customization. Templates can now use the |
This general dev note for Block Locking. The other items in Lock Settings list don't need a dev note. Block Locking SettingsWordPress 6.0 makes it easier to lock blocks using the new controls modal. The release also includes two new settings to choose who can access this option and when. Block EditorThe new add_filter(
'block_editor_settings_all',
function( $settings, $context ) {
// Allow for the Editor role and above - https://wordpress.org/support/article/roles-and-capabilities/.
$settings['canLockBlocks'] = current_user_can( 'delete_others_posts' );
// Only enable for specific user(s).
$user = wp_get_current_user();
if ( in_array( $user->user_email, [ '[email protected]' ], true ) ) {
$settings['canLockBlocks'] = false;
}
// Disable for posts/pages.
if ( $context->post && $context->post->post_type === 'page' ) {
$settings['canLockBlocks'] = false;
}
return $settings;
},
10,
2
); BlocksThe {
"apiVersion": 2,
"supports": {
"lock": false
}
} |
Thank you @ryanwelcher and @Mamaduka , dev notes are published and Field guide updated. |
There is only on open item in this tracking issue: It's not necessarily a Devnote for 6.0 but while we have the attention of plugin authors, it might be good to add a note to the Misc Dev Notes section about depricated APIs for this PR as well. #37854 - See my comment |
All published. |
Description
For WordPress 6.0, a GitHub project is being used to track dev notes and their progress. You can find the dev notes project view here - https://github.com/orgs/WordPress/projects/28/views/1
Please share your notes here as comments or a link to a shared Google document. The WordPress 6.0 Documentation team (@zzap, @abhansnuk @aurooba and I, @bph) will be happy to assist in wording and scope.
If your note is ready to be posted on Make Blog and you have privileges, then go ahead and post it in draft, we can wrangle the reviews.
The dev notes should start latest with Beta 1, but you can certainly start now.
Deadline is before WP 6.0 RC (May 2nd, 2022) - You don't have to wait for the last minute to get it done, thought. 😘
⭐️ Handbook Page: Writing developer notes
Please leave a comment, also if you're unable to write a note for your PR or if you need assistance.
I'll start connecting with PR authors 1:1 to double-check availability, and see if I can unblock things.
👍 (saw it and Thank You! ) 🚀 (in review)
ancestor
prop to schema #39894 @DAreRodzisValidBlockContent
#38794 @dmsnellcustomScripts
property to allow templates to define additional scripts in package.json #38535 @ryanwelcherNumberControl
on Style options. #37160 @mirka/patterns
directory #36751 @mcsf<ListView>
in a span #39687 @getdave (could go into Miscellaneous "Little Gems" post )Theme Export
Lock Settings
** Updates 4/29/2022**
#39950 didn't not in WP6.0
#38780 experimental API (no documentation)
#38397 -> Field Guide: But Wait section.
#36811 (already in 5.9)
#38663 @oandregal (bug fix only)
Updates 4/14/2022
## WebFonts API - probably won't make it into 6.0 as it wasn't merge by Beta 1 (Feature Freeze) (discussion in release leads channel)
#36176 @gziolo @aristath - won't be in 6.0 (comment)
The text was updated successfully, but these errors were encountered: