すでにWordPressを使用してサイトが公開され、運用フェーズに入ったとき、
公開されている投稿データの一部内容を変更したいという要望は多いです。
その投稿を非公開状態にできるのであれば、一度非公開にして内容を修正したあと、公開に戻せばOKでしょう。
ただ、「記事は公開したままで、変更内容は時が来たときにしか表に見せたくない」という要望の場合は少し考えなければいけません。
そのようなケースの場合、どのように対応するのがいいのかについて解説します。
WordPress標準のエクスポート・インポート機能を使う場合はケースが限られる
WordPressに標準搭載のエクスポート・インポート機能があります。
これをつかうと簡単に記事データを移行できます。
ただし、利用ケースが限られます。
使うといいケース
これを使うケースは、移行先に投稿データが全くない状態のときです。
つまり、以下のようなイメージです。
上記のイメージは、カスタム投稿HOGEを本番環境に新設し、そこに、テスト環境の投稿データを移行するケースです。
移行先の本番環境にはカスタム投稿HOGEに関する投稿データが一切ないというのがポイントです。
ちなみに、WordPress標準のエクスポート・インポート機能だと、アイキャッチ画像などの画像データは移行されません。
そのため、画像も一緒に移行したい場合はExport media with selected contentを使用します。
ただし、移行元でベーシック認証がかかっている状態だと、このプラグインを使用したとしても移行先で画像が紐づかないので、一時的にベーシック認証を解除する必要があります。
使わない方がいいケース
逆にこの機能を使わない方がいいケースがあります。
それが以下のようなケースです。
つまり、移行先の本番環境にすでにカスタム投稿HOGEに紐づく投稿データが存在するケースです。
ここに、テスト環境で作成した投稿データDを、WordPress標準のエクスポート・インポート機能を使って移行すると、移行先の投稿データABCにも影響が出る可能性があります。
※正確には、影響がでるときと出ないときがあります。その違いはよくわかってません。
この、WordPress標準のエクスポート・インポート機能の特徴は、投稿の名前が違うと別の投稿として判定され、移行先では新規投稿として追加されることです。
つまり、同じ名前の投稿は基本的にスキップされて上書きされません。
しかし何故か、条件は不明ですが、スキップされているはずなのにスキップ対象のデータの一部が変わっている事象がありました。
そのため、この標準機能を使うときは本番環境に投稿データが無いまっさらな状態がいいと思われます。
※すでに本番環境にある投稿データを全部削除して移行すればうまくいきますが、ゴミ箱に投稿データがあってもダメなので、完全に削除しないといけません。これはかなり怖いのでお勧めしないです。
本番環境で投稿データを非公開にできるのであれば、本番環境で直接投稿データを作成して更新作業などし、対応完了したら非公開から公開にステータスを変えるのが普通です！
【ここから本題】より確実で安全な移行方法
ここからが本題です。
すでに本番環境に投稿データがあり、そのデータの一部内容を変更したいとします。ただし、変更している間に記事は非公開にできず、公開したままという条件つきです。
つまり、以下のようなケースです。
「内容を変更」とは例えば、カスタムフィールドの値を全投稿一律に変更したいとしましょう。
方法①安全度 MAX
この場合(カスタムフィールドの値を全投稿一律に変更したい場合)は、本番環境で新たにカスタムフィールドを作成し、そこに新しいデータを入れ、出力内容をphp側で切り替えるという方法が一番安全です。
もともとあったカスタムフィールドのkey名がhogeだとしたら、新たに「hoge_new」を作成するイメージです。
そして、公開日時になったらphpファイル側でhoge_newの値を出力するようにして切り替えればOKです。
切り替えが完了したら、もともとあったhogeのカスタムフィールドは削除しておきましょう。
これが最も影響範囲が少なく、安全な方法です。
次に、少し影響範囲が大きいものの、方法①では対応できないケースの場合の対応方法について解説します。
方法②安全度 中
2つ目の方法は1つ目の方法では対応できないときに有効です。
例えば、カスタムフィールドの値ではなく、もっと複雑な変更内容のときでしょうか。
この場合は、1度本番環境とまったく同じ状態をテスト環境に移行し、テスト環境で更新作業を行った後、今度はテスト環境とまったく同じ状態を本番環境に移行する方法です。
ことばだけだとわかりずらいので、順を追って説明します。
まず、本番環境をテスト環境に移行します。
All in One WP Migrationを使って行うと早いと思います。
移行したら、テスト環境で更新作業を行います。
その後、再びAll in One WP Migrationを使うなどして、テスト環境を本番環境に移行します。
これで完了です。
ただし、All in One WP Migrationは更新した部分だけでなく、他のデータ全てもごっそり置き替えます。
なので、影響範囲がとても大きく怖いというのがデメリットです。
テスト環境から本番環境に移行する際には、必ず本番環境でバックアップを作成して実施するようにしましょう。
また、この方法にはもう１つ注意点があります。
それは、テスト環境で更新作業を行っている間に、本番環境で何かしらの更新作業があった場合は、その更新作業をテスト環境にも同様に反映する必要があります。
これについては手間ですが、手動で反映するのがいいかと思います。
この作業をしないと、All in One WP Migrationでテスト環境のデータを移行したときに、本番環境がテスト環境の状態とまったく同じになるため、本番環境の更新作業が全部消えます。
なので、お客さんに「更新作業中は本番環境のデータ更新を行わないでください。」とお伝えするか、
「更新した場合はテスト環境にも反映する必要があるのでお知らせください。」とお伝えするかが必要になってきます。
また、サイトにお問い合わせフォームがある場合は注意です。
テスト環境で更新作業中に、本番環境に届いたお問い合わせのデータは、当然テスト環境には届きません。
そのため、テスト環境からAll in One WP Migrationで移行したときに、本番環境に届いていたお問い合わせのデータは消えるので注意してください。
お問い合わせデータから顧客リストをまとめて何か施策しているサイトなどが気にしなきゃいけないポイントですね。
このように、方法②はとにかく手間が増えるので見積も少し高くなるイメージですね。
まとめ
WordPressが運用フェーズに入った時の更新作業は結構神経使いますよね。。
これ以外もそうですが、すでに公開されているサイトの更新を行うときは、何かあったときにすぐに戻せるようにバックアップを必ず取ることを忘れないようにしましょう。
