Tema de bloques vs tema clásico en WordPress: la comparación honesta

Abre la carpeta de tu tema. Si contiene un directorio templates con un index.html dentro, más un theme.json en la raíz, tienes un tema de bloques. Si contiene index.php junto a archivos como header.php y footer.php, y tu barra lateral de administración muestra Apariencia y luego Personalizador, tienes un tema clásico.

Esa única diferencia estructural decide quién puede cambiar qué en tu sitio, dónde se guardan esos cambios y qué mitad del ecosistema de plugins de WordPress se comporta con normalidad.

La identificación en 30 segundos

Señal	Tema clásico	Tema de bloques
Archivo de plantilla raíz	index.php	templates/index.html
Cabecera y pie	header.php, footer.php	parts/header.html, parts/footer.html
Configuración global	functions.php	theme.json (más functions.php opcional)
Menú de administración	Apariencia > Personalizador	Apariencia > Editor
Dónde se guardan los cambios	Archivos en disco	Base de datos, como entradas wp_template
Pantalla de widgets	Presente	Ausente

WordPress lo decide buscando templates/index.html. Un tema que incluye un theme.json pero mantiene sus plantillas PHP se sigue tratando como clásico; ese estado intermedio es común y tiene nombre, lo vemos más abajo.

Si tienes acceso por consola, un comando lo zanja:

wp eval 'var_dump( wp_is_block_theme() );'

WP-CLI es la comprobación más rápida en un sitio que no construiste tú, sobre todo cuando un maquetador visual ha escondido los menús de administración habituales.

Qué cambia para quien edita el sitio

En un tema clásico, la cabecera, el pie, la barra lateral, los colores y el logo viven detrás del Personalizador, y solo tienes los controles que el autor del tema decidió construir. Si el tema no registró un control para el texto de copyright del pie, no hay control. Editas un archivo PHP o te aguantas.

En un tema de bloques, el editor del sitio expone la página entera. Cabecera, pie, el bucle, la página 404, el diseño de los resultados de búsqueda: todo son bloques y todo lo puede editar alguien que jamás ha visto PHP. Esa es la gran función de verdad, y es genuinamente grande.

El coste es que todo lo puede editar alguien que jamás ha visto PHP. Un cliente puede borrar el título del sitio de la cabecera a las 2 de la mañana y no hay historial de versiones en disco desde el que restaurar, solo las revisiones del propio editor del sitio. Se puede blindar con el bloqueo de bloques y restringiendo quién llega al editor, pero es trabajo opcional que tienes que acordarte de hacer.

Dos pérdidas menores que molestan en la práctica: los temas de bloques no tienen pantalla de widgets (las zonas de widgets se sustituyen por partes de plantilla y bloques), y los menús clásicos se sustituyen por el bloque Navegación, que guarda sus elementos como un tipo de contenido aparte en lugar de en la pantalla de Menús de siempre.

Qué cambia para el desarrollador

Los temas clásicos usan la jerarquía de plantillas PHP. WordPress resuelve una petición bajando por una cadena conocida (single-{post-type}.php, luego single.php, luego singular.php, luego index.php) y tu archivo se ejecuta, llama a get_header(), ejecuta el bucle e imprime marcado que controlas carácter a carácter.

<?php get_header(); ?>
<main class="site-main">
  <?php while ( have_posts() ) : the_post(); ?>
    <h1><?php the_title(); ?></h1>
    <?php the_content(); ?>
  <?php endwhile; ?>
</main>
<?php get_footer(); ?>

Los temas de bloques usan los mismos nombres de jerarquía con extensión .html, pero el archivo contiene marcado de bloques (HTML con delimitadores de bloque en comentarios) y no hay etiquetas de plantilla:

<!-- wp:template-part {"slug":"header","tagName":"header"} /-->

<!-- wp:group {"tagName":"main"} -->
<main class="wp-block-group">
  <!-- wp:post-title {"level":1} /-->
  <!-- wp:post-content /-->
</main>
<!-- /wp:group -->

<!-- wp:template-part {"slug":"footer","tagName":"footer"} /-->

Tres consecuencias con las que el desarrollador choca de inmediato:

