Si todavía crees que usar FeedBurner es una buena idea (yo nunca lo tuve claro) la forma más cómoda de configurarlo es modificando el archivo .htaccess, aunque también existen plugins específicos (por ejemplo el FD Feedburner Plugin).

Se trata de añadir lo siguiente al .htaccess:

<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /
RewriteCond %{HTTP_USER_AGENT} !FeedBurner [NC]
RewriteCond %{HTTP_USER_AGENT} !FeedValidator [NC]
RewriteRule ^feed/(.*)$ http://feeds2.feedburner.com/xxxxxx [R,L]
</IfModule>

Con lo anterior conseguimos que nuestro WordPress únicamente genere el feed para FeedBurner y que el resto de clientes (navegadores, arañas, etc.) sean redirigidos a la URL de FeedBurner.

Teóricamente este es el mejor método para usar FeedBurner ya que seguimos difundiendo la URL del feed original y así siempre podemos dejar de usar este servicio sin muchos inconvenientes. El problema está en que al haber la redirección muchos usuarios siguen el enlace del feed con el navegador y se suscriben a la URL del feed de FeedBurner… o sea que con el tiempo acabaremos con lectores suscritos a ambas URLs.

El método alternativo es modificar el theme de WordPress, o usar algún plugin, para difundir directamente la URL del feed de FeedBurner.

Proxy de Google

Si teníamos una cuenta en FeedBurner y la hemos migrado a Google recientemente, a parte del engorroso cambio de la URL del feed, quizás hemos notado que ahora la URL que difunde tu feed para cada post pasa por un proxy de Google.

En principio esto ya sucedía antes y el cambio únicamente es que ahora en lugar de pasar por feeds.feedburner.com pasa por feedproxy.google.com (aunque en mi caso antes de migrar la cuenta a Google no pasaba por ningún proxy, tengo caché, lo puedo demostrar :)

En cualquier caso si queremos desactivar completamente el proxy de Google hemos de cambiar la configuración de nuestro feed en FeedBurner. Concretamente se trata de desactivar la opción “Item link clicks” de la sección “TotalStats” dentro de la pestaña “Analize”. Con esto seguiremos teniendo estadísticas de número de lectores e ítems vistos (información más que suficiente) pero difundiremos siempre la URL original de cada post, algo muy recomendable para SEO (como bien nos explicaba Armonth hace tiempo).

Así es como debería quedar la configuración en FeedBurner:

Entradas relacionadas:

• Usando mod_rewrite y FeedBurner para las feeds de un blog con WordPress
• Actualizar un WordPress a la última versión
• Internacionalización de temas en WordPress usando gettext

Si nuestra intención es hacer borrón y cuenta nueva con nuestro blog eliminando todos los archivos pero conservando la base de datos los pasos a seguir son los siguientes:

[1] Como siempre antes de empezar cualquier tarea parecida backup de todo. Incluso es buena idea montar el blog entero en otro sitio para después poder comparar el viejo con el nuevo.

[2] Desactivamos todos los plugins y seleccionamos el tema por defecto. Aunque en nuestro caso como tenemos intención de borrar todos los archivos el nuevo WordPress desactivará todo lo que no encuentre.

[3] Borramos todos los archivos anteriores. Si tenemos el wordpress mezclado con otras cosas el comando en cuestión es algo como:

$ rm -rf index.php license.txt readme.html wp-* xmlrpc.php

[4] Descomprimimos la última versión de WordPress en el mismo sitio donde teníamos la anterior.

[5] Editamos el nuevo wp-config.php y añadimos los datos de conexión y nombre de la BD.

[6] Comprobamos en qué codificación está trabajando nuestro WordPress. Por ejemplo con:

mysql> show create table wp_posts;

Nos fijamos en el CHARSET utilizado y definimos DB_CHARSET con el mismo valor. En el caso de ser "utf8" no tenemos que tocar nada pero si estamos con "latin1" es necesario indicarlo en wp-config.php con:

