Working with Gutenberg

The content field of the document is the post’s post_content, which is exactly the block markup the WordPress block editor (Gutenberg) reads and writes. Octa Editor treats it as opaque HTML, so the block editor stays fully compatible.

Block markup is preserved

Gutenberg stores each block as HTML wrapped in comment delimiters such as <!-- wp:paragraph -->. Octa Editor does not parse, reformat, or strip these delimiters. Reading a record returns the block markup verbatim, and writing content back opens the blocks normally in the editor.

The safest way to edit a block-based page is to export the record, change the text inside the markup, and write it back. Keep the <!-- wp:… --> and <!-- /wp:… --> delimiters intact. If a block’s markup becomes malformed, the block editor flags it as an invalid block, the same as it would for any hand-edited content. This is a WordPress behavior, not an Octa Editor restriction.

HTML sanitization

Octa Editor applies the same HTML rules WordPress applies on a normal save, and the rule follows the unfiltered_html capability.

• A user with unfiltered_html (typically an administrator or editor on a single site) writes raw HTML, so any block markup, including custom HTML blocks, is stored untouched.
• A user without unfiltered_html has the content filtered through wp_kses_post, which strips scripts, event handlers, and other disallowed markup. This matches what the block editor itself does for that user.

Because the behavior mirrors core, Octa Editor adds no new restrictions. If a block survives a normal editor save for a given user, it survives a write through Octa Editor for that same user. See Capabilities and permissions.

ACF blocks and fields

Custom field values are not part of content. They live in the separate fields object and are written through the ACF provider. See Custom fields (ACF).