get_header() y get_footer() no se ejecutan nunca. Cualquier cosa enganchada a esas acciones, en un plugin o en un tema hijo antiguo, deja de hacer nada en silencio. wp_head y wp_footer siguen disparándose, así que la mayoría del encolado sobrevive, pero los hooks específicos de la cabecera no.

La base de datos gana a tus archivos. En cuanto alguien guarda una plantilla en el editor del sitio, WordPress almacena esa versión como una entrada wp_template y la sirve en lugar de tu archivo. Puedes editar el archivo HTML toda la tarde y ver cero cambios en la parte pública. Borrar la personalización de esa plantilla devuelve la versión del archivo. Este es el aviso de “mi tema de bloques está roto” más común de todos, y no es un fallo.

Los estilos se mudan a theme.json. Colores, escala de espaciado, tipografía y valores por defecto por bloque se declaran como datos en lugar de CSS, y WordPress genera el CSS. Es más limpio y mucho más consistente, hasta que necesitas algo que el esquema no expresa, momento en el que acabas escribiendo CSS igualmente y peleando por especificidad contra las reglas generadas.

{
  "version": 3,
  "settings": {
    "color": {
      "palette": [
        { "slug": "brand", "color": "#1a1a1a", "name": "Brand" }
      ]
    }
  }
}

Comprueba el valor de version contra la versión de WordPress en la que estás: el esquema se ha revisado más de una vez y copiar un número de versión de un tutorial antiguo produce settings que se ignoran sin avisar.

Ten en cuenta que functions.php no desaparece. Los temas de bloques lo siguen usando para encolar, registrar entradas de add_image_size, tipos de contenido personalizados y cualquier otra cosa en PHP. Simplemente haces mucho menos trabajo de plantillas ahí.

Qué ganas de verdad y qué pierdes de verdad

Pasarte a bloques te da: control desde el editor sobre la página entera, consistencia de diseño impuesta por theme.json, menos archivos que mantener y estilos que coinciden entre el editor y la parte pública mucho más a menudo de lo que los temas clásicos consiguieron nunca.

Pasarte a bloques te quita: control directo del marcado de salida, la personalización sencilla basada en hooks, la compatibilidad con todo lo que dé por hecho que hay plantillas PHP y la tranquilidad de que la apariencia del sitio vive en el control de versiones.

Esto último merece énfasis. En un tema clásico, git log te dice qué cambió. En un tema de bloques, una parte relevante de la apariencia del sitio vive en la base de datos, donde tu pipeline de despliegue no mira.

Cuándo un tema clásico sigue siendo la respuesta correcta

• Un maquetador visual lleva el sitio. Elementor, Divi, Beaver Builder y herramientas parecidas se encargan ellas mismas de las plantillas. Poner un tema de bloques debajo añade un segundo sistema de plantillas que no hace nada.
• El marcado tiene que ser exacto. Bibliotecas de componentes a medida, marcado de accesibilidad estricto, requisitos de esquema poco habituales: la salida de los bloques está limitada por lo que los bloques emiten, y pelearse con eso cuesta más que escribir PHP.
• Plugins con muchas plantillas. Los plugins de membresías, LMS, directorios y las extensiones de comercio más antiguas suelen incluir sobrescrituras de plantillas PHP. Muchos ya tienen equivalentes en bloques; muchos otros no.
• El sitio está terminado y funciona. Un tema con cinco años de personalizaciones acumuladas no tiene ruta de actualización a bloques, solo una reconstrucción. “Es el enfoque más nuevo” no es una razón de negocio.
• Nadie más que tú lo va a editar. El beneficio principal del editor del sitio es ceder el control a quien no programa. Si no hay nadie que no programe, estás pagando los costes de un beneficio que nadie usa.

El término medio híbrido

Un tema clásico puede añadir un theme.json y quedarse con el sistema de estilos globales, los presets de color y espaciado y un estilado consistente en el editor, manteniendo a la vez sus plantillas PHP y el Personalizador. WordPress no lo llama tema de bloques y el editor del sitio sigue sin estar disponible, pero obtienes casi todo el beneficio de sistema de diseño por una fracción del trabajo.

Para un sitio existente que en general funciona, este suele ser el primer movimiento correcto. Añade theme.json, define tu paleta y tu espaciado, borra el CSS al que sustituye y comprueba si todavía quieres lo demás.