WordPress prosi o moje dane uwierzytelniające FTP, aby zainstalować wtyczki

Zainstalowałem blog WordPress w moim systemie lokalnym. Ale kiedy próbuję dodać wtyczki od administratora, prosi o dostęp do FTP. Co muszę skonfigurować, aby WordPress mógł przesyłać pliki bez FTP?

Spróbuj dodać kod w wp-config.php:

define('FS_METHOD', 'direct');

Jeśli używasz Ubuntu.

sudo chown -R www-data:www-data PATH_TO_YOUR_WORDPRESS_FOLDER

„Za każdym razem, gdy używasz panelu sterowania WordPress do automatycznej instalacji, aktualizacji lub usuwania wtyczek, WordPress musi wprowadzić zmiany w plikach w systemie plików.

Przed wprowadzeniem jakichkolwiek zmian WordPress najpierw sprawdza, czy ma dostęp do bezpośredniego manipulowania systemem plików.

Jeśli WordPress nie ma niezbędnych uprawnień do bezpośredniej modyfikacji systemu plików, zostaniesz poproszony o podanie danych uwierzytelniających FTP, aby WordPress mógł spróbować zrobić to, czego potrzebuje, przez FTP ”.

Rozwiązanie: aby dowiedzieć się, z jakim użytkownikiem działa Twoja instancja Apache, utwórz skrypt testowy o następującej treści:

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

Dla mnie był to demon, a nie dane www. Następnie popraw pozwolenie przez:

sudo chown -R daemon /path/to/your/local/www/folder

Na OSX użyłem następujących i zadziałało:

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

_www to użytkownik, na którym działa PHP na komputerze Mac.

(Może być również konieczne chmodowanie niektórych folderów. Zrobiłem to najpierw i nie naprawiłem tego. Dopiero gdy wykonałem polecenie chown, zadziałało, więc nie jestem pewien, czy to było polecenie chown samodzielnie lub połączenie chmod i chown.)

Zmieniłem własność folderu wordpress rekurencyjnie na www-data i ponownie uruchomiłem Apache.

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

Zadziałało jak urok!

Od pierwszego trafienia w Google :

WordPress prosi o podanie danych logowania FTP, gdy nie może uzyskać bezpośredniego dostępu do plików. Zwykle jest to spowodowane tym, że PHP działa jako użytkownik Apache (mod_php lub CGI), a nie użytkownik, który jest właścicielem twoich plików WordPress.

Jest to raczej normalne w większości współdzielonych środowisk hostingowych - pliki są przechowywane jako użytkownik, a Apache działa jako użytkownik apachelub httpd. W rzeczywistości jest to dobre zabezpieczenie, więc exploity i hacki nie mogą modyfikować hostowanych plików. Możesz to obejść, ustawiając wszystkie pliki WP na zabezpieczenia 777, ale oznacza to brak zabezpieczeń, więc zdecydowanie odradzam to. Po prostu użyj protokołu FTP, jest to automatycznie zalecane obejście z dobrego powodu.

Jeśli podczas instalacji wtyczki Wordpress zapyta o nazwę hosta lub dane FTP. Następnie wykonaj następujące kroki:

Zaloguj się na swój serwer i przejdź do / var / www / html / wordpress / . Otwórz wp-config.php i dodaj tę linię po define ('DB_COLLATE')

define('FS_METHOD', 'direct');

Jeśli pojawi się błąd „Nie można utworzyć katalogu”. Przyznaj uprawnienia do zapisu w swoim katalogu wordpress rekurencyjnie jako

chmod -R go+w wordpress

UWAGA. Ze względów bezpieczeństwa cofnij te uprawnienia po zainstalowaniu wtyczki jako

chmod -R go-w wordpress

Najpierw przejdź do folderu instalacyjnego (na przykład)

cd /Applications/XAMPP/xamppfiles/

Teraz zamierzamy zmodyfikować twój katalog htdocs:

sudo chown -R daemon htdocs

Po wyświetleniu monitu wprowadź hasło roota, a następnie zakończ je wywołaniem chmod:

sudo chmod -R g+w htdocs

Zrobiłem lokalną instalację WordPress na Ubuntu 14.04, postępując zgodnie z instrukcjami tutaj opisanymi i po prostu uruchamiając:

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

rozwiązałem mój problem z pobieraniem wtyczek. Jedynym powodem, dla którego zostawiam ten post, jest to, że kiedy wyszukałem w Google mój problem, był to jeden z pierwszych wyników i doprowadził mnie do rozwiązania mojego problemu.

