Archivo de la categoría: blog

Desde hace tiempo tenía curiosidad por saber si era viable poner publicidad en el blog. Nunca he trabajado con temas de publicidad en páginas web y esta sería una buena oportunidad para aprender como se implementan y cual es su funcionamiento.

Yo soy el primero que utiliza bloqueadores de anuncios para navegar por internet, así que quería que el impacto en la estructura de la página fuese mínimo y no resultasen molestos. Me decidí por un anuncio en la barra lateral en pantallas grandes, y un anuncio horizontal encima del artículo en pantallas de móvil.

He realizado un par de experimentos y los resultados han sido concluyentes.

Google AdSense

La principal ventaja de usar AdSense es la sencillez. Una de las opciones es simplemente añadir un pequeño código JavaScript y automáticamente te inserta anuncios en la página. Hice la prueba y me parecieron demasiado intrusivos, por lo que pasé a usar las otras opciones con tamaños estáticos. También es interesante que los anuncios se adaptan al visitante, por lo que es indiferente desde que país te visitan. Como contrapartida no puedes elegir el anuncio que se mostrará, aunque si puedes filtrar algunas de las categorías.

La idea inicial era dejar estos anuncios durante un mes, pero tras 6 días los resultados han sido tan claros que que decidido dar el experimento por concluido. Los números son:

• Páginas vistas: 3870
• Impresiones de anuncios: 1657
• Clics: 0

Con estos números he obtenido un beneficio de 0,02€. Así que calculo que en un mes ganaría un total de 8 centimos, lo que no compensa en absoluto el tiempo invertido en su gestión y mantenimiento.

Sinceramente no esperaba un resultado tan abismal. Diría que la clave está en los clics y en este caso supongo que los anuncios no eran interesantes para mis visitantes. Tal vez el algoritmo de Google necesita más tiempo para ir ajustando que es lo que se muestra, pero con unos resultados iniciales tan pobres no tengo la paciencia de esperar unos meses. Tal vez en el futuro repita el experimento por comprobar si hay alguna mejoría.

Amazon Programa de Afiliados

Viendo el escaso éxito de AdSense me decidí a probar el Programa de Afiliados de Amazon. Como ventaja, tu eliges que producto quieres que se exponga en el anuncio. Por otro lado, solo obtienes beneficios si alguien entra en Amazon a través de tu enlace y realiza una compra. Esto supone dos grandes inconvenientes:

• El enlace es a la tienda de un país, en este caso España. Eso significa que los visitantes de otros países no pueden realizar una compra a través del enlace.
• Tienes que elegir un producto que sea interesante para tus visitantes, y probablemente ese producto será distinto según el artículo al que ha llegado tu visitante. Eso significa que necesitaría un sistema que mostrara anuncios distintos según el contenido del artículo, lo cual supone un mayor esfuerzo de mantenimiento.

Todo esto sería asumible si la recompensa lo justificara, pero los resultados tras 11 días de experimento han sido:

• Impresiones de anuncio: 5168
• Clics: 13
• Compras: 0

Esto suponen unos beneficios totales de 0€. Un fracaso como negocio, pero al menos los resultados con concluyentes.

Conclusión

El mundo de la publicidad en internet es complejo y gracias a este experimento he aprendido lo más básico sobre su funcionamiento, pero requería por mi parte mucho más tiempo, esfuerzo y dedicación para poder sacarle partido y no es algo en lo que quiera adentrarme en estos momentos.

Desde hace ya un tiempo he querido abandonar WordPress como motor para mi blog. Las razones para ello son múltiples, pero las más destacadas serían:

• Realizar copias de seguridad de manera más sencilla.
• Tener los artículos en un formato más exportable.
• Despreocuparme de las actualizaciones.
• Mejor seguridad.

