Estás en la sección 'WordPress' ↓

Thumbnails de YouTube en Facebook

La situación es la siguiente: tienes un blog en WordPress donde publicas posts que incluyen videos de YouTube. Al pegar un permalink de este blog en el muro de Facebook, se esperaría obtener los thumbnails correspondientes al video YouTube.

Con un blog que administro (enlacenacional.com) esto no sucedía. Facebook solo mostraba el logo de la web como thumbnail. Siempre. Era muy aburrido.

He leído que mucha gente tiene este problema, la mayoría le echa la culpa a un error de Facebook. Buscando una solución dí con una pista: la solución pasa por insertar en la cabecera de cada página el meta tag siguiente, que indica qué imagen debe usarse como preview (en este caso deben ser los thumbnails del video YouTube):

< link rel="image_src" >

Para hacer esto automáticamente, encontré el plugin Facebook and Digg Thumbnail generator. Sin embargo, noté que este plugin falla con los códigos embeded más recientes de YouTube.

For the record, anteriormente, el código embeded era de este tipo:

value="http://www.youtube.com/v/AhMfIL5MF2A&hl=es&fs=1

Ahora es así:

value="http://www.youtube.com/v/Os28AxvgYSw?fs=1&hl=es_ES

Como resultado de esta variación, el plugin Facebook and Digg Thumbnail generator no funciona correctamente. Había que mejorar, actualizar, su código, en particular la línea correspondiente a la expresión regular que obtiene el identificador del video, una serie de 11 caracteres.

Para eso, reemplazo esta línea:

preg_match('@www.youtube.com/v/([^&"\' ]*)&@i', $post->post_content, $m);

por esta otra:

preg_match('/www.youtube.com\/v\/([A-Za-z0-9._%-]*)[&\w;=\+_\-]*/', $post->post_content, $m);

Y ya que estoy en eso, agrego dos variables extras, para generar dos thumbnails más que Facebook pueda mostrar:

$image = "http://i4.ytimg.com/vi/$yt_id/default.jpg";
$image1 = "http://i4.ytimg.com/vi/$yt_id/1.jpg";
$image3 = "http://i4.ytimg.com/vi/$yt_id/3.jpg";
...
echo "\t".'< link rel="image_src" href="'.$image."\" />
echo "\t".'< link rel="image_src" href="'.$image1."\" />
echo "\t".'< link rel="image_src" href="'.$image3."\" />

Hechos estos cambios, el plugin funciona correctamente, y ahora Facebook ya tiene 4 opciones de thumbnails para los links de Enlace Nacional: el logo, y los 3 thumbnails del video YouTube.

Estoy en WordPress 2.5

Acabo de actualizar mi blog a WordPress 2.5 nombre clave “Brecker” (también en castellano gracias a Carrero.es). Lo más tedioso como siempre fue el backup previo, y subir por FTP los nuevos archivos del CMS. Luego, el upgrade se hace en un minuto, al menos en este blog pequeño con menos de 100 entradas. Ahora sigo probando algunas nuevas opciones: para actualizar los plugins en un click, y otra que permite crear galerías de fotos.

Para actualizar los otros blogs que administro creo que esperaré a la version 2.5.1, que resolverá algunos bugs que ya vienen apareciendo, por ejemplo he visto que no se guardan los cambios en la hora y fecha de un post ya publicado, si solo modifico los minutos. Seguiré testeando este juguete nuevo.

Actualización [1 abril]: También se puede agregar Gravatar a los comentarios, que ya viene por defecto en WP 2.5. Basta incluir la función “echo get_avatar” en comments.php, yo la estoy probando con el email del autor del comentario:

< ? php echo get_avatar( get_comment_author_email(), '80' ) ? >

Cómo seguir tus comentarios en otros blogs

Esto viene siendo un tópico al que, tras muchos intentos, aun no le encuentro la solución ideal, y lo recuerdo ahora leyendo este post de Luis Aguirre. ¿Cómo seguirle el rastro a los comentarios que voy dejando en otros blogs? Descartando la idea de suscribirme al feed de cada comment que he escrito, o de visitar -y recordar- constantemente el blog aquel donde dejé un comentario, traté de recurrir a herramientas tipo co.mments o coComment. Utilicé el primero por un tiempo, pero el limitante seguía siendo el mismo: recordar que tenía que utilizar la bendita herramienta de rastreo. Incluso, algunas veces en que lo hacía, era el browser el que olvidaba mi contraseña, lo cual me obligaba a realizar un paso adicional: el log in. ¡Todo esto para escribir un miserable comentario!

Por ahora lo más cercano a una solución es la opción que aparece en Blogger, la casilla que dice “Enviar por correo electrónico comentarios de seguimiento…”, aunque solo funciona para los que tenemos cuenta en Google/Blogger. Mientras que en WordPress yo uso el plugin Subscribe to comments con muy buenos resultados para mis lectores. Recomiendo que los demás bloggers WP lo usen, y así me hagan la vida más fácil :) Con estas herramientas en Blogger y WordPress ya tendríamos cubierta buena parte de los blogs. Sí conoces de otros servicios similares, deja un comment recomendándolo, más de uno te lo agradecerá.

