Version Control for WordPress Content: Is DB Version Control the Answer?

WordPress keeps a revision history for posts and pages, but not for classic menus, widgets, plugin settings or most site options, and it has no built-in way to sync content between a local, staging and live site. DB Version Control is a free developer plugin that exports posts, pages, menus and settings to JSON files you can track in Git. It can help a developer team, but as of October 2026 it is distributed only on GitHub, has not changed since version 1.1.0 in May 2025, and carries real risks on a live site.

What does WordPress already keep a history of?

WordPress saves a revision every time you update a post or page, so you can compare versions and restore an earlier one from the editor.

• Posts, pages and many custom post types. Revisions record changes to the title, author, content and excerpt. WordPress 7.0 added a new revisions screen that marks added, removed and changed blocks.
• Block theme design. Since WordPress 6.5, the Site Editor keeps revisions for styles, templates and template parts.
• No history. Classic menus, widgets, plugin settings and most site options live elsewhere in the database (settings sit in the wp_options table) and are simply overwritten when changed. Media files have no versions either.

Revisions also stay on one site: they undo a bad edit, but cannot carry changes from staging to live.

What is DB Version Control?

DB Version Control is a free plugin that treats content like code: it writes your posts, pages, menus and settings to readable JSON files (a plain text data format) in a sync folder, so a developer can track them with Git, the version control system used for code. Robert DeVore released it in May 2025. In June 2025, after stepping away from WordPress, he handed it and his other WordPress plugins, 20 in all, to the agency WebDevStudios.

Question	Answer (October 2026)
Current version	1.1.0, released May 29, 2025
Where to get it	GitHub only (WebDevStudios/db-version-control); not in the WordPress.org plugin directory
Maintained?	No code changes since May 2025; open issues have no reply from a maintainer
Price and license	Free, GPL v2 or later
Requirements	WordPress 5.0 or later and PHP 7.4 or later; WP-CLI for imports

Treat it as a tool to test on copies, not as a maintained product.

What does DB Version Control export and import?

It exports published content and most site settings, and imports them back through WP-CLI, WordPress's command line tool.

• Posts and pages. One JSON file per published item, with its custom fields, for the post types you choose (posts and pages by default, plus public types such as WooCommerce products).
• Settings. One options.json file with the settings WordPress loads on every page, minus a short list such as the site address and security keys.
• Menus. One menus.json file with classic menus and their locations.
• Block theme data. Templates, template parts, global styles, navigation and the site's custom CSS, added in version 1.1.0.

Files update automatically when a post is saved or certain settings change, or all at once from the DBVC Export screen or the wp dbvc export command. There is no import button: importing is the wp dbvc import command, which overwrites existing content.

What it leaves out matters as much: media files, categories and tags, comments, users, post authors and dates, drafts and scheduled posts, and anything plugins keep in their own database tables, such as form entries and, on newer WooCommerce stores, orders.

How does a Git content sync work, in plain terms?

A developer exports on one site, commits the changed files to Git, and imports them on the other site.

• Edit content on the staging copy, a private copy of the site for testing.
• Export, and the JSON files for the changed pages and settings update.
• Commit them to Git. A diff (a list of the lines that changed) shows exactly what changed and when.
• On the live site, pull the files and run the import.

This suits developer teams who already use Git and WP-CLI. It does not suit an owner without a developer, or a store where the live database changes every hour.

What are the limits and risks?

The biggest risks are secrets in the settings file, how imports match content, and what an import changes beyond content.

Secrets in the settings file

The plugin's documentation says sensitive options such as API keys and salts are excluded automatically. In the 1.1.0 code, that list covers WordPress's own security keys and a few core settings only, so API keys, mail passwords and payment keys that other plugins save as settings can end up in options.json, and from there in a Git repository.

Files that can be opened in a browser

The sync folder must sit inside the WordPress installation, and by default it sits inside the plugin's own folder. A contributor reported in August 2025 that the export folder had no access restrictions, so the JSON files could be opened directly in a browser. Their pull request has not been merged, so protecting the folder is up to you.

Imports match by ID number

Each file is matched to the destination by its database ID. A page created on staging is not created on live if live has no item with that ID, and if live has a different item with that ID, the import overwrites it. It works best when both sites began as a copy of the same database.

Settings imports change more than content

The import writes back every setting in options.json, which includes the list of active plugins and the active theme. Importing staging settings onto live can change far more than a page.

Media, serialized data and page builders

Images are not copied, so the other site needs the same media. Many settings are stored as serialized data, a packed format that breaks if edited by hand; the plugin handles it, but it does not swap site addresses inside content, so a staging address can reach the live site. Content and custom fields also pass through WordPress's cleaning functions, which strip embed code such as iframes and HTML stored in custom fields, and an open issue reports page builder (Bricks) data not importing correctly.

What are the alternatives for site owners and teams?

For most sites, a backup before every change plus a staging copy is safer than syncing content through Git.

Option	What it does	Best for	Watch for
WordPress revisions	Restores an earlier version of a post, page, template or style	Every site	One site only; no settings or classic menus
A backup before every change	Copies files and database so you can roll back	Every site	A restore also rolls back new orders and form entries
Host staging with push	Copies live to staging, then pushes files, the database or chosen tables back	Owners whose host offers it	A full push overwrites live
WP Migrate (WP Engine)	Free Lite version exports the database with a safe find and replace; the paid version pushes and pulls databases, media, themes and plugins	Developers and agencies	A push replaces whole tables on the destination
DB Version Control	Content and settings as JSON files in Git	Developer teams using Git and WP-CLI	The limits above

Host tools differ. Kinsta can push only files, only the database or specific tables, backs up the live site first, and warns that it cannot tell new orders from old during a push. SiteGround's Custom Deploy compares staging with live and lets you pick files and tables, so you can leave tables such as visitor comments on live untouched.

VersionPress, an earlier attempt at Git-based version control for WordPress, is not an option: its project page says it is not actively developed and not production-ready, and its code repository was archived in July 2024.

Which approach fits your site?

Choose by how often your live data changes and who works on the site:

• One business site, no developer: rely on revisions, daily off-site backups and a staging copy for updates, and make content changes on the live site.
• A store or membership site: never push a whole staging database to live. Copy live to staging, test, then push only files or chosen tables, or repeat the content edits on live.
• A developer team: keep themes and custom plugins in Git, and add DB Version Control or WP Migrate for content only after a full test round trip between copies.

For developers: a safer DB Version Control setup

• Use a dedicated sync folder under wp-content and block web access to it with a server rule. The README suggests a folder outside the web root, but the 1.1.0 code rejects any path outside the WordPress install.
• Add every plugin secret to the dbvc_excluded_option_keys filter, read options.json before the first commit, and keep the repository private.
• Run wp db export before every wp dbvc import, so you can roll back.
• On large sites, lower the batch size option (the default is 50). When site addresses differ, run wp search-replace afterwards: it handles serialized data and has a dry run option.

Whatever you use, back up before any import or push. WP Resolve's Essential, Business and Commerce care plans include daily off-site backups kept 30 days, and Business Care and Commerce Care test updates on a staging copy before they reach your live site.

Not sure what your site is backing up today? The free site health check covers your updates, backups, security and speed, or you can text WP Resolve at (916) 209-0917.

Frequently asked questions