Deja de reconstruir cada sitio de WordPress

Resumen

La mayoría de las agencias construyen cada sitio de WordPress desde un tema en blanco, incluso cuando una base compartida recortaría semanas del cronograma. Este artículo argumenta que theme.json, los patrones de bloques y los bloques dinámicos te permiten estandarizar la capa estructural mientras preservas el diseño distintivo de cada cliente. Aborda directamente las cinco objeciones que impiden que los equipos cambien: «tenemos clientes diferentes», «los bloques personalizados son caros», «el editor es confuso», «perderemos nuestros hooks y filtros» y «FSE no está listo para producción». Cada objeción recibe un contraargumento práctico y un patrón concreto que puedes adoptar de forma incremental. La recompensa es un proceso de construcción repetible que aún honra el trabajo a medida donde corresponde. Advertencia: no se prometen botones de reinicio con un clic.

¿Cuántos de los sitios de tus clientes comparten siquiera una línea de código? No la línea de copyright—código real. Si la respuesta es «apenas algunos», ya has sentido el dolor: la misma sección hero reconstruida por novena vez, el mismo marcado de cuadrícula de equipo copiado de un proyecto a otro, los mismos ajustes de preprocesado cruzando referencias en media docena de temas. También has escuchado la defensa: «Cada cliente tiene necesidades diferentes». Cierto. Sin embargo, la conclusión que todos sacan—que cada sitio necesita una base a medida—es falsa. El ecosistema de WordPress ahora te ofrece una manera de estandarizar las piezas estructurales sin estandarizar el diseño: theme.json para tokens de diseño, patrones de bloques para layout repetido, y bloques dinámicos para las pocas características que necesitan lógica real del lado del servidor. Este artículo trata sobre las objeciones que impiden que las agencias den ese paso, y lo que realmente funciona cuando las enfrentas.

La objeción «pero cada cliente es diferente»

El principio subyacente: estandariza la base, no la superficie. La razón para mantener la estructura en una biblioteca compartida es precisamente dejar libre la capa visual. Un archivo theme.json no es un diseño—es un conjunto de tokens de diseño. Los colores, el espaciado y la tipografía son valores, no marcado. Ese es el cambio crítico: puedes compartir el marcado mientras un theme.json por sitio hace que el sitio se vea completamente diferente para una marca distinta.

Toma dos clientes: un bufete de abogados y un minorista al aire libre. Sus lenguajes de diseño están a años luz. Pero ambos necesitan una sección hero, una cuadrícula de testimonios, una banda de llamada a la acción. En lugar de reconstruir el marcado para cada uno, mantén tres patrones de bloques y deja que el theme.json de cada cliente defina colores, fuentes y espaciado. La estructura permanece idéntica; los tokens de diseño la transforman de una marca a la otra. Cuando el minorista cambie su paleta de colores la próxima primavera, editas un archivo en su sitio—no el marcado en seis plantillas.

En la práctica, esto significa que tu equipo crea patrones como código, los registra en un plugin compartido y deja que el theme.json de cada sitio de cliente maneje la pintura. Los nombres de clase del patrón se convierten en tu arquitectura; los valores, en las variables. Incluso puedes ir más allá y extender theme.json para incluir configuraciones personalizadas para tipos de contenido o salida de plugins, aunque en algún momento estás construyendo una interfaz de configuración en lugar de un sitio—una trampa que discutimos en nuestra mirada a la extensión de theme.json. Mantén la capa compartida ligera: debe contener solo lo que se repite entre clientes. En el momento en que te encuentras agregando una opción «por si alguien algún día la quiere», has creado una abstracción que costará más de mantener de lo que ahorra.

Cuando configuras un nuevo cliente, los primeros treinta minutos deberían ser: clonar el plugin de patrones compartidos, crear un nuevo theme.json con la paleta y escala tipográfica del cliente, y registrar su logotipo y pie de página. Eso no es una construcción personalizada; es una tarea de configuración. El trabajo restante específico del cliente va en el contenido, la estructura y cualquier característica genuinamente a medida. Esta es la diferencia entre construir cada casa desde cero y tener un conjunto de planos prefabricados que puedes volver a pintar y empapelar. La analogía es flexible, pero el principio se sostiene: cuanto más empujas hacia los valores de theme.json, menos tienes que tocar el marcado.

Una de las victorias más simples es observar cómo funcionan realmente los patrones de bloques. Un patrón es solo una colección de bloques con contenido y estilos predefinidos. Puedes guardar cualquier configuración de bloques como un patrón, y luego un cliente puede insertarlo sin necesidad de saber cómo está construido. Eso significa que el patrón se convierte en un «punto de entrada» para usuarios no técnicos. Cuando tu equipo mantiene el patrón subyacente en código, el cliente obtiene una biblioteca consistente sin tocar una sola etiqueta de PHP.

