• Resuelto abkrim

    (@abkrim)


    Hola

    TRas una actualizacion de Apache 2.4 con PHP 5.5.32 mis clientes estan teniendo problemas para actualizar WordPress y modulos.

    Escenario:
    Apache 2.4 PHP 5.5.32 en modo SuPHP (usuario ejecuta el proceso PHP)
    Mod Security 2.9
    mod Securty descativado para el usuario y su dominio de forma global.

    Se activa el debug en el wp-config.php

    define('WP_DEBUG', true);
    define('WP_DEBUG_LOG', true);
    define('WP_DEBUG_DISPLAY', false)

    No se ha podido completar la actualización automática de WordPress. Por favor, vuelve a intentarlo.

    El log wp-content/debug.log no muestra error alguno salvo los porpios de algunos plugins.

    En el caso de la actualizacion de wordpress, este no muestra nada Ningun log arroja ningun tipo de error

    #94.23.XXX.XXX es mi ip
    tail -f /usr/local/apache/logs/error_log|grep 94.23.XXX.XXX
    tail -f /usr/local/apache/logs/modsec_audit.log |grep 94.23.XXX.XXX
    tail -f wp-content/debug.log

    En el caso de los plugins
    Algunos ponene ne mantenimiento el sitio, pero no se actualizan. (YoastSEO)
    Otros se quedan eternamente esperando…(Broken Link Checker)

    Si ponemos varios de un tiron, el sistema se queda pensando y en mantemiento.

    He verificado que las Ip de downloads.wordpress.org no esten en mi firewall bloquedas

    # dig +short downloads.wordpress.org
    66.155.40.186
    66.155.40.187
    66.155.40.188
    66.155.40.189
    
    # csf -g 66.155.40.
    
    Chain            num   pkts bytes target     prot opt in     out     source               destination
    No matches found for 66.155.40. in iptables

    Configuro FTP de acuerdo a https://codex.wordpress.org/Editing_wp-config.php

    define( 'FTP_BASE', '/home/XXXXX/public_html/' );
    define( 'FTP_CONTENT_DIR', '/home/XXXXX/public_html/wp-content/' );
    define( 'FTP_PLUGIN_DIR ', '/home/XXXXX/public_html/wp-content/plugins/' );
    define( 'FTP_PUBKEY', '/home/XXXXX/.ssh/id_rsa.pub' );
    define( 'FTP_PRIKEY', '/home/XXXXX/.ssh/id_rsa' );
    define( 'FTP_USER', 'wp@XXXXX.com' );
    define( 'FTP_PASS', 'XXXXXXXXXX' );
    define( 'FTP_HOST', 'localhost' );
    define( 'FTP_SSL', false );

    Timeout sin que se vea algun log en el ftp, nada… parace que ni siquiera funcione.

    Actualizar WordPress

    Descargando paquete de instalación desde https://downloads.wordpress.org/release/es_ES/wordpress-4.4.2.zip…

    Descomprimiendo actualización…
    ….

    Pero nada, pasada 1 hora seguimso sin log, sin error, y sin actualizarse.

    Como he dicho, y en prevision de algunas contestacion del tipo «permisos de los directorios» decir que el servidor esta en modo SuPHP, y que por tanto los permisos de 755 ó 750 para los directorios que intervienen son validos.

    Se aceptan todo tipo de ideas.

Viendo 4 respuestas - de la 1 a la 4 (de un total de 4)
  • Moderador almendron

    (@almendron)

    Yo empezaría por lo básico:
    1.- Renombra la carpeta «plugins». Con ello los desactivamos todos.
    2.- Cambia el tema activo a alguno de los que trae por defecto wordpress. De esa forma, descartamos que el tema origine algún problema.
    2.- Haz una actualización manual: https://codex.wordpress.org/es:Actualizar_WordPress

    Creo que tu problema está con la configuración del directorio temporal. ¿Lo tienes configurado en PHP, existe y se puede escribir en él?

    Se puede definir también en wp-config.php, por ejemplo:

    define('WP_TEMP_DIR', ABSPATH . 'wp-content/temp/');

    Aunque no vas a hacer eso en cada instalación de cada cliente, sería muy engorroso. Comprueba la configuración general del directorio temporal en el servidor.

    Iniciador del debate abkrim

    (@abkrim)

    Gracias @almendron. La Penosa y fea solucion de wodpres de Actualizar de 0 es la que me ha quedado. Es lamentable que el sistema de debug de wordpress, sea tan penoso. Bueno el de el y el de los plugins.
    Gracias @cybmeta, la que me cuenta la sabia, pero otra que también es penosa de WP. Pese a poner esa variable resulta que algunas instalaciones antiguas tienen ese valor en mysql, y algunos a de las instalaciones que fallaron, resultaron que venian de un /home2/user en vez de /home/user. Lo suyo seria que el define tuviera preferencia sobre cualquier valor guardado en Mysql.
    Cada vez me gusta menos WP.
    Un saludo.

    A mi me gusta tanto WordPress que cuándo veo a alguien haciendo ese tipo de comentarios siento un poco de pena. Me gustaría que a todo el mundo le gustase tanto como a mí ;). Pero bueno, nunca llueve a gusto de todos. Hay que aceptarlo

    De todas formas, como te decía, estoy convencido 99.9% que el problema se debía a tu configuración de PHP y no a WordPress. De hecho, el problema aparece cuándo actualizas Apache y PHP, no cuándo actualizas WordPress.

    Y lo que dices que WordPress guarda al ruta al directory temporal de PHP en la base de datos, no se que yo que decirte. Que yo sepa, WordPress no hace eso.

    Es más, si te fijas en el código fuente de código fuente de get_temp_dir(), función introducida hace 8 años en la versión 2.5, nunca se hace referencia a la base de datos y, como reclamas, la prioridad es la constante WP_TEMP_DIR si esta ha sido definida.

    Te agradecería si pudieras compartir la configuración PHP referente al directorio temporal, tanto la del servidor como la del usuario, y esa entrada que dices de la base de datos que yo nunca he visto, podríamos salir de dudas.

    Y no se, se me acaba de ocurrir que la entrada en la base de datos sea upload_path, una opción que fue eliminada del UI hace cuatro años, salvo que no tenga el valor predeterminado sino otro establecido por el usario.

    La verdad que me gustaría entender cual ha sido el problema, igual hay algo que solucionar o hacer mejor y se puede hacer.

Viendo 4 respuestas - de la 1 a la 4 (de un total de 4)
  • El debate ‘Imposible realizar un debug sobre problemas de actualizacion’ está cerrado a nuevas respuestas.