Cómo solucionar el problema con las miniaturas del teaser en Drupal 11
Corrección de estiramientos y pixelamientos no deseados
Caso real en mi blog sobre Drupal 11 con el tema Solo. En el monitor ancho de casa, la portada se veía impecable: cada artículo del listado mostraba su miniatura pequeña al lado del texto. Pero en un monitor casi cuadrado en mi lugar de trabajo, un monitor con relación de aspecto 5:4 (resolución 1280×1024), esa misma miniatura de 220 px aparecía enorme y pixelada; también en un monitor de 27 pulgadas girado a vertical (1080×1920, proporción 9:16). Lo primero que sospeché fue una conversión de imágenes a WebP que había hecho días antes. Falsa pista. El culpable era un script del tema Solo que, después de cargar la página, le metía a la imagen un ancho inline que pisaba mi hoja de estilos. La solución cupo en tres líneas de la hoja de estilos CSS con el modificador !important.
Esa mañana estaba en la sala de cómputo de mi lugar de trabajo, terminando un examen en uno de esos computadores con monitor casi cuadrado (con relación de aspecto 5:4 y resolución 1280×1024), de los que ya casi no se ven. Como suelo hacer cuando tengo tiempo libre frente a alguna computadora que no es la mía, entré a curiosear mi propio sitio, orlandocarcamo.com. Y me llevé un susto: las imágenes del listado de artículos —esas miniaturas que van al lado cada resumen de los artículos, en la portada— aparecían gigantes y pixeladas, todas borrosas, feas. No era así como yo las había dejado en el proceso de mantenimiento del blog.
Recargué la página. Nada. La cerré y la volví a abrir. Igual. Pensé que era cosa de ese computador viejo de la sala y me quedé con la duda en el camino de regreso a casa.
Ya en mi estudio, encendí mi ordenador con monitor ancho de 34 pulgadas y entré de nuevo al sitio. Todo perfecto: las miniaturas pequeñitas al lado del texto resumen de cada artículo, como debe ser. «Entonces sí era el computador de la universidad», pensé. Pero por curiosidad arrastré la ventana del navegador a mi segundo monitor, el que tengo en vertical, y ahí estaba otra vez el problema: la misma imagen, estirada y pixelada. No era el computador de la sala. Era algo de mi sitio que solo se rompía en pantallas angostas. Y como yo soy un profesor que no cuenta con la ayuda técnica de un ingeniero, entonces, si mi blog trabaja mal, me toca a mí sentarme a diagnosticar el problema y comenzar a arreglarlo.
Problema real
En la portada de mi blog, cada artículo del listado se muestra en formato teaser: una miniatura pequeña a la izquierda y, al lado, el título y el resumen. Esa miniatura es una imagen recortada por Drupal a 220×148 píxeles. Diminuta y liviana, justo para lo que sirve.
El problema aparecía solo en pantallas de poca anchura —el monitor cuadrado de la universidad, mi monitor vertical— y tenía dos rasgos muy concretos:
- La miniatura se agrandaba: en lugar de quedarse en sus 220 px, se estiraba para ocupar buena parte del ancho de la columna.
- Se veía pixelada: como el archivo real solo mide 220 px, al forzarlo a varios cientos de píxeles el navegador tenía que «inventar» los que faltaban, y la imagen se veía borrosa y con dientes.
Síntoma principal
La miniatura del teaser se veía nítida y pequeña en monitores anchos, pero enorme y pixelada en monitores cuadrados o verticales. El contenido y el archivo de la imagen estaban bien; el problema era exclusivamente que algo la estiraba más allá de su tamaño real cuando la pantalla era angosta.
Al inspeccionar la etiqueta de la imagen con las herramientas del navegador —clic derecho sobre el elemento problemático y selección de "inspeccionar"—, esto era lo que aparecía:
<img loading="lazy"
src="…/styles/medium/…/imagen-central….jpg.webp?itok=…"
width="220" height="148"
alt="…"
class="solo-image image-style-medium"
data-once="solo-clickable-images solo-broken-images">Dos cosas saltaban a la vista. La etiqueta declaraba width="220" height="148": el tamaño correcto estaba ahí escrito. Y, sin embargo, la imagen se mostraba mucho más grande. Cuando lo que una etiqueta declara y lo que el navegador muestra no coinciden, la culpa casi siempre es de un estilo que manda por encima en la jerarquía.
Contexto mínimo
- Plataforma: Drupal 11 autoalojado en un VPS propio.
- Sitio:
orlandocarcamo.com. - Tema: Solo (un tema comercial para Drupal).
- Componente afectado: la miniatura del teaser en el listado de artículos de la portada, servida por el estilo de imagen
mediuma 220×148 px. - Cuándo se veía: solo en pantallas de poca anchura —monitores cuadrados y monitores en orientación vertical—. En monitores anchos, invisible.
Un dato que despistaba
Pocos días antes había convertido a WebP las imágenes centrales de mis artículos para que cargaran más rápido sin perder calidad. Como el problema apareció «después» de ese cambio, mi primer instinto fue culpar a la conversión. Es una trampa lógica muy común: que dos cosas ocurran seguidas no significa que una haya causado la otra. Guardar esa sospecha para verificarla —en vez de darla por cierta— fue lo que evitó perder tiempo por el camino equivocado.
Causa del error o confusión
Primera hipótesis descartada: la culpa es del WebP
La sospecha más a mano era el cambio reciente de formato. Pero bastó pensarlo un momento para descartarlo. Una imagen se ve pixelada cuando la agrandas por encima de su tamaño real, y eso pasa igual sea JPG, PNG o WebP. El formato no estira nada. Además, la misma imagen se veía nítida en el monitor ancho y borrosa en el vertical: si fuera culpa del archivo, se vería mal en los dos. El formato WebP quedó libre de sospecha.
Segunda pista: solo se rompe en pantallas angostas
Que el fallo dependiera del ancho de la pantalla apuntaba directamente al CSS responsive, esa parte de las hojas de estilo que reacomoda el diseño según el tamaño de la ventana. En pantallas anchas, la columna del teaser es estrecha y no deja crecer la imagen. En pantallas angostas, la columna se ensancha, y si la imagen tiene permiso para ocupar «todo el ancho disponible», crece con ella. Todo encajaba con una regla del tipo width: 100% aplicada a la miniatura.
La pista definitiva: cargaba bien y «saltaba» después
Al probar una primera corrección en CSS, ocurrió algo revelador: la página cargaba con la imagen del tamaño correcto y, un instante después, la imagen volvía a agrandarse sola. Ese «salto» posterior a la carga es la firma inconfundible de un script JavaScript que interviene sobre la imagen después de que la página se dibuja en la pantalla. Y en la etiqueta revelada con "inspeccionar" estaba la prueba: data-once="solo-clickable-images solo-broken-images". El tema Solo trae un script que procesa las imágenes al terminar la carga.
Por qué el CSS normal no ganaba
Ese script no solo tocaba la imagen: le escribía el ancho directamente en la propia etiqueta, en lo que se llama un estilo inline (un style="…" pegado al elemento). Y en las reglas de CSS, un estilo inline tiene más prioridad que cualquier regla de una hoja de estilos externa. Por eso mi corrección se veía un instante y luego el script la pisaba: mi CSS mandaba primero, el inline mandaba después.
La causa clave (en una frase)
La miniatura se estiraba porque un script del tema Solo le aplicaba un ancho inline tras cargar la página, y ese estilo inline vencía a mi hoja de estilos. No era el WebP ni la caché: era una cuestión de prioridad entre estilos, y mi CSS estaba perdiendo esa batalla.
Solución documentada (paso a paso)
Principio de la solución
Cuando un estilo inline puesto por un script te está pisando el CSS, hay una sola palabra en las hojas de estilo que puede vencerlo: !important. Es el único mecanismo del CSS con prioridad suficiente para superar a un estilo inline. La meta era fijar la miniatura a su ancho real de 220 px de forma que ni el script pudiera cambiarlo, sin romper la adaptabilidad en móvil.
Paso 1 — Localizar la clase correcta
La miniatura llevaba dos clases útiles: solo-image (la que el tema usa para procesar la imagen) e image-style-medium (la del estilo de imagen de 220 px). Combinar ambas en el selector apunta con precisión a esta miniatura y no a otras imágenes del sitio.
Paso 2 — Escribir la regla con !important
En el CSS del tema solo tuve que añadir esta regla. El comentario que fijé en la cabecera es a propósito porque cuando uno vuelve a leer su propio código meses después, agradece que el «yo» del pasado le explique de qué se trataba.
/* ============================================================
FIX teaser: la miniatura se estiraba y pixelaba en
monitores cuadrados o verticales.
Causa: el JS del tema Solo (solo-clickable-images) reajusta
las imagenes tras cargar la pagina y les mete un width
inline que agranda la miniatura 'medium' (220x148).
La declación !important es necesaria para vencer ese estilo inline.
Orlando Carcamo - 11/09/2026
============================================================ */
.solo-image.image-style-medium {
width: 220px !important;
height: auto !important;
max-width: 100% !important;
}Qué hace cada línea
width: 220px devuelve la miniatura a su ancho real. height: auto deja que la altura se ajuste sola y no se deforme. max-width: 100% es la red de seguridad: en una pantalla muy pequeña —un móvil angosto— la imagen nunca se desbordará del contenedor, porque este tope siempre la contiene. Y el !important en las tres es lo que le gana la partida al estilo inline del script.
Paso 3 — Guardar, limpiar caché y comprobar
Tras guardar el cambio y vaciar la caché de Drupal, la comprobación fue directa: abrir el sitio en el monitor vertical, que era donde el fallo se reproducía sin falta. Esta vez la miniatura cargó pequeña y se quedó pequeña. El script ya no podía agrandarla.
Sobre el uso de !important
Se suele decir, con razón, que abusar de !important es mala práctica porque vuelve el CSS difícil de mantener. Pero hay un caso legítimo para usarlo: exactamente cuando un script de terceros —aquí, el del tema Solo — impone estilos inline que uno no puede editar directamente. En esa situación, !important no es un atajo perezoso, sino la herramienta adecuada. La clave es reservarlo para esos casos concretos y dejarlo documentado, como lo hice aquí.
Evidencia (texto y/o registros)
El diagnóstico se apoyó en lo que revelaba la propia etiqueta de la imagen antes y después de aplicar la regla, observada con las herramientas del navegador:
| Momento | Ancho declarado | Ancho mostrado (monitor vertical) | Aspecto |
|---|---|---|---|
| Antes del fix | 220 px | estirada (varios cientos de px) | pixelada |
| Con CSS sin !important | 220 px | 220 px un instante, luego se agranda | pixelada tras el «salto» |
| Con CSS y !important | 220 px | 220 px, estable | nítida |
La señal que lo confirmó todo
La prueba definitiva no fue un registro del servidor, sino el comportamiento visible: con la regla sin !important, la imagen cargaba bien y «saltaba» a grande medio segundo después. Ese salto era el script actuando. Al añadir !important al CSS, el salto desapareció por completo y la miniatura se quedó clavada en sus 220 px, tanto en el monitor vertical como en el cuadrado.
Verificación
Consideré el problema resuelto cuando la miniatura se mostraba en su tamaño real y de forma estable en todas las pantallas. Las comprobaciones fueron:
- En el monitor vertical, la miniatura carga pequeña y ya no «salta» a grande tras cargar la página.
- En el monitor cuadrado —el escenario original del susto— la imagen se ve nítida, con el texto al lado como debe ser.
- En el monitor ancho, donde nunca falló, todo sigue igual: la regla no rompió nada de lo que ya funcionaba.
- En el móvil, la miniatura se adapta sin desbordarse, gracias al
max-width: 100%. - El comentario en el cabecero de la regla deja claro, para el futuro, qué hace ese trozo de código y por qué.
Qué queda pendiente
La regla resuelve la miniatura medium del teaser, que era la afectada. Si en algún momento otra imagen del tema Solo mostrara el mismo comportamiento —cargar bien y agrandarse después—, ya sé que el patrón es idéntico: es el script del tema imponiendo un estilo inline, y se corrige con el mismo enfoque, apuntando a la clase de esa otra imagen. Conviene tenerlo presente antes de volver a sospechar de la caché o del formato de archivo.
Aprendizajes y prevención
El primer aprendizaje fue no dejarse llevar por la coincidencia. Que el fallo apareciera después de convertir las imágenes a WebP hacía tentador culpar al WebP, pero un momento de razonamiento lo descartó: el formato no estira imágenes. Lo que va seguido en el tiempo no siempre está unido por una causa. Verificar la sospecha, en lugar de creerla, ahorra horas de trabajo por el camino equivocado.
El segundo aprendizaje fue leer el síntoma con atención. Que el problema apareciera solo en pantallas angostas señalaba al CSS responsive; y que la imagen «saltara» después de cargar señalaba a un script. Cada detalle del comportamiento era una pista sobre dónde mirar. El diagnóstico no fue adivinar, sino escuchar lo que el propio fallo estaba diciendo.
El tercer aprendizaje fue entender la jerarquía de estilos del CSS: una hoja de estilos externa pierde frente a un estilo inline, y un estilo inline pierde frente a !important. Saber ese orden de prioridades convirtió un problema desconcertante en una solución de tres líneas. No hacía falta pelear con el script ni desactivarlo; bastaba con hablar el idioma del CSS en su nivel más alto.
El cuarto aprendizaje fue de método: documentar la solución en el propio código. Un comentario de cinco líneas en el cabecero de la regla le ahorra al «yo» del futuro tener que redescubrir todo esto desde cero. Cuando uno administra su propio servidor y su propio blog sin un equipo de colaboradores, esos comentarios que preceden al código CSS son la memoria que uno no puede darse el lujo de perder.
Conclusión
Lo que empezó como un susto en una sala de cómputo terminó siendo una pequeña lección sobre cómo el navegador decide qué estilo obedecer. La miniatura no se estiraba por culpa del formato de imagen ni de la caché, sino porque un script del tema le imponía un ancho que mi CSS no lograba vencer. El diagnóstico honesto —descartar el WebP, escuchar el síntoma, encontrar el script— llevó directo a la causa sin instalar ni tocar nada de más.
La solución no fue pelearse con el tema ni desactivar su script, sino usar la única herramienta del CSS con prioridad suficiente para el caso: tres líneas con !important, apuntadas a la clase correcta y con un comentario que explica por qué están ahí. La miniatura volvió a su sitio, estable y nítida, en todas las pantallas.
Administrar el propio blog cuando uno es profesor y no empresa tiene estas cosas: los problemas los resuelve uno mismo, a veces de noche, después de un día de clases. Pero cada uno de esos problemas, bien entendido y bien documentado, se convierte en conocimiento que ya no se vuelve a perder. Y esa, al final, es la idea de esta serie de problemas reales y soluciones documentadas.
- Inicie sesión o registrese para enviar comentarios