Bloque dinámico en Gutenberg: reutilizar lógica sin duplicar código

Transformas la lógica del shortcode en un bloque dinámico robusto, con render en servidor, seguridad y arquitectura reutilizable para crecer sin deuda técnica.

Muchos plugins se quedan en shortcode y desaprovechan la experiencia moderna del editor de bloques.

En esta lección darás el salto a bloque dinámico sin reescribir toda la lógica de negocio.

La idea profesional es simple: una sola fuente de verdad para render y varias superficies de uso (shortcode, bloque, API).

Cuando termines tendrás una implementación preparada para escalar, mantener y evolucionar.

  • Si la salida depende de datos vivos, contexto o permisos, necesitas render en servidor.
  • Un bloque estático guarda HTML en el contenido. Funciona bien para piezas editoriales fijas.
  • Un bloque dinámico ejecuta callback PHP al renderizar, ideal cuando el contenido depende de opciones del plugin, usuario actual, fecha o estado.
  • Caso real: avisos legales por país/rol no pueden resolverse con HTML fijo sin duplicar contenido manual.
  • Estático: contenido fijo y simple.

Cuándo usar bloque dinámico y no bloque estático

Si la salida depende de datos vivos, contexto o permisos, necesitas render en servidor.

Un bloque estático guarda HTML en el contenido. Funciona bien para piezas editoriales fijas.

Un bloque dinámico ejecuta callback PHP al renderizar, ideal cuando el contenido depende de opciones del plugin, usuario actual, fecha o estado.

Caso real: avisos legales por país/rol no pueden resolverse con HTML fijo sin duplicar contenido manual.

  • Estático: contenido fijo y simple.
  • Dinámico: reglas de negocio y contexto.
  • Para plugins: dinámico suele ser la opción más sólida.

Arquitectura limpia: renderer compartido

No dupliques lógica entre shortcode y bloque.

Extrae la generación de salida a una función o clase (`NoticeRenderer`) y reutilízala desde todos los canales.

Así, cuando cambias una regla (por ejemplo, audiencia o tono), la modificación se aplica en bloque y shortcode automáticamente.

Este patrón reduce bugs por divergencia y facilita testing.

Registrar bloque dinámico con `render_callback`

El callback de render debe ser seguro, corto y predecible.

Registra el bloque en `init` y delega todo a tu renderer compartido.

Valida atributos entrantes con whitelist y aplica valores por defecto.

Devuelve siempre string; evita `echo` directo dentro del callback.

Rendimiento del bloque dinámico

Dinámico no significa lento si diseñas caché y consultas bien.

Si el resultado cambia poco, cachea HTML por contexto (por ejemplo, por rol o idioma) con transients.

Evita consultas caras por cada render del bloque en páginas con muchos elementos.

Mide impacto en TTFB al activar el bloque en plantillas de alto tráfico.

WordPress Plugin
12

Bloque dinámico en Gutenberg: reutilizar lógica sin duplicar código

Transformas la lógica del shortcode en un bloque dinámico robusto, con render en servidor, seguridad y arquitectura reutilizable para crecer sin deuda técnica.

Código del tema: register_block_type_from_metadata

📘 Teoría

Cuándo usar bloque dinámico y no bloque estático

Si la salida depende de datos vivos, contexto o permisos, necesitas render en servidor.

Un bloque estático guarda HTML en el contenido. Funciona bien para piezas editoriales fijas.

Un bloque dinámico ejecuta callback PHP al renderizar, ideal cuando el contenido depende de opciones del plugin, usuario actual, fecha o estado.

Caso real: avisos legales por país/rol no pueden resolverse con HTML fijo sin duplicar contenido manual.

  • Estático: contenido fijo y simple.
  • Dinámico: reglas de negocio y contexto.
  • Para plugins: dinámico suele ser la opción más sólida.

Arquitectura limpia: renderer compartido

No dupliques lógica entre shortcode y bloque.

1

Extrae la generación de salida a una función o clase (`NoticeRenderer`) y reutilízala desde todos los canales.

2

Así, cuando cambias una regla (por ejemplo, audiencia o tono), la modificación se aplica en bloque y shortcode automáticamente.

3

Este patrón reduce bugs por divergencia y facilita testing.

Registrar bloque dinámico con `render_callback`

El callback de render debe ser seguro, corto y predecible.

Registra el bloque en `init` y delega todo a tu renderer compartido.

Valida atributos entrantes con whitelist y aplica valores por defecto.

Devuelve siempre string; evita `echo` directo dentro del callback.

1

Error frecuente

Render callback con lógica de negocio extensa.

  • Difícil de mantener.
  • Más riesgo de incoherencias.
  • Peor testabilidad.
2

Patrón recomendado

Callback mínimo + renderer dedicado.

  • Más claridad.
  • Menos duplicidad.
  • Evolución más fácil.

Rendimiento del bloque dinámico

Dinámico no significa lento si diseñas caché y consultas bien.

1

Si el resultado cambia poco, cachea HTML por contexto (por ejemplo, por rol o idioma) con transients.

2

Evita consultas caras por cada render del bloque en páginas con muchos elementos.

3

Mide impacto en TTFB al activar el bloque en plantillas de alto tráfico.

🧪 Aprende probando

Ejemplo Ejemplo guiado: registrar bloque con metadata y render callback Configuramos un bloque dinámico que reutiliza el renderer del plugin.

🏁 Retos

Reto Reto real: añadir atributo `audience` y fallback seguro Extiende el bloque para soportar segmentación básica sin romper render existente.

¿Qué es esto?

Soy Cristian Eslava y a veces hago webs para procrastinar yo y vosotros. culTest

La hice en febrero de 2026 para facilitar el aprendizaje de mis alumnos. La idea es aprender desarrollo web practicando y que el proyecto siga creciendo con nuevos temas, tests y retos.

Está inspirada en MDN, W3Schools, CodePen, Manz y muchos otros sitios de documentación sobre desarrollo web. Quería combinar teoría útil, ejemplos ejecutables, retos y el sistema de tests que ya tenía en culTest. culTest

Si te gustó, si no te gustó o si quieres escribirme, puedes hacerlo en cristianeslava@gmail.com