他のほとんどのソフトウェアと同様に、新しいプラグイン、設定オプション、またはテンプレートの変更を別のテスト環境で試す方が安全です。 WordPressローカル開発環境 。
これについて私が見たほとんどの質問と回答はもっと単純なケースです。初期開発をローカルで行い、それからすべてをライブサイトにデプロイします。それは簡単だ。ただし、サイトのライフサイクルの途中で何らかの変更をテストする必要がある場合はどうすればよいですか?私はステップがあるべきだと思います:
私は1 + 2のやり方を知っていますが、3についてはよくわかりません。このステップは2つの部分に分けられます:
繰り返しますが、1は簡単なので、たとえばテンプレートの更新はテストから本番に簡単に移行できます。しかし2はトリッキーです。 test dbをliveにコピーすることは常に可能というわけではありません(その間に内容の変更などがあったかもしれません)、スキーマの比較も簡単な作業ではありません。理論的にはtest <-> live同期に役立つプラグインがありますが存在するかどうかわかりません。
あなたはどうやってこれに対処しますか?ヒントとテクニックや手順はありますか?
私はあなたがこれに対する何らかの包括的または簡単な答えを見つけるとは思わない。私はあなたがすでにあなたのインストールのさまざまな面を分析した方法が重要だと思います - すなわち、データベースへの変更とは異なるものとしてファイルへの変更を考えること。
私が行う変更の大部分はファイルレベルです - 例えば、CSS、フックのためのコードの追加、そのようなもの。あなたが言ったように、それらはファイルで分離されています。
データベースに影響する変更については、プラグインとして区分化される傾向があるため、どのようなステップを踏んでいるかを追跡している限り、それらを分離してデプロイまたはロールバックするのも簡単です。
あなたはデータベースの変更についてもっと心配しているように思われるので、あなたはあなたが議論したいと思う特定の変更または変更のタイプがありますか?テスト用データベースと本番データベースの両方のMySqlダンプを作成してから、ファイル差分ツールを使用して違いを見つけることを検討できます。多くの場合、これにより、おそらくデプロイメントスクリプトにパッケージ化できるいくつかのSQLコマンドを抽出できます(ただし、スクリプトを正しく実行するためには、基盤となるデータベースについてかなりの理解が必要です)。
それは逆効果に思えるかもしれませんが、変更をローカルに転送するには、通常私のローカル環境でデータベースを削除し、ライブデータベースのコピーをダンプしてからテキストエディタで開き、ライブURLを見つけて置き換えるだけです。私の地元のURL.
たとえば、私のライブサイトが http://www.awesomewidgets.com で、ローカルのテストURLが次のような場合です。 http:// localhost/awesomewidgets - "http://www.awesomewidgets.com"を検索して置換し、 "http:// localhost/awesomewidgets"にします。 「
ライブサイトにインストールした可能性のあるプラグインや、通常はwp-content/uploadsフォルダ内にある画像、ビデオ、オーディオファイルなどのアップロードファイルをコピーすることを忘れないでください(変更しない限り)。 ).