78879aef686ecec12b93268413a408362049e69d
36 URLs en 500 desde el cutover: las mismas 9 cartas de otras semanas en fr/it/en/pt. En espanol iban bien, y contra CDMON las mismas URLs daban 200, o sea que era regresion nuestra. La reescritura de enlaces internos al idioma activo llamaba a url_to_postid() una vez por enlace, y estas cartas traen unos 40. Cuando la URL no encaja en ninguna regla de reescritura, la WP_Query que monta esa funcion se queda sin clausula que la acote y se trae las 32.311 entradas CON su contenido, dos veces por peticion. 256 MB agotados en class-wpdb.php y 500. Se sustituye por fea_href_a_post_id(): ultimo segmento del path y una consulta con LIMIT 1, que no puede degenerar, cacheada por peticion. El ORDER BY reproduce a quien sirve WordPress esa misma URL, y no es cosmetico: hay 4 slugs compartidos por una pagina de primer nivel y una entrada, donde gana la pagina, y 58 compartidos por dos entradas -duplicados del import de Joomla- donde gana la de post_date mas reciente. Mi primer intento ordenaba por ID ASC y en esos 58 habria traducido el enlace equivocado. Verificado: 116/116 cartas traducidas en 200, 200 entradas al azar en 200, E2E 13/13, y el resolutor nuevo coincide con url_to_postid() en 461 de 461 slugs de los casos donde url_to_postid() no revienta. La consulta gorda ha desaparecido del performance_schema. Van dos centinelas a la suite E2E, una carta italiana y una francesa de las que fallaban. Nota de metodo para el futuro: esto no se reproduce con wp-cli, porque Polylang no instancia su frontend en CLI y el filtro sale antes de tiempo. Se cazo mirando events_statements_history_long en MySQL mientras se pedia la pagina por HTTP. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
feadulta.org — Migración Joomla → WordPress
Working tree del proyecto feadulta.org. WordPress nuevo, scripts de migración K2 → WP, mu-plugins custom.
La documentación operativa está en la wiki del repo.
Enlaces rápidos
- Wiki — Home
- Credenciales y accesos
- Infraestructura
- Arquitectura WordPress
- Sincronización local → producción
- Limitaciones del servidor de producción
- Roadmap
- Issues
Runbooks locales
Estructura local
/home/rafa/joomla-migration/
├── wordpress/ WP local (Docker)
│ └── wp-content/mu-plugins/ fea-homepage.php, carta-semana-plugin.php (trackeados)
├── joomla/ Joomla legacy restaurado (solo lectura, port 8080)
├── joomla-php83/ Joomla con PHP 8.3 (deploy compat, port 8083)
├── scripts/ Importadores, fixers, cutover
├── tools/
│ ├── e2e/ Suite Playwright + Gemma vision
│ └── akeeba-kickstart/ Kickstart.php para restaurar .jpa
├── (backups/ ya no está aquí — movida a N:\Backup\Joomla_db el 2026-07-06, ~25 GB, fuera de WSL)
├── archive/ Scripts setup-inicial y logs migración (gitignored)
├── analisis-cartas/ Histórico de cartas semanales
├── evangelios_html/ HTML de los evangelios
├── capturas/ PNGs de referencia (gitignored)
└── docker-compose.yml
Arrancar el entorno local
cd /home/rafa/joomla-migration
docker compose up -d
# WordPress: https://farmer.taild3aaf6.ts.net/fea/ (Tailscale + Caddy)
# Joomla (legacy, consulta): http://localhost:8080
Description
Languages
PHP
61%
Python
35.7%
Shell
3.3%