¿Sage o un tema a medida? ¿Cuál usan?

Los dos, y lo decide la plataforma de hosting. WordPress VIP limita lo que un tema puede hacer en runtime, así que ahí construimos un tema PHP clásico con la lógica repartida entre inc, template-parts y clases en lugar de acumularse en functions.php. En Kinsta, Ymir o un DigitalOcean provisionado con Trellis usamos el stack Roots: WordPress versionado con Composer, Acorn, plantillas Blade y Vite con Tailwind para los assets. Este sitio corre esa segunda configuración. La decisión se toma en la primera semana, porque no es reversible sin reescribir las plantillas.

¿Por qué bloquean la paleta de colores y los tamaños de fuente en el editor?

Porque un selector de color abierto es un sistema de marca sin nadie que lo haga cumplir. Cada valor hexadecimal tipeado a mano es un valor que nadie aprobó, y que después nadie puede cambiar sin encontrarlo primero. Los design tokens se definen una sola vez en CSS y se compilan hacia el editor en tiempo de build. A partir de ahí: La paleta por defecto de WordPress, los gradientes, los duotonos y los tamaños de fuente por defecto quedan desactivados. Los campos de color, gradiente, duotono y tamaño de fuente personalizados quedan desactivados junto con ellos. Lo que queda en este sitio son 96 colores aprobados y 13 tamaños tipográficos. Los editores conservan opciones reales. Lo que pierden es la posibilidad de inventar un valor.

¿En qué se diferencia esto de su sistema de bloques?

El desarrollo del tema es el terreno sobre el que se apoya el sistema de bloques. Fija la plataforma de hosting, el pipeline de build, la capa de tokens y las fronteras entre paquetes. El sistema de bloques es la parte que los editores tocan de verdad. Los dos están hechos para encajar. Cada uno de los 48 tipos de bloque tiene exactamente una clase handler de PHP y una plantilla Blade, ambas dentro de la estructura que define el desarrollo del tema. Si después cambiás la base, todos los bloques se mueven con ella. El lado editorial está cubierto en la página del Sistema de Bloques Atómicos de 40Q.

¿Podemos quedarnos con el tema que ya tenemos?

A veces. Miramos tres cosas: si el build se puede reproducir desde un lockfile, si presentación y lógica están separadas, y si el editor tiene límites o es un lienzo abierto. Si un tema falla en las tres, volverlo mantenible suele costar más que una base limpia y encima hereda las restricciones originales. Si falla en una, arreglamos esa. Te decimos en qué caso estás antes de que te comprometas. La organización de assets y la estrategia de carga son parte de la misma decisión, y por eso esto corre en paralelo al trabajo de rendimiento y no después.

¿Qué necesitan de nosotros antes de empezar?

Cinco cosas, y la primera bloquea al resto: La plataforma de hosting, confirmada. VIP, Kinsta, Ymir y DigitalOcean llevan a builds distintos. Un repositorio donde podamos trabajar, con su CI si ya lo usan. Acuerdo del equipo de ingeniería sobre el toolchain, porque ellos lo van a mantener. Tokens de marca o un manual de diseño, si querés que la capa visual quede conectada desde el arranque. Un responsable técnico con nombre que pueda aprobar decisiones de arquitectura. Nada de esto exige un diseño terminado. El desarrollo del tema está deliberadamente desacoplado del resultado visual, así que puede arrancar antes de que el diseño esté aprobado.

¿Qué recibimos en la entrega?

El tema estructurado según las convenciones de arriba, con cada dependencia declarada y fijada. Un build que corre con un solo comando y produce la misma salida en cualquier máquina. La configuración del editor ya limitada a tus tokens. Un README con las convenciones de nombres para vistas, bloques y funciones. El estándar que nos exigimos: un desarrollador que nunca vio el proyecto puede clonarlo, buildearlo y encontrar dónde va un cambio sin preguntarle a nadie.

Desarrollo de temas

Arquitectura de temas WordPress Enterprise que sigue en pie al tercer año

Plataforma de hosting, pipeline de build, límites para el editor, fronteras entre paquetes, entorno local. Cinco decisiones que se toman en la primera semana, ninguna visible en el lanzamiento, todas definiendo todavía el costo de cada cambio tres años después.

Inicio
Capacidades
Desarrollo de temas

Decisiones de base

Cinco decisiones baratas hoy y caras después

Desarrollar un tema no es instalar un tema. Es el conjunto de definiciones estructurales que determina si la plataforma sigue siendo mantenible años después del lanzamiento.

La plataforma de hosting define el tema

WordPress VIP no permite el mismo build que Kinsta, Ymir o un DigitalOcean provisionado con Trellis. En VIP entregamos un tema PHP clásico con la lógica repartida entre inc, template-parts y clases. En el resto usamos el stack Roots: WordPress versionado con Composer, Acorn, Blade. Si la decisión llega tarde, las plantillas se escriben dos veces.

