El Editor de Sitios a prueba de clientes: Un manual de theme.json

Resumen

Cuando un cliente abre el Editor de Sitios de WordPress por primera vez, la capacidad de editar cada bloque, color y diseño puede parecerle una funcionalidad — y a ti una amenaza. Este artículo explica cómo usar theme.json para trazar una línea clara entre la edición de contenido y el control del diseño. En lugar de luchar contra el Editor de Sitios, configuras presets, valores predeterminados y límites que hacen seguro para clientes no técnicos actualizar su propio sitio. Veremos qué bloquear, qué dejar abierto y por qué el exceso de bloqueo es un riesgo real. El enfoque se basa en tokens de diseño y restricciones a nivel de plantilla, por lo que funciona de manera consistente en todos los sitios de clientes que mantienes. Al final, tendrás un flujo de trabajo repetible para entregar el Editor de Sitios sin entregar las llaves de tu sistema de diseño.

¿Qué es lo primero que haces cuando un cliente envía un correo para decir que "solo intentó actualizar el titular" y todo el espaciado del sitio se ha colapsado?

Si mantienes más de un sitio de WordPress, probablemente has recibido ese mensaje de alguna forma. El Editor de Sitios le dio a tu cliente las llaves de un auto con cinco cambios de marcha y sin freno. Piensan que están haciendo un simple cambio de texto, y de repente la tipografía global está desajustada, el héroe de la página de inicio tiene un color neón que no elegiste, y dos bloques ahora están apilados en lugar de uno al lado del otro.

Mientras tanto, piensas en los otros seis sitios de clientes que soportas, y lo último que necesitas es una trampa de mantenimiento donde cada edición "útil" del cliente requiera una restauración desde una copia de seguridad.

La respuesta no es quitar el Editor de Sitios. Es establecer límites dentro de él usando theme.json. Según los Recursos para desarrolladores de WordPress, theme.json es la fuente central de verdad para la configuración y estilos del editor de bloques: define las paletas de colores, la tipografía y las opciones de diseño que se muestran al cliente. Eso significa que el mismo archivo que controla tu diseño también puede controlar lo que tu cliente puede y no puede editar.

Repasemos cómo pensar en esto, porque la mayoría de los tutoriales se centran en lo que theme.json puede hacer por los desarrolladores. La pregunta para una agencia es diferente: ¿cómo lo usamos para que los clientes estén seguros sin sentirse encerrados?

¿Por qué el Editor de Sitios parece tan peligroso?

Tu cliente no está tratando de romper el sitio. Está tratando de hacer lo que le has estado enseñando a hacer durante años en el editor antiguo: cambiar un titular, intercambiar una imagen, tal vez agregar un párrafo. El peligro no es su intención — es que el Editor de Sitios muestra controles globales en el mismo lugar que los controles de contenido.

Aquí hay un escenario común. Un cliente abre una plantilla en el Editor de Sitios y ve un bloque de encabezado. Cambia su color para que coincida con la nueva muestra de marca. Pero debido a que ese encabezado está en una plantilla, el cambio se aplica en todos los lugares donde se usa esa plantilla. Para el cliente, parecía una sola edición. Para el sitio, fue un cambio global.

El principio general: cuando le das a alguien un constructor de páginas, eventualmente encontrará la "configuración con barreras de protección" y las apagará. Pero con theme.json, puedes ocultar las propias barreras. En lugar de decirle al cliente "no toques los estilos globales", simplemente no le muestras una paleta de colores que pueda producir un mal resultado. Defines una paleta de colores aprobados, una escala de tamaños de fuente y un conjunto de presets de espaciado — y el cliente elige de esos, no de todo el espectro de CSS.

Ese es el primer cambio: deja de pensar en reglas y empieza a pensar en fábricas. theme.json es tu línea de producción. Configuras las opciones que el cliente ve, y las restricciones son aplicadas por la propia interfaz, no por un conjunto de instrucciones en un documento de entrega.

¿Qué deberías bloquear realmente?

No todo. Si bloqueas el área de contenido demasiado estrictamente, el cliente o te llamará cada vez que necesite agregar un párrafo, o encontrará una forma de evitarte — a menudo añadiendo un plugin de una sola vez o copiando HTML de su sitio anterior.

Aquí hay una tabla práctica de qué bloquear, qué dejar y por qué:

Superficie de edición	¿Bloquear?	Por qué
Estructura de plantilla y diseños de bloques	Bloquear	Evita la eliminación o reordenación accidental de bloques de diseño centrales
Estilos globales (colores, fuentes, presets de espaciado)	Bloquear con presets	Los clientes eligen de un conjunto aprobado, no valores arbitrarios
Texto e imágenes de contenido	Dejar abierto	Este es su trabajo; deja que lo hagan sin pedir permiso
Espaciado entre bloques	Bloquear parcialmente	Proporciona presets de espaciado para que puedan ajustar el ritmo sin romper la alineación
Patrones de bloques curados	Dejar abierto si los has revisado	Una forma segura para que los clientes agreguen nuevas secciones sin construir desde cero

El matiz importante es "bloquear con presets", no "bloquear fuera". Para los estilos globales, no estás ocultando el panel de configuración; estás reduciendo el número de opciones a un conjunto curado. Para la estructura de plantillas, puedes bloquear ciertos bloques para que no puedan eliminarse, pero aún permitir que los clientes editen el texto dentro de ellos.

