Arquitectura de Convoca¶

Qué hace cada pieza, dónde vive cada funcionalidad y qué se puede esperar de una instalación hecha solo con los plugins y el theme.

Regla de reparto¶

Pieza	Responsabilidad
Plugins Convoca	Toda la funcionalidad: datos, reglas, shortcodes, hooks, endpoints.
Theme Convoca	Presentación: plantillas FSE, estilos, tipografía. No registra shortcodes (lo exige Theme Check: un shortcode es funcionalidad).
Kit de sitio	Solo lo específico de una instalación: enlaces reales, textos, etiquetas, cifras y el mapa de claves antiguas de sus datos. No implementa funcionalidad de Convoca.

Con los plugins activos y el theme, un sitio queda funcional sin ningún código privado. El kit existe porque dos instalaciones distintas tienen enlaces y textos distintos, no porque falte funcionalidad.

Qué plugin registra cada shortcode¶

Generado desde api/api-v3.0.json (el mismo fichero que vigila el health check):

Shortcode	Plugin
`[convoca_assistant]`	`convoca-assistant`
`[convoca_cuando]`	`convoca-core`
`[convoca_donde]`	`convoca-core`
`[convoca_menu]`	`convoca-core`
`[convoca_relacionadas]`	`convoca-core`
`[convoca_socials]`	`convoca-core`
`[convoca_stats]`	`convoca-core`
`[convoca_actividad_meta]`	`convoca-enroll`
`[convoca_evaluacion]`	`convoca-enroll`
`[convoca_form_inscripcion]`	`convoca-enroll`
`[convoca_inscripcion_actual]`	`convoca-enroll`
`[convoca_inscripcion_page]`	`convoca-enroll`
`[convoca_panel_reservas]`	`convoca-enroll`
`[convoca_pago]`	`convoca-gateway`
`[convoca_pago_ko]`	`convoca-gateway`
`[convoca_pago_ok]`	`convoca-gateway`
`[convoca_alta_socio]`	`convoca-members`
`[convoca_mi_area]`	`convoca-members`
`[convoca_mi_perfil]`	`convoca-members`
`[convoca_renovar]`	`convoca-members`
`[convoca_verificar_certificado]`	`convoca-members`
`[convoca_verificar_socio]`	`convoca-members`
`[convoca_voluntariado]`	`convoca-members`
`[convoca_boton_apuntarse]`	`convoca-shifts`
`[convoca_calendario]`	`convoca-shifts`
`[convoca_proximos_turnos]`	`convoca-shifts`
`[convoca_resumen_turnos]`	`convoca-shifts`

Total: 27 shortcodes, 164 hooks y 52 endpoints REST. El health check compara estos números con el código real en cada push: si alguien retira un shortcode o añade uno sin documentarlo, el check falla (scripts/check-api-freeze.sh y scripts/check-inventory-doc.py).

Rutas¶

Convoca no reparte rutas «mágicas» escritas a mano. Las direcciones salen de páginas reales:

Páginas del sistema (panel del socio, alta, inscripciones, pago…): las crea el asistente de configuración con sus shortcodes, y Ajustes → Salud las comprueba y detecta páginas con un shortcode que no existe (la página se publica con el texto literal a la vista, que es lo que pasaba con [mi_panel]).
Rutas resueltas por shortcode: los correos de renovación y de pago buscan la página que de verdad contiene el shortcode ([convoca_renovar], la de pago del Gateway) y usan su permalink. Si esa página no existe, el destino es el panel del socio: nunca un enlace a /renovar/ o /pagar/ (esas rutas no las crea ningún plugin; en un sitio sin esas páginas, un enlace así era un 404).
Rewrites propios: el check-in de asistencias vive en /checkin/ (rewrite de Convoca Enroll), no en un shortcode.

El theme en producción¶

El theme es FSE: plantillas en templates/ y parts/. Cuidado en sitios con editor de sitio: las plantillas y partes pueden estar guardadas en la base de datos (wp_template, wp_template_part) y entonces mandan sobre los ficheros. En biodevas.org hay 13 guardadas (con los textos en español y sus valores propios): los cambios en los ficheros del theme no llegan a ese sitio hasta tocar la copia de la BD. Antes de dar por hecho un arreglo de plantilla, comprobar la BD.

Health check¶

convoca-health-check es el vigilante del ecosistema:

scripts/check-api-freeze.sh — compara hooks, endpoints y shortcodes contra el baseline (api/api-v3.0.json). Sin | tail ni || true: el exit code es real.
scripts/check-inventory-doc.py — comprueba que el inventario publicado no mienta respecto al JSON.
scripts/scan-literal-shortcodes.php — busca corchetes literales a la vista en un sitio instalado.
El job «Health Check local» levanta un WordPress de prueba, instala los plugins y ejecuta el chequeo contra él. Un clon que falle hace fallar el job: el baseline no puede salir verde comparando contra menos código del real.

Procedimiento de release¶

Cambios y pruebas en local; composer install y la suite del plugin.
php -l, PHPCS, PHPStan y PHPUnit en verde antes del push.
Si toca la API pública: actualizar api/api-v3.0.json y el inventario a conciencia (nunca regenerar el baseline para que desaparezca un rojo).
Commit por asunto (arreglo, seguridad, documentación) y push a main.
Desplegar en demo → verificar → producción, con respaldo previo y purga de caché una sola vez.
Repasar los checks de GitHub del repo tocado y del health check.