Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

docs: improve rendering of links for local markdown files #1177

Merged
merged 2 commits into from
Apr 4, 2023

Conversation

aepfli
Copy link
Member

@aepfli aepfli commented Apr 4, 2023

Hugo could be better when linking markdown files if they are outside their own folder. With this improvement, we will fetch all relative links, even with .md, and generate their url different than the originial version.

This change now also allows links to .md files within the links, so we don't need to care about this anymore.

Background

In Hugo you can write documentation with two different naming/structuring approaches:

  1. <docName>/_index.md
  2. <docName>.md

The problem is that links from files within the second approach could be simpler. Locally and in the Markdown space, they're in the same folder. But when Hugo renders them, there is a folder level in between.

With this approach, we're changing how hugo renders relative files. Rather than blindly using the link for pages within the documentation, we search for that page, and take the link from this page, generate via Hugo. This way we will always have the right directory levels, for markdown and for hugo

relates: #1170

Hugo is not really good when it comes to linking markdown files,
if they are not within an own folder. With this improvement, we
will fetch all relative links, even with `.md` and generate their
url different than the [originial version](https://gohugo.io/templates/render-hooks/#link-with-title-markdown-example).

Signed-off-by: Simon Schrottner <[email protected]>
@github-actions github-actions bot added the documentation Improvements or additions to documentation label Apr 4, 2023
@netlify
Copy link

netlify bot commented Apr 4, 2023

Deploy Preview for keptn-lifecycle-toolkit ready!

Name Link
🔨 Latest commit 1dd3a14
🔍 Latest deploy log https://app.netlify.com/sites/keptn-lifecycle-toolkit/deploys/642bddd8ce87d2000886d53e
😎 Deploy Preview https://deploy-preview-1177--keptn-lifecycle-toolkit.netlify.app
📱 Preview on mobile
Toggle QR Code...

QR Code

Use your smartphone camera to open QR code link.

To edit notification comments on pull requests, go to your Netlify site settings.

@aepfli
Copy link
Member Author

aepfli commented Apr 4, 2023

This is the first step to fixing issues in #1162

@aepfli
Copy link
Member Author

aepfli commented Apr 4, 2023

incorporate this change also in #1045 - after merge - this can be part of the theme and should not be here

@sonarcloud
Copy link

sonarcloud bot commented Apr 4, 2023

Kudos, SonarCloud Quality Gate passed!    Quality Gate passed

Bug A 0 Bugs
Vulnerability A 0 Vulnerabilities
Security Hotspot A 0 Security Hotspots
Code Smell A 0 Code Smells

No Coverage information No Coverage information
0.0% 0.0% Duplication

@mowies mowies changed the title docs: improve rendering of links for local markdownfiles docs: improve rendering of links for local markdown files Apr 4, 2023
@mowies mowies merged commit 070bbee into keptn:main Apr 4, 2023
@keptn-bot keptn-bot mentioned this pull request Apr 4, 2023
aepfli added a commit to keptn/docs-tooling that referenced this pull request Apr 4, 2023
Hugo could be better when linking markdown files if they are outside their own folder. With this improvement, we will fetch all relative links, even with `.md,` and generate their url different than the [originial version](https://gohugo.io/templates/render-hooks/#link-with-title-markdown-example).

This change now also allows links to `.md` files within the links, so we don't need to care about this anymore.

In Hugo you can write documentation with two different naming/structuring approaches:
1. `<docName>/_index.md`
2. `<docName>.md`

The problem is that links from files within the second approach could be simpler. Locally and in the Markdown space, they're in the same folder. But when Hugo renders them, there is a folder level in between.

With this approach, we're changing how hugo renders relative files. Rather than blindly using the link for pages within the documentation, we search for that page, and take the link from this page, generate via Hugo. This way we will always have the right directory levels, for markdown and for hugo

relates: keptn/lifecycle-toolkit#1177

Signed-off-by: Simon Schrottner <[email protected]>
aepfli added a commit to keptn/docs-tooling that referenced this pull request Apr 4, 2023
Hugo could be better when linking markdown files if they are outside their own folder. With this improvement, we will fetch all relative links, even with `.md,` and generate their url different than the [originial version](https://gohugo.io/templates/render-hooks/#link-with-title-markdown-example).

This change now also allows links to `.md` files within the links, so we don't need to care about this anymore.

In Hugo you can write documentation with two different naming/structuring approaches:
1. `<docName>/_index.md`
2. `<docName>.md`

The problem is that links from files within the second approach could be simpler. Locally and in the Markdown space, they're in the same folder. But when Hugo renders them, there is a folder level in between.

With this approach, we're changing how hugo renders relative files. Rather than blindly using the link for pages within the documentation, we search for that page, and take the link from this page, generate via Hugo. This way we will always have the right directory levels, for markdown and for hugo

relates: keptn/lifecycle-toolkit#1177

Signed-off-by: Simon Schrottner <[email protected]>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
documentation Improvements or additions to documentation
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants