Publish: lint internal links that point at non-live posts

Abierto
#2 0 comentarios 0 reacciones 0 asignados Ver en GitHub

Nadie ha tomado este issue todavía.

Evaluación

Dificultad
3/5
Tiempo estimado
Medio día
Aptitud para principiantes
72/100
Tipo de issue
Nueva funcionalidad
Claridad
Bien especificado
Estado de actividad
Activo
Stack tecnológico
markdown, sqlite, typescript
Área
backend, content

Línea de trabajo

Start in buildLiveSet in src/lib/server/publish.ts, where the publish pass already has the live slug set when it renders post bodies. The new pure function findLinkProblems(body, liveSlugs) belongs in its own module with a *.check.ts file covering the listed link cases. Done means the check passes for every case, warnings appear per post in the Publish view, editor-route links disable the Publish button with a reason, and the rendered .svx text is unchanged.

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

Descripción

good first issue

Context

Posts link to each other by hand with a root-relative slug (/gear). Nothing checks that the target is a live post, so links to drafts, renamed posts and pasted titles ship broken. Publish already knows the full live set when it renders post bodies (buildLiveSet in src/lib/server/publish.ts).

Scope

In the publish pass, scan each live body for links and report:

  • root-relative hrefs whose first segment is not a live slug: a warning per link, shown in the Publish view;
  • hrefs that contain the editor's own origin or start with /posts/ (an editor route, not a site route): block the publish.

Acceptance criteria

  • A pure function findLinkProblems(body, liveSlugs) in its own module with a *.check.ts covering: live slug, unknown slug, renamed slug, editor-route href, external link, anchor-only link, and a title pasted as a path.
  • The Publish view lists warnings per post; editor-route links disable the Publish button with the reason.
  • No change to the rendered .svx text.

Estimate: about 3 hours.

Lenguaje dominante
HTML
Estrellas
0
Forks
0
Merge medio
1 min
PR fusionados (30 d)
2

Preparar el entorno

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 mrgnw/cfcms

Todos los issues de mrgnw/cfcms

Issues similares

Más issues de Backend & API Design

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.