Hace un tiempo estuve leyendo sobre Jekyll que te permite crear blogs como páginas estáticas a partir de documentos en Markdown. Me gustó mucho el concepto así que he investigado que otras alternativas similares existen. La alternativa más fuerte es Hugo. La verdad es que ambos sistemas son excelentes, y no creo que ahora mismo exista un claro vencedor entre los dos, y dependerá más de otras circunstancias a la hora de elegir. En mi caso me he decantado por Hugo por un motivo, y es que la migración automática WordPress-Jekyll estaba llena de errores, mientras que la WordPress-Hugo fue mucho mejor, reduciendo considerablemente las correcciones a realizar.

Podría haber lanzado los cambios tal cual, pero ya que hacía esta migración quería dejar los ficheros con un código Markdown lo más limpio posible, y me he pegado una buena paliza revisando todos los artículos del blog desde sus inicios. Ha sido un tanto agotador, pero también ha sido divertido releer mis ideas de los últimos 8 años. Además me ha venido bien para limpiar un buen número de enlaces que han muerto a lo largo de los años.

Apenas recuerdo cual fue el primer tema que utilicé para Wordpress, pero no debía de estar muy contento con él, porque en cuanto salió el TwentyFourteen me cambié sin dudarlo. Me gustaba la estructura, se adapta bien a pantallas pequeñas y ser el tema oficial me daba seguridad.

A lo largo de estos últimos años me he dado cuenta de algunas de sus limitaciones, pero por pereza no me decidía a sustituirlo. También ha ayudado que pese a ser el tema por defecto, no lo he visto usado en demasiados blogs, por lo que no me ha dado esa sensación de saturación.

Sin embargo por varios motivos, creo que es el momento de cambiar el tema. Tras buscar un tema de mi agrado, no he encontrado nada que cumpla con mis necesidades, así que me he dispuesto a desarrollar mi propio tema a partir de underscores.

¿Qué objetivos quiero lograr con este nuevo tema?

• Mejorar mis conocimientos y abilidades con SASS.
• Mejorar la usabilidad en dispositivos móviles.
• Mejorar la lectura en pantallas grandes.
• Mejorar la visualización de los ejemplos de código.
• Reducir el tamaño, tiempo de carga y número de peticiones.

Como punto de partida he intentado diseñar una estructura para tres tamaños de pantalla, pequenas, medianas y grandes. Para ello he investigado un buen puñado de blogs, analizando cada uno de sus componentes e intentando razonar la necesidad y diseño de cada uno de ellos.

Vista pequeña para dispositivos móviles

Entre los blogs que he analizado he encontrado tres aproximaciones para esta vista.

• Mostrar los artículos completos
• Mostrar un extracto
• Mostrar solo el título

No creo que exista una aproximación correcta. Creo que cada una es ideal para un tipo de blog y contenido. Si tu objetivo es que el usuario empiece a leer tus entradas en orden cronológico nada más aterrice en tu blog, mostrar el artículo completo es una buena opción.

Tal vez tu blog tiene distintos tipos de contenidos, o distintos autores, y quieres que tu usuario vea esa variedad en la página principal, con un pequeño extracto para atraerle hacia el contenido completo, probablemente un artículo largo. Aquí el extracto tiene sentido.

¿Pero qué tipo de artículos tiene mi blog? Alguien que aterriza en mi página principal por primera vez, ¿va a empezar a leer todas mis entradas en orden cronológico? Probablemente no. Estudiando las estadísticas de los usuario, muy pocos llegan directamente a la página principal. La mayoría llegan por búsquedas o enlaces directos, y por tanto llegan a alguno de los artículos.

¿Cual es entonces mi principal objetivo cuando alguien llega a la página principal de mi blog? Mi objetivo es que lean al menos uno de mis artículos. Como los temas de los que hablo son diversos, es posible que no encuentren nada que les interese entre los primeros artículos, por lo que debería de mostrar una vista que refleje esa variedad de artículos. Puede que incluso mostrando esa variedad, no encuentren nada que les interese, y por tanto me parece interesante mostrar también las categorías. Por último, mostraré la fecha de publicación de los artículos. Considero que ver que los artículos tienen una fecha reciente refleja que el blog está vivo y aumenta el interés en leerlo.