Ahora, la advertencia a la que siempre vuelvo: no sobrecentralices. Un theme.json con una opción para cada matiz concebible es un pantano de mantenimiento. Los patrones compartidos deben ser decididos, no omnipotentes. Si un cliente necesita un layout radicalmente diferente—digamos, una portada de revista con una gran cuadrícula destacada—podría no encajar en tu biblioteca de patrones estándar. Eso está bien. La estandarización significa que ganas en el 80% de los proyectos que son similares, no que fuerzas cada sitio en el mismo molde.

La objeción «los bloques personalizados revientan el presupuesto»

Aquí hay un contraprincipio que suena aburrido pero ahorra dinero: la mayoría de las cosas que crees que necesitan un bloque personalizado no lo necesitan. Los bloques básicos más un patrón pueden cubrir la gran mayoría de los diseños. El bloque personalizado es el último recurso, no la primera intención.

El ejemplo clásico es la cuadrícula de equipo. Si es algo puntual, usa los bloques «columnas» y «grupo» y deja que el cliente agregue un avatar manualmente. Si tres clientes piden la misma cuadrícula con la misma estructura de «enlaces sociales debajo del nombre», ahora tienes un candidato para un patrón de bloques. Cuando ese patrón comienza a acumular nuevas opciones—efectos hover, ordenamiento, estrellas de calificación—el patrón se convierte en un cajón de sastre inmanejable, y entonces es momento de escribir un bloque personalizado. El error que daña el presupuesto es saltar directamente al bloque personalizado en la primera solicitud.

Un escenario más insidioso: el cliente pide un «carrusel de casos de estudio». El primer instinto es pensar: «Necesito un bloque de carrusel». Pero, ¿necesitan un carrusel? Quizás necesiten un grupo de publicaciones desplazables horizontalmente, que los bloques básicos pueden manejar con un bloque «grupo» y algo de CSS. O quizás necesiten una lista dinámica de casos de estudio recientes, que es un bloque dinámico que consulta el CPT. La pregunta no es «¿qué característica quiere el cliente?» sino «¿de qué datos depende?». Si los datos son estáticos y editables por el cliente, un patrón será suficiente. Si los datos provienen de una consulta a la base de datos, un bloque dinámico está justificado. Si los datos necesitan actualizarse en tiempo real desde una API, podrías estar mirando una integración de API REST—eso cruza hacia un tipo diferente de construcción.

Cuando construyas un bloque, block.json es tu amigo. Es la única fuente de verdad para atributos, scripts y estilos, lo que hace que el bloque sea portátil entre proyectos. También te permite declarar dependencias y traducciones limpiamente, lo cual es esencial cuando distribuyes una biblioteca a muchos sitios de clientes. Para contenido que depende de datos en vivo, un bloque dinámico se renderiza en el servidor, por lo que no necesitas enviar un bundle de JavaScript en cada vista de página. Y si tu bloque evoluciona, puedes manejar desaprobaciones con elegancia para que el contenido existente no se rompa—nuestra guía sobre la desaprobación de bloques recorre el patrón exacto.

Antes de construir cualquier cosa, pasa la decisión por esta tabla:

Enfoque	Mejor para	Evítalo cuando
Bloque básico	Contenido puntual, páginas simples	El layout se repite en muchos clientes y necesita opciones ricas
Patrón de bloques	Layouts repetibles sin lógica	El layout necesita condicionales, datos dinámicos o interacciones complejas
Bloque personalizado	Comportamiento repetido, basado en datos o muy específico	La única razón es una sección puntual que puede manejarse con una clase

También querrás pensar en la nomenclatura de bloques desde el primer día. Un nombre de bloque es esencialmente un contrato con tu contenido. Si lo llamas wagent/team-grid y luego lo renombras a wagent/team-carousel, romperás el contenido existente a menos que proporciones una ruta de desaprobación. Elige nombres genéricos basados en el propósito que no se conviertan en publicidad engañosa a medida que el bloque evoluciona. Esto es una parte de la disciplina de nomenclatura que todos hemos aprendido de los prefijos de plugins, y se aplica igualmente a los nombres de bloques.

La opinión contraria aquí es lo más útil que puedo decir: el bloque personalizado que construyes porque un cliente pidió «solo una pieza» casi siempre es un error. Di que no cortésmente, entrega un bloque básico con una clase y ahorra horas. Ganarás más respeto del cliente—y una línea más pequeña en el presupuesto de mantenimiento.

La objeción «los clientes romperán el editor»

Esta objeción tiene media razón. El editor de bloques en sí no es el problema; el problema es dar demasiada cuerda a los clientes. theme.json puede restringir lo que es editable: deshabilitar el editor de plantillas, limitar los bloques permitidos y establecer estilos predeterminados para que una columna mal colocada cause menos daño. Algunos clientes aún lograrán romper cosas, pero puedes restaurar una página a un patrón guardado con un clic—algo que el editor clásico no podía ofrecer.

