cobalt.rs
cobalt.rs copied to clipboard
cobalt-org
[RFC] Internal linking
Basically this: https://www.getzola.org/documentation/content/linking/
This is also a feature I'd like to have, so opening this ticket to bring discussion on the matter.
I'm planning to code this after pagination and shortcodes
Internal linking would be nice. It gives build-time validation that your links are valid.
We;'ll need to split our processing into two phases
- Load and process every front matter
- this is what we need for internal linking
- Generate
content/ page, in collection dependency order
Zola uses ./ relative paths for internal links.
Another option is for us to auto-add references for all pages. This would make links like [other page][./path/to/other.md].
We'd need to look at how each might perform, the impact of breaking compatibility, etc.
We;'ll need to split our processing into two phases
It'll be best if we want until #560 for this.
Looks like auto-references is possible! And in an efficient way (rather than concatenating a list of site references to every page) There is a "broken link" callback. We'd create a structure that knows all pages and assets with their final location and pass it to the pulldown.
^ This will be annoying for a {markdown} block though. We create the liquid parser once and use it for all pages. This could cause some lifetime issues.
However, if we have an ECS (#560) then we can create the liquid parser in that system which could then live shorter than access to the reference data and all might be well.
Shall this manage dead page as well?
Example: an tag-indexed page with only 1 post, this tag get removed from this post = this tag-indexed page should be deleted.
Because you said:
It gives build-time validation that your links are valid.
But I might misinterpreting here ^^'
The idea is that we'd have an index of all available pages. If an internal link can't be found in that index, then it is broken and we error out.
So the only way at the moment, is to delete _site and build again?
Correct.
I'm mixed about adding an implicit cobalt clean before cobalt build when doing cobalt serve. Ideally, we get incremental site updating / cleanup for cobalt serve. For anything besides cobalt serve, we'd have to scan the tree, compare it to what we plan to generate, and delete the rest ... if that is what the user wants.
btw #593 is an example of someone running into the problem of stray files.
Why not an incremental build as well?
I can't think of a use case where the user want to keep stray files: files in _site that don't have their src counterpart.
@Geobert
Why not an incremental build as well?
I addressed that in
For anything besides cobalt serve, we'd have to scan the tree, compare it to what we plan to generate, and delete the rest ... if that is what the user wants.
serve can keep state between runs while build can't. I left off that we could also have the implicit cobalt clean as part of cobalt build as well. Either way, we want the option of not forcing it in case people are mixing content between different generators (cobalt for their site, mdBook for "book" content, etc).
Oh, mixing generator, I could never think of that! Thanks! ^^
As for keeping state, I was imagining some kind of database to keep track of the generated stuff like a compiler do? Just brainstorming here.
As mentioned in #607, Jekyll supports this, and it’s been a handy feature. I’d love to see it come to Cobalt!