Hace ya tiempo que estoy concienciado de lo importante que son las copias de seguridad, pero aún así no siempre me acuerdo de tener las copias al día. Es por esto que lo ideal es tener todo el proceso automatizado, pero no todos los servidores web nos ofrecen esta opción. Hasta ahora siempre he usado hostings gratuitos. El servicio no era el mejor y tiene múltiples inconvenientes, pero sobre todo se quedan muy pobres en las opciones que ofrecen para realizar copias de seguridad. Esto, unido a que tras actualizarme a la última versión de WordPress empezó a fallar el blog, me decidieron a buscar un servidor de pago.

Mis requisitos eran tener acceso al servidor por SSH y poder crear tareas CRON. Tras comparar algunas opciones, me decidí por 1and1, que tenía el mejor precio y cumplía con mis requisitos. He leído que su servicio de atención al cliente no es el mejor, pero las dudas que yo he tenido me las han respondido con rapidez.

Dicho esto, empecemos con la copia de seguridad:

Yo tengo el WordPress en el directorio raíz del FTP. Debería haberlo puesto en una subcarpeta, pero ahora ya no me apetece cambiar, así que se queda así y buscaré como solucionar los problemas que salgan.

En el mismo directorio raíz he creado una carpeta llamada backup. Lo primero será impedir el acceso a esta carpeta. Para ello en el fichero .htaccess que también se encuentra en el raíz, añadimos lo siguiente:

<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /
RewriteCond %{HTTP_HOST} ^(www.)?la-url-de-tu-web.com$
RewriteRule ^backup - [F]
</IfModule>

En esta carpeta de backup tendremos dos ficheros que se encargarán de hacer las copias de seguridad de la base de datos y de los ficheros. Empecemos con la copia de seguridad de la base de datos. El fichero se llamará wordpress-backup-files.sh y su contenido será el siguiente:

#!/bin/sh
tar czf /path-to-files/backup/`date "+%Y%m%d-%H-%M"`-wordpress-files.tar.gz /path-to-files/ --exclude='/path-to-files/backup' --exclude='/path-to-files/backup/*' --exclude='/path-to-files/logs' --exclude='/path-to-files/logs/*'

El primer parámetro será el nombre del fichero con el contenido del blog. Se genera automáticamente con la fecha. Los --exclude especifican que ficheros y carpetas no queremos añadir a la copia. En este caso, como nuestra carpeta de backup está al mismo nivel que el resto, la excluimos, así como su contenido, y hacemos lo mismo con la carpeta de logs.

La segunda parte será hacer una copia de seguridad de la base de datos. De ello se encargará el fichero wordpress-backup-bd.sh cuyo contenido será:

mysqldump -h [host de la base de datos] -u [usuario] -p[contraseña] [nombre de la base de datos] | gzip > /path-to-files/backup/$(date +%Y%m%d-%H-%M)-wordpress-mysql.gz

Por último tendremos que programar el cron para que ejecute estos dos ficheros. En mi caso lanzaré la copia de seguridad el domingo a las 3:00 la base de datos y a las 3:30 los ficheros:

#Weekly database backup
0 3 * * 0 /path-to-files/backup/wordpress-backup-bd.sh

#Weekly files backup
30 3 * * 0 /path-to-files/backup/wordpress-backup-files.sh

Durante el tiempo que he tenido alojado el blog en servidores gratuitos, no he podido utilizar Akismet. Uno de sus requisitos es poder conectarse directamente a la base de datos de Akismet, de donde se obtiene la información sobre spam, pero en los servidores gratuitos esto no era posible. Sin embargo, ahora que tengo un servidor decente he podido tener Akismet en marcha durante un tiempo, y he acabado un tanto decepcionado.