Permíteme pintar un escenario. Un cliente llama y dice: «Moví una sección y ahora toda la página se ve mal». Con un tema clásico, tendrías que iniciar sesión, inspeccionar el CSS y probablemente pasar una hora arreglando el layout. Con una configuración de bloques, puedes abrir la página, seleccionar el área de contenido y restablecerla al patrón guardado. El patrón es la línea base; los cambios del cliente son la superposición. Cuando la superposición sale mal, la eliminas. Eso no es solo un flujo de trabajo más bonito; es un editor fundamentalmente más indulgente.

Ahora el matiz: la mayoría de los clientes no quieren editar mucho. Quieren cambiar texto, intercambiar fotos y quizás reordenar una sección. El patrón de bloques te da exactamente eso sin exponer toda la estructura del sitio. En este sentido, el editor no es un juguete; es un visor. Tu trabajo es calibrar lo que los clientes pueden ver. Eso significa que podrías deshabilitar la configuración de «Plantillas», limitar el insertador de bloques a una lista curada e incluso precargar patrones vacíos con trabajo de marcador de posición. El editor se convierte en un formulario de entrada de contenido en lugar de un lienzo de diseño web.

En el lado de la accesibilidad, la gestión del enfoque y el soporte de teclado del editor de bloques son generalmente mejores que los campos de plantilla de un editor clásico. Pero aún necesitas asegurarte de que los patrones tengan una jerarquía de encabezados adecuada y nombres accesibles. Dado que el patrón se comparte entre clientes, solo arreglas esos problemas una vez, lo cual es otra victoria oculta de la estandarización.

La parte realmente difícil es interna. Para tu equipo, aprender a prototipar con bloques requiere desaprender el hábito de «hacerlo en PHP». Ese es un costo real, pero es un costo único por persona. No es una razón para evitar el enfoque; es una razón para comenzar con una biblioteca de patrones y un cliente indulgente antes de implementarlo en todas partes. No dejes que el estribillo de «mis clientes no pueden manejar bloques» oculte el hecho de que aún no has configurado una instalación de bloques para encontrarlos a mitad de camino.

La objeción «ya tenemos hooks y filtros»

El principio aquí es: no estás descartando los hooks; estás agregando una capa encima. Los bloques son el límite de presentación; los hooks siguen siendo cómo inyectas lógica. El callback de render de un bloque dinámico se ejecuta en PHP, lo que significa que puedes llamar a las mismas funciones y aplicar los mismos filtros que ya conoces.

Imagina un plugin que te permite agregar un campo de «producto destacado» a cualquier publicación usando un filtro. Con un bloque dinámico, puedes incluir un bloque renderizado en el servidor que ejecute ese filtro e imprima la salida dentro del contenedor del bloque. El cliente inserta el bloque; la lógica PHP existente hace el trabajo pesado. Nada se tira. Para un ejemplo aún más concreto, considera un bloque personalizado que lista publicaciones recientes de proyectos. En su callback de render, llamas a get_posts(), luego recorres y aplicas the_title() y the_permalink()—las mismas etiquetas de plantilla que has usado durante años.

Este también es el lugar para ser honesto sobre lo que no se traduce. Algunos temas antiguos ingeniosos usan template-parts con condicionales intrincados que toman argumentos basados en el contexto de la página. Recrear eso como un bloque puede ser desordenado. Pero no tienes que recrearlo todo de una vez. El camino incremental es mantener la lógica PHP, envolverla en un bloque dinámico y mover el marcado a la plantilla del bloque. A menudo descubrirás que tus patrones de filtros existentes pueden manejar la nueva salida. Y si la lógica está estrechamente acoplada a una jerarquía de plantillas (por ejemplo, «en los resultados de búsqueda, muestra esto de manera diferente»), aún puedes usar la plantilla clásica para esas vistas específicas mientras usas bloques para las páginas regulares.

La API REST también abre una puerta diferente: puedes construir bloques que obtengan datos de otros sitios de WordPress o servicios de terceros. Un bloque dinámico puede llamar a wp_remote_get() para obtener JSON y renderizarlo en el front end. Ese es un patrón poderoso para construcciones de agencias donde los clientes quieren mostrar feeds sociales, listados de productos o datos internos sin gestionar una integración separada. La compensación es el almacenamiento en caché y el manejo de errores—si la API remota es lenta, tu página es lenta. Mantén los bloques basados en API fuera del contenido crítico visible sin desplazamiento, o usa renderizado del lado del cliente con un estado de carga adecuado.

Las acciones y los filtros siguen ejecutándose alrededor del guardado y la renderización; la arquitectura de hooks no desaparece cuando adoptas bloques, simplemente se mueve a un nuevo contexto. Si necesitas refrescar tu comprensión de dónde se encuentran las acciones y los filtros con este nuevo mundo de bloques, nuestro análisis profundo de hooks es un repaso útil.

