內容簡介
SitePush 是一款 WordPress 外掛，允許您擁有多個 WordPress 網站版本，因此您可以在沒有對您的主要實時網站造成任何風險的情況下進行編輯、開發和測試。它非常適合開發人員、設計師和編輯人員，以及任何想在網站對外開放之前測試變更的人。例如：
您可以輕鬆地在網站之間移動內容。例如，在私人演示網站上進行大量編輯，然後一次性將更改推送到實時網站。或者，輕鬆地將您的現有數據庫複製到您的開發網站上，這樣您就可以根據最新內容進行開發。
測試新的佈景主題和外掛，只有當它們已配置好並按照您要求的方式正常運行時，才將它們推送到實時網站。
在私人網站上升級 WordPress、佈景主題和外掛，以便在升級您的實時網站之前進行測試，以確保不會發生任何問題。當然，您會在任何升級之前進行備份（對吧？），但是進行完整備份非常煩人，而從備份中恢復更是難上加難。
輕鬆地在您的開發網站上進行小型（和大型！）代碼更改，進行測試並輕鬆地將新代碼推送到實時網站。對於處理想要「只做一件事」的客戶非常有用。
雖然 SitePush 的安裝比典型外掛要更複雜一些，但一旦設置，它就可以輕鬆地使用，並且可以被非技術作者和編輯人員輕鬆使用。站點管理員可以輕鬆配置 SitePush，以便非管理員只能發佈內容（例如，文章/頁面、評論和上傳文件），並僅限於一組受限站點。
在安裝 SitePush 前，請閱讀安裝說明 - 它不是正常的下載並啟用型外掛。
支援
SitePush 正在積極開發，我將盡力提供修復問題的解決方法。最新的一般發布始終可通過 WordPress 外掛目錄獲得。開發代碼位於 GitHub 上，因此您可能會在那裡找到更頻繁的發布。
有關常見問題，請在 WordPress 論壇上發問，並使用標籤 sitepush。如果有錯誤報告或者您想建議修補程序或解決方案，請前往 SitePush GitHub 存儲庫。
如果您遇到任何 SitePush 問題，如果您能添加以下內容：
define('SITEPUSH_DEBUG', TRUE);
到您的 wp-config.php 文件中，並包括現在顯示在 SitePush 選項屏幕頂部的輸出，那將是非常有幫助的。
免責聲明 - 雖然 SitePush 經過了很好的測試並且在生產網站上使用，但它在不同網站之間移動文件和數據庫內容，這可能會使事情出錯。使用 SitePush 是您自己的風險！請確保您有足夠的備份，如果您發現任何問題，請報告。
路線圖
有一些可改進的領域。目前在路線圖上：
改進 push 撤銷
添加支援在不同服務器上的網站之間的推送
請告訴我們您希望 SitePush 如何發展。
伺服器設置
如何在多個虛擬主機環境中設置 SitePush
您可以在單個虛擬主機中執行您網站的不同版本，也可以在不同的虛擬主機中執行它們。對於某些網頁主機而言，在一個虛擬主機中運行它們始終比分開到不同虛擬主機中配置要容易一些，但如果不同的網站需要在您的 .htaccess 文件中進行任何不同的配置（例如，如果您正在使用緩存外掛），則會失效。
如果您能設置不同的虛擬主機（或一些網頁主機將它們稱為子域），我建議您這樣做。
假設您想擁有三個版本的網站- 描述藍色、紅色和綠色的主題。您希望在每個主題中都有您的實時站點和用於編輯和測試站點的私人站點。在每個主題中，您需要一個私人站點（用於編輯和測試），以及一個實時網站。
以下是您需要完成的步驟：
在主目錄中創建一個名為 sites 的目錄。
在 sites 目錄中，為您的網站創建三個子目錄 – blue, red 和 green。
將每個目錄中的 WordPress 安裝為普通 WordPress 安裝。
按照 SitePush 文檔中的 “定義常量” 說明為每個站點定義常量。
按照 文檔中的 “安裝主要站點和示範/原型站點” 設置您的實時和示範/原型站點。
外掛標籤
開發者團隊
原文外掛簡介
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:-
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.
test new themes and plugins, and only push them to your live site once they are configured and working as you want.
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.
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”.
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
Support
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 hosted on GitHub, 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 SitePush GitHub repository.
If you have any problems with SitePush, it would be helpful if you could add
define('SITEPUSH_DEBUG',TRUE);
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.
Roadmap
There are a number of areas which could be improved. Currently on the roadmap:-
improve push undo
add support for pushing between sites on different servers
Please let me know how you would like to see SitePush evolve.
Server Setup
How to setup SitePush in a multiple vhost environment
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:-
/var/www/vhosts/live/httpdocs
/var/www/vhosts/test/httpdocs
/var/www/vhosts/dev/httpdocs
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:-
/var/www/sitepush/config
You will also probably want to create a directory for any backups SitePush makes, such as:-
/var/www/sitepush/backups
Finally, you will need to create a database for each of your sites. Consult the WordPress installation instructions 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:-
/var/www/vhosts/live/httpdocs/wordpress
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 WordPress documentation 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 the SitePush installation instructions 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:-
cd /var/www/vhosts
cp -r live/httpdocs dev/httpdocs
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:-
cd /var/www/vhosts/dev/httpdocs/wordpress/wp-content
rmdir uploads
ln -s ../../../../live/httpdocs/wordpress/wp-content/uploads uploads
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!
How to setup SitePush in a single vhost
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:-
live.example.com
test.example.com
dev.example.com
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:-
/var/www/httpdocs/live
/var/www/httpdocs/test
/var/www/httpdocs/dev
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:-
/var/www/sitepush/config
You will also probably want to create a directory for any backups SitePush makes, such as:-
/var/www/sitepush/backups
Download WordPress and unzip it into one of the directories for your sites. For example:-
/var/www/httpdocs/live
Follow the instructions for more installing WordPress in a subdirectory.
You should also now create a database for each of your sites. Consult the WordPress installation instructions 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 the SitePush installation instructions 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:-
cd /var/www/httpdocs
cp -r live dev
cp -r live test
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:-
cd /var/www/httpdocs/dev/wp-content
rmdir uploads
ln -s ../../live/wp-content/uploads uploads
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 /* That's all, stop editing! Happy blogging. */:-
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;
}
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:-
require("./{$site_dir}/wp-blog-header.php");
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!
