Hacktoberfest 2026: los issues que los mantenedores marcaron para octubre, abiertos y aptos para principiantes. Explorar issues de Hacktoberfest

publish: upload local files referenced by links, not just images

Abierto
#89 1 comentario 0 reacciones 0 asignados Ver en GitHub

Nadie ha tomado este issue todavía.

Evaluación

Dificultad
4/5
Tiempo estimado
3-5 días
Aptitud para principiantes
48/100
Tipo de issue
Nueva funcionalidad
Claridad
Bastante claro
Estado de actividad
Activo
Stack tecnológico
go
Área
cli

Línea de trabajo

Comienza con el registro de adjuntos hacia adelante en images.go:78, luego lee attachname.go y el clamp compartido withinRoot. Compara el manejo de enlaces con renderImage e inspecciona el mapeo en docs/confluence/links-and-anchors.md. Se considera terminado cuando los destinos de enlaces locales que no sean .md y cumplan los requisitos se carguen y reescriban correctamente, mientras que los enlaces .md conserven el comportamiento existente de URL de página y el renderizado inverso de ri:attachment se actualice mediante sourceFor.

Escrito por el modelo de indexación a partir del texto del issue.

Descripción

enhancement

read/export now pass an attachment link through as raw storage rather than converting it, because a markdown link to the exported file would break on the next publish. From the mapping table in links-and-anchors.md:

storage markdown why
ri:attachment passthrough only images are uploaded, so [x](Deck.ppt) would publish as a dead relative href

So this exports:

Grab <ac:link><ri:attachment ri:filename="Deck.ppt" /><ac:plain-text-link-body>the deck</ac:plain-text-link-body></ac:link>.

where Grab [the deck](Deck.ppt). would read better, preview locally, and reference the file export already downloads (it scans raw storage for ri:filename, not just ac:image, precisely so a link target is included).

What blocks it is the forward path, not the inverse one. Only images.go:78 registers an Attachment, so a local file named by a link destination is never uploaded, and republishing [the deck](Deck.ppt) emits <a href="Deck.ppt"> — a relative href that resolves to nothing on Confluence, with no warning and exit 0. That is the silent failure mode docs/confluence/links-and-anchors.md already calls out for unresolved doc links, and it is worse here because the link was working before the round trip.

The work is therefore in the forward direction first: treat a link destination that names a local non-.md file the way an image src is treated — resolve it page-relative, clamp it to the documentation root, register it as an attachment, and rewrite the href to the attachment. attachname.go's source-path↔attachment-name codec and the withinRoot clamp both already exist and are shared with images; what is missing is a link-side caller. Once a link target uploads, flip ri:attachment in the inverse mapping from passthrough to [body](path) via sourceFor, exactly as renderImage does.

Two things to decide when picking this up. Whether a link to a local file should upload it at all, or only when some marker says so — an unqualified rule means any [x](notes.txt) in a repo starts publishing that file as an attachment, which may be more than anyone asked for. And what .md siblings do, which must keep resolving to page URLs via the existing doc-link path rather than becoming attachments.

Split out of #88, where the passthrough decision was made.

Lenguaje dominante
Go
Estrellas
2
Forks
0
Merge medio
2 h 50 min
PR fusionados (30 d)
52

Guía de contribución

Abrir la guía de contribución

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de mozilla/markfluence

Todos los issues de mozilla/markfluence

Issues similares

Más issues de Go

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.