Desarrollo E-commerce: nehrebeccy.pl

#El peso de las fotografías condicionó el resto del proyecto

Conviene empezar por lo que más pesa en este sitio, porque explica casi todas las decisiones técnicas que vinieron después. Una agencia artística documenta cada velada con fotografías, y esas fotografías llegan tal como salen de la cámara. No son ilustraciones decorativas que se puedan recortar a cualquier tamaño: son la prueba de que el acto ocurrió y de que salió bien, así que nadie va a aceptar que se publiquen degradadas.

De ahí que el trabajo de rendimiento se dividiera desde el principio en dos problemas distintos, resueltos con dos herramientas distintas. La caché de objetos en memoria acorta el trabajo de base de datos para todo lo que de todas formas tiene que pasar por PHP: conjuntos de entradas, términos de taxonomía, opciones. La red de distribución se ocupa de los archivos, es decir, de las fotografías y las grabaciones. Merece la pena decirlo sin rodeos porque se confunde a menudo: una caché de objetos no acelera la descarga de una imagen, y una red de borde no acorta una consulta a la base de datos.

Hay un tercer frente que no resuelve ninguna de las dos capas. Una velada deja imágenes en una cantidad que nadie mira de una sentada, y cargar todos los archivos al construir la página hace que la visitante pague por fotos a las que nunca llega. La galería entrega primero las miniaturas y solo trae las versiones grandes cuando alguien las abre. Hoy suena obvio, pero en 2012 la carga diferida era código propio y no un atributo del elemento de imagen que el navegador respeta por su cuenta.

#Quién es el cliente

R&K Nehrebeccy es una agencia artística de Gdynia, dirigida por Renata y Krystian Nehrebecki, en actividad ininterrumpida desde 1994. Crea y produce eventos artísticos: encuentros con figuras conocidas, conciertos, espectáculos, inauguraciones solemnes, aniversarios y jubileos, cubriendo el recorrido completo desde la idea y el guion hasta la contratación de los artistas, la escenografía y las proyecciones. Una parte reconocible de la oferta son las veladas literarias construidas alrededor de encuentros con autores de libros.

Quien está al otro lado de una consulta no es un consumidor. Es la coordinación de programación de una casa de cultura o de una biblioteca, o la persona de una empresa a la que le ha tocado organizar el aniversario. Esa persona llega con un nombre en la cabeza, comprueba si la agencia ya ha trabajado con ese nombre y solo después escribe o llama. La navegación tenía que ir, por tanto, de un nombre a un evento y de un evento de vuelta a un nombre, y no de la portada a una pestaña de servicios.

#Modelo de contenido: artista y evento

La implementación corre sobre WordPress y la primera decisión fue qué es un artista en la base de datos y qué es un evento. La vía aparentemente más barata, describir ambos como entradas corrientes o, peor, como páginas, ahorra una tarde durante la construcción y se cobra en cada cambio posterior. Una entrada normal no tiene sitio para una fecha de evento, un lugar, ni el papel que tuvo un artista concreto en esa velada concreta. Todo eso acaba dentro del texto, es decir, en un único campo del que no se puede extraer nada de forma programática.

Por eso artista y evento son aquí tipos de contenido separados, unidos por una relación. Un evento tiene varios participantes, un participante tiene muchos eventos, y esa estructura es exactamente lo que permite generar dos vistas a partir de un mismo conjunto de datos: el perfil del artista con la lista de sus apariciones, y la página del evento con la lista de quienes intervinieron. Si esas listas se escribieran a mano en ambos lados, cada cambio exigiría editar en dos sitios, y al cabo de un año la mitad se habría desajustado en silencio.

Las taxonomías ordenan lo mismo desde una tercera dirección. Separar a los participantes en escritores, actores y periodistas, y a los eventos en concierto, encuentro con autor, inauguración y jubileo, produce listados que nadie tiene que mantener. Una entrada nueva asignada a su categoría aparece sola en el listado correcto. Parece un detalle hasta que se recuerda que el sitio lo llevan dos personas junto a su trabajo real, donde la diferencia entre una lista generada y una lista sostenida a mano decide si el sitio sigue siendo cierto tres años después.

#Funcionalidades principales del sitio

