Your feed appears to be encoded as “UTF-8”, but your server is reporting “US-ASCII” (solución)

Al realizar la validación de nuestro feed, hemos encontrado que nos salía este error un tanto curioso, “Your feed appears to be encoded as UTF-8, but your server is reporting US-ASCII“, no obstante la solución es sencilla, ya que este error lo estaba causando el plugin para hacer cache W3 – Total Cache, lo único que hay que hacer, es ir a General Settings -> Page Cache

Asegurarse de tener desmarcada esta opción:

Cache feeds: site, categories, tags, comments
Even if using a feed proxy service (like FeedBurner), enabling this option is still recommended.

Es posible, que según la configuración del servidor tengáis también que añadir estas opciones a vuestro httpd.conf/.htaccess

AddCharset UTF-8 .php
AddType text/html;charset=utf-8 .html
AddType text/xml;charset=UTF-8 .rss

Ajustad UTF-8 a vuestro sistemas de codificación si es distinto.

W3 Total Cache – Cookie is Rejected (solución)

Bien, recientemente estamos haciendo pruebas con W3 Total Cache para reducir la carga de nuestro servidor y poder servir páginas web más rapidamente, pero por algún motivo nos salía este error de cache (mirando el código fuente desde el navegador) si habíamos realizado un comentario (o teniamos una cookie creada previamente), el problema es que WordPress asigna por defecto una cookie a nuestro navegador de una duración de un año si hemos realizado algún comentario en cuestión (30000000 segundos), y entonces el usuario no se le puede servir con la cache de W3 Toal Cache, dónde la única solúcion posible es que él mismo usuario borre la cache y las cookies de su propio navegador, o tener que esperar hasta que la cookie caduque. Un año de espera es un castigo considerable en este caso para W3 Total Cache y para nosotros!.

La solución consite en crear un pequeño filtro para que la cookie tenga menor tiempo de caducidad, y así se podrá continuar utilizando la cache después de este periodo.

En vuestro theme de wordpress en el fichero functions.php

function set_comment_cookie_lifetime($lifetime) {
        // numero en segundos, elejir a gusto este valor (5 minutos por ejemplo)
return 300;
}
add_filter('comment_cookie_lifetime', 'set_comment_cookie_lifetime');

En caso de querer que caduque de inmediato poner el valor en negativo (fecha anterior)

return -30000000;

Al estar la cookie con un valor en negativo, el propio navegador se encargará de no utilizarla y eliminarla.

Espero que os sirva si teneís este problema.

Instalar mod_pagespeed en Debian Etch & Otras desde el código fuente

Me propuse hoy instalar definitivamente mod_pagespeed, a pesar de que a priori la instalación de este módulo puede ser sencilla, la cosa se complica si tienes una distribución algo antigua y oficialmente no soportada, no obstante, una vez logrado el objetivo de instalar el módulo, mod_pagespeed funciona igual de bien que en las demás distribuciones soportadas, simplemente que los que no podemos actualizar a una versión más actual (Debian Lenny), tenemos que hacer “algo más” para hacerlo funcionar en nuestra distribución, este preceso, es válido para otras distribuciones que tampoco están oficialmente soportadas.

¿Que és mod_pagespeed?, creo que con el video nos va a quedar claro cual es la intención de este módulo

Para realizar este tutorial, tuvimos que abir un ticket a los desarolladores de google, para que nos intentasen solucionar errores que no salían durante la compilación, dónde alfinal todo fué más que correcto por parte de ellos :)

Como requisitos mínimos se exige tener instalado GCC 4.2, si embargo Debian Etch trae de serie GCC 4.1, pero esto no ha añadido ningún problema, ya que finalmente también permite la compilación del módulo con la versión 4.1, de hecho, primero se intentó compilarlo con 4.2, pero aún así daba exactamente los mismos errores de compilación.

Aquí teneís la guia oficial de compilación, para las distribuciones soportadas mediante los fuentes de mod_pagespeed, en la nuestra simplemente se añaden problemas/soluciones para la instalación en distribuciones no soportadas.

Vamos a compilar mod_pagespeed:

# cd /usr/local/src

# svn co http://src.chromium.org/svn/trunk/tools/depot_tools

bash: svn: command not found

# aptitude install subversion

# svn co http://src.chromium.org/svn/trunk/tools/depot_tools

# export PATH=$PATH:/usr/local/src/depot_tools

# mkdir mod_pagespeed

# cd mod_pagespeed

# gclient config http://modpagespeed.googlecode.com/svn/tags/0.9.1.1/src

# gclient sync --force

# cd src

