Gestionar la suscripción por correo de nuestros blogs aporta siempre un valor añadido a aquellos con quienes interactuamos a través de nuestra modesta ventana al mundo.
Una de las opciones más utilizadas para gestionar este tipo de suscripciones es FeedBurner: funciona rápidamente y es sencillo de usar. Sin embargo, lo barato sale caro: al usar FeedBurner estamos externalizando nuestra presencia y una pieza importante de información muy valiosa (las direcciones de correo de personas). FeedBurner fue comprada por Google, el mayor vendedor de anuncios del mundo (aten cabos). Y, por si fuera poco, es una trampa a medio plazo para la gestión de nuestros suscriptores, motivo por el cual abandoné su uso en los albores de 2008.
Tanto si usamos Drupal como WordPress, existen módulos que nos permiten gestionar las suscripciones por correo internamente, sin salir de nuestro CMS y sin problema alguno: plug and play.
Este artículo se centra en WordPress y MailPress, cuya instalación es laboriosa pero sencilla (caché de Google, la fuente da error). En el caso de WordPress Multi-Site, MailPress no funciona de inmediato. Se trata de un módulo muy potente, de los más utilizados para esta labor, pero se atasca antes de echar a andar.
¿Qué sucede? El problema real es que MailPress, en el momento de su activación para toda la red de blogs, sólo crea las tablas que necesita para funcionar… en el blog principal de la red, e ignora a los demás. En este caso, una vez activado para la red, el plugin podrá ser activado para cualquier blog, a voluntad de su administrador, que podrá añadir el widget de suscripción a cualquier parte de la web. Este widget, sin embargo, dará error cuando alguien intente suscribirse. A pesar de eso, el mail con el hash de confirmación se enviará al usuario, pero al no existir una base de datos en la cual almacenar esa petición, hacer click devuelve al potencial suscriptor un error del tipo Error #5 - Unknown User
. De cajón: no hay tabla ni info almacenada, así que el sistema te responde que esa petición que tú quieres confirmar no existió jamás :D
Ahora vamos a ver cómo lo arreglamos, para poder gestionar directamente el newsletter de nuestro WordPress Multi-site sin depender de un proveedor externo. Requiere un poco de tinkering, pero nada complicado.
- Antes de nada, aunque confiemos en que no vamos a romper nada, lo que debemos hacer es una copia de seguridad de la base de datos. Usa el gestor que prefieras, si no te ves muy suelto con MySQL, puedes usar phpMyAdmin.
- MailPress crea tres tablas principales. Asumiendo que todas las tablas tengan un prefijo
wp_
, las tres tablas principales sonwp_mailpress_mails
,wp_mailpress_mailmeta
, ywp_mailpress_users
. Podemos usar el mismo gestor utilizado para respaldar nuestra base de datos para ver qué tablas adicionales ha creado MailPress, variará en función de los AddOns que hayamos activado. - Hay quien propone soluciones un tanto complejas que supuestamente funcionan [sic, tiene erratas así que no sé cómo lo hizo para que le funcionara]. La realidad es que toda vez que al menos un blog de la red (el principal), lo más fácil es copiar las tablas creadas para ese blog, algo que hacemos ¡a partir del punto siguiente!.
- Buscamos en el menú de administrador de la Red los
ID
de los blogs para los que queremos activar MailPress, es un número y asumiendo el prefijo anterior como global (wp_
) y que queramos activar MailPress en un blog conID = 2
, necesitaríamos crear como mínimo las tablaswp_2_mailpress_mails
,wp_2_mailpress_mailmeta
, ywp_2_mailpress_users
. Se ve claro el patrón, ¿no? Si hemos activado alguna función útil como las métricas de suscriptores o la gestión de rebotes seguramente tendremos que crear alguna tabla más (wp_2_mailpress_stats
, ywp_2_mailpress_usermeta
). Remito al punto 2 para verificar exactamente qué tablas estamos necesitando. - Una vez sepamos el ID del blog que nos da problemas y las tablas que nos hacen falta, seleccionamos la base de datos en cuestión y ejecutamos una query que deberá tener la siguiente pinta:
CREATE TABLE wp_2_mailpress_mails LIKE wp_mailpress_mails;
CREATE TABLE wp_2_mailpress_users LIKE wp_mailpress_users;
CREATE TABLE wp_2_mailpress_mailmeta LIKE wp_mailpress_mailmeta;
Esto creará en nuestra base de datos unas tablas idénticas a las que ya están funcionando correctamente para el blog matriz, pero vinculadas al blog con ID = 2 de nuestra red. - Si necesitamos activar MailPress en más blogs de nuestra red, modificamos la query para adaptarla al ID de ese blog.
- Y con esto tendremos lista para nuestro WordPress Multi-Site una herramienta fantástica y potente que por algún motivo no se activa bien en este tipo de instalación.
Los beneficios son rápidos e importantes: nos gusta la Red, nos gusta pero no podemos caer en el empujón fácil hacia infraestructura ajena, porque de esa carrera surjen rentas de posición que serán usadas en nuestra contra.
¿Queremos una Red que merezca tal nombre? No una nube para todos, sino millones de nubes pequeñitas. Pasito a pasito hacia la autonomía tecnológica, ¿o no es para eso que usamos un CMS en software libre?
De lo que yo llevo un tiempo intentando quitarme es de Reader, he probado un par de lectores en ubuntu (Liferea y RSSOwl) y cada uno por lo suyo la verdad es que no me acaban de convencer…
En cuanto nos tomemos esa caña te cuento una idea que tengo para eso ;)
¿Cuándo podrás al final?
Pues esta semana regular pero la que viene cualquier tarde a partir de las 7 sin problema. Así que cuando a usted le venga bien caballero.
Fantástico, a mí esta tampoco me viene bien. Pero la que viene (excepto el lunes), tengo esa hora libre el resto de días ;)
Ya te voy contando!