あんまりやらないからビビるっていうね。
大型アップデートとかのためにやる
公開前のWEBサイトなら外部からのアクセスだけ気をつけておけば、ただ作っていけばいい。だから簡単。ちょっとした更新もアップして適用しちゃえばいい、というスタンスがある。
不祥事を恐れる大手とか、そうでなくても大掛かりな更新だと編集の干渉とかで万が一のことがあるんで、テスト環境でアップして確認してから本番環境に適用させる。
そういう理由で、テスト環境を作らなきゃということがある。
お名前.comのサーバーは便利
お名前.comのrsサーバーではテスト環境として既存のWPをコピーできる機能がある。
SSLはないけどBasic認証をつけてくれるし、システム内のドメインも書き換えてくれるから基本的に準備に手間がない。テスト環境の内容を本番環境に上書きできるので、更新作業も楽。
注意点
要するにWPの複製・上書きができるということ。複製を作るのはノーリスクだけど、上書き時にリスクが発生する。上書きしちゃうと元の状態には戻せない。編集前データを残したければログ用として複製をもう一つ作っておく必要がある。
リンクが死んでることがある
テスト環境で作ったページ（固定、カスタム問わず）があるとする。テスト環境では問題なかったのに、本番環境に適用した状態ではアクセスできないという、管理画面ではちゃんとページが作られてるのに何でよ、ということがある。
そういう場合は「設定」＞「パーマリンク設定」に行って「変更を保存」をクリック。
リンクの動作がおかしいときはこれで大体解決するし、コピー時も例外じゃない。
アップデート作業中に投稿・更新があった場合
テスト環境を本番環境に移すと、本番環境で投稿・更新した内容は消える。上書きとはそういうことで、単なるエクスポートじゃない。
だから作業中に更新したりしてないかを確認する必要がある。
カスタムフィールドとか問い合わせフォームとかのプラグイン周りをいじられてたり、テーマファイルを追加されてたりするとしんどい。テスト・本番それぞれで固定ページを作られてる場合もやばい。
片方だけが投稿・更新してる状態ならそちらに合わせたら済むので傷は浅くて済む。
投稿のエクスポート・インポート
WP純正のエクスポートは使えない。というのは画像を引っ張ってこないからで、やっていくにはプラグインを使う必要がある。カスタムフィールド関係もカバーしてたような。
インポートは基本的にWP純正のやつでいい。不思議。
準備
投稿・固定ページならすることは無いんだけど、カスタム投稿はひと手間必要。
カスタム投稿の設定にエクスポートの可否があるのでこれを有効にしなきゃいけない。
CPT UIでも同様で、初期値がFalseになってる。該当のカスタム投稿で「エクスポート可能」を「true」に変更する。
次にエクスポート用のプラグインをインストールする。
検索して出てくる有名所のものを使えば経験上問題ない。
対象を全部エクスポートするもの、期間とか属性を指定してエクスポートするもの、色々ある。
全部をエクスポートする系は記事が多いとインポート時にメチャクチャ時間が掛かる上、不可が掛かりすぎて503エラーを吐くことがある。503が出ても1回だけブラウザを再読み込みして放置すれば処理は完了した。
やっていく
プラグインの機能を使ってエクスポートする。
WPの「ツール」→「インポート」でエクスポートしたファイルを読み込む。インポートのメニューでは基本的に「Wordpress」でいいけど、エクスポートしたファイルがCSVだとCSV対応のインポーターを導入しなきゃいけない。大体はエクスポートのプラグインにインポート機能も付いてるけど、ない場合はインポート用のプラグインを入れましょう。
双方に投稿・編集があった場合
インポートすると上書きされちゃってやばい、ということがある。なので個別に移植していくしかない。期間指定でも無理みたいな詰みがある場合は手動でやっていかなきゃいけない。つらい。
マジでつらい。諦めと覚悟が必要。
手作業で移すしかない場合は手間をどれだけ削れるかがネックなわけで、作成数が少ない方を移していく。パーマリンクが手打ち設定できるならとりあえず問題ない。しかし投稿idが変わる場合があるわけで、自作テーマによってはid指定の条件分岐とか作ったりするし、本当は嫌なんだけど、そうするしかない。投稿idをurlに使ってる場合は301リダイレクトでどうにかするとか。できるのか？考えただけでもしんどい。
URLもSEOに掛かるっぽいから、ページ作成のルールとして自由入力ができるようにしたほうがいいと思います。当ブログみたいに全角対応にするとしんどいけどね。
ContactForm7も例外じゃない。問い合わせフォーム作成時にIDが生成されるわけで、同じ内容で作ってもIDが違うのでだめじゃんっていうね。使用するページで再度設定しないといけない。該当ページがわかってたらいいけど、分からなかったら日付とかでソートを掛けて絞り込んでいくしかない。
ほんとにつらい。
セキュリティ設定が地味にやばい
テスト環境に放り込んだ時に厄介なのがCORS関係。サーバー側の設定に限らず、こういうのはテーマ内のphpとか.htaccessでリソースのドメインを突っ込むわけだけど、自前のドメインもベタ打ちしなきゃいけなかったりする。つまり、テスト環境のドメインが違ってるとエラーを起こす可能性がある。テスト環境ではセキュリティ周りを外しておいて、本番環境に移した際に再度組み込んで、再度CORSのチェックをしましょう。それが無難。
まとめ
rsサーバーのテスト環境機能は移行作業自体はワンクリックで済む。だけど、それだけで問題なく動作しないことばっかりを経験してるので、作業自体はしんどい。
冒頭のリンクもそうだし、特定ページの記事内に埋め込んだ画像が存在しないとか、何故か偶にある。
環境により異なることも多いから、作業自体に慣れてもそこまで効率化できないというか、いちいちチェックをしっかりやらなきゃだから時短を求めるのはマジでやめた方がいいというか、無理ですね。
大変です。
コメント