Sports & Communities · Colombia · 2026

WSKF Colombia · Sitio + Plataforma de Gestión

Monorepo WordPress que entrega dos productos en uno: sitio editorial público y una plataforma SaaS interna para gestión de dojos.

Sitio oficial + sistema de gestión de dojos para la seccional colombiana de la World Shotokan Karate-do Federation. Un solo monorepo WordPress entrega dos productos distintos: el sitio público con un lenguaje visual editorial-marcial (papel washi, hinomaru rojo, kanji decorativo), y un plugin SaaS interno con dos React SPAs para sensei y alumnos.

El reto

WSKF necesitaba presencia pública con identidad propia y, al mismo tiempo, un sistema operativo interno para administrar sedes, instructores, alumnos, horarios y asistencia. La restricción era que todo viviera en el mismo WordPress — sin servicios externos, sin Cloud Functions, autenticación nativa.

Lo que construí

Dos productos sobre un mismo monorepo WordPress: tema público con lenguaje "editorial marcial" y plugin SaaS para gestión de dojos.

40+ bloques Gutenberg custom (cero dependencia de ACF) que se componen vía patterns reusables.
Tipografía editorial: Cormorant Garamond para titulares + Noto Serif JP para marcas decorativas en kanji.
Blog nativo con post formats castellanizados (Standard → NOTA, Video → VIDEO, Gallery → GALERÍA), sin necesidad de CPT.
Bloque wskf/gallery propio con lightbox custom: core/gallery tenía conflictos irresolubles con el layout system de WP 6.4+.
Plugin standalone (wskf-tatami) con arquitectura en capas (Api/, Setup/, Database/) y migraciones SQL incrementales versionadas.
Dos React SPAs en un solo bundle compartiendo chunk vendor.js: panel admin (/wp-admin) y portal alumno/instructor (frontend shortcode).
API REST custom en namespace wskf/v1 con permission callbacks por rol.
Roles custom registrados idempotentemente: wskf_instructor, wskf_alumno.

Stack y arquitectura

PSR-4 + Composer para autoload del plugin.
Auth nativo de WP (cookies + nonces) — zero JWT.
React Router en HashRouter (requerido por vivir dentro de URLs de WP).
Castellanización de la UI del admin (Posts → Noticias) sin tocar core.
Cache buster por filemtime en enqueue → invalidación automática en cada build.
Path aliases compartidos entre tsconfig.json y vite.config.js para mantener consistencia entre TypeScript checks y bundling.

Decisiones notables

Componer todo desde bloques nativos en vez de Timber/Twig — el cliente puede armar páginas sin tocar código.
Render server-side en todos los bloques con ServerSideRender para preview en editor → el editor ve exactamente lo que el público va a ver.
Una galería propia desde cero después de descubrir que WP inyecta is-layout-flex !important vía theme.json y pelea cualquier override — más simple recrear que parchear.
Cache buster con filemtime porque LiteSpeed + browsers cachean agresivamente y los hot-reloads de CSS estaban siendo invisibles.

Aprendizajes

WordPress 6.4+ cambió cómo se renderiza el block layout system: los bloques nativos generan CSS inline en <head> que sobreescribe theme styles con misma especificidad. La solución no es siempre pelear la cascada — a veces conviene construir tu propio bloque.
Mantener UX consistente entre el admin de WP (donde los autores escriben) y el render público requirió escribir un editor.css específico que imita los estilos del frontend.
Diseñar para autores no-técnicos: cada bloque tiene defaults razonables y panel de Inspector con controles autoexplicativos en castellano.