Instalé un blog de WordPress en mi sistema local. Pero cuando trato de agregar complementos de administrador, solicita acceso FTP. ¿Qué necesito configurar para que WordPress pueda cargar sin FTP?
Instalé un blog de WordPress en mi sistema local. Pero cuando trato de agregar complementos de administrador, solicita acceso FTP. ¿Qué necesito configurar para que WordPress pueda cargar sin FTP?
Respuestas:
Intente agregar el código en wp-config.php:
define('FS_METHOD', 'direct');
FS_METHOD
es la abreviatura de FILESYSTEM_METHOD
. Cuando está definiendo direct
modificar los archivos, también conocido como no usar FTP, está obligando a WordPress a intentar alterar los archivos en el sitio directamente.
Si está utilizando Ubuntu.
sudo chown -R www-data:www-data PATH_TO_YOUR_WORDPRESS_FOLDER
www-data
ver aquí: codex.wordpress.org/Hardening_WordPress o aquí: stackoverflow.com/questions/18352682/…
"Siempre que utilice el panel de control de WordPress para instalar, actualizar o eliminar complementos automáticamente, WordPress debe realizar cambios en los archivos del sistema de archivos.
Antes de realizar cualquier cambio, WordPress primero verifica si tiene o no acceso para manipular directamente el sistema de archivos.
Si WordPress no tiene los permisos necesarios para modificar el sistema de archivos directamente, se le pedirán las credenciales de FTP para que WordPress pueda intentar hacer lo que necesita a través de FTP ".
Solución: para saber con qué usuario se ejecuta su instancia de apache, cree un script de prueba con el siguiente contenido:
<?php echo(exec("whoami")); ?>
Para mí, era daemon y no www-data. Luego, arregle el permiso por:
sudo chown -R daemon /path/to/your/local/www/folder
<?php echo(exec("id")); ?>
que incluso le proporcionará datos de grupo más allá de la identificación del usuario:uid=5018(web27) gid=5012(client7) groups=5012(client7),5002(sshusers)
whoami
así que vea la misma información:sudo chown -R `whoami` /path/to/your/local/www/folder
En OSX, utilicé lo siguiente y funcionó:
sudo chown -R _www:_www {path to wordpress folder}
_www es el usuario bajo el que se ejecuta PHP en Mac.
(Es posible que también necesite modificar algunas carpetas. Lo hice primero y no lo solucionó. No fue hasta que hice el comando chown que funcionó, así que no estoy seguro de si fue el comando chown solo, o una combinación de chmod y chown.)
Cambié la propiedad de la carpeta de wordpress a www-data de forma recursiva y reinicié Apache.
sudo chown -R www-data:www-data <folderpath>
¡Funcionó a las mil maravillas!
Desde el primer éxito en Google :
WordPress le solicita sus credenciales de FTP cuando no puede acceder a los archivos directamente. Esto generalmente se debe a que PHP se ejecuta como el usuario de Apache (mod_php o CGI) en lugar del usuario que posee sus archivos de WordPress.
Esto es bastante normal en la mayoría de los entornos de alojamiento compartido: los archivos se almacenan como usuario y Apache se ejecuta como usuario apache
o httpd
. En realidad, esta es una buena precaución de seguridad, por lo que los ataques y los ataques no pueden modificar los archivos alojados. Puede eludir esto configurando todos los archivos WP en seguridad 777, pero eso significa que no hay seguridad, por lo que lo desaconsejaría. Simplemente use FTP, es la solución recomendada automáticamente con una buena razón.
Primero muévase a su carpeta de instalación (por ejemplo)
cd /Applications/XAMPP/xamppfiles/
Ahora vamos a modificar su directorio htdocs:
sudo chown -R daemon htdocs
Ingrese su contraseña de root cuando se le solicite, luego finalícela con una llamada chmod:
sudo chmod -R g+w htdocs
Hice una instalación local de WordPress en Ubuntu 14.04 siguiendo los pasos descritos aquí y simplemente ejecutándome:
sudo chown -R www-data:www-data {path_to_your_project_directory}
resolvió mi problema con la descarga de complementos. La única razón por la que dejo esta publicación aquí es porque cuando busqué en Google mi problema, este fue uno de los primeros resultados y me llevó a la solución a mi problema.
¡Espero que este ayude a alguien!
Tuvimos el mismo problema como parte de un problema mayor. La solución sugerida de
define('FS_METHOD', 'direct');
oculta esa ventana, pero seguimos teniendo problemas con la carga de temas y actualizaciones, etc. Está relacionado con los permisos, sin embargo, en nuestro caso, solucionamos el problema pasando del proveedor de php OS mod_php a la aplicación más segura FastCGI del proveedor de php OS .
Si durante la instalación de un complemento, Wordpress solicita su nombre de host o detalles de FTP. Luego sigue estos pasos:
Inicie sesión en su servidor y navegue hasta / var / www / html / wordpress / . Abra wp-config.php y agregue esta línea después de definir ('DB_COLLATE')
define('FS_METHOD', 'direct');
Si obtiene el error "No se pudo crear el directorio". Otorgue permisos de escritura a su directorio de wordpress de forma recursiva como
chmod -R go+w wordpress
NOTA. Por seguridad, revoque estos permisos una vez que instale un complemento como
chmod -R go-w wordpress
La forma más sencilla de resolver este problema es agregar la siguiente información de FTP a su 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 es la ruta completa a la carpeta "base" (ABSPATH) de la instalación de WordPress FTP_CONTENT_DIR es la ruta completa a la carpeta wp-content de la instalación de WordPress. FTP_PLUGIN_DIR es la ruta completa a la carpeta de complementos de la instalación de WordPress.
Como mencionó Niels, esto sucede porque el usuario del proceso del servidor no puede escribir en la carpeta de Wordpress.
Pero aquí está lo que muchos artículos no explican. Es el propietario del proceso php, no el proceso nginx. Si intenta cambiar el propietario de nginx, no resolverá esto.
Para resolverlo, intente ejecutar ps aux
para ver qué usuario es dueño del proceso php-fpm. Luego, verifique que el usuario sea el mismo usuario que el propietario de la carpeta de wordpress, o que al menos pueda escribir en ella. Si el usuario no puede escribir en él, deberá cambiar los permisos y / o la propiedad de la carpeta; o poner a los dos usuarios (propietario del servidor y propietario de la carpeta de wordpress) en un grupo común que pueda escribir en la carpeta; o cambie la propiedad "usuario" de php.ini a un usuario que pueda escribir en la carpeta.
Hay muchas respuestas similares a esta pregunta, pero ninguna aborda completamente la causa raíz. El comentario de Sebastian Schmid sobre la publicación original lo toca, pero no completamente. Aquí está mi opinión del 2018-11-06:
Causa principal
Cuando intente cargar un complemento a través de la interfaz de administración de WordPress, WordPress hará una llamada a una función llamada "get_filesystem_method ()" (ref: /wp-admin/includes/file.php:1549 ). Esta rutina intentará escribir un archivo en la ubicación en cuestión (en este caso, el directorio de complementos). Por supuesto, puede fallar aquí de inmediato si los permisos de archivo no están configurados correctamente para permitir que el usuario de WordPress (piense en la identidad del usuario que ejecuta el php) escriba el archivo en la ubicación en cuestión.
Si se puede crear el archivo, esta función detecta el propietario del archivo temporal, junto con el propietario del archivo actual de la función (ref: /wp-admin/includes/file.php:1572 ) y compara los dos. Si coinciden, entonces, en palabras de WordPress, "WordPress está creando archivos con el mismo propietario que los archivos de WordPress, esto significa que es seguro modificar y crear nuevos archivos a través de PHP" y su complemento se carga correctamente sin el mensaje de credenciales FTP. Si no coinciden, aparece el mensaje Credenciales FTP.
Arreglos
Asegúrese de que la identidad que ejecuta su proceso php sea el propietario del archivo para:
a) Todos los archivos de la aplicación de WordPress, o ...
b) Al menos el archivo /wp-admin/includes/file.php
Comentarios finales
No estoy demasiado interesado en aplicar específicamente la propiedad del archivo al file.php para solucionar este problema (¡se siente un poco hack por decir lo menos!). En este punto, me parece que el código base de WordPress se inclina a que ejecutemos el proceso PHP bajo el mismo principio de usuario que el propietario del archivo para los archivos de la aplicación de WordPress. Agradecería algunos comentarios de la comunidad sobre esto.