[7] Iniciamos el programa de actualización apuntando el navegador a la URL habitual del dashborad (p.e. http://tublog.es/wp-admin/)

[8] Automáticamente aparecerá un mensaje diciendo que debemos proceder con la actualización de la BD. Hacemos clic en "Siguiente" y cruzamos los dedos... si todo va bien te aparecerá algo como "Update successful".

[9] WordPress casi actualizado!

Digo casi porque casi seguro vamos a necesitar realizar alguno de lo siguientes pasos adicionales:

• Si habíamos subido archivos al WordPress utilizando su dashboard hemos de copiar la anterior carpeta wp-content/uploads a la nueva instalación.
• Si trabajábamos con algún plugin para los tags debemos lanzar la importación manualmente desde el dashboard, por ejemplo en el caso del UTW desde "Herramientas" -> "Importar" -> "Ultimate Tag Warrior".
• Si ha pasado mucho tiempo desde la última actualización no es mala idea repasarse las opciones de configuración de WordPress y comprobar que todo está ok, especialmente la sección de Permalinks.
• Como hemos empezado de nuevo en lo que a código PHP se refiere es necesario volver a instalar los plugins que echemos en falta y un tema que nos guste. Por supuesto descargando las últimas versiones de todo y no aprovechando nada del anterior WP para así sacar el máximo partido de las nuevas funcionalidades (en parte uno de los objetivos del procedimiento descrito en este post).

Entradas relacionadas:

• Internacionalización de temas en WordPress usando gettext
• Títulos un poco más SEO y en español para WordPress
• Usando mod_rewrite y FeedBurner para las feeds de un blog con WordPress

Ahora que ya está hecho (y parece que todo funciona) confieso que he migrado desde una versión de WordPress 2.0.4 con más de 20 plugins, modificaciones por todos sitios, etc. en definitiva ha sido todo un mini-proyecto por mi culpa, ya sabía yo que este día llegaría y que con la cantidad de modificaciones que le había hecho al anterior WP fliparía :)

Decir que ha sido un borrón y cuenta nueva sólo conservando la base de datos, en un siguiente post ya contaré los detalles, pero por la parte que le toca a WP el proceso ha sido bastante limpio y sencillo a excepción de algún problema de codificación, ahora WP trabaja con UTF-8 por defecto.

PS: Todo sea para intentar darle algo más de vida a este blog.

Entradas relacionadas:

• PHPBSD.net se une a Planet Webdev
• PHPBSD.net pasa a formar parte de la red SmallSquid.com

Se trata de sustituir el código para los Title Tags que normalmente será algo parecido a esto:

por esto si tenemos WordPress 2.3:

o por esto si tenemos versiones anteriores:

Con esta modificación conseguimos los siguientes tipos de títulos:

• En la home: "NOMBRE_DEL_BLOG » DESCRIPCIÓN_DEL_BLOG"
• En las categorías: "Archivo de NOMBRE_CATEGORÍA en NOMBRE_DEL_BLOG"
• En las etiquetas: "Archivo de etiquetas de NOMBRE_ETIQUETA en NOMBRE_DEL_BLOG"
• En los resultados de búsqueda: "Resultados de búsqueda de TEXTO_BUSCADO en NOMBRE_DEL_BLOG"
• Para todos los posts y páginas: "TÍTULO_ENTRADA en NOMBRE_DEL_BLOG"

Lo anterior está extraido del tema K2, traducido al español y con algún retoque. Podría haber hecho un plugin, pero es tan sencillo y como igualmente sería necesario modificar el tema para llamar al plugin, que mira, modificas el tema y directamente introduces el código de lo que sería el plugin.

Si quieres tomarte más en serio la generación de los títulos o si eres perezoso existen plugins muy avanzados como SEO Title Tag y All in One SEO Pack, este último también sirve para gestionar los Meta Tags "description" y "keywords" también muy importantes para SEO pero no tanto como los Title Tags.

Entradas relacionadas:

• Internacionalización de temas en WordPress usando gettext
• Falta poco para la International PHP Conference 2006
• Un poco de música para FreeBSD

[1] Escoger un nombre para el "dominio". Se trata de escoger un nombre para todo el conjunto de traducciones, normalmente el mismo nombre del tema nos servirá, lo único a tener en cuenta es que ha de ser un nombre único entre todos los temas y plugins instalados.

[2] Modificar las plantillas. Se trata de usar unas determinadas funciones PHP para sacar por pantalla cualquier cadena de texto que tengamos en nuestras plantillas.

Las funciones son _e($texto) y __($texto). Estas funciones buscan una traducción de $texto en el catálogo usando como índice el texto pasado y si no la encuentran devuelven $texto sin modificar, el idioma a traducir lo define la constante WPLANG (en wp-config.php). La única diferencia entre las dos funciones es que __() devuelve con un return() el texto traducido y _e() lo imprime por pantalla con un echo().

Un ejemplo de __e():

por:

Un ejemplo de __():

por:

Para la correcta traducción de las frases en ocasiones es necesario usar printf() o sprinf() junto con __(). Por ejemplo:

Esto permite que el traductor entienda más el significado de la frase que si la troceamos con varios _e(), también permite cambiar el orden de las variables (%1$s y %2$s) si nuestro idioma lo requiere.

A parte de los textos que se mostrarán por pantalla tenemos otros strings importantes a internacionalizar, son los que definen el formato de las fechas. Por ejemplo:

por:

[3] Crear el catálogo de traducciones. Existen varios programas para trabajar con archivos POT, a continuación describo brevemente como usar poEdit para generar el archivo POT y MO a partir de las plantillas anteriormente modificadas.

