Apr 10

Hace tiempo escribí un post acerca de como usar FeedBurner para los feeds de un WordPress que se ha quedado algo obsoleto debido a algunos cambios en WordPress respecto a la URL de los feeds y a la compra de FeedBurner por parte de Google.

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:

FeedBurner snapshot

Tagged with:
Feb 21

Es un procedimiento muy sencillo que está perfectamente detallado en la documentación de WordPress aunque quizás faltan un par de puntos por explicar un poco mejor.

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:

[php] define(‘DB_CHARSET’, ‘latin1’); [/php]

[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).
Tagged with:
Feb 18

Por fin me he sacado de encima una de las tareas pendientes más pesada que me había propuesto para este año: actualizar este blog a la última versión de WP, la 2.7.1.

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.

Tagged with:
Oct 09

Los títulos de las páginas son uno de los factores más importantes de cara a la optimización de un sitio web para los buscadores (SEO). Si tenemos un blog con WordPress la responsabilidad de tener unos buenos títulos recae en el archivo header.php de nuestro tema. El tema por defecto de WordPress (Kubrick), y la mayoría de themes que corren por ahí, generan unos títulos no muy buenos para el posicionamiento, a continuación describo una manera fácil de solucionar esto sin necesidad de ningún plugin.

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

[php] <?php bloginfo('name'); ?> <?php if ( is_single() ) { ?> » Blog Archive <?php } ?> <?php wp_title(); ?> [/php]

por esto si tenemos WordPress 2.3:

[php] <?php if (is_archive()) echo 'Archivo de '; if (is_tag()) echo 'etiquetas de '; echo trim(wp_title('',false)); if (is_search()) echo 'Resultados de búsqueda de '.$s; if ( !(is_404()) and (is_search()) or (is_single()) or (is_page()) or (is_tag()) or (is_archive()) ) echo ' en '; bloginfo('name'); if ( is_home() ) { echo ' » '; bloginfo('description'); } ?> [/php]

o por esto si tenemos versiones anteriores:

[php] <?php if (is_archive()) echo 'Archivo de '; echo trim(wp_title('',false)); if (function_exists('is_tag') and is_tag()) echo 'Archivo de etiquetas de '.$tag; elseif (is_search()) echo 'Resultados de búsqueda de '.$s; if ( !(is_404()) and (is_search()) or (is_single()) or (is_page()) or (function_exists('is_tag') and is_tag()) or (is_archive()) ) echo ' en '; bloginfo('name'); if ( is_home() ) { echo ' » '; bloginfo('description'); } ?> [/php]

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.

Tagged with:
Jun 07

WordPress está disponible en varios idiomas gracias al sistema de localización GNU gettext. Dentro del código de WordPress nos encontramos dos funciones para hacer el trabajo con gettext mucho más sencillo y así poder programar plugins y temas multi-idioma, estas funciones son las mismas que usa internamente el propio WordPress. A pesar de disponer de estas facilidades es muy frecuente encontrarse temas en un único idioma, es cierto que hacer temas multi-idioma añade un coste extra a la confección de un tema, pero en mi opinión es algo que merece la pena si queremos dar mucha más visibilidad a nuestro trabajo. A continuación describo como usar estos mecanismos que proporciona el WordPress para realizar un tema multi-idioma.

[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():

[php]

About

[/php]

por:

[php]

[/php]

Un ejemplo de __():

[php] the_content(‘Read the rest of this entry’); [/php]

por:

[php] the_content(__(‘Read the rest of this entry’,’ejemplo_domain’)); [/php]

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

[php] printf(__(‘You are currently browsing the %1$s weblog archives for the %2$s category.’,’ejemplo_domain’), get_settings(‘siteurl’), single_cat_title(”,false)); [/php]

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:

[php] the_time(‘l, F jS, Y’); [/php]

por:

[php] the_time(__(‘l, F jS, Y’),’ejemplo_domain’); [/php]

[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:

[php] load_theme_textdomain(‘ejemplo_domain’); [/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.

Tagged with:
preload preload preload