私は1つのボックスで開発を行い、2番目のボックスを生産に使用します。現時点では、データベースをダンプしてから、URLの変更の検索を行います。次に、ファイルをコピーして、新しいSQLをインポートします。
これを行うより良い方法はありますか?
私は1つのボックスで開発を行い、2番目のボックスを生産に使用します。現時点では、データベースをダンプしてから、URLの変更の検索を行います。次に、ファイルをコピーして、新しいSQLをインポートします。
これを行うより良い方法はありますか?
回答:
@ Insanity5902:あるボックスから別のボックスへのWordPressサイトの展開は、WordPressを使い始めた初日からPITAでした。(真実は、WordPressを使い始める前に2年間Drupalを使ったPITAだったので、問題はWordPressだけではありません。)
サイトを移動する必要があるたびに、多くの場合、重複した努力を費やさなければならず、希望する頻度でテストにデプロイすることを妨げました。だから4-6ヶ月前にウェブホスト移行の問題を解決するプラグインに取り組み始め、WP Tavernフォーラムで自分のアイデアに言及しました。
今日に早送りして、私はそれをほとんどうまく動かしました、そして、私はそれを便利に「WP Migrate Webhosts」と呼びます。プラグインはまだ非常にベータ版(おそらくアルファ版)ですが、あなたの質問を考えれば、人々がそれを強打し始める準備ができていると思います。
想定されるユースケースは次のとおりです。
私のウェブサイトからプラグインをダウンロードして、プラグインディレクトリに解凍できます(これを行う方法がわからない場合、このプラグインは使用するために何をしているかを知っている人を必要とするため、あなたには向いていません)。このプラグインをWordPress.orgにリリースするまでオンラインのままにしてください。その後、そこでプラグインを探す必要があります。
これを使用するには、あなたの中に異なるアプローチを取るwp-config.php
コメントアウトすることにより、その通常の4(4)を定義しDB_NAME
、DB_USER
、DB_PASSWORD
とDB_HOST
し、代わりに登録するウェブホストのデフォルトをして、各ウェブホスト自体に関する情報を登録します。そのセグメントはwp-config.php
次のようになります(最初のセクションは不要なコードがコメント化されていることに注意してください.dev
。また、日々の開発を容易にするために、ルーティングできないトップレベルドメインを使用してローカルマシンにホストファイルを設定しています。 Macでは、VirtualHostXがこれを簡単にします):
// ** MySQL settings - You can get this info from your web host ** //
/** The name of the database for WordPress */
//define('DB_NAME', 'wp30');
/** MySQL database username */
//define('DB_USER', 'wp30_anon');
/** MySQL database password */
//define('DB_PASSWORD', '12345');
/** MySQL hostname */
//define('DB_HOST', '127.0.0.1:3306');
require_once(ABSPATH . 'wp-content/plugins/wp-migrate-webhosts/wp-webhosts.php');
register_webhost_defaults(array(
'database' => 'example_db',
'user' => 'example_user',
'password' => '12345',
'host' => 'localhost',
'sitepath' => '', // '' if WordPress is installed in the root
));
register_webhost('dev',array(
'name' => 'Example Local Development',
'host' => '127.0.0.1:3306',
'domain' => 'example.dev',
'rootdir' => '/Users/mikeschinkel/Sites/example/trunk',
));
register_webhost('test',array(
'name' => 'Example Test Server',
'rootdir' => '/home/example/public_html/test',
'domain' => 'test.example.com',
));
register_webhost('stage',array(
'name' => 'Example Staging Server',
'rootdir' => '/home/example/public_html/stage',
'domain' => 'stage.example.com',
));
register_webhost('live',array(
'name' => 'Example Live Site',
'rootdir' => '/home/example/public_html/',
'password' => '%asd59kar12*fr',
'domain' => 'www.example.com',
));
require_once(ABSPATH . 'wp-content/plugins/wp-migrate-webhosts/set-webhost.php');
うまくいけば、これは(ほとんど)自明です。コードをできる限りきれいにしようとしましたが、残念ながら、WordPress が呼び出される前require_once()
に「フック」する方法がなかったため、ウェブホスト登録コードのブロックの前後に2つの不可解な行が必要wp-config.php
です。
更新したらwp-config.php
、URLショートカットwp-migrate-webhosts
を使用して、次のように管理画面に移動できます。
上記の説明テキストの公平なビットを持っており、あなたが移行することができます、次のような管理画面が表示されますFROM(から移行するドメインを選択した後、シングルクリックで他のウェブホストドメインのいずれか注:この例では、予定を示しDOWN地域開発が、残りのテスト/ステージ/ライブサーバから、それは移行でき安心TO配置されるように起こるすべてのドメイン。また、これは意味プラグインは、既存のライブサイトを取り、迅速にローカルの開発環境ワーキングを取得するための素晴らしいことでしょう!):
明確でない場合、このコンテキストでの「移行」は、現在定義されているウェブホストに適切なように現在のデータベース内のすべての参照を更新することを意味します(そして「現在」は検査によって探知され$_SERVER['SERVER_NAME']
ます)
プラグインの素晴らしい点は、いくつかの基本的な移行を実装することですが、誰でもそれをフックして独自の移行を実行できます。あなたは、データベース内の画像への完全なパスを格納し、ギャラリーのプラグインを追加した場合たとえば、あなたはフックができmigrate_webhosts
、「渡されるアクションから」ウェブホストをして「へのメタデータの配列として、それぞれを」ウェブホストを、あなたが許可されますSQLまたは適切なWordPress API関数を使用して移行を行うために、データベースで必要なことをすべて実行します。はい、私たちの誰もがプラグインなしでこれを行うことができますが、プラグインなしでは、必要なすべてのコードを書くことはそれが価値がある以上の努力であることがわかりました。プラグインを使用すると、これらの小さなフックを作成して、簡単に処理できます。
また、テストしていないエッジケースで移行が失敗する場合があります。プラグインの改善にご協力いただけますか。Gmailアカウント経由でメールを送信したい人は誰でも(エイリアスは「mikeschinkel」です)
また、プラグインは、それは次のように認識したものに加えて、ユーザー定義のウェブホストのメタデータを受け入れるように設計されたdatabase
、user
、password
、host
、domain
完璧な例があるかもしれないなどgooglemaps_apikey
、あなたがそのあなたのGoogleマップのプラグインのニーズドメインごとに異なるAPIキーを格納できる場所(Google Mapsプラグインを使用したことがある人がアプリをライブサーバーにデプロイせず、コードを正しいAPIキーに変更するのを忘れていませんか?正直言って...)googlemaps_apikey
あなたのregister_webhostの要素()アレイと、小さなカスタムmigrate_webhosts
あなたが効果的に懸念としてそれを排除することができますフック!
まあそれはそれについてです。@ Insanity5902の質問がトリガーになったため、ここでこのプラグインをWordPress AnswerのExchangeで起動しています。役立つかどうかをお知らせください。適切な場合はこちら、そうでない場合はメールでお問い合わせください。
PSこれを使用することにした場合、それはアルファ/ベータであることを覚えておいてください。つまり、今すぐ使用したい場合はマイナーな手術の準備ができているので、多くの手で叩かれたらリリースされたバージョンを使用してください。
PPSこれでの私の目標は何ですか?誰もがアクセスできるように、これがWordPressコアに移行するのを楽しみにしています。しかし、それが考慮される前に、多くの人々がそれを実際にそれが潜在的に作成することができるより多くの問題を解決することを確実にするためにそれを使用することに興味を持たなければなりません。そのため、このアイデアが気に入った場合は、ぜひそれを使用して、WordPressコアに最終的に希望を持たせるためのモメンタムを獲得してください。
可能な場合、私は設定WP_HOME
してWP_SITEURL
の中でwp-config.php
。これは、データベースのダンプとインポートと組み合わせて、私が精通しているすべてのソリューションの中で最も単純です。
http://codex.wordpress.org/Changing_The_Site_URL#Edit_wp-config.php
私のお気に入りのハック。設定をに追加/etc/hosts
して、本番ドメインがマシン上の開発ボックスを指すようにします。本番環境にデプロイするには、すべてのファイルをrsyncし、データベースをプッシュします。
この戦略のリスクは明らかです。開発環境と運用環境を混同する可能性があります。
それでも簡単に修正できます。
数か月前にWPに移行したときに似たようなものが欲しかったので、sshでrsyncとmysqldumpを使用する非常にシンプルなシェルスクリプトを作成しました。
http://snarfed.org/sync_wordpress
洗練されたものでもウェブベースのものでもありませんが、満足しています。
WP Engineは、「ワンクリックステージング」を提供する新しいサービスです。
WPEngineには、「ステージング」と呼ばれる独自の機能があります。仕組みは次のとおりです。ブログに恐ろしい変更を加える前に、「スナップショット」ボタンをクリックします。ブログの完全なコピーを作成し、別の安全な場所に設定します。好きなもので遊ぶことができます。ライブはありません。ライブサイトを公開する準備ができた場合にのみ、メインサイトにアクセスします。
特にすでに稼働しているサイトでは、開発から本番にすばやく移行するための非常に簡単な方法のように見えます。
Duplicator Plugin: 私が取り組んでいるプラグインは次のとおりです。現在ベータ版ですが、ほとんどのサイトで仕事が完了しています。現在、小規模なWordPressインストールを対象としています。 http://wordpress.org/extend/plugins/duplicator/
リソース: プラグインの追加リソースは、http://lifeinthegrid.com/duplicator/にあります。
コミュニティ: あなたの成功またはあなたが遭遇するかもしれない問題について私たちに知らせてください!さまざまなスレッドをより簡単に管理するために、WordPress.orgプラグインフォーラムに問題を投稿してください。プラグインのログデータをオンラインフォーラムに投稿しないでください。ロギングデータは、サポートサイトに送信できます。
私は個人的に呼ばれ、GitHubの上の私のプロジェクトでこの問題に対処していますAutopress。完璧な解決策はまだありませんが、特にwpengineのwpstageプラグインを使って、近づいています。
これは有望に見えます。私たちは、いくつかのデータの移行を処理するスクリプトに取り組んでいます。たとえば、dbのパスの変更、メディアのコピーなど、wp-optionsです。
私が抱えている問題は、ライブサイトが成長し続けている間、他のサイトが開発中であるということです。私たちが取り組んでいるサイトには、1日に20の投稿があり、1日あたり3,000を超えるコメントがあります。phpmyadminまたはコマンドラインを使用して移動するには、データが多すぎます。また、データを移動すると、何らかの理由で常にUTF問題が発生します。
また、メニューオプションがDBに格納されているようになったので、さらに対処する必要があります。
すべてのコードをSVNにチェックインし、サーバー(Beanstalk)からFTP経由でコードをデプロイします。ただし、これによってDBが変更されたり、新しいプラグインがアクティブになったりすることはありません。
私の現在の計画は、ライブサイトに対するすべての変更を行うために開発中にマニフェストファイルを作成することです。
たとえば、ファイルには人間が読める行があります
有効にするプラグイン、移動するwpオプション、移動する画像、移動するページが含まれます。次に、プラグインがマニフェストファイルを検出し、ステージングサイトにすべての変更を加えます。
それをテストし、すべてを手に入れたと確信したら、それが実稼働で動作することを確信できました。
このプラグインはまだアイデアにすぎませんが、いくつかのコードが書かれています。
また、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$') ;
Subversionのエクスポートコマンドを使用して、WordPressファイル(http://core.svn.wordpress.org/tags//)とリポジトリ内のすべてのプラグイン(http://plugins.svn.wordpress.org//tags)をインストールします。 //)、テーマとカスタムプラグインを圧縮して通常どおりインストールします。すべてがコンテンツなしで実行されると、テストDBをエクスポートし、URLとファイルパス(メディア用に保存)の検索/置換を実行して空のデータベースにインポートし、wp-configでデータベース情報を切り替えるだけです。 .php。通常、約10〜20分かかります。
ここには良い解決策が不足しているわけではありませんが、共有の精神で、私は自分のbashデプロイスクリプトを山に追加すると思いました:https : //github.com/jplew/SyncDB
SyncDBは、Wordpressサイトのローカルバージョンとリモートバージョンの同期から退屈をなくすためのbashデプロイスクリプトです。ローカル環境(MAMPなど)で作業している開発者は、1つのターミナルコマンドを使用して、本番サーバーとの間で変更を迅速に「プッシュ」または「プル」できます。
このスクリプトは、Mark JaquithのWP-Skeleton、ハーネスmysqldump
、git
およびrsync
サイト全体(データベース、コード、メディア)を2つの簡単なステップで同期するのに適しています。
./syncdb
git push hub master
私はhttp://wordpress.org/plugins/wp-clone-by-wp-academy/を使用しています。うまくいきます!
わずか3ステップ:
シリアル化された文字列置換を含むすべてのURLを自動的に調整するため、ウィジェットの構成などを失うリスクはありません。
私が経験した唯一の問題は、より大きなデータベース(〜300MB)を備えたいくつかのWebサイトで、サイトバックアップのインポート中にPHPスクリプトの実行タイムアウトが発生したことです。
2017年の時点で、開発から本番へのWordPressデータベースの転送を処理するために見つけた2つの最良の方法があります。
https://wordpress.org/plugins/wp-migrate-db/
これらのWordPressプラグインを使用すると、WordPressインストール間でデータベーステーブルをプッシュ、プル、および同期できます。これは、次の理由により、多くの理由で検索/置換よりもはるかに優れています。
私は自分の仕事の代金を支払われるのが好きなので、ブラッド・トゥエスナード氏を支援し、本物のライセンスコピーを購入することをお勧めします。WP Sync DBはレプリケートであり、結果として常にサポートが遅れています。このプラグインを使用すると、プロセスは非常に簡単です。
https://interconnectit.com/products/search-and-replace-for-wordpress-databases/
この無料のツールはプラグインではありませんが、WordPressのプロダクションインストールのルートディレクトリにインストールされます。これはWP Migrate DB Proほど良いものではありませんが、それはいくつかの手動ステップを必要としますが、それでも一貫して機能する素晴らしいオプションです。このアプローチを使用する場合、プロセスは次のようになります。
より高速なアプローチを使用することもできますが、実稼働サイトのダウンタイムが発生するため、私には受け入れられません。それがプロダクションと呼ばれる理由ですよね?
別の有料ソリューション:Xtreme Oneテーマフレームワークは、Xtremeバックアップを備えたバージョン1.2をリリースしました。これにより、「チャイルドテーマ、レイアウト、またはウィジェットの設定をすべての設定/コンテンツとともにXMLファイルとしてエクスポートまたはインポート」できます。
同僚がこれを見つけました。興味深い概念ですが、クロスサーバーでは機能しませんが、次のように見えます。まだ調査中ですが、ステージングインスタンスに最適です。
RAMPはCrowd Favoriteの新しいコンテンツ展開プラグインであり、とても滑らかに見えます。ただし、250ドルなので、まだ試していません。ただし、節約された時間の分だけ自己負担になる可能性があるため、検討しています。
記載されている他のほとんどの方法と比べて大きな利点は、投稿、コメントなどをインテリジェントにマージできることです。mysqldumpをインポートするだけでなく、データベースのソース管理に似ています。たとえば、投稿をデプロイするときに、本番用のタグがまだ存在しない場合、その投稿のタグもデプロイします。
私のお気に入りの一つをあげさせてください:-)
// 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(あなたが開発者でない場合)、ライブだけで(あなたがしている場合)、別のini_set('display_errors', '0');
ライブのためにも最後に良い、アリを行うことができ、上記のとおり:WP_HOMEおよびWP_SITEURLをそれぞれのローカル/実際のURLに。
ほぼすべて、古典的なWordPress の上に何も残っていません。ライン...
192.168。一部を使用すると、ローカルネットワーク内でローカルテスト(パッドや電話など)を実行できます)
$ GLOBALS ['is_local']は、追加のデバッグ出力などのために、テーマ開発でも役立ちます。
WP_LOCAL_DEV
定数を設定して同様の何かを達成することができます
サイトのサーバー移行を処理するためのもう1つの便利なツールはWordPress CLIです。この記事では何ができるかについて概要を説明していますが、特に「検索と置換」のセクションは古い/ devサイトURLへのすべての参照を見つけるのに役立ちます:
これが最も簡単な方法です:https :
//themes.artbees.net/docs/website-migration/
2回クリックするだけです。1つはエクスポート、もう1つはインポートです。
1つのWP移行プラグインですべてを使用することで可能です。上記のリンクは、その使用方法を示しています。
しばらくこの回答を読んだ後、私は自分の小さなプラグインPitta Migrationを作成しました。理由は:
WP_HOME
and WP_SITEURL
オプションですwp_options
URL を設定します-プラグイン/テーマがこれらを無視する場合をカバーします私の意見では、私が従う最も簡単な方法は手動転送です。wp-contentフォルダーとwp-config.phpファイルを新しいホストにコピーするだけです。古いホストからデータベースをエクスポートし、新しいホストの新しいデータベースにインポートします。
新しいホストデータベースでwp-optionテーブルに移動し、サイトのURLとブログのURLを古いホストの新しいホストアドレスに変更します。等からののhttp:// localhost /をWPにhttp://example.com
これで、wp-configファイルで、データベースとユーザーの情報を新しいホスト情報で変更するだけです。
新しいwp-adminにログインし、設定に移動してパーマリンクを保存します。
できました。これはプラグインを使用せずに簡単だと思います。
私はさまざまな種類のプラグインを試しましたが、これらすべてに多くの種類の問題があります。
ですから、この簡単な手動転送の方が好きです。