Mi problema fue al diseñar web wordpress en la página de categoría. Le dije a la plantilla que usara un diseño especial para «Viajes», pero ella, testaruda, seguía usando el mismo diseño aburrido para todo. Pensé que era cosa del plugins en wordpress o que tenía algo mal configurado. Luego caí en la cuenta.
Es el código, no tú. WordPress tiene unas reglas de juego muy estrictas, la jerarquía de plantillas. Cuando alguien entra a una página, WordPress no elige la plantilla al tuntún. Sigue una lista de prioridades, como un detective buscando pistas, hasta dar con el archivo correcto.
Para mi categoría «Viajes» (supongamos que su slug es «viajes»), WordPress hizo esto:
- Primero buscó un archivo llamado
category-viajes.phpen la carpeta del tema. Esta es la pista más específica. - Como no lo encontré, siguió con una menos específica:
category.php. - Si ese tampoco existía, hubiera usado
archive.php, que sirve para archivos en general. - Y si todo falla, su última opción es el archivo básico
index.php. Es la red de seguridad de todas las plantillas.
Yo tenía creado el category.php, pero no el super específico category-viajes.php. Por eso mi diseño especial nunca se veía. WordPress se conformaba con lo que encontraba primero.
Lo curioso es que esta mecánica es la misma para todo: una entrada de blog, una página estática, los resultados de búsqueda. Siempre busca de lo más concreto a lo más genérico. Es como si tuvieras una llave maestra (index.php) y luego llaves para cada habitación (page.php, single.php), y hasta llaves con nombre para habitaciones concretas (page-contacto.php).
Ahora, el lío se pone mayor con los addons wordpress o temas de bloques (block themes), los más modernos. La lógica es la misma, pero cambian las piezas:
- Los archivos ya no son
.php, son.html. Contienen bloques, no código PHP complejo. - No van sueltos en la carpeta principal, sino en una subcarpeta llamada
/templates/. - Aquí hay un giro: WordPress puede guardar plantillas directamente en la base de datos. Si creas una plantilla personalizada desde el editor de sitio, esa se guarda ahí y tiene prioridad máxima, por encima de cualquier archivo
.htmlde la carpeta.
Este último punto es un arma de doble filo. Es potente porque puedes modificar diseños sin tocar archivos, pero también puede causar confusión. ¿Tu cambio no se ve? Mira si hay una plantilla «personalizada» guardada en la base de datos que esté tomando el control.
Si usas un tema hijo (child theme) para hacer modificaciones sin romper el tema principal, la jerarquía se duplica. WordPress mirará primero si el archivo que busca (por ejemplo, single.php) existe en la carpeta del tema hijo. Si está, lo usa y punto. Si no, entonces va a buscarlo al tema padre. Esto te da control, pero también significa que a veces el tema padre puede tener una plantilla más específica (como single-receta.php) que anule tu single.php genérico en el tema hijo.
Al final, entender esto es lo que separa el «dar palos de ciego» del «arreglarlo con criterio». No es magia negra, es un sistema predecible. La próxima vez que una página no se vea como esperas, pregúntate: ¿qué archivo estará buscando WordPress en su jerarquía, y cuál es el primero que realmente encuentra? Ahí suele estar el meollo del asunto.