WordPress のステージングサイトを立ち上げるのは、かつては仕事の中でも厄介な部分でした。サブドメインを用意し、データベースをコピーし、ファイルを同期し、検索・置換を直し、wp-config.php で何も吹き飛ばないことを祈る。WP Staging Pro はそのすべてをワンクリックのクローンにまとめ上げ、ほとんどの制作会社のワークフローにとって、ステージングの問題は実質的に解決されました。
問題は、ステージングプラグインがどんどん速くなっているのに、ステージングワークフローはどんどん重くなり続けていることです。そして犯人はほぼ必ず同じフォルダー、wp-content/uploads です。
私は毎週、多くの制作会社やプラグインチームと仕事をしています。パターンはどこでもほぼ同じです。サイトはこぢんまりとした 2 GB で立ち上がります。8 年後には、作られた日以来誰も触っていない wp-content/uploads/2018/02/ のサブフォルダーを抱えた 60 GB の怪物になっています。ステージングプラグインは今も動きます。クローンも今も完了します。ただ、必要以上にずっと時間がかかり、ディスクをごっそり食い、ワンクリックのワークフローを静かにコーヒーブレイクに変えてしまうのです。
これが隠れたコストです。そして、これは直す価値があります。なぜなら、その解決策は一度見てしまえば正直かなり退屈なものだからです。
なぜ wp-content/uploads は誰も語らないステージングの税金なのか
平均的な WordPress インストールが内部で実際にどう見えるかを示します。コアはせいぜい 50 MB。プラグインとテーマを合わせても、てんこ盛りの制作会社向けビルドでさえ 500 MB を超えることはまれです。コンテンツの多いサイトのデータベースは、高くても 200〜400 MB ほどでしょう。
そして wp-content/uploads があります。5 年もののWooCommerce サイトでは、このフォルダーは簡単に 20〜50 GB になります。メディアの多い出版サイトや会員制サイトでは、100 GB 超も珍しくありません。私は、uploads が WordPress 全体のフットプリントの 98 % を占めるクライアントサイトを見たことがあります。残りの 2 % が、デプロイのたびに実際に変わるすべてです。
ステージングプラグインはそのすべてに対処しなければなりません。WP Staging Pro が完璧に仕事をこなし、データベースを数秒でコピーし、除外フォルダーを外科手術のような精度でスキップしているときでさえ、クライアントレビュー用にサイト全体をクローンするよう指示した瞬間、あなたはサーバーに 2019 年のすべての JPEG を複製するよう求めているのです。
これは 4 つの現実的なコストとして現れます。
- ディスク容量。 60 GB のサイトをステージングのサブドメインにクローンすると、ディスク上では 120 GB になります。ステージング環境が 2 つ？ 180 GB です。ほとんどの共有ホスト、さらにはマネージドホストでも、それに対して非常に高い料金を請求します。
- クローン時間。 データベースのコピーは速い。ファイルのコピーはサーバーの I/O によって制限されます。60 GB の uploads フォルダーは、プラグインがどれだけ優秀でも 60 GB の I/O ジョブです。
- バックアップの重さ。 ステージングサイトのバックアップを取るたびに、これまでアップロードしたすべての画像が再びアーカイブされます。クラウドの保存先に保管すれば、それは高くつきます。
- 認知的負担。 「今はステージングサイトをクローンしないで、バックアップが終わるのを待っているから」というのは、私が一緒に働いたあらゆる制作会社で、何らかの形で聞いたことのある言葉です。
これらはどれも WP Staging Pro のせいではありません。これはステージングの仮面をかぶったメディアライブラリの問題です。
WP Staging Pro が実際に見事にこなすこと
メディアの話をする前に、WP Staging Pro が何に優れているかを正直に語る価値があります。なぜなら、この記事の趣旨は「ステージングプラグインは遅い」ではないからです——遅くありません、現代のものは見事です。趣旨は、遅い部分が移動したということです。
WP Staging Pro はステージングの難しい部分をほとんど大騒ぎせずに処理します。
- データベースのクローン（選択的なテーブルサポート付き）。これは正直、かつてすべてを壊していたステージングの部分です。テーブルは正しいプレフィックスの書き換えとともにコピーされ、シリアライズされたデータも正しく扱われます。
- ワンクリックのサイトクローンをサブディレクトリまたはサブドメインへ。ユーザー認証付きなので、ステージングのコピーが誤ってインデックスされたりアクセスされたりしません。
- プラグインとテーマの同期をステージングと本番の間で。制作会社はプラグインの更新を切り離してテストし、クライアントの編集を吹き飛ばさずに動作するバージョンを戻せます。
- クラウド保存先付きのバックアップ。Google Drive、Amazon S3、Dropbox、OneDrive、Wasabi、pCloud、DigitalOcean Spaces、汎用の S3 互換ストレージ、SFTP に対応。これはほとんどの人が過小評価する部分です。S3 へのスケジュール化されたバックアップパイプラインは、まさにエンタープライズ級の機能です。
- 鉄壁の復元。必要になる日まで、ありがたみが分からない機能です。バックアップは、そこから復元できる分だけの価値しかありません。WP Staging Pro は、WordPress 自体が壊れて wp-admin にログインできないときでさえ、きれいに復元します。WordPress のインストールから独立して動作するスタンドアロンの復元ツールがあり、まさにすべてがおかしくなった状況のためのものです。サイトが午前 2 時にダウンしたら、あなたをオンラインに戻すのはこの機能です。
- マルチサイト対応。歴史的に、他のあらゆるステージングツールが静かに崩れ落ちてきたところです。
- サイト移行（ホストとドメインの間で）。検索・置換は自動で処理されます。
このプラグインは 50 GB 超のインストールを含むあらゆる規模のサイト向けに作られており、PHP のタイムアウトを避けるために操作をどうチャンク化しているかを掘り下げると、そのアーキテクチャは実に見事です。データベース、プラグインフォルダー、テーマフォルダーの中にあるすべてについては、これは解決済みの問題です。
会話が面白くなるのは wp-content/uploads フォルダーです。
なぜ「uploads フォルダーを除外すればいい」は本当の答えではないのか
当然の一手は、クローン中に wp-content/uploads をスキップするよう WP Staging Pro に指示することです。プラグインはそれを許可しており、一部のワークフローではそれが正解です。
ほとんどのワークフローでは違います。理由はこうです。
ステージングサイトに本番のメディアがなければ、プレビューするすべてのページが壊れて見えます。トップページのヒーロー画像はプレースホルダー。WooCommerce の製品ギャラリーは 404。アイキャッチ画像は表示されません。ステージングの本質は本番が見ているものを見ることであり、メディアのないステージングサイトでは、変更を自信を持って承認できません。
一部のチームは、ステージングクローンと並行して走る NFS マウント、シンボリックリンク、rsync ジョブで回避します。これらは機能します。同時に、脆く、ホスト依存で、ステージングプラグインがなくすために作られたまさにその種の手作業の設定を再び持ち込みます。
ステージングのコピーをいくつ立ち上げても機能し、ホストレベルのスクリプティングを必要としない、よりすっきりした答えがあります。
メディアを WordPress から完全に外へ移す
問題を本当に解決する転換は、WordPress のメディアをサイトの一部として扱うのをやめることです。クラウドのオブジェクトストレージに移し、CDN 経由で配信し、WordPress にはファイルではなくポインターを保持させます。
これが Infinite Uploads の役割です。メディアライブラリ内のすべての画像、動画、ファイルをホスティングサーバーからクラウドへ移し、そのうえで、サイトが世界中のサーバーから訪問者に超高速で配信し続けられるようにします。書類棚をオフィスから顧客に近い倉庫へ移すようなものだと考えてください。ファイルはあなたのものです。ただホスティングサーバー上に住まなくなるだけで、それによってサイトは軽く、速く、バックアップがずっと安くなります。
サイトの日常運用については、結果として WordPress は変わりません。編集者はこれまでどおり画像をアップロードします。メディアライブラリは普通に見えます。URL は機能します。書き換えはデータベースレベルで処理され、古い URL は保持されるため、SEO は壊れません。
ステージングのワークフローに関しては、特に 3 つのことが有用な形で変わります。
ステージングのクローンが無重力になります。 wp-content/uploads が 60 GB の本物の JPEG ではなく、クラウドストレージを指す 200 MB のプレースホルダーになると、WP Staging Pro はメディア側でコピーするものがほとんどありません。クローン時間は「コーヒーを取りに行く」から「待って、もう終わったの?」へと下がります。プラグインが今、作られた目的どおりのこと——実際に変わるサイトの部分をコピーすること——をしているからです。
ステージングと本番が同じメディアライブラリを共有します。 クローンすると、ステージングのコピーは本番と同じクラウドストレージを指します。既存のすべての画像、動画、PDF が、1 つのファイルもコピーせずにステージングで読み込まれます。同期ジョブも、60 GB の転送が終わるのを待つことも、ヒーロー画像が欠けた半壊のプレビューもありません。Infinite Uploads はこのワークフローを WP Staging Pro で特別にテストし、接続がクローンにも本番への変更の差し戻しにも耐えることを確認しています。
バックアップがストレージを食わなくなります。 データベース、プラグイン、テーマの WP Staging Pro のスケジュールバックアップは、数秒で Google Drive に送れるほど小さくなります。メディアはすでにクラウドストレージ層でバックアップされており、すべての WordPress スナップショットの中にアーカイブする必要はありません。ストレージコストは下がります。復元時間も下がります。スケジュールは誰にも気づかれずに 1 時間ごとに走らせられます。
組み合わせたワークフローを実践で
2 つのプラグインを組み合わせるとどうなるかは、かなりシンプルです。
本番はバックアップ、移行、たまのステージングクローンに WP Staging Pro を使います。同じサイトが Infinite Uploads を使って、メディアライブラリをオフロードし CDN 配信のままに保ちます。編集者はどちらのプラグインが存在することも知りません。画像をアップロードし、公開を押し、すべてが機能します。
プラグインの更新をテストしたり、リデザインをプレビューしたりするためにステージングサイトが必要になったら、WP Staging Pro でクローンをクリックします。プラグインはデータベース、プラグインフォルダー、テーマフォルダーをコピーします。uploads フォルダーは参照の薄い殻なので、数秒でコピーされます。新しいステージングサイトは本番と同じクラウドメディアを指して立ち上がり、ディスクの重さなしにすべてのページが正しくレンダリングされます。
作業が終わって変更を本番に戻すとき、WP Staging Pro はデータベースとコードのマージを処理します。メディアはどちらのサーバーにも本当はなかったので、一度も移動する必要はありませんでした。
バックアップがスケジュールで走るとき、それはデータベースとコードのスナップショットなので、小さく、速く、保管が安価です。メディアはクラウドストレージ層に独自の冗長性を持っており、これは結局、1 日 1 回すべてを .wpstg アーカイブに固めるよりも本当に信頼できます。
これが、現代の WordPress 制作会社が 5 GB を超えるすべてのサイトで運用すべきスタックです。データベース、プラグイン、テーマ、移行には WP Staging Pro。メディアには Infinite Uploads。各プラグインが得意なことをこなし、どちらももう一方の邪魔をしません。
スタックが正しいと何が変わるか
制作会社のワークフローにとって重要な指標が、測りやすい形で変わります。
20 分かかっていたステージングのクローンが 2 分未満で終わります。オリジンサーバーのディスク使用量は、メディアの多いサイトで 80〜95 % 下がります。スケジュールバックアップは、50 GB のディレクトリをアーカイブしようとしなくなるため、メモリ制限で失敗しなくなります。ストレージが従量制のプランではホスティング料金が下がります。クライアントのプレビュー環境は、サーバー負荷を見計らって計画するのではなく、気軽に立ち上げられます。
そして数値にしにくい部分——ステージングのワークフローがプロジェクトであることをやめます。最初からそうあるべきだったもの、つまり自信を持って公開できる日常的なクリックになります。
WP Staging Pro はステージングを身近にしました。Infinite Uploads は、あなたのサイトが成長してもそれをそのまま保ちます。
スタックを正直に保ちましょう。uploads フォルダーにワークフローを食わせてはいけません。
