Soporte » WordPress Avanzado » function wp_ob_end_flush_all

  • ResueltoModerador almendron

    (@almendron)


    1) En su momento abrí un hilo porque aparecía lo siguiente cuando activaba el debug:
    Notice: ob_end_flush(): failed to send buffer of zlib output compression (1) in /xxxx//wp-includes/functions.php on line 3721

    2) El mencionado hilo se cerró como resuelto al añadir la siguiente línea en el archivo functions.php (el de la carpeta plugins): remove_action( 'shutdown', 'wp_ob_end_flush_all', 1 );

    3) Sin embargo y tras una comprobación hoy mismo (he activado el debug) , me encuentro con que esa solución resuelve el problema solo de forma parcial. El mensaje ha desaparecido de la vista de los artículos pero se mantiene cuando instalo un plugin. Es como si el «remove» no funcionara en el área de la administración.

    4) He encontrado un código que en principio resuelve del todo el problema:

    function wp_ob_end_flush_all() {
     $levels = ob_get_level();
     //Edit by DK
     for ($i=0; $i<$levels; $i++){
      $obStatus = ob_get_status();
      if (!empty($obStatus['type']) && $obStatus['status']) {
       ob_end_flush();
      }
     }
    }

    5) Ahora bien, este código sustituye al original del archivo wp-includes/functions.php. Esto significa que tendré que volver a cambiarlo cada vez que se actualice WordPress. Y la pregunta: ¿cómo puedo evitar esto último? ¿hay alguna forma de hacerlo?

    • Este debate fue modificado hace 2 años, 8 meses por almendron.

    La página con la que necesito ayuda: [accede para ver el enlace]

