Carta 734: lo que tuvimos que corregir a mano — refuerzo de la guía maestra (#151) #159
Reference in New Issue
Block a user
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?
Al revisar y cerrar la carta 734 ("Echar raíces", https://www.feadulta.com/echar-raices/) encontramos varios problemas que tuvimos que arreglar manualmente antes de poder publicar. Los dejamos documentados aquí para que Mixbot los tenga en cuenta en las próximas cartas, y añadimos los puntos que faltaban en la guía #151 /
docs/guia-publicacion-carta-inma.md.1. Los 22 artículos de la semana se quedaron en borrador, sin publicar
Todos los artículos (comentarios al evangelio, artículos seleccionados, multimedia, noticia de alcance) se crearon correctamente con autor y categoría, pero se quedaron en
draftcon el título prefijado[PRUEBA]y nunca se publicaron. La regla #9 de la guía ("limpiad los [PRUEBA] de semanas ya cerradas") se queda corta: hay que publicar cada artículo (quitando el prefijo del título) según se van dando por buenos, no dejarlo para "más adelante". Si el artículo no está publicado, no tiene URL final estable y rompe el punto 2.2. La carta enlazaba URLs adivinadas, no las URLs reales devueltas por la API
Consecuencia directa del punto 1: como los artículos seguían en borrador con
post_namevacío, los enlaces de la carta se compusieron adivinando el slug a partir del título con[PRUEBA](p. ej..../prueba-silencio/). Al publicar de verdad, WordPress genera el slug desde el título limpio y le añade un sufijo (-2,-4...) si ya existe otro post con ese mismo slug (habitual en contenido de temática recurrente: "Silencio", "La palabra", "Te encontré"...). Resultado: 21 de los 22 enlaces de la carta apuntaban a una URL que nunca existió.Regla a partir de ahora: nunca compongáis un
hrefa mano a partir del título. Usad siempre el campolinkque devuelve la API al crear/publicar el post (esto ya lo decía el Paso 1 de la guía: "Guardar esta URL" — el fallo fue que se guardó/usó antes de publicar). Si un artículo se crea en borrador, hay que volver a comprobar su URL final después de publicarlo, porque puede cambiar por colisión de slug.3.
_carta_idsin asignar en ningún artículoNi los 22 nuevos ni los de contenido reutilizado (evangelio, lecturas) tenían
_carta_id. Uno de ellos ("El reinado de Dios", post 3001) además tenía un_carta_idobsoleto de una carta antigua. Esto ya lo resolvimos con un endpoint nuevo — ver §1.5 dedocs/guia-publicacion-carta-inma.mdy el checklist (§8):GET/POST/DELETE /wp-json/fea/v1/carta-id/{id}.4. "Noticias de alcance" duplicada
La regla #5 de la guía ya avisa de esto y aun así se coló: el artículo de la categoría 41 ("Europa endurece su política migratoria...") estaba también enlazado dentro de "Artículos seleccionados para la semana", lo que lo habría duplicado en la portada. Recordatorio: los posts de "Noticias de alcance" se enlazan solo por su categoría (bloque automático del footer), nunca a mano en el cuerpo de la carta.
5. Rotación de categorías
No se había hecho la rotación 733→22 / 732→21 al tener ya lista la 734. Esto es el Paso 4 de la guía, sin cambios — solo lo mencionamos porque en este caso, al no estar publicada la carta 734 (punto 1), tampoco se había llegado a este paso.
Resumen para la próxima carta: publicar cada artículo en cuanto esté listo (no dejarlo en
[PRUEBA]), coger la URL real dellinkde la respuesta tras publicar (no antes), asignar_carta_idcon el endpoint nuevo, no enlazar a mano las Noticias de alcance, y rotar categorías al final. Referencia cruzada: #151 (guía maestra), #155/#156/#157 (otros hallazgos de esta sesión, no relacionados con este flujo).