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>
fea-legacy-redirect manda al archivo cualquier 404, y eso incluia /.well-known/,
que nunca fue contenido de Joomla: son rutas de protocolo (retos de Let's
Encrypt, security.txt, change-password). Lo encontro el Claude de Inma mirando
por que no se emitian los certificados.
No es lo que bloquea los certificados. El reto de LE va por el puerto 80 y ahi
lo atiende Traefik, que lo intercepta antes de llegar a WordPress y no lo
redirige a HTTPS: se ve en que el 404 del puerto 80 viene vacio y sin cabecera
server, mientras cualquier otra ruta da 302. La configuracion lo confirma,
httpchallenge.entrypoint=http. Los certificados no salen porque Traefik no ha
reintentado desde las 10:44, cuando el DNS aun apuntaba a CDMON.
Pero el redirect estaba mal igualmente, y es una trampa para mas adelante: si
algun dia el reto llegara por el 443 (DNS-01 no, pero un cambio de entrypoint o
un renovador distinto si), este 301 lo tumbaria y el certificado no se
renovaria sin que nadie entendiera por que.
Comprobado que lo demas sigue igual: las URLs viejas de Joomla y los 404
genuinos siguen yendo al archivo, y /es sigue llevando a la home.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
La regla del #180 comment-516 dice "recrear los fea-* desde el repo", pero
carta-semana-plugin.php y stop-redirects.php estan vivos en produccion y no
empiezan por fea-: un glob los dejaria fuera. El despliegue copia esta lista.
28 ficheros con su sha256. Excluidos a proposito los .bak-*, el .disabled,
el health-check.php.quarantined-incident-183 (backdoor del #183) y
fea-support-campaign.php, que esta en el repo pero nunca llego a desplegarse.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
rafa