Parches de artículos

A veces un archivo sirve a la vez como contenido del sitio y como archivo que se lee en otro lugar: un README.md que GitHub renderiza, o HTML que comparte otro proyecto. Un parche define los metadatos de su página desde htmlpress.yaml, de modo que el archivo queda tal cual, igual que los parches de Livemark definen el frontmatter de un artículo.

Uso básico

patches:
  - file: README.md
    article:
      title: Introduction
      description: Set up your first project.
      path: /introduction/
      order: 1
  - file: guides/shared.html
    article:
      sidebar: false

Un archivo .md con parche se convierte en una página: su Markdown (con las tablas, listas de tareas, tachado y notas al pie de GitHub) se renderiza a HTML y se compila a su lado como una página .html, aquí movida a /introduction/. Un archivo .html con parche ya debe ser una página.

Campos

file es la ruta relativa al proyecto; article acepta cualquiera de los campos que define el head de una página: title, label, description, icon, order, path, sidebar, breadcrumbs, toc, image, author (uno o una lista), date, tags, sourceUrl y sourceAction. Cualquier otro campo es un error, y también lo es un archivo que no existe, uno fuera del proyecto (mediante .. o un enlace simbólico), o un archivo oculto, de node_modules o de .htmlpress: todo lo que nombra un parche se publica, así que secretos como .env nunca pueden publicarse.

Semántica de la fusión

Los campos de un parche se aplican sobre el head propio de la página; lo que un parche omite conserva su valor normal. Los enlaces relativos dentro de un archivo movido no se reescriben, así que el enlace docs/guide.md de un README sigue apuntando adonde apuntaba.

Qué no puedes parchear

El contenido: el cuerpo de una página es siempre el cuerpo del archivo.

Ver también

• Frontmatter: las etiquetas del head que una página define por sí misma.
• Archivo de configuración: el glob include que decide qué archivos son páginas.