Un pipeline de build que todavía corre en tres años

Cada dependencia queda declarada y fijada, así el build se reproduce en lugar de reconstruirse de memoria. Este sitio corre Vite y Tailwind CSS v4, PHP con piso en 8.3 y el core de WordPress administrado como paquete de Composer. Actualizar pasa a ser un diff revisable, no una operación que nadie quiere firmar.

Límites editoriales compilados en theme.json

Los design tokens se definen una sola vez en CSS y se compilan hacia el editor de WordPress en tiempo de build. En este sitio eso da 96 colores aprobados y 13 tamaños tipográficos, con la paleta por defecto de WordPress, los gradientes por defecto, los tamaños de fuente por defecto y cualquier override de texto libre desactivados.

Fronteras entre paquetes en lugar de un functions.php que crece

Todo lo que no es presentación vive en su propio paquete de Composer, desarrollado dentro del repositorio con path repositories y enlazado por symlink a vendor. Este código base tiene seis, desde el hub de IA hasta el asistente de SEO y las abilities de MCP. Cada uno se versiona, se testea y se remueve sin tocar una plantilla.

Un entorno local que replica staging

El entorno local se arma contra la plataforma de hosting y no contra lo que cada desarrollador ya tenía instalado: Docker, Herd o Trellis, según dónde vaya a correr el sitio de verdad. La regla es que lo que funciona en local funciona igual en staging. Un entorno que no puede prometer eso convierte cada deploy en una prueba.

Implementación de referencia

La implementación de referencia es este sitio

No son resultados de clientes. Describen el código base detrás de 40q.agency a agosto de 2026 y van a cambiar a medida que cambie. Una afirmación sobre los cimientos que no se puede inspeccionar vale muy poco.

48

Tipos de bloque, cada uno con exactamente una clase handler de PHP y una plantilla Blade. Uno a uno, sin excepciones

96 y 13

Colores aprobados y tamaños tipográficos generados hacia el editor desde el archivo de tokens, con los valores por defecto de WordPress y los overrides de texto libre desactivados

13 y 5

Opciones de fondo de sección y pasos de padding vertical disponibles para editores. El layout es un menú, no un campo de CSS

Qué te deja

Cuánto vale la base una vez que dejás de mirarla

El objetivo de este trabajo no es la elegancia. Es lo que sigue siendo barato después del lanzamiento, cuando ya nadie mira la arquitectura.

Onboarding que se mide en días

Las convenciones están escritas y además la estructura las hace cumplir. Nombres de bloques, ubicación de plantillas y forma de los atributos siguen un solo patrón, así un desarrollador nuevo aprende una convención y la aplica 48 veces en lugar de aprender 48 excepciones.

Cambios de diseño que no tocan el código

Colores, escala tipográfica y espaciados viven en un único archivo de tokens que compila tanto hacia el frontend como hacia el editor. Un rebrand pasa a ser una edición de tokens en vez de una cacería de valores hexadecimales hardcodeados en las plantillas.

Actualizaciones que se pueden revisar de verdad

Core, plugins y paquetes internos se declaran en composer.json y quedan fijados por un lockfile. Cada actualización llega como un diff que alguien puede leer y un build que alguien puede correr, y eso mantiene la plataforma parcheable mucho después del lanzamiento.

Lo que nos preguntan los líderes de ingeniería antes de empezar un build

Las preguntas que definen si vale la pena pagar por una base bien hecha.

Contenido relacionado

Seguí leyendo sobre arquitectura y mantenibilidad

Decisiones de base, temas a medida y el costo de saltearse la mantenibilidad.

A man in a blue checkered shirt stands at a desk in a modern office, working on a computer. Papers, a coffee mug, and a snack bar are on the desk, with large windows showing a cityscape in the background.

Jun 1, 2026

WordPress

Guía de Configuración de WordPress Escalable para Empresas

Three people sit around a table in a modern office with large windows. They are discussing a laptop displaying charts, with notes and diagrams on a whiteboard behind them. City buildings are visible outside.

May 2, 2026

WordPress

Mantenibilidad de sitios web para empresas explicada

May 6, 2024

WordPress

Los Mejores Temas de WordPress (y Por Qué Necesitás Uno a Medida)

Da el siguiente paso

Que un ingeniero revise la arquitectura de tu tema

Mandanos el repositorio o una URL de staging. Vamos a mirar cómo está estructurado el tema, si el build es reproducible y por dónde el editor puede salirse de la marca, y después te enviamos lo que encontramos.

Pedir una revisión de arquitectura Hablá con un ingeniero de WordPress