WordPress のファイル転送：SFTP でサイトのファイルを管理する

サイトのファイルを直そうとして転送ソフトに多数のフォルダーが見えたら、最初に考えるべきことは「今どこに接続しているか」です。WordPress、ホスティングの管理パネル、ファイル転送のアカウントは別々の場合があります。管理画面のパスワードを知っていても、安全なファイル管理方法をすでに確保できているとは限りません。

ここでは、小規模な制作事務所のサイト保守を依頼され、子テーマのスタイルファイルを差し替えつつ、元に戻せる状態を残す場面を考えます。以下は公式資料を基に整理した操作上の提案です。読者のサーバーには接続しておらず、すべてのホスティングサービスが同じパスや権限を使うとも想定していません。

ホスティング事業者から接続情報一式を得る

FTP は転送プロトコルで、SFTP は SSH を通じて接続を暗号化し、FTPS は TLS で FTP を保護します。名前は似ていても接続方式は異なります。ホストが SFTP に対応していれば優先し、FTPS が提供されている場合は公式手順どおりに暗号化を設定してください。接続できるようにするためだけに、暗号化なしの FTP へ切り替えないでください。

必要なのは、サーバーアドレス、ポート、ユーザー名、認証方法、アクセス可能なディレクトリ、ホスト鍵の指紋です。ポートは管理パネルに示された番号を使います。サイトのドメインは CDN を指している場合があるため、そのまま SFTP ホストだと判断できません。本番用とテスト用の接続は名前を分け、接続先の間違いを減らします。

鍵認証では、サーバーに公開鍵を設定し、秘密鍵は保護されたパソコンに置きます。秘密鍵や接続設定一式を複数人のグループへ送らないでください。外部業者との作業では、ホスト管理者に範囲を絞った個別アカウントの作成を相談し、完了後に無効化すると、最上位権限のアカウントを長期間共有せずに済みます。

サイトマネージャーで接続を作り、相手を確認する

FileZilla なら、ファイルメニューからサイトマネージャーを開き、新しいサイトを作成して SFTP を選び、アドレス、ポート、指定のログイン方法を入力します。IP アドレスだけでなく「事務所テストサイト」のように判別しやすい名前を付けましょう。初回接続でホスト鍵の確認が出たら、管理者から受け取った指紋と先に照合します。

指紋は接続先サーバーの身元を確かめるもので、自分のログイン用公開鍵ではありません。初めて表示された値だけでは、それ自体が信頼できる証明になりません。ホスティングの管理パネルか、本人確認済みの管理者から比較用の情報を入手してください。使っていた接続で突然指紋の変更が表示されたら、移転や機器交換の可能性も、別のホストにつながった可能性もあります。理由を確認してから続けます。

1. 管理パネルでアカウントの対象サイトを確認し、ドキュメントルートを記録する。
2. サイトマネージャーでプロトコルとログイン方法を明示的に選び、初期値任せにしない。
3. ホスト鍵の照合後は先にディレクトリを確認し、まだドラッグでのアップロードやフォルダー全体の同期をしない。

サイトのルートを探し、ファイルとデータベースを分ける

ログイン後は通常、左がローカル、右がリモートです。public_html や www が見えても、それだけで対象サイトとは判断できません。複数ドメインや分離されたディレクトリを使っている場合があります。管理パネルの指定パスと照合し、wp-admin、wp-includes、wp-content などの WordPress ディレクトリがあるか確認します。疑問があれば変更を止めてください。

テーマとプラグインは通常 wp-content の対応するサブディレクトリにあり、メディアの実ファイルは uploads に置かれることがよくあります。投稿、ユーザー、多くの設定はデータベースに保存されるため、サイトのフォルダーをダウンロードしてもデータベースは自動で書き出されません。また、写真を uploads に直接置いても、メディアライブラリに完全な添付ファイル情報が作られるわけではありません。

まずファイルとデータベースの完全なバックアップを用意し、さらに今回変更する単独のファイルもダウンロードします。バックアップはローカルの保護された場所に置き、元のパスと日付を残してください。パスワードを含む設定ファイルを .bak やテキストファイルに改名して、公開ディレクトリに残してはいけません。サイトからダウンロードされるおそれがあります。

一度に変更する対象を明確な一つに絞る

外観を調整する場合は、変更箇所が子テーマかを確認します。親テーマやプラグインの元ファイルを直接変えると、更新で上書きされることがあります。管理画面の設定で済む変更なら、プログラムファイルを直す必要はありません。編集が必要な場合は、ローカルの適切なプレーンテキストエディターを使い、元の拡張子と文字コードを保ちます。

アップロード前に、ファイル名、リモートの完全なパス、ファイルサイズ、元の版を比較します。ローカルサイト全体を本番のルートへドラッグしたり、リモート側の余分なファイルを無条件で削除する同期方式を選んだりしないでください。使用中のメディアや、他の人が更新したばかりのファイルを消すおそれがあります。

転送後はキューに失敗した項目がないか確認します。大きなプラグインや複数ファイルのプログラム更新が途中までしか送られていないと、新旧の版が混ざった状態になります。この種の作業には正式な更新・デプロイ手順を使ってください。単独のスタイルファイルなら、先にテストサイトで確認し、合意した時間帯に適用できます。

権限不足なら所有者とホストの規則を先に確認する

一般的な Linux 構成では、ディレクトリ 755、通常ファイル 644 を出発点にしますが、公式資料もホストごとにユーザーとグループの構成が異なることを強調しています。数値は万能な修復方法ではなく、マネージド環境が一部ファイルを意図的に保護している場合もあります。書き込みを拒否されたら、アカウントの範囲、所有者、ディスク容量の割り当て、対象パスを先に確認します。

サイト全体を 777 にしたり、一つのファイルの問題のためにすべてのディレクトリの権限を再帰的に変えたりしないでください。wp-config.php などの設定ファイルには、より慎重なアクセス管理が必要です。実際の値はホストの実行方式に合わせて決めます。エラーの時刻と機密部分を隠したパスをサポートに渡すほうが、無計画に権限を広げるより原因を特定しやすくなります。

FileZilla に .htaccess などドットで始まるファイルが表示されない場合は、隠しファイルの表示設定とサーバー側の制限を確認します。一覧にないという理由だけで、同名の空ファイルを作って上書きしないでください。隠しファイルはリダイレクトやアクセスを制御している場合があり、欠落するとバックアップも不完全になります。

元に戻せる状態で作業を終える

変更後は公開画面と管理画面を開き直し、実際に影響するページを確認します。スタイル変更はスマートフォン幅でも確認し、必要なら関連キャッシュを消してください。転送成功の表示だけで終えてはいけません。表示崩れやプログラムエラーが起きたら、別の不明な変更を重ねる前に元ファイルを戻して検証します。

変更記録には少なくとも、時刻、サイト、ファイルパス、目的、検証結果、元ファイルの保存場所を残します。ファイルの復元で戻るのはその内容だけであり、同時に発生した注文やデータベースの更新は自動では戻りません。保守後は接続を閉じ、一時アカウントとローカルの機密ファイルが引き継ぎ規則どおりに管理されていることを確認します。

詳しい説明を読む

ホストの照合、元ファイルのダウンロード、狭い範囲のアップロード、公開画面の検証を四つの枠で示す図。

ファイルとデータベースの完全なバックアップを作る

サイトの 500 エラーを調べる方法

• チュートリアル
• アプリ・ソフト
• サイト構築・EC
• WordPress