私は1箱で開発をして、生産のために2番目を使います。今はデータベースをダンプしてからURLの変更を置き換えます。次にファイルをコピーして新しいSQLをインポートします。
これを行うより良い方法はありますか?
可能であれば、WP_HOME
にWP_SITEURL
とwp-config.php
を設定します。これをデータベースのダンプとインポートと組み合わせると、私がよく知っているすべての解決策の中で最も単純なものになります。
http://codex.wordpress.org/Changing_The_Site_URL#Edit_wp-config.php
私のお気に入りのハック本番ドメインが自分のマシン上の開発用ボックスを指すように、/etc/hosts
に設定を追加します。本番環境にデプロイするには、すべてのファイルを再同期してデータベースをプッシュオーバーします。
この戦略のリスクは明らかです。開発環境と本番環境を混同する可能性があります。
それでもまだ簡単な修正です。
数ヶ月前にWPに移行したときにも同じようなものが欲しかったので、ssh上でrsyncとmysqldumpを使用する非常に単純なシェルスクリプトを書きました。
http://snarfed.org/sync_wordpress
それは洗練されたものでもWebベースでもありませんが、私はそれに満足しています。
WP Engine は、「ワンクリックステージング」を提供する新しいサービスです。
WPEngineには「ステージング」と呼ばれる独自の機能があります。その仕組みは次のとおりです。ブログに怖い変更を加える前に、「スナップショット」ボタンをクリックします。私たちはあなたのブログの完全なコピーを作成し、それを別の安全な場所に設置します。あなたはあなたが欲しいもので遊ぶことができます。何も生きていません。ライブにする準備が整ったときにだけ、メインサイトにアクセスします。
特に既に稼動しているサイトで、開発から本番にすばやく移動するための非常に簡単な方法のように見えます。
Duplicator Plugin: これは私が取り組んできたプラグインです。現在はベータ版ですが、ほとんどのサイトでその仕事は完了しています。今のところ、WordPressの小規模インストールを対象としています。 http://wordpress.org/extend/plugins/duplicator/
リソース: プラグインのための追加のリソースはここで見つけることができます: http://lifeinthegrid.com/duplicator/
コミュニティ: あなたの成功や遭遇するかもしれない問題について教えてください!さまざまなスレッドをより簡単に管理するために、WordPress.orgプラグインフォーラムに問題を投稿してください。プラグインからオンラインフォーラムにログデータを投稿しないでください。ロギングデータは弊社のサポートサイトに送信できます。
IThemesの BackUpBuddy という製品を見てください。私は2回しか使用しませんでした。毎回1〜2回ヒッチしましたが、全体的に見込みがあります。
これは有望に見えます。私たちはいくつかのスクリプトに取り組んでいます。例えば、データベース内のパスの変更、メディアのコピーなど、いくつかのデータの移行を処理しています。
私が抱えている問題は、他のサイトが開発中の間、ライブサイトは成長し続けているということです。私たちが取り組んでいる1つのサイトには、1日に20の投稿があり、1日に3,000を超えるコメントがあります。これは、phpmyadminやコマンドラインから移動するには多すぎるデータです。また、データを移動すると、何らかの理由で常にUTFの問題が発生します。
また、メニューオプションがDBに格納されているように見えたので、対処することがさらにあります。
私は自分のすべてのコードをSVNにチェックインし、サーバー(Beanstalk)からFTP経由でコードをデプロイします。これは私にとってDBに変更を加えたり、新しいプラグインを有効にしたりすることはありません。
私の現在の計画は、私が開発中にマニフェストファイルを作成してライブサイトにすべての変更を加えることです。
たとえば、ファイルには人間が読める行があります。
それは活性化するためのプラグイン、移動するためのwp-options、移動するための画像、移動するためのページを含みます。それから私のプラグインは、マニフェストファイルを検出し、ステージングサイトにすべての変更を加えるでしょう。
それをテストして、すべてが手に入ったと確信できたら、それが本番環境でうまくいくことを確信できます。
このプラグインはまだ単なるアイデアですが、私はいくつかのコードを書いています。
また、DB内のURLだけを変更したい場合は、次のSQLを使用できます。
$old$
を古いドメインに、$new$
を新しいドメインに置き換えるだけです。
update wp_postmeta set meta_value = replace(meta_value, '$old$' , '$new$') ;
update wp_posts set post_content = replace(post_content, '$old$' , '$new$') ;
update wp_options set option_value = replace(option_value, '$old$' , '$new$') ;
私は、Githubでの Autopress というプロジェクトで、この問題に個人的に対処しています。私はまだ完璧な解決策を持っていません、しかし、私は特にwpengineの人々からのwpstageプラグインで、ますます近づいています。
同様の目標を持つ2つのGoogle Summer of Codeプロジェクト。
2017年現在、WordPressデータベースの開発から運用への移行を処理するために私が見つけた2つの最良の方法がここにあります。
https://wordpress.org/plugins/wp-migrate-db/
これらのWordPressプラグインを使用すると、WordPressインストール間でデータベーステーブルをプッシュ、プル、および同期できます。以下の理由から、これはfind/replaceよりもはるかに優れています。
私は私がしている仕事の代金を支払われるのが大好きなので、Brad Touesnard氏をサポートし、本物のライセンスコピーを購入することをお勧めします。 WP Sync DBは複製であり、結果として常にサポートが遅れています。このプラグインを使えば、プロセスは簡単です。
https://interconnectit.com/products/search-and-replace-for-wordpress-databases/ /
この無料ツールはプラグインではありませんが、WordPressプロダクションインストールのルートディレクトリにインストールされています。これはWP Migrate DB Proほど手動で行う必要があるため、それほど良くありませんが、それでも一貫して機能する優れた選択肢です。この方法を使用すると、プロセスは次のようになります。
あなたはより速いアプローチを使うことができます、しかしそれは私の意見では受け入れられないあなたの生産現場のための休止時間を含みます。だから我々はそれをプロダクションと呼んでいますね。
ここでは良い解決策は不足していませんが、共有の精神の中で、私はbashデプロイスクリプトを追加することにしました: https://github.com/jplew/SyncDB
SyncDBは、ローカルとリモートのバージョンのWordpressサイトを同期させる手間を省くためのbashデプロイスクリプトです。ローカル環境(MAMPなど)で作業している開発者は、1つの端末コマンドで本番サーバーとの間で変更をすばやく「プッシュ」または「プル」できます。
このスクリプトはMark JaquithのWP-Skeletonとうまく機能し、2つの簡単なステップでサイト全体(データベース、コード、およびメディア)を同期するためにmysqldump
、git
、およびrsync
を利用します。
./syncdb
git Push hub master
私は http://wordpress.org/plugins/wp-clone-by-wp-academy/ を使っています。うまく機能します。
わずか3ステップ:
シリアル化された文字列の置き換えを含め、すべてのURLが自動的に調整されるため、ウィジェット構成などが失われる危険性はありません。
私が持っていた唯一の問題は、より大きなデータベース(〜300MB)を持ついくつかのウェブサイトに関するもので、サイトバックアップのインポート中にPHPスクリプト実行タイムアウトを引き起こしました。
Subversionのexportコマンドを使って、WordPressファイル(http://core.svn.wordpress.org/tags//)とリポジトリ内のすべてのプラグイン(http://plugins.svn.wordpress.org//tags)をインストールします。 //)その後、テーマとカスタムプラグインをZip圧縮して、通常どおりインストールします。これらすべてがコンテンツなしで起動して実行されたら、テストDBをエクスポートし、URLとファイルパス(メディア用に保存されている)を検索/置換して空のデータベースにインポートし、wp-configでデータベース情報を切り替えるだけです。 .php通常10〜20分ほどかかります。
通常私はphpMyadminにログインしてデータベースをアップロードし、wp_options> siteurlおよびwp_options> homeの内容を予想されるドメインに編集します。投稿やページのコンテンツ内のURLを更新する必要がある場合は、アップロードの前に、.SQLファイルのURLとメディア/アップロードパスを検索/置換することができます。簡単な仕事です。
私はもうしばらくbackupbuddyプラグインを使っています。それはあなたがデータベースとすべてのファイルのバックアップを作成するか、Zipとしてダウンロードするか、またはFTP経由で他のサーバーに直接それを送ることを可能にします。それはまたあなたのためにURLを見つけて置き換えます。通常、このプロセス全体を実行するのに約5分かかります。また、すべてのファイルが圧縮されているため、アップロード/ダウンロードプロセスははるかに高速です。いいえ、私は彼らのために働きませんが、このプラグインは本当にこのプロセス全体をずっと簡単にしました。
もう1つの有料ソリューション:Xtreme Oneテーマフレームワーク リリースバージョン1.2 with Xtreme Backup あなたが "できるようにすることができます/" - XMLファイル。」
私は自分のサイトをIISで運営しているので(私はasp.netを運営しているので、私はwindowsが必要です)MsftのWebPIを使って新しいインスタンスをインストールします。データ。
それは完璧ではありませんが、全体のことは1時間もかかりません。
明らかに、ワンクリックで解決するのがいいでしょうが、これが私にとって一番簡単な方法です。
_ ramp _ はCrowd Favoriteの新しいコンテンツ展開プラグインで、とても滑らかに見えます。それは250ドルだ、しかし、私はまだそれを試していない。ただし、節約された時間内にそれだけで代金を払ってもかまいません。
他のほとんどの方法に比べて大きな利点は、投稿やコメントなどをインテリジェントにマージできることです。これはmysqldumpをインポートするだけでなく、データベースのソース管理に近いものです。たとえば、投稿をデプロイするとき、プロダクションにまだ存在していない場合は、その投稿のタグもデプロイされます。
同僚がこれを見つけました。面白いコンセプトですが、クロスサーバでは動作しませんが、そのように見えます。私はまだそれを調査しています、しかしそれがステージングインスタンスのためにとてもうまくいくことができるように見えます
あなたが質問をしたときにはこれは起きていなかったかもしれませんが、私は数ヶ月間Blogvaultと呼ばれるサービスを使っていて、それは完璧にこれをしました。私はたぶん50回以上の移行(クロスドメイン、サブドメイン、そしてWebホスト)を行ったことがありますが、これは大した問題ではなく、まったく時間がかかりません。
これは有料サービスです(ドメイン/月ごと)が、それほどではありません。
これはこれまでで最も簡単な方法です: https://themes.artbees.net/docs/website-migration/
2回クリックするだけです。エクスポートするもの、インポートするものです。
All in one WP Migrationプラグインを使用することで可能です。上のリンクはその使い方を示しています。
サイトのサーバー移行を処理するためのもう1つの便利なツールはWordPress CLIです。この記事では可能なことの概要を説明していますが、特に "検索と置換"のセクションは古い/ devサイトURLへの参照をすべて見つけるのに便利です:
私のお気に入りの1つを配りましょう:-)
// proven local<->live codefork (covers local network testing, i.e. from mobile devices):
$GLOBALS['is_local'] =
in_array( $_SERVER['REMOTE_ADDR'], array("127.0.0.1","::1")) || // simple localhost (IPv4 IPv6)
$_SERVER['HTTP_Host'] == 'local.workblog' || // call by local name (adjust)
substr($_SERVER["REMOTE_ADDR"],0,8) == '192.168.'; // (mobile) device in local network
$table_prefix = NULL; // ensure scope
if ( $GLOBALS['is_local'] ) // LOCAL fork ------------------------
{
....
}
else // STAGE/LIVE fork -------------------
{
...そして、あなたはそこからあなたのやり方で働きます。 DB_NAME、DB_USER ... table_prefix。個人的にはローカルでALTERNATE_WP_CRONをオンにし( いくつかの厄介な警告を避けるために )、WP_DEBUGの両方(開発者でない場合)、またはライブ専用(あなたがいる場合)に、もう1つのini_set('display_errors', '0');
をオンにするliveは上記のように最後にantでもうまくいく可能性があります:WP_HOMEとWP_SITEURLをそれぞれのローカル/実際のURLに。
ほとんどすべて、古典的なWordPressの上には何も残っていない'これですべてです、編集をやめてください!'line ...
192.168。ローカルネットワーク内で(パッドや電話から)ローカルテストを実行できます。
$ GLOBALS ['is_local']はあなたのテーマ開発にも役立つでしょう。追加のデバッグ出力などには...
しばらくこの答えに従った後、私は自分自身の小さなプラグインを作成しました - Pitta Migration 。その理由は:
WP_HOME
およびWP_SITEURL
オプションです。wp_options
URLを設定するためにこれらを使います - プラグイン/テーマがこれらを無視する時をカバーしますあなたが継続的な同期を達成しようとしているならば、私はどんなrlcまたはサイト特有のデータも書き直すためにカスタムcronジョブと共にrsyncを使うことを勧めます。
私の意見では、私が従う最も簡単な方法は手動転送です。ただ新しいホストにwp-contentフォルダとwp-config.phpファイルをコピーするだけです。古いホストからデータベースをエクスポートし、新しいホストの新しいデータベースにインポートします。
新しいホストデータベースでwp-option tableに行き、そこでサイトURLとブログURLを古いホストから新しいホストアドレスに変更します。 http:// localhost/wp から http://example.com のように
Wp-configファイルで、新しいホスト情報でデータベースとユーザーの情報を変更するだけです。
それでは新しいwp-adminにログインして設定に行き、パーマリンクを保存してください。
これで終わりです。私はこれがプラグインを使用せずに簡単だと思います。
私はさまざまな種類のプラグインを試してみましたが、これらすべてにさまざまな問題があります。
だから私は私が思うより簡単であるこの簡単な手動転送を好む。