olshtyn.com - Proyecto WordPress | WPPoland

#Tres velocidades de contenido en un mismo portal

olshtyn.com es un portal informativo sobre Olsztyn, pensado para quienes viven en la ciudad y para quienes preparan una visita. El proyecto se entregó en 2012, incluyó también la identidad visual y la ejecución duró alrededor de seis semanas.

El punto de partida no fue el diseño sino el modelo de contenidos, porque el material de un portal urbano vive a tres velocidades distintas y eso condiciona todo lo demás. Una noticia vale unos días y después solo interesa al buscador. El anuncio de un evento vale hasta el día en que ocurre y luego cambia de signo: deja de ser una invitación y pasa a ser archivo. Un texto sobre un monumento o sobre un paseo junto al lago no envejece, y es precisamente el que atrae búsquedas durante años. WordPress, sin tocar nada, mete los tres en el mismo saco ordenado por fecha, de modo que lo más duradero desaparece antes de la vista.

Por eso existen tres tipos de contenido: la noticia, el evento con fecha y lugar, y el material de guía sin caducidad. La consecuencia no se ve el día del lanzamiento, se ve al año. Un evento pasado sale solo de los listados en lugar de quedarse ahí hasta que alguien se acuerde de retirarlo. El material de guía deja de competir por espacio con la noticia del día, así que nadie tiene que empujarlo hacia arriba cada mes con una fecha de publicación renovada de forma artificial. La redacción responde una sola vez a la pregunta sobre el tipo de material, al crearlo, en vez de vigilar su visibilidad cada semana.

En este punto suele aparecer una tabla de resultados. Aquí no aparece ninguna, y es deliberado: las cifras de audiencia pertenecen al editor del portal, no a una ficha de proyecto en nuestro sitio. Lo que sí se puede contar con honestidad son las decisiones y sus consecuencias, y eso es lo que se traslada al proyecto siguiente.

#Quién lee y con qué intención

Olsztyn es la capital de la voivodía de Varmia y Masuria, tiene unos ciento setenta mil habitantes, varios lagos dentro del término municipal y una temporada turística claramente concentrada en verano. Esos datos parecen geografía y en la práctica definieron la arquitectura del sitio.

El residente vuelve por la actualidad. Le interesa lo que pasó ayer y lo que ocurre el fin de semana; entra a menudo y se queda poco. El visitante entra una vez, casi siempre desde el móvil, casi siempre desde fuera de la región, y busca lo permanente: qué merece la pena ver, cómo se llega, dónde está cada cosa. El primero necesita un flujo, el segundo una estructura. Un portal que solo atiende el flujo tiene, al cabo de un año, un archivo ilegible. Un portal que solo atiende la estructura deja de dar motivos para volver.

La taxonomía se mantuvo estrecha a propósito. El modelo tentador describe todo a la vez por barrio, tema, acontecimiento, persona y lugar. Parece flexible el día del estreno y se rompe en el sexto mes, porque dos redactores clasifican el mismo texto de forma distinta y el archivo deja de poder filtrarse. El juego de categorías es corto y cerrado, y lo verdaderamente móvil vive en etiquetas libres de las que no depende ninguna navegación.

Las direcciones se trataron como un activo a largo plazo. La dirección de una pieza lleva el título legible, sin fecha y sin identificador numérico, y la categoría no forma parte de la ruta. Las categorías se reorganizan tarde o temprano, y cambiar la dirección de un texto publicado hace un año cuesta posición y obliga a una redirección. Una dirección que no depende del orden interno de la redacción sobrevive a cualquier reorganización sin trabajo adicional.

#La caché frente a una redacción que publica ahora mismo

La base técnica es WordPress sobre PHP con MySQL, Redis y Memcached como capas de caché, una red de distribución delante y HTML5, CSS3, SASS y JavaScript en el lado del navegador. El código está versionado en Git y el intercambio de datos con la interfaz pasa por AJAX y endpoints REST.

Frente a una tienda, un portal de noticias tiene una ventaja enorme: casi todas las vistas son idénticas para todos los visitantes. No hay carrito, no hay precios por cliente, no hay sesión que se filtre en la página. La inmensa mayoría de las páginas vistas puede servirse sin arrancar PHP siquiera. Lo difícil no es cachear, es invalidar.

