# Pulling changes from WordPress Pull brings the WordPress version of a post back into Workover, replacing the document body. ## When you need it - Someone edited the post in wp-admin and you want those edits in Workover. - A plugin rewrote the content. - A push was refused because WordPress is ahead, and you need to reconcile before pushing. - You imported a site and want a document refreshed against the current post. ## What it does The post’s content comes back, block markup converted into editor content, and Workover re-records the post’s modification time — which is what clears the **WordPress is newer** badge. **It replaces the document body.** Unpushed edits in Workover are overwritten. Workover warns before a pull that would discard work, and the pre-pull state stays in [version history](/docs/version-history), so a pull is recoverable. ## What it does not touch Other tabs. Only the synced tab is replaced — briefs and notes are untouched. ## Pull, or override? When a push is refused because the post changed on the other side, you have two honest options: **Pull first** when the WordPress change matters — someone fixed something, a field was set. Copy your unpushed edits somewhere first, or recover them from version history afterwards. **Override** when you know the change is irrelevant: a plugin bumped a counter, a cache warmer touched the modification time without changing the content. Confirm the warning and push. If you cannot tell, open the post in WordPress and look. It is faster than reasoning about it. ## Content the editor cannot represent ACF fields, shortcodes and third-party blocks are preserved rather than converted — they come back through the round trip intact. Where a post is mostly made of those, Workover will say so and offer the block view instead. See [custom blocks and ACF fields](/docs/custom-blocks-and-acf). ## Related - [How WordPress sync works](/docs/how-wordpress-sync-works) - [Sync status and conflicts](/docs/sync-status-and-conflicts) - [Version history](/docs/version-history)