rafa/feadulta
1
0
Fork 0
Code Issues 71 Pull Requests 5 Actions Packages Projects Releases Wiki Activity

CUTOVER Joomla→WordPress (mañana): checklist maestro, backups, rollback y verificación #153

New Issue
Open
opened 2026-07-07 13:54:09 +00:00 by rafa · 2 comments
rafa commented 2026-07-07 13:54:09 +00:00
Owner
Copy Link
Copy Source

Cutover Joomla → WordPress — checklist maestro (fecha objetivo: mañana)

Issue de referencia rápida para el día del cutover. Consolida la wiki Cutover-DNS (23-06-2026, sigue siendo la base válida) + el estado real que he verificado ahora mismo en el servidor, y añade lo que falta: backups, rollback explícito y puntos que la wiki no cubre.

⚠️ Aviso de numeración: la wiki enlaza a issues viejos (#93, #122, #125...) que ya NO EXISTEN en este Gitea (se reinició la numeración al migrar a gitea.feadulta.com el 2026-06-28). Mapeo a los actuales:

  • viejo #125 (seguridad login) → actual #18
  • viejo #19 (noindex) → actual #6
  • viejo #93/#122 (GA4) → actual #16
  • El resto de referencias de la wiki (#1, #3, #4, #5) SÍ coinciden con los actuales.

0. Mecanismo real del cutover (confirmar antes de nada)

Verificado por SSH: Joomla vive en /web/ y WordPress en /web/wp-nuevo/, en el MISMO servidor (134.0.10.170), bajo la misma cuenta cPanel feadulta. wp-nuevo.feadulta.com es un subdominio que ya apunta a /web/wp-nuevo/.

Esto significa que el cutover probablemente NO es un cambio de DNS a otro servidor, sino:

  • o bien cambiar el document root del dominio principal www.feadulta.com/feadulta.com en el panel cPanel de /web → /web/wp-nuevo (lo más limpio), o
  • mover directorios (mv web web-joomla-old && mv web-joomla-old/wp-nuevo web).

Antes de ejecutar nada, confirmar explícitamente cuál de los dos métodos se va a usar — cambia el plan de rollback (ver §6). Si de verdad hay un cambio de DNS/IP de por medio (proveedor DNS distinto), hay que bajar el TTL con 24h de antelación y ya vamos tarde para mañana — comprobar esto primero.

1. Backups (verificado ahora mismo, 2026-07-07)

  • ✅ UpdraftPlus SÍ hace backup diario de la BD de wp-nuevo: wp-content/updraft/backup_YYYY-MM-DD-*-db.gz, uno por día desde 15-06 hasta hoy (07-07), ~104MB. El de esta noche (07-07 05:09) ya está.
  • ⚠️ NO he encontrado backups de ARCHIVOS (uploads, mu-plugins, tema, TTS mp3, avatares) en updraft/ — solo hay *-db.gz. Verificar si UpdraftPlus tiene programado backup de ficheros y a dónde va (¿remoto configurado o solo local?). Si el backup de ficheros no existe, hacerlo a mano antes del cutover (al menos wp-content/uploads/ y wp-content/mu-plugins/).
  • ⚠️ Backup completo de Joomla (/backup/feadulta.com-*.zip) es de 2025-10-10 — tiene 9 MESES. No es el backup que protege el cutover en sí (Joomla no se toca/borra), pero si algo grave pasa y hace falta restaurar Joomla desde cero, ese backup está muy desactualizado. Recomendado: generar uno nuevo desde cPanel antes de mañana si el proceso de cutover incluye tocar Joomla de alguna forma.
  • Confirmar que el backup de hoy de wp-nuevo (DB) es restaurable (no solo que existe el fichero).
  • Backup manual adicional justo antes de ejecutar el cutover (no fiarse solo del cron de las 05:09 — puede haber cambios de última hora).
  • Congelar cambios editoriales durante la ventana del cutover (nadie publica en Joomla ni en WP mientras se ejecuta).

2. Pre-requisitos de contenido/plugin — bloqueantes vs no bloqueantes

Recomendado hacer SÍ o SÍ antes/durante el cutover:

  • #6 Quitar noindex,nofollow de WordPress (si no, Google no indexará nada tras el cambio).
  • #18 Reinstalar seguridad de login (limit-login-attempts-reloaded + mu-plugin fea-cloudflare-realip.php) — crítico: sin el mu-plugin, LLAR bloquea a todo el mundo porque ve la IP compartida de Cloudflare como origen de todos los intentos.
  • #22 Autoría incorrecta (artículos con autor "feadulta" genérico) — no bloquea el cutover técnico, pero es visible públicamente desde el día 1. Valorar si se corrige antes o se acepta como conocido.
  • #17 Enlace conservador Joomla→WordPress en páginas legacy — confirmar si aplica solo mientras conviven ambos sitios o si es necesario tras el cutover.
  • Redirects 301 Joomla→WP para las URLs con más tráfico (GA4/Search Console) — sección "Redirecciones y SEO" de la wiki, no marcada como hecha en ningún issue.
  • Verificar propiedad del dominio feadulta.com en Search Console antes del cambio.

NO bloqueantes (post-cutover, no mezclar con la ventana de mañana):

  • #4 AdSense — decisión ya tomada: NO activar en el mismo cambio, esperar 7-14 días.
  • #5 Wordfence, #8 cambio de tema, #10/#11/#12/#15 avatares/multiidioma, #20 evangelio diario, #23 cron auto-traducción/TTS.
  • #7 46 enlaces K2 huérfanos, #149 enlaces de contenido reutilizado mal mapeados (Salomé/evangelio/lecturas) — confirmado por Inma que no bloquea, arreglo incremental semana a semana.
  • #9 navegación cartas antiguas, #19/#21 cosas estéticas del single.

Decisiones pendientes con Inma (issue #150, aún sin cerrar) — no bloquean el cutover pero conviene zanjarlas esta semana:

  • _carta_id expuesto por REST o endpoint dedicado para Mixbot.
  • Noticias de alcance: ¿se queda también en el cuerpo de la carta o solo en el bloque del footer (cat 41)?
  • Perfiles Calvo duplicados (1048/948, Rafael Calvo Beca/Torrejón) — ¿fusionar o son personas distintas?

3. Checklist técnico pre-cutover (de la wiki, revisar estado real)

  • Confirmar siteurl/home final: https://www.feadulta.com.
  • Buscar y reemplazar referencias internas a wp-nuevo.feadulta.com y farmer.taild3aaf6.ts.net/fea por el dominio definitivo (posts, options, menús, mu-plugins hardcodeados).
  • Revisar canonical, Open Graph, hreflang (Polylang), feeds y sitemap con las URLs finales.
  • Confirmar HTTPS/certificado válido para www.feadulta.com sirviendo WordPress (ya hay cert en /cert/feadulta.com.*, confirmar que cubre www.).
  • Regenerar permalinks tras el cambio de dominio.
  • wp-nuevo.feadulta.com debe seguir con noindex después del cutover (que quede como staging, no indexable).
  • Confirmar que Cloudflare no bloquea Googlebot ni crawlers sociales (recordar el histórico de 403 Bot Fight Mode, #18/viejo #125).

4. Ejecución (orden sugerido, de la wiki)

  1. Backup manual de última hora (§1).
  2. Cambiar el docroot/mecanismo de servido de www.feadulta.com a WordPress (confirmar método, §0).
  3. Actualizar home/siteurl y limpiar URLs de staging.
  4. Regenerar permalinks.
  5. Activar redirecciones Joomla → WordPress.
  6. Quitar noindex de WordPress (#6).
  7. Verificar canonical/hreflang/sitemap/Open Graph.
  8. Purgar caché de WordPress y Cloudflare.
  9. Verificar GA4 en tiempo real para www.feadulta.com (#16).
  10. Smoke tests: portada (5 idiomas), carta de la semana, evangelios, EFFA, autores, buscador, alta boletín, imágenes, audio TTS, wp-admin/login.
  11. Verificar seguridad de login (#18).

5. Post-cutover — verificación y monitorización

Inmediato:

  • Enviar sitemap nuevo en Search Console.
  • Solicitar indexación manual de: portada, carta actual, portadas por idioma, secciones principales, artículos con más tráfico histórico.
  • Revisar cobertura/canonical elegida por Google, 404s, redirecciones.
  • Actualizar enlaces propios (Brevo, redes sociales, perfiles) al dominio definitivo.

Primeras 48h:

  • Códigos de respuesta (200/301/404) de las URLs principales.
  • Errores de servidor/carga.
  • GA4 por hostname.
  • Tráfico orgánico / errores de indexación.
  • Brevo y carta semanal funcionando.
  • Comportamiento móvil.
  • Intentos de login y reglas Cloudflare (que LLAR + mu-plugin realip estén activos y no bloqueando gente legítima).

2-4 semanas:

  • Usuarios/sesiones/páginas vistas vs histórico Joomla.
  • Páginas de entrada orgánicas.
  • Cobertura del sitemap, URLs excluidas.
  • 404 de enlaces externos.
  • Core Web Vitals.

No esperar que toda la migración aparezca indexada de golpe — fluctuaciones normales varias semanas mientras Google recrawlea.

6. Rollback — plan explícito

Trigger: fallo crítico detectado en los smoke tests o en las primeras horas (portada caída, carta no accesible, login roto, pérdida de datos).

Pasos:

  1. Revertir el docroot/mecanismo del §0 para que www.feadulta.com vuelva a servir Joomla (/web/).
  2. Desactivar cualquier regla nueva de Cloudflare/redirects que interfiera.
  3. Purgar caché de Cloudflare.
  4. Verificar portada, carta y login de Joomla tras el rollback.
  5. Conservar logs y datos de la ventana fallida para diagnosticar antes del siguiente intento.

Importante: el rollback NO debe borrar WordPress ni sus datos. Joomla se mantiene disponible/sin tocar hasta que WordPress supere la fase de estabilización (mínimo 7-14 días, alineado con la ventana de AdSense de #4).

Ojo con el mecanismo elegido en §0: si el cutover se hace moviendo directorios (mv) en vez de cambiar el docroot desde el panel, el rollback es más arriesgado (hay que deshacer el mv exacto) — por eso conviene decidir y documentar el método exacto ANTES de ejecutar, no improvisarlo mañana.

7. Resumen — qué falta decidir/hacer HOY antes de mañana

  1. Confirmar mecanismo exacto del cutover (§0) y si hay TTL/DNS real de por medio.
  2. Confirmar que hay backup de FICHEROS además de BD, o hacerlo a mano.
  3. Decidir si #6 (noindex), #18 (seguridad login) y #22 (autoría) se resuelven antes de ejecutar o inmediatamente después, dentro de la misma ventana.
  4. Freeze de contenido acordado con Inma durante la ventana.
  5. Tener a mano el plan de rollback del §6 escrito/impreso, no solo en la cabeza.

Referencias: wiki Cutover-DNS, #1, #2, #3, #4, #5, #6, #16, #17, #18, #22, #146, #149, #150, #151.

# Cutover Joomla → WordPress — checklist maestro (fecha objetivo: mañana) Issue de referencia rápida para el día del cutover. Consolida la [wiki Cutover-DNS](../../wiki/Cutover-DNS) (23-06-2026, sigue siendo la base válida) + el estado real que he verificado ahora mismo en el servidor, y añade lo que falta: backups, rollback explícito y puntos que la wiki no cubre. **⚠️ Aviso de numeración:** la wiki enlaza a issues viejos (#93, #122, #125...) que ya NO EXISTEN en este Gitea (se reinició la numeración al migrar a `gitea.feadulta.com` el 2026-06-28). Mapeo a los actuales: - viejo #125 (seguridad login) → actual **#18** - viejo #19 (noindex) → actual **#6** - viejo #93/#122 (GA4) → actual **#16** - El resto de referencias de la wiki (#1, #3, #4, #5) SÍ coinciden con los actuales. ## 0. Mecanismo real del cutover (confirmar antes de nada) Verificado por SSH: Joomla vive en `/web/` y WordPress en `/web/wp-nuevo/`, **en el MISMO servidor** (`134.0.10.170`), bajo la misma cuenta cPanel `feadulta`. `wp-nuevo.feadulta.com` es un subdominio que ya apunta a `/web/wp-nuevo/`. Esto significa que el cutover **probablemente NO es un cambio de DNS a otro servidor**, sino: - o bien cambiar el **document root del dominio principal** `www.feadulta.com`/`feadulta.com` en el panel cPanel de `/web` → `/web/wp-nuevo` (lo más limpio), o - mover directorios (`mv web web-joomla-old && mv web-joomla-old/wp-nuevo web`). **Antes de ejecutar nada, confirmar explícitamente cuál de los dos métodos se va a usar** — cambia el plan de rollback (ver §6). Si de verdad hay un cambio de DNS/IP de por medio (proveedor DNS distinto), hay que bajar el TTL con 24h de antelación **y ya vamos tarde para mañana** — comprobar esto primero. ## 1. Backups (verificado ahora mismo, 2026-07-07) - ✅ **UpdraftPlus SÍ hace backup diario de la BD** de wp-nuevo: `wp-content/updraft/backup_YYYY-MM-DD-*-db.gz`, uno por día desde 15-06 hasta hoy (07-07), ~104MB. El de **esta noche (07-07 05:09) ya está**. - ⚠️ **NO he encontrado backups de ARCHIVOS** (uploads, mu-plugins, tema, TTS mp3, avatares) en `updraft/` — solo hay `*-db.gz`. Verificar si UpdraftPlus tiene programado backup de ficheros y a dónde va (¿remoto configurado o solo local?). Si el backup de ficheros no existe, **hacerlo a mano antes del cutover** (al menos `wp-content/uploads/` y `wp-content/mu-plugins/`). - ⚠️ **Backup completo de Joomla (`/backup/feadulta.com-*.zip`) es de 2025-10-10 — tiene 9 MESES**. No es el backup que protege el cutover en sí (Joomla no se toca/borra), pero si algo grave pasa y hace falta restaurar Joomla desde cero, ese backup está muy desactualizado. Recomendado: generar uno nuevo desde cPanel antes de mañana si el proceso de cutover incluye tocar Joomla de alguna forma. - [ ] Confirmar que el backup de hoy de wp-nuevo (DB) es restaurable (no solo que existe el fichero). - [ ] Backup manual adicional justo antes de ejecutar el cutover (no fiarse solo del cron de las 05:09 — puede haber cambios de última hora). - [ ] Congelar cambios editoriales durante la ventana del cutover (nadie publica en Joomla ni en WP mientras se ejecuta). ## 2. Pre-requisitos de contenido/plugin — bloqueantes vs no bloqueantes **Recomendado hacer SÍ o SÍ antes/durante el cutover:** - [ ] **#6** Quitar `noindex,nofollow` de WordPress (si no, Google no indexará nada tras el cambio). - [ ] **#18** Reinstalar seguridad de login (`limit-login-attempts-reloaded` + mu-plugin `fea-cloudflare-realip.php`) — **crítico**: sin el mu-plugin, LLAR bloquea a todo el mundo porque ve la IP compartida de Cloudflare como origen de todos los intentos. - [ ] **#22** Autoría incorrecta (artículos con autor "feadulta" genérico) — no bloquea el cutover técnico, pero es visible públicamente desde el día 1. Valorar si se corrige antes o se acepta como conocido. - [ ] **#17** Enlace conservador Joomla→WordPress en páginas legacy — confirmar si aplica solo mientras conviven ambos sitios o si es necesario tras el cutover. - [ ] Redirects 301 Joomla→WP para las URLs con más tráfico (GA4/Search Console) — sección "Redirecciones y SEO" de la wiki, no marcada como hecha en ningún issue. - [ ] Verificar propiedad del dominio `feadulta.com` en Search Console **antes** del cambio. **NO bloqueantes (post-cutover, no mezclar con la ventana de mañana):** - **#4** AdSense — decisión ya tomada: NO activar en el mismo cambio, esperar 7-14 días. - **#5** Wordfence, **#8** cambio de tema, **#10/#11/#12/#15** avatares/multiidioma, **#20** evangelio diario, **#23** cron auto-traducción/TTS. - **#7** 46 enlaces K2 huérfanos, **#149** enlaces de contenido reutilizado mal mapeados (Salomé/evangelio/lecturas) — confirmado por Inma que no bloquea, arreglo incremental semana a semana. - **#9** navegación cartas antiguas, **#19/#21** cosas estéticas del single. **Decisiones pendientes con Inma (issue #150, aún sin cerrar) — no bloquean el cutover pero conviene zanjarlas esta semana:** - `_carta_id` expuesto por REST o endpoint dedicado para Mixbot. - Noticias de alcance: ¿se queda también en el cuerpo de la carta o solo en el bloque del footer (cat 41)? - Perfiles Calvo duplicados (1048/948, Rafael Calvo Beca/Torrejón) — ¿fusionar o son personas distintas? ## 3. Checklist técnico pre-cutover (de la wiki, revisar estado real) - [ ] Confirmar `siteurl`/`home` final: `https://www.feadulta.com`. - [ ] Buscar y reemplazar referencias internas a `wp-nuevo.feadulta.com` y `farmer.taild3aaf6.ts.net/fea` por el dominio definitivo (posts, options, menús, mu-plugins hardcodeados). - [ ] Revisar canonical, Open Graph, `hreflang` (Polylang), feeds y sitemap con las URLs finales. - [ ] Confirmar HTTPS/certificado válido para `www.feadulta.com` sirviendo WordPress (ya hay cert en `/cert/feadulta.com.*`, confirmar que cubre `www.`). - [ ] Regenerar permalinks tras el cambio de dominio. - [ ] `wp-nuevo.feadulta.com` debe seguir con `noindex` después del cutover (que quede como staging, no indexable). - [ ] Confirmar que Cloudflare no bloquea Googlebot ni crawlers sociales (recordar el histórico de 403 Bot Fight Mode, #18/viejo #125). ## 4. Ejecución (orden sugerido, de la wiki) 1. Backup manual de última hora (§1). 2. Cambiar el docroot/mecanismo de servido de `www.feadulta.com` a WordPress (confirmar método, §0). 3. Actualizar `home`/`siteurl` y limpiar URLs de staging. 4. Regenerar permalinks. 5. Activar redirecciones Joomla → WordPress. 6. Quitar `noindex` de WordPress (**#6**). 7. Verificar canonical/hreflang/sitemap/Open Graph. 8. Purgar caché de WordPress y Cloudflare. 9. Verificar GA4 en tiempo real para `www.feadulta.com` (**#16**). 10. Smoke tests: portada (5 idiomas), carta de la semana, evangelios, EFFA, autores, buscador, alta boletín, imágenes, audio TTS, wp-admin/login. 11. Verificar seguridad de login (**#18**). ## 5. Post-cutover — verificación y monitorización **Inmediato:** - [ ] Enviar sitemap nuevo en Search Console. - [ ] Solicitar indexación manual de: portada, carta actual, portadas por idioma, secciones principales, artículos con más tráfico histórico. - [ ] Revisar cobertura/canonical elegida por Google, 404s, redirecciones. - [ ] Actualizar enlaces propios (Brevo, redes sociales, perfiles) al dominio definitivo. **Primeras 48h:** - [ ] Códigos de respuesta (200/301/404) de las URLs principales. - [ ] Errores de servidor/carga. - [ ] GA4 por hostname. - [ ] Tráfico orgánico / errores de indexación. - [ ] Brevo y carta semanal funcionando. - [ ] Comportamiento móvil. - [ ] Intentos de login y reglas Cloudflare (que LLAR + mu-plugin realip estén activos y no bloqueando gente legítima). **2-4 semanas:** - [ ] Usuarios/sesiones/páginas vistas vs histórico Joomla. - [ ] Páginas de entrada orgánicas. - [ ] Cobertura del sitemap, URLs excluidas. - [ ] 404 de enlaces externos. - [ ] Core Web Vitals. No esperar que toda la migración aparezca indexada de golpe — fluctuaciones normales varias semanas mientras Google recrawlea. ## 6. Rollback — plan explícito **Trigger:** fallo crítico detectado en los smoke tests o en las primeras horas (portada caída, carta no accesible, login roto, pérdida de datos). **Pasos:** 1. Revertir el docroot/mecanismo del §0 para que `www.feadulta.com` vuelva a servir Joomla (`/web/`). 2. Desactivar cualquier regla nueva de Cloudflare/redirects que interfiera. 3. Purgar caché de Cloudflare. 4. Verificar portada, carta y login de Joomla tras el rollback. 5. Conservar logs y datos de la ventana fallida para diagnosticar antes del siguiente intento. **Importante: el rollback NO debe borrar WordPress ni sus datos.** Joomla se mantiene disponible/sin tocar hasta que WordPress supere la fase de estabilización (mínimo 7-14 días, alineado con la ventana de AdSense de **#4**). **Ojo con el mecanismo elegido en §0:** si el cutover se hace moviendo directorios (`mv`) en vez de cambiar el docroot desde el panel, el rollback es más arriesgado (hay que deshacer el `mv` exacto) — por eso conviene decidir y documentar el método exacto ANTES de ejecutar, no improvisarlo mañana. ## 7. Resumen — qué falta decidir/hacer HOY antes de mañana 1. Confirmar mecanismo exacto del cutover (§0) y si hay TTL/DNS real de por medio. 2. Confirmar que hay backup de FICHEROS además de BD, o hacerlo a mano. 3. Decidir si #6 (noindex), #18 (seguridad login) y #22 (autoría) se resuelven antes de ejecutar o inmediatamente después, dentro de la misma ventana. 4. Freeze de contenido acordado con Inma durante la ventana. 5. Tener a mano el plan de rollback del §6 escrito/impreso, no solo en la cabeza. Referencias: wiki [Cutover-DNS](../../wiki/Cutover-DNS), #1, #2, #3, #4, #5, #6, #16, #17, #18, #22, #146, #149, #150, #151.
rafa commented 2026-07-08 00:50:02 +00:00
Author
Owner
Copy Link
Copy Source

Decisión (Rafa, 2026-07-07): mecanismo del cutover = cambiar el document root del dominio principal www.feadulta.com/feadulta.com en el panel cPanel, de /web a /web/wp-nuevo. Es el camino sencillo (§0), no se hace mv de directorios. No hay DNS/IP de por medio (mismo servidor, misma cuenta cPanel) → sin problema de TTL.

Rollback (§6) queda simple: revertir el docroot a /web en el panel.

**Decisión (Rafa, 2026-07-07): mecanismo del cutover = cambiar el document root** del dominio principal `www.feadulta.com`/`feadulta.com` en el panel cPanel, de `/web` a `/web/wp-nuevo`. Es el camino sencillo (§0), no se hace `mv` de directorios. No hay DNS/IP de por medio (mismo servidor, misma cuenta cPanel) → sin problema de TTL. Rollback (§6) queda simple: revertir el docroot a `/web` en el panel.
rafa commented 2026-07-08 03:25:36 +00:00
Author
Owner
Copy Link
Copy Source

CUTOVER EJECUTADO Y CERRADO (2026-07-07/08)

Resumen para quien retome esto (incluido Mixbot): el cutover se ejecutó por mv físico de
directorios (no cambio de docroot vía panel — bloqueado porque ningún subdominio de esta cuenta
puede apuntar a /web a secas, todos son subcarpetas /web/<nombre>), con ventana de
mantenimiento activa durante la ejecución.

Mecanismo final

  • Joomla: /web/* → /web/antiguo/* (subdominio nuevo antiguo.feadulta.com, con banner +
    noindex para evitar contenido duplicado).
  • WordPress: /web/wp-nuevo/* → /web/*.
  • DB de WP: search-replace de dominio (wp-nuevo.feadulta.com y el host Tailscale de dev →
    www.feadulta.com), blog_public=1, permalinks regenerados.

www.feadulta.com (WordPress) — verificado correcto

Contenido, enlaces internos, GA4 (G-6RT9ZRS4LW, portable sin tocar), Search Console (le
faltaba la meta tag de verificación, añadida como mu-plugin fea-gsc-verification.php),
redirección 301 de URLs viejas de Joomla → antiguo.feadulta.com (mu-plugin
fea-legacy-redirect.php).

antiguo.feadulta.com (Joomla) — arreglado, ver #162

Tras el mv daba HTTP 500 en todo el frontend real. Causa: RewriteBase sin ajustar en
.htaccess tras pasar a vivir en un subdirectorio → bucle de mod_rewrite de Apache
(AH00124). Fix: RewriteBase / en /web/antiguo/.htaccess. Verificado, todo 200 ahora.
Diagnóstico completo y lecciones en #162.

Decisiones de enrutado (basadas en tráfico real de GA4, últimos 28 días)

  • /es/ y /es (29.588 visitas — la URL más visitada del sitio, con diferencia): NO van a
    antiguo, redirigen a la home nueva.
  • comentcol1-4, eucacol1-4, estasemana/esta-semana (ítems de menú del antiguo rotativo de
    columnas de la home, ~33.000 visitas combinadas): se quedan yendo a antiguo sin cambios — es
    navegación interna de la web vieja, nadie llega ahí desde fuera.
  • Resto de URLs de contenido real (evangelios, cantos, artículos vía buscadoravanzado/item/...):
    redirección genérica 301 a antiguo, funcionando correctamente tras el fix de #162.

Cloudflare

Riesgo asumido conscientemente: no había forma de purgar caché (sin token API, gestionado por
Inma) ni de verificar cf-cache-status (Cloudflare bloquea curl con challenge de bot). Puede
haber servido HTML viejo de Joomla brevemente en www.feadulta.com hasta que expiró el caché
natural.

Pendiente, no urgente

  • Eliminar el subdominio wp-nuevo en cPanel (ya no se usa).
  • Borrar /web/antiguo/.htaccess.bak-pre-rewritebase cuando se confirme estable.

¿Cerramos este issue y el #162, o los dejáis abiertos como referencia?

## CUTOVER EJECUTADO Y CERRADO (2026-07-07/08) Resumen para quien retome esto (incluido Mixbot): el cutover se ejecutó por **mv físico de directorios** (no cambio de docroot vía panel — bloqueado porque ningún subdominio de esta cuenta puede apuntar a `/web` a secas, todos son subcarpetas `/web/<nombre>`), con ventana de mantenimiento activa durante la ejecución. ### Mecanismo final - Joomla: `/web/*` → `/web/antiguo/*` (subdominio nuevo `antiguo.feadulta.com`, con banner + `noindex` para evitar contenido duplicado). - WordPress: `/web/wp-nuevo/*` → `/web/*`. - DB de WP: `search-replace` de dominio (wp-nuevo.feadulta.com y el host Tailscale de dev → www.feadulta.com), `blog_public=1`, permalinks regenerados. ### www.feadulta.com (WordPress) — verificado correcto Contenido, enlaces internos, GA4 (`G-6RT9ZRS4LW`, portable sin tocar), Search Console (le faltaba la meta tag de verificación, añadida como mu-plugin `fea-gsc-verification.php`), redirección 301 de URLs viejas de Joomla → antiguo.feadulta.com (mu-plugin `fea-legacy-redirect.php`). ### antiguo.feadulta.com (Joomla) — arreglado, ver #162 Tras el `mv` daba HTTP 500 en todo el frontend real. **Causa: `RewriteBase` sin ajustar en `.htaccess`** tras pasar a vivir en un subdirectorio → bucle de `mod_rewrite` de Apache (`AH00124`). Fix: `RewriteBase /` en `/web/antiguo/.htaccess`. Verificado, todo 200 ahora. Diagnóstico completo y lecciones en #162. ### Decisiones de enrutado (basadas en tráfico real de GA4, últimos 28 días) - `/es/` y `/es` (29.588 visitas — la URL más visitada del sitio, con diferencia): NO van a antiguo, redirigen a la home nueva. - `comentcol1-4`, `eucacol1-4`, `estasemana`/`esta-semana` (ítems de menú del antiguo rotativo de columnas de la home, ~33.000 visitas combinadas): se quedan yendo a antiguo sin cambios — es navegación interna de la web vieja, nadie llega ahí desde fuera. - Resto de URLs de contenido real (evangelios, cantos, artículos vía `buscadoravanzado/item/...`): redirección genérica 301 a antiguo, funcionando correctamente tras el fix de #162. ### Cloudflare Riesgo asumido conscientemente: no había forma de purgar caché (sin token API, gestionado por Inma) ni de verificar `cf-cache-status` (Cloudflare bloquea curl con challenge de bot). Puede haber servido HTML viejo de Joomla brevemente en `www.feadulta.com` hasta que expiró el caché natural. ### Pendiente, no urgente - Eliminar el subdominio `wp-nuevo` en cPanel (ya no se usa). - Borrar `/web/antiguo/.htaccess.bak-pre-rewritebase` cuando se confirme estable. ¿Cerramos este issue y el #162, o los dejáis abiertos como referencia?
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
No items
No Label
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
inma rafa
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: rafa/feadulta#153
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?