La caducidad por tiempo es la herramienta equivocada. Si es larga, la redacción no ve su propio artículo y empieza a pedir que se desactive la caché, normalmente en la hora de mayor tráfico del año. Si es corta, la caché deja de ayudar justo cuando hace falta. La invalidación se ata por eso a un acontecimiento y no a un reloj: guardar una entrada limpia la portada, los listados de categoría afectados y la dirección de esa entrada, y deja intacto el resto del sitio. La publicación pasa a ser el disparador, la redacción ve el resultado al instante y nadie necesita ampliar el efecto a todo el portal.

Redis y Memcached cumplen funciones distintas. La caché de objetos acorta las consultas que cualquier petición paga igualmente, es decir menús, listados de categorías y las consultas de archivo más pesadas. Los datos volátiles, que no necesitan sobrevivir a un reinicio, viven aparte. Esa separación tiene una ventaja operativa: vaciar la caché de objetos durante una incidencia no expulsa a nadie del panel de administración.

La red de distribución añade la tercera capa y pesa sobre todo para el lector de fuera. Quien lee desde otra ciudad o desde el móvil en itinerancia recibe los archivos estáticos de un nodo cercano, y el servidor de aplicación no llega a ver esas peticiones. En el material de guía, cargado de imágenes, es el mayor ahorro individual de toda la implementación.

#Carga asíncrona, mapas y fotografías

Los listados de noticias cargan entradas adicionales de forma asíncrona, mediante AJAX y endpoints REST propios, en lugar de recargar la página. La comodidad es evidente; los costes son dos y en 2012 resultaban fáciles de pasar por alto. El primero afecta al buscador: el contenido que solo aparece tras un clic puede ser invisible para un rastreador, de modo que la primera tanda de cualquier listado está en el código de la página, la carga asíncrona se ocupa solo de las páginas siguientes y la paginación numerada permanece en el marcado aunque la interfaz no la muestre. El segundo coste es la caché: un endpoint que devuelve un fragmento de listado es una dirección propia, y o tiene su propia política de caché o se convierte en el agujero por el que el tráfico punta entra en PHP.

Los mapas siguen el mismo razonamiento. Un mapa de un proveedor externo son varios cientos de kilobytes de script más una conexión a un servidor ajeno, pagados mire o no el visitante el mapa. Se carga cuando la persona llega de verdad a la sección de localización, y hasta entonces ocupa su sitio una imagen estática con la dirección. Para un lector con el móvil en la calle, comprobando un único dato, esa diferencia decide si la página llega a abrirse.

Las fotografías merecen una frase propia, porque en un portal urbano son la mayor parte de los bytes transferidos. La redacción publica directamente desde la cámara, en un tamaño muy superior a cualquier vista del sitio. El procesamiento en la subida genera variantes para el listado, para la vista del artículo y para la galería, y la plantilla indica al navegador qué variante corresponde a cada ancho de pantalla. Sin eso, el lector móvil descarga una foto preparada para un monitor, la paga en datos y en tiempo, y la redacción nunca se entera, porque en su conexión todo va rápido.

#Migrar un archivo más antiguo que el sitio

Parte del material procedía de versiones anteriores del servicio y había que trasladarlo con su histórico. Importar desde copias archivadas, entre ellas las de Web Archive, parece una hora de trabajo y lleva varios días, siempre por los mismos motivos.

Los sistemas antiguos usaban otra codificación de caracteres, así que los diacríticos polacos vuelven de la importación convertidos en secuencias de bytes sin sentido, visibles solo cuando alguien lee ese párrafo concreto. Las direcciones antiguas tienen otra forma, por lo que cada pieza importada necesita una redirección desde su dirección anterior; sin ella el sitio tira por la borda todos los enlaces entrantes y todas las posiciones construidas durante años. Las imágenes archivadas llegan a menudo incompletas y sus pies de foto viven dentro del texto en lugar de en un campo propio.

El orden de las operaciones fue determinante: primero el mapa de direcciones antiguas a nuevas, después la importación del contenido y al final la revisión manual de una muestra sobre una copia de producción. El orden inverso termina en una segunda importación, porque corregir direcciones después del arranque significa que una parte del tráfico ya ha caído en el vacío.

