Mark Rowatt Anderson

SitePush is a WordPress plugin which allows you to have multiple versions of your WordPress site, so you can edit, develop, test without any risk to your main, live site. It’s great for developers, designers and editors… anyone who wants to be able to test changes to a site before it is visible to the world. For example:-
<ol>
<li>you can easily move content between sites. For example, make extensive edits on a private staging site, and then push changes all at once to your live site. Or, easily pull copy of your live database into your development site so you are developing against the latest content.</li>
<li>test new themes and plugins, and only push them to your live site once they are configured and working as you want.</li>
<li>upgrade WordPress, themes and plugins on a private site so you can test that nothing breaks before upgrading your live site. Sure you take backups before any upgrades (right?), but it’s a pain doing a full backup and an even bigger pain restoring from a backup.</li>
<li>easily make small (and big!) code changes on your development site, test and easily push new code to a live site. Great for dealing with clients who want “just one more thing”.</li>
</ol>
Although SitePush installation is a bit more involved than a typical plugin, once set up it runs with minimal effort and can be easily used by non-tech authors & editors. Site admins can easily configure SitePush so that non-admins can only push content (i.e. posts/pages, comments and uploads) and to a restricted set of sites.
Please read the Installation instructions before you install SitePush – it’s not a normal download and activate type of plugin installation
<h4>Support</h4>
SitePush is under active development and I will do my best to provide fixes to problems. The latest general releases are always available through the WordPress Plugins Directory. Development code is <a href="https://github.com/rowatt/sitepush/tree/develop" rel="nofollow ugc">hosted on GitHub</a>, so you may find more frequent releases there.
For general questions, please post on the WordPress forums with the tag sitepush. For bug reports or if you wish to suggest patches or fixes, please go to the <a href="https://github.com/rowatt/sitepush" rel="nofollow ugc">SitePush GitHub repository</a>.
If you have any problems with SitePush, it would be helpful if you could add
<pre><code>define('SITEPUSH_DEBUG',TRUE);
</code></pre>
to your wp-config.php file, and include the output which will now be displayed at the top of the SitePush options screen.
Disclaimer Although SitePush has been well tested and is used on production web sites, it moves files and database content between sites which could break things. Use of SitePush is at your own risk! Please make sure you have adequate backups and if you do find any problems please report them.
<h4>Roadmap</h4>
There are a number of areas which could be improved. Currently on the roadmap:-
<ul>
<li>improve push undo</li>
<li>add support for pushing between sites on different servers</li>
</ul>
Please let me know how you would like to see SitePush evolve.
<h3>Server Setup</h3>
<h4>How to setup SitePush in a multiple vhost environment</h4>
You can run your separate versions of a site in a single vhost, or in separate vhosts. While running them all in a single vhost can be little easier to set up on some web hosts, it does not work well if different sites need any different configuration in your .htaccess file – for example if you are using a caching plugin.
If you are able to set up separate vhosts (or subdomains as some hosts call them) I recommend you do it that way.
Let’s say you want to have three versions of your site – live, test, and dev.
Set up a vhost for each site. Where they all sit on your server will depend on your hosting setup, but let’s say they are at:-
<pre><code>/var/www/vhosts/live/httpdocs
/var/www/vhosts/test/httpdocs
/var/www/vhosts/dev/httpdocs
</code></pre>
You will need to create a directory to hold all the config files. If at all possible, this directory should not be web accessible. For example, it might be at:-
<pre><code>/var/www/sitepush/config
</code></pre>
You will also probably want to create a directory for any backups SitePush makes, such as:-
<pre><code>/var/www/sitepush/backups
</code></pre>
Finally, you will need to create a database for each of your sites. Consult the <a href="https://codex.wordpress.org/Installing_WordPress" rel="nofollow ugc">WordPress installation instructions</a> and your web host for how to do this.
Download WordPress and unzip it into one of your sites. I normally keep WordPress in its own subdirectory, for example:-
<pre><code>/var/www/vhosts/live/httpdocs/wordpress
</code></pre>
That way, the root directory stays clean, and if I install anything else outside of WordPress, there won’t be any confusion of which files belong where. You need to make a couple of changes for this setup to work – see <a href="https://codex.wordpress.org/Giving_WordPress_Its_Own_Directory" rel="nofollow ugc">WordPress documentation</a> for more details. Note that for multisite installs, though, you will need to install WordPress in the root directory.
I do, however, put my wp-config.php file in the root directory (WordPress is smart enough to find it).
Next you will need to create the SitePush config files and put them in the config directory you created above. See <a href="https://wordpress.org/extend/plugins/sitepush/installation" rel="ugc">the SitePush installation instructions</a> for what needs to go in your sites config file and your database config file (I usually call them sites.ini.php and dbs.ini.php).
Now, copy the files from the site you just set up to your other sites, for example:-
<pre><code>cd /var/www/vhosts
cp -r live/httpdocs dev/httpdocs
</code></pre>
To save a bit of disk space (at the expense of possibly messing things up between sites), you can also symlink the uploads directory between sites so there is only one copy of any media files uploaded. For example:-
<pre><code>cd /var/www/vhosts/dev/httpdocs/wordpress/wp-content
rmdir uploads
ln -s ../../../../live/httpdocs/wordpress/wp-content/uploads uploads
</code></pre>
The exact paths will depend on your setup.
Finally, log into your live site, install, activate and configure SitePush, and now you are set up to easily move files and content between 3 versions of your site!
<h4>How to setup SitePush in a single vhost</h4>
You can run your separate versions of a site in a single vhost, or in separate vhosts. Depending on your web host, running them all in a single vhost can be bit easier to set up, though it does mean you need to share one .htaccess file across all versions of your site, and won’t work for WordPress Multisite setups.
If you are able to set up separate vhosts (or subdomains as some hosts call them) I recommend you do it that way, but if not, these instructions show how you can have multiple version so of your site on one vhost.
Let’s say you want to have three versions of your site – live, test, and dev.
First make sure that you can set up domain aliases on your host – so that multiple domains point to the same files. For example, you might set up:-
<pre><code>live.example.com
test.example.com
dev.example.com
</code></pre>
If your host allows wildcard domain setups, so for example anything.example.com would point to your files, that would also work
Set up a subdirectory for each site. Where they all sit on your server will depend on your hosting setup, but let’s say they are at:-
<pre><code>/var/www/httpdocs/live
/var/www/httpdocs/test
/var/www/httpdocs/dev
</code></pre>
You will need to create a directory to hold all the config files. If at all possible, this directory should not be web accessible. For example, it might be at:-
<pre><code>/var/www/sitepush/config
</code></pre>
You will also probably want to create a directory for any backups SitePush makes, such as:-
<pre><code>/var/www/sitepush/backups
</code></pre>
Download WordPress and unzip it into one of the directories for your sites. For example:-
<pre><code>/var/www/httpdocs/live
</code></pre>
Follow the <a href="https://codex.wordpress.org/Giving_WordPress_Its_Own_Directory" rel="nofollow ugc">instructions</a> for more installing WordPress in a subdirectory.
You should also now create a database for each of your sites. Consult the <a href="https://codex.wordpress.org/Installing_WordPress" rel="nofollow ugc">WordPress installation instructions</a> and your web host for how to do this.
Complete any other required configuration (WordPress setup, plugin installs etc) and make sure that your site is now working properly. Don’t forget to install SitePush!
Next you need to create the SitePush config files and put them in the config directory you created above. See here readme.txt or <a href="https://wordpress.org/extend/plugins/sitepush/installation" rel="ugc">the SitePush installation instructions</a> for what needs to go in your sites config file and your database config file (I usually call them sites.ini.php and dbs.ini.php).
Now, copy the files from the site you just set up to your other sites, for example:-
<pre><code>cd /var/www/httpdocs
cp -r live dev
cp -r live test
</code></pre>
To save a bit of disk space (at the expense of possibly messing things up between sites), you can also symlink the uploads directory between sites so there is only one copy of any media files uploaded. For example:-
<pre><code>cd /var/www/httpdocs/dev/wp-content
rmdir uploads
ln -s ../../live/wp-content/uploads uploads
</code></pre>
The exact paths will depend on your setup.
Next you need to make some changes to your wp-config.php file so that it will point to the correct site files and database depending on what domain name was used. The exact details will vary depending on your setup, but you will want something like this, which should be inserted immediately above the line <code>/* That's all, stop editing! Happy blogging. */</code>:-
<pre><code>switch ( $_SERVER['SERVER_NAME'] ) {
 case 'test.example.com':
 $site_dir='test';
 define('DB_NAME', 'database_name_here');
 define('DB_USER', 'username_here');
 define('DB_PASSWORD', 'password_here');
 break;

 case 'dev.example.com':
 define('DB_NAME', 'database_name_here');
 define('DB_USER', 'username_here');
 define('DB_PASSWORD', 'password_here');
 $site_dir='dev';
 break;

 case 'www.example.com':
 case 'live.example.com':
 default:
 define('DB_NAME', 'database_name_here');
 define('DB_USER', 'username_here');
 define('DB_PASSWORD', 'password_here');
 $site_dir='live';
 break;
}
</code></pre>
Insert whatever constant definitions are specific to a site in that section, and delete or comment them out from their original location in wp-config.
Lastly, you need to edit the last line of wp-config so it reads:-
<pre><code>require("./{$site_dir}/wp-blog-header.php");
</code></pre>
You can now log into your live site, activate and configure SitePush. Once that is done, you can push everything to your other sites and you should now be able to access all three versions of your site. You are now set up to easily move files and content between 3 versions of your site!