Una palabra de precaución: bloquear un bloque en una plantilla es diferente de bloquearlo en una página específica. Los bloqueos de plantilla afectan a todo el contenido que usa la plantilla. Si necesitas diferentes niveles de bloqueo en diferentes páginas, tendrás que trabajar a nivel de bloque dentro del editor, lo cual es más frágil. Para el trabajo repetible de agencia, diseña tus plantillas para que las áreas bloqueadas sean consistentes.

¿Cómo estableces límites sin que el editor se sienta como una trampa?

La técnica es definir tus tokens de diseño en theme.json y luego resistir la tentación de hacer cualquier otra cosa en CSS.

Por ejemplo, en lugar de permitir que el cliente establezca un color arbitrario en un botón, defines un estilo de botón en theme.json que usa un color específico de tu paleta. El cliente aún puede seleccionar el botón y cambiar su texto, pero el selector de color solo muestra tus muestras aprobadas. Es lo mismo para tamaños de fuente, alturas de línea y espaciado.

El mismo principio se aplica a las plantillas. Puedes usar la función de "bloqueo" en bloques específicos dentro de una plantilla — por ejemplo, bloquear la estructura de columnas de un bloque de testimonio para que un cliente pueda cambiar el texto de la cita pero no convertir tres columnas en dos. Si aún no has usado el bloqueo de bloques, está disponible en la barra de herramientas del editor; cuando bloqueas un bloque, puedes elegir si el cliente puede editar el contenido, moverlo o ambos. Incluso puedes aplicar esto en theme.json para valores predeterminados a nivel de bloque.

Lo que buscas es un editor donde el cliente nunca vea un control que pueda romper el diseño. Eso no significa que no puedan hacer nada mal; significa que lo peor que pueden hacer es cambiar la redacción de un titular, no el aspecto de todo el sitio.

Si estás usando tipos de contenido personalizados, los mismos principios se aplican más allá de las plantillas predeterminadas — consulta nuestra guía sobre extender theme.json a tipos de contenido personalizados y salida de plugins.

¿Qué sucede cuando bloqueas demasiado?

Aquí está el punto controvertido: el exceso de bloqueo es tan dañino como la falta de bloqueo. Un cliente que no puede redimensionar un encabezado o agregar un espacio entre secciones eventualmente te pedirá que "solo lo hagas ver bien" — y entonces vuelves a hacer pequeños cambios gratis. Peor aún, podrían decidir que el Editor de Sitios es inútil y volver a un constructor de páginas de terceros, lo que les da demasiado control nuevamente.

La compensación es real. Los editores bloqueados producen menos llamadas de emergencia, pero también producen más solicitudes de "¿puedes mover este botón cinco píxeles hacia arriba?". Los editores abiertos producen lo contrario. Tu trabajo es encontrar el punto de equilibrio para cada cliente, no aplicar una configuración universalmente.

Una buena heurística inicial: bloquea todo lo que afecta a todas las instancias de algo (estilos globales, estructura de plantilla) y deja abierto todo lo que afecta a una instancia (el texto e imágenes de una sola página). Si un cliente rompe una sola página, es un arreglo de 5 minutos. Si rompe un estilo global, es un arreglo de 20 minutos y una preocupación de seguridad.

¿Cómo haces que esto sea repetible entre clientes?

Aquí es donde entra el flujo de trabajo de la agencia. Deberías tener un theme.json base que defina tus tokens de diseño — la paleta de colores, la escala tipográfica y los presets de espaciado — y luego un archivo de anulación por cliente que extienda o cambie valores específicos.

Empieza creando un tema de bloques "inicial". Aquí te mostramos cómo construir un tema de bloques personalizado con theme.json — una vez que lo has desarrollado y documentado, copiarlo a un nuevo cliente es cuestión de intercambiar colores de marca y fuentes. No estás reinventando la rueda; estás intercambiando tokens. Esta es exactamente la mentalidad de deja de reconstruir cada sitio de WordPress, pero aplicada al editor en lugar del backend.

Debido a que theme.json es un solo archivo, también es fácil de controlar versiones y desplegar en múltiples entornos. Puedes revisar cambios, ver qué ha modificado un cliente en los estilos globales y comparar esos cambios con tu archivo base. Eso te da un sólido rastro de auditoría para las solicitudes de soporte.

Si mantienes múltiples sitios y aún no has configurado un tema base, esta es tu oportunidad. Es la pieza de trabajo personalizado de WordPress que se paga a sí misma cada vez que un cliente abre el editor.

¿Qué pasa con los clientes que siguen pidiendo "un color más"?

Tu paleta es una promesa. Si defines cinco colores de marca y un cliente pide un sexto, la respuesta no es "no" — es "sí, pero llega como una adición deliberada a la paleta, no como un código hex único en un encabezado". Cuando agregas un color a theme.json, está disponible en todo el sitio de manera consistente. Esa es la forma correcta de manejar esas solicitudes.

Aquí es también donde necesitas comunicarte con el cliente. Explícale que el Editor de Sitios solo le muestra los colores y fuentes que coinciden con sus estándares de marca. Si quieren expandir esos estándares, lo manejarás en el sistema de diseño, y entonces cada nuevo color estará disponible en todas partes — incluidas las páginas futuras que aún no han construido. Esa es una respuesta mucho mejor que "no hacemos eso".

Al mismo tiempo, no acumules una paleta de cuarenta colores. Revísala trimestralmente y elimina cualquier cosa que haya sido un accidente de una sola vez. El objetivo es un conjunto de opciones pequeño e intencional.

Si bloqueas el diseño pero dejas el contenido, y haces de la paleta una parte viva de tu relación con el cliente, el Editor de Sitios deja de ser una amenaza. Se convierte en una forma de dar a tus clientes autonomía real sin sacrificar los estándares de diseño que te pagan por proteger.