Cómo arreglar el bug “posts futuros y drafts visibles” en WordPress 2.2.X

La gente de WordPress se ha apresurado en sacar la versión 2.3.2 de su popular CMS, luego de que se hiciera público un tremendo bug, el cual permite que cualquier persona pueda ver los posts futuros (programados para que sean publicados automáticamente) y los drafts (borradores). Como nadie quiere perder el control ni la privacidad de los contenidos de su blog, se recomienda la actualización a la nueva versión 2.3.2.

¿Pero qué pasa con los usuarios que seguimos usando la rama 2.2.X y no queremos aún pasar a la versión 2.3.X de WordPress? Eso fue lo que le consulté a Alex Concha de Buayacorp.com, blogger peruano que ayudó a solucionar el bug. Alex me recomendó, primeramente, que al menos pase a la versión 2.2.3, y luego haga los siguientes cambios:

– Si te preocupa el problema de que alguien vea tus borradores haz los cambios que se muestran en [1] y [2].
– Si permites el registro de usuarios, copia todo el archivo xmlrpc.php (no estoy seguro si tendrás problemas o no).
– Si alguien más aparte de tí publica entradas a través del mail, copia también el archivo wp-mail.php
– Si usas WP en windows, haz el cambio que se muestra en [3],

[1] http://trac.wordpress.org/changeset/6442
[2] http://trac.wordpress.org/changeset/6510
[3] http://trac.wordpress.org/changeset/6521

En mi caso decidí aplicar los cambios [1] y [2] aun estando en la versión 2.2.2, lo cual ha solucionado el bendito bug. No es muy complicado, tan sólo tienen que editar un par de líneas de dos archivos PHP, así que recomiendo esta solución. Pero nunca olviden de guardar un copia de los archivos antes de modificarlos.
En los próximos días comenzaré a actualizar los blogs que administro a la versión 2.2.3 y nuevamente aplicaré estos cambios. Probablemente solo en este, mi blog personal, comenzaré a usar la última version de WordPress 2.3.2.

Extraño error en WordPress

Can’t open file: ‘wp_options.MYI’ (errno: 145)

Ese fue el error que apareció en Cinencuentro el miércoles pasado, específicamente en la base de datos del WordPress. Aproximadamente a las 3:00 a.m. el blog solo mostraba la pantalla de instalación de WordPress (WTF!). Lucho comenzó a buscar el origen del error, pero sin mayor suerte. Luego de algunas horas ya temía lo peor: que algún extraño haya entrado al servidor, o sea, hackeados. A las 6:20 a.m. me llama por teléfono y me pone al tanto. Vaya manera de despertarse. En cuestión de segundos se me fue el sueño y a comenzar a sudar frío. Verifiqué que toda la data estuviese como la dejé a las 2:00 a.m. Que ningún archivo del WordPress haya sido modificado en las últimas horas. Que los passwords no hayan sido modificados. Todo parecía estar Ok. Pero el blog seguía mostrando la pantalla de instalación del WP. Añadir a eso que además había olvidado borrar el archivo install.php, así que cualquiera que visitó el blog en ese momento pudo seguir el proceso de instalación. Es más, al menos cinco veces se completó el proceso de instalación, esto según los emails que me llegaron a la cuenta principal del blog. Felizmente ninguna información se filtró (password de administrador), ni se sobreescribió, tan solo se añadían nuevas entradas “Hola mundo” al blog.

Luego de una estresante hora, revisando la base de datos tabla por tabla, llegué a “wp options”. Ahí fue donde apareció el maldito error “Can’t open file: ‘wp_options.MYI’ (errno: 145)”. Una rápida búsqueda en el WordPress Support y en Google me dió la respuesta que buscaba:

repair table wp_options

Ejecuté esa sentencia y el alma volvió al cuerpo.

La razón del error aun es una incógnita. El soporte técnico de MediaTemple no da razón, “a menos que el error se repita, ignórelo”. Y el resto de humanos que se han topado antes con este error simplemente lo explican como “esas cosas que pasan”. Va para el libro.

Moviendo un blog de Bluehost a Media Temple

El blog es Cinencuentro, y luego de tenerlo por un par de años hosteado en Bluehost hemos decidido mudarlo a un servidor dedicado en Media Temple. Sucede que el servidor compartido que tenemos en Bluehost ya no era suficiente para el tráfico y la cantidad de recusos que utiliza Cinencuentro. En algunos momentos del día recibíamos el temido mensaje de CPU Quota Error, que nos dejaba offline por algunos minutos.

