「要求されたアクションを実行するには、WordPress が Web サーバーにアクセスする必要があります。 次に進むには FTP の接続情報を入力してください。 接続情報が思い出せない場合は、ホスティング担当者に問い合わせてください」の対策とWordPress Filesystem API実装の詳細

表示されるエラーは次の通りです。

接続情報
要求されたアクションを実行するには、WordPress が Web サーバーにアクセスする必要があります。 次に進むには FTP の接続情報を入力してください。 接続情報が思い出せない場合は、ホスティング担当者に問い合わせてください。

ホスト名
FTP ユーザー名
FTP パスワード
接続形式 FTP/FTPS(SSL)
[開始]

Connection Information To perform the requested action, WordPress needs to access your web server. Please enter your FTP credentials to proceed. If you do not remember your credentials, you should contact your web host.

このエラー表示は、WordPressのファイルシステム編集に使われるAPIが共通して利用する、「直接書き込めなかったときの対策」的なページです。

なので、いろいろなページで表示される可能性があります。

この画面に表示される内容について、「FTPなんて使ってないよーどうすればいいの？」という人もいるかも知れません。

このエラーは、サーバーでファイルを作成したり、編集しようとしてみたところ、パーミッション（ファイルの読み書き許可の設定）の問題で、失敗してしまったことが原因で表示されます（その他、余計な設定・指定の可能性もあるが、多くはパーミッションの問題）。

この問題は、パーミッションを、書き込みができるように変更することで、解決できます。

しかし、ここでのポイントは、ファイルの所有者と、サーバーの（PHPを）実行しているユーザーの所有者を一致させるということです。

単純な書き込み権限であれば、グループ権限＋グループが一緒、という方法でも書き込めるはずなのですが、WordPressは、デフォルトでこのグループ権限による書き込みをできないようにしてあり、ファイルの所有者を一致させるために、ファイルの所有者を変更する必要があります。

そのため、以下のコマンド例のようにして、所有者を、サーバーの実行ユーザーと合わせるようにしてください。

$ sudo chown -R nginx path/to/wordpress

※ここではサーバーの実行ユーザーとして「nginx」にしていますが、「apache」だったり、他にもレンタルサーバ-業者や設定次第で、色々な可能性もあります。

この入力画面を表示しているのは、WordPress Filesystem API の、request_filesystem_credentials です。

（特別な指定がなければ）直接書き込みができるかを判定し、直接書き込みができない、かつ、FTP/SSHの認証情報が無い場合に、あの画面を表示する、と言うような仕組みです。

get_filesystem_method

コードをたどってみると、直接書き込み可能かどうかを判断しているのは、get_filesystem_method でした。

ファイルシステムに直接書き込み可能か判断し、書き込み可能な場合はtrueを、FTP/SSHの場合については認証情報を返しています。

ここでの判定には、一時ファイルを作成してから fileowner で現在のユーザーを取得し、そうして確認した「一時ファイルの所有者」と「実行中のPHPファイルの所有者」を比較し、両者が一致していれば書き込み可能と判断していました。

※本当は、このget_filesystem_method や request_filesystem_credentials では、これからAPIを使って書き込みたいディレクトリを指定して、そこで確認する機能自体はある様なのですが、githubを検索しても、さっぱりその引数は活用されておらず、デフォルトの確認方法になっていました。

実際の書き込みフォルダだけのchmodでは解決しない

今回の対策では、この「実行中のPHPファイルの所有者」を変更することで、問題を回避しています。

最低限の変更にしようと、実際に書き込みが行われるフォルダの権限を変更することは、直接の解決にはなりませんでした。

今回の画面は、実際に書き込みを行う前に呼び出される関数が表示しているというのがポイントです。

また、グループの所有者はこの確認に使用していないため、グループ権限が統一されていても、この関数がこのFTPのアカウント入力画面を表示するかどうかには関係ありません。

じゃぁどこ？

まずこの構造が気が付きにくかったのですが、さらにこの判定場所のコードは、WordPressのバージョンによって大きく変わっていました。

「実行中のPHPファイルの所有者」を確認する方法として、古いバージョンでは「getmyuid」関数を利用しており、新しいものでは「fileowner( __FILE__ )」を使用していました。

なので、古いバージョンでは、今回私が遭遇したページのPHPファイルである「options-general.php」、つまり「wp-admin/include」ディレクトリ以下の所有者を変更する必要があり、新しいバージョンでは、私の作成したプラグインファイルである「did2-ab-testing.php」、つまり「wp-contents/plugins」ディレクトリ以下の所有者を変更する必要があるようでした。

その結果分かりやすいのがまるごと所有者変更

このように、細かいところがいろいろ状況によって違うので、それをすべて包括する、万能な解決策としての、丸ごとの所有者変更、でした。

実際にこの画面について調べてみると、この丸ごと対策を示しているサイトばかりだったのですが、詳細を調べた結果でも、オススメする対策はこうなりました。

一応、１ファイルのみの権限変更でも、ちゃんと解決できることは確認できました。ただ、それを特定するのは面倒ですし、また別の画面で出てしまう可能性があるので、やはり、全体丸ごと、がおすすめです。