La objeción «FSE no está listo para producción»

Justo, pero pregúntate qué significa realmente «riesgoso». La edición completa del sitio ha pasado por varias versiones, y theme.json se ha asentado en un esquema estable. El riesgo no es que el editor «se rompa de repente»—el riesgo es que el código personalizado de tu equipo pueda depender de plantillas PHP de estilo antiguo que conviven torpemente con las plantillas de bloques. Además, algunos plugins de terceros aún asumen el editor clásico o el personalizador. Esa es una decisión de compatibilidad, no una razón para desechar todo el modelo.

Una forma útil de pensarlo: los sitios simples y repetibles con contenido escrito en bloques son los menos riesgosos. Los clientes de alto riesgo son aquellos con temas clásicos profundamente personalizados o plugins propietarios que renderizan su propio front-end. Esa es una razón legítima para quedarse con temas clásicos para ese pequeño nicho. El error es pretender que «listo para producción» es un solo interruptor que está encendido o apagado.

Antes de proponer un tema de bloques a un cliente, pasa por una lista de verificación rápida:

• ¿El cliente tiene un tema profundamente personalizado que requeriría migración?
• ¿Los plugins imprescindibles soportan el Editor de Sitios y la API REST?
• ¿El entorno de alojamiento permite el acceso a archivos que espera el tema de bloques?
• ¿Has reservado tiempo para el diseño de patrones, no solo para el registro de bloques?
• ¿El equipo del cliente tolerará los cambios en el editor, o necesitan una plantilla bloqueada?

Si alguna respuesta es no, ajusta el alcance o usa un enfoque híbrido. Eso no es un compromiso; es juicio de ingeniería. Y si estás construyendo un híbrido, recuerda la historia de hooks y filtros de arriba—aún puedes envolver la lógica antigua en bloques dinámicos mientras el theme.json maneja el aspecto global.

El versionado de tu theme.json no es solo una preocupación teórica. He visto que la biblioteca de bloques personalizados de una agencia se rompe cuando el cliente actualiza WordPress y el archivo style del bloque registrado con wp_register_style() se guarda con un handle cambiado. El arreglo fue fácil, pero el pánico fue real. Un proceso de prueba simple—realiza la actualización en una copia de staging del sitio, haz clic en las páginas clave y luego publica—resuelve la mayoría de estas sorpresas.

La objeción que no te has hecho a ti mismo

Esta es la meta-objeción que impide a las agencias estandarizar: «Es un gran cambio, y no hay tiempo para hacerlo durante el trabajo con clientes». Eso es cierto—así que no lo hagas durante el trabajo con clientes. Elige un proyecto interno o un cliente pequeño y construye una biblioteca de patrones. Usa theme.json como sistema de tokens de diseño. Agrega un bloque personalizado solo cuando esté justificado. Envuelve los hooks antiguos donde ayuden. Itera.

Aquí tienes un bosquejo para los primeros 30 días:

1. Audita tus últimas cinco construcciones de clientes y enumera las diez piezas de diseño más repetidas.
2. Convierte esas diez piezas en patrones de bloques, con un pequeño conjunto de clases CSS.
3. Construye un plugin compartido (o mu-plugin) que registre esos patrones. Si no has pensado en la organización de plugins para esto, hojea esta guía para construir plugins robustos primero.
4. Crea un theme.json que coincida con tu diseño de referencia; agrega valores específicos del cliente a medida que surjan proyectos.
5. Elige un pequeño proyecto interno o un cliente amigable y migra esa pila.
6. Documenta la historia de un héroe: un cliente que editó su página de inicio sin llamarte.

Al final de ese experimento, no tendrás una insignia de «primero los bloques» para colgar en la pared. Tendrás un equipo que puede lanzar un nuevo sitio de cliente desde una base compartida sin disculparse por el cronograma. También estarás en una mejor posición para decir no a la solicitud del cliente de un bloque personalizado número 42—porque sabes exactamente lo que los bloques básicos pueden hacer, o porque puedes mostrar por qué un bloque dinámico sería genuinamente más rápido.

¿Seguirás construyendo algunos sitios a medida? Sí. Algunos clientes siempre necesitarán una plantilla personalizada, una página a medida o una integración propietaria que no vale la pena forzar en el modelo compartido. El objetivo no es eliminar el trabajo a medida—es hacerlo la excepción en lugar del predeterminado.

La repetibilidad proviene de las partes aburridas: un esquema sólido de theme.json, una biblioteca de patrones clara y la disciplina para mantener la capa compartida ligera. Esa no es la versión brillante que escuchas en los seminarios web. Es la que vence la tristeza del lunes por la mañana con un tema en blanco.