La primera impresión fue buena, con Akismet el spam desapareció, pero también desaparecieron algunos comentarios que sí eran válidos. Y ese es el problema con Akismet, es increíblemente restrictivo y puede hacer desaparecer comentarios correctos. Es más, durante las últimas semanas, se empezaron a colar comentarios spam en el blog. Igual uno cada dos o tres días, pero comentarios que son descaradamente spam, escritos en inglés, con un texto genérico, apuntando a una URL de publicidad y con un email sospechoso. Y Akismet los daba por válidos. ¡Pues menuda decepción!

Estuve tentado de volver a mi solución anterior, que me había dado excelentes resultados. El problema es que ese código se machaca al realizar una actualización de WordPress, por lo que es costoso de mantener. Lo ideal sería tener un plugin que ofreciese esa funcionalidad, y buscando por internet eso es justo lo que encontré.

El plugin se llama Invisible Captcha y hace exactamente lo que hacía yo, pero en forma de plugin. Añade un campo oculto y aleatorio al formulario de envío de comentarios y después comprueba si el valor del campo es correcto. En caso contrario, el comentario es spam. Lo he usado unas semanas y funciona de lujo. No se ha colado ni un comentario de spam.

Por defecto Invisible Captcha ofrece tres opciones, marcar como spam, marcar para moderación o enviar a la papelera. En mi caso, no quería ni verlos en la papelera, quería que directamente desaparecieran para no tener que estar vaciando la papelera cada dos por tres. Para ello borro el comentario en cuanto es marcado como basura:

if ($invisible_captcha_spam_action=='delete') {
    wp_set_comment_status($id, 'trash');
    wp_delete_comment($id);
    wp_die($invisible_captcha_spam_message, '', array('response' => 403));
}

La línea que he añadido es wp_delete_comment($id); Es importante que el comentario se haya marcado primero como ‘trash’ ya que el método wp_delete_comment solo borra un comentario que ya esté en la papelera.

En definitiva, recomiendo Invisible Captcha como alternativa a Akismet para evitar el spam automático. En blogs con mucho tráfico donde tal vez el spam es introducido por humanos, Invisible Captcha sería inútil. Pero tampoco se como de eficaz sería Akismet en ese caso. De momento para mi blog, me basta y me sobra.

Cuando pensaba que había encontrado el método definitivo anti-spam, resultó no ser eficaz ni durante un día entero. Algunos de los comentarios se estaban marcando correctamente como SPAM, que deben ser los que atacan directamente a wp-comments-post.php. Sin embargo seguían llegando algunos comentarios de SPAM, y no tengo ni idea de como lo están haciendo. Debe haber otra manera de hacer un POST de un comentario, pero por el momento no la he encontrado.

Lo que sí que me he dado cuenta, es que estos comentarios nunca tienen establecido un correo electrónico (al menos de momento). Utilizando ese dato, he complementado el método de identificación de SPAM con el requerimiento de un correo. En wp-includes/comment.php:

if(strpos($comment_content, '[THIS#IS#SPAAAM!]') !== false
    || !is_email($comment_author_email)){
    $comment_approved = 'spam';
}

De momento con esto estoy cazando todo el SPAM. ¡Veremos si dura!

La solución con la base de datos de SPAM debo reconocer que fue ingeniosa. Está muy en mi línea de “matar moscas a cañonazos”. El problema es que lo que se dice eficaz, no era. Digamos que el número de direcciones IP desde las que puede llegar SPAM, o el número de direcciones de correo o URLs que pueden usar en los comentarios están en un orden de magnitud tal que nunca voy a ser capaz de filtrar los comentarios basura.

Todo vuelve a la pregunta que me hice hace ya hace 9 meses: ¿Como estaban los bots de SPAM enviando comentarios saltándose el formulario de envío? Y por pura casualidad, encontré a que página están atacando. Probablemente están haciendo un POST directamente contra wp-comments-post.php.

