Skip to content

Commit

Permalink
prep build 02/06
Browse files Browse the repository at this point in the history
  • Loading branch information
bph committed Feb 6, 2024
2 parents 73839c5 + 8d94c3b commit ba4feb7
Show file tree
Hide file tree
Showing 96 changed files with 2,496 additions and 1,489 deletions.
5 changes: 0 additions & 5 deletions .eslintrc.js
Original file line number Diff line number Diff line change
Expand Up @@ -46,11 +46,6 @@ const restrictedImports = [
name: 'lodash',
message: 'Please use native functionality instead.',
},
{
name: 'reakit',
message:
'Please use Reakit API through `@wordpress/components` instead.',
},
{
name: '@ariakit/react',
message:
Expand Down
38 changes: 38 additions & 0 deletions changelog.txt
Original file line number Diff line number Diff line change
@@ -1,5 +1,43 @@
== Changelog ==

= 17.6.2 =


## Changelog

### Bug Fixes

#### Block Editor
- Writing flow: Maintain correct selection after drag-selecting outside block. ([58684](https://github.com/WordPress/gutenberg/pull/58684))
- useOnBlockDrop: Fix TypeError via array coercion. ([58686](https://github.com/WordPress/gutenberg/pull/58686))




## Contributors

The following contributors merged PRs in this release:

@ellatrix @mcsf


= 17.6.1 =


## Changelog

### Font Library

- Make the API compatible with the upcoming Core patch. ([58671](https://github.com/WordPress/gutenberg/pull/58671))


## Contributors

The following contributors merged PRs in this release:

@youknowriad


= 17.6.0 =

## Changelog
Expand Down
59 changes: 28 additions & 31 deletions docs/README.md

Large diffs are not rendered by default.

38 changes: 20 additions & 18 deletions docs/explanations/architecture/entities.md
Original file line number Diff line number Diff line change
@@ -1,11 +1,12 @@
# Entities and Undo/Redo.
# Entities and Undo/Redo

The WordPress editors, whether it's the post or site editor, manipulate what we call entity records. These are objects that represent a post, a page, a user, a term, a template, etc. They are the data that is stored in the database and that is manipulated by the editor. Each editor can fetch, edit and save multiple entity records at the same time.
The WordPress editors, whether it's the Post or Site Editor, manipulate what we call entity records. These are objects that represent a post, a page, a user, a term, a template, etc. They are the data that is stored in the database, and that is manipulated by the editor. Each editor can fetch, edit, and save multiple entity records at the same time.

For instance, when opening a page in the site editor:
- you can edit properties of the page itself (title, content...)
- you can edit properties of the template of the page (content of the template, design...)
- you can edit properties of template parts (header, footer) used with the template.
For instance, when opening a page in the Site Editor:

- You can edit properties of the page itself (title, content, etc.)
- You can edit properties of the template of the page (content of the template, design, etc.)
- You can edit properties of template parts (header, footer) used with the template.

The editor keeps track of all these modifications and orchestrates the saving of all these modified records. This happens within the `@wordpress/core-data` package.

Expand All @@ -18,13 +19,14 @@ To be able to edit an entity, you need to first fetch it and load it into the `c
wp.data.select( 'core' ).getEntityRecord( 'postType', 'post', 1 );
````

Once the entity is loaded, you can edit it. For example, the following code sets the title of the post to "Hello World". For each fetched entity record, the `core-data` store keeps track of:
- the "persisted" record: The last state of the record as it was fetched from the backend.
- A list of "edits": Unsaved local modifications for one or several properties of the record.
Once the entity is loaded, you can edit it. For example, the following code sets the title of the post to "Hello World". For each fetched entity record, the `core-data` store keeps track of the following:

- **The "persisted" record:** The last state of the record as it was fetched from the backend.
- **A list of "edits":** Unsaved local modifications for one or several properties of the record.

The package also exposes a set of actions to manipulate the fetched entity records.

To edit an entity record, you can call `editEntityRecord`, which takes the entity type, the entity ID and the new entity record as parameters. The following example sets the title of the post with ID 1 to "Hello World".
To edit an entity record, you can call `editEntityRecord`, which takes the entity type, the entity ID, and the new entity record as parameters. The following example sets the title of the post with ID 1 to "Hello World".

````js
wp.data.dispatch( 'core' ).editEntityRecord( 'postType', 'post', 1, { title: 'Hello World' } );
Expand All @@ -42,27 +44,27 @@ Since the WordPress editors allow multiple entity records to be edited at the sa

And to be able to perform both undo and redo operations properly, each modification in the list of edits contains the following information:

- Entity kind and name: Each entity in core-data is identified by the pair _(kind, name)_. This corresponds to the identifier of the modified entity.
- Entity Record ID: The ID of the modified record.
- Property: The name of the modified property.
- From: The previous value of the property (needed to apply the undo operation).
- To: The new value of the property (needed to apply the redo operation).
- **Entity kind and name:** Each entity in core-data is identified by the pair _(kind, name)_. This corresponds to the identifier of the modified entity.
- **Entity Record ID:** The ID of the modified record.
- **Property:** The name of the modified property.
- **From:** The previous value of the property (needed to apply the undo operation).
- **To:** The new value of the property (needed to apply the redo operation).

For example, let's say a user edits the title of a post, followed by a modification to the post slug, and then a modification of the title of a reusable block used with the post. The following information is stored in the undo/redo stack:

- `[ { kind: 'postType', name: 'post', id: 1, property: 'title', from: '', to: 'Hello World' } ]`
- `[ { kind: 'postType', name: 'post', id: 1, property: 'slug', from: 'Previous slug', to: 'This is the slug of the hello world post' } ]`
- `[ { kind: 'postType', name: 'wp_block', id: 2, property: 'title', from: 'Reusable Block', to: 'Awesome Reusable Block' } ]`

The store also keep tracks of a "pointer" to the current "undo/redo" step. By default, the pointer always points to the last item in the stack. This pointer is updated when the user performs an undo or redo operation.
The store also keeps track of a "pointer" to the current "undo/redo" step. By default, the pointer always points to the last item in the stack. This pointer is updated when the user performs an undo or redo operation.

### Cached changes

The undo/redo core behavior also supports what we call "cached modifications". These are modifications that are not stored in the undo/redo stack right away. For instance, when a user starts typing in a text field, the value of the field is modified in the store, but this modification is not stored in the undo/redo stack until after the user moves to the next word or after a few milliseconds. This is done to avoid creating a new undo/redo step for each character typed by the user.

Cached changes are kept outside the undo/redo stack in what is called a "cache" of modifications and these modifications are only stored in the undo/redo stack when we explicitely call `__unstableCreateUndoLevel` or when the next modification is not a cached one.
Cached changes are kept outside the undo/redo stack in what is called a "cache" of modifications, and these modifications are only stored in the undo/redo stack when we explicitly call `__unstableCreateUndoLevel` or when the next modification is not a cached one.

By default all calls to `editEntityRecord` are considered "non-cached" unless the `isCached` option is passed as true. Example:
By default, all calls to `editEntityRecord` are considered "non-cached" unless the `isCached` option is passed as true. Example:

```js
wp.data.dispatch( 'core' ).editEntityRecord( 'postType', 'post', 1, { title: 'Hello World' }, { isCached: true } );
Expand Down
48 changes: 23 additions & 25 deletions docs/getting-started/fundamentals/block-in-the-editor.md
Original file line number Diff line number Diff line change
@@ -1,17 +1,17 @@
# The block in the Editor

The Block Editor is a React Single Page Application (SPA) and every block in the editor is displayed through a React component defined in the `edit` property of the settings object used to [register the block on the client](https://developer.wordpress.org/block-editor/getting-started/fundamentals/registration-of-a-block/#registration-of-the-block-with-javascript-client-side).
The Block Editor is a React Single Page Application (SPA). Every block in the Editor is displayed through a React component defined in the `edit` property of the settings object used to [register the block](https://developer.wordpress.org/block-editor/getting-started/fundamentals/registration-of-a-block/#registration-of-the-block-with-javascript-client-side) on the client.

The `props` object received by the block's `Edit` React component includes:

- [`attributes`](https://developer.wordpress.org/block-editor/reference-guides/block-api/block-edit-save/#attributes) - attributes object
- [`setAttributes`](https://developer.wordpress.org/block-editor/reference-guides/block-api/block-edit-save/#setattributes) - method to update the attributes object
- [`isSelected`](https://developer.wordpress.org/block-editor/reference-guides/block-api/block-edit-save/#isselected) - boolean that communicates whether the block is currently selected
- **[`attributes`](https://developer.wordpress.org/block-editor/reference-guides/block-api/block-edit-save/#attributes):** An object of all the block's attributes.
- **[`setAttributes`](https://developer.wordpress.org/block-editor/reference-guides/block-api/block-edit-save/#setattributes):** A method to update the attributes object.
- **[`isSelected`](https://developer.wordpress.org/block-editor/reference-guides/block-api/block-edit-save/#isselected):** A boolean value that communicates whether the block is currently selected

WordPress provides many built-in standard components that can be used to define the interface of the block in the editor. These built-in components are available via packages such as [`@wordpress/components`](https://developer.wordpress.org/block-editor/reference-guides/packages/packages-components/) and [`@wordpress/block-editor`](https://developer.wordpress.org/block-editor/reference-guides/packages/packages-block-editor/).
WordPress provides many built-in standard components that can be used to define the block interface in the Editor. These built-in components are available via packages such as [`@wordpress/components`](https://developer.wordpress.org/block-editor/reference-guides/packages/packages-components/) and [`@wordpress/block-editor`](https://developer.wordpress.org/block-editor/reference-guides/packages/packages-block-editor/).

<div class="callout">
The WordPress Gutenberg project uses <a href="https://wordpress.github.io/gutenberg/?path=/docs/docs-introduction--page">Storybook</a> to document the user interface components that are available in WordPress packages.
The WordPress Gutenberg project uses <a href="https://wordpress.github.io/gutenberg/?path=/docs/docs-introduction--page">Storybook</a> to document the user interface components that are available in WordPress packages.
</div>

Custom settings controls for the block in the Block Toolbar or the Settings Sidebar can also be defined through this `Edit` React component via built-in components such as:
Expand All @@ -28,34 +28,35 @@ The package [`@wordpress/components`](https://developer.wordpress.org/block-edit
- [`ToggleControl`](https://wordpress.github.io/gutenberg/?path=/docs/components-togglecontrol--docs)
- [`ExternalLink`](https://wordpress.github.io/gutenberg/?path=/docs/components-externallink--docs)

The package [`@wordpress/block-editor`](https://developer.wordpress.org/block-editor/reference-guides/packages/packages-block-editor/) includes a library of components and hooks for the Block Editor, including those to define custom settings controls for the block in the Editor. Some of the components most commonly used from this package are:
The package [`@wordpress/block-editor`](https://developer.wordpress.org/block-editor/reference-guides/packages/packages-block-editor/) includes a library of components and hooks for the Block Editor, including those to define custom settings controls for the block. Some of the components most commonly used from this package are:

- [`RichText`](https://github.com/WordPress/gutenberg/blob/HEAD/packages/block-editor/src/components/rich-text/README.md)
- [`BlockControls`](https://github.com/WordPress/gutenberg/tree/trunk/packages/block-editor/src/components/block-controls)
- [`InspectorControls`](https://github.com/WordPress/gutenberg/blob/HEAD/packages/block-editor/src/components/inspector-controls/README.md)
- [`InnerBlocks`](https://github.com/WordPress/gutenberg/blob/HEAD/packages/block-editor/src/components/inner-blocks/README.md)
- `PanelColorSettings` or `ColorPalette`

<div class="callout callout-tip">
The package <a href="https://developer.wordpress.org/block-editor/reference-guides/packages/packages-block-editor/"><code>@wordpress/block-editor</code></a> also provide the tools to create and use standalone block editors.
<div class="callout callout-info">
The package <a href="https://developer.wordpress.org/block-editor/reference-guides/packages/packages-block-editor/"><code>@wordpress/block-editor</code></a> also provides the tools to create and use standalone block editors.
</div>

A good workflow when using a component for the Block Editor is:

- Import the component from a WordPress package
- Add the corresponding code for the component to your project in JSX format
- Most built-in components will be used to set [block attributes](https://developer.wordpress.org/block-editor/getting-started/fundamentals/block-json/#using-attributes-to-store-block-data), so define any necessary attributes in `block.json` and create event handlers to update those attributes with `setAttributes` in your component
- If needed, adapt the code to be serialized and stored in the database
- Import the component from a WordPress package.
- Add the corresponding code for the component to your project in JSX format.
- Most built-in components will be used to set [block attributes](https://developer.wordpress.org/block-editor/getting-started/fundamentals/block-json/#using-attributes-to-store-block-data), so define any necessary attributes in `block.json` and create event handlers to update those attributes with `setAttributes` in your component.
- Adapt the code to be serialized and stored in the database if needed.

## Block Controls: Block Toolbar and Settings Sidebar

To simplify block customization and ensure a consistent experience for users, there are a number of built-in UI patterns to help generate the editor preview.
To simplify block customization and ensure a consistent user experience, there are several built-in UI patterns to help generate the Editor preview of a block.

The image below details the Block Toolbar and the Settings Sidebar of a selected Paragraph block.

![Diagram showing the Block Toolbar and the Settings Sidebar when a Paragraph block is selected](https://developer.wordpress.org/files/2023/12/block-toolbar-settings-sidebar.png)

### Block Toolbar

When the user selects a block, a number of control buttons may be shown in a toolbar above the selected block. Some of these block-level controls may be included automatically but you can also customize the toolbar to include controls specific to your block type. If the return value of your block type's `edit` function includes a `BlockControls` element, those controls will be shown in the selected block's toolbar.
When the user selects a block, a number of control buttons may be shown in a toolbar above the selected block. Some of these block-level controls may be included automatically, but you can also customize the toolbar to include controls specific to your block type. If the return value of your block type's `Edit` function includes a `BlockControls` element, those controls will be shown in the selected block's toolbar.

```jsx
export default function Edit( { className, attributes: attr, setAttributes } ) {
Expand Down Expand Up @@ -95,18 +96,15 @@ export default function Edit( { className, attributes: attr, setAttributes } ) {

_See the [full block example](https://github.com/WordPress/block-development-examples/tree/trunk/plugins/block-toolbar-ab967f) of the [code above](https://github.com/WordPress/block-development-examples/blob/trunk/plugins/block-toolbar-ab967f/src/edit.js)._


Note that `BlockControls` is only visible when the block is currently selected and in visual editing mode. `BlockControls` are not shown when editing a block in HTML editing mode.

### Settings Sidebar

The Settings Sidebar is used to display less-often-used settings or settings that require more screen space. The Settings Sidebar should be used for **block-level settings only**.
The Settings Sidebar is used to display less-often-used settings or those that require more screen space. The Settings Sidebar should be used for **block-level settings only** and is shown when a block is selected.

If you have settings that affects only selected content inside a block (example: the "bold" setting for selected text inside a paragraph): **do not place it inside the Settings Sidebar**. The Settings Sidebar is displayed even when editing a block in HTML mode, so it should only contain block-level settings.
If a setting only affects selected content inside a block, such as "bolding" text, **do not place the setting inside the Settings Sidebar**. Use a toolbar instead. The Settings Sidebar is displayed even when editing a block in HTML mode, so it should only contain block-level settings.

The Block Tab is shown in place of the Document Tab when a block is selected.

Similar to rendering a toolbar, if you include an `InspectorControls` element in the return value of your block type's `edit` function, those controls will be shown in the Settings Sidebar region.
Similar to rendering a toolbar, if you include an `InspectorControls` component in the `return` value of your block type's `Edit` function, those controls will be shown in the Settings Sidebar region.

```jsx
export default function Edit( { attributes, setAttributes } ) {
Expand Down Expand Up @@ -154,16 +152,16 @@ export default function Edit( { attributes, setAttributes } ) {
```
_See the [full block example](https://github.com/WordPress/block-development-examples/tree/trunk/plugins/settings-sidebar-82c525) of the [code above](https://github.com/WordPress/block-development-examples/blob/trunk/plugins/settings-sidebar-82c525/src/edit.js)._

Block controls rendered in both the toolbar and sidebar will also be used when multiple blocks of the same type are selected.
Block controls rendered in both the toolbar and sidebar will also be available when multiple blocks of the same type are selected.

<div class="callout callout-note">
For common customization settings including color, border, spacing customization and more, you can rely on <a href="https://developer.wordpress.org/block-editor/getting-started/fundamentals/block-json/#enable-ui-settings-panels-for-the-block-with-supports">block supports</a> to provide the same functionality in a more efficient way.
For common customization settings, including color, border, spacing, and more, you can rely on <a href="https://developer.wordpress.org/block-editor/getting-started/fundamentals/block-json/#enable-ui-settings-panels-for-the-block-with-supports">block supports</a> instead of a custom solution. Block supports provide a consistent UI with the same functionality as other Core blocks.
</div>

## Additional resources

- [Storybook for WordPress components](https://wordpress.github.io/gutenberg/?path=/docs/docs-introduction--page)
- [@wordpress/block-editor](https://developer.wordpress.org/block-editor/reference-guides/packages/packages-block-editor/)
- [@wordpress/components](https://developer.wordpress.org/block-editor/reference-guides/packages/packages-components/)
- [`Inspector Controls`](https://github.com/WordPress/gutenberg/blob/HEAD/packages/block-editor/src/components/inspector-controls/README.md)
- [`InspectorControls`](https://github.com/WordPress/gutenberg/blob/HEAD/packages/block-editor/src/components/inspector-controls/README.md)
- [`BlockControls`](https://github.com/WordPress/gutenberg/tree/trunk/packages/block-editor/src/components/block-controls)
Loading

0 comments on commit ba4feb7

Please sign in to comment.