SitePush

Easily move content and code between WordPress sites. Pull your site's DB to a dev site, push new code to a staging site, etc.

migro

Stop using site-migration tools for editorial work.
Plugins like Duplicator and All-in-One WP Migration were built for moving hosts. Clone the whole database, overwrite everything, hope nothing breaks. That’s the wrong tool for the weekly grind of pushing finished posts to production.
Migro is built for that weekly grind.
Pick a post. Click Push. Migro deploys only that post (with its categories, tags, featured image, embedded media, and alt text) and leaves the rest of the destination site untouched. Pull works the same way in reverse: grab live content back to staging for testing.
<h4>Built for agencies and freelancers</h4>
You’re managing client sites with a staging-to-production workflow. The writer drafts on staging, you review, you deploy. Maybe the client wants to push their own finished drafts. Migro handles all of it:
<ul>
<li>Selective deployment. Pick exactly the posts that should move. Nothing else on the destination changes.</li>
<li>Bidirectional Push and Pull. Push staging to production, or pull production back to staging. Same flow either way.</li>
<li>Sync-key tracking. Re-deploying the same post updates it in place, even if its slug or ID differs on the destination.</li>
<li>Backups before every overwrite. One-click restore if a deployment was wrong.</li>
<li>Editor role can deploy. Let your client push their own finished drafts without giving them admin access.</li>
<li>Unlimited. No monthly cap, no upsell prompts blocking your work.</li>
</ul>
<h4>Headline features</h4>
<ul>
<li>Selective Push and Pull between any two WordPress environments.</li>
<li>AI-powered alt text for images missing it. Bring your own Anthropic, OpenAI, or Google Gemini key via the WordPress AI Connector. Existing alt text is never overwritten.</li>
<li>One-click backup and restore before every overwrite.</li>
</ul>
<h4>What comes with a deployment</h4>
When you push a post, Migro brings everything attached to it:
<ul>
<li>Post content, excerpt, slug, status, dates, notes and ping settings</li>
<li>All post meta (custom fields)</li>
<li>Categories and tags, with hierarchies preserved</li>
<li>Featured images, with smart MD5 deduplication so identical files aren’t re-uploaded</li>
<li>Embedded inline images, PDFs, videos, and other attached media</li>
<li>Image alt text, in both the Media Library and inside post content (kept in sync)</li>
<li>Author attribution (falls back to the deploying admin if the source author doesn’t exist on the destination)</li>
</ul>
<h4>Using a page builder?</h4>
Page builders like Elementor, Divi, Beaver Builder, Bricks, Oxygen, Breakdance, Droip, and WPBakery store layouts as serialized data with hardcoded URLs, which doesn’t survive a staging-to-production move without specialized handling. The free version detects page builder content in your posts and warns you before deployment, so you don’t accidentally break a destination layout. Safe page builder migration (serialized data rewriting and CSS regeneration) is part of Migro Pro.
<h4>Built for real production workflows</h4>
<ul>
<li>Two conflict modes. Overwrite (update in place, same post ID and URL) or Skip (don’t touch existing content).</li>
<li>Pre-deployment backups stored locally, retained for 30 days, restorable in one click.</li>
<li>Migration logs with full status, error messages, and configurable retention.</li>
<li>Direct database connection for reliable transfers, plus WordPress REST API authentication via Application Passwords.</li>
<li>Encrypted credentials at rest. Database passwords are encrypted before they’re saved to the options table.</li>
<li>Works with local development environments including Local by WP Engine, with custom sockets, configurable timeouts, and SSL verification toggles.</li>
<li>Available in English, Brazilian Portuguese (pt_BR), and Spanish (es_ES).</li>
</ul>
<h4>How it compares to site-migration tools</h4>
Full-site migrators are built for moving hosts: one-shot, all-or-nothing, clone everything. Migro is built for ongoing editorial deployment: pick the post, click Push, leave the rest alone.
Specifically, Migro gives you:
<ul>
<li>Single-post granularity instead of whole-site cloning</li>
<li>Bidirectional Push and Pull instead of one-way export/import</li>
<li>Sync-key tracking so re-deploying the same post updates in place instead of duplicating</li>
<li>Automatic backup before every overwrite, with one-click restore</li>
<li>No monthly cap on deployments</li>
</ul>
<h4>How it works</h4>
<ol>
<li>Install Migro on both your staging and production sites</li>
<li>Run the setup wizard to connect the two</li>
<li>Pick the posts to deploy and click Push (or Pull)</li>
<li>Review the per-item operation summary, and restore from backup if anything looks wrong</li>
</ol>
<h4>Need more?</h4>
Migro Pro adds Custom Post Types, ACF, Yoast SEO, WooCommerce, scheduled migrations, WP-CLI, full page builder migration, the Quick Migrate sidebar in Gutenberg, and AI-generated SEO metadata. The free version is fully functional on its own. No usage caps, no feature locks, no nag screens.

Migro Content Migrator

You changed one post. Why clone the whole site? Migro deploys individual posts and pages between staging and production.

SitePush vs Migro Content Migrator