# make BUILDTYPE=Release

make: flock: Command not found
make: *** [out/Release/obj.target/net/instaweb/libmod_pagespeed.so] Error 127

# cd /usr/local/src

# wget http://www.kernel.org/pub/linux/utils/util-linux-ng/v2.18/util-linux-ng-2.18.tar.gz

# tar xvfz util-linux-ng-2.18.tar.gz

# cd util-linux-ng-2.18
# mkdir -p /opt
# ./configure --prefix=/opt/util-linux-ng-2.18
# make
# make install

# export PATH=$PATH:/opt/util-linux-ng-2.18/bin

# cd /usr/local/src/mod_pagespeed/src/

# make BUILDTYPE=Release

CC(target) out/Release/obj.target/apr/third_party/apache/apr/src/locks/unix/proc_mutex.o
third_party/apache/apr/src/locks/unix/proc_mutex.c: In function ‘proc_mutex_proc_pthread_create’:
third_party/apache/apr/src/locks/unix/proc_mutex.c:385: error: ‘PTHREAD_MUTEX_ROBUST_NP’ undeclared (first use in this function)
third_party/apache/apr/src/locks/unix/proc_mutex.c:385: error: (Each undeclared identifier is reported only once
third_party/apache/apr/src/locks/unix/proc_mutex.c:385: error: for each function it appears in.)
third_party/apache/apr/src/locks/unix/proc_mutex.c:393: error: ‘PTHREAD_PRIO_INHERIT’ undeclared (first use in this function)
make: *** [out/Release/obj.target/apr/third_party/apache/apr/src/locks/unix/proc_mutex.o] Error 1

# GYP_DEFINES="use_system_apache_dev=1" gclient runhooks

# make BUILDTYPE=Release

CXX(target) out/Release/obj.target/html_rewriter/net/instaweb/apache/apache_message_handler.o
net/instaweb/apache/apache_message_handler.cc:21:19: error: httpd.h: No such file or directory
net/instaweb/apache/apache_message_handler.cc:25:22: error: http_log.h: No such file or directory
…..
net/instaweb/apache/apache_message_handler.cc:61: error: ‘ap_log_error’ was not declared in this scope
make: *** [out/Release/obj.target/html_rewriter/net/instaweb/apache/apache_message_handler.o] Error 1

# aptitude install apache2-threaded-dev libapr1-dev libaprutil1-dev

# make BUILDTYPE=Release

!POR FIN COMPILA!

# cd installl
# make APACHE_ROOT=/etc/apache2 APACHE_MODULES=/usr/lib/apache2/modules APACHE_USER=www-data staging
# make APACHE_ROOT=/etc/apache2 APACHE_MODULES=/usr/lib/apache2/modules APACHE_USER=www-data install

Cosas a verificar:

Verificar los permisos, y que el módulo se esté cargando mediante el fichero pagespeed.conf

LoadModule pagespeed_module modules/mod_pagespeed.so
LoadModule deflate_module modules/mod_deflate.so

Permisos de escritura www-data en /var/mod_pagespeed
Include conf/pagespeed.conf en el fichero de Apache (apache2.conf o httpd.conf)

Ver las diferencias entre tener activado o no mod_pagesped:

http://www.webpagetest.org

Como solucionar el error Mysql [Warning] Changed limits

En un servidor con suficiente tráfico y muchas consultas de base de datos, en ocasiones hay que incrementar el valor por defecto del my.cnf del parametreo max_connections a un valor más adecuado, por ejemplo 1024

max_connections = 100
a
max_connections = 1024

Ya que sinó, la base de datos puede ser insuficiente. Justamente hoy me he dado cuenta de que el servidor se ha vuelto a saturar y mirando los logs, me he dado cuenta de que cada vez que reiniciaba MySQL, él “ajustaba” automáticamete esos valores de max_connections a otro inferior, en este caso a 886, así que existia una limitación del sistema operativo que forzaba el reajuste.


090616 13:49:22 mysqld started
090616 13:49:22 [Warning] Changed limits: max_open_files: 1024 max_connections: 886 table_cache: 64

La solución es bien sencilla, simplemente hay que añadir una linea similar arriba de todo del script o ponerlo en el bash_profile/bashrc, o si quieres hacerlo más elegante, deberiamos de mirar de configurar correctamente el fichero limits.conf (yo he optado por ponerlo encima del script)

ulimit -n valor (por defecto es 1024)
ulimit -n 2048

Realizamos un ulimit -n para ver que realmente se ha cambiado el valor, y volvemos a reiniciar MySQL con nuestro problema resuelto!