The whole point of WPChangeSync, experienced on one site, in ten minutes. Export, read the file, change something, bring it back.
Updated 5 June 2026·Task guide
No second site required
This guide exists because of one sentence I keep hearing: I bought it, but I have not had time to set it all up. Fair. So here is the smallest possible version, on the site you already have. No second site, no remotes, no workflow, no configuration beyond a storage folder.
In ten minutes you will export a piece of your site to a file you can actually read, change something, and bring it back. That round trip is the whole idea of WPChangeSync. Everything else, remotes, workflows, approvals, migrations, is that same loop with more reach.
Minutes 0 to 2: licence and storage
Two one-time steps, skip what you have already done:
Activate your licence under WPChangeSync, then License. If you cannot find your key, it is in your account at my.alterview.net.
Pick a storage location under Settings, then Storage. If you are not sure, choose wp-content/wpchangesync/. If the folder does not exist yet, the screen shows a Create Directory button. You are done when Current Status shows a green OK.
Leave the sync mode alone. Manual is the default, nothing will ever happen unless you click it.
Minutes 3 to 5: export something small
Open the Library. Every row is something syncable on your site, shown next to the file it would become.
Pick something small and harmless. Menus is a good first pick, every site has one and you will recognise every item in the file. If you run Bricks, a single template works nicely too.
Click Export on that row. That is it. WPChangeSync just wrote part of your site to your storage folder as JSON.
Minutes 5 to 7: open the file
Now open the file, over FTP, in your host's file manager, or in your code editor if the folder is local. Look at what is in there: your menu items, their labels, their order, as plain readable text.
This is the moment the plugin makes sense. That file can be read in a pull request, committed to Git, diffed against last week, copied to another environment, or handed to a colleague. Your site's configuration just became a file instead of a database mystery.
Minutes 7 to 10: change something, then bring it back
Back in WordPress, change something visible in that menu. Rename an item, drag it somewhere else, remove it. Confirm the change on the front end.
Then go back to the Library row and click Import. Check the front end again: your change is gone, the menu is back to exactly what the file says. You have just done your first sync, a restore from a file, on one site.
Two things happened quietly along the way: WPChangeSync took a backup before it overwrote anything, and the import only touched the menu. Nothing else on the site was involved. That precision is the difference between this and copying a database.
Why no second site? Because file-based sync has no idea how many sites are involved. Export writes files, import reads them. Whether the file travels to another server in between, by Git, by deploy pipeline, by shared folder, is up to you, later. And if you would rather not touch real content at all, the Activity screen has a demo data seeder that creates sample content to play with and removes it again.
Where to go from here
When the ten minutes leave you wanting more, the natural next steps, in order:
Connect two sites, one Application Password and you can push and pull for real.
Git version control, if the JSON file made your version-control heart beat faster.
And if you get stuck anywhere in those ten minutes, that is a bug in this guide as far as I am concerned. Tell me: support@wpchangesync.com, or post in the community.