El portafolio de artistas es la vista principal. Cada perfil reúne fotografías, una descripción de la trayectoria y el historial de colaboración, y el orden de la información tiene una sola tarea: permitir juzgar en pocos segundos si esa persona encaja en la velada que alguien está planificando. De ahí que la fotografía y la descripción breve estén por encima de la biografía completa, y que la lista de apariciones se vea sin bajar hasta el final.

El calendario y el archivo son los mismos datos vistos desde dos lados. Los eventos próximos son información para el público, los pasados son prueba para quien contrata. Un evento no desaparece cuando pasa su fecha, cambia de vista.

La edición ocurre en el panel estándar de WordPress, con campos ajustados a los tipos de contenido descritos arriba. Deliberadamente no hay constructor visual de páginas. Quien añade un evento entre dos encuentros con autores debe rellenar campos, no diseñar una maquetación, porque diseñar una maquetación en cada entrada es el camino más corto a un sitio cuyas veinte subpáginas parecen veinte sitios distintos.

Compartir en redes sociales es aquí una función y no un adorno. La noticia de un encuentro con un autor circula por los perfiles de quienes participan y por las páginas de las instituciones que lo acogen, así que cada entrada necesita metadatos de compartición correctos: título, descripción y una imagen que no sea un recorte casual del fondo.

#Desafíos y soluciones de programación implementadas

El primer desafío fue recorrer una oferta amplia sin recargar la página entera. El filtrado de artistas por categoría y la carga de tramos sucesivos de la lista ocurren por AJAX, lo que en 2012 significaba un mecanismo concreto: la petición llega al punto de entrada compartido de WordPress para llamadas asíncronas. Conviene saber qué cuesta eso, porque explica el resto. Cada una de esas peticiones arranca WordPress entero junto con sus extensiones, de modo que cuesta más o menos lo mismo que generar una página completa, aunque en la respuesta solo viaje un fragmento de lista. A lo largo de una sesión en la que alguien alterna filtros varias veces, se acumula.

De ahí la construcción: la lista se mantiene corta, el filtro estrecha el conjunto dentro de la consulta y no en el navegador, y el resultado de una combinación de filtros se puede guardar en caché. La alternativa, traer todos los artistas de una vez y tamizarlos en el navegador, resulta tentadora porque el código sale más simple, y deja de funcionar exactamente cuando el conjunto crece lo bastante para que enviarlo entero cueste más que las peticiones adicionales.

El segundo desafío fue la maquetación responsiva en un año en que la responsividad era una práctica reciente y no la opción por defecto. En 2012 los navegadores todavía no tenían un mecanismo para elegir la variante de imagen del lado del cliente; esa capacidad llegó a WordPress varios años después. La decisión sobre qué versión de una fotografía enviar se tomaba en el servidor, a partir de los tamaños registrados. Una galería subida directamente desde la cámara del fotógrafo necesitaba por eso tamaños intermedios definidos de antemano, o un teléfono descargaba el archivo preparado para una pantalla de escritorio.

El preprocesador de hojas de estilo no era en esa situación un ornamento, sino la herramienta que mantenía los puntos de ruptura en un único sitio. Sin él, los umbrales de anchura se dispersan por toda la hoja y cualquier cambio en la rejilla obliga a tocar una docena de lugares a la vez. La maquetación además es anterior a las rejillas nativas en los navegadores, así que las columnas se apoyaban en elementos flotantes y anchuras porcentuales, lo que exige cuidado cuando una galería tiene un número variable de elementos y las filas deben cerrar limpias.

El tercer desafío fue la facilidad de actualización, y la respuesta ahí es organizativa antes que técnica: campos en lugar de contenido libre, listas generadas a partir de relaciones en lugar de escritas, y tamaños de imagen definidos en lugar de una decisión en cada subida. Un sitio en el que la persona que edita tiene que recordar tres reglas para no romper la maquetación es un sitio que se rompe la primera semana tras la entrega.

El cuarto desafío fue poder deshacer. Contenido, configuración y código están separados, y esa propiedad solo se hace visible en el primer cambio que sale mal después del lanzamiento. Si el aspecto de una sección depende de lo que alguien escribió en el cuerpo de una entrada, entonces una corrección visual es una edición de contenido y no se puede revertir sin deshacer trabajo editorial. Mantenerlos aparte significa que una reversión mueve una de las tres capas y no las tres.

#El archivo como argumento comercial

En la mayoría de los sitios con calendario un evento pasado es desecho. Aquí ocurre lo contrario, y esa inversión determina cómo hay que guardar la fecha.