#Un símbolo que tiene que funcionar en una cabecera

El proyecto incluyó la identidad visual, y el símbolo se dibujó para el lugar donde vive realmente. El logotipo de un portal pasa la mayor parte del tiempo en una barra superior de unas pocas decenas de píxeles, en un teléfono, junto al botón de menú, y además tiene que seguir siendo reconocible como icono en una pestaña del navegador. Eso invierte las prioridades de una marca pensada para imprenta: legibilidad en tamaño pequeño, comportamiento sobre fondo plano y una variante simplificada que no se deshaga con una docena de píxeles de ancho. Una marca solo horizontal y con detalles finos luce en una presentación y desaparece en una cabecera real, así que las variantes se hicieron junto con las plantillas y no antes.

#Mantenimiento y una regla sobre los plugins

Un medio informativo no tiene estado de reposo, de modo que el mantenimiento se planificó junto con la implementación y no después: actualizaciones del núcleo, del tema y de los plugins, revisión de registros del sistema, copias de seguridad cuya restauración se ensaya de verdad y no solo se programa, y pequeños cambios funcionales derivados de cómo trabaja la redacción en la práctica.

Conviene decir una regla sin rodeos. La seguridad se resuelve en el código y en la configuración del servidor, no con otro plugin de protección. Un plugin de ese tipo se ejecuta dentro de PHP, es decir, después de que la petición ya haya arrancado la aplicación, con frecuencia acaba siendo él mismo una vulnerabilidad y cobra un coste en cada petición. En un portal con tráfico desigual, que debe aguantar un pico el día en que ocurre algo en la ciudad, es un mal intercambio. El filtrado en la entrada, la comprobación de permisos en el código y una configuración de servidor estricta cuestan menos y actúan antes.

La moderación de comentarios acabó siendo un apartado propio del mantenimiento. La discusión bajo las noticias locales es la parte más viva de un portal urbano y la que más a menudo necesita a una persona leyendo de verdad. La redacción recibió herramientas de moderación y una cola de mensajes retenidos, no un automatismo. Retirar un comentario sobre un asunto municipal es una decisión editorial y no técnica, y un filtro automático habría salido más barato de operar y se habría equivocado justo en los casos que importan. Son los casos en los que un vecino acusa al ayuntamiento de algo.

Las pruebas previas al lanzamiento se hicieron contra una copia de producción y no contra una instalación vacía, porque una instalación vacía tiene diez entradas, cualquier listado cabe en una pantalla, cualquier consulta es inmediata y el archivo no existe. Los problemas de un portal empiezan a partir de unos miles de piezas, cuando las páginas de categoría se vuelven lentas, la búsqueda interna devuelve resultados ordenados sin criterio útil y la paginación llega a la página veinte, que nadie abrió durante las pruebas. Una copia de producción muestra todo eso en pocos minutos.

#Resumen y lo que fijó la fase de análisis

La fase de análisis cerró cuatro cuestiones que después ordenaron cada decisión. El público se definió por partida doble, residente y visitante, aceptando de forma explícita que quieren cosas distintas y que la portada tiene que servir a ambos. El alcance cubrió gestión de contenidos, calendario de eventos, mapas de localización, galerías y comentarios.

El calendario se dividió en etapas, lo que permitió a la redacción empezar a llenar el sitio antes de terminar los últimos trabajos. Las referencias que señaló el cliente eran portales con fuerte vínculo comunitario, y de ahí que comentarios y eventos quedaran arriba y la capa decorativa abajo. Ninguna de esas cuatro cuestiones era técnica, y cada una de ellas decidió después una cuestión técnica.

A una implementación posterior se traslada la capa técnica y la forma de razonar sobre la caché en contenido editorial. No se traslada el modelo de contenidos de este proyecto, escrito para una ciudad, una redacción y un ritmo de publicación concretos. El siguiente portal empieza por la pregunta de quién lo lee y con qué frecuencia, y solo después por lo que va a la base de datos. Ese orden es la parte de este trabajo que sirve en cualquier otro sitio.