Custom blocks and ACF fields

Some things on a WordPress page cannot survive a trip through a rich-text editor. Workover’s answer is to not convert them.

The problem

A rich-text editor understands paragraphs, headings, lists, links and images. It does not understand an ACF field group, a shortcode, or a third-party block that renders a pricing table from a plugin’s own data.

Convert those into editor content and you get their output at best, and nothing at worst. Push that back and you have replaced a working block with a paragraph of text — silently, on a live page.

What Workover does instead

Those elements are preserved rather than converted. They come into the document as opaque markers, travel with it, and are written back exactly as they were. You can move one, or delete it, but you cannot edit its internals in the editor — because editing it there is precisely what would break it.

This covers ACF fields, shortcodes, custom blocks and third-party blocks.

When a page is mostly blocks

For a page built almost entirely out of blocks — a landing page, a pricing page — editing the prose around them is not what you want anyway. Workover scores how much of the post it can meaningfully represent, and when the answer is “not much”, offers to edit the post as blocks instead.

In that mode you work with the block markup itself, and the push sends it verbatim with no conversion. That is the safe way to touch a page like that.

The push guard

If a push would drop something the editor cannot represent, Workover refuses and lists what would be lost. That refusal is the feature: it is the difference between noticing now and finding out when someone visits the page.

You can override when you are certain the element is not needed. Read the list first.

Practical guidance

Prose-heavy posts — the editor, all the way.
Block-heavy pages — the block view, or edit them in WordPress and pull.
Anything with ACF — safe either way; the fields are preserved.