El reflejo natural es colgar la fecha de la entrada como campo adicional. En WordPress ese campo acaba en la tabla de metadatos, donde los valores se almacenan como texto y no como fecha. Una consulta por eventos futuros deja entonces de ser una comparación de fechas y pasa a ser una comparación de cadenas, que produce disparates en cuanto un formato con el día por delante cruza un cambio de mes. Además, cada consulta de ese tipo añade una unión con la tabla de metadatos, y filtrar y ordenar por el mismo campo añade más.

Hay dos salidas limpias y ambas exigen decidir al principio y no al cabo de un año. O la fecha se escribe en un formato que ordena correctamente como texto, año primero y sin separadores, o la propia fecha de publicación de la entrada lleva la fecha del evento y se ajusta el tratamiento de las entradas con fecha futura, con lo que toda la selección pasa a una columna indexada de la tabla de entradas. La diferencia es invisible con cincuenta entradas y muy visible cuando el archivo lleva una década creciendo, que es justamente para lo que existe el archivo.

La segunda trampa afecta a las direcciones. La página de un evento de hace tres años suele estar enlazada desde la biblioteca o la casa de cultura que lo acogió. Si la dirección se construye alrededor de si el evento es próximo o pasado, cruzar la fecha cambia la dirección y todos esos enlaces se rompen. La dirección debe describir qué es el evento, nunca en qué pestaña se muestra en este momento.

#Soporte y mantenimiento del sitio

El soporte del sitio cubre actualizaciones del núcleo y del tema, revisión de registros y copias de seguridad. El orden importa: una copia que nadie ha restaurado nunca no es una copia, es un archivo. Verificar la restauración forma parte del trabajo y no es un añadido.

Las actualizaciones tienen un riesgo propio en un sitio construido sobre relaciones entre tipos de contenido. Cuando el vínculo entre un artista y un evento lo sostiene una capa intermedia, un cambio ahí puede alterar cómo se guardan esos vínculos, y la vista de listado parece correcta justo hasta que alguien crea una entrada nueva. Por eso las actualizaciones van primero a una copia, y la comprobación consiste en crear un vínculo nuevo, no en mirar la portada.

Los cambios visuales y funcionales menores durante el mantenimiento siguen la misma regla que la construcción: un cambio entra en la capa a la que pertenece. Un nuevo tipo de evento es un término de taxonomía, no una plantilla nueva. Otras proporciones en la galería son un cambio de los tamaños de imagen registrados y su regeneración, no una regla de estilo pegada a una sola subpágina.

#Cómo transcurrió la implementación

El conjunto llevó alrededor de seis semanas, desde acordar el alcance hasta la publicación. La maquetación y la disposición de los elementos las aportó el cliente, así que la fase que en otros proyectos se come más calendario aquí no existió. El tiempo fue al modelo de contenido y a las partes que una maqueta no enseña: la relación entre artista y evento, cómo se guarda la fecha, los tamaños de imagen y el comportamiento de los listados al filtrar.

Los casos límite se probaron contra una copia de producción y no contra una instalación vacía. En un sitio con esta forma la diferencia es concreta: una instalación vacía no tiene una entrada con ochenta fotografías en una galería, ni un artista ligado a eventos repartidos por varios años, ni entradas con el campo de fecha rellenado de forma inconsistente porque alguien lo escribió a mano en otro formato. Los tres casos aparecen solo con datos reales, y cada uno puede tumbar una vista de listado.

Tras el lanzamiento el sitio pasó a mantenimiento llevado del lado de la agencia, con nuestro apoyo en actualizaciones y en cambios que van más allá de editar contenido.

#Resumen

nehrebeccy.pl es el sitio de una agencia artística construido alrededor de dos entidades, el artista y el evento, y de la relación entre ambas. De esa estructura salen todas las vistas: el perfil con sus apariciones, la página del evento con sus participantes, los listados por categoría y el archivo, que en este oficio es un activo y no un lastre.

En lo técnico la implementación descansa sobre WordPress, una caché de objetos en memoria, una red de distribución para los medios y una maquetación responsiva hecha cuando la responsividad todavía significaba trabajo manual en cada variante de imagen. En lo organizativo descansa sobre algo más simple: un sitio que llevan dos personas junto a su trabajo real tiene que sobrevivir a que nadie recuerde las reglas de la entrega.