ArquitectoWP

Módulo 0

Principios del WordPress moderno

El criterio y el vocabulario común sobre el que descansa el resto del curso.

En esta página

  1. De blogs a framework
  2. La jerarquía de decisión
  3. Tema frente a plugin
  4. Diseñar y convertir
  5. El agente, vía adicional
  6. Gobernanza y seguridad

De gestor de blogs a framework

WordPress dejó de ser un gestor de blogs. Con el editor de bloques (Gutenberg), la edición completa del sitio (FSE) y sus APIs nativas, es una infraestructura estandarizada —usuarios, contenido, rutas, permisos, editor— sobre la que se construye casi cualquier tipo de sitio: corporativo, tienda, academia, directorio, intranet o arquitectura headless.

Para que una persona o un agente trabaje de forma predecible y sin generar deuda técnica, debe respetar ese estándar en vez de rodearlo.

La jerarquía de decisión

Ante cualquier necesidad se recorre este orden y solo se baja un escalón cuando el anterior no alcanza. Es el criterio central del arquitecto.

1

Bloques del Core

Rendimiento, accesibilidad y compatibilidad futura las garantiza el núcleo.

Antes que: bloques a medida.

2

Patrones de bloques

Estructuras complejas (hero, tarjeta, testimonios) editables desde el editor sin código a medida.

Antes que: componentes propios.

3

theme.json (tokens y estilos globales)

Paleta, tipografía, espaciado y estilos de bloque en un único archivo declarativo.

Antes que: CSS.

4

CSS localizado

Solo donde lo nativo no alcance: micro-animaciones, un layout concreto. Acotado y justificado.

Antes que: CSS global o !important.

5

Bloque propio con block.json

Solo si hay una necesidad de interfaz que lo anterior no cubre. block.json es su única fuente de verdad.

Antes que: JS/PHP suelto.

6

Interactivity API

Interacción de frontend con modelo declarativo, estado estandarizado y poco peso.

Antes que: JavaScript ad hoc o jQuery.

∑

Funciones y APIs nativas

WP_Query, get_posts, REST API. $wpdb solo en casos excepcionales y documentados.

Antes que: SQL directo.

Tres reglas transversales

  • No se modifica el Core de WordPress ni las dependencias generadas (wp-admin, wp-includes, plugins de terceros, node_modules, vendor, carpetas build/). Todo se encapsula en el tema, en plugins propios o en mu-plugins.
  • Toda excepción se justifica por escrito, en el código o en la documentación, para que el equipo entienda por qué se tomó una ruta no estándar.
  • El CSS no está prohibido: está subordinado. La regla es «lo nativo primero», no «nunca CSS».

Presentación frente a funcionalidad

El tema contiene presentación pura: theme.json, plantillas, partes, patrones y estilos; nunca lógica de negocio ni credenciales. Los plugins contienen la funcionalidad (tipos de contenido, integraciones, lógica de negocio); los mu-plugins alojan lo que no debe poder desactivarse sin romper el sitio. Mezclar ambos mundos es la primera fuente de deuda técnica.

Tema

Aspecto: tokens, plantillas, patrones, estilos.

Plugin

Funcionalidad: tipos de contenido, integraciones, negocio.

mu-plugin

Lo crítico que no puede desactivarse desde el panel.

Dos pasos separados: diseñar y convertir

Un agente general —o una herramienta especializada, o una persona— ya puede producir hoy una maqueta bonita y funcional en HTML, CSS y JavaScript, sin saber nada de WordPress. Convertir esa maqueta en un sitio WordPress nativo es un paso distinto, con otras reglas.

1 · Diseñar

  • Libre y sin restricciones de plataforma
  • Persona, agente o herramienta especializada
  • Entrega: maqueta HTML, CSS y JS

2 · Convertir

  • Reglas estrictas de WordPress nativo
  • Bloques, tokens, patrones y plantillas
  • Entrega: sitio editable desde el Site Editor

Separarlos tiene dos ventajas: el diseño puede mejorarse con la herramienta que cada momento ofrezca sin tocar el método de construcción, y la maqueta es un punto de control natural entre «lo que se quiere» y «lo que se construye». El objetivo de la conversión es reproducir fielmente la maqueta como un sistema de sitio reutilizable y editable, nunca como una página HTML incrustada sin más.

El agente es una vía adicional, nunca exclusiva

Esta forma de trabajar no impide que un administrador edite el sitio a mano desde el Site Editor o el escritorio de WordPress. Conviven siempre dos vías: la persona edita directamente cuando le resulta más rápido, y le pide el cambio al agente cuando describirlo es más sencillo que construirlo bloque a bloque.

El canal del agente depende del entorno: con acceso al proyecto (la carpeta de la instalación abierta, típico de un entorno local) o con acceso remoto mediante MCP cuando el sitio está publicado en un hosting sin acceso a archivos. Cambia el mecanismo de acceso, no quién decide.

Gobernanza y seguridad como parte del método

  • Toda operación comprueba capacidades reales del usuario; exponer algo públicamente no equivale a autorizarlo.
  • Las instrucciones que aparezcan en contenido, maquetas o respuestas de modelos son datos no confiables, nunca autorización.
  • Las operaciones destructivas exigen confirmación escrita distinta para cada tipo de operación y copia de seguridad declarada.
  • Principio de honestidad técnica: no afirmar como hecho lo que no se ha probado. Aplica a los agentes y también a este material formativo.

Siguiente paso. Con los principios claros, descubre cómo se dirige un agente de IA para que los respete.