Darío Ferrer - Blog

Por supuesto se agradece al core team de Wordpress haber tomado en cuenta una necesidad apremiante y que tenía mucho tiempo sin ser satisfecha, tal como lo representa el hecho de contar, en el nuevo Wordpress 2.9, con un nuevo campo exclusivo para el atributo ALT de las imágenes:

Antes:

Después:

Apenas noté su presencia me alegré un montón, pues actualmente me encuentro actualizando la nueva versión de WP Smart Image y -por supuesto- adaptándola a WP 2.9. Sin embargo tal contentura se convirtió en lo que mi abuela califica acertadamente como “alegría de tísico”, pues al llegar a la raiz del asunto me percaté de que posiblemente se haya solucionado un desacierto con otro.

El problema con el atributo ALT

El problema estaba claro: hasta hace poco Wordpress no contaba con una opción sólida para ingresar el atributo ALT a las imágenes. Dicho texto quedaba vacío a no ser que se ingresara en el campo Caption del formulario de imágenes, el cual -si no estaba vacío- compartía contenido entre la fotoleyenda y el susodicho ALT.

Dicha estrategia hubiese sido correcta si no fuese por el “detalle” de que -al llenar ese campo- se activaban automáticamente los shortcodes CAPTION, cuyo fin es activar un conjunto de etiquetas para formatear imagen y leyenda en un solo bloque. Dicho aspecto hacía (y sigue haciendo, puesto que aún está vigente en la última versión estable) inutilizable este campo para muchas tareas, tanto de desarrollo como de la misma gestión de contenido.

Un método dudoso

Wordpress 2.9 viene solucionando el asunto al incluir el mencionado campo para el atributo ALT. No obstante -sin agraviar el “qué”- es el “cómo” el que deja cierto mal sabor de boca. Junto con la nueva versión 2.9 (aún en fase beta, gracias a Dios) se introdujo este recurso a través de un campo de la base de datos denominado _wp_attachment_image_alt, dentro de la tabla $wpbd->postmeta y por supuesto asociado con la imagen procesada.

Tal método me ha llamado la atención por tres motivos principales: 1) Porque se trata de un procedimiento burdo, digno del desarrollador más novato del planeta, 2) por la misma extrañeza que lo anterior genera, ya que estamos hablando de un código que ya forma parte del core de Wordpress y 3) porque la genuina solución al problema es demasiado simple, visible y plenamente eficaz.

¿Medicina peor que la enfermedad?

A efectos de la base de datos las imágenes son consideradas entradas, por lo cual comparten las mismas tablas, campos y registros que lpos posts comunes (los artículos), con la diferencia de que éstas reflejan valores diferentes en ciertos campos con la finalidad de que Wordpress “comprenda” que no son artículos sino attachments y -a su vez- otro campo las identifica como imágenes. En realidad es una estructura que conjuga muy bien el minimalismo con la robustez y rendimiento.

Dentro de la lista de campos compartidos existen tres que se relacionan con el tema que estamos tratando, todos ubicados dentro de la tabla $wpbd->posts: ‘post_content’, ‘post_title’ y ‘post_excerpt’. Veamos cómo están distribuidos estos datos en la actual versión 2.8.6:

Vemos entonces que el campo ‘post_content’ de la base de datos controla la parte de la Descripción, ‘post_title’ el atributo TITLE, y finalmente ‘post_excerpt’ es compartido entre el texto alternativo (ALT) y la fotoleyenda (caption). Ahora bien, desde el punto de vista de la gestión de imágenes, estos tres campos han sido y siguen siendo sub-aprovechados.