Así que volvemos a la sencillez. ¿Como detectar un POST que llega a wp-comments-post.php sin pasar por comments.php? Fácil. Si los bots están lanzando un POST genérico para blogs en WordPress, añadamos un nuevo campo al formulario. Si en wp-comments-post.php detectamos que ese campo no está establecido, entonces se está saltando comments.php y debe ser SPAM. Está solución es tan eficaz que hace que mis dos soluciones anteriores queden obsoletas, así que para aligerar la página y reducir tiempo de procesado, elimino las modificaciones del código anteriores. El código definitivo quedaría de la siguiente manera:

Dentro de los ficheros del tema, en el fichero comments.php:

Añadimos un nuevo campo oculto al formulario:

<input type="hidden" id="comment_post_antirobot" name="comment_post_antirobot" value="0" />

Por si acaso el robot de SPAM está comprobando que campos tiene el formulario, cambiamos su valor por javascript:

<script type="text/javascript">
  document.getElementById('comment_post_antirobot').value = "1";
</script>

En wp-comments-post.php:

Obtenemos el valor del campo oculto, y en caso de no estar establecido o no ser igual a 1, marcamos el comentario como SPAM modificando el contenido:

$comment_antirobot    = ( isset($_POST['comment_post_antirobot']) ) ? trim($_POST['comment_post_antirobot']) : null;

if( empty($comment_antirobot) || $comment_antirobot == '0'){
    // It's SPAM
    $comment_content = '[THIS#IS#SPAAAM!] '.$comment_content;    
}

En wp-includes/comment.php, en el método wp_insert_comment:

Comprobamos si contiene la marca de SPAM en su contenido, y en ese caso lo etiquetamos como SPAM:

if(strpos($comment_content, '[THIS#IS#SPAAAM!]') !== false){
    $comment_approved = 'spam';
}

De momento, el SPAM que está llegando se está etiquetando todo automáticamente como tal. A ver cuanto dura la solución… aunque en esta tengo bastante confianza!

El método que implementé contra el SPAM, que comenté en esté articulo, ha estado funcionando bien, pero en los últimos 2 meses ha dejado de cazar todo el SPAM. Los últimos comentarios que están llegando sí que  traen el campo de email cumplimentado, por lo que ya no es efectivo. Dándole vueltas al asunto, se me ha ocurrido hacer mi propia base de datos anti-spam. La idea es que cada vez que llega un nuevo comentario, se comprueba con la base de datos si es SPAM, y en caso que lo sea, añadir sus datos para futuras comprobaciones. El código es el siguiente:

En wp_includes/comment.php en el método wp_insert_comment, justo antes de insertar el comentario hago esta comprobación:

if(!is_email($comment_author_email)){
    $comment_approved = 'spam';
}
else{
    $spam_query = "SELECT * FROM spam_data "
    ."WHERE data = '".$comment_author_IP
    ."' OR data = '".$comment_author_email
    ."' OR data = '".$comment_author_url."'";

    /*$spam_query = "SELECT * FROM spam_data "
    ."WHERE 1";*/

    $spam_results = $wpdb->get_results($spam_query);

    /*if(count($spam_results) <= 0){ // It's SPAM
        $comment_approved = 'spam';
    }*/

    if(count($spam_results) > 0){ // It's SPAM
        $comment_content .= " count: ".count($spam_results);
        $comment_approved = 'spam';

        insert_into_spam_data($comment_author_IP);
        insert_into_spam_data($comment_author_email);
        insert_into_spam_data($comment_author_url);
    }    
}

Y para añadir los datos a la BD he añadido este método:

function insert_into_spam_data($spam_data){
    global $wpdb;

    $spam_query = "SELECT * FROM spam_data "
    ."WHERE data = '".$spam_data."'";

    $spam_results = $wpdb->get_results($spam_query);

    if(count($spam_results) <= 0){
        $wpdb->insert(
            'spam_data',
            array(
                'data' => $spam_data
            ),
            array(
                '%s'
            )
        );
    }
}