Viendo 8 respuestas - de la 1 a la 8 (de un total de 8)
  • Hola @almendron miraste en la configuración de tu PHP si tienes activada por defecto la compresión Zlib? probaste a desactivarla con un <?php ini_set("zlib.output_compression", "Off");?> por ejemplo en el wp-config.php ?

    La función wp_ob_end_flush_all no la puedes sobreescribir ya que no se encuentra entre las Pluggable Functions, si desactivando Zlib por defecto no se soluciona habría que buscar el hook adecuado para desactivar la función y crear la tuya propia que mencionas.

    Moderador almendron

    (@almendron)

    Está activada:

    zlib.output_compression	On	On
    zlib.output_compression_level	-1	-1

    Una duda: ¿qué sucede si desactivo la compresión Zlib? ¿no me quedaré sin compresión? Quiero decir: ¿no es peor el remedio que la enfermedad?

    Hola @almendron, si desactivas la comprensión zlib no debería suceder nada, ya que la compresión siempre debe realizarse desde el propio servidor web (Apache ó Nginx) y no desde el lenguaje de programación (PHP), es decir, lo que realizan los plugins de caché es añadir las líneas de compresión al .htaccess del tipo:

    
    # Gzip compression
    <IfModule mod_deflate.c>
    # Active compression
    SetOutputFilter DEFLATE
    # Force deflate for mangled headers
    <IfModule mod_setenvif.c>
    <IfModule mod_headers.c>
    SetEnvIfNoCase ^(Accept-EncodXng|X-cept-Encoding|X{15}|~{15}|-{15})$ ^((gzip|deflate)\s*,?\s*)+|[X~-]{4,13}$ HAVE_Accept-Encoding
    RequestHeader append Accept-Encoding "gzip,deflate" env=HAVE_Accept-Encoding
    # Don’t compress images and other uncompressible content
    SetEnvIfNoCase Request_URI \
    \.(?:gif|jpe?g|png|rar|zip|exe|flv|mov|wma|mp3|avi|swf|mp?g|mp4|webm|webp)$ no-gzip dont-vary
    </IfModule>
    </IfModule>

    o

    
    # Compress all output labeled with one of the following MIME-types
    <IfModule mod_filter.c>
    AddOutputFilterByType DEFLATE application/atom+xml \
    		                          application/javascript \
    		                          application/json \
    		                          application/rss+xml \
    		                          application/vnd.ms-fontobject \
    		                          application/x-font-ttf \
    		                          application/xhtml+xml \
    		                          application/xml \
    		                          font/opentype \
    		                          image/svg+xml \
    		                          image/x-icon \
    		                          text/css \
    		                          text/html \
    		                          text/plain \
    		                          text/x-component \
    		                          text/xml
    </IfModule>

    Si la compresión se basa en PHP cambia de plugin.

    Dicho esto, no quiere decir que desactivando la salida Zlib automática de PHP vaya a solucionar tu problema, pero sería una de las primeras cosas a comprobar, es fácil y rápido desactivarlo y si hay algún problema volverlo a activar. Puedes comprobar fácilmente si el contenido tiene habilitada la compresión desde el inspector web de tu navegador

    • Esta respuesta fue modificada hace 2 años, 8 meses por Carlos Longarela. Razón: link de imagen
    Moderador almendron

    (@almendron)

    Respecto al problema original: he desactivado en el .php.ini la compresión mediante zlib.output_compression = off y parece que todo funciona bien.

    No uso plugin de cache y de hecho no he encontrado el origen del problema. En cualquier caso, dices que «la compresión siempre debe realizarse desde el propio servidor web (Apache ó Nginx) y no desde el lenguaje de programación (PHP)»

    Me he puesto en contacto con el soporte del hosting para que lo miren y me digan algo porque me da la impresión de que la compresión está activada a nivel de PHP.

    Te digo algo en cuanto me contesten.

    Hola @almendron acabo de volver a comprobar tu página y sigue activada la compresión gzip de los contenidos por lo que no se realiza desde PHP (como es lógico), está activada en el servidor web ya que por PHP se debe realizar mediante programación (algo que no van a hacer desde el hosting ya que tendrían que modificar los archivos de tu WP), si no está puesto en el .htaccess estará puesta la directiva a nivel de configuración global del sitio web en el Apache:

    Las cabeceras de tu página principal mostrando que tiene la compresión gzip activada:

    
    HTTP/1.1 200 OK
    Date: Tue, 31 Oct 2017 16:39:36 GMT
    Server: Apache
    Link: <https://www.almendron.com/tribuna/wp-json/>; rel="https://api.w.org/", <https://wp.me/4NO7>; rel=shortlink
    Vary: Accept-Encoding
    Content-Encoding: gzip
    Cache-Control: max-age=0
    Expires: Tue, 31 Oct 2017 16:39:36 GMT
    Content-Length: 50636
    Keep-Alive: timeout=3, max=500
    Connection: Keep-Alive
    Content-Type: text/html; charset=UTF-8

    El problema se debe a que al tener activada por defecto la compresión Zlib desde PHP aunque no se utilice, esta escribe al buffer de salida antes de que se pueda vaciar el mismo mediante ob_end_flush()

    Moderador almendron

    (@almendron)

    En el info aparece:

    1) Sección Phar: gzip compression enabled

    2) Sección PHP Variables: $_SERVER['HTTP_ACCEPT_ENCODING'] gzip, deflate, br

    No se si esto te dice algo. En el .htaccess no hay nada.

    Si, la directiva $_SERVER['HTTP_ACCEPT_ENCODING'] gzip, deflate, br indica que está activada la compresión desde el propio Apache, con lo que la directiva de php zlib.output_compression = off estaría correcta ya que con zlib activado te causaría más problemas que posibles soluciones (no creo que vayas a utilizar zlib para nada teniéndolo activado desde el servidor web).

    Moderador almendron

    (@almendron)

    Pues perfecto. Da gusto plantear aquí los problemas 🙂

    Muchísimas gracias, Carlos.

Viendo 8 respuestas - de la 1 a la 8 (de un total de 8)
  • El debate ‘function wp_ob_end_flush_all’ está cerrado a nuevas respuestas.