Un usuario preguntó 👇
Al intentar actualizar plugins / themes / WP, dice: Update Failed: No se pudo encontrar el directorio de contenido de WordPress (wp-content). ¿Tiene algo que ver con mi ruta de instalación? Mi carpeta de wordpress está disponible en SFTP a través de la siguiente ruta / public_html / wordpress / wp-content / plugins para que tenga un / public_html / en la ruta, que es la mejor carpeta a la que tengo acceso. ¿Es eso algo que podría ser un obstáculo para el plugin? ¿Y dónde puedo establecer la ruta predeterminada? Todo lo mejor, Barnabas Kadar
(@davidanderson)
Hace 2 años, 5 meses
Puedes probar las constantes FTP_BASE, FTP_PLUGIN_DIR, FTP_CONTENT_DIR, como se describe aquí – https://codex.wordpress.org/Editing_wp-config.php#WordPress_Upgrade_Constants – están activos para el modo de inicio de sesión de este plugin.
David
(@tgoeg)
Hace 2 años
Yo tenía el mismo error. Cambió la configuración de sshd para hacer que WP root sea el directorio de inicio de sesión inicial de los usuarios de SFTP. p.ej.
Match User wordpress
ChrootDirectory /home/wordpress/public_html
ForceCommand internal-sftpLos arreglos mencionados no ayudaron a solucionar este problema. Sospecho que se evalúan al iniciar sesión a través de SFTP. Solo decidí FTP_BASE o ambos FTP_BASE y FTP_CONTENT_DIR.
Este plugin o núcleo debe ser un error.
He activado la depuración, pero no he encontrado ninguna entrada en el registro de depuración asociado con este plugin.
Esta respuesta fue modificada hace 2 años por. Esta respuesta fue modificada hace 2 años por.
(@tgoeg)
Hace 2 años
Pensando en ello: esta no es una solución en absoluto para las actualizaciones del núcleo, porque el chroot debe ser propiedad de root. Por tanto, el usuario no podrá escribir archivos en el navegador web. El es FTP_BASE debe ser honrado. No hay otra solución.
(@tgoeg)
Hace 2 años
Utilizando define( 'WP_CONTENT_DIR', 'whatever/dir/wp-content' ); finalmente esto resuelto.
Esto definitivamente debería hacerse como parte de la documentación. ¡Creo que la mayoría de la gente intentará separar a los usuarios con chroots!
Lo único que falta para una configuración adecuada y segura es usar wordpress umask 0027 para que los archivos obtengan los permisos predeterminados (usando setgid también).
Sin embargo, eso parece imposible.
Aquí se menciona un truco (no lo arreglaría): https://wordpress.org/support/topic/fail-to-make-wp-set-the-umask-i-want/
(@davidanderson)
Hace 1 año, 12 meses
Hola,
Toda la lógica para encontrar WP está dentro del núcleo de WordPress. Este plugin solo proporciona un método de conexión SFTP para la conexión en sí (es decir, no tiene ninguna de las lógicas «buscar WP»).
David
(@tgoeg)
Hace 1 año, 11 meses
Entonces algo se rompe dentro del corazón. Y define( 'WP_CONTENT_DIR', 'whatever/dir/wp-content' ); los aditivos se desactivan durante la noche. Eso también es bastante feo. Entonces todavía estoy sin resolver.
¿Es posible mi solución? Es decir, sin permisos de escritura para el usuario de Apache (que no sea el directorio de carga) y una actualización de fin de semana funciona utilizando las credenciales / permisos correctos para un usuario SSH mientras usa este plugin
(@davidanderson)
Hace 1 año, 11 meses
¿Puedes aclarar tu situación? No entendí bien el problema actual, porque tu primera publicación decía que lo resolviste. ¿Qué parte se resuelve y cuál no se resuelve?
(@tgoeg)
Hace 1 año, 11 meses
Perdón por no ser lo suficientemente claro. De hecho, nada está resuelto.
La instalación de WP pertenece al usuario: www-data y método 2750 para directorios y 0640 para archivos.
Por lo tanto, el usuario puede leer y escribir y solo se pueden leer los datos www.
El bit pegajoso del grupo también crea nuevos archivos propiedad de www-data.
Me gustaría usar este plugin para realizar las actualizaciones durante el fin de semana de WP para que use SFTP como «usuario» para editar / escribir archivos.
El problema es que después de que este plugin autentica al usuario correctamente (puedo ver 4 inicios de sesión exitosos en el registro sshd), el fin de semana dice "Update Failed: Unable to locate WordPress content directory (wp-content)." como dice el autor original de esta pregunta.
Si habilito el registro de depuración, no muestra nada relevante en el registro, pero es extraño que haya contenido, ya que wp-include / load.php tiene la siguiente línea:
ini_set( 'error_log', WP_CONTENT_DIR . '/debug.log' );
Así que en cierto modo WP_CONTENT_DIR debe configurarse correctamente (y el sitio web funciona perfectamente en lugar de actualizaciones, lo que me permite pensar en el WP_CONTENT_DIR para ser encontrado correctamente. De hecho, está en su ubicación predeterminada.
Lo único que probablemente resulte útil aquí es NINGÚN directorio base SFTP de «usuario» como raíz web.
(Necesito croot al usuario, y el directorio para chroot necesita la propiedad raíz: http://man.openbsd.org/sshd_config#ChrootDirectory
Hay un directorio wwwroot en la casa del «usuario» adjunto a / var / www / wordpress)
Aceptando la documentación, aceptaría ese sitio
define( 'FTP_BASE', '/home/user/wwwroot/' );
Esto debería resolverse, lo cual no es así.
Si me acuesto
define( 'WP_CONTENT_DIR', '/var/www/wordpress/wp-content' );
las actualizaciones funcionan a la perfección, pero algo en esta configuración en wordpress desactivó todos los plugins la noche después de que se solucionó sin interacción administrativa (la página aún funcionaba después de las actualizaciones; tal vez esto fue solo un problema almacenamiento en caché y la página ya estaba rota después de la actualización; no pude reactivar los plugins. Después de desinstalarlos WP_CONTENT_DIR Logré reactivarlos de nuevo.
Estoy buscando una solución para dejar básicamente mis permisos y archivos de wp-config como están (lo que ciertamente funciona cuando uso wp-cli para actualizaciones, pero necesito permitir actualizaciones de fin de semana para una agencia externa) . Sin embargo, SSH SFTP Updater solo parece funcionar con las variables FTP_ * como parece.
Espero haber sido más claro ahora 🙂
¡Gracias por tu ayuda continua!
(@tgoeg)
Hace 1 año, 11 meses
Hace 6 años, alguien parecía tener la misma pregunta usando FTP:
https://wordpress.stackexchange.com/questions/115052/unable-to-locate-wordpress-plugin-directory-ftp-base-not-working
(@tgoeg)
Hace 1 año, 11 meses
Estoy en php7.2
Esto podría ser https://core.trac.wordpress.org/ticket/41831 o https://core.trac.wordpress.org/ticket/35517
Si es así, debe tenerse en cuenta que este plugin no es actualmente compatible con php7.x en la configuración dada.
Veré si algunos lugares de trabajo mencionados solucionan esto.
(@davidanderson)
Hace 1 año, 11 meses
Hola,
No soy un experto en lo que hace WP al intentar encontrar archivos después de iniciar sesión en FTP (S); No he estudiado esa parte si WP core. Este plugin simplemente establece la propia conexión SFTP; Acepté cuando el criador no tenía más tiempo antes. Si cree que tiene un error demostrable al intentar acceder a los archivos, entonces es mejor generarlos en Trac, porque como digo, el código para eso está en el fondo y no en este plugin.
David
(@tgoeg)
Hace 1 año, 11 meses
Este plugin no parece ser un error en el plugin, así que no, no puedo señalar el mal funcionamiento.
Sin embargo, creo que los usuarios deben ser informados de que la configuración de SFTP con chroot no funcionará en php 7+. (FWIW, FTP (S) tampoco funcionará).
¿Conoce la configuración de trabajo en php 7+? Si es así, por favor proporcione detalles del archivo / permisos de directorio raíz de webroot y / o si está crootado.
Creo que esto debe ser algún otro tipo de solución, ya sea con la implementación de un servidor SFTP que puede generar un directorio que no está enraizado (o el directorio debe ser de escritura para un grupo u otros, que debe evitarse) o simplemente uno que no chroot (también debe evitarse).
Si puedo encontrar trabajo para reparar el corazón, definitivamente publicaré información aquí para que otros puedan ahorrar la resolución de problemas.
(@ andyg5000)
Hace 1 año, 6 meses
He estado usando este plugin durante un tiempo en mi configuración de alojamiento. Las actualizaciones recientes han dejado de funcionar. Mientras explora wp-admin/includes/class-wp-filesystem-base.php, Me di cuenta de que el FTP_* las constantes se aplican solo cuando FS_METHOD el cable «ftp» está ahí. Hackear un corazón con el siguiente cambio soluciona este problema, pero no quiero hacer eso.
if ( stripos( $this->method, 'ftp' ) !== false || $this->method === 'ssh2') {
No soy un WP WP, así que no sé cuál es la mejor manera de resolver esto. Espero que nos ayude a guiarnos en la dirección correcta.
(@davidanderson)
Hace 1 año, 6 meses
Hola,
¡Mejórate! ¿Puedes probar la versión de lanzamiento directo 0.8.2?
David
(@tgoeg)
Hace 1 año, 6 meses
Definitivamente lo arregla, ¡w00t!
Tuve que definir las siguientes variables:
define( 'FTP_USER', 'user' ); #most likely not necessary, can be entered in the web form as well
define( 'FTP_HOST', '127.0.0.1:22' );
define( 'FTP_BASE', 'wwwroot' ); #the bind mounted directory to /var/www/wordpress, necessary b/c we chroot
define( 'FTP_CONTENT_DIR', 'wwwroot/wp-content/' ); #the *relative* path as seen after an sftp login
define( 'FTP_PLUGIN_DIR ', 'wwwroot/wp-content/plugins/' ); #see above
define( 'FS_METHOD', 'ssh2' );¡Muchas gracias! Si es posible, agregue esto al manual, ya que todos los ejemplos que vi en línea usan rutas completas, que no funcionan. La prueba con sftp desde la línea de comandos ayuda a comprender por qué. Además, si su configuración SSH está reforzada y no acepta todos los cifrados / MAC, se debe agregar una excepción a / etc / ssh / sshd_config:
MACs [..],hmac-sha2-256
¿Solucionó tu problema??
0 / 0