• Instalamos poEdit.
• Configuraciones iniciales como nuestro nombre, etc. en "File -> Preferences".
• Creamos un nuevo catálogo con "File -> New Catalog". En el cuadro de diálogo que aparece:
  • En "Project Info" introducimos el nombre del proyecto, idioma, etc. y la codificación utf-8 (por defecto en todo WP).
  • En "Paths" añadimos un único path, el ".".
  • En "Keywords" añadimos los nombres de las funciones usadas para trabajar con gettext, "__e" y "__" (sin las comillas).
• Lo siguiente es generar el catálogo. Es necesario guardarlo en el mismo directorio que los archivos del tema y ponerle el nombre del locale deseado (p.e. es_ES).

Si todo ha ido bien poEdit escaneará todas nuestras plantillas y generará un archivo POT listo para empezar a traducir. Cada vez que se guarda el catálogo se generará automáticamente el MO, que es el que realmente usa el código PHP, a no ser que configuremos lo contrario en "Preferences".

[4] Cargar las traducciones desde el tema. Ahora sólo falta que nuestro tema cargue el catálogo apropiado dependiendo del idioma definido, esto lo conseguimos añadiendo lo siguiente antes de cualquier llamada a __() o _e(), un buen lugar es al principio del index.php o del header.php:

[5] Listos! En el siguiente acceso a nuestro blog veremos todas las frases traducidas.

Aunque el procedimiento descrito está centrado en WP y las funciones que nos brinda para la internacionalización es muy parecido al uso de otros sistemas basados en gettext, como plugins Smarty, o al uso directo de las funciones gettext del PHP.

Si quieres más información puedes consultar los capítulos Traduciendo WordPress y Escribiendo un Plugin de la documentación de WordPress.

Entradas relacionadas:

• Usando mod_rewrite y FeedBurner para las feeds de un blog con WordPress
• Actualizar un WordPress a la última versión
• MediaWiki con URLs cortas usando mod_rewrite

Si tenemos un blog con un poco de tráfico es muy probable que ya tengamos suscritas unas cuantas personas al feed del blog. Los lectores pueden hacer un check de nuestras feeds en un intervalo de 10 a 30 minutos. Esto con unas 30 o 50 personas suscritas suponen unas 3000 peticiones diarias o más.

Se ha de sumar también que dependiendo de donde tengas presencia con tu blog puedes tener unas 5 o 10 arañas de buscadores consultando el feed. Sin ánimo de hacer publicidad una muy buena solución para quitarnos de encima esta carga es usar FeedBurner. A parte de que ofrece varios servicios interesantes (contadores, estadísticas, etc.).

Puedes fácilmente crearte una cuenta en FeedBurner y agregar tantos feeds como quieras. La idea es que sólo FeedBurner recoja los feeds de tu blog y las peticiones de todos los demás las sirva FeedBurner.

Una manera muy sencilla de conseguir lo anterior es con el uso de mod_rewrite. Esto proporciona dos ventajas, una que no necesitamos modificar absolutamente nada de nuestro blog y la otra que si algún día no queremos seguir con FeedBurner la URL de los feeds que difundimos es la original y no tendremos ningún problema. Otra opción es modificar la plantilla de nuestro blog para que informe de la URL de FeedBurner, pero no podremos cancelar la cuenta con FeedBurner sin perder lectores.

Las reglas para el .htaccess son las siguientes:

<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /
RewriteCond %{HTTP_USER_AGENT} FeedBurner
RewriteRule ^feed/(.*)$ /wp-feed.php?feed=$1 [L,QSA]
RewriteCond %{HTTP_USER_AGENT} !FeedBurner
RewriteRule ^feed/(.*)$ http://feeds.feedburner.com/phpbsd [R,L]
</IfModule>

Con lo anterior dejamos que FeedBurner acceda a los feeds generados por nuestro WordPress y todos los demás navegadores (o arañas de buscadores) los redireccionamos a FeedBurner.

Modificando las anteriores reglas puedes redireccionar otras feeds a FeedBurner que no sean la principal. Por ejemplo para las feeds de un tag específico (si tienes el UTW):

RewriteCond %{HTTP_USER_AGENT} !FeedBurner
RewriteRule ^tag/php/feed/(.*)$ http://feeds.feedburner.com/phpbsd/php [R,L]

Con todas las reglas de rewrite anteriores se asume que tenemos configurado WordPress para generar las feeds ante una URL terminada con "/feed/" y que hemos configurado las feeds correspondientes en FeedBurner.

Para más información tienes la ayuda en wordpress.org y la discusión en el foro correspondiente, también existen algunos plugins relacionados.

Entradas relacionadas:

• WordPress con el FeedBurner de Google y su maldito proxy
• MediaWiki con URLs cortas usando mod_rewrite
• HostGator y FeedBurner, un poco de velocidad para este blog