web-dev-qa-db-ja.com

WordPressプラグインをインストールするためにFTP資格情報を要求する

ローカルシステムにWordPressブログをインストールしました。しかし、管理者からプラグインを追加しようとすると、FTPアクセスが要求されます。 FTPなしでアップロードできるようにするには、WordPressを設定する必要がありますか？

wordpressftp
100
sasi kanth

Wp-config.phpにコードを追加してみてください：

define('FS_METHOD', 'direct');
270
nickle

Ubuntuを使用している場合。

Sudo chown -R www-data:www-data PATH_TO_YOUR_WORDPRESS_FOLDER
31
Nanhe Kumar

「WordPressコントロールパネルを使用してプラグインを自動的にインストール、アップグレード、または削除する場合は、WordPressがファイルシステム上のファイルを変更する必要があります。

変更を行う前に、WordPressは最初に、ファイルシステムを直接操作するアクセス権があるかどうかを確認します。

WordPressがファイルシステムを直接変更するために必要な権限を持っていない場合、WordPressがFTPを介して必要なことを試行できるように、FTP資格情報を要求されます。

解決策：Apacheのインスタンスがどのユーザーとして実行されているかを調べるには、次の内容のテストスクリプトを作成します。

<?php echo(exec("whoami")); ?>

私にとっては、それはデーモンであり、www-dataではありませんでした。次に、次の方法で許可を修正します。

Sudo chown -R daemon /path/to/your/local/www/folder
16
Aboozar Rajabi

OSXでは、次のものを使用しましたが、機能しました。

Sudo chown -R _www:_www {path to wordpress folder}

_wwwは、PHPがMacで実行されるユーザーです。

（いくつかのフォルダもchmodする必要があるかもしれません。最初にそれを行ったので修正しませんでした。chownコマンドを実行するまでは動作しなかったので、chownコマンドかどうかはわかりません。単独、またはchmodとchownの組み合わせ。）

10
Kenny

wordpressフォルダーの所有権をwww-dataに再帰的に変更し、Apacheを再起動しました。

Sudo chown -R www-data:www-data <folderpath>

それは魅力のように働いた！

9
KawaiKx

Googleでの最初のヒットから ：

WordPressは、ファイルに直接アクセスできない場合、FTP資格情報を要求します。これは通常、PHPファイルを所有するユーザーではなく、Apacheユーザー（mod_phpまたはCGI）として実行されているWordPressが原因です。

これは、ほとんどの共有ホスティング環境ではかなり正常です-ファイルはユーザーとして保存され、ApacheはユーザーApacheまたはhttpdとして実行されます。これは実際には優れたセキュリティ予防策であるため、悪用やハッキングはホストされているファイルを変更できません。すべてのWPファイルを777セキュリティに設定することでこれを回避できますが、これはnoセキュリティを意味するため、これには強くお勧めします。 FTPを使用するだけで、正当な理由がある場合に自動的に推奨される回避策です。

7
Niels Keurentjes

最初にインストールフォルダに移動します（たとえば）

cd /Applications/XAMPP/xamppfiles/

次に、htdocsディレクトリを変更します。

Sudo chown -R daemon htdocs

プロンプトが表示されたらrootパスワードを入力し、chmod呼び出しで終了します。

Sudo chmod -R g+w htdocs
3
Benja Garrido

Ubuntu 14.04でWordPressのローカルインストールを行いました こちら の手順に従って、単に実行します：

Sudo chown -R www-data:www-data {path_to_your_project_directory}

プラグインのダウンロードに関する問題を解決しました。ここにこの投稿を残す唯一の理由は、問題をグーグルで検索したとき、これが最初の結果の1つであり、それが問題の解決につながったためです。

これが誰にも役立つことを願っています！

3
Hiren Gohel

より大きな問題の一部として同じ問題がありました。提案された解決策

define('FS_METHOD', 'direct');

そのウィンドウを非表示にしますが、テーマやアップグレードなどの読み込みにまだ問題があります。アクセス権に関連していますが、この場合、php OSベンダーmod_phpより安全なphp OSベンダーFastCGIアプリケーション。