Esto debería parar una buena parte del SPAM. El siguiente paso será que cuando yo marque manualmente un comentario como SPAM, sus datos también sean incluidos en la tabla con la información de SPAM. Para ello en el metodo wp_spam_comment, tras marcar el comentario como SPAM, añadimos este código:

insert_into_spam_data($comment->comment_author_IP);
insert_into_spam_data($comment->comment_author_email);
insert_into_spam_data($comment->comment_author_url);

Ahora faltará ver como de efectivas son las medidas. Me estoy planteando introducir algún otro tipo de comprobación anti-spam, viendo que el captcha no está funcionando. Pero eso para otro artículo más adelante 🙂

Ya comenté en un post anterior los problemas que estaba teniendo con el Spam.

Como tuve los problemas de indexación en Google, dejaron de bonbardearme, pero ahora que está resuelto, vuelvo a ver una buena cantidad de comentarios Spam nuevos cada vez que me paso por el blog. Dije la última vez que WordPress no traía un sistema anti-spam integrado, y era mentira. Tras investigar un poco veo que trae Akismet, que parece ser una solución muy robusta anti-spam. El problema es que al igual que me pasaba con ReCaptcha, el plugin de Akismet intenta hacer una conexión externa y parece ser el servidor gratuito de FreeHostia no lo permite, por lo que sigo sin poder usar esa opción.

Algo que veo que tienen en común todos los comentarios spam es que no tienen especificado un correo electrónico, cuando es indispensable para mandar un comentario. Por más pruebas que hago no consigo replicar la creación de un comentarios sin correo, lo que me hace pensar que de alguna manera deben estar saltándose alguna de las comprobaciones de wordpress, aunque no intuyo como.

Buscando el momento exacto en el que se guardan los comentarios en la base de datos, parece ser que es en el fichero /wp-includes/comment.php, en el método wp_insert_comment. No se siquiera si es posible que estén llegando hasta este punto evitando algún paso intermedio, pero por si acaso he añadido aquí una comprobación adicional para verificar que el correo del comentario existe y es correcto:

if(!is_email($comment_author_email)){
  return -1;
}

Ahora toca esperar y ver si ha sido efectivo…

ACTUALIZACIÓN 12/12/2011

Aunque el código anterior parecía efectivo, al impedir por completo la creación del nuevo comentario, no había manera de comprobarlo. Si tras unas semanas no aparecía nuevo spam, se podría decir que ha funcionado, pero como quería algo más definitivo, he modificado el código por lo siguiente:

if(!is_email($comment_author_email)){
  $comment_approved = 'spam';
}

Así, lo que hago es permitir que se inserte en la base de datos, pero marcado directamente como spam, y ya ha dado sus frutos, acabo de ver un nuevo comentario de spam etiquetado automáticamente como tal. Se confirma entonces que de alguna manera están evitando el método normal de añadir un comentario en wordpress, y que este código es efectivo en contrarrestarlo mientras no rellenen el campo de correo.

Y con este creo que ya son 4 dominios distintos los que ha tenido este blog… Pero con un poco de suerte este será el definitivo!

Al final me decidí por un .com ¿Por qué? Pues sencilla razón. Si Google puede decidir dejar de indexar un dominio gratuito, nada me asegura que lo vuelva a hacer con el siguiente, así que .com y voy sobre seguro.

Después de mirar un poco las tarifas de dominios, me decidí por comprarlo en 1and1, que por 6€ al año me parece un buen precio (gracias @davidinchi por la recomendación! :D)

Los próximos pasos serán volver a tener en marcha las herramientas para Webmasters, el analytics y volver a meter la URL en el resto de buscadores (bueno, Bing y Yahoo).

Ya actualizaré comentando los progresos.