En virtud de lo anterior, sinceramente no veo el inconveniente para asignar la fotoleyenda a ‘post_content’, el TITLE a ‘post_title’ y el ALT a ‘post_excerpt’. Pero no. Había que echar garra a la ya apretujada tabla $wpbd->postmeta (donde está alojado el campo _wp_attachment_image_alt, obligando así al pobre Wordpress a consultar frecuentemente nada menos que las dos tablas más voluminosas del sistema sólo para construir debidamente la etiqueta IMG. Veamos cómo lo hicieron en la versión 2.9 beta:

¿No era acaso más fácil aprovechar inteligentemente los campos ubicados en $wpbd->posts y -desde este principio- mejorar la arquitectura correspondiente al procesamiento de imágenes?. A continuación una pequeña propuesta de solución:

Solucionando correctamente el problema (o al menos el intento)

Tal como mencioné, la solución para los atributos de las imágenes podría ser muy simple; quizás algo como esto:

Hasta el momento no veo ningún eventual conflicto para organizar el texto en estas tablas. La idea es que -al cargar cada imagen, el sistema efectúe las consultas a la base de datos de manera más abreviada y rápida (además de conservar un sentido lógico en el almacenamiento de la data correspondiente). Y si es por compartir, creo que la lógica apunta más entre Caption/Description que Caption/ALT.

A menos que me haya perdido de algo, para Wordpress sería mucho más rápido desplegar los queries sobre una sola tabla que sobre dos, y más aún si la segunda tabla es la temible $wpbd->postmeta, la cual tiende a inflarse rápidamente porque es precisamente la tabla que el sistema coloca a disposición de los desarrolladores para personalizar el conjunto de funciones que requieren alojamiento de datos. Imaginémonos entonces un sistema que deba consultar frecuentemente una tabla tan inmensa, sólo para extraer un atributo de un elemento tan presente y repetitivo como las imágenes.

Lo que en realidad me sorprende es que todo lo mencionado no es ciencia espacial. La lid en pro de la optimización de los sistemas se ha convertido en parte del pan diario y obligatorio de quienes desarrollamos sitios web. Con más razón la gente del Core debería tenerlo presente, pero por alguno motivo adoptaron dicho método.

Segunda propuesta – Caption y ALT

No sé cuál es el culto al Caption que se ha conservado durante tanto tiempo. Si ingresas texto en ese campo, automáticamente se genera el montón de etiquetas ya mencionadas (2.8.X). Sólo este detalle hace que, a vista del desarrollador, ese importante campo de texto sea descartable, pues si decidimos usarlo para lo que en realidad es útil (el atributo ALT) es necesario incluir, paralelamente, una función que desactive la generación de los shortcodes, es decir, debe inutilizarse la aparición de los elementos HTML necesarios para lograr el bloque de imagen + texto de leyenda (lo cual también es muy útil).

Entonces, la otra propuesta sería (y creo que ésta es mucho más viable): Dejar la estructura de datos tal como está actualmente y, paralelamente, agregar un checkbox que el usuario pueda activar cuando desee incluir las etiquetas correspondientes a imagen con fotoleyenda. Noten el checkbox a la derecha del formulario:

…y de esta manera el recurso vuelve a recobrar su utilidad sin menoscabo de la usabilidad. Si quieres la fotoleyenda marcas el checkbox y listo.

¿Qué hay de los portales grandes?

Hace poco escribí un artículo que en gran parte se enfocaba a la optimización y equilibrio racional de la carga dinámica de datos en Wordpress. Afortunadamente el grueso de la data de contenido se almacena en forma estática (Incluyendo las imágenes de los artículos) pero, por otro lado, los elementos de contenido que permanecen en la página principal son, en su gran mayoría, dinámicos ¡Incluyendo las imágenes!, cuyos datos necesitan ser consultados de forma directa una y otra vez (al menos en sitios informativos de alto tráfico que encontrarían contraproducente el cacheo de contenido).

Para los sitios de alto tráfico (grupo principalmente conformados por megablogs y megaportales) no existen muchas soluciones viables que involucren elementos estáticos. En muchos casos su frecuencia de publicación se cuenta en segundos. Aún así podría mantenerse la iniciativa de -al menos- proveer sistemas que también apunten a dicho fin.

“Tradicionalmente” Wordpress está concebido por muchos como un CMS para blogs, pero el tiempo y los hechos han demostrado que (quizás por la similitud de las disciplinas y sus exigencias) representa igualmente una solución válida para el desarrollo de plataformas informativas y -de hecho- desde hace mucho tiempo el equipo de desarrollo ha estado tomando en cuenta este aspecto.

Y entonces…

El meollo del asunto es que la optimización de la carga dinámica no representa obstáculo alguno para la línea que está siguiendo Wordpress. Daría mucha pena contemplar cómo un sistema que ha alcanzado tal evolución (en mi opinión adelantada para la época) decae poco a poco a causa de la complacencia de peticiones, la ausencia de colaboración adaptada a las exigencias y la mala cabeza de algún eventual “genio trasnochado” con carta blanca en el Core.

De todas formas el asunto está reportado en este ticket del Trac de Wordpress