バリエーションはクライアント次第というところでしょうか。
Webサイトをどのように認識していて、どういう効果を上げたいのか。
検索エンジンを重要視しているのであれば、そこまでの作業にどういうスキルを使うのか理解しておいてもらわないといけないと感じてます。
また、リニューアルやコンテンツ追加の程度にもよるでしょう。
ケース・バイ・ケースでわたしの行動は異なってきます。
原稿を受け取るとローカルで作成を開始します。
そのローカルサイトを見て、確認してもらう。それから、Webサイトの方を更新日にセットするという流れです。
運用中のサイトを更新すると、その間のアクセスがメンテナンスモードになるので
ドメインの直下に、同じ内容のwpサイトを3つ作成しています。
クライアントの希望日にスイッチングするというスタイルを基本の流れとしています。
もちろんクライアントにそれを理解しておいてもらわなくてはいけません。
トピック投稿者
Kite
(@ixkaito)
digit@maetelさん
早速のご回答ありがとうございます。
ドメインの直下に、同じ内容のwpサイトを3つ作成しています。
こちらは同じDBを使うということでしょうか?
では少し具体的な運用例を挙げるとします。
トップページ、固定ページ、投稿、カスタム投稿タイプがそれぞれあるサイトがあるとします。
定期的に投稿とカスタム投稿タイプのコンテンツ追加があり、不定期に既存コンテンツの一部分のみの変更がある(例:画像の変更、一部のテキストの追加・削除など)。
サイト更新のフローとしては、必ずテスト/ステージング段階で一度Web上でクライアント確認があり(その間本番は変更前の状態で公開中)、OKが出た段階で追加&変更分を本番に反映する。
この場合、みなさんならいかがいたしますか?
こちらでは以下のような方法と問題点を考えてみました。
(A) 完全に別DBとWPのテスト環境を用意し、OKが出た段階で本番のWPで同じ作業をする。
問題点:同じ作業を2回するのは無駄、その分ヒューマンエラーの可能性が高くなる、しかもテストでOKが出たあと。
(B) 完全に別DBとWPのテスト環境を用意し、OKが出た段階でテストDBのURLを書き換え、本番にインポートする。
問題点:DBのエクスポート、URL書き換え、インポートがかなり手間。大規模なサイトとなれば、変更がないほとんどなのに、無駄にDBの上書きをすることになる。またテストの投稿時に挿入した画像なども、本番の方にも再度入れないといけない。
(C) 運用時は基本本番のWPで作業。追加コンテンツは非公開にし、クライアントにはWPにログインした状態で確認してもらう。変更するコンテンツは同じものを複製して、必要部分を変更後こちらも非公開で確認してもらう。
問題点:変更予定の既存コンテンツは変更前と変更後の両方が見れる状態。インデックス系のページの変更はこちらの方法では対応できないので、本番で直接変更、もしくはリンクがつながっていないページを個別に用意、もしくはテンプレートファイル内で直接テストと本番の内容を分岐する必要がある。
(D) カスタムフィールドを応用して、ひとつの投稿内に本番とテストの両方を記述できるようにし、テストに記述があれば、WPにログイン中はこちらの内容を表示。
問題点:システム構築に時間がかかる。最終的にはやはり記事内ではあるが、テストの内容を本番に貼り付ける必要がある、ただし(A)よりはヒューマンエラーの確率はかなり減ると思われます。
理想にわりと近いのは(D)かなと思っておりますが、もしもっといいやり方やアイデアなどございましたら、是非お聞かせください。よろしくお願いいたします。
こんなプラグインもありますよ。
http://www.kakunin-pl.us/2012/05/20/wp-post-branche/
個人的な感想としては、WordPressはそういうワークフローの構築には向きません。
私も WordPress 以外を検討する事をお勧めしますが、WP でやるなら、
(A)パターン
リモート投稿(xmlrpc)を使えば、(A)パターンでもかなり楽になるかもしれません。
手元の端末で記事本文や画像を保持しているので、
1. まずテストサイトへ送信
2. OK が出たら本番へ送信
でできます。2度作業するのは、送信だけです。
ナビゲーションメニューも更新したい、とかだとxmlrpcで作業するのは大変かもしれないですが。
(システム内部ではナビゲーションメニューはカスタム投稿なので、無理矢理やればできるだろう、とは思います)
(B)パターン
シェルスクリプト書いておけば、ほぼ自動化できますね。
むしろ
「テスト用のDBで単純に上書きすると、コメントや問い合わせ等が消えてしまう」
のほうが問題かもしれません。
(C), (D) はixkaitoさんとほぼ同じ印象です。問題点に妥協できれば採用、でしょうか。
トピック投稿者
Kite
(@ixkaito)
Takuro Hishikawa さん
ご回答ありがとうございます。
こういうプラグインもあるんですね。詳しく見てみたいと思います。
Fumito MIZUNO さん
いろいろアイデアとアドバイスありがとうございます。
(A)パターン
リモート投稿(xmlrpc)を使えば、(A)パターンでもかなり楽になるかもしれません。
こちらであれば結構ありかもしれません。
細かいところでの二重作業は妥協できる範囲かなと思います。
(B)パターン
シェルスクリプト書いておけば、ほぼ自動化できますね。
こちらについてもう少し詳しく教えていただけますでしょうか。
もしくは参考になるサイトでもかまいません。
実はかなり気になっていたんですが、詳しく紹介しているところをなかなか見つけられなくて。
「テスト用のDBで単純に上書きすると、コメントや問い合わせ等が消えてしまう」
のほうが問題かもしれません。
確かそうですね、コメントと問い合わせを利用しないサイトの予定でしたので、考えておりませんでしたが、テスト中に本番DBに変更があるサイトの場合は問題がありますね。
データベースに関しては、
http://www.rescuework.jp/blog/wordpress-backup.html
http://open-groove.net/mysql/shell-and-mysql/
あたりを読めば書いてありますね。(シェルとMySQLコマンドは前提ですが)
作業としては、バックアップ=>リストアなので、
自動化しているウェブ制作会社は多いのではないかな、と思います。
ただ、テストサイトと本番サイトのURLが異なる場合は、
データベースのデータの置換が必要になりますね。
http://dogmap.jp/2012/09/20/wordpress-replace-siteurl/
あとは画像等ですが、wp-contentフォルダ以下にあるので、
テストサイトから本番へコピーしてあげれば良いでしょう。
コメントや問い合わせを利用しないサイトであれば、確認環境でのみWordPressを動作させて、確認が取れたら静的ファイルを吐き出し、公開環境へは静的ファイルを転送するという手段もありますね。
http://staticpress.net/
トピック投稿者
Kite
(@ixkaito)
Fumito MIZUNO さん
参考サイトありがとうございます!
こちらを参考にして是非試してみたいと思います。
Takuro Hishikawa さん
再度アイデアいただきありがとうございます。
実はこちらの方法を一度検討したんですが、検索機能が必要でしたので、断念しました。