Mam nadzieję, że ten pomoże każdemu!

Mieliśmy ten sam problem jako część większego problemu. Sugerowane rozwiązanie

define('FS_METHOD', 'direct');

ukrywa to okno, ale nadal mieliśmy problemy z ładowaniem motywów i uaktualnień itp. Jest to związane z uprawnieniami, jednak w naszym przypadku rozwiązaliśmy problem, przechodząc od dostawcy php OS mod_php do bezpieczniejszej aplikacji dostawcy php OS FastCGI .

Najłatwiejszym sposobem rozwiązania tego problemu jest dodanie następujących informacji FTP do pliku 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 to pełna ścieżka do folderu „podstawowego” (ABSPATH) instalacji WordPress. FTP_CONTENT_DIR to pełna ścieżka do folderu wp-content instalacji WordPress. FTP_PLUGIN_DIR to pełna ścieżka do folderu wtyczek instalacji WordPress.

Jak wspomniał Niels, dzieje się tak, ponieważ użytkownik procesu serwera nie może pisać do folderu Wordpress.

Ale tutaj jest rzecz, której wiele artykułów nie wyjaśnia. Jest właścicielem procesu php, a nie procesu nginx. Jeśli spróbujesz zmienić właściciela nginx, nie rozwiąże to tego problemu.

Aby go rozwiązać, spróbuj uruchomić ps auxi sprawdzić, który użytkownik jest właścicielem procesu php-fpm. Następnie sprawdź, czy użytkownik jest tym samym użytkownikiem, co właściciel folderu wordpress, czy przynajmniej może do niego pisać. Jeśli użytkownik nie może w nim pisać, musisz zmienić uprawnienia i / lub własność folderu; lub umieść dwóch użytkowników (właściciela serwera i właściciela folderu wordpress) we wspólnej grupie, która może pisać do folderu; lub zmień właściwość „user” php.ini na użytkownika, który może pisać do folderu.

Istnieje wiele podobnych odpowiedzi na to pytanie, ale żadna z nich nie dotyka w pełni pierwotnej przyczyny. Komentarz Sebastiana Schmida do oryginalnego posta dotyka go, ale nie do końca. Oto moja opinia na dzień 2018-11-06:

Przyczyna

Kiedy spróbujesz załadować wtyczkę przez interfejs administratora WordPress, WordPress wykona wywołanie funkcji o nazwie „get_filesystem_method ()” (ref: /wp-admin/includes/file.php:1549 ). Ta procedura spróbuje zapisać plik w odpowiedniej lokalizacji (w tym przypadku w katalogu wtyczek). Oczywiście może się to natychmiast nie powieść, jeśli uprawnienia do pliku nie są ustawione prawidłowo, aby umożliwić użytkownikowi WordPress (myśląc o tożsamości użytkownika wykonującego php) zapisanie pliku w danej lokalizacji.

Jeśli plik można utworzyć, funkcja ta następnie wykrywa właściciela pliku tymczasowego, wraz z właścicielem pliku bieżącego pliku funkcji (ref: /wp-admin/includes/file.php:1572 ) i porównuje oba. Jeśli pasują do siebie, mówiąc słowami WordPress, „WordPress tworzy pliki jako ten sam właściciel co pliki WordPress, oznacza to, że można bezpiecznie modyfikować i tworzyć nowe pliki za pośrednictwem PHP”, a wtyczka została pomyślnie przesłana bez monitu o poświadczenia FTP. Jeśli nie pasują, pojawi się monit o poświadczenia FTP.

Poprawki

1. Upewnij się, że katalog wtyczki jest zapisywalny przez tożsamość, na której działa twój proces php.

2. Upewnij się, że tożsamość, na której działa twój proces php, jest właścicielem pliku:

   a) Wszystkie pliki aplikacji WordPress lub ...
   b) Co najmniej plik /wp-admin/includes/file.php

Uwagi końcowe

Nie jestem przesadnie zainteresowany konkretnym zastosowaniem praw własności do pliku file.php, aby obejść ten problem (wydaje się to co najmniej trochę hakerskie!). Wydaje mi się, że w tym momencie baza kodu WordPress skłania się ku temu, abyśmy wykonywali proces PHP na tej samej zasadzie użytkownika, co właściciel pliku aplikacji WordPress. Z radością powitałbym kilka komentarzy społeczności na ten temat.

Miałem ten sam problem! Dodałem poniższy kod w pliku wp-config.php (w dowolnej linii) i już działa!

define('FS_METHOD', 'direct');