How WordPress sync works

Workover does not host your content and does not sit in front of your site. It talks to WordPress through the REST API, using credentials you gave it, and it does so only when you ask. Understanding the model takes two minutes and saves a lot of confusion later.

Two copies, one link

When a document is linked to a WordPress post, there are two copies of that content: the one in Workover and the one in WordPress. Neither is automatically authoritative. They are reconciled by two deliberate actions:

• Push — send the Workover version to WordPress, overwriting the post.
• Pull — fetch the WordPress version into Workover, overwriting the document.

There is no continuous background sync, and that is on purpose. Content is not a database row; an automatic merge of two edited drafts produces something nobody wrote. Workover instead tells you which side is ahead and makes you choose.

What Workover remembers

At the moment of a push or pull, Workover records when the WordPress post was last modified. That single timestamp is what everything else is built on.

Periodically, and when you open a project, Workover re-checks the modification time of the linked posts. If a post changed since the timestamp it recorded, it knows WordPress has moved on. That is what produces the WordPress is newer badge, and it is why a push can be refused — see sync status and conflicts.

What a push actually sends

A push is a single write to the WordPress REST API containing:

• The body, converted from the editor’s format into Gutenberg block markup.
• The title.
• Any fields you changed in the WordPress panel — status, slug, excerpt, categories, tags, featured image, author, publication date, SEO fields, custom fields.

Fields you did not touch are not sent at all. This matters: a push never blanks something you left alone, so a setting configured in WordPress and never mirrored in Workover survives.

Images

Images in a document are stored by Workover. Before a push, any that WordPress does not already have are uploaded into your media library and the body is rewritten to point at them there. The published page therefore does not depend on Workover being reachable, and disconnecting later does not break your images.

Content WordPress has that the editor cannot represent

Some things do not survive a round trip through a rich-text editor — ACF fields, shortcodes, and custom or third-party blocks. Workover preserves these rather than converting them: they are carried through untouched and written back as they were.

When a post is mostly made of those, Workover will say so and offer to edit it as blocks instead, which avoids the conversion entirely. Custom blocks and ACF fields explains when that happens.

What a pull does

A pull replaces the document body with what is on WordPress, converting block markup back into editor content, and re-records the timestamp. Your Workover edits to that document are replaced — which is why Workover warns before a pull that would discard unpushed work.

Previous versions are kept, so a pull is recoverable: version history will still have what you had before it.

Permissions

Workover can only do what the WordPress user behind the application password can do. If pushes fail with a permissions error, that user’s role is the first thing to check — an Editor cannot publish others’ posts, and a Contributor cannot publish at all.

Revoking the application password in WordPress cuts the connection immediately and affects nothing already published.