La mudanza tuvo el punto más pesado en la importación de la base de datos. La exportación en sí es muy sencilla, ya sea creando un script SQL o un archivo de datos, como un XML por ejemplo. El dolor de cabeza comenzó cuando me di cuenta que al exportar la base de datos en el nuevo servidor, todos los caracteres especiales (como tildes, eñes y demás) aparecían incorrectamente en el volcado vía SQL. Sucedía que había un conflicto en la codificación de estos caracteres en la base de datos. Probablemente haya sido un problema que se arrastra desde los primeros días del blog, cuando pasamos de tenerlo en un servidor provisional (gracias a Marco) a uno en Bluehost. En aquel entonces, utilizando WordPress 1.5.3, forcé a que la base de datos utilice la codificación Latin en vez de UTF-8. Al realizar la actualización a WordPress 2.1 la confusión ya se había completado, y solo salió a la luz ahora que tuve que hacer la mudanza.

Entonces, ya que la importación vía SQL no iba a ser posible, tenía que utilizar el volcado a un archivo tipo XML, el cual sí mostraba correctamente los caracteres especiales de nuestro querido castellano. El problema ahora era que el bendito archivo pesaba 30 MB. WordPress, o mejor dicho, la configuración del servidor PHP solo permite cargar (subir, upload) archivos de 2 MB, por defecto. Si bien cambié los parámetros en el archivo de configuración php.ini para que sea posible hacer transferencias de mayor volumen, al parecer WordPress no da para tanto, y fallaba en el intento. Es así que tuve que partir el archivo XML en archivos más pequeños que sí puedan ser exportados en el nuevo WordPress 2.2.2. En promedio fueron archivos de 4 MB (En las pruebas que realicé, algunos archivos XML de 5 MB o más no lograban terminar el proceso).

Durante este proceso de importación aprendí algunas cosas, como que no sirve activar plugins ni elegir un theme nuevo, mientras no se haya volcado toda la data. Algunos plugins causaban que la importación se truncase o de errores.

No puedo olvidar mencionar que en todo este trance conté con la gran ayuda de Franc. quien me proveyó de muchas ideas para no desisitir en mi intento de cambiar de servidor =D

Luego de todo esto, ya tenía la valiosa base de datos de Cinencuentro en su nuevo hogar. Ahora tocaba solucionar algunos problemas que siempre aparecen en estos casos. Por ejemplo:

  • En los títulos de los posts, las comillas dobles (” “) han pasado como caracteres HTML &# 8220 y &# 8221. Si bien esto no debe ser un problema mayor, algunos plugins, como el Recent Posts version 1.07 no interpretan bien estos caracteres y los imprimen tal cual. Otros plugins como el Related Posts version 2.04 no tiene este problema.

Otros problemas a los que aun no le encuentro solución son:

* El plugin Twitter Tools causa un error al grabar una entrada. Luego de grabar los cambios, extrañamente aparece una ventana para descargar el archivo post.php

* El valioso plugin WP-Cache 2.0.21 da un error en el mismo proceso, cuando se graba una entrada, no se recarga el preview del post, sino solo aparece una pantalla en blanco. Los cambios, sin embargo, sí se han grabado.

* El plugin WP-UserOnline 2.06 causa un error similar, aunque solo cuando se edita un post ya publicado, y no en un post en estado draft (borrador), o un post nuevo.

* El plugin Lightbox simplemente no funciona.

Eso por ahora. Por lo demás, todo anda Ok, y yo me preparo para llenar el blog de plugins y scripts hasta matar el servidor :D

Nuevo Google Analytics, y nuevo WordPress 2.2

Google AnalyticsSe renuevan un par de mis servicios preferidos 2.0. Primero, Google Analytics que ya necesitaba un upgrade urgente. Aún está fresco el recuerdo de la chamba que significó “traducir a castellano” los stats de Cinencuentro, buceando entre los diferentes reportes que este potente servicio de estadísticas ofrece, y hacerlos entendibles para cualquier loco de los númeritos, como un servidor. Ahora, con la nueva interfaz del Analytics el trabajo se nos facilita, el dashboard te da una mirada rápida de cómo se han movido las visitas en las últimas 24 horas. Gran mejora, espero nomás que se mantenga free. De todas formas, siempre le doy una mirada a las estadísticas que nos ofrece el fiel StatCounter. Pueden leer un infome detallado del nuevo Google Analytics en Modern Life.

Segundo, ha sido la esperadísima nueva versión de WordPress, el CMS por excelencia, al que le estoy confiando gran parte de mi trabajo, y con buenos resultados. La nueva versión es la 2.2, nombre clave Stan Getz. Por ahora sólo lo he instalado en un blog de prueba en el que estoy trabajando un nuevo sitio (pista: será el renovado EnlaceNacional.com). A pesar de los infaltables bugs que ya están apareciendo, por ahora todo va bien por acá. Aprovecho para recomendar Planeta WordPress, sitio donde encontrarán todo, pero todo, lo que necesitas saber sobre nuestro querido administrador de contenidos.