Plan de migración — media y social fuera de Enroll¶

Estado: plan escrito, no ejecutado. Es el requisito que el goal pone a la fase 5: no se toca sin un plan verificable, porque aquí hay tablas con datos y rutas que ya usan otros plugins.

1. Lo que hay, medido¶

Dentro de convoca-enroll viven dos subsistemas completos:

Comparten instalador y actualizador (class-media-installer.php, class-media-upgrade-manager.php), osea que hoy no se pueden mover por separado sin llevarse el ciclo de vida.

2. Por qué no es una limpieza¶

• Datos propios. Cuatro tablas con histórico (logs de generación, plantillas, cuentas OAuth, cola de publicación). Moverlas de plugin exige decidir quién es el dueño y no renombrarlas: el nombre de tabla es el contrato con los datos ya guardados.
• Rutas públicas. Cinco rutas de media y cinco de social bajo un namespace que hoy es de Enroll. Cambiar el namespace rompe a cualquier consumidor; se mantienen y se declaran compatibles.
• Ciclo de vida. Instalación, dbDelta y upgrades viven en Enroll. Separar el plugin obliga a mover también las versiones de esquema y a que el nuevo plugin ejecute sus upgrades sin depender de que Enroll esté activo.
• Dependencias de vuelta. Media usa capacidades y utilidades de Enroll; social usa los CPT de actividades. Hay que invertir esas dependencias por contratos de Core antes de separar.

3. Destino propuesto¶

Dos plugins nuevos, convoca-media y convoca-social, ambos con Requires Plugins: convoca-core. No se separan el uno del otro en el mismo paso.

Orden de dependencias: Core → Media → Social (social publica lo que media genera).

4. Pasos, cada uno verificable¶

1. Contratos primero, sin mover nada. Extraer a Core lo que media y social necesitan de Enroll (capacidades, utilidades, acceso a actividades) y dejar pruebas de que Enroll sigue igual. Verificación: inventario --check en verde y batería de Enroll intacta.
2. Plugin vacío que se activa solo. convoca-media con su cabecera, su Requires Plugins y su instalador propio que no crea tablas todavía (las tablas siguen siendo de Enroll). Verificación: se activa y desactiva sin fatales, con Enroll activo y sin él.
3. Mover código, no datos. Las clases pasan al plugin nuevo; las tablas no se tocan. Las rutas conservan el namespace actual. Enroll deja de cargar media/ cuando convoca-media está activo (guarda class_exists, una sola vez). Verificación: captura de las pantallas de media antes/después + rutas idénticas (el mismo arnés de capturar-rutas que ya se usó en Members).
4. Traspaso del esquema. El instalador de convoca-media pasa a ser el dueño de dbDelta con la misma definición; Enroll deja de ejecutarla. Ninguna tabla se renombra ni se copia. Verificación: comparar SHOW CREATE TABLE de las cuatro tablas antes y después: idéntico. Y una prueba de que una instalación limpia crea las tablas.
5. Retirada de la copia vieja, solo después de un ciclo completo con el plugin nuevo activo. Verificación: desactivar convoca-media no debe romper Enroll; reactivarlo recupera todo.
6. Social, repitiendo 2-5 con el mismo orden.

5. Rollback¶

En cada paso: paquete anterior guardado, copia de las cuatro tablas antes del paso 4 y el paso 3 reversible con un commit. Si el paso 4 falla, se restaura el instalador de Enroll y las tablas no se habrán tocado.

6. Cuándo NO hacerlo¶

Si al hacer el paso 1 aparece que media y social comparten estado con el flujo de inscripciones (por ejemplo, decisiones de plazas o de evaluación), se para: sería rediseño de dominio, no una extracción. En ese caso se documenta el acoplamiento y se deja como está, que es lo que el goal manda cuando un trozo no se puede aislar.

7. Estimación honesta¶

Cuatro tablas, diez rutas, dos ciclos de vida y ~5.500 líneas: no es una tarde. Es un goal propio, con su fase de contratos y su ventana de migración. Este documento es el requisito para empezarlo, no un trabajo hecho.