-
Notifications
You must be signed in to change notification settings - Fork 4.3k
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
Docs: Copy and formatting edits for the "Markup representation of a b…
…lock" guide (#58688) * Copy and formatting edits. * Clarify markup guidelines. Co-authored-by: ndiego <nick.diego@automattic.com> Co-authored-by: justintadlock <greenshady@git.wordpress.org>
- Loading branch information
1 parent
42be4bd
commit 04b5a80
Showing
1 changed file
with
29 additions
and
24 deletions.
There are no files selected for viewing
53 changes: 29 additions & 24 deletions
53
docs/getting-started/fundamentals/markup-representation-block.md
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -1,46 +1,51 @@ | ||
| # Markup representation of a block | ||
|
|
||
| When stored in the database or in templates as HTML files, blocks are represented using a [specific HTML grammar](https://developer.wordpress.org/block-editor/explanations/architecture/key-concepts/#data-and-attributes), which is technically valid HTML based on HTML comments that act as explicit block delimiters | ||
| Blocks are stored in the database or within HTML templates using a unique [HTML-based syntax](https://developer.wordpress.org/block-editor/explanations/architecture/key-concepts/#data-and-attributes), distinguished by HTML comments that serve as clear block delimiters. This ensures that block markup is technically valid HTML. | ||
|
|
||
| These are some of the rules for the markup used to represent a block: | ||
| Here are a few guidelines for the markup that defines a block: | ||
|
|
||
| - All core block comments start with a prefix and the block name: `wp:blockname` | ||
| - For custom blocks, `blockname` is `namespace/blockname` | ||
| - Core blocks begin with the `wp:` prefix, followed by the block name (e.g., `wp:image`). Notably, the `core` namespace is omitted. | ||
| - Custom blocks begin with the `wp:` prefix, followed by the block namespace and name (e.g., `wp:namespace/name`). | ||
| - The comment can be a single line, self-closing, or wrapper for HTML content. | ||
| - Custom block settings and attributes are stored as a JSON object inside the block comment. | ||
| - Block settings and attributes are stored as a JSON object inside the block comment. | ||
|
|
||
| _Example: Markup representation of an `image` core block_ | ||
| The following is the simplified markup representation of an Image block: | ||
|
|
||
| ``` | ||
| <!-- wp:image --> | ||
| <figure class="wp-block-image"><img src="source.jpg" alt="" /></figure> | ||
| ```html | ||
| <!-- wp:image {"sizeSlug":"large"} --> | ||
| <figure class="wp-block-image size-large"> | ||
| <img src="source.jpg" alt="" /> | ||
| </figure> | ||
| <!-- /wp:image --> | ||
| ``` | ||
|
|
||
| The [markup representation of a block is parsed for the Block Editor](https://developer.wordpress.org/block-editor/explanations/architecture/data-flow/) and the block's output for the front end: | ||
|
|
||
| - In the editor, WordPress parses this block markup, captures its data and loads its `edit` version | ||
| - In the front end, WordPress parses this block markup, captures its data and generates its final HTML markup | ||
|
|
||
| Whenever a block is saved, the `save` function, defined when the [block is registered in the client](https://developer.wordpress.org/block-editor/getting-started/fundamentals/registration-of-a-block/#registration-of-the-block-with-javascript-client-side), is called to return the markup that will be saved into the database within the block delimiter's comment. If `save` is `null` (common case for blocks with dynamic rendering), only a single line block delimiter's comment is stored, along with any attributes | ||
| The markup for a block is crucial both in the Block Editor and for displaying the block on the front end: | ||
|
|
||
| The Post Editor checks that the markup created by the `save` function is identical to the block's markup saved to the database: | ||
| - WordPress analyzes the block's markup within the Editor to extract its data and present the editable version to the user. | ||
| - On the front end, WordPress again parses the markup to extract data and render the final HTML output. | ||
|
|
||
| - If there are any differences, the Post Editor triggers a [block validation error](https://developer.wordpress.org/block-editor/reference-guides/block-api/block-edit-save/#validation). | ||
| - Block validation errors usually happen when a block’s `save` function is updated to change the markup produced by the block. | ||
| - A block developer can mitigate these issues by adding a [**block deprecation**](https://developer.wordpress.org/block-editor/reference-guides/block-api/block-deprecation/) to register the change in the block. | ||
| <div class="callout callout-tip"> | ||
| Refer to the <a href="https://developer.wordpress.org/block-editor/explanations/architecture/data-flow/">Data Flow</a> article for a more in-depth look at how block data is parsed in WordPress. | ||
| </div> | ||
|
|
||
| The markup of a **block with dynamic rendering** is expected to change so the markup of these blocks is not saved to the database. What is saved in the database as representation of the block, for blocks with dynamic rendering, is a single line of HTML consisting on just the block delimiter's comment (including block attributes values). That HTML is not subject to the Post Editor’s validation. | ||
| When a block is saved, the `save` function—defined when the [block is registered in the client](https://developer.wordpress.org/block-editor/getting-started/fundamentals/registration-of-a-block/#registration-of-the-block-with-javascript-client-side)—is executed to generate the markup stored in the database, wrapped in block delimiter comments. For dynamically rendered blocks, which typically set `save` to `null`, only a placeholder comment with block attributes is saved. | ||
|
|
||
| _Example: Markup representation of a block with dynamic rendering (`save` = `null`) and attributes_ | ||
| Here is the markup representation of a dynamically rendered block (`save` = `null`). Notice there is no HTML markup besides the comment. | ||
|
|
||
| ```html | ||
| <!-- wp:latest-posts {"postsToShow":4,"displayPostDate":true} /--> | ||
| ``` | ||
|
|
||
| ## Additional Resources | ||
| When a block has a `save` function, the Block Editor checks that the markup created by the `save` function is identical to the block's markup saved to the database: | ||
|
|
||
| - Discrepancies will trigger a [validation error](https://developer.wordpress.org/block-editor/reference-guides/block-api/block-edit-save/#validation), often due to changes in the `save` function's output. | ||
| - Developers can address potential validation issues by implementing [block deprecations](https://developer.wordpress.org/block-editor/reference-guides/block-api/block-deprecation/) to account for changes. | ||
|
|
||
| As the example above shows, the stored markup is minimal for dynamically rendered blocks. Generally, this is just a delimiter comment containing block attributes, which is not subject to the Block Editor's validation. This approach reflects the dynamic nature of these blocks, where the actual HTML is generated server-side and is not stored in the database. | ||
|
|
||
| ## Additional resources | ||
|
|
||
| - [Data Flow and Data Format](https://developer.wordpress.org/block-editor/explanations/architecture/data-flow/) | ||
| - [Static vs. dynamic blocks: What’s the difference?](https://developer.wordpress.org/news/2023/02/27/static-vs-dynamic-blocks-whats-the-difference/) | ||
| - [Block deprecation – a tutorial](https://developer.wordpress.org/news/2023/03/10/block-deprecation-a-tutorial/) | ||
| - [Static vs. dynamic blocks: What’s the difference?](https://developer.wordpress.org/news/2023/02/27/static-vs-dynamic-blocks-whats-the-difference/) | Developer Blog | ||
| - [Block deprecation – a tutorial](https://developer.wordpress.org/news/2023/03/10/block-deprecation-a-tutorial/) | Developer Blog | ||
| - [Introduction to Templates > Block markup](https://developer.wordpress.org/themes/templates/introduction-to-templates/#block-markup) | Theme Handbook |