3
malta

この問題を解決する最も簡単な方法は、次のFTP情報をwp-config.phpに追加することです

define('FS_METHOD', 'direct');
define('FTP_BASE', '/usr/home/username/public_html/my-site.example.com/wordpress/');
define('FTP_CONTENT_DIR', '/usr/home/username/public_html/my-site.example.com/wordpress/wp-content/');
define('FTP_PLUGIN_DIR ', '/usr/home/username/public_html/my-site.example.com/wordpress/wp-content/plugins/');

FTP_BASEは、WordPressインストールの「ベース」（ABSPATH）フォルダーへのフルパスですFTP_CONTENT_DIRは、wp-contentフォルダーへのフルパスですWordPressインストール。 FTP_PLUGIN_DIRは、WordPressインストールのプラグインフォルダーへのフルパスです。

2
Purvik Dhorajiya

Nielsが述べたように、これは、サーバープロセスユーザーがWordpressフォルダーに書き込むことができないために発生します。

しかし、多くの記事で説明されていないことがあります。これは、nginxプロセスではなく、phpプロセスの所有者です。 nginxの所有者を変更しようとしても、これは解決しません。

解決するには、ps auxを実行して、php-fpmプロセスを所有しているユーザーを確認してください。次に、そのユーザーがwordpressフォルダーの所有者と同じユーザーであること、または少なくとも書き込みできることを確認します。ユーザーが書き込みできない場合は、フォルダーのアクセス許可や所有権を変更する必要があります。または、2人のユーザー（サーバー所有者とwordpressフォルダー所有者）を、フォルダーへの書き込みが可能な共通グループに入れます。または、php.iniの「user」プロパティを、フォルダに書き込むことができるユーザーに変更します。

1
mahemoff

この質問には多くの同様の回答がありますが、根本原因に完全に触れているものはありません。 Sebastian Schmid's 元の投稿へのコメントはそれに触れていますが、完全ではありません。 2018年11月6日現在の私の見解：

根本原因

WordPress adminインターフェイスを介してプラグインをアップロードしようとすると、WordPressは「get_filesystem_method（）」と呼ばれる関数を呼び出します（ref： / wp- admin/includes/file.php：1549 ）。このルーチンは、問題の場所（この場合はプラグインディレクトリ）にファイルを書き込もうとします。もちろん、WordPressユーザー（phpを実行するユーザーIDを考えてください）が問題の場所にファイルを書き込むことを許可するファイル権限がセットアップされていない場合、ここですぐに失敗する可能性があります。

ファイルを作成できる場合、この関数は、関数の現在のファイルのファイル所有者とともに、一時ファイルのファイル所有者を検出します（参照： / wp-admin/includes/file.php：1572 =）2つを比較します。一致する場合、WordPressの言葉では、「WordPressはWordPressファイルと同じ所有者としてファイルを作成しています。これは、PHPを介して新しいファイルを変更および作成しても安全であることを意味します」 FTP資格情報プロンプト。一致しない場合は、FTP資格情報プロンプトが表示されます。

修正

  1. プラグインディレクトリが、PHPプロセスを実行しているIDによって書き込み可能であることを確認します。

  2. PHPプロセスを実行しているIDが次のいずれかのファイル所有者であることを確認します。

    a）すべてのWordPressアプリケーションファイル、または...
    b）少なくとも/wp-admin/includes/file.phpファイル

最終コメント

この問題を回避するためにfile.phpにファイルの所有権を具体的に適用することにあまり熱心ではありません（控えめに言ってもちょっとしたハックを感じます！）。現時点では、WordPressコードベースは、PHPのファイル所有者と同じユーザープリンシパルの下でWordPressプロセスを実行することに傾いているように思えます。 _アプリケーションファイル。これに関するコミュニティからのコメントを歓迎します。

1
Matt Woodward

私は同じ問題に直面していました！以下のコードをwp-config.phpファイル（任意の行）に追加しましたが、現在動作しています！

define('FS_METHOD', 'direct');
1
erovere