From e821e7e530e46dba92a8fd2e593cf5525de00bf9 Mon Sep 17 00:00:00 2001 From: Nick Diego Date: Mon, 5 Feb 2024 13:09:17 -0600 Subject: [PATCH 1/2] Copy and formatting edits. --- .../markup-representation-block.md | 53 ++++++++++--------- 1 file changed, 29 insertions(+), 24 deletions(-) diff --git a/docs/getting-started/fundamentals/markup-representation-block.md b/docs/getting-started/fundamentals/markup-representation-block.md index b048160907a259..0cecca4ab1f100 100644 --- a/docs/getting-started/fundamentals/markup-representation-block.md +++ b/docs/getting-started/fundamentals/markup-representation-block.md @@ -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` +- The comments for all Core blocks start with the `wp` prefix (namespace) followed by the block name (e.g., `wp:image`) +- For custom blocks, the comment should begin with a unique `namespace`, typically associated with the plugin or the block's creator, followed by the `blockname` (e.g., `namespace:blockname`). - 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: -``` - -
+```html + +
+ +
``` -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. +
+ Refer to the Data Flow article for a more in-depth look at how block data is parsed in WordPress. +
-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 ``` -## 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 \ No newline at end of file From 9ba35884f10807c3b53b41b4867f71aab3809a2d Mon Sep 17 00:00:00 2001 From: Nick Diego Date: Mon, 5 Feb 2024 17:40:57 -0600 Subject: [PATCH 2/2] Clarify markup guidelines. --- .../fundamentals/markup-representation-block.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/docs/getting-started/fundamentals/markup-representation-block.md b/docs/getting-started/fundamentals/markup-representation-block.md index 0cecca4ab1f100..b9cbb528b49db8 100644 --- a/docs/getting-started/fundamentals/markup-representation-block.md +++ b/docs/getting-started/fundamentals/markup-representation-block.md @@ -4,8 +4,8 @@ Blocks are stored in the database or within HTML templates using a unique [HTML- Here are a few guidelines for the markup that defines a block: -- The comments for all Core blocks start with the `wp` prefix (namespace) followed by the block name (e.g., `wp:image`) -- For custom blocks, the comment should begin with a unique `namespace`, typically associated with the plugin or the block's creator, followed by the `blockname` (e.g., `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. - Block settings and attributes are stored as a JSON object inside the block comment.